Cache d’hôte local
Pour garantir que la base de données du site XenApp et XenDesktop 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. (La section Bases de données de l’article (/fr-fr/xenapp-and-xendesktop/7-15-ltsr/system-requirements.html) répertorie les fonctionnalités de haute disponibilité de SQL Server prises en charge dans XenApp et XenDesktop.) Cependant, des problèmes et des interruptions de réseau peuvent empêcher les utilisateurs de se connecter à leurs applications ou bureaux.
La fonctionnalité Cache d’hôte local (LHC) permet aux opérations de courtage de connexion dans 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 d’hôte local s’active 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 de XenApp et XenDesktop. C’est une alternative plus puissante à la fonctionnalité de location de connexion introduite dans XenApp 7.6.
Bien que cette implémentation du cache d’hôte local partage le nom de la fonctionnalité de cache d’hôte local des versions XenApp 6.x et antérieures, elle présente 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 ; lisez la suite pour savoir comment il fonctionne.
Remarque :
Bien que la location de connexion 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 des droits sont spécifiquement 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 Remote PC Access) configurées dans le site.
- Identités (noms et adresses IP) des machines clientes Citrix Receiver™ activement utilisées pour se connecter aux ressources publiées.
Il contient également des informations pour les connexions actuellement actives qui ont été établies pendant que 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 et 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 Citrix Broker) sur un Controller accepte les requêtes de connexion de StoreFront et communique avec la base de données du Site pour connecter les utilisateurs aux VDA qui sont enregistrés auprès du Controller.
- Une vérification est effectuée toutes les deux minutes afin de 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 Delivery Group) ou des actions système (telles que les attributions de machines).
- Si une modification a été apportée depuis la dernière vérification, le broker principal utilise le service Citrix Config Synchronizer (CSS) pour synchroniser (copier) les informations vers un broker secondaire (service Citrix High Availability) sur le Controller. Toutes les données de configuration du broker sont copiées, pas seulement les éléments qui ont changé depuis la vérification précédente. Le broker secondaire importe les données dans une base de données Microsoft SQL Server Express LocalDB sur le Controller. Le 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 synchronisation.
- Si aucune modification n’est survenue depuis la dernière vérification, aucune donnée n’est copiée.
Le graphique suivant illustre les changements dans les 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 cesse d’écouter les informations StoreFront et VDA (marqué X dans le graphique). Le broker principal demande alors au broker secondaire (service High Availability) de commencer à écouter et à traiter les requêtes de connexion (marqué par une ligne pointillée rouge dans le graphique).
- Lorsqu’une panne commence, le broker secondaire ne dispose d’aucune donnée d’enregistrement VDA actuelle, mais dès qu’un VDA communique avec lui, un processus de réenregistrement est déclenché. Pendant ce processus, le broker secondaire obtient également les informations de session actuelles concernant ce VDA.
- Pendant que le broker secondaire gère les connexions, le broker principal continue de 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 d’écouter les informations de connexion, et le broker principal reprend les opérations de brokering. La prochaine fois qu’un VDA communique avec le broker principal, un processus de réenregistrement est déclenché. Le broker secondaire supprime toutes les enregistrements de VDA restants 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 du CSS.
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. Pour plus de détails, consultez la section « Surveiller » ci-dessous.
Vous pouvez également déclencher intentionnellement une panne ; consultez la section « Forcer une panne » ci-dessous 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 homologues.
Les brokers secondaires communiquent entre eux sur un canal distinct. Ils 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 sera en charge des opérations de brokering dans la zone en cas de panne. Pendant la panne, tous les VDA se réenregistrent auprès du broker secondaire élu. Les brokers secondaires non élus de la zone rejetteront 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 se réenregistreront auprès du broker secondaire nouvellement élu.
Pendant une panne, si un contrôleur est redémarré :
- Si ce contrôleur n’est pas le broker principal élu, le redémarrage n’a aucun impact.
- Si ce contrôleur est le broker principal élu, un contrôleur différent est élu, ce qui entraîne le réenregistrement des VDA. Une fois que le contrôleur redémarré démarre, il prend automatiquement en charge le brokering, ce qui entraîne un nouveau réenregistrement des VDA. Dans ce scénario, les performances peuvent être affectées pendant les ré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 principal.
Le journal des événements fournit des informations sur les élections. Consultez la section « Surveiller » ci-dessous.
Considérations et exigences de conception
Le cache d’hôte local est pris en charge pour les applications et bureaux hébergés sur serveur, ainsi que pour les bureaux statiques (attribués) ; il n’est pas pris en charge pour les bureaux VDI en pool (créés par MCS ou PVS).
Il n’y a pas de limite de temps imposée pour fonctionner en mode de panne. Cependant, rétablissez le fonctionnement normal du site aussi rapidement que possible.
Ce qui est indisponible ou change pendant une panne :
- Vous ne pouvez pas utiliser Studio ni exécuter de cmdlets PowerShell.
- Les informations d’identification de l’hyperviseur ne peuvent pas être obtenues 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 à distance 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 dans une zone vers un VDA dans une zone différente) ne sont pas pris en charge pendant une panne.
Par défaut, les VDA de bureau gérés par l’alimentation dans les groupes de mise à disposition en pool qui ont la propriété ShutdownDesktopsAfterUse activée sont placés en mode maintenance lorsqu’une panne se produit. Vous pouvez modifier ce comportement par défaut pour permettre l’utilisation de ces bureaux pendant une panne. Cependant, vous ne pouvez pas compter sur la gestion de l’alimentation pendant la panne. (La gestion de l’alimentation reprend après la reprise des opérations normales.) De plus, ces bureaux peuvent contenir des données de l’utilisateur précédent, car ils n’ont pas été redémarrés.
Pour annuler le comportement par défaut, vous devez l’activer à l’échelle du site et pour chaque groupe de mise à disposition concerné.
Pour le site, exécutez la cmdlet PowerShell suivante :
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true
Pour chaque groupe de mise à disposition concerné, exécutez la cmdlet PowerShell suivante :
Set-BrokerDesktopGroup -Name "\<*name*\>" -ReuseMachinesWithoutShutdownInOutage $true
L’activation de cette fonctionnalité sur le site et dans les groupes de mise à disposition n’affecte pas le fonctionnement de la propriété ShutdownDesktopsAfterUse configurée pendant les opérations normales.
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 service de haute disponibilité 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 la 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 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 CPU n’est observée que pendant la période de panne lorsque la base de données est inaccessible et que le service de haute disponibilité 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.
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é d’un Mo toutes les 2-3 minutes. Lorsque le fonctionnement normal reprend, la base de données locale est recréée et l’espace est libéré. Cependant, le broker doit disposer d’un espace suffisant 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 des E/S supplémentaires pendant une panne : environ 3 Mo d’écritures par seconde, avec plusieurs centaines de milliers de lectures.
Performances :
Pendant une panne, un seul broker gère toutes les connexions. Ainsi, dans les Sites (ou zones) qui équilibrent la charge entre plusieurs Controllers pendant les opérations normales, le broker élu pourrait avoir à gérer beaucoup plus de requêtes que la normale pendant une panne. Par conséquent, les demandes de CPU seront plus élevées. Chaque broker du Site (zone) doit être capable de gérer la charge supplémentaire imposée par LocalDB et tous les VDA affectés, car le broker élu pendant une panne pourrait 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 multi-zones, jusqu’à 10 000 VDA dans chaque 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 se réenregistrer auprès d’un broker, ce broker pourrait ne pas disposer d’informations complètes sur les sessions en cours. Ainsi, une demande de connexion utilisateur pendant cet intervalle pourrait entraîner le lancement d’une nouvelle session, même si la reconnexion à une session existante était possible. Cet intervalle (pendant lequel le “nouveau” broker acquiert les informations de session de tous les VDA lors du réenregistrement) est inévitable. Notez que 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 se réenregistrer auprès d’un broker différent :
- Début d’une panne : Lors de la migration d’un broker principal vers un broker secondaire.
- Défaillance du broker pendant une panne : Lors de la migration d’un broker secondaire défaillant vers un broker secondaire nouvellement élu.
- Reprise 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
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 augmente avec le nombre d’objets (tels que les VDA, les applications, les groupes). Par exemple, la synchronisation de 5000 VDA peut prendre dix minutes ou plus. Consultez la section “Surveillance” ci-dessous pour plus d’informations sur les entrées de synchronisation dans le journal des é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 PowerShell sur chaque contrôleur doit être définie sur RemoteSigned, Unrestricted ou Bypass.
SQL Server Express LocalDB
Le 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. Aucune maintenance administrative n’est nécessaire pour le LocalDB. 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. Le LocalDB ne peut pas être partagé 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 Controller à 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 ou non de SQL Server Express pour une utilisation en tant que base de données de site.
Paramètres par défaut après l’installation et 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 connexion est désactivée par défaut.)
Après une mise à niveau, le paramètre du cache d’hôte local reste inchangé. Par exemple, si le cache d’hôte local était activé dans la version précédente, il reste activé dans la version mise à niveau. Si le cache d’hôte local était désactivé (ou non pris en charge) dans la version précédente, il reste désactivé dans la version mise à niveau.
Activer et désactiver le cache d’hôte local
Pour activer le cache d’hôte local, saisissez :
Set-BrokerSite -LocalHostCacheEnabled $true -ConnectionLeasingEnabled $false
Cette cmdlet désactive également la fonctionnalité de location de connexion. N’activez pas à la fois le cache d’hôte local et la location de connexion.
Pour déterminer si le cache d’hôte local est activé, saisissez :
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), saisissez :
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 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 service de haute disponibilité 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, afin d’éviter les tempêtes d’enregistrement VDA.
Forcer une panne
Vous pourriez vouloir forcer délibérément une panne de base de données.
- Si votre réseau est constamment en panne et en ligne. 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.
- Pour tester un plan de reprise après sinistre.
- 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, définissez OutageModeForced sur 1. Cela indique au broker d’entrer en mode panne, quel que soit l’état de la base de données. (Définir la valeur sur 0 désactive le mode panne du serveur.)
- Dans un scénario Citrix Cloud™, le connecteur entre en mode panne, quel que soit l’état de la connexion au plan de contrôle ou à la zone principale.
Surveiller
Les journaux d’événements indiquent quand les synchronisations et les pannes se produisent.
Service de synchronisation de la configuration :
Pendant les opérations normales, les événements suivants peuvent se produire lorsque le CSS copie et exporte la configuration du broker et l’importe dans la base de données locale (LocalDB) à l’aide du service de haute disponibilité (broker secondaire).
- 503 : Une modification a été détectée dans la configuration du broker principal, et une importation est en cours de démarrage.
- 504 : La configuration du broker a été copiée, exportée, puis importée avec succès dans la base de données locale (LocalDB).
- 505 : Une importation vers la base de données locale (LocalDB) a échoué ; voir ci-dessous pour plus d’informations.
- 510 : Aucune donnée de configuration du service de configuration 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é :
- 3502 : Une panne s’est produite et le broker secondaire (service de haute disponibilité) effectue des opérations de brokering.
- 3503 : Une panne a été résolue et les opérations normales ont repris.
- 3504 : Indique quel broker secondaire est élu, ainsi que les autres brokers impliqués dans l’élection.
Dépannage
Plusieurs outils de dépannage sont disponibles lorsqu’une importation de synchronisation vers la LocalDB é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.
Dans cet article
- Contenu des données
- Fonctionnement
- Sites avec plusieurs contrôleurs
- Considérations et exigences de conception
- Gérer le cache d’hôte local
- SQL Server Express LocalDB
- Paramètres par défaut après l’installation et la mise à niveau de XenApp ou XenDesktop®
- Activer et désactiver le cache d’hôte local
- Vérifier que le cache d’hôte local fonctionne
- Forcer une panne
- Surveiller
- Dépannage