Tiempo para el efecto
Este blog es una continuación de “¿Cuál es un buen plano de control para operar una gran cantidad de clústeres de Kubernetes?” . El blog anterior describió el enfoque único de Operaciones de Flota de Volterra para administrar una flota de sitios y aplicações de infraestructura. Este blog específico describe un desafío clave de deriva de configuración que enfrenta un equipo de operaciones al realizar cambios de configuración en una gran cantidad de clústeres o sitios. Yo llamo este desafío “Tiempo para hacer efecto”.
¿Qué es el tiempo hasta el efecto?
Se puede describir simplemente como el tiempo que tarda en surtir efecto la intención de una operación. Los ejemplos incluyen:
- ¿Cuánto tiempo tardará en aplicarse mi configuración de política de seguridad en todos mis sitios?
- ¿Cuánto tiempo tardará la última versión de mi aplicação en propagarse a todos los sitios?
- ¿Cuánto tiempo llevará actualizar el sistema operativo o el software de infraestructura en todos mis sitios distribuidos globalmente?
¿Por qué es importante?
Esta pregunta se puede responder a través de algunos ejemplos de clientes del mundo real:
- Meltdown y Spectre: la principal preocupación de todos los CISO después de que se supo la noticia de Meltdown/Spectre era cómo parchar rápidamente el sistema operativo en toda su infraestructura. Se medía cada hora el tiempo que tardaba el equipo de operaciones en cumplir su intención (es decir, actualizar la versión del sistema operativo) para que surtiera efecto.
- ¿Seguro que has oído hablar de la flota de máquinas expendedoras que provocó un ataque de denegación de servicio en una universidad? Aquí está el TL;DR en caso de que no hayas seguido el ataque: los piratas informáticos explotaron una vulnerabilidad de día cero e instalaron malware que se conectó con otras máquinas expendedoras y creó una flota de bots expendedores. Luego envió enormes volúmenes de tráfico y provocó un ataque de denegación de servicio a la universidad. La universidad al detectar el ataque tuvo que configurar las reglas de política de red en cada máquina expendedora una por una para evitar el acceso al servidor de comando y control. Para ellos era sumamente importante que su intención (es decir, bloquear el acceso a un sitio web específico) se hiciera efectiva inmediatamente en todas las máquinas expendedoras para detener el sangrado.
El tiempo transcurrido hasta el efecto es importante para varias categorías, como software de infraestructura, software de aplicação , política de red y política de seguridad.
¿Cuál es el desafío?
La gravedad del desafío se experimenta más cuando el equipo de operaciones tiene que gestionar
- Una gran escala de sitios
- Sitios distribuidos globalmente
- Entornos heterogéneos, es decir, sitios en nubes privadas, públicas y de telecomunicaciones y dispositivos de borde.
- Conectividad inconsistente para los sitios
Un gran ejemplo de un equipo de operaciones de un OEM automotriz responsable de actualizar el software y administrar la conectividad de sus automóviles (en adelante denominados sitios del cliente). La implementación típica incluiría un centro de datos privados desde donde el equipo de operaciones controla sus automóviles a nivel global (o regional, dependiendo de la estructura organizacional).
Para entender el desafío, veamos las soluciones que tiene a su disposición el equipo de operaciones. La mayoría de las soluciones ofrecen software de gestión alojado en el centro de datos privados de un cliente para administrar de forma centralizada la gran escala de sitios distribuidos. Cuando el fabricante de equipos originales (OEM) de automóviles configura una política que debe aplicarse a todos los automóviles, el software de gestión central básicamente descargaría un script de configuración a cada automóvil, uno por uno. El script de configuración podría ser un libro de estrategias de Ansible o un diagrama de Helm que ejecuta una serie de comandos de configuración en cada sitio. Esto se puede visualizar como se muestra en el diagrama a continuación.
El problema es que el tiempo hasta el efecto es directamente proporcional al número de sitios. Los proveedores de software de gestión centralizada argumentarán que, siempre que todas las operaciones se puedan realizar de forma remota y automatizada, esto será lo mejor que se puede lograr.
Volterra no está de acuerdo y lo podemos demostrar en este blog. Hemos construido un plano de control distribuido con un enfoque arquitectónico jerárquico y escalable que está diseñado para garantizar un tiempo mínimo de efecto.
Arquitectura Volterra para un tiempo mínimo de ejecución
Los elementos fundamentales para lograr un tiempo mínimo de efecto son:
- Arquitectura jerárquica basada en árboles
- Plano de control distribuido diseñado específicamente
A continuación se muestra una descripción general de la arquitectura de alto nivel.
El enfoque de arquitectura jerárquica de Volterra es crear un árbol de nodos para la distribución de la configuración. Cada nodo realiza una operación de almacenamiento y reenvío, es decir, almacena la configuración localmente y luego la reenvía a sus hijos. Esto se puede describir mejor con un ejemplo. Cuando un usuario configura un objeto, como una política de red, en la consola Volterra, el plano de control y administración distribuye la configuración a los hijos inmediatos, los bordes regionales (RE). Cada RE almacena la configuración localmente y la reenvía a sus hijos. Los hijos de RE son sitios de clientes conectados a ese RE.
Una arquitectura jerárquica basada en árboles garantiza un tiempo mínimo para obtener resultados. El tiempo hasta el efecto está limitado por la cantidad de niveles en el árbol y la cantidad de hijos por nodo. El número máximo de niveles en el árbol es tres (controlador → RE → sitio del cliente). El número de niños por nodo es directamente proporcional al número de sitios conectados a RE. Se genera una instancia de servicio en el RE para manejar la configuración de un conjunto de sitios. El plano de control de escalamiento horizontal de Volterra genera nuevas instancias de servicio a pedido, si hay un aumento en la cantidad de sitios conectados al RE.
Configuración de prueba
La medición del tiempo hasta el efecto se realizó a gran escala en los sitios de los clientes conectados a dos bordes regionales ubicados en Nueva York (NY8-NYC) y París (PA4-PAR). Los sitios de los clientes estaban distribuidos globalmente en Santa Clara (California), Houston (Texas), Madrid (España), Praga (República Checa), Londres (Reino Unido), etc. Además, los sitios de los clientes se encontraban en entornos heterogéneos como AWS, máquinas virtuales (ESXi), Edge Gateways, incluidas Intel NUC y Fitlet2.
El portal de clientes y el plano de control global de Volterra se ejecutaban en Azure (Washington-IAD). Los sitios de los clientes se distribuyeron en múltiples espacios de nombres e inquilinos para representar un entorno operativo del mundo real.
Las condiciones de falla se simularon eliminando instancias de servicio en el RE y utilizando enlaces de conectividad de mala calidad entre el RE y los sitios del cliente. En la Figura 3 se muestra una vista instantánea en el tiempo de un segmento de toda la flota, en un solo espacio de nombres.
Metodología de prueba
Los registros de auditoría, con marcas de tiempo, se capturan en el sistema Volterra cada vez que se configuran objetos en la consola Volterra y la configuración se aplica en cada sitio del cliente. El tiempo de propagación se midió como la diferencia de tiempo entre la configuración en el portal y la aplicação de la configuración en el sitio del cliente. A continuación se describe un proceso detallado paso a paso.
- Configurar objetos en el portal del cliente.
- Mida la hora de inicio como la hora de creación del objeto en el portal del cliente (en este documento denominado Controlador global de Volterra). Vea la figura 4 como ejemplo.
- Mida el tiempo de finalización como el tiempo de creación del objeto en el sitio del cliente. Vea la figura 5 como ejemplo.
Tenga en cuenta que las capturas de pantalla que se muestran son solo una muestra y no se refieren a la misma iteración de medición.
Hora de inicio de la configuración
Hora de finalización de la configuración
Resultados de la prueba
Los resultados de las pruebas de los tiempos de propagación se muestran en las figuras 6 y 7. El gráfico de la figura 6 indica que la mayoría de las muestras de medición tuvieron un tiempo de propagación entre 0 y 400 ms. Esto significa que todos los sitios de los clientes se actualizan con una nueva configuración entre 0 y 400 ms. Como se mencionó anteriormente, las condiciones de falla se simularon reiniciando los servicios en el RE e introduciendo fallas/demoras de conectividad en el sitio del cliente. El tiempo de propagación de la configuración es más largo en estas condiciones de falla y varía de 600 ms a 9 segundos, en estas pruebas específicas, dependiendo del tipo de falla. Por ejemplo, una falla de conectividad entre RE y los sitios del cliente aumentará el tiempo que tarda la configuración en llegar al sitio del cliente. Sin embargo, el beneficio del plano de control distribuido de Volterra es que sigue el paradigma de configuración eventualmente consistente, es decir, sigue intentando garantizar que la configuración en todos los sitios del cliente esté alineada con la intención definida por el cliente.
El gráfico de la figura 7 indica que el 85% de las veces, todos los sitios de los clientes se actualizan con una nueva configuración en 322 milisegundos. En la situación en que se introducen condiciones de falla, algunos sitios de clientes podrían experimentar un tiempo de propagación de ~3 a 9 segundos.
Descargo de responsabilidad: Estas mediciones están estrechamente relacionadas con la topología, la escala, el entorno de implementación y las situaciones de falla simuladas. No medimos todas las posibles situaciones de falla ni otros entornos. Por lo tanto, no podemos hacer afirmaciones sobre el retraso de propagación en otras situaciones o entornos que no fueron probados. Por ejemplo, si hay una falla en el clúster de Kubernetes, el sistema tendría que esperar a que se detecte la falla, reiniciarse y volver a intentar la configuración, lo que genera un mayor retraso de propagación.