Documentation produit
Citrix DaaS
Voir PDF

Cache d’hôte local

September 27, 2024
Contributeur: 
C

Conseil :

Dans le nœud Accueil de Studio, la fonction d’alertes d’intégrité du service vous envoie des alertes proactives pour vous assurer que le cache d’hôte local et les zones sont correctement configurés. Ainsi, en cas de panne, le cache d’hôte local fonctionne et vos utilisateurs ne sont pas affectés. Les alertes se répartissent en deux niveaux : les alertes à l’échelle du site affichées dans la page d’accueil (icône représentant un drapeau) et les alertes relatives aux zones affichées dans l’onglet Dépannage de chaque zone. Pour plus d’informations, consultez la section Zones.

Le mode de cache d’hôte local (LHC) permet de poursuivre les opérations de négociation de connexion dans un déploiement Citrix DaaS (anciennement Citrix Virtual Apps and Desktops Service) lorsqu’un composant Cloud Connector ne peut pas communiquer avec Citrix Cloud. Le cache d’hôte local est activé lorsque la connexion réseau est perdue pendant 60 secondes.

Grâce au cache d’hôte local, les utilisateurs qui sont connectés lorsqu’une panne se produit peuvent continuer à travailler sans interruption. Les délais des nouvelles connexions et des reconnexions sont réduits.

Important :

Si vous utilisez un déploiement StoreFront sur site, vous devez ajouter tous les Cloud Connector avec lesquels sont (ou peuvent être) enregistrés des VDA à StoreFront en tant que Delivery Controller. Un Cloud Connector qui n’est pas ajouté à StoreFront ne peut pas passer en mode panne, ce qui peut entraîner des échecs de lancement de l’utilisateur.

Pour les déploiements sans instance StoreFront locale, utilisez la fonctionnalité de continuité de la plate-forme Citrix Workspace pour permettre aux utilisateurs de se connecter aux ressources pendant les pannes. Pour plus d’informations, consultez Continuité du service.

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

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

Fonctionnement

Découvrez comment le cache d’hôte local interagit avec Citrix Cloud.

En mode de fonctionnement normal

Image de fonctionnement normal

  • Le broker principal (Citrix Remote Broker Provider Service) sur un Cloud Connector accepte des requêtes de connexion provenant de StoreFront. Le broker principal communique avec Citrix Cloud pour connecter les utilisateurs aux VDA qui sont enregistrés auprès du Cloud Connector.
  • Citrix Config Synchronizer Service (CSS) interroge le broker dans Citrix Cloud environ toutes les 5 minutes pour savoir si des modifications ont été apportées à la configuration. 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 la configuration a été modifiée depuis la dernière vérification, le service CSS synchronise (copie) les informations sur un broker secondaire sur le Cloud Connector. (Le broker secondaire est également connu sous le nom de service de haute disponibilité, ou HA Broker, comme indiqué dans la figure précédente.)

    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. La base de données du cache d’hôte local est recréée chaque fois que la synchronisation se produit.

    Microsoft SQL Server Express LocalDB (utilisé par la base de données du cache d’hôte local) est installé automatiquement lorsque vous installez un Cloud Connector. La base de données du cache d’hôte local ne peut pas être partagée sur des Cloud Connector. Vous n’avez pas besoin de sauvegarder la base de données du cache d’hôte local. 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.

Durant une panne

Image d'interruption

Lorsqu’une panne commence :

  • Le broker secondaire démarre l’écoute et traite les demandes de connexion.
  • Lorsque la panne commence, le broker secondaire ne dispose pas des données d’enregistrement de VDA, mais lorsqu’un VDA communique avec lui, un processus d’enregistrement est déclenché. Au cours de ce processus, le broker secondaire obtient également des informations de session sur ce VDA.
  • Bien que le broker secondaire gère les connexions, le broker principal continue à surveiller la connexion à Citrix Cloud. 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 d’enregistrement est déclenché. Le broker secondaire supprime les enregistrements de VDA restants de la panne précédente. 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ù 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 consigne les synchronisations et les pannes.

Aucun délai n’est imposé pour le fonctionnement en mode panne.

Vous pouvez également déclencher intentionnellement une panne. Voir Forcer une panne pour savoir quand cela peut être nécessaire et comment procéder.

Emplacements de ressources avec plusieurs Cloud Connector

