Cache d’hôte local

La fonctionnalité de cache d’hôte local (LHC) permet de poursuivre les opérations de négociation de connexion dans un déploiement du service Citrix Virtual Apps and Desktops lorsqu’un Cloud Connector ne peut pas communiquer avec Citrix Cloud. Le cache d’hôte local est activé lorsque la connexion réseau est perdue pendant 20 secondes.

Grâce au cache d’hôte local, les utilisateurs qui sont connectés lorsqu’une panne se produit peuvent continuer à travailler sans interruption. Les délais des nouvelles connexions et des reconnexions sont réduits.

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 sont spécifiquement attribués des droits sur les ressources publiées à partir du site.
  • Identités des utilisateurs qui utilisent actuellement ou ont récemment utilisé des ressources publiées à partir du site.
  • Identités des machines VDA (y compris les machines Remote PC Access) configurées sur le site.
  • Identités (noms et adresses IP) des machines de l’application Citrix Workspace utilisées activement pour se connecter aux ressources publiées.

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

  • Résultats de toute analyse de point de terminaison de machine client réalisée par l’application Citrix Workspace.
  • Identités des machines d’infrastructure (telles que les serveurs Citrix Gateway et StoreFront) impliquées dans le site.
  • Dates/heures et types d’activités récentes des utilisateurs.

Fonctionnement

En mode de fonctionnement normal :

Image de fonctionnement normal

  • Le broker principal (Citrix Remote Broker Provider Service) sur un Cloud Connector accepte des requêtes de connexion provenant de StoreFront, et communique avec Citrix Cloud pour connecter les utilisateurs aux VDA qui sont enregistrés auprès du Cloud Connector.
  • Citrix Config Synchronizer Service (CSS) interroge le broker dans Citrix Cloud environ toutes les deux minutes pour savoir si des modifications ont été apportées à la configuration. Ces modifications peuvent avoir été initiées par un administrateur (telles que la modification d’une propriété de groupe de mise à disposition) ou être des actions du système (telles que les attributions de machine).
  • Si la configuration a été modifiée depuis la dernière vérification, le service CSS synchronise les informations (copie) sur un broker secondaire (Citrix High Availability Service, HA broker dans l’illustration ci-dessus) sur le Cloud Connector. Toutes les données de configuration sont copiées, et pas seulement les éléments qui ont été modifiés depuis la dernière vérification. Le broker secondaire importe les données dans une base de données Microsoft SQL Server Express LocalDB sur le Cloud Connector. Le service CSS s’assure que les informations de la base de données LocalDB du broker secondaire correspondent aux informations de la base de données du site dans Citrix Cloud. La base de données LocalDB est recréée chaque fois que la synchronisation se produit.

La base de données LocalDB est installée automatiquement lorsque vous installez un Cloud Connector. Cette base de données ne peut pas être partagée sur des Cloud Connector. Vous n’avez pas besoin de sauvegarder cette base de données ; elle est recréée chaque fois qu’une modification de la configuration est détectée.

  • Si aucune modification n’a été apportée depuis la dernière vérification, les données de configuration ne sont pas copiées.

Durant une panne :

Image d'interruption

Lorsqu’une panne commence :

  • Le broker secondaire démarre l’écoute et traite les demandes de connexion.
  • Lorsque la panne commence, le broker secondaire ne dispose pas des données d’enregistrement de VDA, mais dès qu’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 sur ce VDA.
  • Bien que le broker secondaire gère les connexions, le broker principal continue à surveiller la connexion à Citrix Cloud. Lorsque la connexion est rétablie, le broker principal demande au broker secondaire d’arrêter l’écoute des informations de connexion, et le broker principal reprend les opérations de négociation de connexion. La prochaine fois qu’un VDA communique avec le broker principal, un processus d’enregistrement est déclenché. Le broker secondaire supprime les enregistrements de VDA restants de la panne précédente. Le service CSS reprend la synchronisation des informations lorsqu’il détecte des modifications de la configuration dans Citrix Cloud.

Dans le cas peu probable où une panne démarre pendant une synchronisation, l’importation en cours est annulée et la dernière configuration connue est utilisée.

Le journal d’événements consigne les synchronisations et les pannes.

Aucun délai n’est imposé pour le fonctionnement en mode panne.

Vous pouvez également déclencher intentionnellement une panne. Voir Forcer une panne pour savoir quand cela peut être nécessaire et comment procéder.

Emplacements de ressources (zones satellite) avec plusieurs Cloud Connector

