Las implementaciones de pods, las implementaciones de configuraciones de puerta de enlace del pod y las operaciones estándar requieren tipos y tamaños específicos de máquinas virtuales para su capacidad de nube de Microsoft Azure. Su suscripción necesita la configuración y las cuotas adecuadas para admitir estas máquinas virtuales. Cuando se utiliza la opción para implementar la puerta de enlace externa del pod en una suscripción independiente, esa suscripción necesita la cuota y la configuración para admitir esa configuración de puerta de enlace externa.

Importante: El asistente de implementación de pods valida que el entorno de Microsoft Azure tenga suficiente cuota de núcleos para crear el pod y la configuración de puerta de enlace que especificó, si hubiese alguna. Si el asistente determina que no hay suficiente cuota dada la información de suscripción que especificó en el asistente, se mostrará un mensaje en pantalla y el asistente no continuará con el siguiente paso.

A partir de la versión de manifiesto del pod de la versión de septiembre de 2019, tanto para los pods recién implementados en esa versión como para los pods actualizados a esa versión, cada pod tiene un equilibrador de carga de Microsoft Azure y un servidor de Microsoft Azure Database for PostgreSQL. Cuando se actualiza un pod al manifiesto de septiembre de 2019 o versiones posteriores, el pod actualizado incluye un equilibrador de carga de Microsoft Azure y un servidor de Microsoft Azure Database for PostgreSQL. El servidor de Microsoft Azure Database for PostgreSQL se implementa con un servidor único.

Nota: Las máquinas virtuales con la GPU habilitada solo están disponibles en algunas regiones de Microsoft Azure. Para obtener más información, consulte los Productos de Microsoft Azure por región.

En las tablas que aparecen a continuación, la columna de especificación de máquina virtual proporciona:

  • Los nombres de serie utilizados en la documentación de Microsoft Azure
  • Los nombres de familia de vCPU utilizados en las cuotas que se muestran en el portal de Microsoft Azure
  • El nombre específico del tipo de máquina virtual de esa familia

Para ver las cuotas actuales de una suscripción en el portal de Microsoft Azure, desplácese a Todos los servicios > Suscripciones, haga clic en la suscripción y, a continuación, haga clic en Uso + cuotas. Para obtener más información sobre los tamaños de las máquinas virtuales de Microsoft Windows en Microsoft Azure, consulte este tema y sus subtemas en la documentación de Microsoft Azure: https://docs.microsoft.com/es-es/azure/virtual-machines/windows/sizes.

Máquinas virtuales de Jump Box

Las máquinas virtuales de Jump Box se crean temporalmente en las suscripciones de Microsoft Azure para los fines descritos en las tablas que aparecen a continuación.

Tabla 1. Requisitos de la máquina virtual de Jump Box del pod
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Jumpbox Familia F estándar de Linux:

Standard_F2 (2 núcleos, 4 GB de memoria)

Disco del SO: HDD estándar de 30 GiB

1 por pod Una máquina virtual creada en el entorno de Microsoft Azure y utilizada durante la creación del pod inicial, y durante las actualizaciones de software posteriores en el entorno. Una máquina virtual de Jump Box para cada pod que implemente. La máquina virtual de Jump Box se elimina automáticamente cuando se completa el proceso de actualización o creación del pod, y ya no se la necesita.
Nota: Se acaba de implementar una máquina virtual de Jump Box para crear un pod, para desarrollar los componentes verdes de una actualización cuando esté disponible la siguiente versión del software del pod, para organizar el proceso de actualización azul/verde en el pod y para el proceso de adición de una configuración de puerta de enlace a un pod existente.
Tabla 2. Cuando la puerta de enlace externa está en una VNet independiente: requisitos de la máquina virtual de Jump Box
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Jumpbox Familia F estándar de Linux:

Standard_F2 (2 núcleos, 4 GB de memoria)

Disco del SO: HDD estándar de 30 GiB

