Caché de host local

Para garantizar 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 tolerante a fallos, siguiendo las prácticas recomendadas de alta disponibilidad de Microsoft. (Para ver las funciones de alta disponibilidad de SQL Server compatibles, consulte Bases de datos). Sin embargo, los problemas e interrupciones de red pueden provocar que los usuarios no puedan conectarse a sus aplicaciones o escritorios.

La función Caché de host local permite que las operaciones de intermediación de conexiones en un sitio continúen cuando se produce una interrupción. Una interrupción se produce cuando la conexión entre un Delivery Controller™ y la base de datos del sitio falla en un entorno Citrix® local. La Caché de host local se activa cuando la base de datos del sitio está inaccesible durante 90 segundos.

A partir de XenApp y XenDesktop 7.16, la función de concesión de conexiones (una función de alta disponibilidad predecesora en versiones anteriores) se eliminó del producto y ya no está disponible.

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 derechos a los recursos publicados desde el sitio.
• Identidades de los usuarios que están utilizando actualmente o que han utilizado recientemente recursos publicados desde el sitio.
• Identidades de las máquinas VDA (incluidas las máquinas de Acceso con PC remoto) configuradas en el sitio.
• Identidades (nombres y direcciones IP) de las máquinas cliente de Citrix Receiver™ que se utilizan activamente para conectarse a recursos publicados.

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

• Resultados de cualquier análisis de puntos finales de máquinas 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) en un Controller acepta las solicitudes de conexión de StoreFront. El broker se comunica con la base de datos del sitio para conectar a los usuarios con los VDA registrados en el Controller.
• El servicio Citrix Config Synchronizer Service (CSS) comprueba con el broker aproximadamente cada 5 minutos si se han realizado cambios. Esos cambios pueden ser iniciados por el administrador (como cambiar una propiedad de grupo de entrega) o acciones del sistema (como asignaciones de máquinas).

• Si se produjo un cambio de configuración desde la comprobación anterior, el CSS sincroniza (copia) la información en un broker secundario en el Controller. (El broker secundario también se conoce como High Availability Service).

  Se copian todos los datos de configuración, no solo los elementos que cambiaron desde la comprobación anterior. El CSS importa los datos de configuración a una base de datos de Microsoft SQL Server Express LocalDB en el Controller. Esta base de datos se conoce como base de datos de Local Host Cache. El CSS garantiza que la información de la base de datos de Local Host Cache coincida con la información de la base de datos del sitio. La base de datos de Local Host Cache se vuelve a crear cada vez que se produce una sincronización.

  Microsoft SQL Server Express LocalDB (utilizado por la base de datos de Local Host Cache) se instala automáticamente al instalar un Controller. (Puede prohibir esta instalación al instalar un Controller desde la línea de comandos). La base de datos de Local Host Cache no se puede compartir entre Controllers. No es necesario hacer una copia de seguridad de la base de datos de Local Host Cache. 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 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).

Durante una interrupción

Cuando comienza una interrupción:

