Planes de escalabilidad automática y escenarios de ejemplo en Azure Virtual Desktop
La escalabilidad automática permite escalar o reducir verticalmente las máquinas virtuales (VM) del host de sesión en un grupo de hosts de acuerdo con la programación para optimizar los costos de implementación.
Nota
- Azure Virtual Desktop (clásico) no admite la escalabilidad automática.
- No puede usar la escalabilidad automática y los hosts de sesión de escalado mediante Azure Automation en el mismo grupo de hosts. Debe usar la una o los otros.
- La escalabilidad automática está disponible en Azure y Azure Government en las mismas regiones en las que puede crear grupos de hosts.
- La compatibilidad con el escalado automático de Azure Stack HCI con Azure Virtual Desktop se encuentra actualmente en versión preliminar. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
Para obtener mejores resultados, se recomienda usar la escalabilidad automática con máquinas virtuales implementadas con plantillas de Azure Resource Manager (ARM) de Azure Virtual Desktop o herramientas de Microsoft.
Funcionamiento de un plan de escalado
Antes de crear el plan, tenga en cuenta lo siguiente:
Puede asignar un plan de escalado a uno o varios grupos de hosts del mismo tipo de grupo de hosts. Las programaciones del plan de escalado también se aplicarán a todos los grupos de hosts asignados.
Solo puede asociar un plan de escalado por grupo de hosts. Si asigna un único plan de escalado a varios grupos de hosts, esos grupos de hosts no se pueden asignar a otro plan de escalado.
Hibernate está disponible para grupos de hosts personales. Para obtener más información, vea Hibernación en máquinas virtuales.
Un plan de escalado solo puede funcionar en su zona horaria configurada.
Un plan de escalado puede tener una o varias programaciones. Por ejemplo, diferentes programaciones durante los días laborables frente al fin de semana.
Asegúrese de comprender los patrones de uso antes de definir la programación. Deberá programar para las siguientes horas del día:
- Ascenso: el inicio del día, cuando aumenta el uso.
- Horas punta: la hora del día en la que se espera que el uso esté en su nivel más alto.
- Descenso: cuando baja el uso. Normalmente, es aquí cuando se apagan las máquinas virtuales para ahorrar costos.
- Fuera de horas punta: la hora del día en la que se espera que el uso esté en su nivel más bajo.
El plan de escalado se hará efectivo en cuanto lo habilite.
Además, tenga en cuenta estas limitaciones:
No use la escalabilidad automática en combinación con otras herramientas de escalado de Microsoft o de terceros. Asegúrese de deshabilitarlas para los grupos de hosts a los que aplica los planes de escalado.
Para los grupos de hosts agrupados, la escalabilidad automática sobrescribe el modo de purga, por lo que debe asegurarse de usar etiquetas de exclusión al actualizar las máquinas virtuales de los grupos de hosts.
Para los grupos de hosts agrupados, la escalabilidad automática omite los algoritmos de equilibrio de carga existentes en la configuración del grupo de hosts y, en su lugar, aplica el equilibrio de carga en función de la configuración de la programación.
Escenarios de ejemplo para el escalado automático de grupos de hosts agrupados
En esta sección, hay cuatro escenarios que muestran cómo funcionan diferentes partes de la escalabilidad automática para grupos de hosts agrupados. En cada ejemplo, hay tablas que muestran la configuración del grupo de hosts y demostraciones visuales animadas.
Nota:
Para más información sobre lo que significan los términos de los parámetros, consulte nuestro glosario de escalabilidad automática.
Escenario 1: ¿Cuándo activa las máquinas virtuales la escalabilidad automática?
En este escenario, demostraremos que la escalabilidad automática puede activar las máquinas virtuales (VM) del host de sesión en cualquier fase de la programación del plan de escalado cuando la capacidad del grupo de hosts utilizado supera el umbral de capacidad.
Por ejemplo, echemos un vistazo a la siguiente configuración del grupo de hosts, tal y como se describe en esta tabla:
Parámetro | Value |
---|---|
Fase | Ramp-up (Ascenso) |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 30 % |
Porcentaje mínimo de hosts | 30 % |
Hosts de sesión disponibles | 2 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 10 |
Sesiones de usuario | 0 |
Capacidad usada del grupo de hosts | 0 % |
Al principio de esta fase, la escalabilidad automática ha activado dos hosts de sesión para que coincidan con el porcentaje mínimo de hosts. Aunque el 30 % de seis no es un número entero, la escalabilidad automática lo redondea al número entero más cercano. Tener dos hosts de sesión disponibles y un límite máximo de sesiones de cinco sesiones por host significa que este grupo de hosts tiene una capacidad de grupo de hosts disponible de 10. Puesto que actualmente no hay ninguna sesión de usuario, la capacidad utilizada del grupo host es del 0 %.
Cuando comience el día, supongamos que tres usuarios inician sesión e inician sesiones de usuario. Sus sesiones de usuario se distribuyen uniformemente entre los dos hosts de sesión disponibles, ya que el algoritmo de equilibrio de carga es amplitud primero. La capacidad disponible del grupo de hosts sigue siendo 10, pero con las tres nuevas sesiones de usuario, la capacidad utilizada del grupo host ahora es del 30 %. Sin embargo, la escalabilidad automática no activará máquinas virtuales hasta que la capacidad utilizada del grupo hosts sea mayor que el umbral de capacidad. En este ejemplo, el umbral de capacidad es del 30 %, por lo que la escalabilidad automática aún no activará ninguna máquina virtual.
En este momento, los parámetros del grupo de hosts son parecidos a los siguientes:
Parámetro | Value |
---|---|
Fase | Ramp-up (Ascenso) |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 30 % |
Porcentaje mínimo de hosts | 30 % |
Hosts de sesión disponibles | 2 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 10 |
Sesiones de usuario | 3 |
Capacidad usada del grupo de hosts | 30 % |
Cuando otro usuario inicia sesión e inicia una sesión, habrá cuatro sesiones de usuario totales distribuidas entre dos hosts de sesión. La capacidad utilizada del grupo de hosts ahora es del 40 %, que es mayor que el umbral de capacidad. Como resultado, la escalabilidad automática activará otro host de sesión para que la capacidad utilizada del grupo de hosts sea menor o igual que el umbral de capacidad (30 %).
En resumen, estos son los parámetros cuando la capacidad utilizada del grupo de hosts supera el umbral de capacidad:
Parámetro | Value |
---|---|
Fase | Ramp-up (Ascenso) |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 30 % |
Porcentaje mínimo de hosts | 30 % |
Hosts de sesión disponibles | 2 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 10 |
Sesiones de usuario | 4 |
Capacidad usada del grupo de hosts | 40% |
Estos son los parámetros después de que la escalabilidad automática active otro host de sesión:
Parámetro | Value |
---|---|
Fase | Ramp-up (Ascenso) |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 30 % |
Porcentaje mínimo de hosts | 30 % |
Hosts de sesión disponibles | 3 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 15 |
Sesiones de usuario | 4 |
Capacidad usada del grupo de hosts | 27 % |
Activar otro host de sesión significa que ahora hay tres hosts de sesión disponibles en el grupo de hosts. Aunque el límite máximo de sesiones sigue siendo cinco, la capacidad disponible del grupo de hosts ha llegado a 15. Dado que ha aumentado la capacidad disponible del grupo de hosts, la capacidad utilizada del grupo de hosts ha bajado al 27 %, que está por debajo del umbral de capacidad del 30 %.
Cuando otro usuario inicia sesión, habrá cinco sesiones de usuario repartidas entre tres hosts de sesión disponibles. La capacidad utilizada del grupo de hosts ahora es del 33 %, que supera el umbral de capacidad del 30 %. Si se supera el umbral de capacidad, se activa la escalabilidad automática para activar otro host de sesión.
Dado que nuestro ejemplo está en fase de ascenso, es probable que nuevos usuarios sigan iniciando sesión. A medida que llegan más usuarios, el patrón se vuelve más claro:
Sesiones de usuario totales | Número de hosts de sesión disponibles | Capacidad disponible del grupo de hosts | Umbral de capacidad | Capacidad usada del grupo de hosts | ¿La escalabilidad automática activa otro host de sesión? |
---|---|---|---|---|---|
5 | 3 | 15 | 30 % | 33 % | Sí |
5 | 4 | 20 | 30 % | 25 % | No |
6 | 4 | 20 | 30 % | 30 % | No |
7 | 4 | 20 | 30 % | 35 % | Sí |
7 | 5 | 25 | 30 % | 28 % | No |
Como se muestra en esta tabla, la escalabilidad automática solo activa nuevos hosts de sesión cuando la capacidad utilizada del grupo de hosts supera el umbral de capacidad. Si la capacidad utilizada del grupo de hosts está en el umbral de capacidad o por debajo de él, la escalabilidad automática no activará nuevos hosts de sesión.
La animación siguiente es un resumen visual de lo que acabamos de ver en el escenario 1.
Escenario 2: ¿Cuándo desactiva las máquinas virtuales la escalabilidad automática?
En este escenario, mostraremos que la escalabilidad automática desactiva los hosts de sesión cuando se cumplen todas las condiciones siguientes:
- La capacidad utilizada del grupo de hosts está por debajo del umbral de capacidad.
- La escalabilidad automática puede desactivar los hosts de sesión sin superar el umbral de capacidad.
- La escalabilidad automática solo desactiva los hosts de sesión sin sesiones de usuario (a menos que el plan de escalado esté en fase de descenso y haya habilitado la configuración para forzar el cierre de sesión).
- La escalabilidad automática agrupada no desactivará los hosts de sesión en la fase de rampa para evitar una experiencia de usuario incorrecta.
En este escenario, el grupo de hosts comienza con el siguiente aspecto:
Parámetro | Value |
---|---|
Fase | Peak |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 30 % |
Porcentaje mínimo de hosts | 30 % |
Hosts de sesión disponibles | 5 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 25 |
Sesiones de usuario | 7 |
Capacidad usada del grupo de hosts | 28 % |
Dado que estamos en la fase de hora punta, podemos esperar que el número de usuarios permanezca relativamente estable. Sin embargo, para mantener estable la cantidad de recursos utilizados a la vez que se sigue siendo eficaz, la escalabilidad automática activará y desactivará los hosts de sesión según sea necesario.
Por lo tanto, supongamos que hay siete usuarios que han iniciado sesión durante las horas punta. Si el número total de sesiones de usuario es siete, esto hará que la capacidad utilizada del grupo de hosts sea del 28 %. Dado que la escalabilidad automática no puede desactivar un host de sesión sin que la capacidad utilizada del grupo de hosts supere el umbral de capacidad, la escalabilidad automática aún no desactivará ningún host de sesión.
Si dos de los siete usuarios cierran sesión durante su pausa para la comida, eso deja cinco sesiones de usuario en cinco hosts de sesión. Puesto que el límite máximo de sesiones sigue siendo cinco, la capacidad disponible del grupo de hosts es 25. Tener solo cinco usuarios significa que la capacidad utilizada del grupo de hosts ahora es del 20 %. Ahora, la escalabilidad automática debe comprobar si puede desactivar un host de sesión sin hacer que la capacidad utilizada del grupo de hosts sea superior al umbral de capacidad.
Si la escalabilidad automática ha desactivado un host de sesión, la capacidad disponible del grupo de hosts sería 20. Con cinco usuarios, la capacidad utilizada del grupo de hosts sería entonces del 25 %. Dado que el 25 % es menor que el umbral de capacidad del 30 %, la escalabilidad automática seleccionará un host de sesión sin sesiones de usuario, lo pondrá en modo de purga y lo desactivará.
Una vez que la escalabilidad automática desactive uno de los hosts de sesión sin sesiones de usuario, quedan cuatro hosts de sesión disponibles. El límite máximo de sesiones del grupo de hosts sigue siendo cinco, por lo que la capacidad disponible del grupo de hosts es 20. Dado que hay cinco sesiones de usuario, la capacidad utilizada del grupo de hosts es del 25 %, que sigue estando por debajo del umbral de capacidad.
Sin embargo, si otro usuario cierra sesión y sale a comer, ahora hay cuatro sesiones de usuario repartidas entre los cuatro hosts de sesión del grupo de hosts. Puesto que el límite máximo de sesiones sigue siendo cinco, la capacidad disponible del grupo de hosts es 20 y la capacidad utilizada del grupo de hosts es del 20 %. Al desactivar otro host de sesión, quedarían tres hosts de sesión y una capacidad disponible del grupo de hosts de 15, lo que haría que la capacidad utilizada del grupo de hosts suba hasta aproximadamente el 27 %. Aunque el 27 % está por debajo del umbral de capacidad, no hay ningún host de sesión con ninguna sesión de usuario. La escalabilidad automática seleccionará el host de sesión con el menor número de sesiones de usuario, lo pondrá en modo de purga y esperará a que se cierren todas las sesiones de usuario antes de desactivarlo. Si en algún momento la capacidad utilizada del grupo de hosts llega a un punto en el que la escalabilidad automática ya no puede desactivar el host de sesión, sacará el host de sesión del modo de purga.
La animación siguiente es un resumen visual de lo que acabamos de ver en el escenario 2.
Escenario 3: ¿Cuándo obliga la escalabilidad automática a los usuarios a cerrar sesión?
La escalabilidad automática solo obliga a los usuarios a cerrar sesión si ha habilitado la configuración forzar cierre de sesión durante la fase de descenso de la programación del plan de escalado. La configuración para forzar el cierre de sesión no cerrará la sesión de los usuarios durante ninguna otra fase de la programación del plan de escalado.
Por ejemplo, echemos un vistazo a un grupo de hosts con los parámetros siguientes:
Parámetro | Value |
---|---|
Fase | Descenso |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la profundidad |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 4 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 20 |
Sesiones de usuario | 4 |
Capacidad usada del grupo de hosts | 20% |
Durante la fase de descenso, el administrador del grupo de hosts ha establecido el umbral de capacidad en el 75 % y el porcentaje mínimo de hosts en el 10 %. Tener un umbral de capacidad alto y un porcentaje mínimo de hosts bajo en esta fase reduce la necesidad de activar nuevos hosts de sesión al final del día laborable.
En este escenario, supongamos que actualmente hay cuatro usuarios en los cuatro hosts de sesión disponibles en este grupo de hosts. Puesto que la capacidad disponible del grupo de hosts es 20, significa que la capacidad utilizada del grupo de hosts es del 20 %. Según esta información, la escalabilidad automática detecta que puede desactivar dos hosts de sesión sin superar el umbral de capacidad del 75 %. Sin embargo, dado que hay sesiones de usuario en todos los hosts de sesión del grupo de hosts, para desactivar dos hosts de sesión, la escalabilidad automática deberá forzar a los usuarios a cerrar sesión.
Cuando haya habilitado la configuración para forzar el cierre de sesión, la escalabilidad automática seleccionará los hosts de sesión con el menor número de sesiones de usuario y, a continuación, pondrá los hosts de sesión en modo de purga. A continuación, la escalabilidad automática envía a los usuarios de los hosts de sesión seleccionados notificaciones de que se van a cerrar de forma forzada sus sesiones después de un tiempo determinado. Una vez transcurrido ese tiempo, si los usuarios aún no han finalizado sus sesiones, la escalabilidad automática finalizará forzadamente sus sesiones. En este escenario, dado que hay igual número de sesiones de usuario en cada uno de los hosts de sesión del grupo de hosts, la escalabilidad automática elegirá dos hosts de sesión de forma aleatoria para cerrar la sesión de forma forzada de todos sus usuarios y, a continuación, desactivará los hosts de sesión.
Una vez que la escalabilidad automática desactive los dos hosts de sesión, la capacidad disponible del grupo de hosts ahora será 10. Ahora que solo quedan dos sesiones de usuario, la capacidad utilizada del grupo de hosts es del 20 %, como se muestra en la tabla siguiente.
Parámetro | Value |
---|---|
Fase | Descenso |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la profundidad |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 2 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 10 |
Sesiones de usuario | 2 |
Capacidad usada del grupo de hosts | 20% |
Ahora, supongamos que los dos usuarios que se vieron obligados a cerrar sesión quieren seguir trabajando e iniciar sesión de nuevo. Puesto que la capacidad disponible del grupo de hosts sigue siendo 10, la capacidad utilizada del grupo de hosts ahora es del 40 %, que está por debajo del umbral de capacidad del 75 %. Sin embargo, la escalabilidad automática no puede desactivar más hosts de sesión, ya que eso dejaría solo un host de sesión disponible y una capacidad disponible del grupo de hosts de cinco. Con cuatro usuarios, esto haría que la capacidad utilizada del grupo de hosts fuera del 80 %, que está por encima del umbral de capacidad.
Por lo tanto, ahora los parámetros son parecidos a los siguientes:
Parámetro | Value |
---|---|
Fase | Descenso |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la profundidad |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 2 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 10 |
Sesiones de usuario | 4 |
Capacidad usada del grupo de hosts | 40% |
En este momento, si otro usuario cierra sesión, solo quedan tres sesiones de usuario distribuidas entre los dos hosts de sesión disponibles. En otras palabras, el grupo de hosts ahora tiene el siguiente aspecto:
Parámetro | Value |
---|---|
Fase | Descenso |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la profundidad |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 2 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 10 |
Sesiones de usuario | 3 |
Capacidad usada del grupo de hosts | 30 % |
Dado que el límite máximo de sesiones sigue siendo cinco y la capacidad disponible del grupo de hosts es 10, la capacidad utilizada del grupo de hosts ahora es del 30 %. La escalabilidad automática ahora puede desactivar un host de sesión sin superar el umbral de capacidad. La escalabilidad automática desactiva un host de sesión eligiendo el host de sesión con el menor número de sesiones de usuario. A continuación, la escalabilidad automática coloca el host de sesión en modo de purga, envía a los usuarios una notificación que indica que el host de sesión se va a desactivar y, después de un período de tiempo establecido, fuerza el cierre de sesión de los usuarios restantes y lo desactiva. Después de hacerlo, ahora hay un host de sesión disponible restante en el grupo de hosts con un límite máximo de cinco sesiones, lo que hace que la capacidad disponible del grupo de hosts sea cinco.
Dado que la escalabilidad automática ha forzado a un usuario a cerrar sesión al desactivar el host de sesión elegido, ahora solo quedan dos sesiones de usuario, lo que hace que la capacidad utilizada del grupo de hosts sea del 40 %.
Como resumen, este es el aspecto del grupo de hosts ahora:
Parámetro | Value |
---|---|
Fase | Descenso |
Total de hosts de sesión | 6 |
Límite máximo de sesiones | 5 |
Algoritmo de equilibrio de carga | Con prioridad a la profundidad |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Capacidad disponible del grupo de hosts | 5 |
Sesiones de usuario | 2 |
Hosts de sesión disponibles | 1 |
Capacidad usada del grupo de hosts | 40% |
Después de eso, imaginemos que el usuario que se ha visto obligado a cerrar sesión vuelve a iniciar sesión, lo que hace que el grupo de hosts tenga el siguiente aspecto:
Parámetro | Value |
---|---|
Fase | Descenso |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la profundidad |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 1 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 5 |
Sesiones de usuario | 3 |
Capacidad usada del grupo de hosts | 60% |
Ahora hay tres sesiones de usuario en el grupo de hosts. Sin embargo, la capacidad del grupo de hosts sigue siendo cinco, lo que significa que la capacidad utilizada del grupo de hosts es del 60 % y se encuentra por debajo del umbral de capacidad. Dado que desactivar el host de sesión restante haría que la capacidad disponible del grupo de hosts fuera cero, que está por debajo del porcentaje mínimo del 10 % de los hosts, la escalabilidad automática garantizará que siempre haya al menos un host de sesión disponible durante la fase de descenso.
La animación siguiente es un resumen visual de lo que acabamos de ver en el escenario 3.
Escenario 4: ¿Cómo funcionan las etiquetas de exclusión?
Cuando una máquina virtual tenga un nombre de etiqueta que coincida con la etiqueta de exclusión del plan de escalado, la escalabilidad automática no la activará, desactivará ni cambiará su configuración de modo de purga. Las etiquetas de exclusión son aplicables en todas las fases de la programación del plan de escalado.
Este es el grupo de hosts de ejemplo con el que empezamos:
Parámetro | Value |
---|---|
Fase | Poca actividad |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 1 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 5 |
Sesiones de usuario | 3 |
Capacidad usada del grupo de hosts | 60% |
En este escenario de ejemplo, el administrador del grupo de hosts aplica la etiqueta de exclusión del plan de escalado a cinco de los seis hosts de sesión. Cuando un nuevo usuario inicia sesión, se eleva el número total de sesiones de usuario hasta cuatro. Solo hay un host de sesión disponible y el límite máximo de sesiones del grupo de hosts sigue siendo cinco, por lo que la capacidad disponible del grupo de hosts es cinco. La capacidad utilizada del grupo de hosts es del 80 %. Sin embargo, aunque la capacidad utilizada del grupo de hosts sea mayor que el umbral de capacidad, la escalabilidad automática no activará ningún otro host de sesión porque todos los hosts de sesión, excepto el que se está ejecutando actualmente, se han etiquetado con la etiqueta de exclusión.
Por lo tanto, ahora el grupo de hosts tiene el siguiente aspecto:
Parámetro | Value |
---|---|
Fase | Poca actividad |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 1 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 5 |
Sesiones de usuario | 4 |
Capacidad usada del grupo de hosts | 80 % |
A continuación, supongamos que los cuatro usuarios han cerrado sesión, con lo que no queda ninguna sesión de usuario en el host de sesión disponible. Dado que no hay sesiones de usuario en el grupo de hosts, la capacidad utilizada del grupo de hosts es 0. La escalabilidad automática mantendrá este único host de sesión a pesar de que no tiene usuarios, ya que durante la fase de menor actividad, la configuración del porcentaje mínimo de hosts de la escalabilidad automática determina que debe mantener al menos un host de sesión disponible durante esta fase.
En resumen, el grupo de hosts ahora tiene el siguiente aspecto:
Parámetro | Value |
---|---|
Fase | Poca actividad |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 10 % |
Hosts de sesión disponibles | 1 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 5 |
Sesiones de usuario | 0 |
Capacidad usada del grupo de hosts | 0 % |
Si el administrador aplica el nombre de la etiqueta de exclusión a la última máquina virtual del host de sesión sin etiquetar y la desactiva, significa que incluso si otros usuarios intentan iniciar sesión, la escalabilidad automática no podrá activar una máquina virtual para dar cabida a su sesión de usuario. El usuario verá el error "No hay recursos disponibles".
Sin embargo, no poder volver a activar las máquinas virtuales significa que el grupo de hosts no podrá cumplir con su porcentaje mínimo de hosts. Para corregir los posibles problemas que esto pueda provocar, el administrador quita las etiquetas de exclusión de dos de las máquinas virtuales. La escalabilidad automática solo activa una de las máquinas virtuales, ya que solo necesita una máquina virtual para cumplir el requisito mínimo del 10 %.
Por último, el grupo de hosts tendrá el siguiente aspecto:
Parámetro | Value |
---|---|
Fase | Poca actividad |
Total de hosts de sesión | 6 |
Algoritmo de equilibrio de carga | Con prioridad a la amplitud |
Umbral de capacidad | 75 % |
Porcentaje mínimo de hosts | 19 % |
Hosts de sesión disponibles | 1 |
Límite máximo de sesiones | 5 |
Capacidad disponible del grupo de hosts | 5 |
Sesiones de usuario | 0 |
Capacidad usada del grupo de hosts | 0 % |
La animación siguiente es un resumen visual de lo que acabamos de ver en el escenario 4.
Pasos siguientes
- Para obtener información sobre cómo crear planes de escalado para la escalabilidad automática, consulte Creación del escalado para la escalabilidad automática para grupos de hosts de Azure Virtual Desktop.
- Para revisar los términos asociados a la escalabilidad automática, consulte el glosario de escalabilidad automática.
- Para obtener respuestas a las preguntas más frecuentes sobre la escalabilidad automática, consulte Preguntas frecuentes sobre escalabilidad automática (versión preliminar) de Azure Virtual Desktop.