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

REMARQUE :

Cet article fournit des recommandations de taille et d’échelle pour les déploiements XenApp et XenDesktop à 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 :

• Lors d’une panne, un seul courtier par zone gère les inscriptions et les sessions des courtiers en Virtual Delivery Agent (VDA).
• Un processus d’élection, qui permet de décider quel courtier sera actif, ne tient pas compte des ressources du courtier.
• 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 courtiers (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 courtier unique qui est choisi pour négocier toutes les connexions et gérer les enregistrements de VDA. Tous les VDA du site seront réenregistrés auprès de ce courtier unique, qui sera alors confronté à une demande de ressources plus élevée (par rapport à un site multi-courtiers en fonctionnement normal), en particulier sur les sites contenant 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 se développer au-delà de cela, car le moteur SQL a besoin de mémoire pour lui-même et d’autres caches plus petits. En général, plus la panne est longue et plus le nombre de ressources accessibles en mode panne est important, plus l’utilisation de la mémoire LocalDB augmentera. Toutefois, lorsque la connectivité de 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écutera le même broker et le même code SQL que pendant le 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 courtage augmentera, les ouvertures de session prendront plus de temps à traiter et certaines tentatives d’ouverture de session 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 dans un site où les brokers ont des quantités différentes de ressources, le broker élu ne sera pas nécessairement le plus puissant en termes de CPU ou de RAM, ce qui pourrait potentiellement conduire à de mauvaises performances en mode panne. Il est important que chaque courtier 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) sur un site est important, plus l’importation prendra de temps, mais elle devrait durer moins de dix 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

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

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

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 postes de travail regroupés sous tension de ce groupe seront 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é dans n’importe quel 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), gardez à l’esprit que les applications peuvent se comporter de manière incorrecte 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 bureaux groupés non redémarrés en mode panne.

Lors d’une panne, aucune modification ne peut être apportée au site ; la base de données est en fait un instantané de la base de données principale du site et 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 soit le maximum par zone, étant donné que les sessions contribuent à la charge du broker sélectionné en cas de 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.

Lors d’une panne, le pic recommandé est de 25 000 utilisateurs par zone, ce qui peut atteindre 1 à 2 000 lancements de ressources par minute si la taille est appropriée.

Les lancements d’applications sont traités comme les lancements de bureau. Les mêmes recommandations s’appliquent aux deux ; toutefois, Citrix vous recommande de prendre également en compte la fréquence de lancement. Un seul utilisateur peut lancer plusieurs applications, augmentant ainsi la charge exercée par utilisateur sur le courtier 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 courtiers n’est effectuée. Ainsi, sur un site où les courtiers disposent de ressources variables, il est possible que le courtier 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 aura une incidence sur les temps de réponse et le débit maximal d’ouverture de session.

Les courtiers 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 RAM constituent un bon point de départ pour tester les performances en mode panne du LHC.

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

Un broker surchargé entraînera des connexions échouées.