Cache d’hôte local

Pour garantir que la base de données du site Citrix Virtual Apps and Desktops est toujours disponible, Citrix recommande de commencer par un déploiement SQL Server tolérant aux pannes, en suivant les meilleures pratiques de haute disponibilité de Microsoft. (Pour les fonctionnalités de haute disponibilité de SQL Server prises en charge, consultez Bases de données.) Cependant, des problèmes et interruptions réseau peuvent empêcher les utilisateurs de se connecter à leurs applications ou bureaux.

La fonctionnalité Cache d’hôte local permet aux opérations de courtage de connexion dans un site de se poursuivre en cas de panne. Une panne se produit lorsque la connexion entre un Delivery Controller™ et la base de données du site échoue dans un environnement Citrix® sur site. Le Cache d’hôte local s’active lorsque la base de données du site est inaccessible pendant 90 secondes.

À partir de XenApp et XenDesktop 7.16, la fonctionnalité de location de connexion (une fonctionnalité de haute disponibilité précédente dans les versions antérieures) a été supprimée du produit et n’est plus disponible.

Contenu des données

Le Cache d’hôte local inclut les informations suivantes, qui constituent un sous-ensemble des informations de la base de données principale :

• Identités des utilisateurs et des groupes auxquels des droits sont attribués pour les ressources publiées à partir du site.
• Identités des utilisateurs qui utilisent actuellement ou qui ont récemment utilisé des ressources publiées à partir du site.
• Identités des machines VDA (y compris les machines d’accès PC distant) configurées sur le site.
• Identités (noms et adresses IP) des machines clientes Citrix Receiver™ utilisées activement pour se connecter aux ressources publiées.

Il contient également des informations pour les connexions actuellement actives qui ont été établies lorsque la base de données principale était indisponible :

• Résultats de toute analyse de point de terminaison de machine cliente effectuée par Citrix Receiver.
• Identités des machines d’infrastructure (telles que les serveurs NetScaler Gateway et StoreFront™) impliquées dans le site.
• Dates, heures et types d’activités récentes des utilisateurs.

Fonctionnement

Le graphique suivant illustre les composants du cache d’hôte local et les chemins de communication pendant les opérations normales.

Pendant les opérations normales

• Le broker principal (service de broker Citrix) sur un contrôleur accepte les requêtes de connexion de StoreFront. Le broker communique avec la base de données du site pour connecter les utilisateurs aux VDA enregistrés auprès du contrôleur.
• Le service Citrix Config Synchronizer (CSS) vérifie auprès du broker toutes les 5 minutes environ si des modifications ont été apportées. Ces modifications peuvent être initiées par l’administrateur (comme la modification d’une propriété de groupe de mise à disposition) ou être des actions système (comme les attributions de machines).

• Si une modification de configuration est survenue depuis la vérification précédente, le CSS synchronise (copie) les informations vers un broker secondaire sur le contrôleur. (Le broker secondaire est également connu sous le nom de service de haute disponibilité.)

  Toutes les données de configuration sont copiées, pas seulement les éléments modifiés depuis la vérification précédente. Le CSS importe les données de configuration dans une base de données Microsoft SQL Server Express LocalDB sur le contrôleur. Cette base de données est appelée base de données du cache d’hôte local. Le CSS garantit que les informations de la base de données du cache d’hôte local correspondent aux informations de la base de données du site. La base de données du cache d’hôte local est recréée à chaque synchronisation.

  Microsoft SQL Server Express LocalDB (utilisé par la base de données du cache d’hôte local) est installé automatiquement lorsque vous installez un contrôleur. (Vous pouvez interdire cette installation lors de l’installation d’un contrôleur à partir de la ligne de commande.) La base de données du cache d’hôte local ne peut pas être partagée entre les contrôleurs. Vous n’avez pas besoin de sauvegarder la base de données du cache d’hôte local. Elle est recréée chaque fois qu’une modification de configuration est détectée.

• Si aucune modification n’est survenue depuis la dernière vérification, aucune donnée n’est copiée.

Le graphique suivant illustre les modifications des chemins de communication si le broker principal perd le contact avec la base de données du site (une panne commence).