1 por pod Cuando se implementa de forma opcional la puerta de enlace externa en su propia VNet o suscripción, se necesita una máquina virtual de Jump Box independiente de la máquina virtual de Jump Box que utilizan los recursos principales del pod. Esta máquina virtual de Jump Box se crea en el entorno de Microsoft Azure en un grupo de recursos independiente de la máquina virtual de Jump Box del pod, y se utiliza durante la implementación inicial de la configuración de la puerta de enlace externa y durante las actualizaciones de software posteriores en esa puerta de enlace externa. Una máquina virtual de Jump Box para cada puerta de enlace externa en su propia VNet o suscripción que implemente. La máquina virtual de Jump Box se elimina automáticamente cuando se completa el proceso de implementación o actualización de la puerta de enlace externa, y ya no se la necesita.
Nota: Se implementa una nueva máquina virtual de Jump Box para crear una de estas puertas de enlace externas en su propia VNet o suscripción (durante la creación del pod o al usar el flujo de trabajo Editar pod para agregar la puerta de enlace externa a un pod existente), para crear los componentes verdes de una actualización para esa puerta de enlace externa cuando la siguiente versión del software de la puerta de enlace el pod esté disponible para usted y para instrumentar el proceso de actualización azul/verde en esa puerta de enlace externa.

Máquinas virtuales del administrador de pods

Por lo general, estas máquinas virtuales se consideran el núcleo del propio pod. Las máquinas virtuales del administrador de pods son responsables de realizar el reaprovisionamiento de la conexión de los clientes de usuario final con el software de Horizon Agent que se ejecuta en los escritorios virtuales aprovisionados por el pod.

Tabla 3. Requisitos de la máquina virtual de administración de pods: para las máquinas virtuales principales del pod, sin incluir configuraciones de puerta de enlace
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Pod sin alta disponibilidad habilitada: instancias de administración del pod Linux - Familia Dv3 estándar:

Standard_D4_v3 (4 núcleos, 16 GB de memoria).

Disco del SO: HDD estándar de 30 GiB

Nota: Si el tipo Standard_D4_v3 no está disponible en la región de Microsoft Azure, el implementador utilizará Standard_D3_v2 (4 núcleos, 14 GB de memoria) de la familia Dv2 estándar.
1 por pod durante las operaciones de estado estable

2 por pod durante el tiempo empleado de extremo a extremo para el proceso de actualización azul/verde del pod.

Para un pod sin alta disponibilidad habilitada, durante las operaciones de estado estable, existe una máquina virtual, que se enciende y ejecuta el pod. Cuando VMware Operations pone a su disposición un nuevo manifiesto del pod, y el sistema comienza a crear los componentes verdes para el proceso de actualización azul/verde del pod, se crea y se enciende una segunda instancia. Como parte del proceso de actualización de extremo a extremo, programe la hora a la que el sistema pasará a usar los componentes verdes. Una vez hecho el cambio, el pod utiliza la máquina virtual recién creada para las operaciones de estado estable, la máquina virtual que se usó anteriormente en el conjunto de componentes azules se detiene y, a continuación, se elimina.

El tamaño del entorno debe admitir las dos instancias del administrador de pods que se están ejecutando en paralelo para el período de actualización de extremo a extremo que empieza a partir de la hora en la que el sistema comienza a crear los componentes verdes del pod para el proceso de actualización azul/verde, y que se extiende hasta que las actividades de actualización se completan y el pod pasa a utilizar los nuevos componentes verdes. Consulte la Guía de administración para obtener una descripción del proceso de actualización azul/verde del pod.

Pod con alta disponibilidad habilitada: instancias de administración del pod Linux - Familia Dv3 estándar:

Standard_D4_v3 (4 núcleos, 16 GB de memoria).

Disco del SO: HDD estándar de 30 GiB

Nota: Si el tipo Standard_D4_v3 no está disponible en la región de Microsoft Azure, el implementador de pods utilizará Standard_D3_v2 (4 núcleos, 14 GB de memoria) de la familia Dv2 estándar.
2 por pod durante las operaciones de estado estable

4 por pod durante el tiempo empleado de extremo a extremo para el proceso de actualización azul/verde del pod.

