Présentation technique : cache d’hôte local/mode haute disponibilité pour Citrix Virtual Apps and Desktops Service

Vue d’ensemble

Le cache d’hôte local (LHC), dans le contexte du service Citrix Virtual Apps and Desktops (CVAD), peut être considéré comme une police d’assurance. Cette police d’assurance entre en jeu lorsque, pour une raison quelconque (pannes, problèmes de connexion, coupures d’Internet, etc.), les Citrix Cloud Connector ne sont pas en mesure de communiquer avec le service de courtage Citrix (faisant partie du service CVAD et désormais appelé broker en cloud). Une rupture de communication entre un emplacement de ressource et le broker cloud peut avoir un impact sur l’utilisateur final. Le cache d’hôte local est conçu pour atténuer cet impact sur l’utilisateur final.

Le cache d’hôte local est une combinaison de plusieurs services et composants qui se réunissent pour prendre en charge les responsabilités de courtage jusqu’à ce que la connexion au broker cloud puisse être rétablie.

Figure 1 : Représentation conceptuelle du service CVAD présentant les composantes pertinentes pour le mode HA

Composants Cloud Connector

Il existe plusieurs composants dans Citrix Cloud Connector qui sont requis pour les opérations de cache d’hôte local.

• Servicede synchronisation de configuration : le service CSS (Configuration Synchronizer Service) vérifie périodiquement avec le cloud Broker (toutes les 60 secondes) pour voir si des modifications de configuration ont été apportées. Les modifications peuvent être initiées par l’administrateur (par exemple, la modification d’une propriété de groupe de mise à disposition) ou des actions système (telles que des affectations de machines). Lorsque des modifications sont détectées, CSS synchronise les modifications du broker de cloud vers les machines connecteurs.
• LocalDB : Le CSS importe les données de configuration dans une base de données Microsoft SQL Server Express LocalDB. Une nouvelle instance de la base de données est créée pour chaque opération de synchronisation. Une fois la synchronisation terminée, la dernière instance DB remplace l’instance DB précédente.
• Service de haute disponibilité  : Le service High Availability (HA Service) est un service Broker spécialisé qui fournit la fonctionnalité de courtage d’exécution pendant une panne. Le service AP est également appelé broker secondaire.
• Fournisseur de courtage à distance : Remote Broker Provider remplit plusieurs fonctions importantes :
  • Il agit comme un proxy relais de communication entre Citrix Virtual Delivery Agent (VDA) et Cloud Broker
  • Il agit comme un proxy relais de communication entre un StoreFront local ou un ADC local et les différents services Citrix Cloud
  • Il détermine quand basculer un emplacement de ressource entre le mode HA et le fonctionnement normal

Figure 2 : composants et services du connecteur qui jouent un rôle avec le mode HA

Le dimensionnement approprié des machines de connecteur de cloud est une étape importante pour s’assurer que les ressources appropriées sont disponibles pour les services en mode Haute disponibilité. Consultez l’article Considérations sur l’échelle et la taille pour en savoir plus.

Mode haute disponibilité

Citrix Cloud Connector est capable d’entrer ou de quitter le mode HA automatiquement sans intervention de l’administrateur. Le mode HA peut être déclenché par l’un des éléments suivants :

• Échec des énumérations StoreFront ou des demandes de lancement
• Défaut de relais des communications entre le VDA et le broker en cloud
• Défaut de présenter des demandes d’Secure Ticket Authority (STA) au service CVAD au nom d’un ADC local lors d’un lancement

En mode HA, le service HA prend en charge plusieurs fonctions de courtage importantes, il énumère les ressources, lance des sessions de courtage et accepte les enregistrements VDA. De plus, le service AP agit en tant que fournisseur d’AST. Dans un emplacement de ressources doté de plusieurs Cloud Connector, les services HA communiquent entre eux dans le cadre d’un processus d’élection. Ce processus d’élection détermine quelle instance du service HA prend le relais si le mode HA est déclenché.

Figure 3 : Emplacement des ressources fonctionnant en mode HA

Entrée/sortie du mode haute disponibilité

La décision de passer au mode HA dépend de l’énumération et du trafic de lancement circulant à travers une instance Cloud Connector donnée. Seule la machine connecteur configurée en tant que Delivery Controller dans StoreFront prendra en charge la détection et la transition en mode HA. Cette optimisation est nécessaire pour éviter les enregistrements VDA inutiles.

