Caché de host local

La función Caché de host local (LHC) permite que la intermediación de las conexiones en una implementación de Citrix Virtual Apps and Desktops Service continúe cuando un Cloud Connector no se pueda comunicar con Citrix Cloud. La Caché de host local se activa después de que la conexión de red se haya perdido durante 20 segundos.

Con la Caché de host local, los usuarios que estén conectados cuando se produce una interrupción pueden seguir trabajando sin interrupciones. En las conexiones nuevas y las reconexiones se dan demoras mínimas de conexión.

Contenido de datos

La Caché de host local incluye la siguiente información, que es un subconjunto de la información contenida en la base de datos principal:

  • Identidades de los usuarios y los grupos que tienen derechos específicamente asignados a recursos publicados en el sitio.
  • Identidades de los usuarios que actualmente usan, o que han utilizado recientemente, recursos publicados en el sitio.
  • Identidades de las máquinas VDA (incluidas las máquinas de acceso con Remote PC) configuradas en el sitio.
  • Identidades (nombres y direcciones IP) de las máquinas cliente de la aplicación Citrix Workspace que se utilizan activamente para conectarse a los recursos publicados.

También contiene información para las conexiones actualmente activas que se establecieron mientras la base de datos principal no estaba disponible:

  • Resultados de todos los análisis de máquinas de punto final del cliente realizados por la aplicación Citrix Workspace.
  • Identidades de las máquinas de la infraestructura (tales como Citrix Gateway y servidores StoreFront) que intervienen en las operaciones del sitio.
  • Fechas, horas y tipos de actividades recientes de los usuarios.

Funcionamiento

Durante el funcionamiento habitual:

Imagen de funcionamiento normal

  • El broker principal (Citrix Remote Broker Provider Service) en un Cloud Connector acepta las solicitudes de conexión provenientes de StoreFront, y se comunica con Citrix Cloud para conectar usuarios a los agentes VDA que están registrados en el Cloud Connector.
  • El servicio Citrix Config Synchronizer Service (CSS) se comunica con el broker de Citrix Cloud aproximadamente cada dos minutos para comprobar si se han hecho cambios de configuración. Esos cambios pueden haberse iniciado por la acción de un administrador (si modifica una propiedad del grupo de entrega, por ejemplo) o por acciones del sistema (como las asignaciones de máquinas).
  • Si se ha producido un cambio de configuración desde la comprobación anterior, CSS sincroniza la información (la copia) a un broker secundario (Citrix High Availability Service, HA broker en la imagen anterior) presente en el Cloud Connector. Se copian todos los datos de la configuración, no solo los elementos que hayan cambiado desde la comprobación anterior. El broker secundario importa los datos en una base de datos LocalDB de Microsoft SQL Server Express ubicada en el Cloud Connector. El servicio CSS comprueba que la información de la base de datos LocalDB que presenta el broker secundario coincide con la información que hay en la base de datos del sitio en Citrix Cloud. La base de datos LocalDB se crea con cada sincronización.

La base de datos LocalDB se instala automáticamente cuando se instala un Cloud Connector. Esa base de datos no se puede compartir entre los Cloud Connectors. No es necesario hacer copias de seguridad de esta base de datos; se vuelve a crear cada vez que se detecta un cambio de configuración.

  • Si no se han producido cambios desde la última comprobación, no se copian los datos de configuración.

Durante una interrupción:

Imagen de interrupción de servicio

Cuando empieza una interrupción:

  • El broker secundario comienza a escuchar y a procesar las solicitudes de conexión.
  • Cuando empieza la interrupción, el broker secundario no dispone de datos actuales de registro de agentes VDA, pero, en cuanto un VDA se comunica con él, comienza un proceso de registro. Durante este proceso, el broker secundario también obtiene información de sesión actualizada acerca de ese VDA.
  • Mientras el broker secundario gestiona las conexiones, el broker principal sigue supervisando la conexión a Citrix Cloud. Cuando se restaura la conexión, el broker principal indica al secundario que deje de escuchar para obtener la información de conexión. A continuación, el broker principal reanuda la intermediación. La próxima vez que el VDA se comunica con el broker principal, comienza un proceso de registro. El broker secundario elimina los registros de VDA restantes desde 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.

