Caché de host local
Para garantizar que la base de datos del sitio de XenApp y XenDesktop esté siempre disponible, Citrix recomienda empezar con una implementación de SQL Server tolerante a fallos, siguiendo las prácticas recomendadas de alta disponibilidad de Microsoft. (La sección Bases de datos del artículo Requisitos del sistema enumera las funciones de alta disponibilidad de SQL Server compatibles con XenApp y XenDesktop). Sin embargo, los problemas e interrupciones de la red pueden impedir que los usuarios se conecten a sus aplicaciones o escritorios.
La función Caché de host local (LHC) permite que las operaciones de intermediación de conexiones en un sitio de XenApp o XenDesktop continúen cuando se produce una interrupción. Una interrupción se produce cuando falla la conexión entre un Delivery Controller™ y la base de datos del sitio. La caché de host local se activa cuando la base de datos del sitio es inaccesible durante 90 segundos.
La caché de host local es la función de alta disponibilidad más completa de XenApp y XenDesktop. Es una alternativa más potente a la función de concesión de conexiones que se introdujo en XenApp 7.6.
Aunque esta implementación de la caché de host local comparte el nombre de la función de caché de host local en XenApp 6.x y versiones anteriores de XenApp, existen mejoras significativas. Esta implementación es más robusta e inmune a la corrupción. Los requisitos de mantenimiento se minimizan, como la eliminación de la necesidad de comandos dsmaint periódicos. Esta caché de host local es una implementación técnicamente diferente; siga leyendo para saber cómo funciona.
Nota:
Aunque la concesión de conexiones es compatible con la versión 7.15 LTSR, se eliminará en la siguiente versión.
Contenido de los datos
La caché de host local incluye la siguiente información, que es un subconjunto de la información de la base de datos principal:
- Identidades de usuarios y grupos a los que se asignan específicamente derechos a los recursos publicados desde el sitio.
- Identidades de usuarios que están utilizando actualmente, o que han utilizado recientemente, recursos publicados desde el sitio.
- Identidades de máquinas VDA (incluidas las máquinas de acceso remoto a PC) configuradas en el sitio.
- Identidades (nombres y direcciones IP) de las máquinas cliente de Citrix Receiver™ que se utilizan activamente para conectarse a los recursos publicados.
También contiene información para las conexiones activas actuales que se establecieron mientras la base de datos principal no estaba disponible:
- Resultados de cualquier análisis de punto final de máquina cliente realizado por Citrix Receiver.
- Identidades de las máquinas de infraestructura (como los servidores NetScaler Gateway y StoreFront™) implicadas en el sitio.
- Fechas, horas y tipos de actividad reciente de los usuarios.
Cómo funciona
El siguiente gráfico ilustra los componentes de Local Host Cache y las rutas de comunicación durante las operaciones normales.
Durante las operaciones normales:
- El broker principal (Citrix Broker Service) de un Controller acepta las solicitudes de conexión de StoreFront y se comunica con la base de datos del sitio para conectar a los usuarios con los VDA registrados en el Controller.
- Cada dos minutos se comprueba si se han realizado cambios en la configuración del broker principal. Esos cambios pueden haber sido iniciados por acciones de PowerShell/Studio (como cambiar una propiedad de un grupo de entrega) o acciones del sistema (como asignaciones de máquinas).
- Si se ha realizado un cambio desde la última comprobación, el broker principal utiliza el Citrix Config Synchronizer Service (CSS) para sincronizar (copiar) la información en un broker secundario (Citrix High Availability Service) del Controller. Se copian todos los datos de configuración del broker, no solo los elementos que han cambiado desde la comprobación anterior. El broker secundario importa los datos a una base de datos Microsoft SQL Server Express LocalDB en el Controller. El CSS garantiza que la información de la base de datos LocalDB del broker secundario coincida con la información de la base de datos del sitio. La base de datos LocalDB se vuelve a crear cada vez que se produce una sincronización.
- Si no se han producido cambios desde la última comprobación, no se copian datos.
El siguiente gráfico ilustra los cambios en las rutas de comunicación si el broker principal pierde el contacto con la base de datos del sitio (comienza una interrupción):
Cuando comienza una interrupción:
- El broker principal ya no puede comunicarse con la base de datos del sitio y deja de escuchar la información de StoreFront y VDA (marcado con una X en el gráfico). A continuación, el broker principal indica al broker secundario (High Availability Service) que empiece a escuchar y procesar las solicitudes de conexión (marcado con una línea discontinua roja en el gráfico).
- Cuando comienza la interrupción, el broker secundario no tiene datos de registro de VDA actuales, pero tan pronto como un VDA se comunica con él, se activa un proceso de nuevo registro. Durante ese proceso, el broker secundario también obtiene información de sesión actual sobre ese VDA.
- Mientras el agente secundario gestiona las conexiones, el agente principal sigue supervisando la conexión con la base de datos del sitio. Cuando se restablece la conexión, el agente principal indica al agente secundario que deje de escuchar la información de conexión, y el agente principal reanuda las operaciones de intermediación. La próxima vez que un VDA se comunique con el agente principal, se activa un proceso de nuevo registro. El agente secundario elimina cualquier registro de VDA restante de la interrupción anterior y reanuda la actualización de la base de datos LocalDB con los cambios de configuración recibidos del CSS.
En el improbable caso de que se produzca una interrupción durante una sincronización, la importación actual se descarta y se utiliza la última configuración conocida.
El registro de eventos proporciona información sobre las sincronizaciones y las interrupciones. Consulte la sección “Supervisar” a continuación para obtener más detalles.
También puede provocar una interrupción intencionadamente; consulte la sección “Forzar una interrupción” a continuación para obtener más detalles sobre por qué y cómo hacerlo.
Sitios con varios Controllers
Entre otras tareas, el CSS proporciona rutinariamente al agente secundario información sobre todos los Controllers de la zona. (Si su implementación no contiene varias zonas, esta acción afecta a todos los Controllers del sitio). Con esa información, cada agente secundario conoce a todos los agentes secundarios del mismo nivel.
Los agentes secundarios se comunican entre sí en un canal independiente. Utilizan una lista alfabética de nombres FQDN de las máquinas en las que se ejecutan para determinar (elegir) qué agente secundario se encargará de las operaciones de intermediación en la zona si se produce una interrupción. Durante la interrupción, todos los VDA se vuelven a registrar con el agente secundario elegido. Los agentes secundarios no elegidos de la zona rechazarán activamente las solicitudes de conexión entrantes y de registro de VDA.
Si un agente secundario elegido falla durante una interrupción, se elige otro agente secundario para que tome el relevo, y los VDA se volverán a registrar con el agente secundario recién elegido.
Durante una interrupción, si se reinicia un Controller:
- Si ese Controller no es el agente principal elegido, el reinicio no tiene ningún impacto.
- Si ese Controller es el agente principal elegido, se elige un Controller diferente, lo que provoca que los VDA se vuelvan a registrar. Después de que el Controller reiniciado se encienda, asume automáticamente la intermediación, lo que provoca que los VDA se vuelvan a registrar. En este escenario, el rendimiento puede verse afectado durante los nuevos registros.
Si apaga un Controller durante las operaciones normales y luego lo enciende durante una interrupción, la caché de host local no se puede utilizar en ese Controller si es elegido como agente principal.
El registro de eventos proporciona información sobre las elecciones. Consulte la sección “Supervisar” a continuación.
Consideraciones y requisitos de diseño
La caché de host local es compatible con aplicaciones y escritorios alojados en servidor, y escritorios estáticos (asignados); no es compatible con escritorios VDI agrupados (creados por MCS o PVS).
No hay un límite de tiempo impuesto para operar en modo de interrupción. Sin embargo, restaure el sitio a su funcionamiento normal lo antes posible.
Qué no está disponible o cambia durante una interrupción:
- No puede usar Studio ni ejecutar cmdlets de PowerShell.
- Las credenciales del hipervisor no se pueden obtener del servicio de host. Todas las máquinas están en estado de energía desconocido y no se pueden emitir operaciones de energía. Sin embargo, las máquinas virtuales en el host que están encendidas se pueden usar para solicitudes de conexión.
- Una máquina asignada solo se puede usar si la asignación se realizó durante las operaciones normales. No se pueden realizar nuevas asignaciones durante una interrupción.
- La inscripción y configuración automáticas de las máquinas de acceso remoto a PC no son posibles. Sin embargo, las máquinas que se inscribieron y configuraron durante el funcionamiento normal son utilizables.
- Los usuarios de aplicaciones y escritorios alojados en servidores pueden usar más sesiones de las que permiten sus límites de sesión configurados, si los recursos se encuentran en zonas diferentes.
- Los usuarios solo pueden iniciar aplicaciones y escritorios desde VDAs registrados en la zona que contiene el agente (secundario) actualmente activo/elegido. Los lanzamientos entre zonas (desde un agente en una zona a un VDA en una zona diferente) no son compatibles durante una interrupción.
De forma predeterminada, los VDAs de escritorio con administración de energía en grupos de entrega agrupados que tienen la propiedad ShutdownDesktopsAfterUse habilitada se colocan en modo de mantenimiento cuando ocurre una interrupción. Puede cambiar este valor predeterminado para permitir que esos escritorios se usen durante una interrupción. Sin embargo, no puede depender de la administración de energía durante la interrupción. (La administración de energía se reanuda después de que se reanudan las operaciones normales). Además, esos escritorios pueden contener datos del usuario anterior, ya que no se han reiniciado.
Para anular el comportamiento predeterminado, debe habilitarlo en todo el sitio y para cada grupo de entrega afectado.
Para el sitio, ejecute el siguiente cmdlet de PowerShell:
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Para cada grupo de entrega afectado, ejecute el siguiente cmdlet de PowerShell:
Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true
La habilitación de esta función en el sitio y en los grupos de entrega no afecta la forma en que funciona la propiedad ShutdownDesktopsAfterUse configurada durante las operaciones normales.
Tamaño de la RAM:
El servicio LocalDB puede usar aproximadamente 1,2 GB de RAM (hasta 1 GB para la caché de la base de datos, más 200 MB para ejecutar SQL Server Express LocalDB). El servicio de alta disponibilidad puede usar hasta 1 GB de RAM si una interrupción dura un intervalo prolongado con muchos inicios de sesión (por ejemplo, 12 horas con 10 000 usuarios). Estos requisitos de memoria se suman a los requisitos de RAM normales para el Controller, por lo que es posible que deba aumentar la capacidad total de RAM.
Tenga en cuenta que si utiliza una instalación de SQL Server Express para la base de datos del sitio, el servidor tendrá dos procesos sqlserver.exe.
Configuración de núcleos de CPU y sockets:
La configuración de la CPU de un Controller, en particular el número de núcleos disponibles para SQL Server Express LocalDB, afecta directamente al rendimiento de Local Host Cache, incluso más que la asignación de memoria. Esta sobrecarga de CPU se observa solo durante el período de interrupción, cuando la base de datos no está disponible y el servicio de alta disponibilidad está activo.
Aunque LocalDB puede usar varios núcleos (hasta 4), está limitado a un solo socket. Agregar más sockets no mejorará el rendimiento (por ejemplo, tener 4 sockets con 1 núcleo cada uno). En su lugar, Citrix recomienda usar varios sockets con varios núcleos. En las pruebas de Citrix, una configuración de 2x3 (2 sockets, 3 núcleos) proporcionó un mejor rendimiento que las configuraciones de 4x1 y 6x1.
Almacenamiento:
A medida que los usuarios acceden a los recursos durante una interrupción, LocalDB crece. Por ejemplo, durante una prueba de inicio/cierre de sesión que se ejecuta a 10 inicios de sesión por segundo, la base de datos creció un MB cada 2-3 minutos. Cuando se reanuda el funcionamiento normal, la base de datos local se vuelve a crear y se recupera el espacio. Sin embargo, el broker debe tener suficiente espacio en la unidad donde está instalado LocalDB para permitir el crecimiento de la base de datos durante una interrupción. Local Host Cache también incurre en E/S adicionales durante una interrupción: aproximadamente 3 MB de escrituras por segundo, con varios cientos de miles de lecturas.
Rendimiento:
Durante una interrupción, un broker gestiona todas las conexiones, por lo que en los sitios (o zonas) que equilibran la carga entre varios Controllers durante las operaciones normales, el broker elegido podría tener que gestionar muchas más solicitudes de lo normal durante una interrupción. Por lo tanto, las demandas de CPU serán mayores. Cada broker del sitio (zona) debe poder gestionar la carga adicional impuesta por LocalDB y todos los VDA afectados, ya que el broker elegido durante una interrupción podría cambiar.
Límites de VDI:
- En una implementación de VDI de una sola zona, se pueden gestionar eficazmente hasta 10 000 VDA durante una interrupción.
- En una implementación de VDI multizona, se pueden gestionar eficazmente hasta 10 000 VDA en cada zona durante una interrupción, con un máximo de 40 000 VDA en el sitio. Por ejemplo, cada uno de los siguientes sitios se puede gestionar eficazmente durante una interrupción:
- Un sitio con cuatro zonas, cada una con 10 000 VDA.
- Un sitio con siete zonas, una con 10 000 VDA y seis con 5000 VDA cada una.
Durante una interrupción, la gestión de carga dentro del sitio puede verse afectada. Los evaluadores de carga (y especialmente las reglas de recuento de sesiones) pueden superarse.
Durante el tiempo que tardan todos los VDA en volver a registrarse con un broker, es posible que ese broker no tenga información completa sobre las sesiones actuales. Por lo tanto, una solicitud de conexión de usuario durante ese intervalo podría resultar en el inicio de una nueva sesión, aunque fuera posible la reconexión a una sesión existente. Este intervalo (mientras el broker “nuevo” adquiere información de la sesión de todos los VDA durante el nuevo registro) es inevitable. Tenga en cuenta que las sesiones que están conectadas cuando comienza una interrupción no se ven afectadas durante el intervalo de transición, pero las nuevas sesiones y las reconexiones de sesión sí podrían verse afectadas.
Este intervalo ocurre cada vez que los VDA deben volver a registrarse con un broker diferente:
- Comienza una interrupción: Al migrar de un broker principal a un broker secundario.
- Fallo del broker durante una interrupción: Al migrar de un broker secundario que falló a un broker secundario recién elegido.
- Recuperación de una interrupción: Cuando se reanudan las operaciones normales y el broker principal recupera el control.
Puede reducir el intervalo disminuyendo el valor del registro HeartbeatPeriodMs del Protocolo de broker de Citrix (valor predeterminado = 600000 ms, que son 10 minutos). Este valor de latido es el doble del intervalo que el VDA utiliza para los pings, por lo que el valor predeterminado da como resultado un ping cada 5 minutos.
Por ejemplo, el siguiente comando cambia el latido a cinco minutos (300000 milisegundos), lo que resulta en un ping cada 2,5 minutos:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
El intervalo no se puede eliminar por completo, por muy rápido que se registren los VDA.
El tiempo que tarda la sincronización entre brokers aumenta con el número de objetos (como VDA, aplicaciones, grupos). Por ejemplo, sincronizar 5000 VDA podría tardar diez minutos o más en completarse. Consulte la sección “Monitor” a continuación para obtener información sobre las entradas de sincronización en el registro de eventos.
Administrar la caché de host local
Para que la caché de host local funcione correctamente, la política de ejecución de PowerShell en cada Controller debe establecerse en RemoteSigned, Unrestricted o Bypass.
SQL Server Express LocalDB
La base de datos Microsoft SQL Server Express LocalDB que utiliza la caché de host local se instala automáticamente al instalar un Controller o al actualizar un Controller desde una versión anterior a la 7.9. No se necesita mantenimiento por parte del administrador para la LocalDB. Solo el broker secundario se comunica con esta base de datos; no se pueden usar cmdlets de PowerShell para cambiar nada de esta base de datos. La LocalDB no se puede compartir entre Controllers.
El software de base de datos SQL Server Express LocalDB se instala independientemente de si la caché de host local está habilitada.
Para evitar su instalación, instale o actualice el Controller utilizando el comando XenDesktopServerSetup.exe e incluya la opción /exclude “Local Host Cache Storage (LocalDB)”. Sin embargo, tenga en cuenta que la función de caché de host local no funcionará sin la base de datos, y no podrá utilizar una base de datos diferente con el agente secundario.
La instalación de esta base de datos LocalDB no afecta a la instalación de SQL Server Express para su uso como base de datos del sitio.
Configuración predeterminada después de la instalación y actualización de XenApp o XenDesktop®
Durante una nueva instalación de XenApp® y XenDesktop, la caché de host local está habilitada de forma predeterminada. (El arrendamiento de conexiones está deshabilitado de forma predeterminada).
Después de una actualización, la configuración de la caché de host local no cambia. Por ejemplo, si la caché de host local estaba habilitada en la versión anterior, permanece habilitada en la versión actualizada. Si la caché de host local estaba deshabilitada (o no era compatible) en la versión anterior, permanece deshabilitada en la versión actualizada.
Habilitar y deshabilitar la caché de host local
Para habilitar la caché de host local, introduzca:
Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false
Este cmdlet también deshabilita la función de arrendamiento de conexiones. No habilite la caché de host local y el arrendamiento de conexiones a la vez.
Para determinar si la caché de host local está habilitada, introduzca:
Get-BrokerSite
Compruebe que la propiedad LocalHostCacheEnabled sea True y que la propiedad ConnectionLeasingEnabled sea False.
Para deshabilitar la caché de host local (y habilitar el arrendamiento de conexiones), introduzca:
Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true
Verificar que la caché de host local funciona
Para verificar que la caché de host local está configurada y funciona correctamente:
- Asegúrese de que las importaciones de sincronización se completan correctamente. Compruebe los registros de eventos.
- Asegúrese de que la base de datos SQL Server Express LocalDB se creó en cada Delivery Controller. Esto confirma que el Servicio de alta disponibilidad puede tomar el control, si es necesario.
- En el servidor Delivery Controller, vaya a C:\Windows\ServiceProfiles\NetworkService.
- Verifique que se hayan creado HaDatabaseName.mdf y HaDatabaseName_log.ldf.
- Fuerce una interrupción en los Delivery Controllers. Después de verificar que la caché de host local funciona, recuerde volver a poner todos los Controllers en modo normal. Esto puede tardar aproximadamente 15 minutos, para evitar tormentas de registro de VDA.
Forzar una interrupción
Es posible que desee forzar deliberadamente una interrupción de la base de datos.
- Si su red se interrumpe y se restablece repetidamente. Forzar una interrupción hasta que se resuelvan los problemas de red evita la transición continua entre los modos normal y de interrupción.
- Para probar un plan de recuperación ante desastres.
- Mientras se reemplaza o se realiza el mantenimiento del servidor de la base de datos del sitio.
Para forzar una interrupción, edite el registro de cada servidor que contenga un Delivery Controller.
- En HKLM\Software\Citrix\DesktopServer\LHC, establezca OutageModeForced en 1. Esto indica al broker que entre en modo de interrupción, independientemente del estado de la base de datos. (Establecer el valor en 0 saca al servidor del modo de interrupción).
- En un escenario de Citrix Cloud™, el conector entra en modo de interrupción, independientemente del estado de la conexión al plano de control o a la zona principal.
Monitorizar
Los registros de eventos indican cuándo se producen sincronizaciones e interrupciones.
Servicio de sincronización de configuración:
Durante las operaciones normales, los siguientes eventos pueden ocurrir cuando el CSS copia y exporta la configuración del broker y la importa a la LocalDB utilizando el Servicio de alta disponibilidad (broker secundario).
- 503: Se encontró un cambio en la configuración del broker principal y se está iniciando una importación.
- 504: La configuración del broker se copió, exportó y luego se importó correctamente a la LocalDB.
- 505: Falló una importación a la LocalDB; consulte a continuación para obtener más información.
- 510: No se recibieron datos de configuración del Servicio de configuración principal.
- 517: Hubo un problema de comunicación con el Broker principal.
- 518: El script de sincronización de configuración se abortó porque el Broker secundario (Servicio de alta disponibilidad) no se está ejecutando.
Servicio de alta disponibilidad:
- 3502: Se produjo una interrupción y el broker secundario (Servicio de alta disponibilidad) está realizando operaciones de intermediación.
- 3503: Se ha resuelto una interrupción y se han reanudado las operaciones normales.
- 3504: Indica qué broker secundario ha sido elegido, además de otros brokers implicados en la elección.
Solucionar problemas
Hay varias herramientas de solución de problemas disponibles cuando falla una importación de sincronización a LocalDB y se publica un evento 505.
Rastreo CDF: Contiene opciones para los módulos ConfigSyncServer y BrokerLHC. Esas opciones, junto con otros módulos de broker, probablemente identificarán 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 función de informe afecta a la velocidad de sincronización, por lo que Citrix recomienda deshabilitarla cuando no se utilice.
Para habilitar y generar un informe de rastreo CSS, introduzca el siguiente 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 función de informes:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Exportar la configuración del broker: Proporciona la configuración exacta para fines de depuración.
Export-BrokerConfiguration | Out-File file-pathname
Por ejemplo, Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.
En este artículo
- Contenido de los datos
- Cómo funciona
- Sitios con varios Controllers
- Consideraciones y requisitos de diseño
- Administrar la caché de host local
- SQL Server Express LocalDB
- Configuración predeterminada después de la instalación y actualización de XenApp o XenDesktop®
- Habilitar y deshabilitar la caché de host local
- Verificar que la caché de host local funciona
- Forzar una interrupción
- Monitorizar
- Solucionar problemas