Product Documentation

Memoria caché del host local

Feb 14, 2017

Para que la base de datos del sitio de XenApp y XenDesktop 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. (En la sección "Bases de datos" del artículo "Requisitos del sistema", se ofrece una lista de las funcionalidades de alta disponibilidad de SQL Server que se admiten en XenApp y XenDesktop.) 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 funcionalidad Memoria caché del host local (LHC) permite que las operaciones de intermediación (broker) de las conexiones en un sitio de XenApp o XenDesktop continúen cuando se produce una interrupción. La interrupción ocurre cuando:

  • Se interrumpe la conexión entre un Delivery Controller y la base de datos del sitio en un entorno local de Citrix.
  • Se produce un error en el vínculo WAN establecido entre el sitio y el plano de control de Citrix en un entorno de Citrix Cloud.

La Memoria caché del host local es la funcionalidad más completa que existe para la alta disponibilidad en XenApp y XenDesktop. Es una alternativa más eficaz que la funcionalidad Concesión de conexiones que se introdujo en XenApp 7.6.

Aunque esta implementación de Memoria caché del host local comparte el nombre con la funcionalidad Memoria caché del 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 Memoria caché del host local es completamente diferente; siga leyendo para saber cómo funciona.

Funcionamiento

En el siguiente gráfico, se muestran los componentes de Memoria caché del host local y las rutas de comunicación que se establecen durante un funcionamiento normal.

localized image

Durante el funcionamiento normal:

  • 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. 
  • Cada dos minutos, se comprueba 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 realiza un cambio desde la última comprobación, el broker principal usa Citrix Config Synchronizer Service (CSS) para sincronizar (copiar) información a un broker secundario (Citrix High Availability Service) en el Controller. Se copian todos los datos de configuración del broker, 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 Controller. 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. 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:

localized image

Cuando empieza una interrupción:

  • 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 broker secundario (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).
  • 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 re-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 la base de datos del sitio. 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 re-registro. El broker secundario 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.

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. Consulte la siguiente sección "Supervisión" para obtener más información.

También puede empezar intencionadamente una interrupción; consulte la siguiente sección "Cómo 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 broker secundario 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 broker secundario obtiene datos de todos los demás brokers secundarios de su nivel. 

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 volverán a registrarse en el broker secundario que acaba de elegirse.

El registro de eventos proporciona información sobre las opciones elegidas. Consulte la sección siguiente "Supervisión".

Requisitos y consideraciones de diseño

Sugerencia: Además de la información en esta sección, consulte Local Host Cache sizing and scaling en los artículos de conceptos avanzados. 

La Memoria caché del host local se admite para aplicaciones y escritorios alojados en servidores y escritorios estáticos (asignados). En cambio, no se admite para escritorios VDI agrupados (creados por Machine Creation Services o Provisioning Services).

Cambios o elementos no disponibles durante una interrupción

  • 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.
  • Las máquinas con agentes VDA en grupos de entrega agrupados que se configuran en "Apagar después de usar" se colocan en modo de mantenimiento.
  • 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.

Tamaño de la 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.

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 Memoria caché del 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.

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, 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 Memoria caché del host local también conlleva E/S adicional durante una interrupción: aproximadamente 3 MB de escrituras por segundo, con varias cientos de miles de lecturas.

Rendimiento

Durante una interrupción, un solo broker 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 broker 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 broker del sitio (zona) debe ser capaz de gestionar la carga adicional que impone LocalDB y todos los VDA afectados porque el broker elegido durante una interrupción podría cambiar.

Nota: En esta versión, se pueden gestionar hasta 5 000 VDA de forma eficaz durante una interrupción.

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 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 proceso de re-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 volver a registrarse en otro broker:

  • Comienza una interrupción: Al migrar desde un broker principal a un broker secundario.
  • Error de broker durante una interrupción: Al migrar desde un broker secundario en que se produjo un error 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. 

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), pero el intervalo no se puede eliminar por completo, independientemente de lo rápido que se registren los VDA. Por ejemplo, el siguiente comando cambia el latido a cinco minutos (300 000 milisegundos):