Parmi ses différentes tâches, le service CSS fournit régulièrement au broker secondaire des informations sur tous les Cloud Connector dans l’emplacement de ressources. Ces informations permettent à chaque broker secondaire de connaître tous les brokers secondaires homologues qui s’exécutent sur d’autres Cloud Connector dans l’emplacement des ressources.

Les brokers secondaires communiquent entre eux sur un canal distinct. Ces brokers 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.

Important :

Les connecteurs d’un emplacement des ressources doivent être en mesure de 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 intermittents peuvent survenir lors d’un événement de cache d’hôte local.

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 s’enregistrent auprès du broker secondaire qui vient d’être sélectionné.

Durant une panne, si un Cloud Connector est redémarré :

  • Si ce Cloud Connector n’est pas le broker sélectionné, le redémarrage n’a aucun impact.
  • Si ce Cloud Connector est le broker sélectionné, un autre Cloud Connector est sélectionné, et par conséquent les VDA s’enregistrent. Une fois que le Cloud Connector redémarré est sous tension, il reprend automatiquement la négociation des connexions, et les VDA s’enregistrent à nouveau. Dans ce scénario, les performances peuvent être affectées lors des enregistrements.

Le journal d’événements contient des informations sur les sélections.

Fonctionnalités indisponibles durant une panne et autres différences

Aucun délai n’est imposé pour le fonctionnement en mode panne. Toutefois, si la défaillance est due à la perte de la connectivité à Citrix Cloud à partir de leur emplacement de ressources, Citrix recommande de restaurer la connectivité à partir de l’emplacement de ressources le plus rapidement possible.

Durant une panne :

  • Lors d’un événement de mise en cache de l’hôte local, Studio peut être temporairement inaccessible. Si Studio est accessible, les VDA situés dans des emplacements de ressources fonctionnant en mode HA s’affichent comme non enregistrés dans Studio. Ces VDA restent accessibles via le cache d’hôte local.

  • Vous avez un accès limité au SDK Remote PowerShell.

    • Vous devez d’abord :
      • Ajouter une clé de Registre EnableCssTestMode avec une valeur de 1 : New-ItemProperty -Path HKLM:\SOFTWARE\Citrix\DesktopServer\LHC -Name EnableCssTestMode -PropertyType DWORD -Value 1
      • Définissez l’authentification du SDK sur OnPrem de sorte que le proxy du SDK n’essaie pas de rediriger les appels de l’applet de commande : $XDSDKAuth="OnPrem"
      • Utiliser le port 89 : Get-BrokerMachine -AdminAddress localhost:89 | Select MachineName, ContollerDNSName, DesktopGroupName, RegistrationState
    • Après avoir exécuté ces commandes, vous pouvez accéder à :
      • Toutes les applets de commande Get-Broker*.
  • Les données de surveillance ne sont pas envoyées à Citrix Cloud pendant une panne. Par conséquent, les fonctions de surveillance n’affichent pas l’activité lors d’une défaillance.
  • 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 machine virtuelle 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.
  • Lors d’un événement de mise en cache de l’hôte local, chaque zone agit indépendamment. 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. Utilisez la fonctionnalité de vérification de l’intégrité avancée de StoreFront pour acheminer les requêtes de lancement vers la zone appropriée lors d’un événement LHC.
  • Si une panne de base de données de site se produit avant le début d’un redémarrage programmé pour les VDA d’un groupe de mise à disposition, les redémarrages commencent à la fin de la panne. Ce scénario peut donner des résultats inattendus. Pour plus d’informations, voir Redémarrages programmés retardés en raison d’une panne de la basede données.
  • La préférence de zone ne peut pas être configurée. Si elle est configurée, les préférences ne sont pas prises en compte pour le lancement de la session.
  • Lesrestrictions de balises dans lesquelles des balises sont utilisées pour désigner des emplacements de ressources ne sont pas prises en charge pour les lancements de session. Lorsque de telles restrictions de balises sont configurées et que l’option Contrôle avancé de l’état d’un magasin StoreFront est activée, le lancement des sessions peut échouer par intermittence.

Exigences de StoreFront

Si vous utilisez un déploiement StoreFront sur site, vous devez ajouter tous les Cloud Connector avec lesquels sont (ou peuvent être) enregistrés des VDA à StoreFront en tant que Delivery Controller. Un Cloud Connector qui n’est pas ajouté à StoreFront ne peut pas passer en mode panne, ce qui peut entraîner des échecs de lancement de l’utilisateur.