En el caso improbable de que se inicie una interrupción durante una sincronización, la importación de ese momento se descarta y se utiliza la última configuración conocida.

El registro de eventos indica cuándo tienen lugar las sincronizaciones y las interrupciones.

No hay límites de tiempo impuestos para el funcionamiento en modo de interrupción.

También puede desencadenar intencionadamente una interrupción. Consulte Forzar una interrupción para obtener más información sobre cómo y por qué hacerlo.

Ubicaciones de recursos (zonas satélite) con varios Cloud Connectors

Entre otras de sus tareas, CSS proporciona constantemente al broker secundario información sobre todos los Cloud Connectors de la ubicación de recursos. Con esta información, cada broker secundario sabe cuáles son todos los demás brokers secundarios.

Los brokers secundarios se comunican entre sí por un canal independiente. Utilizan una lista alfabética de nombres de dominio completo (FQDN) de las máquinas que están ejecutando para determinar (elegir) al broker secundario que estará a cargo de intermediar las operaciones de la zona si se produce una interrupción. Durante la interrupción, todos los VDA vuelven a registrarse en el broker secundario que se haya elegido. Los brokers secundarios de la zona que no hayan sido elegidos rechazarán las solicitudes entrantes de conexión y de registro que les envíen los agentes 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 una interrupción, si se reinicia un Cloud Connector:

  • Si ese Cloud Connector no es el broker principal elegido, el reinicio no tiene repercusión.
  • Si ese Cloud Connector sí es el broker principal elegido, se elegirá otro Cloud Connector y los VDA deberán registrarse en él. 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.

Requisitos y consideraciones de diseño

No hay límites de tiempo impuestos para el funcionamiento en modo de interrupción. Sin embargo, si la interrupción se debe a la pérdida local de la conectividad de Citrix Cloud con su ubicación de recursos, los clientes deben restaurar la conectividad de la ubicación de recursos afectada lo más rápido posible.

Lo que no está disponible durante una interrupción y otras diferencias

  • No puede usar Studio ni ejecutar cmdlets de PowerShell.
  • Los datos de supervisión no se envían a Citrix Cloud durante una interrupción. Por lo tanto, las funciones de supervisión (Director) no mostrarán actividad de un intervalo de interrupción.
  • Host Service no puede proporcionar credenciales de hipervisor. Todas las máquinas están en el estado de energía desconocido (unknown) y no se pueden emitir operaciones de administración de energía. No obstante, las máquinas virtuales del host que estén encendidas se pueden utilizar para las solicitudes de conexión.
  • Una máquina asignada solo se puede usar si la asignación se dio durante el funcionamiento normal. No se pueden realizar asignaciones nuevas durante una interrupción.
  • No se puede configurar ni inscribir automáticamente las máquinas de acceso con Remote PC. En cambio, las máquinas que se inscribieron y configuraron durante el funcionamiento normal se pueden usar.
  • Si los recursos están en zonas diferentes, es posible que los usuarios de aplicaciones y escritorios alojados en servidor superen la cantidad de sesiones indicadas en el límite configurado de sesiones.
  • Los usuarios solo pueden iniciar aplicaciones y escritorios desde los VDA registrados en la zona que contiene el High Availability Service actualmente activo o elegido. Durante una interrupción, no se admiten inicios entre zonas (desde un High Availability Service de una zona en un VDA de otra zona).

El caché de host local solo funciona con StoreFront implementado por el cliente. No funciona con el espacio de trabajo.

La función “Caché de host local” se admite para aplicaciones y escritorios alojados en servidores y escritorios estáticos (asignados).

