Unidad 4.3: Elasticidad y VM Auto Scaling

Introducción

La elasticidad en IONOS CLOUD tiene dos ejes distintos que se deciden en momentos diferentes. La escalabilidad vertical aumenta una única 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 de métricas y es el mecanismo de elasticidad administrado por la plataforma. La decisión que une ambos ejes 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 de CPU, núcleos, RAM) y almacenamiento se establecen de antemano, por lo que elegir el camino horizontal administrado compromete el diseño de las réplicas de la capa definido en la Unidad 4.1. Esta unidad cubre ambos ejes, los controles anti-flapping que mantienen estable un grupo de escalado y la precondición sin estado que hace segura la escalabilidad horizontal, y luego crea un grupo de escalado automático y realiza un redimensionamiento en vivo en la capa FinCorp.

1. Elasticidad vertical: escalado vertical en vivo y sus límites

El escalado vertical en vivo (LVS) modifica los recursos de una VM después de su aprovisionamiento. Tanto en servidores Dedicated Core como en servidores vCPU, puede realizar hotplug ascendente (agregar CPU, RAM, NICs y volúmenes de almacenamiento) mientras el servidor está en ejecución. Esto le permite reaccionar rápidamente ante un pico de demanda sin necesidad de una ventana de mantenimiento. Los límites son específicos y son importantes para el diseño:

• El escalado ascendente es en vivo; el escalado descendente es asimétrico. Puede escalar en vivo la CPU, la RAM, las NICs y los volúmenes de almacenamiento. Solo puede escalar en descenso las NICs y los volúmenes de almacenamiento. Reducir la CPU o la RAM requiere un reinicio, por lo que el escalado descendente de cómputo es una operación planificada, no transparente.
• El límite superior del hotplug de RAM es de 240 GB. El hotplug de RAM se desactiva automáticamente cuando el tamaño de la RAM supera los 240 GB. Por encima de ese límite, aumentar la RAM obliga a reiniciar la VM cada vez, lo que significa que el LVS ya no se aplica a esa dimensión.
• Windows tiene más restricciones. Windows permite escalar los núcleos de CPU en vivo, pero no la RAM, y escalar más allá de ocho núcleos de CPU requiere un reinicio. Planifique las configuraciones de Windows en consecuencia.

El escalado vertical es la palanca adecuada cuando una sola carga de trabajo simplemente necesita ser mayor y no puede dividirse, pero tiene un límite rígido (una VM no puede exceder las capacidades del host) y el escalado descendente asimétrico lo hace inadecuado para el tráfico que fluctúa. Para eso, se escala horizontalmente.

2. Elasticidad horizontal: VM Auto Scaling

VM Auto Scaling es el servicio gestionado que inicia y termina réplicas completas de VM para adaptarse a la carga. Actualmente solo admite escalado horizontal: crea más VMs basándose en la configuración de réplicas de un grupo, en lugar de redimensionar las existentes. Dos hechos fundamentales determinan todo diseño que lo utilice.

La configuración de la réplica se decide de antemano. Un grupo de VM Auto Scaling crea nuevas réplicas de VM a partir de una plantilla de réplica, por lo que la forma de cómputo de la réplica (arquitectura de CPU, núcleos, RAM) y el almacenamiento son decisiones de diseño tomadas en la Unidad 4.1. Los tipos de almacenamiento de réplica admitidos son HDD, SSD Premium y SSD Standard. VM Auto Scaling es una función de acceso anticipado, y los registros de flujo aún no son compatibles con las réplicas de escalado automático, lo que constituye una pequeña pero real brecha de observabilidad que debe tenerse en cuenta.

La configuración de la réplica se aplica solo a las réplicas nuevas. El grupo cuenta con una plantilla de réplica (la definición de la VM desde la cual se crean las nuevas réplicas). Modificar la plantilla, o cambiar manualmente los recursos de una réplica, solo afecta a las réplicas creadas después del cambio; no redimensiona la flota existente. Este es el sentido preciso en el que el servicio no realiza escalado vertical: no añade núcleos, RAM ni almacenamiento a las VMs en ejecución. Los nombres de réplica generados automáticamente son NOMBRES, no identificadores de servidor, y no pueden utilizarse para obtener información a través de la API, por lo que debe construir sus herramientas operativas en torno al grupo, no en torno a las identidades individuales de las réplicas.

