Caché de host local
Para que la base de datos del sitio de Citrix Virtual Apps and Desktops esté siempre disponible, Citrix recomienda empezar con una implementación de SQL Server con tolerancia a fallos que resulta de las prácticas recomendadas para la alta disponibilidad de Microsoft (Para ver las funcionalidades de alta disponibilidad de SQL Server que se admiten, consulte Bases de datos.) Sin embargo, las interrupciones y los problemas de red pueden tener como resultado que los usuarios no puedan conectarse a sus aplicaciones o escritorios.
La función Caché de host local (LHC) permite que las operaciones de intermediación (broker) de las conexiones en un sitio continúen cuando se produce una interrupción. Se produce una interrupción cuando se interrumpe la conexión entre un Delivery Controller y la base de datos del sitio en un entorno local de Citrix. La función Caché de host local se activa cuando no se puede acceder a la base de datos del sitio durante 90 segundos.
A partir XenApp y XenDesktop 7.16, la Concesión de conexiones (una función de alta disponibilidad en versiones anteriores) se eliminó de XenApp y XenDesktop, y ya no está disponible.
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 Citrix Receiver 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 Citrix Receiver.
- Identidades de las máquinas de la infraestructura (tales como NetScaler Gateway y servidores de StoreFront) que intervienen en las operaciones del sitio.
- Fechas, horas y tipos de actividades recientes de los usuarios.
Funcionamiento
En el siguiente gráfico, se muestran los componentes de Caché de host local y las rutas de comunicación que se establecen durante un funcionamiento normal.
Durante el funcionamiento habitual:
- El broker principal (Citrix Broker Service) en un Controller acepta las solicitudes de conexión provenientes de StoreFront, y se comunica con la base de datos del sitio para conectar usuarios a los agentes VDA que están registrados en el Controller.
- Se comprueba periódicamente (un minuto después de la comprobación anterior) si se han realizado cambios en la configuración del broker principal. Esos cambios pueden haberse iniciado con acciones de PowerShell, de Studio (como modificar una propiedad del grupo de entrega) o del sistema (como las asignaciones de máquinas).
- Si se ha realizado algún cambio desde la última comprobación, el servicio Citrix Config Synchronizer Service (CSS) sincroniza (copia) información al servicio Citrix High Availability Service ubicado en el Controller (en parte de la documentación, el servicio High Availability Service se denomina broker secundario). Se copian todos los datos de configuración del broker, no solo los elementos que han cambiado desde la comprobación anterior. El servicio High Availability Service importa los datos en una base de datos LocalDB de Microsoft SQL Server Express ubicada en el Controller. El servicio CSS comprueba que la información de la base de datos LocalDB coincide con la información que hay en la base de datos del sitio. La base de datos LocalDB se crea con cada sincronización.
- Si no se han producido cambios desde la última comprobación, no se copian los datos.
En el siguiente gráfico, se muestran los cambios que se realizan en las rutas de comunicación si se interrumpe la conexión entre el broker principal y la base de datos del sitio:
Al principio de una interrupción del servicio:
- El broker principal ya no puede comunicarse con la base de datos del sitio y deja de escuchar para obtener información de StoreFront y VDA (marcado con una X en el gráfico). El broker principal indica al servicio High Availability Service que empiece a escuchar y a procesar solicitudes de conexión (marcado con una línea discontinua de color rojo en el gráfico). El servicio High Availability Service descarta todas las llamadas provenientes del CSS.
- Cuando empieza la interrupción, el servicio High Availability Service no dispone de datos actuales de registro de agentes VDA, pero, en cuanto un VDA se comunica con él, comienza un proceso de rerregistro. Durante este proceso, el servicio High Availability Service también obtiene información de sesión actualizada acerca de ese VDA.
- Mientras el servicio High Availability Service gestiona las conexiones, el broker principal sigue supervisando la conexión a la base de datos del sitio. Cuando se restaura la conexión, el broker principal indica al High Availability Service 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 rerregistro. El servicio High Availability Service elimina toda información de registro de VDA que haya quedado de la interrupción anterior, y vuelve a actualizar la base de datos LocalDB con los cambios de configuración que ha recibido del servicio CSS.
La transición entre el modo normal y de interrupción no afecta a las sesiones existentes; solo afecta al inicio de sesiones nuevas.
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 proporciona información sobre sincronizaciones e interrupciones del servicio. Consulte la siguiente sección “Supervisar” para obtener más información.
También puede empezar intencionadamente una interrupción; consulte la siguiente sección “Forzar una interrupción” para obtener más información sobre cómo y por qué hacerlo.
Sitios con varios Controllers
Entre otras de sus tareas, CSS proporciona constantemente al servicio High Availability Service información sobre todos los Controllers de la zona (si su entorno no contiene varias zonas, esta acción afecta a todos los Controllers del sitio). Con esta información, cada High Availability Service obtiene datos de todos los demás servicios High Availability Service de su nivel.
Los servicios High Availability Service 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 High Availability Service 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 High Availability Service que se haya elegido. Los servicios High Availability Service 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 High Availability Service falla durante una interrupción, se elige otro High Availability Service para tomar el control, y los VDA se volverán a registrar en el High Availability Service recién 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 caso, el rendimiento puede verse afectado durante los nuevos registros.
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.
El registro de eventos proporciona información sobre las opciones elegidas. Consulte la sección siguiente “Supervisión”.
Requisitos y consideraciones de diseño
No hay límites de tiempo impuestos para el funcionamiento en modo de interrupción. Sin embargo, debe restaurar el sitio a su funcionamiento normal lo más rápidamente posible.
Lo que no está disponible durante una interrupción y otras diferencias
- No puede usar Studio ni ejecutar cmdlets de PowerShell.
- 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 del servicio.
- 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).
- Si se produce una interrupción de la base de datos del sitio antes de que comience un reinicio programado para los agentes VDA de un grupo de entrega, los reinicios comienzan cuando finaliza la interrupción del servicio. Esto puede provocar resultados inesperados. Para obtener más información, consulte Reinicios programados que se retrasan por una interrupción de la base de datos.
- Las restricciones por etiquetas en las que se utilizan etiquetas para designar zonas no se admiten para el inicio de sesiones. Cuando se configuran tales restricciones por etiquetas y la opción de comprobación avanzada de estado de un almacén de StoreFront está habilitada, es posible que las sesiones no consigan iniciarse de forma intermitente.
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 VDA de escritorio con administración de energía en grupos de entrega agrupados (creados por MCS o Citrix Provisioning) que tienen la propiedad ShutdownDesktopsAfterUse habilitada no están disponibles para nuevas conexiones durante eventos de caché de host local. Puede cambiar este valor predeterminado para permitir que esos escritorios se usen durante la caché de host local. 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 se han reiniciado.
Para reemplazar el comportamiento predeterminado, debe habilitarlo en todo el sitio y para cada grupo de entrega afectado. Ejecute los siguientes cmdlets de PowerShell.
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
Habilitar esta función en el sitio y los grupos de entrega no afecta al funcionamiento de la propiedad configurada “ShutdownDesktopsAfterUse” durante las operaciones normales.
Importante:
Si no se habilitan ReuseMachinesWithoutShutdownInOutageAllowed al nivel del sitio ni ReuseMachinesWithoutShutdownInOutage al nivel del grupo de entrega, no se podrán iniciar sesiones en los VDA de escritorio con administración de energía desde grupos de entrega agrupados durante eventos de caché de host local.
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 Controller. Por lo tanto, es posible que necesite aumentar la cantidad total de RAM.
Tenga en cuenta que, si usa una base de datos de SQL Server Express como la base de datos del sitio, el servidor tendrá dos procesos sqlserver.exe.
Consideraciones sobre la configuración de sockets y núcleo de CPU
La configuración de la CPU de un Controller, 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 mejorará 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, la base de datos local se vuelve a crear y el espacio se devuelve. No obstante, debe haber suficiente espacio en la unidad donde está instalada LocalDB para permitir el aumento del 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 High Availability Service se encarga de todas las conexiones, por lo que, en los sitios (o las zonas) con carga equilibrada entre varios Controllers durante el funcionamiento normal, es posible que el High Availability Service elegido deba gestionar muchas más solicitudes durante una interrupción que en una situación normal. Por lo tanto, la necesidad de CPU será mucho mayor. Cada High Availability Service del sitio (zona) debe ser capaz de gestionar la carga adicional que impone LocalDB y todos los VDA afectados porque el High Availability Service elegido durante una interrupción podría cambiar.
Límites de VDI:
- En una implementación de VDI de zona única, se puede controlar hasta 10 000 agentes VDA durante una interrupción.
- En una implementación de VDI de varias zonas, se puede controlar hasta 10 000 agentes VDA por zona durante una interrupción, hasta un máximo de 40 000 agentes VDA en el sitio. Por ejemplo: cada uno de los siguientes sitios puede controlarse de forma eficaz durante una interrupción:
- Un sitio de cuatro zonas, cada zona con 10 000 agentes VDA.
- Un sitio con siete zonas, una zona con 10 000 agentes VDA y seis zonas con 5000 agentes VDA.
Durante una interrupción, la administración de carga dentro del sitio puede verse afectada. Es posible que se superen los patrones de carga (especialmente, las reglas de recuento de sesiones).
Mientras todos los VDA vuelven a registrarse en un High Availability Service, 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 inicie otra sesión, aunque la reconexión a una sesión existente fuera posible. Este intervalo (mientras el “nuevo” High Availability Service obtiene la información de sesión de todos los VDA durante el proceso de rerregistro) 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 volver a registrarse:
- Comienza una interrupción: Al migrar desde un broker principal a un High Availability Service.
- Fallo del servicio High Availability Service durante una interrupción: Al migrar desde un servicio High Availability Service que falló al servicio High Availability Service recién elegido.
- Recuperación de una interrupción: Cuando se reanudan las operaciones normales y el broker principal retoma el control.
Puede reducir el intervalo si disminuye el valor de Registro HeartbeatPeriodMs del protocolo del broker de Citrix (el valor predeterminado es 600 000 ms, que equivale a 10 minutos). Este valor de latido es el doble del intervalo que usa el VDA para los pings, por lo que el valor predeterminado da como resultado un ping cada 5 minutos.
Por ejemplo: este comando cambia el latido a cinco minutos (300 000 milisegundos), lo que resulta en un ping cada 2 minutos y medio:
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs -PropertyType DWORD –Value 300000
Tenga cuidado al cambiar el valor de latido. Aumentar la frecuencia resulta en una mayor carga en los Controllers durante los modos de funcionamiento normal y el de interrupción.
El intervalo no se puede eliminar por completo, independientemente de lo rápido que se registren los VDA.
El tiempo que tarda la sincronización entre servicios High Availability Service aumenta con la cantidad de objetos (como agentes VDA, aplicaciones, grupos). Por ejemplo, sincronizar 5000 VDA podría llevar diez minutos o más. Consulte Supervisión para obtener información sobre las entradas de sincronización en el registro de eventos.
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.
Administrar la Caché de host local
Para que la “Caché de host local” funcione correctamente, la directiva de ejecución de PowerShell en cada Controller debe establecerse en RemoteSigned, Unrestricted o Bypass.
LocalDB de SQL Server Express
La base de datos LocalDB de Microsoft SQL Server Express que usa la Caché de host local se instala automáticamente al instalar un Controller o actualizarlo desde una versión anterior a 7.9. No se necesita mantenimiento de administrador para la LocalDB. Only the High Availability Service communicates with this database. No puede usar cmdlets de PowerShell para realizar ningún cambio en esta base de datos. La LocalDB no se puede compartir entre los Controllers.
La base de datos LocalDB de SQL Server Express se instala independientemente de si la Caché de host local está habilitada.
Para impedir la instalación, instale o actualice el Controller con el comando XenDesktopServerSetup.exe e incluya la opción /exclude "Local Host Cache Storage (LocalDB)". No obstante, tenga en cuenta que la función “Caché de host local” no funcionará sin la base de datos, y no se puede usar otra base de datos con el servicio High Availability Service.
Instalar esta base de datos LocalDB no influye en si instala SQL Server Express para usarla como la base de datos del sitio.
Para obtener información sobre cómo reemplazar una versión anterior de SQL Server Express LocalDB por una versión más reciente, consulte Reemplazar SQL Server Express LocalDB.
Parámetros predeterminados después de la instalación y la actualización de los productos
La Caché de host local se habilita durante una nueva instalación de Citrix Virtual Apps and Desktops (7.16 como versión mínima). Después de una actualización (a la versión 7.16 o posterior), la Caché de host local se habilita si hay menos de 10 000 agentes VDA en toda la implementación.
Habilitar o inhabilitar la Caché de host local
-
Para habilitar la Caché de host local, escriba:
Set-BrokerSite -LocalHostCacheEnabled $truePara saber si la Caché de host local está habilitada, escriba:
Get-BrokerSiteCompruebe que la propiedad LocalHostCacheEnabled es True.
-
Para inhabilitar la Caché de host local, escriba:
Set-BrokerSite -LocalHostCacheEnabled $false
Recuerde: A partir de XenApp y XenDesktop 7.16, la concesión de conexiones (la función que precedió a la Caché de host local desde la versión 7.6) se ha eliminado del producto y ya no está disponible.
Verificar que la Caché de host local está funcionando
Para verificar que la Caché de host local está configurada y funciona correctamente:
- Compruebe que las importaciones de sincronización se completan correctamente. Verifique los registros de eventos.
- Asegúrese de que la base de datos LocalDB de SQL Server Express se ha creado en cada Delivery Controller. Eso confirma que el servicio de alta disponibilidad High Availability Service puede tomar el control, si fuera necesario.
- En el servidor de 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. Una vez que haya verificado que la Caché de host local funciona, recuerde volver a colocar todos los Controllers de nuevo en el modo normal. Este proceso puede tardar aproximadamente 15 minutos y, gracias a él, se evitan avalanchas de registros de VDA.
Forzar una interrupción del servicio
Puede que le convenga forzar una interrupción de la base de datos.
- Si la red tiene altibajos repetidos. Forzar una interrupción hasta que se resuelvan los problemas de red impide una transición fluida entre los modos normal y de interrupción.
- Para probar un plan de recuperación ante desastres.
- Al cambiar o mantener el servidor de la base de datos del sitio.
Para forzar una interrupción, modifique el Registro de cada servidor que contiene un Delivery Controller. En HKLM\Software\Citrix\DesktopServer\LHC, establezca OutageModeForced como REG_DWORD en 1. Esto indica al broker que introduzca el modo de interrupción independientemente del estado de la base de datos. Establecer este valor en 0 saca al servidor del modo de interrupción.
Supervisar
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.
- 503: Se ha encontrado un cambio en la configuración del broker principal, por lo que se inicia un proceso de importación.
- 504: La configuración del broker se ha copiado, exportado y, a continuación, importado a la LocalDB.
- 505: Ha fallado una importación a la LocalDB; consulte más adelante para obtener más información.
- 507: Se ha abandonado una importación debido a una interrupción pendiente. Si se inicia una interrupción durante una sincronización, la importación de ese momento se descarta y se utiliza la última configuración conocida.
- 510: No se recibieron datos de configuración del servicio de configuración procedentes del servicio de configuración principal.
- 517: Hubo un problema de comunicación con el broker principal.
- 518: Se ha abortado el script de Config Sync porque el Broker secundario (High Availability Service) no se está ejecutando.
High Availability Service (Servicio de alta disponibilidad):
- 3502: Se ha producido una interrupción y el servicio 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 servicio High Availability Service elegido, además de otros servicios que hayan participado en la elección.
Solución de 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.
Rastreo CDF: Contiene opciones para los módulos ConfigSyncServer y BrokerLHC. Esas opciones, junto con otros módulos de broker, identificarán probablemente el problema.
Informe: Puede generar y proporcionar un informe que detalle el punto del 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 rastreo de CSS, escriba:
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, inhabilite la funcionalidad de informes:
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0
Exportar la configuración de broker: Proporciona la configuración exacta con fines de depuración.
Export-BrokerConfiguration | Out-File <file-pathname>
Por ejemplo, Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.