Si utiliza una VNet emparejada, la práctica recomendada es crear las subredes requeridas antes de implementar el pod para asegurarse de que haya tenido en cuenta los espacios de direcciones que necesitan sus subredes en la VNet antes de ejecutar el asistente de implementación. Incluso cuando la VNet no está emparejada, en lugar de hacer que el proceso de implementación del pod de first-gen cree las subredes necesarias, puede crearlas de antemano en la VNet.

Importante: Esta información se aplica únicamente cuando tenga acceso a un entorno de arrendatario de first-gen en el plano de control de first-gen. Como se describe en el artículo 92424 de la base de conocimientos, el plano de control de first-gen ha llegado a la fecha de fin de disponibilidad (EOA). Consulte el artículo para obtener información.
Importante: 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 esta versión de manifiesto o una versión posterior como para los pods actualizados a dicha versión o una versión posterior, la subred de administración del pod también debe admitir la comunicación de red con el recurso de servicio de Microsoft Azure Database for PostgreSQL del pod. Antes de implementar un pod nuevo o actualizar un pod existente, la subred de administración del pod que se cree debe contar con el servicio Microsoft.Sql como endpoint de servicio. El proceso de implementación o actualización comprobará si la subred tiene el endpoint y no continuará si el endpoint no está habilitado en la subred. Para obtener más información, consulte Arrendatarios de first-gen: cuándo usar las subredes existentes para un pod de Horizon Cloud en Microsoft Azure.

Al crear las subredes de antemano, debe asegurarse de que sus rangos de direcciones, en notación de enrutamiento de interdominios sin clases (CIDR), cumplan los requisitos mínimos del asistente de implementación de pods:

  • Para la subred de administración, se requiere una CIDR de /27 o más. Esta subred es para las direcciones IP que utilizan las máquinas virtuales involucradas en las actividades de administración del pod en sí.
  • Para la subred de máquina virtual principal, también conocida como subred de tenant o de escritorio, se requiere un CIDR de /27 o más. Para entornos de producción, se recomienda una CIDR de /24 a /21 (256 direcciones a 2048 direcciones). Esta subred es para las direcciones IP que se utilizan para las máquinas virtuales de servidor RDSH y de escritorios de VDI en esa subred. La máquina virtual del administrador de pods utiliza una dirección IP de esta subred. Si el pod tendrá una configuración interna de Unified Access Gateway, esas máquinas virtuales de Unified Access Gateway también usarán direcciones IP de esta subred. Si el pod tendrá una configuración de puerta de enlace externa que se implementa mediante la VNet del pod, las máquinas virtuales de Unified Access Gateway de esa puerta de enlace externa también usan direcciones IP de esta subred.
    Importante: Las máquinas virtuales de los escritorios VDI, las imágenes compatibles con RDS y todas la máquinas virtuales RDSH de las granjas del pod consumen estas direcciones IP. Debido a que no puede extenderse esta subred de máquina virtual principal después de implementado el pod, asegúrese de establecer este rango lo suficientemente grande para admitir al número de escritorios que prevea que querrá que este pod proporcione. Por ejemplo, si prevé que este pod debería proporcionar más de 1000 escritorios en el futuro, asegúrese de que este rango incluya más que ese número de direcciones IP. A partir de la versión de julio de 2020, una nueva función permite editar el pod y agregar subredes de máquina virtual adicionales para que las usen las máquinas virtuales de granja y las máquinas virtuales de escritorio VDI. Esa nueva función ofrece la flexibilidad de agregar subredes de máquina virtual a lo largo del tiempo para adaptarse al crecimiento de asignaciones de escritorios VDI y granjas. Debido a que el sistema utilizará la subred de la máquina virtual principal de forma predeterminada, a menos que se especifique expresamente las subredes adicionales en las definiciones de asignaciones de escritorios VDI y granjas, se recomienda asegurarse de que el rango de la subred de la máquina virtual principal sea lo suficientemente grande como para acomodar el número previsto de máquinas virtuales y escritorios de granja.
  • Si va a realizar una configuración externa de Unified Access Gateway implementada en la VNet del pod, necesita una subred DMZ con una CIDR de /28 o más. Esta subred es para las direcciones IP que utilizan las NIC de las máquinas virtuales de Unified Access Gateway para comunicarse con el equilibrador de carga de la configuración de esta puerta de enlace externa. Si desea mantener los rangos de subredes DMZ y administración ubicados de forma conjunta, podría hacer que el rango de subredes DMZ fuera similar al de la subred de administración con una dirección IP especificada. Por ejemplo, si la subred de administración es 192.168.8.0/27, una subred DMZ coincidente sería 192.168.8.32/27.
  • Si va a implementar la configuración de Unified Access Gateway externa en su propia VNet, independiente de la del pod, esa VNet necesita tres subredes:
    • Se requiere una subred de administración con una CIDR de /27 o más. Esta subred es para las direcciones IP que utilizan las máquinas virtuales involucradas en las actividades de administración de la puerta de enlace externa global, como la máquina virtual del conector de puerta de enlace.
    • Se requiere una subred back-end con una CIDR de /27 o más. Esta subred es para las direcciones IP que utilizan las NIC de las máquinas virtuales de Unified Access Gateway para comunicarse con las máquinas virtuales de escritorio y granja aprovisionadas por el pod a través de la VNet emparejada con la VNet del pod.
    • Una subred de front-end (DMZ) con una CIDR de /28 o más. Esta subred es para las direcciones IP que utilizan las NIC de las máquinas virtuales de Unified Access Gateway para comunicarse con el equilibrador de carga de la puerta de enlace externa. Si desea mantener los rangos de subredes de front-end y administración ubicados de forma conjunta en esta VNet, podría hacer que el rango de subredes DMZ fuera similar al de la subred de administración con una dirección IP especificada. Por ejemplo, si la subred de administración es 192.168.8.0/27, una subred de front-end coincidente sería 192.168.8.32/27.