• El broker secundario comienza a escuchar y procesar las solicitudes de conexión.
• Cuando comienza la interrupción, el broker secundario no tiene datos de registro de VDA actuales, pero cuando un VDA se comunica con él, se activa un proceso de registro. Durante ese proceso, el broker secundario también obtiene información de sesión actual sobre ese VDA.
• Mientras el broker secundario gestiona las conexiones, el Brokering Principal sigue supervisando la conexión. Cuando se restablece la conexión, el Brokering Principal indica al broker secundario que deje de escuchar la información de conexión y el Brokering Principal reanuda las operaciones de intermediación. La próxima vez que un VDA se comunique con el Brokering Principal, se activa un proceso de registro. El broker secundario elimina cualquier registro de VDA restante de la interrupción anterior. El CSS reanuda la sincronización de la información cuando detecta que se han producido cambios de configuración en la implementación.

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 (#event-logs) registro de eventos proporciona información sobre las sincronizaciones y las interrupciones.

No hay un límite de tiempo impuesto para operar en modo de interrupción.

La transición entre el modo normal y el modo de interrupción no afecta a las sesiones existentes. Solo afecta al inicio de nuevas sesiones.

También puede provocar una interrupción intencionadamente. Consulte (#force-an-outage) [Forzar una interrupción] para obtener más información sobre por qué y cómo hacerlo.

Sitios con varios Controllers

Entre otras tareas, el CSS proporciona rutinariamente al broker 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 broker secundario conoce a todos los brokers secundarios pares que se ejecutan en otros Controllers de la zona.

Los brokers secundarios se comunican entre sí en un canal independiente. Esos brokers utilizan una lista alfabética de nombres FQDN de las máquinas en las que se ejecutan para determinar (elegir) qué broker secundario realizará las operaciones de intermediación en la zona si se produce una interrupción. Durante la interrupción, todos los VDA se registran con el broker secundario elegido. Los brokers secundarios no elegidos de la zona rechazan activamente las solicitudes de conexión entrantes y de registro de VDA.

Si un broker secundario elegido falla durante una interrupción, se elige otro broker secundario para que tome el relevo y los VDA se registran con el broker secundario recién elegido.

Durante una interrupción, si se reinicia un Controller:

• Si ese Controller no es el broker elegido, el reinicio no tiene ningún impacto.
• Si ese Controller es el broker elegido, se elige un Controller diferente, lo que provoca que los VDA se registren. Después de que el Controller reiniciado se encienda, asume automáticamente la intermediación, lo que provoca que los VDA se registren de nuevo. En este escenario, el rendimiento puede verse afectado durante los 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 broker.

Los (#event-logs) registros de eventos proporcionan información sobre las elecciones.

Qué no está disponible durante una interrupción y otras diferencias

No hay un límite de tiempo impuesto para operar en modo de interrupción. Sin embargo, Citrix recomienda restaurar la conectividad lo antes posible.

Durante una interrupción:

• No puede usar Studio.

• Tiene acceso limitado al SDK de PowerShell.

  • Primero debe:
    • Agregar una clave de registro EnableCssTestMode con un valor de 1: New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
    • Usar el puerto 89: Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
  • Después de ejecutar esos comandos, puede acceder a:
    • Todos los cmdlets Get-Broker*.
• 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 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 servidor pueden usar más sesiones que sus límites de sesión configurados, si los recursos están en zonas diferentes.
• Los usuarios solo pueden iniciar aplicaciones y escritorios desde VDA registrados en la zona que contiene el agente secundario actualmente activo/elegido. Los lanzamientos entre zonas (desde un agente secundario en una zona a un VDA en una zona diferente) no son compatibles durante una interrupción.
• Si se produce una interrupción de la base de datos del sitio antes de que comience un reinicio programado para los VDA de un grupo de entrega, los reinicios comienzan cuando finaliza la interrupción. Esto puede tener resultados no deseados. Para obtener más información, consulte Reinicios programados retrasados debido a una interrupción de la base de datos.
• No se puede configurar la preferencia de zona. Si se configura, las preferencias no se tienen en cuenta para el inicio de la sesión.
• Las restricciones de etiquetas, donde las etiquetas se utilizan para designar zonas, no se admiten para los inicios de sesión. Cuando se configuran dichas restricciones de etiquetas y se habilita la opción de comprobación de estado avanzada de un almacén de StoreFront, las sesiones pueden fallar intermitentemente al iniciarse.

Compatibilidad con aplicaciones y escritorios

LHC admite los siguientes tipos de VDA y modelos de entrega:

Nota:

Habilitar el acceso a los VDA de escritorio con administración de energía en grupos de entrega agrupados no afecta la forma en que funciona la propiedad ShutdownDesktopsAfterUse configurada durante las operaciones normales. Cuando se habilita el acceso a estos escritorios durante LHC, los VDA no se reinician automáticamente una vez finalizado el evento de LHC. Los VDA de escritorio con administración de energía en grupos de entrega agrupados pueden retener datos de sesiones anteriores hasta que los VDA se reinicien. Un reinicio de VDA puede ocurrir cuando un usuario cierra sesión en el VDA durante operaciones que no son de LHC o cuando los administradores reinician el VDA.

Habilitar LHC para VDA agrupados de SO de sesión única con administración de energía mediante Web Studio

Con Web Studio, puede hacer que esas máquinas estén disponibles para nuevas conexiones durante los eventos de LHC por grupo de entrega:

• Para habilitar esta función durante la creación de grupos de entrega, consulte Crear grupos de entrega.
• Para habilitar esta función para un grupo de entrega existente, consulte Administrar grupos de entrega.

Nota:

Esta configuración solo está disponible en Web Studio para grupos de entrega de escritorios agrupados que entregan VDA con administración de energía.

Habilitar LHC para VDA agrupados de SO de sesión única con administración de energía mediante PowerShell

Para habilitar LHC para VDA en un grupo de entrega específico, siga estos pasos:

1. Habilite esta función a nivel de sitio ejecutando este comando:

   Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

2. Habilite LHC para un grupo de entrega ejecutando este comando con el nombre del grupo de entrega especificado:

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

Para cambiar la disponibilidad predeterminada de LHC para los grupos de entrega agrupados recién creados con VDA administrados por energía, ejecute el siguiente comando:

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

Consideraciones sobre el 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 agente secundario 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.

Si utiliza una instalación de SQL Server Express para la base de datos del sitio, el servidor tendrá dos procesos sqlserver.exe.

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

La configuración de CPU de un Controller, especialmente 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 agente secundario 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.

Consideraciones de 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ó 1 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, debe haber suficiente espacio disponible 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 más E/S durante una interrupción: aproximadamente 3 MB de escrituras por segundo, con varios cientos de miles de lecturas.

Consideraciones de rendimiento

Durante una interrupción, un broker secundario gestiona todas las conexiones, por lo que en sitios (o zonas) que equilibran la carga entre varios Controladores durante las operaciones normales, el broker secundario 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 secundario del sitio (zona) debe ser capaz de gestionar la carga adicional impuesta por la base de datos de Local Host Cache y todos los VDA afectados, ya que el broker secundario elegido durante una interrupción puede cambiar.

Límites de VDI:

• En una implementación VDI de una sola zona, se pueden gestionar eficazmente hasta 10 000 VDA durante una interrupción.
• En una implementación VDI multizona, se pueden gestionar eficazmente hasta 10 000 VDA en cada zona durante una interrupción, hasta un máximo de 40 000 VDA en el sitio. Por ejemplo, cada uno de los siguientes sitios puede gestionarse 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 5 000 VDA cada una.

Durante una interrupción, la administració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 registrarse con un broker secundario, es posible que ese servicio no tenga información completa sobre las sesiones actuales. Por lo tanto, una solicitud de conexión de usuario durante ese intervalo puede resultar en el inicio de una nueva sesión, aunque la reconexión a una sesión existente fuera posible. Este intervalo (mientras el “nuevo” broker secundario adquiere información de la sesión de todos los VDA durante el nuevo registro) es inevitable. 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í pueden verse afectadas.

Este intervalo se produce siempre que los VDA deben registrarse:

• Comienza una interrupción: Al migrar de un broker principal a un broker secundario.
• Fallo del broker secundario 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 retoma el control.

Puede disminuir el intervalo reduciendo el valor del registro HeartbeatPeriodMs del Protocolo de Broker de Citrix (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 da como resultado un ping cada 2,5 minutos:

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

Tenga precaución al cambiar el valor de latido. Aumentar la frecuencia provoca una mayor carga en los Controllers tanto en modo normal como en modo de interrupción.

El intervalo no se puede eliminar por completo, independientemente de la rapidez con la que se registren los VDA.

El tiempo que tarda en sincronizarse entre los agentes secundarios aumenta con el número de objetos (como VDA, aplicaciones, grupos). Por ejemplo, la sincronización de 5000 VDA puede tardar 10 minutos o más en completarse.

Diferencias con las versiones de XenApp 6.x

Aunque esta implementación de Local Host Cache comparte el nombre de la función Local Host Cache de 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 Local Host Cache es una implementación técnicamente diferente.

Administrar Local Host Cache

Para que Local Host Cache funcione correctamente, la política de ejecución de PowerShell en cada Controller debe establecerse en RemoteSigned, Unrestricted o Bypass.

SQL Server Express LocalDB

El software Microsoft SQL Server Express LocalDB que utiliza Local Host Cache se instala automáticamente al instalar un Controller o al actualizar un Controller desde una versión anterior a la 7.9. Solo el agente 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 Local Host Cache está habilitada.

Para evitar su instalación, instale o actualice el Controller mediante el comando XenDesktopServerSetup.exe e incluya la opción /exclude "Local Host Cache Storage (LocalDB)". Sin embargo, tenga en cuenta que la función Local Host Cache no funcionará sin la base de datos, y no puede usar una base de datos diferente con el agente secundario.

La instalación de esta base de datos LocalDB no afecta a si instala SQL Server Express para usarlo como 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.

Configuración predeterminada después de la instalación y actualización del producto

Durante una nueva instalación de Citrix Virtual Apps and Desktops (versión mínima 7.16), la caché de host local está habilitada.

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 VDA en toda la implementación.

Habilitar y deshabilitar la caché de host local

• Para habilitar la caché de host local, introduzca:

  Set-BrokerSite -LocalHostCacheEnabled $true

  Para determinar si la caché de host local está habilitada, introduzca Get-BrokerSite. Compruebe que la propiedad LocalHostCacheEnabled es True.

• Para deshabilitar la caché de host local, introduzca:

  Set-BrokerSite -LocalHostCacheEnabled $false

Recuerde: A partir de XenApp y XenDesktop 7.16, el arrendamiento de conexiones (la función que precedió a la caché de host local a partir de la versión 7.6) se eliminó del producto y ya no está disponible.

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 completen correctamente. Compruebe los registros de eventos.
• Asegúrese de que la base de datos SQL Server Express LocalDB se haya creado en cada Delivery Controller. Esto confirma que el agente secundario puede tomar el control, si es necesario.
  • En el servidor Delivery Controller, vaya a C:\Windows\ServiceProfiles\NetworkService.
  • Verifique que HaDatabaseName.mdf y HaDatabaseName_log.ldf se hayan creado.
• Forzar una interrupción en los Delivery Controllers. Una vez que haya verificado que la caché de host local funciona, recuerde volver a poner todos los Controllers en modo normal. Esto puede tardar aproximadamente 15 minutos.

Registros de eventos

Los registros de eventos indican cuándo se producen las sincronizaciones y las interrupciones. En los registros del visor de eventos, el modo de interrupción se denomina modo HA.

Servicio de sincronización de configuración:

Durante las operaciones normales, pueden ocurrir los siguientes eventos cuando el CSS importa los datos de configuración en la base de datos de la caché de host local mediante el agente de la caché de host local.

• 503: El servicio de sincronización de configuración de Citrix recibió una configuración actualizada. Este evento indica el inicio del proceso de sincronización.
• 504: El servicio de sincronización de configuración de Citrix importó una configuración actualizada. La importación de la configuración se completó correctamente.
• 505: El servicio de sincronización de configuración de Citrix falló una importación. La importación de la configuración no se completó correctamente. Si hay una configuración anterior correcta disponible, se utiliza si se produce una interrupción. Sin embargo, estará desactualizada con respecto a la configuración actual. Si no hay ninguna configuración anterior disponible, el servicio no puede participar en la intermediación de sesiones durante una interrupción. En este caso, consulte la sección Solución de problemas y póngase en contacto con el soporte de Citrix.
• 507: El servicio de sincronización de configuración de Citrix abandonó una importación porque el sistema está en modo de interrupción y el agente de la caché de host local se está utilizando para la intermediación. El servicio recibió una nueva configuración, pero la importación se abandonó porque se produjo una interrupción. Este es el comportamiento esperado.
• 510: No se recibieron datos de configuración del servicio de configuración del servicio de configuración principal.
• 517: Hubo un problema al comunicarse 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:

Este servicio también se conoce como el agente de la caché de host local.

• 3502: Se produjo una interrupción y el agente de la caché de host local está realizando operaciones de intermediación.
• 3503: Se resolvió una interrupción y se reanudaron las operaciones normales.
• 3504: Indica qué broker de Local Host Cache ha sido elegido, además de otros brokers de Local Host Cache implicados en la elección.
• 3507: Proporciona una actualización de estado de Local Host Cache cada 2 minutos, lo que indica que el modo Local Host Cache está activo en el broker elegido. Contiene un resumen de la interrupción, incluida la duración de la interrupción, el registro de VDA y la información de la sesión.
• 3508: Anuncia que Local Host Cache ya no está activo en el broker elegido y que se han restaurado las operaciones normales. Contiene un resumen de la interrupción, incluida la duración de la interrupción, el número de máquinas que se registraron durante el evento de Local Host Cache y el número de inicios correctos durante el evento de LHC.
• 3509: Notifica que Local Host Cache está activo en los brokers no elegidos. Contiene la duración de la interrupción cada 2 minutos e indica el broker elegido.
• 3510: Anuncia que Local Host Cache ya no está activo en los brokers no elegidos. Contiene la duración de la interrupción e indica el broker elegido.

Forzar una interrupción

Es posible que desee forzar una interrupción deliberadamente.

• Si su red se conecta y desconecta 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 (y las consiguientes tormentas de registro de VDA frecuentes).
• Para probar un plan de recuperación ante desastres.
• Para ayudar a garantizar que Local Host Cache funciona correctamente.
• 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, cree y establezca OutageModeForced como REG_DWORD en 1. Esta configuración indica al broker de Local Host Cache que entre en modo de interrupción, independientemente del estado de la base de datos. Al establecer el valor en 0, el broker de Local Host Cache sale del modo de interrupción.

Para verificar los eventos, supervise el archivo de registro Current_HighAvailabilityService en C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.

Solucionar problemas

Hay varias herramientas de solución de problemas disponibles cuando falla una importación de sincronización a la base de datos de Local Host Cache 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 la velocidad de sincronización, por lo que Citrix recomienda deshabilitarla cuando no se utilice.

Para habilitar y producir 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 deshabilitar 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.

Comandos de PowerShell de Local Host Cache

Puede administrar Local Host Cache (LHC) en sus Delivery Controllers mediante comandos de PowerShell.

El módulo de PowerShell se encuentra en la siguiente ubicación en los Delivery Controllers:

C:\Program Files\Citrix\Broker\Service\ControlScripts

Importante:

Ejecute este módulo solo en los Delivery Controllers.

Importar módulo de PowerShell

Para importar el módulo, ejecute lo siguiente en su Delivery Controller.

cd C:\Program Files\Citrix\Broker\Service\ControlScripts Import-Module .\HighAvailabilityServiceControl.psm1

Comandos de PowerShell para administrar LHC

Los siguientes comandos le ayudan a activar y administrar el modo LHC en los Delivery Controllers.

Nota:

• Utilice el puerto 89 al ejecutar los cmdlets Get-Broker* en el Delivery Controller. Por ejemplo:
  • Get-BrokerMachine -AdminAddress localhost:89
• Cuando no está en modo LHC, el Broker LHC del Delivery Controller solo contiene información de configuración.
• Durante el modo LHC, el Broker LHC del Delivery Controller elegido contiene la siguiente información:
  • Estados de los recursos
  • Detalles de la sesión
  • Registros de VDA
  • Información de configuración