Pendant une panne

Lorsqu’une panne commence :

• Le broker secondaire commence à écouter et à traiter les requêtes de connexion.
• Lorsque la panne commence, le broker secondaire ne dispose pas des données d’enregistrement VDA actuelles, mais lorsqu’un VDA communique avec lui, un processus d’enregistrement est déclenché. Au cours de ce processus, le broker secondaire obtient également des informations de session actuelles sur ce VDA.
• Pendant que le broker secondaire gère les connexions, le Principal de courtage continue de surveiller la connexion. Lorsque la connexion est restaurée, le Principal de courtage demande au broker secondaire d’arrêter d’écouter les informations de connexion, et le Principal de courtage reprend les opérations de courtage. La prochaine fois qu’un VDA communique avec le Principal de courtage, un processus d’enregistrement est déclenché. Le broker secondaire supprime toutes les enregistrements de VDA restants de la panne précédente. Le CSS reprend la synchronisation des informations lorsqu’il apprend que des modifications de configuration ont eu lieu dans le déploiement.

Dans le cas improbable où une panne commencerait pendant une synchronisation, l’importation actuelle est ignorée et la dernière configuration connue est utilisée.

Le journal des événements fournit des informations sur les synchronisations et les pannes.

Aucune limite de temps n’est imposée pour le fonctionnement en mode de panne.

La transition entre le mode normal et le mode de panne n’affecte pas les sessions existantes. Elle n’affecte que le lancement de nouvelles sessions.

Vous pouvez également déclencher intentionnellement une panne. Consultez Forcer une panne pour plus de détails sur les raisons et la manière de procéder.

Sites avec plusieurs contrôleurs

Parmi ses autres tâches, le CSS fournit régulièrement au broker secondaire des informations sur tous les contrôleurs de la zone. (Si votre déploiement ne contient pas plusieurs zones, cette action affecte tous les contrôleurs du site.) Ayant ces informations, chaque broker secondaire connaît tous les brokers secondaires pairs fonctionnant sur d’autres contrôleurs de la zone.

Les brokers secondaires communiquent entre eux sur un canal distinct. Ces brokers utilisent une liste alphabétique des noms de domaine complets (FQDN) des machines sur lesquelles ils s’exécutent pour déterminer (élire) quel broker secondaire assurera les opérations de courtage dans la zone en cas de panne. Pendant la panne, tous les VDA s’enregistrent auprès du broker secondaire élu. Les brokers secondaires non élus de la zone rejettent activement les demandes de connexion entrantes et d’enregistrement de VDA.

Si un broker secondaire élu tombe en panne pendant une panne, un autre broker secondaire est élu pour prendre le relais, et les VDA s’enregistrent auprès du nouveau broker secondaire élu.

Pendant une panne, si un contrôleur est redémarré :

• Si ce contrôleur n’est pas le broker élu, le redémarrage n’a aucun impact.
• Si ce contrôleur est le broker élu, un contrôleur différent est élu, ce qui entraîne l’enregistrement des VDA. Une fois le contrôleur redémarré mis sous tension, il reprend automatiquement le courtage, ce qui entraîne un nouvel enregistrement des VDA. Dans ce scénario, les performances peuvent être affectées pendant les enregistrements.

Si vous mettez hors tension un contrôleur pendant les opérations normales, puis le mettez sous tension pendant une panne, le cache d’hôte local ne peut pas être utilisé sur ce contrôleur s’il est élu comme broker.

Les journaux d’événements fournissent des informations sur les élections.

Ce qui est indisponible pendant une panne, et autres différences

Il n’y a pas de limite de temps imposée pour fonctionner en mode panne. Cependant, Citrix recommande de rétablir la connectivité le plus rapidement possible.

Pendant une panne :

• Vous ne pouvez pas utiliser Studio.

• Vous avez un accès limité au SDK PowerShell.

  • Vous devez d’abord :
    • Ajouter une clé de registre EnableCssTestMode avec une valeur de 1 : New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
    • Utiliser le port 89 : Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ControllerDNSName, DesktopGroupName, RegistrationState
  • Après avoir exécuté ces commandes, vous pouvez accéder à :
    • Toutes les cmdlets Get-Broker*.