Disponibilité des ressources

Pour garantir la disponibilité des ressources (applications et bureaux) lors d’une panne, vous pouvez procéder de deux manières :

  • Publiez les ressources dans chaque emplacement de ressources de votre déploiement.
  • Si vous utilisez StoreFront 1912 CU4 ou version ultérieure, publiez les ressources sur au moins un emplacement de ressources et activez la vérification de l’état avancée sur tous les serveurs StoreFront. Pour les versions antérieures à StoreFront 2308, la vérification de l’état avancée est désactivée par défaut et doit être activée par un administrateur. Pour StoreFront version 2308 et versions ultérieures, cette fonctionnalité est activée par défaut. Pour plus d’informations et des instructions sur l’activation de la vérification de l’état avancée, consultez la section Vérification de l’état avancée.

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é du VDA pendant les événements 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 les rendre disponibles pour de nouvelles connexions pendant les événements LHC. Pour plus d’informations, consultez Activer l’utilisation de Studio et Activer l’utilisation 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 à des VDA de bureau à alimentation gérée dans des groupes de mise à disposition mis en pool n’affecte pas le fonctionnement de la propriété ShutdownDesktopsAfterUse configurée pendant les opérations normales. Lorsque l’accès à ces bureaux pendant un événement LHC est activé, les VDA ne redémarrent pas automatiquement une fois l’événement LHC terminé. 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’aide de Studio, vous pouvez rendre ces machines disponibles pour de nouvelles connexions pendant les événements LHC, selon le groupe 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 :

  1. Activez cette fonctionnalité au niveau du site en exécutant cette commande :

    Set-BrokerSite -ReuseMachinesWithoutShutdownInOutageAllowed $true

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

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

Vérifier que le cache d’hôte local fonctionne

Découvrez comment vérifier que le cache d’hôte local est correctement configuré.

Pour vérifier que le cache d’hôte local est configuré et fonctionne correctement :

  • Si vous utilisez StoreFront, vérifiez que le déploiement local de StoreFront pointe vers tous les Cloud Connector de cet emplacement de ressources.
  • 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 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 et HaDatabaseName_log.ldf sont créés.
  • Forcez une interruption sur tous les Cloud Connector dans l’emplacement de ressources. Après avoir vérifié que le cache d’hôte local fonctionne, n’oubliez pas de remettre tous les Cloud Connector en mode normal. Cela peut prendre environ 15 minutes.

Journaux d’événements

Les journaux d’événements consignent les synchronisations et les pannes. Dans les journaux de l’observateur d’événements, le mode panne est appelé mode HA.

Service de synchronisation de la configuration

Pendant une opération normale, les événements suivants peuvent se produire lorsque le CSS importe les données de configuration dans la base de données Cache hôte local à l’aide du broker Cache hôte local.

  • 503 : Citrix Config Sync Service 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. Il indique le début du processus de synchronisation.
  • 504 : Citrix Config Sync Service a importé une configuration mise à jour. L’importation de la configuration s’est terminée avec succès.
  • 505 : Échec d’une importation par Citrix Config Sync Service. L’importation de la configuration n’a pas réussi. Si une configuration précédente réussie est disponible, elle est utilisée en cas de panne. 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 à l’intermédiation de session pendant une panne. Dans ce cas, consultez la section Dépannage et contactez le support Citrix.
  • 507 : Citrix Config Sync Service a abandonné une importation car le système est en mode d’arrêt et le broker Cache d’hôte local est utilisé pour la négociation de connexions. Le service a reçu une nouvelle configuration, mais l’importation a été abandonnée en raison d’une panne. Il s’agit du comportement attendu.
  • 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.

Service de haute disponibilité

Ce service est également connu sous le nom de broker Cache d’hôte local.

  • 3502 : une panne s’est produite et le broker Cache d’hôte local effectue des opérations de broker.
  • 3503 : une panne a été résolue et le fonctionnement normal est rétabli.
  • 3504 : indique le broker Cache d’hôte local qui a été sélectionné, ainsi que les autres brokers Cache d’hôte local impliqués dans la sélection.
  • 3507 : fournit une mise à jour de l’état du cache d’hôte local toutes les 2 minutes, ce qui indique que le mode de cache d’hôte local est actif sur le broker sélectionné. Contient un résumé de la panne, notamment sa durée, l’enregistrement du VDA et les informations de session.
  • 3508 : annonce que le cache d’hôte local n’est plus actif sur le broker sélectionné et que les opérations normales ont été rétablies. Contient un résumé de la panne, notamment sa durée, le nombre de machines enregistrées lors de l’événement de cache d’hôte local et le nombre de lancements réussis lors de l’événement.
  • 3509 : indique que le cache d’hôte local est actif sur le ou les brokers non sélectionnés. Indique la durée de l’interruption toutes les 2 minutes, ainsi que le broker sélectionné.
  • 3510 : Annonce que le cache d’hôte local n’est plus actif sur le ou les brokers non sélectionnés. Contient la durée de la panne et indique le broker sélectionné.