Il existe plusieurs états pendant tout le cycle d’entrée et de sortie du mode HA. Pendant l’état Travailler normalement, tous les composants sont sains et toutes les transactions de courtage sont gérées par le broker en cloud. Le CSS réplique activement les configurations du cloud Broker vers les machines connecteurs.

Dans le cas où certains composants ne parviennent pas à présenter un rapport sain, le connecteur passe à l’état HA en attente. Dans cet état, une vérification complète de l’état de santé est lancée afin de déterminer la marche à suivre. Les connecteurs interagissent avec d’autres connecteurs dans l’emplacement des ressources pour déterminer leur état d’intégrité. La décision de passer de la HA en attente à la HA initiale est basée sur l’état de santé de tous les connecteurs dans un emplacement de ressource donné. Si les vérifications d’intégrité réussissent, les connecteurs reprennent l’état Working Normalement. Sinon, si les vérifications d’intégrité continuent d’échouer, les connecteurs passent à l’état HA initial.

Figure 4 : États du connecteur pour le mode HA entrée/existant

Pendant l’état HA initial, le service High Availability sur le connecteur prend en charge les responsabilités de courtage. Tous les VDA de l’emplacement de ressources actuel qui ont été enregistrés auprès du broker cloud s’inscriront auprès du service HA/broker secondaire sur le connecteur. À la fin de l’AP initiale, des vérifications de l’état sont lancées. Si toutes les vérifications de l’état réussissent, l’état passe à Récupération en attente, sinon l’état passe à la haute disponibilité étendue.

Les vérifications d’intégrité se poursuivent pendant la période HA étendue et lorsque toutes les vérifications d’intégrité réussissent, l’état passe à la récupération en attente. Il n’y a pas de durée maximale pour qu’un connecteur reste dans l’état HA étendu.

En attente de récupération sert de période d’attente, où tous les composants sont sains, avant de remettre le courtage au broker en cloud. Si l’un des contrôles d’intégrité échoue pendant la récupération en attente, l’état revient à Extended HA. Si toutes les vérifications d’intégrité réussissent pendant l’intégralité de la période de récupération en attente, l’état passe à Travailler normalement. Avec cette transition, le mode HA est sorti, et tous les VDA de l’emplacement de ressource qui ont été enregistrés auprès du Broker secondaire se réinscrivent désormais auprès du broker cloud.

Instance de service CVAD avec plusieurs emplacements de ressources

Le broker cloud est conçu pour avoir une vue de l’ensemble du déploiement, sur plusieurs sites de ressources. Toutefois, en mode HA, chaque emplacement de ressource devient son propre conteneur indépendant, et le broker secondaire élu dans chaque emplacement de ressource gère les transactions de courtage uniquement pour les VDA dans cet emplacement de ressource. Cette conception est une raison essentielle pour s’assurer que StoreFront est configuré pour inclure tous les Cloud Connector de tous les emplacements de ressources contenant des charges de travail VDA. StoreFront peut ensuite distribuer des demandes de lancement et équilibrer efficacement la charge des utilisateurs sur plusieurs emplacements de ressources.

Enregistrements VDA

Lorsque la panne commence, le broker secondaire sélectionné (lisez la section sur les connecteurs multiples dans un emplacement de ressources pour en savoir plus sur le processus d’élection) ne dispose pas de données d’enregistrement de VDA actuelles, mais lorsqu’un VDA communique avec lui, un processus d’enregistrement est déclenché. Au cours de ce processus, le broker secondaire élu obtient également des informations de session en cours pour ce VDA. Le VDA communique avec le broker au moins toutes les 5 minutes. Selon le moment où le dernier battement de cœur a été terminé, un VDA peut prendre jusqu’à 5 minutes pour réaliser le changement du broker cloud au broker secondaire élu et déclencher l’inscription auprès du broker secondaire élu.

Pendant que le broker secondaire sélectionné gère les connexions, le fournisseur de courtage distant surveille la connexion à Citrix Cloud. Lorsque la connexion est restaurée, le fournisseur de courtage distant demande au broker secondaire élu de cesser d’écouter les informations de connexion et reprend la transmission des opérations de courtage au broker en cloud. La prochaine fois qu’un VDA communique avec le fournisseur de broker distant, un autre processus d’enregistrement est déclenché. Le broker secondaire élu supprime tous les enregistrements 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.

Plusieurs connecteurs dans un emplacement de ressource

Citrix recommande un minimum de 2 connecteurs dans chaque emplacement de ressource/zone. Dans chaque zone, un processus électoral est constamment en cours pour s’assurer que les services HA savent quelle machine de connecteur assumerait les responsabilités de courtage en cas d’interruption. Cette option se produit toujours, à la fois pendant les opérations normales et en mode HA.

Le CSS fournit régulièrement au broker secondaire des informations sur tous les Cloud Connector dans l’emplacement des ressources. Ayant ces informations, chaque connecteur connaît tous les connecteurs homologues exécutés dans l’emplacement de ressource. Les brokers secondaires communiquent entre eux sur un canal distinct. Ces services utilisent une liste alphabétique des noms de domaine complet des machines sur lesquelles ils exécutent pour déterminer le broker secondaire élu dans la zone en cas de panne. En mode HA, le broker secondaire élu prend en charge les responsabilités de courtage tandis que les autres brokers secondaires de la zone rejettent activement les demandes d’enregistrement de connexion entrante et de VDA.

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é. En mode HA, si un connecteur est redémarré :

• Si ce connecteur n’est pas le broker secondaire élu, le redémarrage n’a aucun impact.
• Si ce connecteur est le broker secondaire élu, un Cloud Connector différent est sélectionné, ce qui entraîne l’enregistrement des VDA auprès du nouveau broker secondaire élu. 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. Pour plus d’informations sur les événements associés, consultez l’article sur les journaux d’événements de la documentation produit.

Cache hôte local avec plusieurs emplacements de ressources

Équilibrage de charge entre les connecteurs dans un emplacement de ressources

StoreFront local envoie un message de pulsation à tous les Cloud Connector configurés dans son magasin toutes les 60 secondes par défaut. Seuls les Cloud Connector sains (qui répondent avec succès au rythme cardiaque) sont pris en compte pour l’énumération des applications d’équilibrage de charge et les demandes de lancement. La même demande de pulsation au Cloud Connector active également le connecteur pour participer à l’algorithme de mode HA décrit dans les sections précédentes. Pour garantir que tous les emplacements de ressources sont activés en mode HA, il est essentiel de s’assurer que StoreFront local a tous les Cloud Connector identifiés comme Delivery Controller dans la configuration StoreFront. L’absence de configurations StoreFront appropriées peut entraîner une perte de capacité lorsque le site passe en mode HA.

Figure 5 : Déploiement avec plusieurs emplacements de ressources où une seule RL n’est pas prête à la haute disponibilité en raison de configurations manquantes

Mode HA pour les emplacements de ressources publiant les mêmes applications/postes de travail

L’un des modèles de déploiement de service CVAD inclut plusieurs emplacements de ressources, tous publiant des applications et des postes de travail identiques sur les emplacements de ressources. Par exemple, un déploiement contenant des applications provenant d’une seule image multi-session ou de postes de travail VDI groupés peut être déployé uniformément sur tous les emplacements de ressources.

Lorsqu’un tel déploiement fonctionne en mode HA, les utilisateurs peuvent être dirigés vers l’un des VDA dans les différents emplacements de ressources configurés. Dans ce scénario, la charge StoreFront répartit les demandes vers tous les Cloud Connector configurés sur différents emplacements de ressources.

Mode HA pour les emplacements de ressources publiant différentes applications/postes de travail

Un déploiement de service CVAD peut également avoir certaines applications disponibles uniquement dans un sous-ensemble spécifique d’emplacements de ressources. Par exemple, un bureau d’exploitation japonais peut être disponible uniquement sur les VDA s’exécutant au Japon. Un autre exemple concerne les postes de travail statiques/affectés qui sont spécifiques à l’utilisateur et liés à un emplacement de ressource spécifique après l’affectation.

Lorsqu’un tel déploiement fonctionne en mode HA, les demandes de lancement d’application ou de bureau doivent être acheminées vers le Cloud Connector approprié dans les emplacements de ressources spécifiques où résident les applications et les bureaux, car le courtage inter-zones n’est pas disponible en mode HA. La fonctionnalité AdvancedHealthCheck proposée par StoreFront 1912 LTSR Cumulative Update 1 ou ultérieure permet des déploiements tels que décrits dans le paragraphe suivant.

