Cache d’hôte local
Pour vous assurer 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 ayant une tolérance aux pannes en suivant la haute disponibilité des meilleures pratiques de Microsoft. (La section Bases de données répertorie les fonctionnalités de haute disponibilité de SQL Server prises en charge). Toutefois, les utilisateurs peuvent ne pas être en mesure de se connecter à leurs applications ou bureaux à cause de problèmes et d’interruptions réseau.
La fonctionnalité Cache d’hôte local (LHC) permet aux opérations de négociation de connexions sur 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 local. Le cache de l’hôte local est activé lorsque la base de données du site est inaccessible pendant 90 secondes.
À partir de XenApp et XenDesktop version 7.16, la fonction de location de connexion (fonctionnalité de haute disponibilité 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 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 Citrix Receiver 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 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 et les chemins de communication du cache d’hôte local en fonctionnement normal.
En mode de fonctionnement normal :
- Le broker principal (Citrix Broker Service) sur un Controller accepte des requêtes de connexion provenant de StoreFront, et communique avec la base de données du site pour connecter les utilisateurs avec des VDA qui sont enregistrés avec le Controller.
- Une vérification est effectuée périodiquement (une minute après la fin de la vérification précédente) pour déterminer si des modifications ont été apportées à la configuration du broker principal. Ces modifications peuvent avoir été initiées par des actions PowerShell/Studio (telles que la modification d’une propriété de groupe de mise à disposition) ou des actions du système (telles que les attributions de machine).
- Si une modification a été apportée depuis la dernière vérification, le service Citrix Config Synchronizer Service (CSS) synchronise (copie) les informations sur le service Citrix High Availability Service du Controller. (Dans certaines documentations, le High Availability Service est appelé broker secondaire.) Toutes les données de configuration du broker sont copiées, pas seulement les éléments qui ont été modifiés depuis la vérification précédente. Le High Availability Service importe les données dans une base de données Microsoft SQL Server Express LocalDB sur le Controller. Le service CSS garantit que les informations de la base de données LocalDB correspondent aux informations de la base de données du site. La base de données LocalDB est recréée chaque fois que la synchronisation se produit.
- Si aucune modification n’a été apportée depuis la dernière vérification, aucune donnée n’est copiée.
Le graphique suivant illustre les modifications apportées aux chemins de communication si le broker principal perd le contact avec la base de données du site (une panne commence).
Lorsqu’une panne commence :
- Le broker principal ne peut plus communiquer avec la base de données du site, et arrête d’écouter les informations StoreFront et VDA (marque X dans le diagramme). Le broker principal demande ensuite au High Availability Service de démarrer l’écoute et le traitement des demandes de connexion (ligne en pointillés rouge dans le diagramme). Le High Availability Service rejette tous les appels du CSS.
- Lorsque la panne commence, le High Availability Service ne dispose d’aucune donnée d’enregistrement de VDA, mais dès qu’un VDA communique avec lui, un processus de ré-enregistrement est déclenché. Au cours de ce processus, le High Availability Service obtient également des informations de la session en cours sur ce VDA.
- Bien que ce soit le High Availability Service qui gère les connexions, le broker principal continue à surveiller la connexion à la base de données du site. Lorsque la connexion est rétablie, le broker principal demande au High Availability Service 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 de ré-enregistrement est déclenché. Le High Availability Service supprime les enregistrements de VDA de la panne précédente, et reprend la mise à jour de la base de données LocalDB avec les modifications de configuration reçues depuis CSS.
La transition entre le mode normal et le mode panne n’affecte pas les sessions existantes ; elle n’affecte que le lancement de nouvelles sessions.
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 contient des informations sur les synchronisations et les pannes. Consultez la section « Contrôle » ci-dessous pour plus de détails.
Vous pouvez également déclencher une panne volontairement ; veuillez consulter la section « Forcer une panne » ci-dessous pour plus de détails sur cette procédure.
Sites disposant de plusieurs Controller
Parmi ses différentes tâches, le service CSS fournit régulièrement au High Availability Service des informations sur tous les Controllers de la zone. (Si votre déploiement ne contient pas plusieurs zones, cette action affecte tous les Controllers du site). Ces informations permettent à chaque High Availability Service de connaître tous les High Availability Services homologues.
Les High Availability Services 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 High Availability Service 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 High Availability Service sélectionné. Les High Availability Services non sélectionnés dans la zone rejettent activement les requêtes de connexion et d’enregistrement de VDA entrantes.
Si un High Availability Service sélectionné échoue pendant une panne, un autre High Availability Service est choisi pour prendre le relais et les VDA se ré-enregistrent auprès du High Availability Service nouvellement sélectionné.
Durant une panne, si un Controller est redémarré :
- Si ce Controller n’est pas le broker principal sélectionné, le redémarrage n’a aucun impact.
- Si ce Controller est le broker principal sélectionné, un autre Controller est sélectionné, et par conséquent le VDA s’enregistre à nouveau. Une fois que le Controller redémarré est sous tension, il reprend automatiquement la négociation des connexions, et le VDA s’enregistre à nouveau. Dans ce scénario, les performances peuvent être affectées lors des ré-enregistrements.
Si vous mettez un Controller hors tension en fonctionnement normal et le remettez sous tension durant une panne, le cache d’hôte local ne peut pas être utilisé sur ce Controller s’il est sélectionné en tant que broker principal.
Le journal d’événements contient des informations sur les sélections. Consultez la section « Contrôle » ci-dessous.
Considérations relatives à la conception et configuration requise
Aucun délai n’est imposé pour le fonctionnement en mode panne. Toutefois, restaurez le site pour un fonctionnement normal le plus rapidement possible.
Fonctionnalités indisponibles durant une panne et autres différences
- Vous ne pouvez pas utiliser Studio ou exécuter des applets de commande PowerShell.
- 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.
- Une machine attribuée peut uniquement être utilisée si l’attribution s’est produite lors d’un fonctionnement normal. 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 lors du fonctionnement normal peuvent être utilisées.
- 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 zones différentes.
- Les utilisateurs peuvent lancer des applications et des bureaux uniquement à partir de VDA enregistrés dans la zone contenant le High Availability Service actuellement actif/sélectionné. Les lancements entre zones (depuis un High Availability Service dans une zone vers un VDA situé dans une autre zone) ne sont pas pris en charge durant une panne.
- Si une panne de base de données de site se produit avant le début d’un redémarrage programmé pour les VDA d’un groupe de mise à disposition, les redémarrages commencent à la fin de la panne. Cela peut donner des résultats inattendus. Pour plus d’informations, voir Redémarrages programmés retardés en raison d’une panne de la basede données.
- Les restrictions de balises dans lesquelles des 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 Contrôle avancé de l’état d’un magasin StoreFront est activée, le lancement des sessions peut échouer par intermittence.
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).
Par défaut, les VDA de bureau à alimentation gérée appartenant à des groupes de mise à disposition regroupés en pool (créés par MCS ou Citrix Provisioning) dont la propriété ShutdownDesktopsAfterUse est activée ne sont pas disponibles pour les nouvelles connexions lors d’un événement Cache d’hôte local. Vous pouvez modifier cette valeur par défaut pour autoriser l’utilisation de ces bureaux pendant le cache d’hôte local. Toutefois, vous ne pouvez pas compter sur la gestion de l’alimentation durant la panne. (La gestion de l’alimentation reprend une fois que les opérations normales reprennent.) En outre, ces bureaux peuvent contenir des données de l’utilisateur précédent, car ils n’ont pas été redémarrés.
Pour modifier le comportement par défaut, vous devez l’activer au niveau du site et pour chaque groupe de mise à disposition affecté. Exécutez les applets de commande PowerShell suivants.
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true
L’activation de cette fonctionnalité dans le site et les groupes de mise à disposition n’affecte pas le fonctionnement de la propriété « ShutdownDesktopsAfterUse » configurée en fonctionnement normal.
Important :
Si ReuseMachinesWithoutShutdownInOutageAllowed au niveau du site et ReuseMachinesWithoutShutdownInOutage au niveau du groupe de mise à disposition ne sont pas activés, toutes les tentatives de lancement de session vers les VDA de bureau dont l’alimentation est gérée dans des groupes de mise à disposition regroupés échoueront lors d’un événement Cache hôte local.
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 Controller, il se peut donc que vous deviez augmenter la quantité totale de capacité RAM.
Notez que 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 sur la configuration des sockets et des cœurs d’UC
Une configuration d’UC de Controller, notamment le nombre de cœurs disponibles pour SQL Server Express LocalDB, affecte directement les performances de 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 et l’espace disque est rétabli. Toutefois, le disque sur lequel la base de données LocalDB est installée doit avoir suffisamment d’espace 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 High Availability Service gère toutes les connexions ; dans les sites (ou zones) qui équilibrent la charge entre plusieurs Controllers en fonctionnement normal, le High Availability Service 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 seront plus nombreuses. Chaque High Availability Service du site (ou de la zone) doit être en mesure de gérer la charge supplémentaire imposée par la base de données LocalDB et tous les VDA concernés car le High Availability Service sélectionné lors d’une panne peut changer.
Limites de VDI :
- Dans un déploiement VDI à zone unique, jusqu’à 10 000 VDA peuvent être gérés efficacement au cours d’une panne.
- Dans un déploiement VDI multizone, jusqu’à 10 000 VDA par zone peuvent être gérés au cours d’une panne, avec un maximum de 40 000 VDA sur le site. Par exemple, chacun des sites suivants peut être géré de manière efficace durant 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.
Durant une panne, la gestion de la charge pour l’ensemble du site peut être affectée. Les calculateurs de charge (et plus particulièrement les règles du nombre de sessions) risquent d’être dépassés.
Pendant que tous les VDA s’enregistrent à nouveau avec un High Availability Service, il est possible que ce service 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 High Availability Service reçoit les informations de session depuis tous les VDA dans le cadre du ré-enregistrement) est inévitable. Notez que les sessions qui sont connectées lorsqu’une panne démarre 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 les VDA doivent se ré-enregistrer :
- Début d’une panne : lors de la migration depuis un broker principal vers un High Availability Service.
- Échec du High Availability Service lors d’une panne : lors de la migration d’un High Availability Service qui a échoué vers un High Availability Service nouvellement sélectionné.
- Reprise après une panne : lorsque les opérations normales reprennent, et que le broker principal reprend le contrôle.
Vous pouvez réduire cet intervalle en réduisant la valeur de registre HeartbeatPeriodMs de Citrix Broker Protocol (valeur par défaut=600000 ms, c’est-à-dire 10 minutes). Cette valeur de pulsation est le double de l’intervalle que le VDA utilise pour les pings, donc la valeur par défaut entraîne un ping toutes les 5 minutes.
Par exemple, la commande suivante règle la pulsation sur 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 de pulsation. L’augmentation de la fréquence entraîne une plus grande charge sur les Controllers pendant le mode normal et le mode panne.
L’intervalle ne peut pas être entièrement éliminé, quelle que soit la rapidité avec laquelle les VDA s’enregistrent.
Le temps nécessaire à la synchronisation entre les High Availability Services augmente avec le nombre d’objets (VDA, applications, groupes). Par exemple, la synchronisation de 5000 VDA peut prendre plus de dix minutes. Consultez la section Contrôle pour de plus amples informations sur les entrées de synchronisation dans le journal d’événements.
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 dsmaint pé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
Pour que le cache d’hôte local fonctionne correctement, la stratégie d’exécution de PowerShell sur chaque Controller doit être définie sur RemoteSigned, Unrestricted ou Bypass.
SQL Server Express LocalDB
La base de données Microsoft SQL Server Express LocalDB que le cache d’hôte local utilise est installée automatiquement lorsque vous installez un Controller ou mettez à niveau un Controller à partir d’une version antérieure à la version 7.9. Aucune maintenance administrateur n’est requise pour LocalDB. Seul le High Availability Service communique avec cette base de données. Vous ne pouvez pas utiliser les applets de commande PowerShell pour modifier quoi que ce soit dans cette base de données. La base de données LocalDB ne peut pas être partagée entre les Controllers.
Le logiciel de la 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 Delivery Controller à l’aide de la commande XenDesktopServerSetup.exe et ajoutez l’option /exclude "Local Host Cache Storage (LocalDB)". Cependant, n’oubliez pas 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 autre base de données avec le High Availability Service.
L’installation de cette base de données LocalDB ne détermine pas si vous devez installer SQL Server Express ou non pour l’utiliser en tant que base de données du 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 la section 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 7.16 au minimum), 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 le déploiement entier.
Activer/désactiver le cache d’hôte local
-
Pour activer le cache d’hôte local, entrez :
Set-BrokerSite -LocalHostCacheEnabled $truePour déterminer si le cache d’hôte local est activé, entrez :
Get-BrokerSiteVérifiez que la propriété LocalHostCacheEnabled est définie sur True.
-
Pour désactiver le cache d’hôte local, entrez :
Set-BrokerSite -LocalHostCacheEnabled $false
Rappel : à partir de XenApp and XenDesktop 7.16, la location de connexion (fonctionnalité antérieure au 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 déroulent correctement. Vérifiez les journaux d’événements.
- Assurez-vous que la base de données LocalDB SQL Server Express a été créée sur chaque Delivery Controller. Cela confirme que le High Availability Service 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 Controller. Après avoir vérifié que le cache d’hôte local fonctionne, n’oubliez pas de remettre tous les Controller en mode normal. Cela peut prendre environ 15 minutes pour éviter les pics d’enregistrement de VDA.
Forcer une interruption
Vous pouvez souhaiter délibérément forcer une interruption de la base de données.
- 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.
- Pour tester un plan de récupération d’urgence.
- Lorsque vous remplacez ou effectuez une maintenance sur le 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, définissez OutageModeForced comme REG_DWORD sur 1. Ce réglage demande au broker d’entrer en mode panne, quel que soit l’état de la base de données Si vous définissez la valeur sur 0, le serveur sort du mode panne.
Surveiller
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.
- 503 : une modification a été trouvée dans la configuration du broker principal et une importation démarre.
- 504 : la configuration du broker a été copiée, exportée, puis importée avec succès dans LocalDB.
- 505 : une ‘importation dans LocalDB a échoué ; consultez la section ci-dessous pour plus d’informations.
- 507 : une importation a été abandonnée en raison d’une panne. Lorsqu’une panne démarre pendant une synchronisation, l’importation en cours est annulée et la dernière configuration connue est utilisée.
- 510 : Aucune donnée de configuration du service de configuration reçue depuis le service de configuration principal.
- 517 : Un problème s’est produit lors de la communication avec le broker principal.
- 518 : Le script Config Sync a été abandonné car le Broker secondaire (High Availability Service) n’est pas en cours d’exécution.
High Availability Service :
- 3502 : une panne s’est produite et le 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 High Availability Service qui a été sélectionné, ainsi que les autres brokers impliqués dans la sélection.
Dépannage
Plusieurs outils de dépannage sont disponibles lorsque l’importation de la 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, sont susceptibles d’identifier le problème.
Rapport : vous pouvez générer et fournir un rapport détaillant le point d’échec. 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 :
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é, désactivez 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.