De forma predeterminada, los escritorios VDA con la energía administrada que formen parte de grupos de entrega agrupados (creados con MCS o Citrix Provisioning) que tengan habilitada la propiedad ShutdownDesktopsAfterUse se colocan en el modo de mantenimiento cuando ocurre una interrupción. Puede cambiar este comportamiento predeterminado y permitir que esos escritorios se utilicen durante una interrupción. Sin embargo, no podrá confiar en la administración de energía durante la interrupción. (La administración de energía se reanuda una vez reanudadas las operaciones normales.) Además, esos escritorios podrían contener datos del usuario anterior, porque no ha sido reiniciados.

Para reemplazar el comportamiento predeterminado, debe estar habilitado en todo el sitio y para cada grupo de entrega afectado. Realice una llamada de asistencia para habilitarlo en todo el sitio (este comando no se puede ejecutar con el Remote PowerShell SDK).

Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

Para cada grupo de entrega afectado, ejecute el siguiente cmdlet de PowerShell.

Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true

Habilitar esta característica en el sitio y los grupos de entrega no afecta al funcionamiento de la propiedad configurada ShutdownDesktopsAfterUse durante las operaciones normales.

Consideraciones sobre tamaño de RAM

El servicio LocalDB puede usar aproximadamente 1,2 GB de RAM (1 GB máximo para la caché de la base de datos, más 200 MB para ejecutar LocalDB de SQL Server Express). El servicio High Availability Service puede usar hasta 1 GB de RAM si la interrupción es duradera y se producen muchos inicios de sesión (por ejemplo, 12 horas con 10 000 usuarios). Estos requisitos de memoria son adicionales a los requisitos de memoria RAM habituales para el Cloud Connector. Por lo tanto, es posible que necesite aumentar la cantidad total de RAM.

Consideraciones sobre la configuración de sockets y núcleo de CPU

La configuración de la CPU de un Cloud Connector, especialmente la cantidad de núcleos disponibles para la base de datos LocalDB de SQL Server Express, afecta directamente al rendimiento que tendrá la Caché de host local, incluso más que la asignación de memoria. Este consumo de recursos de CPU solo se ha observado durante el periodo de interrupción cuando la base de datos no está disponible y el servicio High Availability Service está activo.

A pesar de que LocalDB pueda usar varios núcleos (hasta 4), está limitada a solamente un socket. Agregar más sockets no mejora el rendimiento (por ejemplo, tener 4 sockets con 1 núcleo cada uno). En vez de ello, Citrix recomienda usar varios sockets con varios núcleos. En las pruebas llevadas a cabo por Citrix, una configuración de 2x3 (2 sockets, 3 núcleos) proporciona un mejor rendimiento que las configuraciones 4x1 y 6x1.

Consideraciones sobre almacenamiento

LocalDB aumenta de tamaño a medida que los usuarios acceden a los recursos durante una interrupción. Por ejemplo, durante una prueba de inicio y cierre de sesión en la que se ejecutan 10 inicios de sesión por segundo, la base de datos aumentó de tamaño 1 MB cada 2 o 3 minutos. Cuando se reanuda el funcionamiento normal, se vuelve a crear la base de datos local cuando se detecta un cambio de configuración. No obstante, el intermediario (broker) debe tener suficiente espacio en la unidad donde está instalada LocalDB para permitir el cambio de tamaño de la base de datos durante una interrupción. La Caché de host local también conlleva E/S adicional durante una interrupción: aproximadamente 3 MB de escrituras por segundo, con varios cientos de miles de lecturas.

Consideraciones sobre rendimiento

Durante una interrupción, un solo broker se encarga de todas las conexiones. En las ubicaciones de recursos con carga equilibrada entre varios Cloud Connectors durante el funcionamiento normal, puede que el broker elegido deba gestionar muchas más solicitudes durante una interrupción que en una situación normal. Por lo tanto, el consumo necesario de CPU es mucho mayor. Todos los brokers de la ubicación de recursos deben ser capaces de gestionar la carga adicional que imponen LocalDB y todos los VDA afectados, porque el broker elegido durante una interrupción podría cambiar.

