Unidad 4.3: Elasticidad y VM Auto Scaling

Introducción

La elasticidad en IONOS tiene dos ejes distintos que se deciden en momentos diferentes. La escalabilidad vertical aumenta una sola VM en ejecución y es en gran medida una operación en vivo; la escalabilidad horizontal agrega y elimina réplicas completas bajo una política métrica y es el mecanismo de elasticidad administrado de la plataforma. La decisión que une los dos se toma antes de que cualquiera de ellos se ejecute: VM Auto Scaling crea nuevas réplicas a partir de una plantilla de réplica cuya configuración de cómputo (arquitectura CPU, núcleos, RAM) y almacenamiento se establecen de antemano, por lo que elegir el camino administrado horizontal compromete el diseño de réplica del nivel de vuelta en la Unidad 4.1. Esta unidad cubre ambos ejes, los controles anti-flapping que mantienen un grupo de escalado estable, y la precondición sin estado que hace que la escalabilidad horizontal sea segura, luego crea un grupo de escalado automático y realiza un cambio de tamaño en vivo en el nivel de FinCorp.

1. Elasticidad Vertical: Escalado Vertical en Vivo y sus Límites

El Escalado Vertical en Vivo (LVS) cambia los recursos de un VM después de la provisión. En ambos servidores Dedicated Core y vCPU, puede conectar caliente hacia arriba (agregar CPU, RAM, NICs y volúmenes de almacenamiento) mientras el servidor se ejecuta, lo que es cómo reacciona rápidamente a un pico sin una ventana de mantenimiento. Los límites son específicos y son importantes para el diseño:

• Escalado hacia arriba es en vivo; escalado hacia abajo es asimétrico. Puede escalar hacia arriba en vivo CPU, RAM, NICs y volúmenes de almacenamiento. Solo puede escalar hacia abajo en vivo NICs y volúmenes de almacenamiento. Reducir CPU o RAM requiere un reinicio, por lo que un escalado hacia abajo de la computación es una operación planificada, no transparente.
• El límite de conexión caliente de RAM es de 240 GB. La conexión caliente de RAM se deshabilita automáticamente cuando el tamaño de RAM supera los 240 GB. Por encima de ese límite, aumentar RAM fuerza al VM a reiniciarse cada vez, lo que significa que LVS ya no se aplica a esa dimensión.
• Windows está más limitado. Windows permite escalar CPU núcleos en vivo pero no RAM, y escalar más allá de ocho CPU núcleos requiere un reinicio. Planifique los niveles de Windows en consecuencia.

El escalado vertical es la palanca correcta cuando una sola Workload simplemente necesita ser más grande y no se puede dividir, pero tiene un límite duro (un VM no puede superar el host) y el escalado asimétrico hacia abajo lo hace una mala opción para el tráfico que sube y baja. Para eso, se escala hacia afuera.

2. Elasticidad Horizontal: VM Auto Scaling

VM Auto Scaling es el servicio gestionado que lanza y termina réplicas completas de VM para ajustarse a la carga. Actualmente, solo admite escalado horizontal: crea más máquinas virtuales en función de la configuración de réplicas de un grupo en lugar de cambiar el tamaño de las existentes. Dos hechos fundamentales dan forma a cada diseño que lo utiliza.

La configuración de réplicas se decide de antemano. Un grupo de VM Auto Scaling crea nuevas réplicas de VM a partir de una plantilla de réplicas, por lo que la forma de cómputo de la réplica (arquitectura CPU, núcleos, RAM) y el almacenamiento son decisiones de diseño realizadas con antelación, en la Unidad 4.1. Los tipos de almacenamiento de réplicas admitidos son HDD, SSD Premium y SSD Standard. VM Auto Scaling es una característica de acceso temprano, y los Flow Logs aún no están admitidos en réplicas de escalado automático, lo que supone una pequeña pero real brecha de observabilidad que tener en cuenta.

La configuración de réplicas se aplica solo a nuevas réplicas. El grupo tiene una plantilla de réplicas (la definición de VM que se utiliza para crear nuevas réplicas). Cambiar la plantilla o cambiar manualmente los recursos de una réplica solo afecta a las réplicas creadas después del cambio; no cambia el tamaño de la flota existente. Este es el sentido preciso en el que el servicio no realiza escalado vertical: no agrega núcleos, RAM o almacenamiento a máquinas virtuales en ejecución. Los nombres de réplicas generados automáticamente son nombres, no identificadores de servidor, y no se pueden utilizar para recuperar información a través de API, por lo que debe crear sus herramientas operativas en torno al grupo, no en torno a identidades de réplicas individuales.

