Cache d’hôte local
Cet article fournit une vue d’ensemble exhaustive de la fonctionnalité Cache d’hôte local (LHC) et met l’accent sur sa capacité à assurer la continuité des activités. Il explique le fonctionnement du LHC à la fois pendant les opérations normales de fonctionnement et lorsque le mode LHC est activé. En outre, l’article fournit des conseils sur les vérifications de configuration, le dépannage, les commandes PowerShell pour la gestion du LHC et la surveillance de l’état d’intégrité du LHC avec les journaux d’événements.
Vue d’ensemble
Le LHC permet aux utilisateurs d’accéder aux applications et bureaux lors des pertes de connectivité entre les Cloud Connector et Citrix Cloud en raison d’une interruption du réseau ou d’un problème avec Citrix Cloud. Les sessions actives ne sont pas affectées lorsque le mode LHC est activé et que de nouvelles sessions sont négociées via le broker LHC exécuté sur les machines Cloud Connector.
Si le LHC est activé par défaut, il demeure important de s’assurer que votre environnement est correctement configuré pour utiliser cette fonctionnalité. Bien que les erreurs de configuration ne perturbent pas les opérations normales du broker, elles peuvent dégrader les performances du LHC et affecter ainsi les utilisateurs lorsque le mode LHC est actif. Pour garantir le fonctionnement optimal de la fonctionnalité LHC, accédez au nœud Zones dans Studio afin de vérifier si Citrix a détecté des erreurs et des avertissements relatifs aux zones. Consultez également le guide Vérifier les configurations de résilience et l’article Avoid Common Misconfigurations that Can Negative Impact DaaS Resiliency pour obtenir une liste de contrôle complète de la configuration du LHC.
Important :
Le LHC ne s’active que si les machines Cloud Connector reçoivent du trafic de StoreFront ou si la continuité du service est activée. Pour plus d’informations sur l’utilisation de la continuité du service et du cache d’hôte local pour maintenir l’accès des utilisateurs aux applications et bureaux en cas d’interruption de service, consultez Continuité du service.
Fonctionnement
Pendant les opérations normales, le service Remote Broker Provider exécuté sur un Cloud Connector communique avec Citrix Cloud pour toutes les opérations de négociation. Le service Citrix Config Synchronizer (CSS) vérifie régulièrement les modifications de configuration dans Citrix Cloud et synchronise ces données avec le broker LHC exécuté sur le Cloud Connector. Si la connectivité est perdue entre les Cloud Connector et Citrix Cloud ou si Citrix Cloud rencontre un problème, le mode LHC s’active et garantit un accès continu aux applications et bureaux.
Pendant les opérations de négociation normales
- Le service Citrix Remote Broker Provider exécuté sur un Cloud Connector accepte les demandes de connexion provenant de StoreFront. Le service Remote Broker Provider communique avec Citrix Cloud pour connecter les utilisateurs aux VDA enregistrés auprès de Citrix Cloud.
- Toutes les 5 minutes environ, le CSS vérifie auprès du broker Cloud dans Citrix Cloud si des modifications de configuration ont été apportées. Ces modifications peuvent avoir été initiées par un administrateur (telles que la modification d’une propriété de groupe de mise à disposition) ou être des actions du système (telles que les attributions de machine).
-
Si une modification de configuration est survenue depuis la vérification précédente, le CSS synchronise les informations avec le broker LHC exécuté sur le Cloud Connector. (Le broker LHC est également appelé « High Availability Service », ou broker HA).
Toutes les données de configuration sont copiées, et pas seulement les éléments qui ont été modifiés depuis la dernière vérification. Le CSS importe les données de configuration dans une base de données Microsoft SQL Server Express LocalDB sur le Cloud Connector. Cette base de données est appelée base de données du cache d’hôte local. Le service CSS s’assure que les informations de la base de données du cache d’hôte local du broker secondaire correspondent aux informations de la base de données du site dans Citrix Cloud.
Microsoft SQL Server Express LocalDB (utilisé par la base de données LHC) est installé automatiquement lorsque vous installez un Cloud Connector. La base de données du LHC ne peut pas être partagée entre les Cloud Connector. Il n’est pas nécessaire de sauvegarder la base de données LHC. Elle est recréée chaque fois qu’une modification de la configuration est détectée.
- Si aucune modification n’a été apportée depuis la dernière vérification, les données de configuration ne sont pas copiées.
Lorsque le mode LHC est activé
- Le broker LHC commence à écouter les informations de connexion et à traiter les demandes de connexion.
- Lorsque les Cloud Connector perdent leur connectivité à Citrix Cloud pour la première fois, le broker LHC ne dispose pas des données d’enregistrement actuelles du VDA, mais lorsqu’un VDA communique avec lui, un processus d’enregistrement est déclenché. Au cours de ce processus, le broker LHC obtient également les informations de session en cours pour ce VDA.
- Pendant que le broker LHC gère les connexions, le service Remote Broker Provider continue de surveiller la connexion à Citrix Cloud. Lorsque la connexion est rétablie, le service Remote Broker Provider demande au broker LHC de cesser d’écouter les informations de connexion, et Citrix Cloud reprend ses opérations de négociations. La prochaine fois qu’un VDA communiquera avec Citrix Cloud via le service Remote Broker Provider, un processus d’enregistrement sera déclenché. Le broker LHC supprime tous les enregistrements VDA restants lorsque le mode LHC était actif. Le service CSS reprend la synchronisation des informations lorsqu’il détecte des modifications de la configuration dans Citrix Cloud.
Dans le cas peu probable où le LHC démarrerait pendant une synchronisation, l’importation en cours est annulée et la dernière configuration connue est utilisée.
Le journal des événements consigne les synchronisations et les activations du mode LHC.
Aucun délai n’est imposé pour le fonctionnement en mode LHC.
Vous pouvez également déclencher manuellement le mode LHC. Consultez la section Forcer le mode LHC pour en savoir plus sur les raisons et les modalités de cette opération.
Zones dotées de plusieurs Cloud Connector
Parmi ses différentes tâches, le CSS fournit régulièrement au broker LHC des informations sur tous les Cloud Connector de la zone. Grâce à ces informations, chaque broker LHC connaît tous les brokers LHC homologues qui s’exécutent sur d’autres machines Cloud Connector de la zone.
Les brokers LHC communiquent entre eux sur un canal distinct. Ces brokers utilisent une liste alphabétique des noms de domaine complet des machines sur lesquelles ils s’exécutent pour déterminer (sélectionner) le broker LHC qui effectuera les opérations de négociation dans la zone si celle-ci passe en mode LHC. En mode LHC, tous les VDA se réenregistrent auprès du broker LHC sélectionné. Les brokers LHC non sélectionnés dans la zone rejettent activement les demandes de connexion entrantes et d’enregistrement de VDA.
Important :
Les connecteurs d’une zone doivent pouvoir communiquer entre eux à l’adresse
http://<FQDN_OF_PEER_CONNECTOR>:80/Citrix/CdsController/ISecondaryBrokerElection
. S’ils ne peuvent pas communiquer à cette adresse, plusieurs brokers peuvent être sélectionnés et des échecs de lancement peuvent survenir en mode LHC.
En mode LHC, si un Cloud Connector est redémarré ou si le broker LHC tombe en panne :
- Si ce Cloud Connector n’est pas le broker LHC sélectionné, le redémarrage n’a aucun impact.
- Si ce Cloud Connector est le broker sélectionné, le broker LHC du Cloud Connector suivant est sélectionné, ce qui déclenche l’enregistrement des VDA. L’ordre de sélection dépend de la position du nom de domaine complet des Cloud Connector dans la liste alphabétique. Une fois que le broker LHC redevient actif, les opérations LHC se poursuivent sur le premier connecteur de la liste alphabétique, ce qui peut entraîner un nouvel enregistrement des VDA. Dans ce scénario, les performances peuvent être affectées lors des enregistrements.
Pour plus d’informations sur les événements liés aux sélections de brokers LHC, consultez les journaux d’événements.
Contenu des données du cache d’hôte local
La base de données LHC contient les données suivantes, qui constituent un sous-ensemble des données de la base de données principale :
- Identités des utilisateurs et des groupes auxquels sont attribués des droits sur les ressources publiées à partir du site.
- Identités des utilisateurs qui utilisent actuellement ou ont récemment utilisé des ressources publiées à partir du site.
- Identités des machines VDA (y compris les machines Remote PC Access) configurées sur le site.
- Identités (noms et adresses IP) des machines de l’application Citrix Workspace utilisées activement pour se connecter aux ressources publiées.
Elle contient également les informations suivantes concernant les connexions actives qui ont été établies en mode LHC :
- Résultats de toute analyse de point de terminaison de machine client réalisée par l’application Citrix Workspace.
- Identités des machines d’infrastructure (telles que les serveurs Citrix Gateway et StoreFront) impliquées dans le site.
- Dates, heures et types d’activités récentes des utilisateurs
États du cache d’hôte local
Il existe plusieurs états tout au long du cycle d’entrée et de sortie du mode LHC. Le schéma suivant décrit les états d’entrée et de sortie du mode LHC.
- Pendant l’état Fonctionnement normal, l’intégrité de tous les composants est satisfaisante et toutes les transactions de négociation sont gérées par le broker Cloud. - - Le CSS reproduit activement les configurations du broker Cloud sur les Cloud Connector. En cas d’échec à l’une des vérifications de l’intégrité, les machines Cloud Connector passent à l’état HA en attente. Lors du passage à cet état, une vérification de l’intégrité complète est lancée pour déterminer les mesures à prendre. Tous les connecteurs de la zone communiquent entre eux pour déterminer leur état d’intégrité.
- La décision de passer de l’état HA en attente à l’état HA initial dépend de l’état d’intégrité de tous les connecteurs d’une zone donnée. En cas de réussite aux vérifications de l’intégrité, les connecteurs/contrôleurs repassent à l’état Fonctionnement normal. En cas d’échecs répétés aux vérifications de l’intégrité, les connecteurs/contrôleurs passent à l’état HA initial.
- Pendant l’état HA initial, le broker LHC exécuté sur le connecteur sélectionné se charge des négociations. Tous les VDA de la zone actuelle déjà enregistrés s’enregistreront alors auprès du broker LHC exécuté sur le Cloud Connector. Le réenregistrement de tous les VDA auprès du service HA peut prendre jusqu’à 5 minutes. À la sortie de l’état HA initial, des vérifications de l’intégrité sont lancées. En cas de réussite à ces vérifications, l’état passe à Restauration en attente. En cas d’échec, l’état passe à HA prolongé.
- Les vérifications de l’intégrité se poursuivent pendant toute la durée de l’état HA prolongé. Dès que les vérifications de l’intégrité renvoient une réussite, l’état HA prolongé passe à l’état Restauration en attente. Il n’y a pas de durée maximale pendant laquelle un connecteur reste à l’état HA prolongé.
- L’état Restauration en attente sert de période tampon pour rétablir l’intégrité complète des services avant la sortie du mode LHC. En cas d’échec à l’une des vérifications de l’intégrité pendant la période à l’état Restauration en attente, l’état redevient HA prolongé.
- En cas de réussite à toutes les vérifications de l’intégrité effectuées tout au long de la période de 10 minutes à l’état Restauration en attente, l’état passe à Fonctionnement normal. Le passage à cet état déclenche la sortie du mode LHC. Tous les VDA de la zone qui étaient enregistrés auprès du broker LHC se réenregistrent alors auprès du broker Cloud. Là encore, ce réenregistrement peut prendre jusqu’à 5 minutes.
Considérations importantes concernant le mode LHC
En mode LHC, vous devez tenir compte des impacts suivants :
Aspect | Impact pendant le mode LHC |
---|---|
Accès à Studio | Peut être inaccessible, selon la nature de la perturbation. Les VDA situés dans des zones fonctionnant en mode LHC s’affichent comme étant non enregistrés dans Studio, car ils sont enregistrés auprès du broker LHC. |
Accès à distance au SDK PowerShell
|
Accès limité. Nécessite l’activation du mode de test de CSS et la configuration de l’authentification du SDK. Pour activer le mode de test de CSS : ajoutez la clé de registre. Définissez « EnableCssTestMode » avec une valeur DWORD de « 1 » sous HKLM:\SOFTWARE\Citrix\DesktopServer\LHC .
Pour définir l’authentification du SDK : définissez la variable $XDSDKAuth sur « OnPrem » pour empêcher le proxy du SDK de rediriger les appels d’applet de commande. Après avoir effectué ces modifications, vous pouvez utiliser toutes les applets de commande Get-Broker .
Remarque : incluez le paramètre -AdminAddress localhost:89 dans l’appel initial de l’applet de commande.
Exemple : Get-BrokerMachine -AdminAddress localhost:89
|
Données de surveillance | Les fonctions de Monitor ne fournissent aucune donnée d’activité à partir du moment où le mode LHC est actif. Toutefois, un sous-ensemble de données de surveillance est disponible dans le tableau de bord du cache d’hôte local sur la page Tendances de Monitor. |
Informations d’identification Hypervisor | Impossible à obtenir auprès du service hôte. Machines dans un état d’alimentation inconnu : aucune opération d’alimentation possible. Les machines virtuelles sous tension sont disponibles pour les connexions. |
Machines attribuées | Disponibles uniquement si elles sont attribuées pendant les opérations normales. Impossibilité, en mode LHC, d’assigner de nouvelles machines. |
Machines Remote PC Access | L’inscription et la configuration automatiques ne sont pas prises en charge. Les machines enregistrées et configurées pendant le fonctionnement normal sont utilisables. |
Limites de session des applications et bureaux hébergés sur serveur | Les utilisateurs peuvent utiliser plus de sessions que leurs limites de session configurées, si les ressources se trouvent dans des zones différentes. |
Comportement des zones | Chaque zone agit indépendamment. Si la fonctionnalité Vérification avancée de l’intégrité de StoreFront est activée, StoreFront peut acheminer les demandes de lancement vers la zone appropriée pendant le mode LHC et éviter ainsi les échecs de lancement de session. |
Redémarrages planifiés des VDA | Si le mode LHC se déclenche avant le début des redémarrages planifiés des VDA d’un groupe de mise à disposition, les redémarrages débutent lorsque le mode LHC prend fin et les opérations de négociation normales reprennent. Ces conditions peuvent provoquer des redémarrages inattendus lorsque la zone quitte le mode LHC. Pour plus d’informations, notamment sur les configurations susceptibles de modifier ce comportement, consultez Redémarrages planifiés différés en raison d’une interruption de base de données. |
Préférences de zone | Les configurations des préférences de zone ne sont pas prises en compte pour les lancements de session. |
Restrictions de balises | Lorsque les groupes de mise à disposition comportent des VDA dans plusieurs zones, les restrictions de balises peuvent entraîner des échecs de lancement si les VDA ne sont pas présents dans toutes les zones. |
Prise en charge des applications et des bureaux
Le mode LHC prend en charge les types de VDA et les modèles de mise à disposition suivants :
Type de VDA | Modèle de mise à disposition | Disponibilité des VDA en mode LHC |
---|---|---|
OS multi-session | Applications et bureaux | Toujours disponible. |
Système d’exploitation monosession statique (attribué) | Bureaux | Toujours disponible. |
Système d’exploitation mono-session à alimentation gérée aléatoire (regroupé)
|
Bureaux
|
Non disponible par défaut. Toutes les tentatives de lancement de session sur des VDA à alimentation gérée appartenant à des groupes de mise à disposition échoueront par défaut.
Vous pouvez rendre ces VDA disponibles pour de nouvelles connexions pendant le mode LHC. Pour plus d’informations, consultez Activation à l’aide de Studio et Activation à l’aide de PowerShell. Important :l’activation de l’accès à des machines mono-session regroupées à alimentation gérée peut entraîner la présence de données et de modifications issues des sessions utilisateur précédentes dans les sessions suivantes. |
Remarque
L’activation de l’accès aux VDA de bureau à alimentation gérée appartenant à des groupes de mise à disposition n’affecte pas le fonctionnement de la propriété
ShutdownDesktopsAfterUse
configurée pendant les opérations normales. Lorsque l’accès à ces bureaux en mode LHC est activé, les VDA ne redémarrent pas automatiquement après la reprise des opérations de négociation normales. Les VDA de bureau à alimentation gérée et appartenant à des groupes de mise à disposition mis en pool peuvent conserver les données des sessions précédentes jusqu’au redémarrage du VDA. Un redémarrage du VDA peut se produire lorsqu’un utilisateur ferme sa session pendant des opérations autres que le LHC ou lorsque les administrateurs redémarrent le VDA.
Activer le mode LHC pour les VDA à OS mono-session et alimentation gérée mis en pool à l’aide de Studio
L’utilisation de Studio permet de rendre ces machines disponibles pour de nouvelles connexions en mode LHC, par groupe de mise à disposition :
- Pour activer cette fonctionnalité lors de la création de groupes de mise à disposition, consultez Créer des groupes de mise à disposition.
- Pour activer cette fonctionnalité pour un groupe de mise à disposition existant, consulter Gérer les groupes de mise à disposition
Remarque
Ce paramètre n’est disponible dans Studio que pour les groupes de mise à disposition de bureaux regroupés qui fournissent des VDA à alimentation gérée.
Activer le mode LHC pour les VDA à OS mono-session et alimentation gérée mis en pool à l’aide de PowerShell
Pour activer le mode LHC pour des VDA appartenant à un groupe de mise à disposition spécifique, procédez comme suit :
-
Activez cette fonctionnalité au niveau du site en exécutant cette commande :
Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true <!--NeedCopy-->
-
Activez le mode LHC pour un groupe de mise à disposition en exécutant cette commande avec le nom du groupe de mise à disposition spécifié comme suit :
Set-BrokerDesktopGroup -Name "name" -ReuseMachinesWithoutShutdownInOutage $true <!--NeedCopy-->
Pour modifier la disponibilité par défaut du mode LHC pour les groupes de mise à disposition mis en pool récemment créés avec des VDA à alimentation gérée, exécutez la commande suivante :
Set-BrokerSite -DefaultReuseMachinesWithoutShutdownInOutage $true
<!--NeedCopy-->
Remarque
La modification de la valeur par défaut ne modifie pas le paramètre des groupes de mise à disposition existants. Elle n’affecte que les groupes de mise à disposition créés à l’aide de PowerShell.
Configuration du StoreFront
Si vous utilisez un déploiement StoreFront local, vérifiez les points suivants :
- Si vous utilisez un serveur virtuel d’équilibrage de charge, configurez-le pour surveiller les connecteurs en fonction des fonctionnalités de broker (par exemple, utilisez le moniteur CITRIX-XD-DDC intégré sur un NetScaler pour équilibrer les charges des connecteurs).
- Incluez tous les Cloud Connector d’un même locataire cloud sous la dans un seul flux de ressources dans StoreFront.
- Consultez Configurations de NetScaler Gateway dans la rubrique StoreFront et assurez-vous que tous les connecteurs sont répertoriés en tant que serveurs STA. Passez en revue les appliances NetScaler et assurez-vous que tous les STA répertoriés dans StoreFront sont au même format que sur le serveur virtuel NetScaler Gateway. L’intégrité du service STA peut également être surveillée sur le serveur virtuel Gateway.
- Ajoutez tous les connecteurs au flux de ressources dans StoreFront et assurez-vous que StoreFront peut communiquer avec tous les Cloud Connector via le port désigné dans le flux de ressources.
Remarque
Pour les clients disposant de nombreux connecteurs, il peut être avantageux de configurer un serveur virtuel d’équilibrage de charge pour chaque zone afin de réduire les frais de gestion et de simplifier le dépannage. Pour plus d’informations, consultez l’article Citrix TIPS : Integrating Citrix Virtual Apps and Desktops service et StoreFront.
Valider le fonctionnement du cache d’hôte local
Pour vérifier que le LHC est configuré et fonctionne correctement :
- Assurez-vous que les importations de synchronisation se déroulent correctement. Consultez les journaux d’événements pour en savoir plus sur les méthodes de surveillance des synchronisations LHC.
- Assurez-vous que la base de données Cache hôte local a été créée sur chaque Cloud Connector. Cela confirme que le High Availability Service peut prendre le relais, si nécessaire.
- Sur le serveur Cloud Connector, accédez à
c:\Windows\ServiceProfiles\NEtworkService
. - Vérifiez que
HaDatabaseName.mdf
etHaDatabaseName_log.ldf
sont créés.
- Sur le serveur Cloud Connector, accédez à
- Forcez le mode LHC sur tous les Cloud Connector de la zone : après avoir vérifié que le cache d’hôte local fonctionne, pensez à rétablir le mode de fonctionnement normal de tous les Cloud Connector. Consultez la section États du mode Cache d’hôte local pour plus d’informations sur le temps nécessaire à la sortie du mode LHC.
Surveiller le cache d’hôte local
Journaux d’événements
Les journaux d’événements fournissent des informations essentielles concernant l’état et les performances du cache d’hôte local.
Service de synchronisation de la configuration
En fonctionnement normal, les événements suivants peuvent se produire lorsque le CSS importe les données de configuration dans la base de données LHC à l’aide du broker LHC.
ID d’événement | Description |
---|---|
503 | Indique que le CSS a reçu une configuration mise à jour. Cet événement se produit chaque fois qu’une configuration mise à jour est reçue depuis Citrix Cloud. Cela indique le début du processus de synchronisation. |
504 | Indique que le CSS a importé une configuration mise à jour. L’importation de la configuration s’est terminée avec succès. |
505 | Indique un échec d’importation par le CSS. L’importation de la configuration n’a pas réussi. Si une configuration précédente réussie est disponible, elle est utilisée lorsque le mode LHC est activé. Cependant, elle sera obsolète à partir de la configuration actuelle. Si aucune configuration précédente n’est disponible, le service ne peut pas participer à la négociation de session en mode LHC. Dans ce cas, consultez la section Dépannage et contactez le support Citrix. |
507 | Indique que le CSS a abandonné une importation parce que le système est en mode LHC et que le broker LHC est utilisé pour le la négociation. Le service a reçu une nouvelle configuration, mais l’importation a été abandonnée en raison de l’entrée en mode LHC. Il s’agit du comportement attendu. |
510 | Indique qu’aucune donnée de configuration CSS n’a été reçue du service de configuration principal. |
517 | Indique qu’un problème est survenu lors de la communication avec le service Remote Broker Provider. |
518 | Indique que le script CSS a été abandonné car le broker LHC (High Availability Service) n’est pas en cours d’exécution. |
Service de haute disponibilité
Ce service est également connu sous le nom de broker LHC.
ID d’événement | Description |
---|---|
3502 | Indique qu’une panne s’est produite et que le broker LHC effectue des opérations de négociation. |
3503 | Indique qu’une panne a été résolue et que le fonctionnement normal est rétabli. |
3504 | Indique le broker LHC qui est sélectionné et les autres brokers LHC impliqués dans la sélection. |
3507 | Indique que le mode LHC est actif sur le broker LHC sélectionné. Contient un résumé de la panne, notamment sa durée, l’enregistrement du VDA et les informations de session. |
3508 | Indique que le LHC n’est plus actif sur le broker LHC sélectionné et que le fonctionnement normal a été rétabli. Fournit un résumé de l’interruption, notamment sa durée, le nombre de machines enregistrées lors de l’événement LHC et le nombre de lancements réussis en mode LHC. |
3509 | Indique que le LHC est actif sur le broker LHC non sélectionné. Indique la durée de l’interruption toutes les 2 minutes, ainsi que le broker LHC sélectionné. |
3510 | Indique que le LHC n’est plus actif sur le broker LHC non sélectionné. Indique la durée de l’interruption, ainsi que le broker LHC sélectionné. |
Remote Broker Provider
Ce service fait office de proxy entre Citrix Cloud, vos VDA et les Cloud Connector.
ID d’événement | Description |
---|---|
3001 | Vérifie si les Cloud Connector doivent passer en mode LHC. Survient après l’échec d’une seule vérification de l’intégrité du Cloud Connector. En cas d’échec à la prochaine vérification de l’intégrité au bout de 60 secondes, le Cloud Connector passe en mode LHC. |
3002 | Indique que le Cloud Connector ne peut pas passer en mode LHC. La raison est incluse dans les informations relatives à l’événement. |
3003
|
Indique que le Cloud Connector est en train de passer à différents états du mode LHC. L’événement fournit des informations sur les points suivants
|
Remarque
Les événements 3001 qui se produisent régulièrement sur les Cloud Connector tout au long de la journée ne sont généralement pas une source de préoccupation. Cependant, s’ils se produisent plusieurs fois par heure, cela indique un problème de réseau et peut justifier une enquête plus approfondie.
Citrix Monitor
Citrix Monitor contient des informations centralisées concernant les entrées en mode LHC et les performances des différentes zones de votre environnement.
Pour plus d’informations, consultez Surveiller les tendances historiques d’un site.
Forcer le mode Cache d’hôte local
Vous souhaiterez peut-être forcer le mode Cache d’hôte local dans les scénarios suivants :
- Si votre réseau s’interrompt et reprend de manière répétée : le fait de forcer le mode LHC jusqu’à ce que les problèmes de réseau soient résolus empêche les transitions continues entre le mode de fonctionnement normal et le mode LHC (et les pics fréquents d’enregistrements de VDA qui en résultent).
- Pour tester un plan de récupération d’urgence.
- Pour vous assurer que le cache d’hôte local fonctionne correctement.
Pour forcer le mode LHC :
-
Modifiez le registre de chaque serveur Cloud Connector dans
HKLM\Software\Citrix\DesktopServer\LHC
: créezOutageModeForced
et définissez REG_DWORD sur1
.- La définition de la valeur sur
1
indique au broker LHC de passer en mode LHC, quel que soit l’état de la connexion à Citrix Cloud. - La définition de la valeur sur
0
indique au broker LHC de quitter le mode LHC et de reprendre son fonctionnement normal.
- La définition de la valeur sur
Pour vérifier les événements :
- Surveillez le fichier journal
Current_HighAvailabilityService
dansC:\ProgramData\Citrix\workspaceCloud\Logs\Plugins\HighAvailabilityService
.
Résoudre les problèmes de synchronisation d’importation
Lorsqu’une synchronisation d’importation vers la base de données du LHC échoue et qu’un événement 505 est enregistré, vous pouvez utiliser les outils de résolution des problèmes suivants :
- Suivi CDF :
- Activer le traçage pour les modules
ConfigSyncServer
etBrokerLHC
. - À utiliser avec d’autres modules de broker pour identifier le problème.
- Activer le traçage pour les modules
- Rapport de suivi CSS :
-
Génère un rapport détaillé qui identifie l’objet à l’origine de l’échec de synchronisation.
Remarque
L’activation de ce rapport peut avoir un impact sur la vitesse de synchronisation. Désactivez-le si vous ne résolvez pas activement des problèmes.
Pour activer et générer un rapport de suivi CSS :
-
Activer les rapports : exécutez la commande suivante :
New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -PropertyType DWORD -Value 1 <!--NeedCopy-->
-
Localiser le rapport : le rapport HTML est généré dans
C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\CitrixBrokerConfigSyncReport.html
. -
Désactiver les rapports : une fois le rapport généré, exécutez la commande suivante pour désactiver la fonctionnalité de création de rapports :
Set-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTraceMode -Value 0 <!--NeedCopy-->
-
Commandes PowerShell du cache d’hôte local
Vous pouvez gérer le cache d’hôte local sur vos Cloud Connector à l’aide des commandes PowerShell.
Le module PowerShell se trouve à l’emplacement suivant sur les Cloud Connector :
C:\Program Files\Citrix\Broker\Service\ControlScripts
Important :
Exécutez ce module uniquement sur les Cloud Connector.
Importer le module PowerShell
Pour importer le module, exécutez la commande suivante sur votre Cloud Connector :
Import-Module "C:\Program Files\Citrix\Broker\Service\ControlScripts\HighAvailabilityServiceControl.psm1
<!--NeedCopy-->
Commandes PowerShell pour gérer le cache d’hôte local (LHC)
Les applets de commande suivantes vous aident à activer et à gérer le mode LHC sur les Cloud Connectors.
Applets de commande | Fonction |
---|---|
Enable-LhcForcedOutageMode |
Permet de placer le broker en mode LHC. Les fichiers de base de données du cache d’hôte local doivent avoir été créés avec succès par le CSS pour que Enable-LHCForcedOutageMode fonctionne correctement. Cette applet de commande force uniquement le LHC sur le Cloud Connector sur lequel il a été exécuté. Pour que le mode LHC s’active, cette applet de commande doit être exécutée sur tous les Cloud Connector de la zone. |
Disable-LhcForcedOutageMode |
Permet de faire sortir le broker du mode LHC. Cette applet de commande désactive uniquement le mode LHC sur le Cloud Connector sur lequel elle a été exécutée. La commande Disable-LhcForcedOutageMode doit être exécutée sur tous les Cloud Connector de la zone. |
Set-LhcConfigSyncIntervalOverride |
Définit l’intervalle auquel CSS vérifie les modifications de configuration sur le site Citrix DaaS. L’intervalle de temps peut aller de 60 secondes (une minute) à 3 600 secondes (une heure). Ce paramètre s’applique uniquement au Cloud Connector sur lequel il a été exécuté. Pour des raisons de cohérence entre les Cloud Connector, pensez à exécuter cette applet de commande sur chaque Cloud Connector. Par exemple : Set-LHCConfigSyncIntervalOverride -Sseconds 1200
|
Clear-LhcConfigSyncIntervalOverride |
Définit l’intervalle auquel CSS vérifie les modifications de configuration sur le site Citrix DaaS sur la valeur par défaut de 300 secondes (cinq minutes). Ce paramètre s’applique uniquement au Cloud Connector sur lequel il a été exécuté. Pour des raisons de cohérence entre les Cloud Connector, pensez à exécuter cette applet de commande sur chaque Cloud Connector. |
Enable-LhcHighAvailabilitySDK |
Permet d’accéder à toutes les applets de commande Get-Broker* dans le Cloud Connector sur lequel elles ont été exécutées. |
Disable-LhcHighAvailabilitySDK |
Désactive l’accès aux commandes PowerShell du broker dans le Cloud Connector sur lequel elles ont été exécutées. |
Remarque
- Utilisez le port 89 lorsque vous exécutez les applets de commande
Get-Broker*
sur le Cloud Connector. Par exemple :
Get-BrokerMachine -AdminAddress localhost:89
- Lorsqu’il n’est pas en mode LHC, le broker LHC du Cloud Connector ne contient que les informations de configuration.
- En mode LHC, le broker LHC détient les informations suivantes :
- États des ressources
- Détails de la session
- Enregistrements de VDA
- Informations de configuration
Informations supplémentaires
-
Voir Considérations sur le dimensionnement et la scalabilité du cache d’hôte local pour plus d’informations sur :
- Méthodes d’essai et résultats
- Considérations sur la taille de la RAM
- Considérations sur la configuration des sockets et des cœurs d’UC
- Considérations sur le stockage
Dans cet article
- Vue d’ensemble
- Fonctionnement
- Contenu des données du cache d’hôte local
- États du cache d’hôte local
- Considérations importantes concernant le mode LHC
- Valider le fonctionnement du cache d’hôte local
- Surveiller le cache d’hôte local
- Citrix Monitor
- Forcer le mode Cache d’hôte local
- Résoudre les problèmes de synchronisation d’importation
- Informations supplémentaires