Importante: Para cada CIDR, asegúrese de que cada combinación de máscara de bits y prefijo dé como resultado un rango de direcciones IP donde el prefijo aparezca como la dirección IP inicial. Microsoft Azure requiere que el prefijo CIDR sea el principio del rango. Por ejemplo, un CIDR correcto de 192.168.182.48/28 podría provocar un rango de IP de 192.168.182.48 a 192.168.182.63, y el prefijo es igual que la dirección IP inicial (192.168.182.48). Sin embargo, un CIDR incorrecto de 192.168.182.60/28 podría provocar un rango de IP de 192.168.182.48 a 192.168.182.63, donde la dirección IP inicial no es igual al prefijo de 192.168.182.60. Asegúrese de que sus CIDR deriven en rangos de direcciones IP en los que la dirección IP inicial coincida con el prefijo de CIDR.

Requisitos previos

Asegúrese de que la región de Microsoft tenga la VNet que va a utilizar para el pod. Consulte Horizon Cloud first-gen: configurar la red virtual obligatoria en Microsoft Azure.

Asegúrese de que no se superpongan los rangos de direcciones que va a utilizar para las subredes. El asistente de implementación de pods mostrará un error si los rangos de subredes se superponen.

Procedimiento

  1. En el portal de Microsoft Azure, desplácese hasta la VNet para la que necesita crear las subredes descritas.
  2. Haga clic en Subredes.
  3. Haga clic en + Subred.
    Aparece la pantalla Agregar subred.
  4. Proporcione la información de los campos obligatorios.
    Opción Descripción
    Nombre Especifique un nombre para la subred.
    Rango de direcciones (bloque CIDR) Escriba una CIDR para la subred.
  5. Si esta subred va a ser la subred de administración, en la sección Endpoints de servicio, seleccione el servicio Microsoft.Sql.
  6. Haga clic en Aceptar.
    La subred se agrega a la VNet.
  7. Repita los pasos del 3 al 5 para agregar las subredes necesarias restantes.
  8. Si va a implementar la puerta de enlace externa en su propia VNet, repita los pasos para las subredes de esa VNet.

Resultados

Precaución: Las subredes que se creen de forma manual en la VNet antes de la implementación del pod deben permanecer vacías. No reutilice las subredes existentes que ya tienen elementos que utilizan direcciones IP en dichas subredes. Si una dirección IP ya está en uso en las subredes, es muy probable que se produzcan problemas, como un pod que no se implementa u otros problemas de conflictos de IP descendentes. No ponga ningún recurso en las subredes o, de lo contrario, utilice cualquiera de las direcciones IP. Este aviso de precaución incluye pods implementados desde Horizon Cloud: no reutiliza las subredes en las que ya se dispone de un pod implementado.

Qué hacer a continuación

Para cualquier subred de administración que creó, asegúrese de que el servicio Microsoft.Sql esté habilitado como un endpoint de servicio. Consulte Arrendatarios de first-gen: cuándo usar las subredes existentes para un pod de Horizon Cloud en Microsoft Azure. Este servicio debe estar habilitado en la subred de administración del pod y, si va a implementar la puerta de enlace externa en su propia VNet, el servicio también debe estar habilitado en la subred de administración de esa puerta de enlace.