Para un pod con alta disponibilidad habilitada, durante las operaciones de estado estable, existen dos máquinas virtuales, que se encienden y ejecutan el pod. Cuando VMware Operations pone a su disposición un nuevo manifiesto del pod, y el sistema comienza a crear los componentes verdes para el proceso de actualización azul/verde del pod, se crea y se enciende una segunda instancia por máquina virtual del administrador de pods. En ese momento, hay un total de cuatro (4) máquinas virtuales del administrador de pods que están en ejecución. Como parte del proceso de actualización de extremo a extremo, programe la hora a la que el sistema pasará a usar los componentes verdes. Una vez hecho el cambio, el pod utiliza las dos máquinas virtuales recién creadas para las operaciones de estado estable, y las dos máquinas virtuales que se usaron anteriormente en el conjunto de componentes azules se detienen y, a continuación, se eliminan.

El tamaño del entorno debe admitir las cuatro instancias del administrador de pods que se están ejecutando en paralelo para el período de actualización de extremo a extremo que empieza a partir de la hora en la que el sistema comienza a crear los componentes verdes del pod para el proceso de actualización azul/verde, y que se extiende hasta que las actividades de actualización se completan y el pod pasa a utilizar los nuevos componentes verdes. Consulte la Guía de administración para obtener una descripción del proceso de actualización azul/verde del pod.

Máquinas virtuales relacionadas con la puerta de enlace

Las máquinas virtuales relacionadas con la puerta de enlace son:

  • Las instancias de Unified Access Gateway configuradas para que funcionen como puertas de enlace seguras para los clientes de usuario final que acceden a los recursos aprovisionados por el pod.
  • Cuando se implementa la puerta de enlace externa en una red virtual independiente, la máquina virtual del Connector de puerta de enlace controla las operaciones de administración de la nube en esa configuración de puerta de enlace externa.
Nota: A partir de la versión trimestral de julio de 2020, puede elegir entre una lista de modelos de máquinas virtuales compatibles para las instancias de Unified Access Gateway cuando implemente una puerta de enlace nueva, ya sea en el momento de la implementación de todo el pod o al agregar una nueva puerta de enlace. Antes de la versión 2020 de julio, las instancias de puerta de enlace eran necesarias para utilizar el modelo de máquina virtual Standard_A4_v2. La lista de modelos de máquinas virtuales compatibles que puede elegir en el asistente en pantalla dependerá de los modelos de máquina virtual que estén disponibles en la región de Microsoft Azure en la que va a implementar las instancias de puerta de enlace. Las opciones que se muestran también dependerán de la cuota de máquina virtual en la suscripción de Microsoft Azure que se utiliza para la implementación de la puerta de enlace. El menú Modelo de máquina virtual del asistente de implementación de pods refleja de forma dinámica los modelos de máquina virtual que cumplen estos requisitos.

Las actualizaciones de software mantendrán los modelos de máquina virtual de las instancias de puerta de enlace. Siempre que el modelo de máquina virtual de las instancias de puerta de enlace sea anterior a una actualización de pod, será su modelo de máquina virtual después de la actualización.

Tabla 4. Requisitos de máquina virtual de Unified Access Gateway
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Instancias de Unified Access Gateway A partir de esta versión, puede elegir entre los siguientes modelos de máquina virtual para las nuevas implementaciones de puerta de enlace.
  • Familia Standard Av2 de Linux: Standard_A4_v2 (4 núcleos, 8 GB de memoria), disco del SO: HDD estándar de 20 GiB
  • Familia Standard FSv2 de Linux:
    • Standard_F8s_v2 (8 núcleos, 16 GB de memoria), disco del SO: SSD de 32 GiB

Varía según si elige tener una configuración de Unified Access Gateway externa o interna, o ambos tipos para el mismo pod.

Para una instancia que solo sea externa o interna:
  • 2 por pod durante las operaciones de estado estable
  • 4 por pod durante el tiempo empleado de extremo a extremo para las actividades de actualización azul/verde relacionadas con el pod.
Para un pod con configuración de Unified Access Gateway tanto externa como interna
  • 4 por pod durante las operaciones de estado estable
  • 8 por pod durante el tiempo empleado de extremo a extremo para las actividades de actualización azul/verde relacionadas con el pod.