Parmi ses différentes tâches, le service CSS fournit régulièrement au broker secondaire des informations sur tous les Cloud Connector dans l’emplacement de ressources. Ces informations permettent à chaque broker secondaire de connaître tous les brokers secondaires homologues.

Les brokers secondaires communiquent entre eux sur un canal distinct. Ils utilisent une liste alphabétique des noms de domaine complet (FQDN) des machines qu’ils exécutent pour déterminer (sélectionner) le broker secondaire qui sera en charge des opérations de négociation dans la zone si une panne se produit. Durant la panne, tous les VDA se ré-enregistrent auprès du broker secondaire sélectionné. Les brokers secondaires non sélectionnés dans la zone rejettent activement les requêtes de connexion et d’enregistrement de VDA entrantes.

Si un broker secondaire sélectionné échoue lors d’une panne, un autre broker secondaire est sélectionné pour prendre le relais et les VDA s’enregistrent auprès du broker secondaire qui vient d’être sélectionné.

Durant une panne, si un Cloud Connector est redémarré :

  • Si ce Cloud Connector n’est pas le broker principal sélectionné, le redémarrage n’a aucun impact.
  • Si ce Cloud Connector est le broker principal sélectionné, un autre Cloud Connector est sélectionné, et par conséquent les VDA s’enregistrent. Une fois que le Cloud Connector redémarré est sous tension, il reprend automatiquement la négociation des connexions, et les VDA s’enregistrent à nouveau. Dans ce scénario, les performances peuvent être affectées lors des enregistrements.

Le journal d’événements contient des informations sur les sélections.

Limitations, considérations et exigences

Le cache d’hôte local est pris en charge pour les applications et les bureaux hébergés sur le serveur, et les bureaux statiques (attribués). Il n’est pas pris en charge pour les bureaux VDI en pool créés par MCS ou Citrix Provisioning (car, en cas de panne, les machines VDI ne peuvent pas être restaurées dans leur état principal après utilisation).

Fonctionnalités indisponibles durant une panne et autres différences

  • Vous ne pouvez pas utiliser les fonctions de gestion (Studio) dans Citrix Cloud pour des éléments dans l’emplacement de ressources sur lequel la panne se produit, ou exécuter des applets de commande PowerShell.
  • Les données de surveillance ne sont pas envoyées à Citrix Cloud pendant une panne. Par conséquent, les fonctions de surveillance (Director) n’affichent pas l’activité lors d’une panne.
  • Les informations d’identification de l’hyperviseur ne peuvent pas être obtenues depuis Host Service. Toutes les machines se trouvent dans un état d’alimentation inconnu et aucune opération d’alimentation ne peut être émise. Toutefois, les VM de l’hôte qui sont sous tension peuvent être utilisées pour les demandes de connexion.
  • Les VDA de bureau avec alimentation gérée dans des groupes de mise à disposition regroupés dont la propriété ShutDownDesktopsAfterUse est activée sont placés en mode maintenance lorsqu’une panne se produit.
  • Une machine attribuée peut uniquement être utilisée si l’attribution s’est produite avant la panne. De nouvelles attributions ne peuvent pas être effectuées lors d’une panne.
  • L’inscription et la configuration automatiques de machines Remote PC Access ne sont pas possibles. Toutefois, les machines qui ont été inscrites et configurées avant la panne peuvent accepter des connexions.
  • Les utilisateurs d’applications et de bureaux hébergés sur le serveur peuvent utiliser plus de sessions que leurs limites de session configurées, si les ressources se trouvent dans des emplacements de ressources différents.

Considérations sur la taille de la RAM

Le service LocalDB peut utiliser environ 1,2 Go de RAM (jusqu’à 1 Go pour le cache de base de données, plus 200 Mo pour l’exécution de SQL Server Express LocalDB). High Availability Service peut utiliser jusqu’à 1 Go de RAM si une panne dure longtemps avec un grand nombre d’ouvertures de session (par exemple, 12 heures avec 10 000 utilisateurs). Ces exigences de mémoire s’ajoutent aux exigences de RAM requises normalement pour le Cloud Connector, il se peut donc que vous deviez augmenter la quantité totale de capacité RAM.

Considérations sur la configuration des sockets et des cœurs d’UC

La configuration d’UC d’un Cloud Connector, notamment 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 charge de l’UC est observée uniquement au cours de la période de panne lorsque la base de données ne peut pas être contactée et que le service High Availability Service est actif.

Bien que la base de données LocalDB puisse utiliser plusieurs cœurs (jusqu’à 4), elle est limitée à un seul socket. L’ajout de sockets ne permet pas d’améliorer les performances (par exemple, 4 sockets avec 1 cœur chacun). Citrix vous recommande plutôt d’utiliser plusieurs sockets avec plusieurs cœurs. Au cours des tests Citrix, une configuration 2x3 (2 sockets, 3 cœurs) a fourni de meilleures performances que les configurations 4x1 et 6x1.

