Resumen técnico: Caché de host local/modo de alta disponibilidad para el servicio Citrix Virtual Apps and Desktops

Información general

Local Host Cache (LHC), en el contexto del servicio Citrix Virtual Apps and Desktops (CVAD), se puede considerar como una póliza de seguro. Esta póliza de seguro entra en juego cuando, por cualquier motivo (interrupciones, problemas de conexión, apagones de Internet, etc.), Citrix Cloud Connectors no pueden comunicarse con el servicio de intermediación de Citrix (parte del servicio CVAD y, en adelante, el agente de la nube). Un desglose de la comunicación entre una ubicación de recursos y el agente en la nube puede provocar un impacto en el usuario final: la caché de host local está diseñada para mitigar dicho impacto en el usuario final.

Local Host Cache es una combinación de varios servicios y componentes que se unen para asumir las responsabilidades de intermediación hasta que se pueda restablecer la conexión con el broker en la nube.

Ilustración 1: Representación conceptual del servicio CVAD mostrando componentes relevantes para el modo HA

Componentes Cloud Connector

Hay varios componentes dentro de Citrix Cloud Connector que son necesarios para las operaciones de caché de host local.

• Servicio deSincronizador de Configuración: El Servicio de Sincronizador de Configuración (CSS) comprueba periódicamente con el broker en la nube (cada 60 segundos) para ver si se han realizado cambios en la configuración. Los cambios pueden ser iniciados por el administrador (como cambiar una propiedad de grupo de entrega) o acciones del sistema (como asignaciones de máquinas). Cuando se detectan cambios, CSS sincroniza los cambios desde el broker en la nube con las máquinas del conector.
• LocalDB: CSS importa los datos de configuración en una base de datos LocalDB de Microsoft SQL Server Express. Se crea una nueva instancia de la base de datos para cada operación de sincronización. Una vez que la sincronización se ha completado correctamente, la instancia de base de datos más reciente reemplaza a la instancia de base de datos anterior.
• Servicio de alta disponibilidad: El servicio de alta disponibilidad (HA Service) es un servicio de broker especializado que proporciona la funcionalidad de intermediación en tiempo de ejecución durante una interrupción. El Servicio de Asuntos Humanitarios también se denomina intermediario secundario.
• Proveedor de Broker Remoto: El Proveedor de Broker Remoto realiza varias funciones importantes:
  • Actúa como un proxy de comunicación de retransmisión entre Citrix Virtual Delivery Agent (VDA) y Cloud Broker
  • Actúa como un proxy que transmite la comunicación entre un StoreFront local o un ADC local y los diversos servicios de Citrix Cloud
  • Determina cuándo cambiar una ubicación de recursos entre el modo HA y el funcionamiento normal

Ilustración 2: Componentes y servicios del conector que desempeñan un papel con el modo HA

El tamaño adecuado de las máquinas de Cloud Connector es un paso importante para garantizar que los recursos adecuados estén disponibles para los servicios en el modo de alta disponibilidad. Consulte el artículo sobre consideraciones de escala y tamaño para obtener más información.

Modo de alta disponibilidad

Citrix Cloud Connectors es capaz de entrar o salir del modo HA automáticamente sin intervención del administrador. El modo HA se puede activar mediante cualquiera de las siguientes opciones:

• Error de enumeraciones de StoreFront o solicitudes de inicio
• Error al retransmitir las comunicaciones entre el VDA y el broker en la nube
• Error al presentar solicitudes de Secure Tíquet Authority (STA) al servicio CVAD en nombre de un ADC local durante un lanzamiento

Durante el modo HA, el servicio HA asume varias funciones importantes de intermediación, enumera recursos, inicia sesión de intermediarios y acepta registros de VDA. Además, el Servicio de HA actúa como proveedor de STA. En una ubicación de recursos con varios Cloud Connectors, los servicios de HA se comunican entre sí como parte de un proceso de elección. Este proceso de elección determina qué instancia del servicio HA asume el control si se activa el modo HA.

Ilustración 3: Ubicación de recursos que funciona en modo HA

Entrada/Salida del Modo de Alta Disponibilidad

La decisión de realizar la transición al modo HA depende del tráfico de enumeración e inicio que fluya a través de una instancia de Cloud Connector determinada. Solo el equipo conector que se haya configurado como Delivery Controller en StoreFront admitirá la detección y transición del modo HA. Esta optimización es necesaria para evitar registros de VDA innecesarios.

