Microsoft AZ-140: Operaciones, escalado y optimización de hosts de sesión — Guía de estudio

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Virtual Desktop Specialty AZ-140 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Las operaciones de los hosts de sesión en Azure Virtual Desktop (AVD) se centran en tres disciplinas principales: dimensionamiento adecuado e ingeniería de rendimiento, escalado inteligente y gestión de energía, y operaciones fiables del día 2. El objetivo es ofrecer una experiencia de usuario consistente durante la demanda máxima mientras se minimiza el gasto durante las horas de menor actividad, todo ello sin comprometer la mantenibilidad o la recuperabilidad. Esta sección explica cómo diseñar y operar el autoescalado de AVD con planes de escalado, configuración de programación y capacidad, estados operativos como el modo de purga, y la solución de problemas de estado y registro. Luego, vincula la guía de dimensionamiento (incluidas las cargas de trabajo habilitadas para GPU) y la automatización con palancas de optimización de costos como las reservas, los planes de ahorro y el Beneficio Híbrido de Azure.

Diseño del autoescalado: Planes de escalado, programaciones y asignación a grupos de hosts

• Planes de escalado y asignación

  • Un plan de escalado define cuándo y cómo un grupo de hosts agrupado inicia, purga, detiene y desasigna los hosts de sesión. Un plan de escalado puede asignarse a múltiples grupos de hosts, incluso en diferentes regiones.
  • Cada grupo de hosts asignado ejecuta el plan de escalado de forma independiente en su propio contexto de zona horaria. Utilice la configuración de zona horaria del plan de escalado por programación para alinearla con el horario comercial local.
  • Etiqueta de exclusión: defina un par clave/valor de etiqueta para que el autoescalado ignore VMs específicas (p. ej., canarios operativos o pilotos de mantenimiento).
  • El modo de equilibrio de carga es importante: el modo primero en amplitud (breadth-first) distribuye las sesiones entre los hosts (mejora el rendimiento instantáneo, ralentiza la reducción horizontal); el modo primero en profundidad (depth-first) apila las sesiones en menos hosts (maximiza la consolidación y el ahorro de costos). Para un autoescalado centrado en los costos, utilice el modo primero en profundidad con umbrales de capacidad adecuados.

• Programaciones: fase de incremento, pico, fase de reducción, fuera del pico

  • Fase de incremento: inicia y prepara la flota mínima antes de la demanda, luego realiza una ampliación horizontal cuando se superan los umbrales de capacidad.
  • Pico: mantiene más capacidad en línea para minimizar la latencia y las colas; la ampliación horizontal continúa si se superan los umbrales.
  • Fase de reducción: pone los hosts seleccionados en modo de purga, consolida las sesiones y, después de un período de gracia, apaga los hosts inactivos.
  • Fuera del pico: mantiene una pequeña base para el acceso fuera del horario laboral; los hosts inactivos restantes se desasignan para minimizar el gasto.

• Umbrales de capacidad, disponibilidad mínima de hosts y comportamiento del autoescalado

  • El umbral de capacidad (%) se mide contra la capacidad total de sesiones de los hosts en línea. Cuando la utilización promedio excede el umbral, el autoescalado inicia VMs adicionales. La utilización depende del máximo de sesiones por host y del número actual de sesiones. Ajústelo por carga de trabajo; comience con 60–70% para el modo primero en profundidad, 70–80% para el modo primero en amplitud.
  • La disponibilidad mínima de hosts se puede definir como un número o porcentaje de hosts a mantener en ejecución en cada fase de la programación. Mantenga siempre al menos un “repuesto” para absorber picos repentinos.
  • Seguridad en la reducción horizontal: el autoescalado utiliza el modo de purga y verificaciones de “sin sesión activa” para evitar desconectar a los usuarios. Solo se detienen/desasignan los hosts inactivos.

• Gestión de energía y desasignación consciente de los costos

  • Detener (desasignar) libera los cargos de computación; los discos del SO y de datos continúan incurriendo en cargos de almacenamiento. El autoescalado desasigna los hosts inactivos durante la fase de reducción y fuera del pico.
  • Iniciar VM al conectar puede complementar la postura fuera del pico al arrancar VMs desasignadas cuando un usuario intenta conectarse. Asegúrese de que la identidad administrada o la entidad de servicio del grupo de hosts tenga permisos de Inicio de VM en el grupo de recursos del host de sesión.
  • Evite el apagado desde el sistema operativo invitado sin desasignación; deja la VM asignada y facturable.