• Les informations d’identification de l’hyperviseur ne peuvent pas être obtenues auprès du service d’hôte. Toutes les machines sont dans un état d’alimentation inconnu et aucune opération d’alimentation ne peut être émise. Cependant, les machines virtuelles sur l’hôte qui sont sous tension peuvent être utilisées pour les demandes de connexion.
• Une machine attribuée ne peut être utilisée que si l’attribution a eu lieu pendant les opérations normales. De nouvelles attributions ne peuvent pas être effectuées pendant une panne.
• L’inscription et la configuration automatiques des machines d’accès PC distant ne sont pas possibles. Cependant, les machines qui ont été inscrites et configurées pendant le fonctionnement normal sont utilisables.
• Les utilisateurs d’applications et de bureaux hébergés sur serveur peuvent utiliser plus de sessions que leurs limites de session configurées, si les ressources se trouvent dans des zones différentes.
• Les utilisateurs peuvent lancer des applications et des bureaux uniquement à partir des VDA enregistrés dans la zone contenant le broker secondaire actuellement actif/élu. Les lancements inter-zones (d’un broker secondaire dans une zone vers un VDA dans une zone différente) ne sont pas pris en charge pendant une panne.
• Si une panne de la base de données du site se produit avant le début d’un redémarrage planifié des VDA dans un groupe de mise à disposition, les redémarrages commencent lorsque la panne se termine. Cela peut avoir des résultats inattendus. Pour plus d’informations, consultez Redémarrages planifiés retardés en raison d’une panne de base de données.
• La préférence de zone ne peut pas être configurée. Si elle est configurée, les préférences ne sont pas prises en compte pour le lancement de session.
• Les restrictions de balises où les balises sont utilisées pour désigner des zones ne sont pas prises en charge pour les lancements de session. Lorsque de telles restrictions de balises sont configurées et que l’option de vérification avancée de l’état d’un magasin StoreFront est activée, les sessions peuvent échouer à se lancer par intermittence.

Prise en charge des applications et des bureaux

Le LHC prend en charge les types de VDA et les modèles de mise à disposition suivants :

Remarque :

L’activation de l’accès aux VDA de bureau gérés par l’alimentation dans les groupes de mise à disposition en pool n’affecte pas le fonctionnement de la propriété ShutdownDesktopsAfterUse configurée pendant les opérations normales. Lorsque l’accès à ces bureaux pendant le LHC est activé, les VDA ne redémarrent pas automatiquement une fois l’événement LHC terminé. Les VDA de bureau gérés par l’alimentation dans les groupes de mise à disposition en pool peuvent conserver les données des sessions précédentes jusqu’au redémarrage des VDA. Un redémarrage de VDA peut se produire lorsqu’un utilisateur se déconnecte du VDA pendant des opérations non-LHC ou lorsque les administrateurs redémarrent le VDA.

Activer le LHC pour les VDA en pool d’OS mono-session gérés par l’alimentation à l’aide de Web Studio

À l’aide de Web Studio, vous pouvez rendre ces machines disponibles pour de nouvelles connexions pendant les événements LHC, groupe de mise à disposition par groupe de mise à disposition :

• Pour activer cette fonctionnalité lors de la création d’un groupe de mise à disposition, consultez Créer des groupes de mise à disposition.
• Pour activer cette fonctionnalité pour un groupe de mise à disposition existant, consultez Gérer les groupes de mise à disposition.

Remarque :

Ce paramètre est disponible dans Web Studio uniquement pour les groupes de mise à disposition de bureaux en pool qui fournissent des VDA gérés par l’alimentation.

Activer le LHC pour les VDA en pool d’OS mono-session gérés par l’alimentation à l’aide de PowerShell

Pour activer le LHC pour les VDA dans un groupe de mise à disposition spécifique, suivez ces étapes :

1. Activez cette fonctionnalité au niveau du site en exécutant cette commande :

   Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

2. Activez le LHC pour un groupe de mise à disposition en exécutant cette commande avec le nom du groupe de mise à disposition spécifié :

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

