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

REMARQUE :

Cet article fournit des recommandations de dimensionnement et de mise à l’échelle pour les déploiements XenApp et XenDesktop utilisant le cache d’hôte local (LHC). Pour les recommandations de dimensionnement et de mise à l’échelle pour Citrix DaaS, consultez Considérations relatives au dimensionnement et à la mise à l’échelle des Cloud Connectors.

Le LHC offre une haute disponibilité en permettant la poursuite du courtage de connexion pendant une panne. Les utilisateurs du LHC doivent prendre en compte les considérations de conception suivantes :

• Pendant une panne, un seul broker par zone gérera les enregistrements d’agents de livraison virtuels (VDA) et les sessions de broker.
• Un processus d’élection, qui décide quel broker sera actif, ne prend pas en compte les ressources du broker.
• Si un seul broker dans une zone ne peut pas gérer toutes les ouvertures de session en fonctionnement normal, il ne fonctionnera pas correctement en mode panne.
• Aucune gestion de site n’est disponible pendant une panne.
• Un SQL Server hautement disponible reste la conception recommandée.
• Pour les scénarios de connectivité intermittente à la base de données, il est toujours préférable d’isoler le SQL Server et de laisser le site en mode panne jusqu’à ce que tous les problèmes sous-jacents soient résolus.
• Il y a une limite de 10 000 VDA par zone.
• Les bureaux en pool 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 le leasing de connexion en termes d’utilisation de l’espace disque, mais qui nécessite considérablement plus de CPU et de mémoire. Le LHC a des phases de synchronisation au cours desquelles les détails de la base de données principale du site sont synchronisés 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 que SQL optimise ces écritures.

Le LHC utilise un seul broker qui est élu pour gérer toutes les connexions et les enregistrements VDA. Tous les VDA du site se réenregistreront auprès de ce broker unique, qui connaîtra alors une demande plus élevée de ressources (par rapport à un site multi-brokers en fonctionnement normal), en particulier dans les sites avec un grand nombre de VDA.

LHC utilise Microsoft LocalDB, qui apparaît dans le Gestionnaire des tâches en tant que 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 la base de données. Cependant, le processus augmentera au-delà de cette limite 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 les ressources accédées pendant le mode de panne sont nombreuses, plus l’utilisation de la mémoire LocalDB augmentera. Cependant, lorsque la connectivité de la base de données du site est restaurée, sqlserver.exe conservera cette mémoire et ne la renverra pas immédiatement au pool principal.

Effet des sockets et cœurs de CPU en mode de panne

LHC utilise une version d’exécution de SQL Server appelée LocalDB qui possède une licence spécifique la limitant à quatre cœurs ou à un seul socket, selon la valeur la plus faible. 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 de broker avec quatre sockets et un cœur par socket limitera LocalDB à l’utilisation d’un seul cœur, tandis que la même VM configurée comme une machine à 1 socket et 4 cœurs signifie que LocalDB peut accéder aux quatre cœurs (bien qu’ils soient partagés avec d’autres processus). En mode de panne, LocalDB exécutera le même code de broker et SQL que pendant le fonctionnement normal. De nombreuses requêtes SQL peuvent être gourmandes en CPU et avoir un impact direct sur les performances du brokering en mode de panne. Pour plus de détails, consultez Considérations relatives à la taille et à la mise à l’échelle pour les connecteurs cloud et également Limites de capacité de calcul par édition de SQL Server.

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

• Le nombre d’applications publiées
• Le nombre d’utilisateurs gérés par le broker
• Le taux auquel les utilisateurs tentent de lancer des sessions
• Performances d’Active Directory

À mesure que l’utilisation totale du CPU du broker approche 100 %, le temps de réponse du brokering augmentera, les ouvertures de session prendront plus de temps à être traitées et certaines tentatives d’ouverture de session pourront échouer.

Sites avec plusieurs brokers

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

Synchronisation avec la base de données du site

Le service CitrixConfigSync gère l’importation des données de la base de données du site vers une copie locale sur les brokers. Il surveille la base de données du site pour détecter les modifications de 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) dans un site est élevé, plus l’importation prendra du temps, mais elle devrait être inférieure à dix minutes pour un site de 10 000 VDA.