Unified Access Gateway es una función opcional que se implementa para el pod cuando se establece la configuración de puerta de enlace en el asistente de implementación. Si decide tener instancias de Unified Access Gateway en el pod, el entorno debe admitir dichas instancias que se ejecutan durante el proceso de actualización azul/verde de extremo a extremo del pod. El número de instancias de estado estable depende de si opta por tener ambas configuraciones de Unified Access Gateway.

Cuando tiene solo una configuración externa o solo una configuración interna de Unified Access Gateway, durante las operaciones de estado estable, existen dos instancias, las cuales están encendidas y proporcionan las capacidades de Unified Access Gateway. Durante un proceso de actualización, se crean dos instancias adicionales, que se encienden para ejecutar actualizaciones de software en Unified Access Gateway. Una vez hecho el cambio, el pod migra y pasa a usar las máquinas virtuales recién creadas, y las máquinas virtuales que se usaron anteriormente en el conjunto de componentes azules se detienen y, a continuación, se eliminan.

Cuando tiene ambas configuraciones de Unified Access Gateway, durante las operaciones de estado estable, existen cuatro instancias, las cuales están encendidas y proporcionan las capacidades de Unified Access Gateway. Dos instancias proporcionan las capacidades de la configuración externa y dos instancias, las de la configuración interna. Durante un proceso de actualización, se crean dos instancias adicionales por configuración, que se encienden para ejecutar las actualizaciones de software en Unified Access Gateway. Una vez hecho el cambio, el pod migra y pasa a usar las máquinas virtuales recién creadas, y las máquinas virtuales que se usaron anteriormente en el conjunto de componentes azules se detienen y, a continuación, se eliminan.

El tamaño del entorno debe admitir las instancias indicadas de Unified Access Gateway que se están ejecutando en paralelo para el período de actualización de extremo a extremo que empieza a partir de la hora en la que el sistema comienza a crear los componentes verdes del pod para el proceso de actualización azul/verde, y que se extiende hasta que las actividades de actualización se completan y el pod pasa a utilizar los nuevos componentes verdes. Consulte la Guía de administración para obtener una descripción del proceso de actualización azul/verde del pod.

Tabla 5. Cuando la puerta de enlace externa está en una VNet independiente: requisitos de la máquina virtual del conector de puerta de enlace
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Instancia del conector de puerta de enlace Familia Av2 estándar de Linux:

Standard_A1_v2 (1 núcleo, 2 GB de memoria)

Disco del sistema operativo: HDD estándar de 10 GiB

1 por este tipo de puerta de enlace externa durante las operaciones de estado estable

2 por este tipo de puerta de enlace externa durante el tiempo empleado de extremo a extremo para las actividades de actualización azul/verde relacionadas con el pod.

Cuando la puerta de enlace externa se implementa en una VNet independiente, esta máquina virtual se crea y se utiliza para las operaciones de administración de la nube en esa configuración de puerta de enlace externa. Durante un proceso de actualización, se crea una instancia adicional y se enciende para ejecutar las actualizaciones de software en Unified Access Gateway en la configuración de la puerta de enlace externa. Una vez finalizada la actualización, se produce la migración a la máquina virtual recién creada y se detiene el uso anterior y, a continuación, se elimina. Si decide utilizar esta configuración opcional, el entorno debe alojar estas instancias que se ejecutan de extremo a extremo durante las actividades de actualización azules/verdes relacionadas con el pod.

Máquinas virtuales de imagen principal

Una imagen principal es una máquina virtual de sistema operativo Microsoft Windows que se configura para que Horizon Cloud pueda convertirla en una imagen publicada. A veces, verá que se hace referencia a estas máquinas virtuales como patrones dorados o imágenes maestras.

Tabla 6. Requisitos de la máquina virtual de imagen
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Imágenes principales

Las imágenes principales están habilitados para GPU o no, según lo que usted seleccione al crearlas.

Para las imágenes principales con GPU habilitado, el sistema utiliza:

  • El NV6 estándar de la serie NV (de las vCPU de la familia NV estándar)
  • Disco del SO: HDD estándar de 127 GiB

Variable, según sus necesidades