Pour modifier la disponibilité LHC par défaut pour les groupes de mise à disposition en pool nouvellement créés avec des VDA gérés par l’alimentation, exécutez la commande suivante :

Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true

Considérations relatives à la taille de la RAM

Le service LocalDB peut utiliser environ 1,2 Go de RAM (jusqu’à 1 Go pour le cache de la base de données, plus 200 Mo pour l’exécution de SQL Server Express LocalDB). Le broker secondaire peut utiliser jusqu’à 1 Go de RAM si une panne dure longtemps avec de nombreuses ouvertures de session (par exemple, 12 heures avec 10 000 utilisateurs). Ces exigences de mémoire s’ajoutent aux exigences de RAM normales pour le Controller, vous devrez donc peut-être augmenter la capacité totale de RAM.

Si vous utilisez une installation SQL Server Express pour la base de données du site, le serveur aura deux processus sqlserver.exe.

Considérations relatives à la configuration des cœurs de CPU et des sockets

La configuration du CPU d’un Controller, en particulier le nombre de cœurs disponibles pour SQL Server Express LocalDB, affecte directement les performances du cache d’hôte local, encore plus que l’allocation de mémoire. Cette surcharge de CPU n’est observée que pendant la période de panne lorsque la base de données est inaccessible et que le broker secondaire est actif.

Bien que LocalDB puisse utiliser plusieurs cœurs (jusqu’à 4), il est limité à un seul socket. L’ajout de sockets supplémentaires n’améliorera pas les performances (par exemple, avoir 4 sockets avec 1 cœur chacun). Au lieu de cela, Citrix recommande d’utiliser plusieurs sockets avec plusieurs cœurs. Lors des tests Citrix, une configuration 2x3 (2 sockets, 3 cœurs) a fourni de meilleures performances que les configurations 4x1 et 6x1.

Considérations relatives au stockage

Lorsque les utilisateurs accèdent aux ressources pendant une panne, la base de données LocalDB augmente. Par exemple, lors d’un test de connexion/déconnexion exécuté à 10 connexions par seconde, la base de données a augmenté de 1 Mo toutes les 2-3 minutes. Lorsque le fonctionnement normal reprend, la base de données locale est recréée et l’espace est restitué. Cependant, un espace suffisant doit être disponible sur le lecteur où LocalDB est installé pour permettre la croissance de la base de données pendant une panne. Le cache d’hôte local entraîne également plus d’E/S pendant une panne : environ 3 Mo d’écritures par seconde, avec plusieurs centaines de milliers de lectures.

Considérations relatives aux performances

Pendant une panne, un broker secondaire gère toutes les connexions. Ainsi, dans les sites (ou zones) qui équilibrent la charge entre plusieurs contrôleurs pendant les opérations normales, le broker secondaire élu pourrait avoir à gérer beaucoup plus de requêtes que la normale pendant une panne. Par conséquent, les exigences en matière de CPU seront plus élevées. Chaque broker secondaire du site (zone) doit être capable de gérer la charge supplémentaire imposée par la base de données du cache d’hôte local et tous les VDA affectés, car le broker secondaire élu pendant une panne peut changer.

Limites VDI :

• Dans un déploiement VDI à zone unique, jusqu’à 10 000 VDA peuvent être gérés efficacement pendant une panne.
• Dans un déploiement VDI multizone, jusqu’à 10 000 VDA par zone peuvent être gérés efficacement pendant une panne, pour un maximum de 40 000 VDA sur le site. Par exemple, chacun des sites suivants peut être géré efficacement pendant une panne :
  • Un site avec quatre zones, chacune contenant 10 000 VDA.
  • Un site avec sept zones, une contenant 10 000 VDA et six contenant 5 000 VDA chacune.

Pendant une panne, la gestion de la charge au sein du site peut être affectée. Les évaluateurs de charge (et en particulier les règles de nombre de sessions) peuvent être dépassés.

