Citrix Virtual Apps and Desktops: Análisis detallado de las zonas
En este artículo se explica en detalle cómo funcionan las zonas en los entornos Citrix Virtual Apps and Desktops. También analizamos las implicaciones de colocar elementos como controladores de entrega, conexiones de hipervisores y catálogos de máquinas en diferentes zonas. Puede que quiera empezar leyendo acerca de las zonas en la documentación del producto Citrix.
Zonas primarias y satélite
Cada sitio tiene una zona principal, que incluye la base de datos del sitio central y al menos dos Delivery Controllers.
Las zonas secundarias o satélites incluyen uno o más VDA, controladores, servidores StoreFront y NetScaler Gateways. En operaciones normales, los Controllers de una zona satélite se comunican directamente con la base de datos central del sitio en la zona principal.
Se supone que los controladores de la zona principal tienen buena conectividad con la base de datos del sitio y tienen cierta conectividad con todas las zonas satélite. Sin embargo, no se supone que los elementos de cada zona satélite tengan conectividad con elementos de otras zonas satélite.
Elementos que se pueden asociar a zonas
Varios elementos de una implementación pueden asociarse a una zona satélite. Los elementos de la zona satélite afectan a la forma en que el Sitio interactúa con esos elementos y otros objetos relacionados con ellos. Los elementos que se pueden colocar en las zonas satélite son:
- Máquinas de Controller
- Conexiones con el hipervisor
- Catálogos de máquinas
- NetScaler Gateway
Cuando las máquinas Controller se colocan en una zona satélite, se supone que esas máquinas tienen una buena conectividad local con hipervisores y máquinas VDA en la misma zona satélite. Suponiendo una buena conectividad local, el sistema establece una preferencia para usar los Controllers dentro de la zona para gestionar esos hipervisores y máquinas VDA.
Cuando la conexión de hipervisor se coloca en una zona satélite, se supone que todos los hipervisores gestionados con esa conexión de hipervisor también residen en esa zona satélite. Se prefieren los controladores de esa zona para la comunicación con esa conexión de hipervisor.
Un catálogo de máquinas colocado en una zona satélite implica de manera similar que todas las máquinas VDA de ese catálogo están en la zona satélite. Tras el primer registro de cada VDA, se activa el mecanismo de actualización automática de la lista de controladores. La ubicación de la zona satélite también determina qué Controllers se prefieren cuando los VDA se registran en el sitio.
Los VDA prefieren registrarse en Controllers dentro de su zona local y conmutar por error al registro con Controllers en la zona principal. Los VDA no se registran en los Controllers de otras zonas satélite.
Las instancias de NetScaler Gateway también se pueden asociar a zonas, pero la asociación de Gateway se realiza en la configuración de enrutamiento óptimo de HDX de StoreFront y no, como ocurre con los demás elementos que se describen aquí, como parte de la configuración del sitio. Cuando se asocia un NetScaler Gateway a una zona, significa que se prefiere el Gateway de la zona para las conexiones HDX a las máquinas VDA de esa zona.
Límites a la calidad de conexión
Los Controllers de la zona satélite llevan a cabo interacciones SQL directamente con la base de datos del sitio. Si bien se han realizado algunos cambios para minimizar esta interacción SQL, sí que impone algunos límites a la calidad del enlace entre la zona satélite y la zona principal que contiene la base de datos. Los límites concretos dependen de la cantidad de agentes VDA y sesiones de usuario en esos VDA que se implementan en la zona satélite. Por lo tanto, zonas satélite con pocos VDA y pocas sesiones pueden funcionar con una conexión de peor calidad a la base de datos que las zonas satélite que tengan grandes cantidades de agentes VDA y muchas sesiones. A continuación, se ofrecen algunas directrices:
| Cantidad de sesiones a respaldar | Cantidad máxima supuesta de inicios concurrentes de sesiones de usuario final | Ancho de banda mínimo aceptable | Latencia de ida y vuelta máxima aceptable |
|---|---|---|---|
| Menos de 50 | 20 | 1 Mbps | 250 milisegundos |
| 50–500 | 25 | 1,5 Mbps | 100 ms |
| 500 a 1.000 | 30 | 2 Mbps | 50 milisegundos |
| 1,000–3,000 | 60 | 8 Mbps | 10 milisegundos |
| Más de 3.000 | 60 | 8 Mbps | 5 milisegundos |
Alta disponibilidad con caché de host local
La caché del host local puede ayudar a mantener una alta disponibilidad de intermediación de nuevas conexiones para los usuarios finales en caso de que se produzca una interrupción del sistema. Si utiliza zonas, una pérdida de comunicación entre una zona satélite y la zona principal puede provocar la interrupción, ya que la base de datos reside en la zona principal. En este caso, los Controllers de la zona satélite cambian a la caché de host local y permiten a los usuarios finales negociar nuevas conexiones a aplicaciones y escritorios. Sin embargo, los VDA en los que se ejecutan esas sesiones deben ser accesibles desde los Controllers de la zona satélite.
Entre otras tareas, Citrix Config Synchronizer Service (CSS) proporciona de forma rutinaria al servicio de alta disponibilidad información sobre todos los Controllers de la zona. Con esa información, cada servicio de alta disponibilidad conoce todos los servicios de alta disponibilidad del mismo nivel.
Los servicios High Availability Service se comunican entre sí por un canal independiente. Utilizan una lista alfabética de nombres de FQDN de las máquinas en las que se ejecutan para determinar (elegir) qué servicio de alta disponibilidad se encarga de las operaciones de intermediación en la zona si se produce una interrupción. Durante la interrupción, todos los VDA vuelven a registrarse en el High Availability Service que se haya elegido. Los servicios de alta disponibilidad no elegidos de la zona rechazan activamente las solicitudes de conexión entrante y registro de VDA.
Si un servicio de alta disponibilidad elegido falla durante una interrupción, se elige otro servicio de alta disponibilidad para que asuma el control y los VDA se vuelven a registrar en el servicio de alta disponibilidad recientemente elegido.
Durante una interrupción, si se reinicia un Controller:
- Si ese Controller no es el broker principal elegido, el reinicio no tiene repercusión.
- Si ese Controller es el broker principal elegido, se elegirá otro Controller, por lo que los VDA deberán volver a registrarse. Después de que el Controller reiniciado se encienda, se hace cargo automáticamente de la intermediación, por lo que los VDA deben volver a registrarse. En este escenario, el rendimiento podría verse afectado durante las reinscripciones.
- Si apaga un Controller durante las operaciones normales y lo enciende durante una interrupción, la función Caché de host local no se puede utilizar en ese Controller si este se elige como broker principal.
Implementación de StoreFront
Si desea aprovechar la alta disponibilidad de la intermediación cuando una zona satélite está aislada de la zona principal, implemente una instancia de StoreFront en cada zona satélite. La instancia de StoreFront se necesita en la zona satélite porque una sola instancia de StoreFront en la zona principal por sí sola no puede ponerse en contacto con los Controllers de las zonas satélite si la conectividad entre las zonas principal y satélite se interrumpe en una interrupción del servicio.
Números de zonas
La cantidad de Controllers configurados en el sitio puede afectar al rendimiento de algunas operaciones, como agregar nuevos Controllers al sitio mismo. Para evitar que el rendimiento se vea comprometido, se recomienda limitar el número de zonas de su sitio a no más de 50.
Ajustes y ajustes de configuración de bajo nivel
Se han agregado algunos elementos de configuración nuevos a las zonas de soporte, incluida la adición de la definición de zonas en el nivel del SDK de PowerShell, que forma parte del SDK del servicio de configuración en lugar de, por ejemplo, formar parte del SDK de Broker Service. Otras partes de la configuración de la zona se pueden realizar en otros SDK de PowerShell del servicio de FMA, en particular cuando los elementos están asociados a zonas, lo que hace el servicio que tiene la mayor propiedad de esos objetos. En consecuencia, la pertenencia a la zona de los catálogos de máquinas se define mediante el SDK de Broker Service y la pertenencia a la zona de las conexiones del hipervisor se configura mediante el SDK del servicio de host.
Además, hay disponible una configuración de registro que permite controlar la limitación de los lanzamientos simultáneos de los usuarios finales. La parte principal de la configuración del registro está en HKLM\\Software\\Citrix\\DesktopServer\\ThrottledRequestAddressMaxConcurrentTransactions. En algunas situaciones de prueba, descubrimos que las altas latencias entre las zonas satélite y la base de datos en la zona principal, junto con una tasa relativamente alta de inicios de conexión de aplicaciones y escritorios por parte de los usuarios finales que utilizan un controlador en la zona satélite, provocaban retrasos en los lanzamientos debido a la acumulación de lanzamientos anteriores.
Otros consejos
Se han recibido algunos informes de que el nodo de zonas de Studio ha desaparecido después de actualizar un sitio. El nodo de zonas a veces desaparece porque no se pudo importar el archivo de configuración de roles durante la actualización. Puede corregir el error de importación manualmente importando el archivo mediante el SDK de PowerShell:
cd 'C:\Program Files\Citrix\XenDesktopPoshSdk\Module\Citrix.XenDesktop.Admin.V1\Citrix.XenDesktop.Admin\StudioRoleConfig'
Import-AdminRoleConfiguration –Path .\RoleConfigSigned.xml
<!--NeedCopy-->