Una imagen principal es una máquina virtual de sistema operativo Microsoft Windows que se configura para que Horizon Cloud pueda convertirla en una imagen publicada. Una máquina virtual de sistema operativo Windows compatible con RDSH brinda la base que se utiliza para crear instancias de RDSH en las granjas que proporcionan escritorios basados en sesiones y aplicaciones remotas a los usuarios finales. Una máquina virtual de sistema operativo cliente Windows brinda la base que se utiliza para crear los escritorios de VDI. Cada imagen principal es una combinación de sistema operativo Microsoft Windows y si tiene GPU habilitado o no. Por tanto, si desea que el pod proporcione:

  • Escritorios RDSH que usan el centro de datos de Microsoft Windows 2016, sin GPU
  • Escritorios RDSH que usan el centro de datos de Microsoft Windows 2016, con GPU

Necesita entonces al menos 2 máquinas virtuales de imagen principal.

El proceso para convertir una imagen principal en una imagen publicada en ocasiones se denomina publicar la imagen, o también, sellar la imagen. En ocasiones, la imagen publicada resultante recibe el nombre de imagen sellada o imagen asignable, porque tiene un estado finalizado para su uso en las asignaciones.

El sistema apaga la imagen principal automáticamente cuando se publica (es decir, al realizar la acción Convertir en imagen en la imagen principal en la consola administrativa). Al actualizar una imagen publicada, el sistema enciende la máquina virtual nuevamente.

Nota: Cuando se duplica una imagen desde la consola, el sistema vuelve a encender temporalmente la máquina virtual de la imagen principal para obtener su configuración y aplicarla al duplicado. Cuando consigue la información necesaria, la vuelve a apagar.

Para obtener información sobre cómo crear una imagen principal, consulte el tema Creación de imágenes de escritorio para un pod de Horizon Cloud on Microsoft Azure en la Guía de administración.

En el caso de las imágenes principales sin GPU habilitado y los sistemas operativos cliente Microsoft Windows, el sistema usa:

  • Standard_D4_v3 (de las vCPU de la familia Dv3 estándar)
  • Disco del SO: HDD estándar de 127 GiB

Si Microsoft no proporciona la familia Dv3 estándar en la región de Microsoft Azure donde implementó el pod, el sistema utiliza Standard_D3_v2 en lugar de la familia Dv2 estándar.

En el caso de las imágenes principales sin GPU habilitado y los sistemas operativos compatibles con RDSH de Microsoft Windows, el sistema usa:

  • Standard_D2_v3 (de las vCPU de la familia Dv3 estándar)
  • Disco del SO: HDD estándar de 127 GiB

Si Microsoft no proporciona la serie Dv3 en la región de Microsoft Azure donde implementó el pod, el sistema utiliza Standard_D2_v2 en lugar de la familia Dv2 estándar.

Máquinas virtuales de granja

Las máquinas virtuales de la granja RDSH son las instancias compatibles con RDS que proporcionan aplicaciones remotas y escritorios basados en sesiones a los usuarios finales. Se necesita al menos una granja RDSH para distribuir escritorios de la sesión y una granja RDSH para distribuir aplicaciones remotas. Para cumplir con las necesidades del usuario final o del administrador, puede implementar granjas adicionales.

Nota: En la versión de servicio actual, no es posible proporcionar escritorios basados en sesiones ni aplicaciones remotas desde la misma granja.
Tabla 7. Requisitos de la máquina virtual de granja
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Granja RDSH

Puede personalizar el conjunto de tipos de máquina virtual de Microsoft Azure que desea que esté disponible para su selección al crear granjas en el pod. Puede personalizar su propia lista desde el conjunto de tamaños de máquina virtual de Microsoft Azure que están disponibles generalmente en las regiones estándar de Microsoft Azure. Para obtener más información sobre cómo personalizar el conjunto de tipos de máquinas virtuales disponibles para su uso en las granjas, consulte la Guía de administración de Horizon Cloud.

Al crear o editar una granja, puede personalizar el tamaño de disco del sistema operativo de las instancias de RDSH de la granja para cambiarlo del valor predeterminado del sistema.

