Dimensionnement et mise à l’échelle du cache hôte local

Vue d’ensemble

Cet article fournit des recommandations de taille et d’échelle pour les déploiements de Citrix Virtual Apps and Desktops à l’aide du cache d’hôte local (LHC). Pour des recommandations de taille et d’échelle pour Citrix DaaS, consultez la section Considérations relatives à la taille et à l’échelle pour les

Le LHC assure une haute disponibilité en permettant la poursuite du courtage des connexions en cas de panne. Les utilisateurs du LHC doivent respecter les considérations de conception suivantes :

  • En cas de panne, un seul broker par zone gère les inscriptions au Virtual Delivery Agent (VDA) et les sessions de brokering.
  • Un processus électoral, qui détermine quel broker est actif, ne prend pas en compte les ressources du broker.
  • Si un seul broker d’une zone ne peut pas gérer toutes les ouvertures de session pendant le fonctionnement normal, il ne fonctionnera pas correctement en mode panne.
  • Aucune gestion de site n’est disponible en cas de panne.
  • Un SQL Server à haute disponibilité reste la conception recommandée.
  • Pour les scénarios de connectivité intermittente de base de données, il est toujours préférable d’isoler SQL Server et de laisser le site en mode panne jusqu’à ce que tous les problèmes sous-jacents soient résolus.
  • Il existe une limite de 10 000 VDA par zone.
  • Les postes de travail groupés ne sont pas pris en charge en mode panne, dans la configuration par défaut.

Architecture

Le LHC utilise une base de données SQL Server locale qui est plus efficace que la location de connexions en termes d’utilisation de l’espace disque, mais nécessite beaucoup plus de processeur et de mémoire. Le LHC comporte des phases de synchronisation au cours desquelles les informations de la base de données principale du site sont synchronisées avec les brokers (contrôleurs). Le LHC utilise une base de données SQL qui nécessite toujours des IOPS, et présente l’avantage d’optimiser ces écritures par SQL.

Le LHC emploie un broker unique qui est choisi pour négocier toutes les connexions et gérer les enregistrements de VDA. Tous les VDA du site se réenregistrent auprès de ce broker unique, qui connaît alors une demande de ressources plus élevée (par rapport à un site multi-brokers en fonctionnement normal), en particulier sur les sites comptant un grand nombre de VDA.

Le LHC utilise Microsoft LocalDB, qui apparaît dans le Gestionnaire des tâches sous le nom de processus sqlserver.exe. Il a été configuré pour utiliser jusqu’à 1 Go de mémoire pour la mise en cache du pool de tampons de base de données. Cependant, le processus va au-delà de cela, car le moteur SQL a besoin de mémoire pour lui-même et pour d’autres caches plus petits. En général, plus la panne est longue et plus les ressources sont accessibles en mode panne, plus l’utilisation de la mémoire LocalDB augmente. Toutefois, lorsque la connectivité à la base de données du site est rétablie, sqlserver.exe conserve cette mémoire et ne la renvoie pas immédiatement au pool principal.

Effet des sockets et des cœurs de processeur pendant le mode de panne

Le LHC utilise une version d’exécution de SQL Server appelée LocalDB, qui dispose d’une licence spécifique qui le limite à quatre cœurs ou à un seul socket, selon le moins élevé des deux. Cela peut avoir un effet significatif sur les performances lorsque la machine physique ou virtuelle a été configurée avec plusieurs sockets avec un seul ou deux cœurs. Une machine broker avec quatre sockets et un cœur par socket limitera LocalDB à n’utiliser qu’un seul cœur, alors que la même machine virtuelle configurée comme une machine à 1 socket et 4 cœurs signifie que LocalDB peut accéder aux quatre cœurs (tout en les partageant avec d’autres processus). En mode panne, LocalDB exécute le même broker et le même code SQL qu’en fonctionnement normal. La plupart des requêtes SQL peuvent être gourmandes en CPU et avoir un impact direct sur les performances du courtage en mode panne. Pour plus de détails, voir Considérations relatives à la taille et à l’échelle des connecteurs cloud et également Limites de capacité de calcul par édition de SQL Server.

Les autres facteurs incluent la configuration du site elle-même, tels que les suivants :

  • Le nombre de demandes publiées
  • Le nombre d’utilisateurs faisant l’objet d’un courtage
  • La fréquence à laquelle les utilisateurs tentent de lancer des sessions
  • Performances Active Directory

À mesure que l’utilisation totale du processeur du broker approche 100 %, le temps de réponse du broker augmente, le traitement des connexions prend plus de temps et certaines tentatives de connexion peuvent échouer.

Sites avec plusieurs brokers

En mode panne de site, seul un broker traite les demandes d’enregistrement et d’ouverture de session. Dans un site multi-brokers, un processus électoral a lieu pour désigner le broker qui sera actif pendant la panne. Toutefois, ce processus électoral ne tient pas compte des ressources matérielles dont disposent les brokers. Cela signifie que sur un site où les brokers disposent de différentes quantités de ressources, le broker sélectionné ne sera pas nécessairement le plus puissant en termes de CPU ou de RAM, ce qui peut potentiellement entraîner de mauvaises performances en mode panne. Il est important que chaque broker réponde aux exigences supplémentaires du LHC, au cas où il serait élu.

synchronisation avec la base de données du site

Le service CitrixConfigSync gère l’importation de données de la base de données du site dans une copie locale sur les brokers. Il surveille la base de données du site pour détecter les modifications apportées à la configuration du site et déclenche une nouvelle importation lorsque des modifications se produisent. Une copie de la base de données locale actuelle est effectuée avant le début de l’importation. Plus le nombre de ressources (telles que les VDA) d’un site est élevé, plus l’importation est longue, mais elle peut prendre moins de 10 minutes pour un site contenant 10 000 VDA.

Emplacement de la base

La base de données locale est stockée dans :

C:\Windows\ServiceProfiles\NetworkService\HaDatabaseName.mdf

Pour garantir la fiabilité, le service CitrixConfigSync effectue une sauvegarde de l’importation de base de données synchronisée précédemment réussie, avant de démarrer une nouvelle synchronisation de base de données de site. Si, pour une raison quelconque, la synchronisation ne se termine pas correctement, la sauvegarde est utilisée jusqu’à ce qu’une synchronisation réussie soit terminée. Vous ne devez pas copier la base de données manuellement.

Spécifications techniques du cache d’hôte local

Architecture Spec
Disk Space Cela dépend de la configuration du site. Pour 1 000 hôtes RDS et 9 500 VDI avec 65 000 utilisateurs, 75 Mo sont utilisés.
RAM 3 Go, ~1 Go pour SQL Server, 2 Go pour High Availability Service et CitrixConfigSync Service.
Configuration du délai de synchronisation 10 000 VDA : environ 7 minutes
Temps d’activation en cas de panne Cela dépend du nombre de VDA et de la dernière synchronisation d’enregistrement avec le broker. Un seul broker est disponible pour l’enregistrement des VDA en mode panne. Par conséquent, pour un grand nombre de VDA, l’enregistrement de tous les VDA peut prendre plusieurs minutes.
Il est temps de rétablir les opérations normales Comme indiqué précédemment, les VDA doivent se désinscrire auprès du broker secondaire et se réenregistrer auprès du broker principal.
Nombre de VDA pris en charge 10,000. Un site peut en contenir plus, mais le temps nécessaire à la synchronisation de la base de données du site augmente avec le nombre de VDA. Les performances d’un seul broker avec de nombreux VDA peuvent empêcher le courtage de certaines connexions pendant la panne.
Gestion du site en cas de panne Non

Activation ou désactivation du cache d’hôte local

Le LHC peut être activé ou désactivé selon les besoins.

Set-BrokerSite —LocalHostCacheEnabled $True $False

Limitations

Les postes de travail doivent avoir été attribués avant de pouvoir être utilisés en mode panne. Les ordinateurs de bureau non assignés ne seront pas disponibles pour le courtage. Cela peut entraîner l’indisponibilité des postes de travail et le signalement « en mode maintenance » si une panne survient avant que toutes les attributions n’aient été synchronisées, alors qu’un poste de travail a effectivement été attribué à un utilisateur.