Pendant le temps nécessaire à tous les VDA pour s’enregistrer auprès d’un broker secondaire, ce service pourrait ne pas disposer d’informations complètes sur les sessions en cours. Ainsi, une demande de connexion utilisateur pendant cet intervalle peut entraîner le lancement d’une nouvelle session, même si une reconnexion à une session existante était possible. Cet intervalle (pendant lequel le « nouveau » broker secondaire acquiert les informations de session de tous les VDA lors du réenregistrement) est inévitable. Les sessions connectées au début d’une panne ne sont pas affectées pendant l’intervalle de transition, mais les nouvelles sessions et les reconnexions de session pourraient l’être.

Cet intervalle se produit chaque fois que les VDA doivent s’enregistrer :

• Début d’une panne : Lors de la migration d’un broker principal vers un broker secondaire.
• Défaillance du broker secondaire pendant une panne : Lors de la migration d’un broker secondaire défaillant vers un broker secondaire nouvellement élu.
• Récupération après une panne : Lorsque les opérations normales reprennent et que le broker principal reprend le contrôle.

Vous pouvez réduire l’intervalle en diminuant la valeur de registre HeartbeatPeriodMs du protocole Citrix Broker (par défaut = 600000 ms, soit 10 minutes). Cette valeur de pulsation est le double de l’intervalle utilisé par le VDA pour les pings, de sorte que la valeur par défaut entraîne un ping toutes les 5 minutes.

Par exemple, la commande suivante modifie la pulsation à cinq minutes (300000 millisecondes), ce qui entraîne un ping toutes les 2,5 minutes :

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

Soyez prudent lorsque vous modifiez la valeur du battement de cœur. L’augmentation de la fréquence entraîne une charge plus importante sur les contrôleurs en modes normal et de panne.

L’intervalle ne peut pas être entièrement éliminé, quelle que soit la rapidité d’enregistrement des VDA.

Le temps nécessaire à la synchronisation entre les brokers secondaires augmente avec le nombre d’objets (tels que les VDA, les applications, les groupes). Par exemple, la synchronisation de 5000 VDA peut prendre 10 minutes ou plus.

Différences par rapport aux versions de XenApp 6.x

Bien que cette implémentation du cache d’hôte local partage le nom de la fonctionnalité de cache d’hôte local dans XenApp 6.x et les versions antérieures de XenApp, il existe des améliorations significatives. Cette implémentation est plus robuste et immunisée contre la corruption. Les exigences de maintenance sont minimisées, par exemple en éliminant le besoin de commandes dsmaint périodiques. Ce cache d’hôte local est une implémentation techniquement entièrement différente.

Gérer le cache d’hôte local

Pour que le cache d’hôte local fonctionne correctement, la stratégie d’exécution PowerShell sur chaque contrôleur doit être définie sur RemoteSigned, Unrestricted ou Bypass.

SQL Server Express LocalDB

Le logiciel Microsoft SQL Server Express LocalDB utilisé par le cache d’hôte local est installé automatiquement lorsque vous installez un contrôleur ou mettez à niveau un contrôleur à partir d’une version antérieure à 7.9. Seul le broker secondaire communique avec cette base de données. Vous ne pouvez pas utiliser les cmdlets PowerShell pour modifier quoi que ce soit concernant cette base de données. La LocalDB ne peut pas être partagée entre les contrôleurs.

Le logiciel de base de données SQL Server Express LocalDB est installé, que le cache d’hôte local soit activé ou non.

Pour empêcher son installation, installez ou mettez à niveau le contrôleur à l’aide de la commande XenDesktopServerSetup.exe, et incluez l’option /exclude "Local Host Cache Storage (LocalDB)". Cependant, gardez à l’esprit que la fonctionnalité de cache d’hôte local ne fonctionnera pas sans la base de données, et vous ne pouvez pas utiliser une base de données différente avec le broker secondaire.

L’installation de cette base de données LocalDB n’a aucun effet sur l’installation de SQL Server Express pour une utilisation en tant que base de données de site.

Pour plus d’informations sur le remplacement d’une version antérieure de SQL Server Express LocalDB par une version plus récente, consultez Remplacer SQL Server Express LocalDB.

Paramètres par défaut après l’installation et la mise à niveau du produit

Lors d’une nouvelle installation de Citrix Virtual Apps and Desktops (version minimale 7.16), le cache d’hôte local est activé.