Límites de VDI:

  • En una implementación con una sola ubicación de recursos, se pueden gestionar hasta 10 000 agentes VDA durante una interrupción.
  • En una implementación de VDI con varias ubicaciones de recursos, se puede gestionar un máximo de 10 000 agentes VDA por ubicación durante una interrupción, y hasta 40 000 agentes VDA en la implementación. Por ejemplo, cada una de las siguientes implementaciones puede gestionarse de forma eficaz durante una interrupción:
    • Una implementación con cuatro ubicaciones de recursos secundarias, cada una con 10 000 agentes VDA.
    • Una implementación con siete zonas secundarias, una zona con 10 000 agentes VDA y seis zonas con 5000 agentes VDA.

Durante una interrupción, la administración de carga puede verse afectada. Es posible que se superen los patrones de carga (especialmente, las reglas de recuento de sesiones).

Mientras todos los VDA se registran en un broker, este puede no disponer de información completa sobre las sesiones actuales. Por lo tanto, si un usuario solicita conectarse durante ese intervalo, puede que se cree una nueva sesión aunque la reconexión a una sesión existente fuera posible. Este intervalo (mientras el nuevo broker obtiene la información de sesión de todos los VDA durante el registro) no se puede evitar. Tenga en cuenta que las sesiones que están conectadas cuando se inicia una interrupción no se verán afectadas durante ese intervalo de transición, pero las sesiones nuevas y las reconexiones sí pueden verse afectadas.

Este intervalo se da siempre que los VDA deben registrarse en otro broker:

  • Comienza una interrupción: Al migrar desde un broker principal a un broker secundario.
  • Fallo de broker durante una interrupción: Al migrar desde un broker secundario en que se produjo el fallo a otro broker secundario que acaba de elegirse.
  • Recuperación de una interrupción: Cuando se reanudan las operaciones normales y el broker principal retoma el control.

El tiempo que tarda la sincronización entre brokers aumenta con la cantidad de objetos (como agentes VDA, aplicaciones, grupos). Por ejemplo, sincronizar 5000 agentes VDA podría llevar diez minutos o más.

Requisito de StoreFront

Importante:

Cada zona satélite (ubicación de recursos) debe tener un StoreFront local (“on-premises”) instalado y configurado. (La función de caché de host local funciona solo en ubicaciones de recursos que contienen un StoreFront local).

Diferencias con versiones de XenApp 6.x

Aunque esta implementación de Caché de host local comparte el nombre con la funcionalidad Caché de host local de XenApp 6.x y versiones anteriores de XenApp, existen entre ellas diferencias importantes. Esta implementación es más sólida e inmune al daño. Los requisitos de mantenimiento se han minimizado; por ejemplo, se ha eliminado la necesidad de comandos dsmaint periódicos. Técnicamente, esta implementación de Caché de host local es completamente diferente.

Administración de la Caché de host local

La función Caché de host local está siempre habilitada en una implementación de Citrix Virtual Apps and Desktops Service. No es necesario hacer nada más para configurarla ni administrarla.

Como se ha mencionado anteriormente, la base de datos LocalDB se instala automáticamente cuando se instala un Cloud Connector en una ubicación de recursos. No intente inhabilitarla ni quitarla. (Citrix actualiza regularmente el Cloud Connector. Si inhabilita o quita el software de LocalDB manualmente, la próxima actualización de Cloud Connector lo reemplazará.)

Verificar que la Caché de host local está funcionando

Para verificar que la Caché de host local está configurada y funciona correctamente:

  • Verifique que la ubicación de recursos contiene un StoreFront local que apunta a los Cloud Connectors que se encuentran en esa ubicación de recursos.
  • Compruebe que las importaciones de sincronización se completan correctamente. Verifique los registros de eventos.
  • Compruebe que LocalDB de SQL Server se haya creado en cada Cloud Connector. Eso confirma que el servicio de alta disponibilidad High Availability Service puede tomar el control, si fuera necesario.
    • En el servidor de Cloud Connector, vaya a c:\Windows\ServiceProfiles\NetworkService\
    • Verifique que se hayan creado HaDatabaseName.mdf y HaDatabaseName_logldf
  • Fuerce una interrupción en todos los Cloud Connectors de la ubicación de recursos. Una vez que haya verificado que la Caché de host local funciona, recuerde volver a colocar todos los Cloud Connectors de nuevo en el modo normal. Este proceso puede tardar aproximadamente 15 minutos y, gracias a él, se evitan avalanchas de registros de VDA.