Estado operativo, mantenimiento y estado: Modo de purga, notificaciones y registro

• Modo de purga y ventanas de mantenimiento

  • El modo de purga (AllowNewSession=false) impide nuevos inicios de sesión mientras permite que las sesiones existentes finalicen. Úselo para aplicar parches, actualizar agentes, reemplazar imágenes o para la reducción horizontal.
  • Enfoque de mantenimiento: ponga el/los host(s) en modo de purga, espere a que estén inactivos, cierre sesión de forma controlada a las sesiones persistentes después de una notificación, luego aplique las actualizaciones y reinicie. Valide el estado/señal de latido y vuelva a habilitar nuevas sesiones.

• Estrategia de notificación al usuario

  • Notificaciones del plan de escalado: configure el mensaje de cierre de sesión y el período de gracia durante la fase de reducción. Use un lenguaje claro y con plazos definidos.
  • Notificaciones suplementarias: use Azure Automation (Send-AzVMRunCommand, notificaciones emergentes a través de PowerShell) o Endpoint Manager para mostrar mensajes en la sesión antes del mantenimiento.

• Estado del host de sesión, señal de latido y estado del agente

  • Estados típicos: Available, Unavailable (NoHeartbeat), NeedsAssistance, Unhealthy, Shutdown, NotJoinedToDomain, Upgrading.
  • Requisitos previos de la señal de latido/agente: salida por el puerto 443 a los puntos de conexión del servicio AVD (use la etiqueta de servicio AzureVirtualDesktop), resolución DNS estable, sincronización de tiempo y unión a dominio exitosa si corresponde.
  • Servicios del agente: Remote Desktop Agent Loader y Remote Desktop Agent deben estar en ejecución. El agente de AVD y la pila en paralelo (side-by-side stack) se actualizan automáticamente si se permite el acceso de salida.

• Registro y solución de problemas

  • Para unir VMs existentes a un grupo de hosts, cree un token de registro (válido por un tiempo limitado) e instale/registre el agente de AVD con ese token.
  • Pasos comunes para el aislamiento de fallas:
    • Verifique que el host aparezca como Registrado y Disponible en el grupo de hosts; si no, vuelva a registrarlo con un nuevo token.
    • Inspeccione el Visor de eventos: los registros de Microsoft-RDInfra-RDAgent, Microsoft-RDInfra-RDAgentBootLoader y RDS/TerminalServices en busca de errores de conectividad o autenticación.
    • Valide el DNS: la resolución de dominio y la resolución de puntos de conexión de servicio deben tener éxito; si usa Azure AD DS, asegúrese de que el DNS de la VNet apunte a los controladores de dominio administrados.
    • Confirme que el Firewall de Windows o las reglas de seguridad de red permitan la salida por el puerto 443 y que ninguna intercepción de TLS rompa la confianza del servicio.

• Ejemplos de automatización útiles

# Put a session host in drain mode (no new sessions)
Update-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-finance `
  -Name host1.contoso.com -AllowNewSession:$false

# Gracefully logoff idle users after notice (example)
Invoke-AzVMRunCommand -ResourceGroupName rg-avd -Name host1 `
  -CommandId RunPowerShellScript -ScriptPath .\Notify-And-Logoff.ps1

Dimensionamiento, utilización y cargas de trabajo con GPU

• Selección del tamaño de la VM y dimensionamiento basado en la carga de trabajo

  • Comience con la caracterización de la carga de trabajo: ofimática/productividad, trabajador del conocimiento con optimización para Microsoft 365 Apps y Teams, desarrollador/ingeniería o gráficos/3D.
  • CPU: mantenga el uso sostenido de CPU por debajo del 70–75 % con picos cortos por debajo del 85 %. Supervise Processor(_Total)% Processor Time y System\Processor Queue Length.
  • Memoria: apunte a menos del 80 % de memoria comprometida (committed) con Memory\Available MBytes por encima de 500 MB por host; vigile la paginación. La caché de FSLogix puede aumentar el working set; dimensione en consecuencia.
  • Almacenamiento: la experiencia del usuario depende de los IOPS y la latencia del perfil de FSLogix. Use Premium SSD v2, Ultra Disk para escenarios intensivos en temporales/caché, y Azure Files Premium o Azure NetApp Files para perfiles con altos IOPS. Para entornos muy grandes o perfiles de latencia ultrabaja, Azure NetApp Files proporciona la mejor consistencia.
  • Líneas base iniciales (multisesión):
    • Productividad ligera: 4–8 vCPU, 16–32 GB de RAM; breadth-first para mejorar la capacidad de respuesta.
    • Trabajador del conocimiento medio: 8–16 vCPU, 32–64 GB de RAM; depth-first para optimizar costos.
    • Desarrollo/compilación/datos pesados: 16–32 vCPU, 64–128 GB de RAM; considere usar grupos dedicados.