Hay varios estados durante todo el ciclo de entrada y salida del modo HA. Durante el estado Working Normal, todos los componentes están en buen estado y todas las transacciones de intermediación son manejadas por el broker en la nube. El CSS está replicando activamente las configuraciones desde el broker en la nube a las máquinas conectoras.

En caso de que algunos de los componentes no informen en buen estado, el conector pasa al estado de alta disponibilidad pendiente. Cuando se encuentra en este estado, se inicia una comprobación de estado completa para determinar el siguiente curso de acción. Los conectores interactúan con otros conectores de la ubicación del recurso para determinar su estado de mantenimiento. La decisión de pasar de HA pendiente a HA inicial se basa en el estado de mantenimiento de todos los conectores de una ubicación de recurso determinada. Si las comprobaciones de estado se realizan correctamente, los conectores pasan de nuevo al estado Working Normal. Alternativamente, si las comprobaciones de estado continúan fallando, los conectores pasan al estado HA inicial.

Ilustración 4: Estados del conector para el modo de alta disponibilidad de entrada/existente

Durante el estado de alta disponibilidad inicial, el servicio de alta disponibilidad del conector asume las responsabilidades de intermediación. Todos los agentes VDA de la ubicación de recursos actual que se registraron con el broker en la nube se registrarán con el servicio de HA/agente secundario en el conector. Al final de la HA inicial, se inician las comprobaciones de estado. Si todas las comprobaciones de mantenimiento se realizan correctamente, el estado pasa a Recuperación pendiente; de lo contrario, el estado pasa a HA extendido.

Las comprobaciones de mantenimiento continúan durante el período de HA extendido y, cuando todas las comprobaciones de mantenimiento se realizan correctamente, el estado pasa a Pendiente de recuperación. No existe una duración máxima de tiempo para que un conector permanezca en el estado HA extendido.

La recuperación pendiente sirve como un período de espera, donde todos los componentes están en buen estado, antes de entregar el intermediario de vuelta al intermediario en la nube. Si alguna de las comprobaciones de estado falla durante la recuperación pendiente, el estado pasa de nuevo a HA extendido. Si todas las comprobaciones de mantenimiento se realizan correctamente durante la totalidad del período de recuperación pendiente, el estado pasa a Working Normal. Con esta transición, el modo HA salido, y todos los agentes VDA de la ubicación de recursos que se registraron con el Broker secundario ahora vuelven a registrarse en el broker en la nube.

Instancia de servicio CVAD con varias ubicaciones de recursos

El broker en la nube está diseñado para tener una vista de toda la implementación en varias ubicaciones de recursos. Sin embargo, cuando está en modo HA, cada ubicación de recurso se convierte en su propio pod independiente, y el agente secundario elegido en cada ubicación de recurso administrará las transacciones de intermediación solo para los agentes VDA dentro de esa ubicación de recursos. Este diseño es una razón crítica para garantizar que StoreFront está configurado para incluir todos los Cloud Connectors de todas las ubicaciones de recursos que contienen cargas de trabajo de VDA. StoreFront puede distribuir solicitudes de lanzamiento y equilibrar la carga de manera efectiva a los usuarios en varias ubicaciones de recursos.

Registros de VDA

Cuando comienza la interrupción, el agente secundario elegido (lea la sección sobre varios conectores en una ubicación de recursos para obtener más información sobre el proceso de elección) no tiene datos de registro de VDA actuales, pero cuando un VDA se comunica con él, se activa un proceso de registro. Durante ese proceso, el agente secundario elegido también obtiene información de sesión actual para ese VDA. El VDA se comunica con el intermediario al menos cada 5 minutos. Dependiendo de cuándo se completó el último latido del corazón, puede tomar un VDA hasta 5 minutos para realizar el cambio del broker en la nube al intermediario secundario elegido y activar el registro con el intermediario secundario elegido.

Mientras el agente secundario elegido gestiona las conexiones, el proveedor de broker remoto supervisa la conexión a Citrix Cloud. Cuando se restablece la conexión, el proveedor de broker remoto indica al agente secundario elegido que deje de escuchar la información de conexión y reanuda la transmisión de operaciones de intermediación al broker en la nube. La próxima vez que un VDA se comunica con el proveedor de broker remoto, se activa otro proceso de registro. El agente secundario elegido elimina cualquier registro de VDA restante de la interrupción anterior. El servicio CSS reanuda la sincronización de información cuando detecta que se han producido cambios de configuración en Citrix Cloud.

Varios conectores en una ubicación de recursos