New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer -Name HeartbeatPeriodMs
-PropertyType DWORD –Value 300000

El tiempo que tarda la sincronización entre brokers 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 la siguiente sección "Supervisión" para obtener información sobre las entradas de sincronización en el registro de eventos.

Administración de la Memoria caché del host local

LocalDB de SQL Server Express

La base de datos LocalDB de Microsoft SQL Server Express que usa la Memoria caché del 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. Solo el broker secundario se comunica con esta base de datos; no puede usar cmdlets de PowerShell para cambiar nada 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 Memoria caché del 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 funcionalidad Memoria caché del host local no funcionará sin la base de datos, y no se puede usar otra base de datos con el broker secundario.

Nota: Instalar esta base de datos LocalDB no influye en si instala SQL Server Express para usarla como la base de datos del sitio.

Parámetros predeterminados después de la instalación y la actualización de XenApp o XenDesktop

En la siguiente tabla, se muestran los parámetros de la funcionalidad Memoria caché del host local y los de la funcionalidad Concesión de conexiones después de una nueva instalación de XenApp o XenDesktop y después de una actualización a XenApp o XenDesktop 7.12 (o una versión posterior respaldada).

Operación

Cantidad de agentes VDA

Concesión de conexiones: Antes

Memoria caché del host local: Después

Concesión de conexiones: Después

Instalación

Cualquiera

-

Inhabilitado

Habilitado

Actualización

< 5K

Habilitado

Inhabilitado

Habilitado

Actualización

< 5K

Inhabilitado

Habilitado

Inhabilitado

Actualización

> 5K

Habilitado

Inhabilitado

Habilitado

Actualización

> 5K

Inhabilitado

Inhabilitado

Inhabilitado

 

Instalación. Después de una nueva instalación de XenApp o XenDesktop, la Memoria caché del host local se inhabilita y la Concesión de conexiones se habilita de forma predeterminada. 

Actualización. La cantidad de agentes VDA presentes en un sitio afecta a la configuración predeterminada de la Memoria caché del host local después de una actualización. La actualización no produce cambios en la funcionalidad Concesión de conexiones.

Si el sitio tiene menos de 5 000 VDA:

  • La Memoria caché del host local se habilita si la Concesión de conexiones se inhabilita antes de la actualización. La Concesión de conexiones permanece inhabilitada.
  • La Memoria caché del host local se inhabilita si la Concesión de conexiones se habilita antes de la actualización. La Concesión de conexiones permanece habilitada.

Si el sitio tiene 5000 o más agentes VDA:

  • La Memoria caché del host local se inhabilita (independientemente de la Concesión de conexiones), y la Concesión de conexiones conserva la misma configuración que tenía antes de la actualización.

Cómo habilitar o inhabilitar la Memoria caché del host local

Para habilitar la Memoria caché del host local, escriba:

 Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false

Este cmdlet también inhabilita la funcionalidad Concesión de conexiones. No habilite la Memoria caché del host local y la Concesión de conexiones a la vez.

Para saber si la Memoria caché del host local está habilitada, escriba:

Get-BrokerSite

Compruebe que la propiedad LocalHostCacheEnabled es True, y la propiedad ConnectionLeasingEnabled es False.

Para inhabilitar la Memoria caché del host local (y habilitar la Concesión de conexiones), escriba:

Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true

Cómo forzar una interrupción

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 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.)
  • En caso de Citrix Cloud, el conector entra en modo de interrupción independientemente del estado de la conexión al plano de control o la zona principal.

Supervisión

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

Config Synchronization 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: 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.

High Availability Service

  • 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. 

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.

Seguimiento 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 seguimiento 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\NetworkService\LocalService\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 < ruta y nombre del archivo>

Por ejemplo, Export-BrokerConfiguration | Out-File C:\BrokerConfig.xml.