2.1 Una única política de métrica y los controles contra el oscilado

Un grupo tiene exactamente una política de métrica: se define una única métrica cuya utilización desencadena el escalado. Las métricas admitidas son el promedio de utilización de CPU de la instancia (porcentaje), y los bytes y paquetes de red entrantes y salientes. Dentro de esa única política se define una acción de escalado hacia fuera y una acción de escalado hacia dentro, cada una con un tipo de cantidad (Absoluto o Porcentaje) y una cantidad.

Los controles que impiden que el grupo oscile (alterne entre escalado hacia fuera y hacia dentro) no son comodidades opcionales; son el diseño de un grupo estable:

• La separación obligatoria de umbrales. Los umbrales de escalado hacia dentro y hacia fuera deben estar separados por al menos 40 puntos porcentuales. Esta banda muerta impide que una única lectura ruidosa de la métrica desencadene un escalado hacia fuera y un escalado hacia dentro inmediato.
• El tiempo de espera (cooldown). Tras una acción de escalado, el grupo espera un período de tiempo de espera 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 tiempo de espera 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 del sobreescalado.
• El tamaño del lote por acción. Escale por lotes: el máximo recomendado es de 5 VMs por acción de escalado, con un tope de grupo recomendado de alrededor de 100 réplicas y un mínimo de una réplica. El mínimo de una réplica significa que no existe escalado a cero; el grupo siempre mantiene al menos una réplica en estado cálido.

La configuración de un grupo crea automáticamente dos alarmas de monitorización (una para escalado hacia dentro y otra para escalado hacia fuera) según la política. Opcionalmente, la configuración de la réplica puede hacer referencia a una unidad de copia de seguridad para que las copias de seguridad de las VMs de réplica se almacenen periódicamente, y puede asociar un grupo de destino de Managed Application Load Balancer (rango de peso de destino de 1 a 256) para que las nuevas réplicas se añadan automáticamente detrás del equilibrador de carga a medida que aparecen. Esa asociación con el 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 ausencia de estado

El escalado horizontal solo es seguro si una réplica puede crearse o destruirse sin perder el estado del usuario, porque el grupo añade y elimina VMs completas según su propio calendario. Esto convierte la ausencia de estado en una precondición, no en una ventaja deseable. Cualquier estado de sesión o de proceso debe externalizarse fuera de la réplica, que es exactamente la función del nivel de caché In-Memory DB (Módulo 5): el estado de sesión y compartido reside en la caché, las réplicas permanecen sin estado, y el grupo de escalado automático puede reemplazarlas libremente. Se trata del mismo nivel In-Memory que la Unidad 1.3 denominó como sustituto para el escalado de lectura, que ahora cumple doble función como 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 él a través de un equilibrador de capa 4 privado y se escala mediante los patrones del nivel de datos del Módulo 5.

Consideraciones de diseño

• Escalabilidad. Decida el eje de escalado por nivel: vertical para una carga de trabajo que debe ser mayor y no puede dividirse (dentro del límite de hotplug de 240 GB y la reducción de CPU/RAM que implica reinicio), horizontal para tráfico que fluctúa. Solo la ruta horizontal se gestiona, y crea nuevas réplicas a partir de una plantilla de réplicas definida en tiempo de diseño.
• Fiabilidad. La brecha de umbral, el tiempo de espera y el tamaño del lote son los controles de estabilidad. Un tiempo de espera 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 un escalado horizontal descontrolado.
• Operaciones. Los cambios en la configuración de la réplica solo se aplican a las réplicas nuevas, y los nombres de las réplicas no son identificadores de servidor, por lo que debe operar sobre la abstracción de grupo. El mínimo de uno significa presupuestar al menos una réplica siempre activa por nivel de escalado.