Citrix recomienda un mínimo de 2 conectores en cada ubicación o zona de recursos. En cada zona, hay un proceso electoral constantemente en marcha para asegurarse de que los Servicios de HA sepan qué máquina de conector asumiría las responsabilidades de intermediación si hay una interrupción. Esta elección siempre ocurre, tanto durante las operaciones normales como cuando se ejecuta en modo HA.

El CSS proporciona de forma rutinaria al agente secundario información sobre todos los Cloud Connectors en la ubicación del recurso. Al disponer de esa información, cada conector sabe acerca de todos los conectores de pares que se ejecutan en la ubicación del recurso. Los brokers secundarios se comunican entre sí por un canal independiente. Estos servicios utilizan una lista alfabética de nombres FQDN de las máquinas en las que se ejecutan para determinar el agente secundario elegido en la zona si se produce una interrupción. Cuando está en modo HA, el intermediario secundario elegido asume las responsabilidades de intermediación, mientras que los otros intermediarios secundarios de la zona rechazan activamente las solicitudes de conexión entrante y registro de VDA.

Si un broker secundario elegido falla durante una interrupción, se elegirá otro broker secundario para que le releve, y los VDA se registrarán en el broker secundario que acaba de elegirse. Durante el modo HA, si se reinicia un conector:

• Si ese conector no es el agente secundario elegido, el reinicio no tiene ningún impacto.
• Si ese conector es el agente secundario elegido, se elige otro Cloud Connector, lo que hace que los VDA se registren con el nuevo agente secundario elegido. Después de que el Cloud Connector reiniciado se encienda, se hace cargo automáticamente de la intermediación, por lo que los VDA deben volver a registrarse. En este caso, el rendimiento puede verse afectado durante los registros.

El registro de eventos proporciona información sobre las opciones elegidas. Para obtener más información sobre los eventos asociados, consulte el artículo de registros de eventos de la documentación del producto.

Caché de host local con varias ubicaciones de recursos

Equilibrio de carga entre conectores en una ubicación de recursos

StoreFront local envía un mensaje de latido a todos los Cloud Connectors configurados en su almacén cada 60 segundos de forma predeterminada. Solo se tienen en cuenta los Cloud Connectors en buen estado (que responden correctamente al latido) para la enumeración de aplicaciones de equilibrio de carga y las solicitudes de inicio. La misma solicitud de latido a Cloud Connectors también activa el conector para participar en el algoritmo de modo HA descrito en las secciones anteriores. Para garantizar que todas las ubicaciones de recursos estén habilitadas para funcionar en modo HA, es fundamental asegurarse de que StoreFront local tenga todos los Cloud Connectors identificados como Delivery Controllers en la configuración de StoreFront. Si no se dispone de las configuraciones adecuadas de StoreFront, se podría perder la capacidad cuando el sitio entra en modo HA.

Ilustración 5: Implementación con varias ubicaciones de recursos donde una RL no está preparada para alta disponibilidad debido a la falta de configuraciones

Modo HA para ubicaciones de recursos publicando las mismas aplicaciones/escritorios

Uno de los modelos de implementación de servicios CVAD incluye varias ubicaciones de recursos: todas ellas publican aplicaciones y escritorios idénticos en todas las ubicaciones de recursos. Por ejemplo, una implementación que contenga aplicaciones de una sola imagen multisesión o escritorios VDI agrupados puede implementarse uniformemente en todas las ubicaciones de recursos.

Cuando una implementación de este tipo funciona en modo HA, los usuarios pueden ser dirigidos a cualquiera de los VDA en las distintas ubicaciones de recursos configuradas. En este caso, la carga de StoreFront equilibra las solicitudes a todos los Cloud Connectors configurados en varias ubicaciones de recursos.

Modo HA para ubicaciones de recursos publicando diferentes aplicaciones/escritorios

Una implementación de servicio CVAD también puede tener determinadas aplicaciones disponibles solo en un subconjunto específico de ubicaciones de recursos. Por ejemplo, un escritorio del sistema operativo japonés solo puede estar disponible en los VDA que se ejecutan en Japón. Otro ejemplo es con escritorios estáticos/asignados que son específicos del usuario y están vinculados a una ubicación de recursos específica después de la asignación.

Cuando una implementación de este tipo funciona en modo HA, las solicitudes de inicio de aplicaciones o escritorios deben enrutarse al Cloud Connector apropiado en las ubicaciones de recursos específicas donde residen las aplicaciones y los escritorios, ya que la intermediación entre zonas no está disponible en modo HA. La función AdvancedHealthCheck ofrecida por StoreFront 1912 LTSR Cumulative Update 1 o posterior ofrece tales implementaciones como se describe en el párrafo siguiente.