• Hosts de sesión con GPU

  • Para CAD/GIS/3D/edición de video y visualizaciones complejas, use NVads A10 v5 para perfiles de vGPU granulares y una excelente relación precio/rendimiento; considere las familias NV v4/v5 cuando sea apropiado.
  • Implemente la NVIDIA GPU Driver Extension para Windows en las VM de la serie N. Valide la codificación por hardware: habilite AVC/H.264 y configure la política “Usar codificación por hardware para Escritorio remoto” (Use hardware encoding for Remote Desktop) cuando sea beneficioso.
  • Supervise la GPU con contadores de rendimiento (Performance Counters) (utilización del motor de GPU, memoria de GPU) y métricas de Azure Monitor. Asegúrese de que haya suficiente margen de CPU (headroom); las aplicaciones con uso intensivo de gráficos siguen siendo sensibles a la inanición de CPU (CPU starvation).

• Telemetría y ajuste iterativo

  • Habilite Azure Monitor para obtener información de AVD (insights) y Log Analytics. Realice un seguimiento de la CPU, la memoria, la latencia del perfil de FSLogix, la duración del inicio de sesión, las desconexiones y los tiempos de intermediación (brokering).
  • Ajuste el MaxSessionLimit del grupo de hosts y el modo de equilibrio de carga según la contención observada, y luego reajuste los umbrales de autoescalado para que coincidan.

Optimización de costos: Encendido, autoescalado, reservas, Savings Plans y AHB

• Alinear el escalado con el horario comercial

  • Usar el modo en profundidad más umbrales de capacidad conservadores para consolidar sesiones y acelerar la reducción de escala (scale-in). Combinar con la desasignación fuera de horas pico y Start VM on connect para accesos tardíos o poco frecuentes.
  • Establecer un recuento mínimo de hosts pequeño pero no nulo para evitar tormentas de arranque en frío.

• Reservas y Savings Plans

  • Reservas: las reservas de VM de 1 o 3 años bloquean SKU específicos en regiones específicas para obtener los mayores descuentos; ideal para la capacidad base que se ejecuta la mayor parte del tiempo (p. ej., la flota de horas pico diurnas).
  • Compute Savings Plans: ofrecen descuentos flexibles entre familias de VM y regiones; útiles cuando se mezclan tamaños o para entornos dinámicos donde la previsibilidad exacta de los SKU es menor.
  • Reservas de almacenamiento: la capacidad reservada de Azure Files puede reducir los costos de almacenamiento de FSLogix a escala.

• Azure Hybrid Benefit (AHB) y licenciamiento

  • Aplicar AHB a las cargas de trabajo de Windows Server y clientes de Windows elegibles para reducir los cargos de licenciamiento del SO de computación. Asegurar la elegibilidad y el cumplimiento de las licencias.
  • Para implementaciones de Microsoft 365, confirmar que el licenciamiento cubra Windows Enterprise multi-session y Microsoft 365 Apps cuando corresponda.

• Scripts operativos y runbooks

  • Usar Azure Automation o GitHub Actions para:
    • Secuencias de drenaje/habilitación de la flota antes y después del mantenimiento.
    • Scripts de precalentamiento antes del escalado los lunes o después de días festivos.
    • Corrección de estado (reiniciar servicios del agente, volver a registrar el host si se pierde el latido).
  • La orquestación impulsada por etiquetas simplifica las operaciones selectivas (p. ej., etiquetar Environment=Pilot para excluirlo de la reducción de escala).

# Start or stop idle hosts by tag (supplemental to native autoscale)
$hosts = Get-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-ops
foreach ($h in $hosts) {
  if ($h.Session -eq 0 -and $h.Tags["KeepOnline"] -ne "true") {
    Stop-AzVM -ResourceGroupName rg-avd -Name ($h.Name.Split("/")[1]) -Force -StayProvisioned:$false
  }
}