Para obtener información específica sobre los tamaños de máquina virtual de Windows que están generalmente disponibles en las regiones estándar de Microsoft Azure, consulte la documentación de Microsoft en https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.

Nota: Para los entornos de producción, asegúrese de que los tipos de máquinas virtuales que utilice para las granjas tengan un mínimo de dos (2) CPU. Si se cumplen estos criterios, se evitarán problemas inesperados de conexión de los usuarios finales. Estos criterios son el resultado de las recomendaciones de Horizon Agent sobre un mínimo de 2 CPU para instalar o actualizar Horizon Agent desde la versión 7.x o una versión posterior. Los criterios de Horizon Agent se especifican en la documentación del producto de Horizon a partir de la versión 7.8 (las referencias a un mínimo de 2 CPU comienzan en esta versión y se pueden encontrar en Instalar Horizon Agent en una máquina virtual).
Varía según sus necesidades y la forma en que haya personalizado los tamaños de máquina virtual en el entorno de Horizon Cloud.

El estado de alimentación de las máquinas virtuales varía según los valores de configuración de la granja y la demanda de los usuarios finales.

Máquinas virtuales de escritorio VDI

Las máquinas virtuales de escritorio VDI son las instancias que proporcionan escritorios VDI a los usuarios finales.

Nota: Una nueva función de la versión de servicio trimestral de julio de 2020 es el uso de funciones de App Volumes con pods en Microsoft Azure. Cuando se utiliza el proceso de captura de App Volumes de la consola para agregar aplicaciones nativas al inventario de Horizon Cloud, el sistema crea una asignación de escritorios VDI de dos máquinas virtuales para admitir el proceso de captura. El tipo de máquina virtual utilizado para esta asignación generada por el sistema es el mismo modelo que se utiliza para la imagen publicada que seleccionó en la consola para el proceso de captura de aplicaciones.
Tabla 8. Requisitos de la máquina virtual de escritorio de VDI
Máquina virtual Especificación de máquinas virtuales de Microsoft Azure Cantidad Descripción
Escritorios VDI

Puede personalizar el conjunto de tipos de máquina virtual de Microsoft Azure que desea que esté disponible para su selección al crear asignaciones de escritorios VDI en el pod. Puede personalizar su propia lista desde el conjunto de tamaños de máquina virtual de Microsoft Azure que están disponibles generalmente en las regiones estándar de Microsoft Azure. Para obtener más información sobre cómo personalizar el conjunto de tipos de máquinas virtuales disponibles para su uso en las asignaciones de escritorio VDI, consulte la Guía de administración de Horizon Cloud.

Nota: Un pequeño conjunto de tamaños de máquina virtual de Microsoft Azure que Microsoft ha determinado que no son adecuados para los casos de uso de VDI se omiten automáticamente, como Standard_B2ls y Standard_B1s.

Al crear o editar una asignación de escritorio VDI, puede personalizar el tamaño de disco del sistema operativo de las instancias de escritorios VDI para cambiarlo a otro valor distinto al predeterminado del sistema.

Para obtener información detallada sobre los tamaños de máquinas virtuales de Windows, consulte la documentación de Microsoft en https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.

Nota: Para los entornos de producción, asegúrese de que los tipos de máquinas virtuales que utilice para las asignaciones de escritorio de VDI tengan un mínimo de dos (2) CPU. Si se cumplen estos criterios, se evitarán problemas inesperados de conexión de los usuarios finales. Estos criterios son el resultado de las recomendaciones de Horizon Agent sobre un mínimo de 2 CPU para instalar o actualizar Horizon Agent desde la versión 7.x o una versión posterior. Los criterios de Horizon Agent se especifican en la documentación del producto de Horizon a partir de la versión 7.8 (las referencias a un mínimo de 2 CPU comienzan en esta versión y se pueden encontrar en Instalar Horizon Agent en una máquina virtual).
Varía según sus necesidades y la forma en que haya personalizado los tamaños de máquina virtual en el entorno de Horizon Cloud.

El estado de alimentación de las máquinas virtuales varía según las opciones de configuración de la asignación de escritorios de VDI y la demanda de los usuarios finales.