StoreFront enumera aplicaciones y escritorios de Cloud Connectors en cualquier región. La información de enumeración ahora contiene una asignación entre el recurso (una aplicación o un escritorio) y las ubicaciones de recursos donde reside la aplicación/escritorio. Esta asignación se utiliza para dirigir las solicitudes de inicio del usuario a ubicaciones de recursos específicas. Revise los pasos de configuración que se enumeran en la documentación del producto para permitir que StoreFront utilice esta funcionalidad.

Arquitecturas con Citrix ADC

Supervisión

El dispositivo Citrix ADC proporciona un monitor integrado, el monitor CITRIX-XD-DDC, que supervisa los servidores Citrix Virtual Apps y Desktop Delivery Controller. En el contexto del servicio Citrix Virtual Apps and Desktops, Cloud Connectors son equivalentes a los servidores de Delivery Controller. El monitor envía un sondeo a los servidores de controlador/conector configurados en forma de mensaje XML. Si el servidor responde al sondeo con la identidad de la comunidad, se considerará que el sondeo ha sido correcto y el estado del servidor se marca como UP. Si la respuesta no tiene un código correcto o la identidad de la comunidad de servidores no está presente en la respuesta, el sondeo se considera un error y el estado del servidor se marca como DOWN.

Encontrará más información sobre el monitor CITRIX-XD-DDC en la documentación de Citrix ADC.

Citrix ADC para ubicaciones de recursos publicando diferentes aplicaciones o escritorios

Para arquitecturas que involucren Citrix ADC con ubicaciones de recursos que publiquen diferentes aplicaciones y escritorios, es necesario realizar las siguientes configuraciones.

• Agregue los Cloud Connectors en cada ubicación de recursos a un VIP único en el equilibrador de carga de ADC.
• Habilite la función StoreFront AdvancedHealthCheck como se describe aquí.
• Asignar cada zona o ubicación de recurso a una IP virtual (VIP) ADC
• Agregue todos los VIP de ADC como Delivery Controllers a StoreFront.
• Configure el equilibrador de carga ADC para supervisar los Cloud Connectors en cada ubicación de recursos a través del monitor CITRIX-XD-DDC.

Ilustración 6: Implementación con varias ubicaciones de recursos y Citrix ADC

Consideraciones sobre la carga de trabajo de VDA de escritorio agrupado

Cuando un usuario cierra sesión en un VDA de escritorio agrupado, la imagen del VDA se restablece para eliminar cualquier dato específico del usuario en el VDA. Cuando un sitio se ejecuta en modo HA, la operación de restablecimiento no está disponible. Y por lo tanto, cuando un usuario cierra sesión de un VDA de escritorio agrupado, la máquina se coloca en modo de mantenimiento. Este restablecimiento evita que una imagen contaminada esté disponible para otro usuario.

Dependiendo de las necesidades de seguridad para una implementación, este comportamiento se puede modificar aplicando una actualización para todo el sitio y por grupo de entrega. Encontrará más información sobre cómo anular el comportamiento predeterminado en la documentación del producto.

Para cargas de trabajo de VDA de sobremesa agrupadas que se ejecutan en VMware vSphere y Citrix Hypervisor, una nueva función que introduce soporte para operaciones de alimentación durante el modo HA está disponible en la vista previa. Esta función agrega la capacidad de restablecer imágenes incluso cuando un sitio está funcionando en modo HA. Lea más sobre la oferta de vista previa aquí.

Prueba de caché de host local

Local Host Cache está diseñado para funcionar sin ninguna intervención del usuario, es totalmente autónoma. Sin embargo, puede verificar que todos los Cloud Connectors estén correctamente sincronizados y listos para asumir el control. Se recomiendan los siguientes pasos:

• Como se describe en las secciones anteriores, cada conector realiza la sincronización de la configuración del sitio de forma independiente. Los resultados de la sincronización están disponibles en el Visor de eventos. Consulte la sección Registros de eventos de la documentación del producto para obtener más información sobre los eventos.
• Se puede simular una interrupción para probar la solución de caché de host local en un entorno. La guía sobre cómo forzar una interrupción está disponible en la documentación del producto. Al forzar una interrupción, tenga especial cuidado de establecer todos los conectores de una ubicación de recursos en el modo de interrupción forzada.