Emplacement de la base de données

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

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

Pour assurer 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 avec succès, 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 bureaux doivent avoir été attribués avant de pouvoir être utilisés en mode panne. Les bureaux non attribués ne seront pas disponibles pour le brokering. Cela peut entraîner l’indisponibilité des bureaux et le signalement d’un « mode maintenance » si une panne survient avant que toutes les attributions n’aient été synchronisées, même si un utilisateur s’est vu attribuer un bureau.

Les bureaux mis en pool 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 en matière de sécurité et de performances. Si vous configurez un groupe de mise à disposition contenant des bureaux mis en pool pour qu’ils ne redémarrent pas à la déconnexion, tous les bureaux mis en pool sous tension de ce groupe seront disponibles en mode panne. Cependant, après la déconnexion d’un utilisateur, le bureau ne sera pas dans un état propre car il n’est pas redémarré. Cela pourrait être un problème de sécurité dans n’importe quel scénario. Si l’utilisateur suivant de ce bureau est un administrateur local de ce bureau, les données d’un utilisateur précédent pourraient être accessibles. Et bien que ce risque soit moins préoccupant pour les utilisateurs standard (non-administrateurs), gardez à l’esprit que les applications pourraient se comporter de manière incorrecte et causer 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 mis en pool non redémarrés en mode panne.

Pendant une panne, aucune modification du site ne peut être effectuée ; la base de données est effectivement un instantané de la base de données principale du site et est supprimée à chaque nouvelle synchronisation.

Taille de la base de données

Pour la configuration VDI de 10 000 (c’est-à-dire 10 000 bureaux VDI à session unique), la LocalDB était d’environ 75 Mo. Pour la configuration RDS de 100 000 (c’est-à-dire 100 000 utilisateurs), la LocalDB variait entre 100 et 300 Mo, selon le nombre d’applications et de connexions. Comme une copie de la base de données est effectuée avant le début d’une nouvelle importation, prévoyez 1 Go d’espace pour la LocalDB.

Considérations relatives au dimensionnement des utilisateurs

Bien que 10 000 VDA soient le maximum par zone, étant donné que les sessions contribueront à la charge sur le broker élu pendant la panne, Citrix vous recommande de prendre également en compte le nombre maximal de sessions par zone. La densité de session entre en jeu lors de l’utilisation de VDA multisessions, car plusieurs sessions peuvent être initiées vers un seul VDA.

Pendant 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 correctement ajustée.

Les lancements d’applications sont traités de manière similaire aux lancements de bureaux. Les mêmes recommandations s’appliquent aux deux ; cependant, Citrix recommande de prendre également en compte le taux de lancement. Un seul utilisateur peut lancer plusieurs applications, augmentant ainsi la charge par utilisateur sur le broker pendant la panne.

Lors du calcul de la capacité des applications, tenez compte du nombre moyen d’applications lancées par utilisateur et maintenez-le dans la même recommandation de 25 000 par zone.

Résumé

Pendant une panne de la base de données d’un 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 CPU et de la mémoire lors de son fonctionnement.

Dans les sites à plusieurs brokers, n’importe quel broker peut être élu comme broker de panne, et par conséquent, tous doivent disposer de suffisamment de ressources pour faire face en mode panne. Aucune évaluation des ressources des brokers n’est effectuée, de sorte que dans un site avec des brokers ayant des quantités de ressources variables, il est possible que le broker le moins puissant soit élu pendant une panne.

La disposition des cœurs et des sockets doit être prise en compte dans la conception des brokers.

Le nombre d’applications et de bureaux publiés aura un effet sur les temps de réponse de connexion et le débit maximal de connexion.

Les brokers avec des ressources CPU insuffisantes peuvent rencontrer des échecs de lancement.

Citrix recommande de définir vos exclusions antivirus. Pour plus d’informations, consultez Livre blanc technique : Bonnes pratiques en matière de sécurité des points de terminaison, d’antivirus et d’anti-logiciels malveillants.

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

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

Un broker surchargé entraînera des échecs de connexion.