Après une mise à niveau (vers la version 7.16 ou ultérieure), le cache d’hôte local est activé s’il y a moins de 10 000 VDA dans l’ensemble du déploiement.

Activer et désactiver le cache d’hôte local

• Pour activer le cache d’hôte local, saisissez :

  Set-BrokerSite -LocalHostCacheEnabled $true

  Pour déterminer si le cache d’hôte local est activé, saisissez Get-BrokerSite. Vérifiez que la propriété LocalHostCacheEnabled est True.

• Pour désactiver le cache d’hôte local, saisissez :

  Set-BrokerSite -LocalHostCacheEnabled $false

Rappel : À partir de XenApp et XenDesktop 7.16, la location de connexion (la fonctionnalité qui a précédé le cache d’hôte local à partir de la version 7.6) a été supprimée du produit et n’est plus disponible.

Vérifier que le cache d’hôte local fonctionne

Pour vérifier que le cache d’hôte local est configuré et fonctionne correctement :

• Assurez-vous que les importations de synchronisation se terminent avec succès. Vérifiez les journaux d’événements.
• Assurez-vous que la base de données SQL Server Express LocalDB a été créée sur chaque Delivery Controller. Cela confirme que le broker secondaire peut prendre le relais, si nécessaire.
  • Sur le serveur Delivery Controller, accédez à C:\Windows\ServiceProfiles\NetworkService.
  • Vérifiez que HaDatabaseName.mdf et HaDatabaseName_log.ldf sont créés.
• Forcez une panne sur les Delivery Controllers. Après avoir vérifié que le cache d’hôte local fonctionne, n’oubliez pas de remettre tous les contrôleurs en mode normal. Cela peut prendre environ 15 minutes.

Journaux d’événements

Les journaux d’événements indiquent quand les synchronisations et les pannes se produisent. Dans les journaux de l’observateur d’événements, le mode de panne est appelé mode HA.

Service de synchronisation de la configuration :

Pendant les opérations normales, les événements suivants peuvent se produire lorsque le CSS importe les données de configuration dans la base de données du cache d’hôte local à l’aide du broker du cache d’hôte local.

• 503 : Le service Citrix Config Sync a reçu une configuration mise à jour. Cet événement indique le début du processus de synchronisation.
• 504 : Le service Citrix Config Sync a importé une configuration mise à jour. L’importation de la configuration s’est terminée avec succès.
• 505 : Le service Citrix Config Sync a échoué une importation. L’importation de la configuration n’a pas été effectuée avec succès. Si une configuration réussie précédente est disponible, elle est utilisée en cas de panne. Cependant, elle sera obsolète par rapport à la configuration actuelle. S’il n’y a pas de configuration précédente disponible, le service ne peut pas participer au brokering de session pendant une panne. Dans ce cas, consultez la section Dépannage et contactez le support Citrix.
• 507 : Le service Citrix Config Sync a abandonné une importation car le système est en mode de panne et le broker du cache d’hôte local est utilisé pour le brokering. Le service a reçu une nouvelle configuration, mais l’importation a été abandonnée en raison d’une panne. C’est un comportement attendu.
• 510 : Aucune donnée de configuration du service de configuration n’a été reçue du service de configuration principal.
• 517 : Un problème de communication avec le broker principal est survenu.
• 518 : Le script de synchronisation de la configuration a été annulé car le broker secondaire (service de haute disponibilité) n’est pas en cours d’exécution.

Service de haute disponibilité :

Ce service est également connu sous le nom de broker du cache d’hôte local.