StoreFront énumère les applications et les postes de travail de Cloud Connector dans n’importe quelle région. Les informations d’énumération contiennent désormais un mappage entre la ressource (une application ou un bureau) et les emplacements de ressources où réside l’application/bureau. Ce mappage est utilisé pour diriger les demandes de lancement de l’utilisateur vers des emplacements de ressources spécifiques. Passez en revue les étapes de configuration répertoriées dans la documentation du produit pour permettre à StoreFront d’utiliser cette fonctionnalité.

Architectures impliquant Citrix ADC

Surveillance

L’appliance Citrix ADC fournit un moniteur intégré, le moniteur CITRIX-XD-DDC, qui surveille les serveurs Citrix Virtual Apps and Desktops Delivery Controller. Dans le contexte du Citrix Virtual Apps and Desktops Service, les Cloud Connector sont équivalents aux serveurs Delivery Controller. Le moniteur envoie une sonde aux serveurs contrôleur/connecteurs configurés sous la forme d’un message XML. Si le serveur répond à la sonde avec l’identité de la batterie de serveurs, la sonde est considérée comme ayant réussi et l’état du serveur est marqué comme UP. Si la réponse n’a pas de code de succès ou si l’identité de la batterie de serveurs n’est pas présente dans la réponse, la sonde est considérée comme une défaillance et l’état du serveur est marqué comme DOWN.

Plus d’informations sur le moniteur CITRIX-XD-DDC sont disponibles dans la documentation Citrix ADC.

Citrix ADC pour les emplacements de ressources publiant différentes applications/postes de travail

Pour les architectures impliquant Citrix ADC avec des emplacements de ressources publiant différentes applications et postes de travail, les configurations suivantes doivent être effectuées.

• Regroupez les Cloud Connector dans chaque emplacement de ressource en un VIP unique dans l’équilibreur de charge ADC.
• Activez la fonction AdvancedHealthCheck de StoreFront comme décrit ici.
• Mapper chaque zone ou emplacement de ressource à une adresse IP virtuelle ADC (VIP)
• Ajoutez tous les VIP ADC en tant que Delivery Controller à StoreFront.
• Configurez l’équilibreur de charge ADC pour surveiller les Cloud Connector dans chaque emplacement de ressource via le moniteur CITRIX-XD-DDC.

Figure 6 : Déploiement avec plusieurs emplacements de ressources et Citrix ADC

Considérations relatives à la charge de travail VDA Pool Desktop

Lorsqu’un utilisateur se déconnecte un VDA de bureau groupé, l’image du VDA est réinitialisée pour supprimer toutes les données spécifiques à l’utilisateur sur le VDA. Lorsqu’un site s’exécute en mode HA, l’opération de réinitialisation n’est pas disponible. Par conséquent, lorsqu’un utilisateur se déconnecte d’un VDA de bureau groupé, la machine est placée en mode maintenance. Cette réinitialisation empêche la mise à disposition d’une image entachée pour un autre utilisateur.

Selon les besoins de sécurité d’une implémentation, ce comportement peut être modifié en appliquant une mise à jour à l’échelle du site et par groupe de distribution. Vous trouverez plus d’informations sur la façon de remplacer le comportement par défaut dans la documentation du produit.

Pour les charges de travail VDA de bureau groupées exécutées sur VMware vSphere et Citrix Hypervisor, une nouvelle fonctionnalité qui introduit la prise en charge des opérations d’alimentation en mode HA est disponible en prévisualisation anticipée. Cette fonctionnalité ajoute la possibilité de réinitialiser les images même lorsqu’un site fonctionne en mode HA. Pour en savoir plus sur la version préliminaire, cliquez ici.

Test du cache hôte local

Local Host Cache est conçu pour fonctionner sans aucune intervention de l’utilisateur - - il est entièrement autonome. Vous pouvez cependant vérifier que tous les Cloud Connector sont correctement synchronisés et prêts à être pris en charge. Les étapes suivantes sont recommandées :

• Comme décrit dans les sections précédentes, chaque connecteur effectue la synchronisation de la configuration du site indépendamment. Les résultats de la synchronisation sont disponibles dans l’Observateur d’événements. Reportez-vous à la section Journaux d’événements de la documentation produit pour plus de détails sur les événements.
• Une panne peut être simulée pour tester la solution Local Host Cache dans un environnement. Des conseils sur la façon de forcer une panne sont disponibles dans la documentation du produit. Lorsque vous forcez une panne, prenez soin de régler tous les connecteurs d’un emplacement de ressource sur le mode de panne forcée.