Product Documentation

Cache d’hôte local

Jun 20, 2017

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 dans un environnement Citrix local.
  • La liaison WAN entre le site et le plan de contrôle Citrix échoue dans un environnement cloud Citrix.

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.5 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.

Fonctionnement

Le graphique suivant illustre les composants et les chemins de communication du cache d'hôte local en fonctionnement normal.

localized image

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 Citrix Config Synchronizer Service (CSS) pour synchroniser (copier) les informations sur un broker secondaire (Citrix High Availability Service) sur le 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) :

localized image

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é.

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).

Il n’existe aucune limite de temps imposée pour le fonctionnement en mode panne. Toutefois, restaurez le site aussi 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.
  • Les machines avec VDA dans des groupes de mise à disposition regroupés qui sont configurés avec « Arrêt après utilisation » sont placées en mode de maintenance.
  • 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.

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.

Remarque : dans cette version, jusqu'à 5 000 VDA peuvent être gérés de manière efficace durant une panne.

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), mais l'intervalle ne peut pas être éliminé complètement, quelle que soit la vitesse à laquelle les VDA s'enregistrent. Par exemple, la commande suivante règle la pulsation sur cinq minutes (300000 millisecondes) : 

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

Le temps nécessaire à la synchronisation entre les brokers 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 » 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

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 Controller.

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.

Remarque : 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

Le tableau suivant illustre les paramètres de cache d'hôte local et de location de connexion après une nouvelle installation de XenApp ou XenDesktop, et après une mise à niveau vers XenApp ou XenDesktop 7.12 (ou une version ultérieure prise en charge).

Opération

Nombre de VDA

Location de connexion avant l'opération

Cache d'hôte local après l'opération

Location de connexion après l'opération

Installation

Quelconque

-

Désactivée

Activée

Mise à niveau

< 5000

Activée

Désactivée

Activée

Mise à niveau

< 5000

Désactivée

Activée

Désactivée

Mise à niveau

> 5000

Activée

Désactivée

Activée

Mise à niveau

> 5000

Désactivée

Désactivée

Désactivée

 

Installation : après une nouvelle installation de XenApp ou XenDesktop, le cache d'hôte local est désactivé et la location de connexion est activée par défaut. 

Mise à niveau : le nombre de VDA dans un site affecte le paramètre par défaut du cache d'hôte local après une mise à niveau. Le paramètre de location de connexion n'est pas modifié en raison de la mise à niveau.

Si votre site contient moins de 5 000 VDA :

  • Le cache d'hôte local est activé si la location de connexion a été désactivée avant la mise à niveau. La location de connexion reste désactivée.
  • Le cache d'hôte local est désactivé si la location de connexion a été activée avant la mise à niveau. La location de connexion reste activée.

Si votre site contient 5 000 VDA ou plus :

  • Le cache d'hôte local est désactivé (quel que soit le paramètre de location de connexion), et la location de connexion conserve le même paramètre qu'avant la 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

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.

Surveiller

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

Service de synchronisation de la configuration

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.

Service de haute disponibilité

  • 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 : 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 < nom_chemin_fichier>

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