2.1 Una política de métricas y los controles anti-flapping

Un grupo tiene exactamente una política de métricas: define una sola métrica cuya utilización desencadena el escalado. Las métricas admitidas son la utilización promedio de la arquitectura CPU de la instancia (porcentaje), y los bytes y paquetes de red de entrada y salida. Dentro de esa política, define una acción de escalado hacia arriba y una acción de escalado hacia abajo, cada una con un tipo de cantidad (absoluto o porcentaje) y una cantidad.

Los controles que evitan que el grupo oscile (flapping entre escalado hacia arriba y hacia abajo) no son comodidades opcionales; son el diseño de un grupo estable:

• La brecha de umbral obligatoria. Los umbrales de escalado hacia abajo y hacia arriba deben estar separados por al menos 40 puntos porcentuales. Esta banda muerta evita que una sola lectura de métrica ruidosa desencadene un escalado hacia arriba y un escalado hacia abajo inmediato.
• El período de enfriamiento. Después de una acción de escalado, el grupo espera un período de enfriamiento antes de actuar de nuevo. El valor predeterminado es de 5 minutos; el mínimo es de 120 segundos (2 minutos) y el máximo es de 24 horas. Un período de enfriamiento más corto que el tiempo que necesita una nueva réplica para calentarse y comenzar a absorber la carga es la causa clásica de sobre-escalado.
• El tamaño de lote por acción. Escalar en lotes: el máximo recomendado es de 5 máquinas virtuales por acción de escalado, con un techo de grupo recomendado de alrededor de 100 réplicas y un piso de una réplica. El piso mínimo de una réplica significa que no hay escalado a cero; el grupo siempre mantiene al menos una réplica en caliente.

Configurar un grupo crea dos alarmas de monitoreo automáticamente (una para escalado hacia abajo y una para escalado hacia arriba) según la política. Opcionalmente, la configuración de réplicas puede hacer referencia a una unidad de copia de seguridad para que se almacenen regularmente copias de seguridad de réplicas de VM, y puede asociar un grupo de destino Managed Application Load Balancer (rango de peso de destino de 1 a 256) para que las nuevas réplicas se agreguen automáticamente detrás del equilibrador de carga a medida que aparecen. Esa asociación de ALB es lo que hace que un nivel de escalado sea utilizable: sin ella, las nuevas réplicas no recibirían tráfico.

2.2 La precondición de la ausencia de estado

El escalado horizontal solo es seguro si una réplica se puede crear o destruir sin perder el estado del usuario, porque el grupo agrega y elimina máquinas virtuales completas según su propio calendario. Eso hace que la falta de estado sea una precondición, no un lujo. Cualquier estado de sesión o en proceso debe externalizarse fuera de la réplica, lo cual es exactamente el trabajo de la capa de caché In-Memory DB (Módulo 5): el estado de sesión y el estado compartido viven en la caché, las réplicas permanecen sin estado y el grupo de escalado automático puede cambiarlas libremente. Esta es la misma capa de memoria que la Unidad 1.3 nombró como la sustitución de escalado de lectura, ahora haciendo doble trabajo como la capa de externalización de estado que hace que el escalado automático sea limpio. Un nivel con estado (una base de datos, por ejemplo) nunca es el nivel de escalado automático; se accede a través de un equilibrador de carga de capa 4 privado y se escala mediante los patrones de nivel de datos del Módulo 5.

Consideraciones de diseño

• Escalabilidad. Decida el eje de escalado por nivel: vertical para un Workload que debe ser más grande y no se puede dividir (dentro del límite de 240 GB con conexión caliente y la reducción de CPU/RAM que admite reinicio), horizontal para tráfico que fluye y refluye. Solo se gestiona la ruta horizontal, y esta crea nuevas réplicas a partir de una plantilla de réplica de tiempo de diseño.
• Confiabilidad. La brecha de umbral, el tiempo de enfriamiento y el tamaño del lote son los controles de estabilidad. Un tiempo de enfriamiento demasiado corto en relación con el tiempo de calentamiento de la réplica es el fallo de producción más común, lo que produce una escalada descontrolada.
• Operaciones. Los cambios de configuración de réplica solo se aplican a nuevas réplicas, y los nombres de réplica no son identificadores de servidor, por lo que operan en la abstracción de grupo. El piso mínimo de uno significa presupuestar al menos una réplica siempre activa por nivel de escalado.