Escenario de problema práctico

IKEA enfrenta picos durante los días laborables por parte de planificadores 3D, ingenieros de producto y personal del centro de llamadas que utilizan aplicaciones remotas. Las tardes y los fines de semana tienen una baja demanda. Las sesiones respaldadas por GPU deben mantenerse responsivas mientras se minimiza el costo general de computación.

1. Segmentar los grupos de hosts por carga de trabajo

   • Crear tres grupos de hosts compartidos: GPU-CAD (NVads A10 v5), KnowledgeWorker (serie D/E) y ContactCenter (serie D).
   • Por qué: Alinea el tamaño y la densidad de las VM con perfiles de rendimiento distintos; permite ventanas de mantenimiento y autoescalado independientes.

2. Asociar un único plan de escalado con programaciones según el horario comercial

   • Definir una fase de incremento a las 07:00, pico de 09:00 a 17:00, fase de reducción de 17:00 a 19:00, y fuera de horas pico el resto del tiempo; establecer la zona horaria a la región de cada grupo.
   • Por qué: Garantiza que la capacidad esté lista antes de que lleguen los usuarios, consolida y apaga de forma controlada después del horario laboral, y respeta los horarios regionales.

3. Ajustar los umbrales de capacidad y la disponibilidad mínima de hosts por grupo

   • GPU-CAD: en amplitud, umbral de capacidad del 70 %, mínimo de hosts en línea del 30 %; KnowledgeWorker: en profundidad, umbral del 65 %, mínimo del 10 %; ContactCenter: en profundidad, umbral del 70 %, mínimo del 15 %.
   • Por qué: Las cargas de trabajo de GPU prefieren una distribución más amplia para mayor capacidad de respuesta; las cargas de trabajo de oficina se benefician de la consolidación para reducir costos; el centro de llamadas requiere una reserva constante para los cambios de turno.

4. Habilitar Start VM on connect para KnowledgeWorker y ContactCenter

   • Otorgar a la identidad administrada del grupo de hosts permisos de inicio de VM; mantener bajo el mínimo fuera de horas pico.
   • Por qué: Reduce los cargos por tiempo de ejecución inactivo mientras se preserva el acceso justo a tiempo para inicios de sesión inesperados fuera del horario laboral.

5. Implementar un flujo de trabajo de mantenimiento y notificación

   • Antes del Patch Tuesday: poner el 20 % de cada grupo en modo de drenaje mediante una etiqueta; notificar a los usuarios 30 minutos antes; después de que estén inactivos, aplicar parches, reiniciar, validar el agente/latido y luego rotar al siguiente lote.
   • Por qué: El drenaje progresivo evita cierres de sesión masivos, preserva la continuidad del servicio y reduce los picos en el servicio de asistencia.

6. Monitorear e iterar con Azure Monitor for AVD

   • Hacer seguimiento del uso de CPU, memoria, GPU, duración del inicio de sesión, latencia de FSLogix; ajustar mensualmente MaxSessionLimit y los umbrales de autoescalado.
   • Por qué: El ajuste basado en datos mantiene el SLA y controla el gasto a medida que evolucionan los patrones de uso.

7. Aplicar palancas de costo

   • Reservar capacidad de 3 años para el pico base de los días laborables en KnowledgeWorker y ContactCenter; usar un Compute Savings Plan para la demanda variable de GPU; aplicar Azure Hybrid Benefit donde sea elegible.
   • Por qué: Las reservas aseguran los mayores ahorros para la carga base predecible; los Savings Plans se flexionan con los picos de GPU menos predecibles; AHB reduce los costos de licenciamiento del SO.

8. Reforzar el registro y el estado

   • Mantener un runbook permanente para volver a registrar cualquier host que muestre NoHeartbeat y validar DNS/hora. Mantener etiquetas de exclusión para hosts de diagnóstico.
   • Por qué: La corrección rápida y automatizada limita el impacto en el usuario y preserva la capacidad durante problemas inesperados del agente.

Con este diseño, IKEA cumple los objetivos de rendimiento diurno —incluida la capacidad de respuesta de la GPU— mientras desasigna agresivamente la capacidad fuera de horario y automatiza el mantenimiento, lo que resulta en una experiencia de usuario estable y una reducción de costos medible.

← FSLogix · Todos los dominios · Aplicaciones y experiencia del usuario final →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →