MSTech Geeks

Introducción

Una de las principales palancas de optimización de costes en Azure Virtual Desktop es el autoescalado mediante un AVD Scaling Plan. Sin embargo, es también una de las funcionalidades que más dudas genera en su configuración: ¿cuándo arranca una nueva VM? ¿cuándo se apaga? ¿qué pasa con los usuarios conectados durante el ramp-down?

En este post vamos a ver cómo configurar un Scaling Plan desde cero sobre un host pool Pooled existente y cómo validar que el comportamiento es el esperado en un entorno de laboratorio real.

¿Qué son los Scaling Plans en AVD?

Un Scaling Plan es el recurso de Azure que permite definir políticas de autoescalado para los host pools de Azure Virtual Desktop. A través de él se establecen las condiciones bajo las cuales el servicio debe encender, apagar, crear o eliminar session hosts de forma automática, sin intervención manual.

Un Scaling Plan no actúa directamente sobre las VMs: lo hace a través del servicio de autoescalado de AVD, que evalúa periódicamente el estado del host pool (número de sesiones activas, capacidad disponible, fase horaria activa) y toma decisiones en consecuencia.

Métodos de escalado

Al crear un Scaling Plan debemos de elegir uno de estos dos métodos:

• Power management autoscaling: el servicio únicamente enciende y apaga VMs que ya existen en el host pool. El número de session hosts es fijo; lo que varía es cuántos están encendidos en cada momento.

• Dynamic autoscaling (preview): el servicio puede, además de encender y apagar, crear y eliminar VMs del host pool en función de la demanda. Es el modo más potente desde el punto de vista de optimización de costes, pero implica que el aprovisionamiento de nuevos session hosts debe estar automatizado y ser reproducible.

Schedules

A la hora de crear un Scaling Plan, es importante entender que este artefacto se articula mediante uno o varios schedules. Cada schedule define un ciclo diario dividido en cuatro fases:

• Ramp-up: periodo de calentamiento previo a las horas pico. Se busca tener capacidad disponible antes de que lleguen los usuarios.
• Peak hours: horas de máxima demanda. El objetivo es garantizar capacidad y experiencia de usuario.
• Ramp-down: descenso de actividad al final de la jornada. El sistema empieza a liberar recursos.
• Off-peak hours: horas de mínima actividad. El pool opera con el mínimo de recursos posible.

Cada fase tiene su propia hora de inicio, algoritmo de balanceo de carga y umbrales de capacidad, lo que permite un control fino del comportamiento del pool a lo largo del día.

Relación con el host pool

Es necesario entender que un Scaling Plan se crea como recurso independiente y se asigna a uno o varios host pools. En el momento de la asignación se puede habilitar o deshabilitar el autoescalado por host pool, lo que permite tener el mismo plan definido pero activarlo selectivamente. Cuando el modo dinámico está activo, el portal bloquea la gestión manual del número de session hosts: el control pasa completamente al plano de autoescalado.

Beneficios de utilizar Scaling Plans

El beneficio más evidente es la reducción del coste de compute. Sin autoescalado, las VMs permanecen encendidas 24 horas independientemente de si hay usuarios conectados. Con un Scaling Plan, el pool se adapta a la demanda real.

En modo Power management el ahorro viene de apagar VMs sin sesiones activas. En modo Dynamic autoscaling el ahorro es mayor: las VMs se eliminan y se deja de pagar tanto el cómputo como los discos asociados mientras no existen.

Más allá del coste, los Scaling Plans aportan otros beneficios relevantes. Permiten alinear capacidad con demanda real en lugar de dimensionar el pool permanentemente para el peor caso. Eliminan la necesidad de mantener automatizaciones externas para gestionar el ciclo de vida de las VMs. Y preservan la experiencia de usuario gracias al Ramp-up, que garantiza capacidad disponible antes de que lleguen los primeros usuarios, y al mecanismo de notificación del Ramp-down, que avisa a los usuarios antes de cerrar sus sesiones.

Un punto a tener en cuenta en modo dinámico: cuando el sistema crea una nueva VM, el proceso lleva varios minutos. Una configuración incorrecta de umbrales y fases puede generar degradación de experiencia en picos de demanda abruptos. El ajuste fino del Ramp-up es clave para evitarlo.

Contexto del laboratorio

El punto de partida es un host pool de tipo “Pooled” (hp-qanat-avd-demo-ne), desplegado en North Europe, con una sola VM (qanat-node-0) y sin ningún scaling plan asignado, es decir, con dimensionamiento estático. El objetivo es convertirlo en un entorno de autoescalado dinámico sin modificar el host pool en sí, únicamente añadiendo y asignando un Scaling Plan.

Paso 1: Crear el AVD Scaling Plan

Desde el portal de Azure, navegamos a “Azure Virtual Desktop > Scaling plans” y creamos un nuevo recurso con los siguientes parámetros básicos:

Paso 2: Configurar el Schedule

Importante hacer notar que un Scaling Plan puede contener múltiples schedules (por ejemplo, uno para días laborables y otro para fin de semana). En este caso creamos un único schedule llamado `weekdays_schedule`, aplicable de lunes a viernes.

El porcentaje mínimo de hosts activos determina qué fracción del pool debe estar disponible como mínimo en todo momento, independientemente de la fase del día. Con un 50% y un máximo de 2 VMs, se garantiza que al menos 1 VM esté siempre activa.

El algoritmo Breadth-first distribuye las sesiones entre todos los hosts disponibles de forma equilibrada. Esto es adecuado en Ramp-up porque se busca repartir la carga antes de que la demanda sea alta. El umbral de capacidad del 60% indica que, cuando un host supere ese porcentaje de ocupación, el servicio de scaling considerará arrancar o crear una nueva VM.

Importante hacer notar que cada fase del schedule define su propio algoritmo de balanceo de carga, que es el que el servicio aplica durante ese intervalo horario. Mientras el Scaling Plan está activo y asignado al host pool, el algoritmo configurado directamente en el host pool no tiene efecto.

En este caso y para esta fase, el algoritmo Depth-first concentra las sesiones en el menor número posible de hosts, dejando los demás libres para ser apagados o eliminados si no tienen carga. Es la estrategia habitual en horas pico para maximizar la eficiencia y reducir el coste: se llenan las VMs antes de encender nuevas.

El umbral de capacidad y los límites de VMs quedan fijados por la configuración heredada de la fase anterior y no son editables en esta pestaña, lo cual es el comportamiento esperado del portal.

La fase de reducción comienza a las 06:00 PM, cuando empieza a descender la demanda.

El parámetro “Force sign out” es uno de los más relevantes en la fase de Ramp-down. Cuando está activado, el servicio de scaling enviará la notificación configurada a los usuarios con sesión activa y, transcurrido el tiempo de espera, cerrará las sesiones y apagará (o eliminará, en modo dinámico) la VM. Si se deja en «No», el sistema esperará a que los usuarios cierren sesión voluntariamente antes de apagar la máquina, lo que puede prolongar indefinidamente el coste.

El horario fuera de pico comienza a las 10:00 PM. En esta fase el pool opera con el mínimo de recursos posible: 1 VM activa, algoritmo Depth-first, esperando el ciclo del día siguiente.

Paso 3: Asignación al Host Pool y validación previa

En la pestaña “Host pool assignments”, asociamos el scaling plan al host pool `hp-qanat-avd-demo-ne` con el autoescalado habilitado. Antes de crear el recurso, el portal muestra el resumen completo en la pestaña “Review + create”, donde podemos confirmar todos los parámetros antes de confirmar.

Un detalle importante que aparece inmediatamente después de asignar el scaling plan al host pool: el portal deshabilita la opción de añadir session hosts manualmente. Además, y como podemos observar, el aviso es explícito:

También podemos observar que el segundo nodo ha sido eliminado, efecto del comportamiento de nuestro nuevo Scaling Plan asignado a este Host Pool.

Validación del comportamiento del laboratorio

• Estado inicial

El host pool parte de  una VM activa (qanat-node-0) y cero sesiones. Es la situación de reposo anterior al inicio del Ramp-up.

• Fase de Ramp-up (08:00 AM)

Durante la fase de Ramp-up el sistema mantiene toda la carga sobre qanat-node-0. Las sesiones van aumentando progresivamente sin que se produzca aún ningún evento de escalado:

– 08:10 AM → 1 sesión activa

– 08:17 AM → 2 sesiones activas

– 08:25 AM → 3 sesiones activas

– 08:49 AM → 4 sesiones activas, 1 sola VM

Este es el comportamiento esperado. El servicio de autoescalado no evalúa la carga en tiempo real, sino de forma periódica. Aunque el umbral de capacidad del Ramp-up está fijado en el 60%, el sistema necesita que esa condición se cumpla en un ciclo de evaluación para actuar. Con 4 sesiones concentradas en una única VM Standard_D2as_v5, la ocupación supera claramente ese umbral y, en el siguiente ciclo, el servicio toma la decisión de provisionar una segunda VM.

El host pool ahora refleja 2 VMs activas, ambas disponibles para recibir sesiones.

• Fase de Peak hours (09:00 AM)

Durante la fase de Peak hours desconectamos dos de las cuatro sesiones activas. Con el algoritmo Depth-first en juego y un umbral de capacidad del 60%, el servicio de autoescalado evalúa que la carga restante puede ser absorbida por un único session host. En el siguiente ciclo de evaluación, elimina qanat-node-1 y el pool vuelve a su tamaño mínimo de una sola VM.

Conclusiones sobre el AVD Scaling Plan

Los Scaling Plans son una herramienta nativa y potente para optimizar el coste de AVD, pero su valor real está en la lógica de fases y en el ajuste fino de umbrales y algoritmos. Una configuración bien pensada adapta el pool a los patrones de uso reales de la organización; una configuración incorrecta puede generar oscilaciones continuas de escalado o degradación de experiencia de usuario.

El modo Dynamic autoscaling maximiza el ahorro, pero exige que el aprovisionamiento de session hosts sea completamente automatizado y reproducible. El Force sign-out es efectivo para liberar recursos, pero es una decisión operativa que debe comunicarse a los usuarios y validarse con las aplicaciones del entorno.

Y sobre todo: antes de llevar cualquier configuración a producción, hay que validarla en laboratorio. Exactamente como hemos hecho en este post.

Si quieres explorar cómo complementar AVD con herramientas de gestión avanzada, puedes leer también Azure Virtual Desktop + Nerdio Manager: la combinación perfecta que convierte el VDI en plataforma.