Guía de implementación de DCD

Esta guía crea un grupo de VM Auto Scaling para la capa de aplicación orientada al cliente de FinCorp (la capa Dedicated Core de la Unidad 4.1) y, a continuación, realiza un redimensionamiento vertical en vivo para mostrar los dos ejes de elasticidad lado a lado. Los requisitos previos son la plantilla de réplica de Dedicated Core (una definición de servidor desde la cual el grupo crea 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 construcción: Configurar un grupo de escalado automático con una política de métrica y un redimensionamiento en vivo.

Pasos (en Data Center Designer):

1. En el VDC de FinCorp, inicie Create VM Auto Scaling Group. La ventana de creación muestra una pestaña de Autoscaling Setup y una pestaña de Replica Configuration. Asegúrese de que el centro de datos que aloja el grupo tenga los recursos necesarios disponibles.
2. En Autoscaling Setup, establezca las cantidades mínima y máxima de réplicas del grupo (mínimo de una; máximo recomendado alrededor de 100).
3. Defina la única política de métrica. Seleccione la métrica (para la aplicación de FinCorp, el promedio de utilización de CPU). Establezca el Scale Out Threshold y el Scale In Threshold, manteniéndolos separados por al menos 40 puntos porcentuales.
4. Defina la acción Scale Out: tipo de cantidad (Absoluto o Porcentaje) y cantidad (el número de réplicas a agregar), manteniendo el lote en o por debajo de los 5 recomendados por acción.
5. Defina la acción Scale In de la misma manera (cantidad mínima de una).
6. Establezca el cooldown (predeterminado de 5 minutos; mínimo de 2 minutos, máximo de 24 horas) al menos al tiempo de calentamiento de las réplicas, para que las nuevas réplicas puedan absorber la carga antes de la siguiente acción.
7. En Replica Configuration, defina la plantilla de réplica de Dedicated Core (núcleos, RAM, almacenamiento de los tipos admitidos y la imagen de arranque). Asocie el grupo de destinos del ALB de la Unidad 3.3 para que las nuevas réplicas reciban tráfico (peso de destino de 1 a 256; el ALB reenvía a un puerto de destino configurable en cualquier parte del rango TCP de 1 a 65535, no a un puerto fijo 80). Opcionalmente, haga referencia a una unidad de copia de seguridad. Haga clic en Create.
8. Para mostrar la elasticidad vertical, seleccione el servidor subyacente de Dedicated Core (o una VM gestionada manualmente) en el Workspace y, en el Inspector, aumente la CPU y la RAM. Provisione el cambio: el aumento de CPU y RAM es en vivo (por debajo del límite de hotplug de 240 GB de RAM), mientras que una reducción posterior de CPU/RAM requeriría un reinicio.

Errores comunes:

• Establecer los umbrales de escala hacia dentro y hacia fuera a menos de 40 puntos porcentuales de distancia. La separación obligatoria se rechaza si se incumple y existe precisamente para evitar el flapping.
• Un cooldown más corto que el tiempo de calentamiento de las réplicas, lo que hace que el grupo siga escalando hacia fuera antes de que las réplicas anteriores asuman la carga.
• Olvidar asociar el grupo de destinos del ALB, de modo que las nuevas réplicas aparezcan pero no reciban tráfico.
• Esperar que un cambio en la plantilla de réplica redimensione la flota en ejecución. Solo se aplica a las nuevas réplicas; la flota existente no se modifica.
• Escalar una capa con estado. Primero externalice la sesión/estado a la caché In-Memory; solo las capas sin estado se escalan de forma segura.

Patrón de arquitectura

La capa web elástica estándar combina tres de los hilos de este curso. El equilibrador público de capa 7 (Unidad 3.3) se encuentra delante de un grupo de escalado automático de Dedicated Core, cuyas réplicas son sin estado, con el estado de sesión y el estado compartido almacenados en una caché de In-Memory DB en la red privada (Módulo 5). Bajo carga, la utilización de CPU supera el umbral de escalado hacia afuera, el grupo añade réplicas en lotes de hasta cinco, el grupo de objetivos de ALB las detecta automáticamente y el tiempo de espera (cooldown) previene la sobre corrección; a medida que la carga disminuye y cruza el umbral de escalado hacia adentro (al menos 40 puntos por debajo), las réplicas se eliminan hasta alcanzar el mínimo de una réplica. Para la aplicación orientada al cliente de FinCorp, esta es la capa que absorbe las fluctuaciones diarias del tráfico: la línea base se dimensiona de forma reducida en Dedicated Core (Unidad 4.1), las picos se gestionan añadiendo réplicas en lugar de utilizar una VM permanentemente grande, y dado que las réplicas no conservan estado, el grupo puede reemplazarlas sin afectar a los usuarios autenticados.

Resumen

La elasticidad de IONOS CLOUD tiene dos ejes que se deciden en momentos diferentes. La escalabilidad vertical aumenta una única VM en ejecución, permitiendo la ampliación en vivo de CPU/RAM/NIC/almacenamiento y la reducción en vivo de NIC/almacenamiento, siendo necesario un reinicio para la reducción de CPU/RAM y estando deshabilitado el hotplug de RAM por encima de 240 GB. La escalabilidad horizontal mediante VM Auto Scaling es la ruta administrada, una función de Acceso Anticipado que crea nuevas réplicas a partir de una plantilla de réplica de diseño, con una política de métrica por grupo, un umbral de separación obligatorio de 40 puntos porcentuales, un tiempo de espera (cooldown) de dos minutos a 24 horas, una orientación de lotes de alrededor de cinco VM por acción, y un mínimo de una réplica (sin escalado a cero). La configuración de la réplica se aplica solo a las réplicas nuevas, y la capa escalada debe ser sin estado, con el estado externalizado a la caché In-Memory. La compilación configura un grupo impulsado por métricas detrás del ALB y muestra un redimensionamiento en vivo junto a este.

Puntos clave:

• Vertical: ampliación en vivo de CPU/RAM/NIC/almacenamiento; reducción en vivo solo de NIC/almacenamiento; la reducción de CPU/RAM requiere un reinicio; el hotplug de RAM está deshabilitado por encima de 240 GB.
• El Auto Scaling horizontal crea nuevas réplicas a partir de una plantilla de réplica de diseño (forma de cómputo y almacenamiento), comprometida en la Unidad 4.1.
• Una política de métrica por grupo; los umbrales de escalado hacia dentro y hacia fuera deben diferir en al menos 40 puntos porcentuales; el tiempo de espera (cooldown) predeterminado es de 5 minutos (de 2 minutos a 24 horas); se recomienda un lote de hasta 5 VM; mínimo de una réplica, sin escalado a cero.
• La configuración de la réplica se aplica solo a las réplicas nuevas; el servicio no redimensiona la flota en ejecución, y los nombres de las réplicas no son identificadores de servidor.
• La capa de auto escalado debe ser sin estado, con la sesión/estado externalizado a la caché In-Memory; asocie un grupo de objetivos del ALB para que las réplicas nuevas reciban tráfico.

Terminología importante:

• Escalabilidad vertical en vivo (LVS): cambio de los recursos de una VM en ejecución, en vivo para la ampliación y para la reducción de NIC/almacenamiento; la reducción de CPU/RAM y la RAM por encima de 240 GB requieren un reinicio.
• Política de métrica: la única regla por grupo de auto escalado (una métrica, una acción de escalado hacia fuera y una acción de escalado hacia dentro) que desencadena el escalado.
• Tiempo de espera (Cooldown): la espera tras una acción de escalado antes de la siguiente, el control principal contra el sobreescalado.
• Separación de umbrales: la separación mínima obligatoria de 40 puntos porcentuales entre los umbrales de escalado hacia dentro y hacia fuera que previene el flapping.

Lectura adicional

• Unidad 4.1: Selección de la clase de cómputo (la razón por la que la capa 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 (la capa de externalización del estado que hace que el escalado automático sea seguro).