Consulte también Consideraciones de escalabilidad para usar Caché de host local con Cloud Connectors.

Registros de eventos

Los registros de eventos indican cuándo tienen lugar las sincronizaciones y las interrupciones.

Config Synchronizer Service:

Durante el funcionamiento normal, pueden ocurrir los siguientes eventos cuando CSS copia, exporta la configuración del broker y la importa a la LocalDB mediante High Availability Service (broker secundario).

  • 503: Citrix Config Sync Service recibió una configuración actualizada. Este evento ocurre cada vez que el servicio High Availability Service recibe una configuración actualizada de Citrix Cloud. Indica el inicio del proceso de sincronización. Un evento 504 o 505 siempre sigue a este evento.
  • 504: Citrix Config Sync Service importó una configuración actualizada. La importación de la configuración se completó correctamente.
  • 505: Falló una importación de Citrix Config Sync Service. La importación de la configuración no se completó correctamente. Si hay una configuración previa disponible, se usará si ocurre una interrupción. Sin embargo, estará desactualizada frente a la configuración actual. Si no hay ninguna configuración previa disponible, el servicio no puede participar en la intermediación de sesiones durante una interrupción. En este caso, consulte la sección Solucionar problemas y póngase en contacto con la asistencia de Citrix.
  • 507: Citrix Config Sync Service abandonó una importación porque el sistema está en modo de detención y la caché de host local se está utilizando para la intermediación de broker. El servicio recibió una nueva configuración, pero la importación fue abandonada debido a una interrupción. Este es el comportamiento esperado.

High Availability Service (Servicio de alta disponibilidad):

  • 3502: Se ha producido una interrupción y el broker secundario (High Availability Service) está llevando a cabo operaciones de intermediación.
  • 3503: Se ha resuelto una interrupción y se ha reanudado el funcionamiento normal.
  • 3504: Indica el broker secundario elegido, además de otros brokers que hayan participado en la elección.

Forzar una interrupción

Puede que quiera forzar deliberadamente una interrupción.

  • Si la red tiene altibajos repetidos. Forzar una interrupción hasta que se resuelvan los problemas de red impide una transición continua entre los modos normal y de interrupción (con los registros frecuentes de VDA que ello conlleva).
  • Para probar un plan de recuperación ante desastres.
  • Para comprobar que la Caché de host local funciona correctamente.

Para forzar una interrupción, modifique el Registro de cada servidor de Cloud Connector. En HKLM\Software\Citrix\DesktopServer\LHC, establezca OutageModeForced en 1. Eso indica al broker que se coloque en el modo de interrupción, independientemente del estado de la conexión a Citrix Cloud. Establecer este valor en 0 saca al servidor del modo de interrupción.

Solucionar problemas

Existen varias herramientas de solución de problemas disponibles cuando falla una importación de sincronización a la LocalDB y se publica un evento 505.

Seguimiento CDF: Contiene opciones para los módulos ConfigSyncServer y BrokerLHC. Esas opciones, junto con otros módulos de broker, pueden identificar el problema.

Informe: Si falla una importación de sincronización, puede generar un informe. Este informe se detiene en el objeto que causa el error. Esta funcionalidad de informe afecta a la velocidad de sincronización, por lo que Citrix recomienda inhabilitarla cuando no se use.

Para habilitar y generar un informe de seguimiento de CSS, escriba el comando:

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1

El informe HTML se publica en: C:\Windows\ServiceProfiles\NetworkService\ AppData\Local\Temp\CitrixBrokerConfigSyncReport.html

Una vez generado el informe, introduzca el siguiente comando para inhabilitar la funcionalidad de informes:

Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0