Implementar Horizon en Azure VMware Solution
- 09/29/2020
- 11 minutos para leer
-
-
s -
t
-
Nota
Este documento se centra en el producto VMware Horizon, anteriormente conocido como Horizon 7. Horizon es una solución diferente a Horizon Cloud on Azure, aunque hay algunos componentes compartidos. Las principales ventajas de la solución VMware en Azure incluyen tanto un método de dimensionamiento más sencillo como la integración de la gestión de VMware Cloud Foundation en el portal de Azure.
VMware Horizon®, una plataforma de escritorios y aplicaciones virtuales, se ejecuta en el centro de datos y proporciona una gestión sencilla y centralizada. Ofrece escritorios y aplicaciones virtuales en cualquier dispositivo y en cualquier lugar. Horizonte le permite crear y gestionar conexiones a escritorios virtuales de Windows y Linux, aplicaciones alojadas en Remote Desktop Server (RDS), escritorios y máquinas físicas.
Aquí nos centramos específicamente en la implementación de Horizonte en Azure VMware Solution. Para obtener información general sobre VMware Horizon, consulte la documentación de producción de Horizon:
-
¿Qué es VMware Horizon?
-
Más información sobre VMware Horizon
-
Arquitectura de referencia de Horizon
Con la introducción de Horizon en Azure VMware Solution, ahora hay dos soluciones de infraestructura de escritorio virtual (VDI) en la plataforma Azure. El siguiente diagrama resume las diferencias clave a alto nivel.
Horizon 2006 y las versiones posteriores en la línea de lanzamiento de Horizon 8 admiten tanto la implementación en las instalaciones como la implementación de Azure VMware Solution. Hay algunas características de Horizon que son compatibles en las instalaciones pero no en Azure VMware Solution. También se admiten otros productos del ecosistema Horizon. Para obtener información, consulte la paridad de características y la interoperabilidad.
Implementar Horizon en una nube híbrida
Puede implementar Horizon en un entorno de nube híbrida cuando utilice Horizon Cloud Pod Architecture (CPA) para interconectar los centros de datos locales y de Azure. CPA amplía su implementación, construye una nube híbrida y proporciona redundancia para la continuidad del negocio y la recuperación de desastres. Para obtener más información, consulte Ampliación de entornos Horizon 7 existentes.
Importante
CPA no es una implantación ampliada; cada pod de Horizon es distinto, y se requiere que todos los Servidores de conexión que pertenecen a cada uno de los pods individuales estén ubicados en una única localización y se ejecuten en el mismo dominio de difusión desde una perspectiva de red.
Al igual que en las instalaciones o en un centro de datos privado, Horizon puede desplegarse en una nube privada de Azure VMware Solution. Discutiremos las diferencias clave en la implementación de Horizon en las instalaciones y en Azure VMware Solution en las siguientes secciones.
La nube privada de Azure es conceptualmente lo mismo que el SDDC de VMware, un término que se suele utilizar en la documentación de Horizon. En el resto de este documento se utilizan los términos nube privada de Azure y SDDC de VMware de forma intercambiable.
El Conector de Nube de Horizonte es necesario para que Horizonte en la Solución VMware de Azure gestione las licencias de suscripción. Cloud Connector puede implementarse en Azure Virtual Network junto a Horizon Connection Servers.
Importante
La compatibilidad de Horizon Control Plane con Horizon on Azure VMware Solution aún no está disponible. Asegúrese de descargar la versión VHD de Horizon Cloud Connector.
Rol vCenter Cloud Admin
Dado que Azure VMware Solution es un servicio SDDC y Azure gestiona el ciclo de vida del SDDC en Azure VMware Solution, el modelo de permisos de vCenter en Azure VMware Solution está limitado por diseño.
Los clientes deben utilizar el rol Cloud Admin, que tiene un conjunto limitado de permisos de vCenter. El producto Horizon se modificó para funcionar con el rol de Cloud Admin en Azure VMware Solution, específicamente:
-
Se modificó el aprovisionamiento de clones instantáneos para que se ejecute en Azure VMware Solution.
-
Se creó una política vSAN específica (VMware_Horizon) en Azure VMware Solution para que funcione con Horizon, que debe estar disponible y utilizarse en los SDDC implementados para Horizon.
-
La caché de lectura basada en el contenido (CBRC) de vSphere, también conocida como View Storage Accelerator, está desactivada cuando se ejecuta en Azure VMware Solution.
Importante
El CBRC no debe volver a activarse.
Nota
La Solución VMware Azure configura automáticamente los ajustes específicos de Horizon siempre que se implemente Horizon 2006 (también conocido como Horizon 8) y superior en la rama Horizon 8 y se seleccione la opción Azure en el instalador de Horizon Connection Server.
Arquitectura de implementación de Horizon en Azure VMware Solution
Un diseño típico de arquitectura de Horizon utiliza una estrategia de pods y bloques. Un bloque es un único vCenter, mientras que varios bloques combinados forman un pod. Un pod de Horizon es una unidad de organización determinada por los límites de escalabilidad de Horizon. Cada pod de Horizon tiene un portal de gestión independiente, por lo que una práctica de diseño estándar es minimizar el número de pods.
Cada nube tiene su propio esquema de conectividad de red. En combinación con la red de VMware SDDC / NSX Edge, la conectividad de red de Azure VMware Solution presenta requisitos únicos para la implementación de Horizon que son diferentes de los locales.
Cada nube privada de Azure y SDDC puede manejar 4.000 sesiones de escritorio o de aplicaciones, asumiendo:
-
El tráfico de carga de trabajo se alinea con el perfil de trabajador de tareas de LoginVSI.
-
Sólo se considera el tráfico de protocolo, no los datos de usuario.
-
NSX Edge está configurado para ser grande.
Nota
Su perfil de carga de trabajo y sus necesidades pueden ser diferentes y, por tanto, los resultados pueden variar en función de su caso de uso. Los volúmenes de datos de usuario pueden reducir los límites de escala en el contexto de su carga de trabajo. Dimensione y planifique su despliegue en consecuencia. Para obtener más información, consulte las directrices de tamaño en la sección Tamaño de los hosts de la solución VMware de Azure para las implementaciones de Horizon.
Dado el límite máximo de la nube privada de Azure y del SDDC, recomendamos una arquitectura de implementación en la que los servidores de conexión de Horizon y las puertas de acceso unificadas (UAG) de VMware se ejecuten dentro de la red virtual de Azure. Esto convierte efectivamente cada nube privada de Azure y SDDC en un bloque. A su vez, se maximiza la escalabilidad de Horizon que se ejecuta en Azure VMware Solution.
La conexión desde Azure Virtual Network a las nubes privadas Azure / SDDCs debe configurarse con ExpressRoute FastPath. El siguiente diagrama muestra una implementación básica de Horizon.
Conectividad de red para escalar Horizon en Azure VMware Solution
Esta sección expone la arquitectura de red a alto nivel con algunos ejemplos de implementación comunes para ayudarle a escalar Horizon en Azure VMware Solution. El enfoque se centra específicamente en los elementos de red críticos.
Un solo pod de Horizon en Azure VMware Solution
Un solo pod de Horizon es el escenario de implementación más directo porque se implementa un solo pod de Horizon en la región este de Estados Unidos. Dado que se estima que cada nube privada y SDDC puede gestionar 4.000 sesiones de escritorio, se implementa el tamaño máximo de Horizon pod. Puede planificar la implementación de hasta tres nubes privadas/SDDC.
Con las máquinas virtuales (VM) de la infraestructura Horizon implementadas en Azure Virtual Network, puede alcanzar las 12.000 sesiones por pod Horizon. La conexión entre cada nube privada y SDDC a la Red Virtual Azure es ExpressRoute Fast Path. No se necesita tráfico de este a oeste entre las nubes privadas.
Las suposiciones clave para este ejemplo de implementación básica incluyen que:
-
No tiene un pod Horizon local que desee conectar a este nuevo pod utilizando Cloud Pod Architecture (CPA).
-
Los usuarios finales se conectan a sus escritorios virtuales a través de Internet (vs. conectarse a través de un centro de datos local).
Conectan su controlador de dominio AD en Azure Virtual Network con su AD local a través de una VPN o un circuito ExpressRoute.
Una variación del ejemplo básico podría ser soportar la conectividad para los recursos locales. Por ejemplo, los usuarios acceden a los escritorios y generan tráfico de aplicaciones de escritorio virtual o se conectan a un pod Horizon local mediante CPA.
El diagrama muestra cómo soportar la conectividad para los recursos locales. Para conectar su red corporativa a la red virtual de Azure, necesitará un circuito ExpressRoute. También necesitará conectar su red corporativa con cada una de las nubes privadas y los SDDC utilizando ExpressRoute Global Reach. Permite la conectividad desde el SDDC al circuito ExpressRoute y a los recursos locales.
Múltiples pods de Horizon en Azure VMware Solution a través de múltiples regiones
Otro escenario es escalar Horizon a través de múltiples pods. En este escenario, se despliegan dos pods Horizon en dos regiones diferentes y se federan utilizando CPA. Es similar a la configuración de la red en el ejemplo anterior, pero con algunos enlaces adicionales entre regiones.
Conectará la red virtual de Azure en cada región a las nubes privadas/SDDC en la otra región. Permite que los servidores de conexión de Horizon que forman parte de la federación CPA se conecten a todos los escritorios gestionados. La adición de nubes privadas/SDDC adicionales a esta configuración permitiría escalar hasta 24.000 sesiones en total.
Los mismos principios se aplican si despliega dos pods Horizon en la misma región. Asegúrese de desplegar el segundo pod Horizon en una red virtual Azure separada. Al igual que en el ejemplo de un solo pod, puede conectar su red corporativa y su pod local a este ejemplo de varios pods/regiones mediante ExpressRoute y Global Reach.
Dimensionar los hosts de Azure VMware Solution para las implementaciones de Horizon
La metodología de dimensionamiento de Horizon en un host que se ejecuta en Azure VMware Solution es más sencilla que la de Horizon local. Esto se debe a que el host de Azure VMware Solution está estandarizado. El dimensionamiento exacto del host ayuda a determinar el número de hosts necesarios para soportar sus requisitos de VDI. Es fundamental para determinar el coste por escritorio.
Tablas de dimensionamiento
Los requisitos específicos de vCPU/vRAM para los escritorios virtuales de Horizon dependen del perfil de carga de trabajo específico del cliente. Trabaje con su equipo de ventas de MSFT y VMware para ayudar a determinar sus requisitos de vCPU/vRAM para sus escritorios virtuales.
| vCPU por VM | vRAM por VM (GB) | Instancia | 100 VMs | 200 VMs | 300 VMs | 400 VMs | 500 VMs | 600 VMs | 700 VMs | 800 VMs | 900 VMs | 1000 VMs | 2000 VMs | 3000 VMs | 4000 VMs | 5000 VMs | 6000 VMs | 6400 VMs |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 3.5 | AVS | 3 | 3 | 4 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 17 | 25 | 33 | 41 | 49 | 53 |
| 2 | 4 | AVS | 3 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 9 | 18 | 26 | 34 | 42 | 51 | 54 | |
| 2 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 2 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 2 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 2 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 4 | 3.5 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 4 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 4 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 4 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 4 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 6 | 3.5 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 4 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 6 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 6 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 8 | 3.5 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 4 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 6 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 8 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 8 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
Insumos para el dimensionamiento del horizonte
Aquí tienes lo que necesitarás reunir para tu carga de trabajo prevista:
-
Número de escritorios concurrentes
-
VCPU requerida por escritorio
-
VRAM requerida por escritorio
-
Almacenamiento requerido por escritorio
En general, las implementaciones de VDI están limitadas por la CPU o la RAM, lo que determina el tamaño del host. Tomemos el siguiente ejemplo para una carga de trabajo del tipo LoginVSI Knowledge Worker, validado con pruebas de rendimiento:
-
2.000 despliegues de escritorios concurrentes
-
2vCPU por escritorio.
-
4-GB vRAM por escritorio.
-
50 GB de almacenamiento por escritorio
Para este ejemplo, el número total de hosts es de 18, lo que supone una densidad de máquinas virtuales por host de 111.
Importante
Las cargas de trabajo de los clientes variarán con respecto a este ejemplo de LoginVSI Knowledge Worker. Como parte de la planificación de su despliegue, trabaje con su VMware EUC SEs para sus necesidades específicas de tamaño y rendimiento. Asegúrese de ejecutar sus propias pruebas de rendimiento utilizando la carga de trabajo real y planificada antes de finalizar el dimensionamiento del host y ajustar en consecuencia.
Licencias de Horizon en Azure VMware Solution
Hay cuatro componentes en los costos generales de ejecutar Horizon en Azure VMware Solution.
Costo de capacidad de Azure VMware Solution
Para obtener información sobre los precios, consulte la página de precios de Azure VMware Solution
Costo de las licencias de Horizon
Hay dos licencias disponibles para utilizar con Azure VMware Solution, que pueden ser de usuario concurrente (CCU) o de usuario nombrado (NU):
-
Licencia de suscripción de Horizon
-
Licencia de suscripción universal de Horizon
Si solo se va a implementar Horizon en Azure VMware Solution en un futuro próximo, utilice la licencia de suscripción de Horizon ya que tiene un coste menor.
Si se implementa en Azure VMware Solution y en las instalaciones, como en un caso de uso de recuperación de desastres, elija la licencia de suscripción universal de Horizon. Incluye una licencia de vSphere para la implementación en las instalaciones, por lo que tiene un coste más elevado.
Trabaje con su equipo de ventas de VMware EUC para determinar el coste de las licencias de Horizon en función de sus necesidades.
Tipos de instancias de Azure
Para conocer los tamaños de las máquinas virtuales de Azure que se necesitarán para la infraestructura de Horizon, consulte las directrices de VMware que puede encontrar aquí.