Cache d’hôte local
Pour vous assurer que la base de données du site XenApp et XenDesktop 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 dans l’article Configuration système requise répertorie les fonctionnalités de haute disponibilité de SQL Server prises en charge dans XenApp et XenDesktop). 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 XenApp ou XenDesktop 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. Le cache de l’hôte local est activé lorsque la base de données du site est inaccessible pendant 90 secondes.
Le cache d’hôte local est la fonctionnalité de haute disponibilité la plus complète dans XenApp et XenDesktop. Il s’agit de la plus puissante solution alternative à la fonctionnalité de location de connexion, qui a été introduite dans XenApp 7.6.
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 ; lisez la section suivante pour savoir comment il fonctionne.
Remarque :
Bien que la location de connexions soit prise en charge dans la version 7.15 LTSR, elle sera supprimée dans la version suivante.
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 toutes les deux minutes 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 broker principal utilise le service Citrix Config Synchronizer Service (CSS) pour synchroniser (copier) les informations sur un broker secondaire (service Citrix High Availability Service) du Controller. Toutes les données de configuration du broker 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 Controller. Le service CSS garantit que les informations de la base de données LocalDB du broker secondaire 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 broker secondaire (High Availability Service) de démarrer l’écoute et le traitement des demandes de connexion (ligne en pointillés rouge dans le diagramme).
- Lorsque la panne commence, le broker secondaire 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 broker secondaire obtient également des informations de session sur ce VDA.
- Bien que ce soit le broker secondaire 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 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 de ré-enregistrement est déclenché. Le broker secondaire 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.
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 broker secondaire des informations sur tous les Controller de la zone (si votre déploiement ne contient pas plusieurs zones, cette action affecte tous les Controller du site). 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 se ré-enregistrent auprès du broker secondaire qui vient d’être 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
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 regroupés (créés par MCS ou PVS).
Aucun délai n’est imposé pour le fonctionnement en mode panne. Toutefois, restaurez le site pour un fonctionnement normal le plus rapidement possible.
Disponibilités ou changements au cours d’une panne :
- 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 bureaux uniquement à partir de VDA enregistrés dans la zone contenant le broker (secondaire) actuellement actif/sélectionné. Les lancements entre zones (depuis un broker dans une zone vers un VDA situé dans une autre zone) ne sont pas pris en charge durant une panne.
Par défaut, 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. Vous pouvez modifier ce comportement par défaut pour autoriser ces bureaux à être utilisés lors d’une panne. 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é.
Pour le site, exécutez l’applet de commande PowerShell suivante :
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Pour chaque groupe de mise à disposition affecté, exécutez l’applet de commande PowerShell suivante :
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.
Taille de 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.
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.
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 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.
Performances :
Durant une panne, un seul broker gère toutes les connexions ; dans les sites (ou zones) qui équilibrent la charge entre plusieurs Controller en fonctionnement normal, 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 seront plus nombreuses. Chaque broker 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 broker 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 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 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 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.
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
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 brokers augmente avec le nombre d’objets (VDA, applications, groupes) Par exemple, la synchronisation de 5 000 VDA peut prendre plus de dix minutes. Consultez la section « Contrôle » ci-dessous pour de plus amples informations sur les entrées de synchronisation dans le journal d’événements.
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 broker secondaire communique avec cette base de données ; vous ne pouvez pas utiliser les applets de commande PowerShell pour modifier quoi que ce soit sur 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 broker secondaire.
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.
Paramètres par défaut après l’installation ou la mise à niveau de XenApp ou XenDesktop
Lors d’une nouvelle installation de XenApp et XenDesktop, le cache d’hôte local est activé par défaut. (La location de connexions est activée par défaut.)
Après une mise à niveau, le paramètre de cache d’hôte local est inchangé. Par exemple, si le cache d’hôte local a été activé dans la version antérieure, il reste activé dans la version mise à niveau. Si le cache d’hôte local a été désactivé (ou qu’il n’est pas pris en charge) dans la version antérieure, il reste désactivé dans la version mise à niveau.
Activer/désactiver le cache d’hôte local
Pour activer le cache d’hôte local, entrez :
Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false
Cette applet de commande désactive également la fonctionnalité de location de connexion. N’activez pas le cache d’hôte local et la location de connexion en même temps.
Pour déterminer si le cache d’hôte local est activé, entrez :
Get-BrokerSite
Vérifiez que la propriété LocalHostCacheEnabled est True, et que la propriété ConnectionLeasingEnabled est False.
Pour désactiver le cache d’hôte local (et activer la location de connexion), entrez :
Set-BrokerSite -LocalHostCacheEnabled $false -ConnectionLeasingEnabled $true
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 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.)
- Dans un scénario Citrix Cloud, le connecteur entre en mode panne quel que soit l’état de la connexion avec le plan de contrôle ou la zone principale.
Surveillance
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 : 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.
- 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 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.
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 : 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 suivante :
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1
Le rapport HTML est publié sur 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.
Dans cet article
- Contenu des données
- Fonctionnement
- Sites disposant de plusieurs Controller
- Considérations relatives à la conception et configuration requise
- Gérer le cache d’hôte local
- SQL Server Express LocalDB
- Paramètres par défaut après l’installation ou la mise à niveau de XenApp ou XenDesktop
- Activer/désactiver le cache d’hôte local
- Vérifier que le cache d’hôte local fonctionne
- Forcer une interruption
- Surveillance
- Dépannage