DCD Implementación paso a paso

Esta implementación crea un grupo VM Auto Scaling para la capa de aplicación de FinCorp (el nivel Dedicated Core de la Unidad 4.1) y luego realiza un redimensionamiento vertical en vivo para mostrar los dos ejes de elasticidad uno al lado del otro. Los requisitos previos son la plantilla de réplica Dedicated Core (una definición de servidor que el grupo utiliza para crear réplicas) y, para la distribución de tráfico, el Load Balancer de aplicación de capa 7 público de la Unidad 3.3.

Objetivo de la implementación: Configurar un grupo de auto-escalado con una política de métricas y un redimensionamiento en vivo.

Pasos (en el Data Center Designer):

1. En el VDC de FinCorp, inicie Crear grupo VM Auto Scaling. La ventana de creación muestra una pestaña de configuración de auto-escalado y una pestaña de configuración de réplica. Asegúrese de que el centro de datos que hospeda el grupo tenga los recursos necesarios disponibles.
2. En Configuración de auto-escalado, establezca los recuentos de réplica mínimo y máximo del grupo (piso de uno; techo recomendado alrededor de 100).
3. Defina la política de métricas única. Seleccione la métrica (para la aplicación FinCorp, utilización promedio de CPU). Establezca los umbrales de escalado hacia arriba y escalado hacia abajo, manteniéndolos al menos 40 puntos porcentuales aparte.
4. Defina la acción de escalado hacia arriba: tipo de cantidad (Absoluto o Porcentaje) y cantidad (número de réplicas que se van a agregar), manteniendo el lote en o por debajo del recomendado de 5 por acción.
5. Defina la acción de escalado hacia abajo de la misma manera (cantidad mínima de uno).
6. Establezca el tiempo de enfriamiento (predeterminado 5 minutos; mínimo 2 minutos, máximo 24 horas) en al menos el tiempo de calentamiento de la réplica, para que las nuevas réplicas puedan absorber la carga antes de la próxima acción.
7. En Configuración de réplica, defina la plantilla de réplica Dedicated Core (núcleos, RAM, almacenamiento de los tipos compatibles y la imagen de arranque). Asocie el grupo de destino ALB de la Unidad 3.3 para que las nuevas réplicas reciban tráfico (peso de destino 1 a 256; el ALB reenvía a un puerto de destino configurable en cualquier lugar del rango TCP 1 a 65535, no un puerto fijo 80). Opcionalmente, haga referencia a una unidad de copia de seguridad. Haga clic en Crear.
8. Para mostrar la elasticidad vertical, seleccione el Dedicated Core Server subyacente (o un VM administrado manualmente) en el Espacio de trabajo y, en el Inspector, aumente CPU y RAM. Proporcione el cambio: el escalado hacia arriba de CPU y RAM es en vivo (por debajo del techo de 240 GB de RAM con conexión caliente), mientras que un escalado hacia abajo posterior de CPU/RAM requeriría un reinicio.

Errores comunes:

• Establecer los umbrales de escalado hacia arriba y hacia abajo más cercanos que 40 puntos porcentuales. La brecha obligatoria se rechaza si se viola y existe precisamente para evitar el "flapping".
• Un tiempo de enfriamiento más corto que el tiempo de calentamiento de la réplica, lo que causa que el grupo siga escalando hacia arriba antes de que las réplicas anteriores tomen la carga.
• Olvidar asociar el grupo de destino ALB, por lo que las nuevas réplicas aparecen pero no reciben tráfico.
• Esperar que un cambio en la plantilla de réplica cambie el tamaño de la flota en ejecución. Sólo se aplica a las nuevas réplicas; la flota existente no cambia.
• Escalar una capa con estado. Externalice la sesión/estado en la caché en memoria primero; solo las capas sin estado se escalan de manera segura.

Patrón de arquitectura