Remote Broker Provider

Ce service fait office de proxy entre Citrix Cloud, vos VDA et vos machines Cloud Connector.

  • 3001 : vérifie si les machines Cloud Connector doivent passer en mode haute disponibilité. Cet événement se produit après un seul échec de machine Cloud Connector à la vérification de l’intégrité. Si une machine Cloud Connector échoue à la prochaine vérification de l’intégrité au bout de 60 secondes, elle passe en mode haute disponibilité.
  • 3002 : indique que la machine Cloud Connector ne peut pas passer en mode haute disponibilité. La raison pour laquelle le passage en mode haute disponibilité échoue est fournie dans les informations sur l’événement.

  • 3003 : indique que la machine Cloud Connector passe par différents états du mode haute disponibilité. Ce diagramme décrit les états d’entrée et de sortie du mode haute disponibilité. L’événement fournit les informations suivantes :

    • L’état à partir duquel la machine Cloud Connector est en cours de transition.
    • L’état vers lequel la machine Cloud Connector est en cours de transition.
    • La durée de l’état précédent.

Remarque :

Des événements 3001 peuvent se produire fréquemment sur vos machines Cloud Connector. Ces événements peuvent être dus à des interruptions du réseau et ne constituent pas une source de préoccupation.

Forcer une interruption

Vous pouvez souhaiter délibérément forcer une interruption.

  • 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 (et les fréquentes rafales 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.

Bien qu’un Cloud Connector puisse être mis à jour pendant une interruption forcée, des problèmes imprévus peuvent survenir. Nous vous recommandons de définir un calendrier pour les mises à jour de Cloud Connector afin d’éviter les intervalles de mode d’interruption forcée.

Pour forcer une interruption, modifiez le registre de chaque serveur Cloud Connector. Dans HKLM\Software\Citrix\DesktopServer\LHC, créez et définissez OutageModeForced comme REG_DWORD sur 1. Ce réglage demande au broker Cache d’hôte local d’entrer en mode d’interruption, quel que soit l’état de la connexion à Citrix Cloud. Si vous définissez la valeur sur 0, le broker Cache d’hôte local sort du mode d’interruption.

Pour vérifier les événements, surveillez le fichier journal Current_HighAvailabilityService dans C:\ProgramData\Citrix\workspaceCloud\Logs\Plugins\HighAvailabilityService.

Dépannage

Plusieurs outils de dépannage sont disponibles lorsque l’importation d’une synchronisation dans la base de données Cache d’hôte local é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, peuvent identifier le problème.

Rapport : en cas d’échec d’une importation de synchronisation, 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

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 :

cd C:\Program Files\Citrix\Broker\Service\ControlScripts Import-Module .\HighAvailabilityServiceControl.psm1

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 service ConfigSync 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 LHC soit actif, cette applet de commande doit être exécutée sur tous les Cloud Connector de l’emplacement des ressources.
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 était exécutée. Disable-LhcForcedOutageMode doit être exécuté sur tous les Cloud Connector de l’emplacement des ressources.
Set-LhcConfigSyncIntervalOverride Permet de définir l’intervalle auquel Citrix Config Synchronizer Service (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 -Seconds 1200
Clear-LhcConfigSyncIntervalOverride Permet de définir l’intervalle auquel Citrix Config Synchronizer Service (CSS) vérifie les modifications de configuration sur le site Citrix DaaS, à 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* du Cloud Connector sur lequel elles étaient exécutées
Disable-LhcHighAvailabilitySDK Désactive l’accès aux commandes Broker PowerShell dans le Cloud Connector sur lequel elles étaient 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 du Cloud Connector sélectionné contient 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
Cache d’hôte local
September 27, 2024
Contributeur: 
C
September 27, 2024
Contributeur: 
C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.