Considérations sur le stockage

Lorsque les utilisateurs accèdent à des ressources pendant une panne, la taille de la base de données LocalDB augmente. Par exemple, lors d’un test d’ouverture/fermeture de session avec 10 ouvertures de session par seconde, la base de données a augmenté d’1 Mo toutes les 2-3 minutes. Lorsque le fonctionnement normal reprend, la base de données locale est recréée lorsqu’une modification de la configuration est détectée. Le broker doit avoir suffisamment d’espace sur le disque sur lequel la base de données LocalDB est installée pour permettre à la taille de la base de données d’augmenter durant une panne. Le cache d’hôte local entraîne également des E/S supplémentaires pendant une panne : environ 3 Mo d’écritures par seconde, avec plusieurs centaines de milliers de lectures.

Considérations sur les performances

Durant une panne, un seul broker gère toutes les connexions. Dans les emplacements de ressources qui équilibrent la charge entre plusieurs Cloud Connector (dans des conditions de fonctionnement normales), le broker sélectionné peut être amené à prendre en charge beaucoup plus de requêtes que d’habitude durant une panne. Par conséquent, les demandes d’UC sont plus nombreuses. Chaque broker dans l’emplacement de ressources doit être en mesure de gérer la charge supplémentaire imposée par la base de données LocalDB et tous les VDA affectés, car le broker sélectionné lors d’une panne peut changer.

Limites de VDI :

  • Dans un déploiement avec un seul emplacement de ressources, jusqu’à 10 000 VDA peuvent être gérés efficacement au cours d’une panne.
  • Dans un déploiement VDI avec plus d’un emplacement de ressources, jusqu’à 10 000 VDA dans chaque emplacement de ressources peuvent être gérés au cours d’une panne, avec un maximum de 40 000 VDA dans le déploiement. Par exemple, chacun des déploiements suivants peut être géré de manière efficace durant une panne :
    • Un déploiement avec quatre emplacements de ressources secondaires contenant chacun 10 000 VDA.
    • Un déploiement avec sept zones secondaires, une contenant 10 000 VDA et six contenant 5 000 VDA chacune.

Durant une panne, la gestion de la charge peut être affectée. Les calculateurs de charge (et plus particulièrement les règles du nombre de sessions) peuvent être dépassés.

Pendant que tous les VDA s’enregistrent avec un broker, il est possible que ce broker ne dispose pas d’informations complètes sur les sessions en cours. Par conséquent, une demande de connexion d’un utilisateur pendant cet intervalle peut entraîner le démarrage d’une nouvelle session, même si la reconnexion à une session existante est possible. Cet intervalle (pendant lequel le nouveau broker reçoit les informations de session depuis tous les VDA dans le cadre de l’enregistrement) est inévitable. Lorsqu’une panne démarre, les sessions connectées ne sont pas affectées lors de l’intervalle de transition, mais les nouvelles sessions et les reconnexions de session peuvent l’être.

Cet intervalle se produit lorsque des VDA doivent s’enregistrer auprès d’un autre broker :

  • Une panne démarre : lors de la migration depuis un broker principal vers un broker secondaire.
  • Défaillance du broker durant une panne : lors de la migration depuis un broker secondaire qui a échoué vers un nouveau broker secondaire.
  • Reprise après une panne : lorsque les opérations normales reprennent, et que le broker principal reprend le contrôle.

Le temps nécessaire à la synchronisation entre les brokers augmente avec le nombre d’objets (VDA, applications, groupes) Par exemple, la synchronisation de 5 000 VDA peut prendre plus de dix minutes.

Exigences de StoreFront

Important :

Chaque zone satellite (emplacement de ressources) doit avoir un StoreFront installé et configuré localement. Le cache de l’hôte local fonctionne uniquement dans les emplacements de ressources contenant un StoreFront local.

Différences par rapport aux versions XenApp 6.x

Bien que cette implémentation du cache d’hôte local porte le même nom que la fonctionnalité de cache d’hôte local dans XenApp 6.x et les versions antérieures de XenApp, d’importantes améliorations y ont été apportées. Cette implémentation est plus solide et plus résistante à la corruption des données. Les besoins de maintenance ont été réduits, par exemple le besoin de commandes dsmaintpériodiques a été éliminé. Ce cache d’hôte local est une implémentation complètement différente sur le plan technique.

Gérer le cache d’hôte local