El nivel web elástico estándar compone tres de los hilos de este curso. El equilibrador de carga de capa 7 público (Unidad 3.3) se sitúa delante de un grupo de auto-escalado de Dedicated Core cuyas réplicas son estatales, con sesión y estado compartido mantenidos en una caché In-Memory DB en la red privada (Módulo 5). Bajo carga, la utilización de CPU cruza el umbral de escalado horizontal, el grupo agrega réplicas en lotes de hasta cinco, el grupo de objetivos de ALB los recoge automáticamente, y el enfriamiento evita la sobre-corrección; a medida que la carga disminuye y cruza el umbral de escalado vertical (al menos 40 puntos más bajo), las réplicas se eliminan hasta llegar al piso de una réplica. Para la aplicación orientada al cliente de FinCorp, este es el nivel que absorbe los cambios diarios de tráfico: la línea de base se dimensiona de tamaño pequeño en Dedicated Core (Unidad 4.1), los picos se manejan agregando réplicas en lugar de una VM permanentemente grande, y como las réplicas no mantienen estado, el grupo puede reemplazarlas sin afectar a los usuarios conectados.

Resumen

La elasticidad de IONOS tiene dos ejes decididos en diferentes momentos. La escalada vertical aumenta una sola VM en ejecución, en vivo para CPU/RAM/NIC/almacenamiento de aumento y NIC/almacenamiento de reducción, con CPU/RAM de reducción que necesita un reinicio y RAM con hotplug deshabilitado por encima de 240 GB. La escalada horizontal a través de VM Auto Scaling es el camino gestionado, una característica de acceso temprano que estampa nuevas réplicas a partir de una plantilla de réplica de tiempo de diseño, con una política de métrica por grupo, un umbral obligatorio de 40 puntos porcentuales, un enfriamiento desde dos minutos hasta 24 horas, orientación por lotes alrededor de cinco máquinas virtuales por acción, y un piso de una réplica (no escalado a cero). La configuración de réplica solo se aplica a nuevas réplicas, y el nivel escalado debe ser sin estado, con estado externalizado al caché In-Memory. La construcción conecta un grupo impulsado por métricas detrás del ALB y muestra un redimensionamiento en vivo junto a él.

Puntos clave:

• Vertical: aumento de CPU/RAM/NIC/almacenamiento en vivo; reducción solo NIC/almacenamiento en vivo; CPU/RAM de reducción necesita un reinicio; RAM con hotplug deshabilitado por encima de 240 GB.
• Escalado automático horizontal estampa nuevas réplicas a partir de una plantilla de réplica de tiempo de diseño (forma de cálculo y almacenamiento), comprometido en la Unidad 4.1.
• Una política de métrica por grupo; umbrales de escalado hacia adentro y hacia afuera deben diferir al menos 40 puntos porcentuales; enfriamiento predeterminado de 5 minutos (2 minutos a 24 horas); lote recomendado de hasta 5 máquinas virtuales; piso de una réplica, no escalado a cero.
• La configuración de réplica solo se aplica a nuevas réplicas; el servicio no redimensiona la flota en ejecución, y los nombres de réplica no son identificadores de servidor.
• El nivel de escalado automático debe ser sin estado, con sesión/estado externalizado al caché In-Memory; asociar un grupo de destino ALB para que las nuevas réplicas reciban tráfico.

Terminología importante:

• Escalado vertical en vivo (LVS): cambio de los recursos de una VM en ejecución, en vivo para aumento y para NIC/almacenamiento de reducción; CPU/RAM de reducción y RAM por encima de 240 GB necesitan un reinicio.
• Política de métrica: la regla única por grupo de escalado automático (una métrica, una acción de escalado hacia afuera y una acción de escalado hacia adentro) que desencadena el escalado.
• Enfriamiento: la espera después de una acción de escalado antes de la siguiente, el control principal anti-escalado excesivo.
• Brecha de umbral: la separación mínima obligatoria de 40 puntos porcentuales entre umbrales de escalado hacia adentro y hacia afuera que evita el balanceo.

Lectura adicional

• Unidad 4.1: Selección de clase de cómputo (por qué el nivel es Dedicated Core).
• Unidad 3.3: Equilibrio de carga - Capa 7 (el ALB al que se adjunta el grupo).
• Unidad 5.5: Base de datos en memoria (el nivel de externalización de estado que hace que el auto-escalado sea seguro).