• 3502 : Une panne s’est produite et le broker du cache d’hôte local effectue des opérations de brokering.
• 3503 : Une panne a été résolue et les opérations normales ont repris.
• 3504 : Indique quel broker de cache d’hôte local est élu, ainsi que les autres brokers de cache d’hôte local impliqués dans l’élection.
• 3507 : Fournit une mise à jour de l’état du cache d’hôte local toutes les 2 minutes, indiquant que le mode cache d’hôte local est actif sur le broker élu. Contient un résumé de la panne, y compris sa durée, l’enregistrement des VDA et les informations de session.
• 3508 : Annonce que le cache d’hôte local n’est plus actif sur le broker élu et que les opérations normales ont été restaurées. Contient un résumé de la panne, y compris sa durée, le nombre de machines enregistrées pendant l’événement de cache d’hôte local et le nombre de lancements réussis pendant l’événement LHC.
• 3509 : Notifie que le cache d’hôte local est actif sur le ou les brokers non élus. Contient une durée de panne toutes les 2 minutes et indique le broker élu.
• 3510 : Annonce que le cache d’hôte local n’est plus actif sur le ou les brokers non élus. Contient la durée de la panne et indique le broker élu.

Forcer une panne

Vous pourriez vouloir forcer délibérément une panne.

• Si votre réseau est en panne et en ligne de manière répétée. Forcer une panne jusqu’à ce que les problèmes réseau soient résolus empêche une transition continue entre les modes normal et panne (et les tempêtes d’enregistrement VDA fréquentes qui en résultent).
• Pour tester un plan de reprise après sinistre.
• Pour s’assurer que le cache d’hôte local fonctionne correctement.
• Lors du remplacement ou de la maintenance du serveur de base de données du site.

Pour forcer une panne, modifiez le registre de chaque serveur contenant un Delivery Controller. Dans HKLM\Software\Citrix\DesktopServer\LHC, créez et définissez OutageModeForced comme REG_DWORD sur 1. Ce paramètre indique au broker de cache d’hôte local d’entrer en mode panne, quel que soit l’état de la base de données. La définition de la valeur sur 0 fait sortir le broker de cache d’hôte local du mode panne.

Pour vérifier les événements, surveillez le fichier journal Current_HighAvailabilityService dans C:\ProgramData\Citrix\WorkspaceCloud\Logs\Plugins\HighAvailabilityService.

Dépannage

Plusieurs outils de dépannage sont disponibles lorsqu’une importation de synchronisation vers la base de données du cache d’hôte local échoue et qu’un événement 505 est publié.

Traçage CDF : Contient des options pour les modules ConfigSyncServer et BrokerLHC. Ces options, ainsi que d’autres modules de broker, permettront probablement d’identifier le problème.

Rapport : Si une importation de synchronisation échoue, vous pouvez générer un rapport. Ce rapport s’arrête à l’objet à l’origine de l’erreur. Cette fonctionnalité de rapport affecte la vitesse de synchronisation, c’est pourquoi Citrix recommande de la désactiver lorsqu’elle n’est pas utilisée.

Pour activer et produire un rapport de trace CSS, entrez la commande suivante :

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

Le rapport HTML est publié à l’adresse C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html.

Une fois le rapport généré, entrez la commande suivante pour désactiver la fonctionnalité de rapport :

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

Exporter la configuration du broker : Fournit la configuration exacte à des fins de débogage.

Export-BrokerConfiguration | Out-File <file-pathname>

Par exemple, Export-BrokerConfiguration | Out-File C:\\BrokerConfig.xml.

Commandes PowerShell du cache d’hôte local

Vous pouvez gérer le cache d’hôte local (LHC) sur vos Delivery Controllers à l’aide de commandes PowerShell.

Le module PowerShell se trouve à l’emplacement suivant sur les Delivery Controllers :

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

Important :

Exécutez ce module uniquement sur les Delivery Controllers.

Importer le module PowerShell

Pour importer le module, exécutez la commande suivante sur votre Delivery Controller.

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

Commandes PowerShell pour gérer le LHC

Les commandes suivantes vous aident à activer et à gérer le mode LHC sur les Delivery Controllers.

Remarque :

• Utilisez le port 89 lors de l’exécution des cmdlets Get-Broker* sur le Delivery Controller. Par exemple :
  • Get-BrokerMachine -AdminAddress localhost:89
• Lorsque le mode LHC n’est pas activé, le Broker LHC sur le Delivery Controller ne contient que des informations de configuration.
• En mode LHC, le Broker LHC sur le Delivery Controller élu contient les informations suivantes :
  • États des ressources
  • Détails de la session
  • Enregistrements VDA
  • Informations de configuration