Le cache d’hôte local est toujours activé dans un déploiement du service Citrix Virtual Apps and Desktops. Vous n’avez rien d’autre à faire pour le configurer ou le gérer.

Comme indiqué précédemment, la base de données LocalDB est installée automatiquement lorsque vous installez un Cloud Connector dans un emplacement de ressources. N’essayez pas de la désactiver ou de la supprimer. (Citrix met à jour le Cloud Connector régulièrement. Si vous désactivez ou supprimez le logiciel LocalDB manuellement, la prochaine mise à jour du Cloud Connector le remplace.)

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 :

  • Vérifiez que l’emplacement de ressources contient un StoreFront local qui pointe vers les Cloud Connector dans cet emplacement de ressources.
  • Assurez-vous que les importations de synchronisation se déroulent correctement. Vérifiez les journaux d’événements.
  • Assurez-vous que SQL Server LocalDB a été créé sur chaque Cloud Connector. Cela confirme que le High Availability Service peut prendre le relais, si nécessaire.
    • Sur le serveur Cloud Connector, accédez à c:\Windows\ServiceProfiles\NetworkService\
    • Vérifiez que HaDatabaseName.mdf et HaDatabaseName_logldf sont créés
  • Forcez une interruption sur tous les Cloud Connector dans l’emplacement de ressources. Après avoir vérifié que le cache d’hôte local fonctionne, n’oubliez pas de remettre tous les Cloud Connector en mode normal. Cela peut prendre environ 15 minutes pour éviter les pics d’enregistrement de VDA.

Consultez également Scalability considerations for using Local Host Cache with Cloud Connectors.

Journaux d’événements

Les journaux d’événements consignent les synchronisations et les pannes.

Config Synchronizer Service :

Lors du fonctionnement normal, les événements suivants peuvent se produire lorsque le service CSS copie et exporte la configuration du broker puis l’importe dans la base de données LocalDB à l’aide du High Availability Service (broker secondaire).

  • 503 : Citrix Config Sync Service a reçu une configuration mise à jour. Cet événement se produit chaque fois que le High Availability Service reçoit une configuration mise à jour de Citrix Cloud. Il indique le début du processus de synchronisation. Un événement 504 ou 505 suit toujours cet événement.
  • 504 : Citrix Config Sync Service a importé une configuration mise à jour. L’importation de la configuration s’est terminée avec succès.
  • 505 : Échec d’une importation par Citrix Config Sync Service. L’importation de la configuration n’a pas réussi. Si une configuration précédente réussie est disponible, elle sera utilisée en cas de panne. Cependant, elle sera obsolète à partir de la configuration actuelle. Si aucune configuration précédente n’est disponible, le service ne peut pas participer à l’intermédiation de session pendant une panne. Dans ce cas, consultez la section Dépannage et contactez le support Citrix.
  • 507 : Citrix Config Sync Service a abandonné une importation car le système est en mode d’arrêt et le cache d’hôte local est utilisé pour la négociation de connexions. Le service a reçu une nouvelle configuration, mais l’importation a été abandonnée en raison d’une panne. Il s’agit du comportement attendu.

High Availability Service :

  • 3502 : une panne s’est produite et le broker secondaire (High Availability Service) effectue les opérations de négociation.
  • 3503 : une panne a été résolue et le fonctionnement normal est rétabli.
  • 3504 : indique le broker secondaire qui a été sélectionné, ainsi que les autres brokers impliqués dans la sélection.

Forcer une interruption

Vous pouvez souhaiter délibérément forcer une interruption.

  • Si votre réseau s’interrompt et reprend de manière répétée. Forcer une panne jusqu’à la résolution des problèmes réseau empêche le basculement en continu entre les modes de fonctionnement normal et de panne (et les fréquents enregistrements de VDA qui en résultent).
  • Pour tester un plan de récupération d’urgence.
  • Pour vous assurer que le cache d’hôte local fonctionne correctement.

Pour forcer une interruption, modifiez le registre de chaque serveur Cloud Connector. Dans HKLM\Software\Citrix\DesktopServer\LHC, définissez OutageModeForced sur 1. Ce réglage demande au broker d’entrer en mode d’interruption, quel que soit l’état de la connexion à Citrix Cloud. Si vous définissez la valeur sur 0, le broker sort du mode d’interruption.

Dépannage

Plusieurs outils de dépannage sont disponibles lorsque l’importation d’une synchronisation dans LocalDB échoue et qu’un événement 505 est signalé.

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

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

Pour activer et générer un rapport de traçage CSS, entrez la commande :

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

Le rapport HTML est publié sous 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