Les postes de travail groupés ne sont pas pris en charge en mode panne dans la configuration par défaut. Il existe une solution de contournement, mais elle a des implications potentielles sur la sécurité et les performances. Si vous configurez un groupe de mise à disposition contenant des bureaux groupés pour qu’il ne redémarre pas à la fermeture de session, tous les bureaux groupés sous tension de ce groupe sont disponibles en mode panne. Toutefois, une fois qu’un utilisateur se déconnecte, le bureau ne sera pas dans un état propre car il n’est pas redémarré. Cela peut poser un problème de sécurité quel que soit le scénario. Si le prochain utilisateur de ce poste de travail est un administrateur local de ce poste de travail, les données d’un utilisateur précédent peuvent être accessibles. Et bien que ce risque soit moins préoccupant pour les utilisateurs standard (non administrateurs), n’oubliez pas que les applications peuvent ne pas se comporter correctement et entraîner des problèmes de performances au fil du temps. Important :les administrateurs doivent examiner attentivement les implications potentielles de l’utilisation de cette solution de contournement pour l’utilisation de postes de travail groupés non redémarrés en mode panne.

Lors d’une panne, aucune modification du site ne peut être apportée. La base de données est en fait un instantané de la base de données du site principal et elle est supprimée chaque fois qu’une nouvelle synchronisation se produit.

Taille de la base

Pour la configuration de 10 000 VDI (c’est-à-dire 10 000 postes de travail VDI à session unique), la base de données LocalDB était d’environ 75 Mo. Pour la configuration de 100 000 RDS (c’est-à-dire 100 000 utilisateurs), la base de données LocalDB variait entre 100 et 300 Mo, en fonction du nombre d’applications et de connexions. Comme une copie de la base de données est prise avant le début d’une nouvelle importation, allouez 1 Go d’espace à LocalDB.

Considérations relatives au dimensionnement

Bien que 10 000 VDA soient le maximum par zone, étant donné que les sessions contribuent à la charge du broker sélectionné lors d’une panne, Citrix vous recommande de prendre également en compte les sessions de pointe par zone. La densité de session entre en jeu lors de l’utilisation de VDA multisessions, car plusieurs sessions peuvent être initiées sur un seul VDA.

En cas de panne, le pic recommandé est de 25 000 utilisateurs par zone, ce qui peut atteindre 1 à 2 000 lancements de ressources par minute s’il est correctement dimensionné.

Les lancements d’applications sont traités comme les lancements de bureau. Les mêmes recommandations s’appliquent dans les deux cas. Citrix vous recommande toutefois de prendre également en compte le taux de lancement. Un seul utilisateur peut lancer plusieurs applications, ce qui augmente la charge exercée par utilisateur sur le broker en cas de panne.

Lorsque vous calculez la capacité des applications, tenez compte du nombre moyen d’applications lancées par utilisateur et maintenez ce chiffre dans les limites de la même recommandation de 25 000 par zone.

Résumé

Lors d’une panne de base de données du site, le LHC prend en charge un large éventail de ressources et de conditions, mais nécessite une planification et une prise en compte du processeur et de la mémoire lors de son fonctionnement

Dans plusieurs sites de broker, n’importe quel broker peut être choisi comme broker de panne, et donc tous doivent disposer de ressources suffisantes pour faire face en mode panne. Aucune évaluation des ressources des brokers n’est effectuée. Ainsi, sur un site où les brokers disposent de ressources variables, il est possible que le broker le moins puissant soit élu lors d’une panne.

La disposition des noyaux et des douilles doit être considérée dans le cadre de la conception des brokers.

Le nombre d’applications et de postes de travail publiés a un effet sur les temps de réponse à l’ouverture de session et sur le débit d’ouverture de session maximal.

Les brokers dont les ressources CPU sont insuffisantes peuvent rencontrer des échecs de lancement.

Citrix vous recommande de définir vos exclusions antivirus. Pour plus d’informations, consultez le document technique : Meilleures pratiques en matière de sécurité des terminaux, d’antivirus et d’antimalware.

Deux cœurs supplémentaires et 2 Go de mémoire vive constituent un bon point de départ pour tester les performances en mode panne du LHC.

1 Go d’espace disque est suffisant pour la base de données LocalDB.

Un broker surchargé entraîne l’échec des connexions.

Dimensionnement et mise à l’échelle du cache hôte local