Concepts avancés

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

Le cache hôte local a été introduit dans XenApp et XenDesktop 7.12 pour remplacer la fonctionnalité de location de connexion fournie dans XenDesktop 7.6. Local Host Cache couvre plus de scénarios que la location de connexion, mais nécessite des considérations de conception différentes.

  • Le cache hôte local prend en charge plus de cas d’utilisation que la location de connexion.
  • Lorsqu’il est opérationnel, le cache hôte local nécessite plus de ressources (CPU et mémoire) que la location de connexion.
  • En mode panne, un seul broker par zone gère les enregistrements VDA et les sessions de broker.
  • Un processus électoral détermine quel broker sera actif en cas de panne, mais ne tient pas compte des ressources du broker.
  • Si un broker unique dans une zone ne serait pas capable de gérer toutes les ouvertures de session pendant le fonctionnement normal, cela ne fonctionnera pas bien en mode panne.
  • Aucune gestion de site n’est disponible en mode panne.
  • Un SQL Server hautement disponible reste la conception recommandée.
  • Pour les scénarios de connectivité de base de données intermittente, 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 y a une limite de 5 000 VDA par zone (non appliquée).
  • Il n’y a pas de limite de 14 jours.
  • Les postes de travail groupés ne sont pas pris en charge en mode panne, dans la configuration par défaut.

Architecture

La location de connexion a été introduite dans XenDesktop 7.6 pour permettre un accès continu aux ressources pendant les périodes d’interruption de la base de données du site. Il ne prend pas en charge les postes de travail groupés VDI et, par défaut, les utilisateurs doivent se connecter à une ressource au cours des 14 jours précédents. Une autre restriction était qu’il tenterait de connecter les utilisateurs au dernier hôte de poste de travail ou d’application auquel ils se sont connectés pendant le fonctionnement normal. Si cela n’était pas disponible, la connexion ne serait pas négociée.

L’architecture des deux technologies (location de connexion et cache hôte local) est très différente, et elles nécessitent des ressources différentes pour fonctionner. La location de connexion crée des fichiers de location XML individuels, qui peuvent nécessiter plusieurs Go d’espace disque, en fonction du nombre de ressources dans un site. Local Host Cache utilise une base de données SQL Server locale et est plus efficace dans l’utilisation de l’espace disque, mais nécessite beaucoup plus de mémoire et de CPU que la location de connexion. Les deux ont des phases de synchronisation où les détails de la base de données du site principal sont synchronisés avec les brokers (Controllers). La synchronisation initiale de la location de connexion peut entraîner des E/S par seconde considérables en raison du nombre total de fichiers individuels créés sur le système de fichiers. Bien que Local Host Cache utilise une base de données SQL qui nécessite encore des E/S par seconde, il a l’avantage d’optimiser SQL ces écritures.

Dans une configuration de location de connexion avec plusieurs brokers, chaque broker a une copie des baux XML et est capable de broker des connexions lors d’une panne, ce qui aide à équilibrer la charge. Toutefois, avec Local Host Cache, un broker unique est choisi pour négocier toutes les connexions et gérer les enregistrements VDA. Tous les VDA du site se réinscriront auprès de ce broker unique et, à ce titre, ce broker connaîtra une plus grande demande de ressources par rapport à un site multi-broker en fonctionnement normal, en particulier dans les sites comptant un grand nombre de VDA.

Local Host Cache 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 mémoire tampon 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 les ressources sont accessibles en mode panne, plus l’utilisation de la mémoire LocalDB augmentera. Toutefois, lorsque la connectivité de la base de données de site est restaurée, sqlserver.exe conservera cette mémoire et ne la renvoie pas immédiatement au pool principal.

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

Dans les versions précédentes de XenApp et XenDesktop, les administrateurs ne se préoccupaient pas nécessairement de la configuration du processeur de la machine Broker (Controller) : la disposition du nombre de sockets et de cœurs, soit dans une machine physique ou virtuelle.

Local Host Cache utilise une version d’exécution de SQL Server appelée LocalDB qui dispose d’une licence spécifique qui le limite au moindre des quatre cœurs ou d’un socket unique. 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 double cœur. Une machine de courtage avec 4 sockets et un cœur par socket limitera LocalDB à utiliser un seul cœur, alors que la même machine virtuelle configurée comme une machine à 1 socket 4 core signifie que LocalDB peut accéder aux 4 cœurs (bien que les partager 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.

D’autres facteurs incluent la configuration du site elle-même :

  • Nombre de demandes publiées
  • Nombre d’utilisateurs faisant l’objet d’un courtage
  • Taux auquel 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 broker réponde aux exigences supplémentaires de Local Host Cache, au cas où il serait choisi.

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 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 en cours est effectuée avant le début de l’importation. Plus le nombre de ressources (telles que les VDA) dans un site est important, plus l’importation prendra de temps, mais elle devrait être inférieure à dix minutes pour un site avec 5000 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 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 réussit pas, 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.

Comparaison de Local Host Cache avec la location de connexion

  Location de connexion Cache d’hôte local
Espace disque 2 Go recommandés Dépend de la configuration du site. Pour 50 hôtes RDS avec 125 000 utilisateurs, 300 Mo sont utilisés.
RAM 100 MO 3 Go, ~ 1 Go pour SQL Server, 2 Go pour High Availability Service et CitrixConfigSync Service.
Temps de synchronisation de la configuration Dépendante IOPS ; 40 000 VDA : ~ 26 minutes 5 000 VDA : ~ 7 minutes
Temps d’activation en cas de panne 150 secondes, délai d’attente SQL de 30 secondes + délai d’attente de 120 secondes (configurable) Dépend du nombre de VDA et de la dernière synchronisation d’enregistrement avec le broker. Seul un broker unique sera disponible pour l’enregistrement VDA en mode panne, donc pour un grand nombre de VDA, cela peut prendre plusieurs minutes avant que tous les VDA ne soient enregistrés.
Temps de restauration des opérations normales 120 secondes pour la désactivation du crédit-bail, alors les VDA doivent se réenregistrer auprès des brokers Comme ci-dessus, les VDA devront annuler leur inscription auprès du broker secondaire et se réinscrire auprès du broker principal.
Nombre de VDA pris en charge 50,000 5,000. Un site peut avoir plus que cela, mais le temps nécessaire pour synchroniser la base de données du site augmentera avec le nombre de VDA. Les performances d’un broker unique avec un grand nombre de VDA peuvent entraîner le fait que certaines connexions ne soient pas négociées pendant la panne.
Gestion du site en cas de panne Non Non

Configuration des limites de mémoire LocalDB

Le processus LocalDB a été limité à 1 Go de RAM pour la mise en cache, ce qui ne devrait pas normalement être modifié. Cette valeur peut être modifiée si nécessaire ; pour que les modifications prennent effet, le site doit fonctionner normalement (pas en mode d’interruption) et une synchronisation de la base de données du site doit être forcée.

Pour réduire la mémoire à 768 Mo :

Étape 1. Modifiez le fichier C:\Program Files\Citrix\Broker\Service\HighAvailabilityService.exe.config.

Recherchez la section <appSettings> et ajoutez une entrée :

<add key="MaxServerMemoryInMB" value="768" />

Étape 2 : Pour forcer la synchronisation de la base de données, arrêtez le service de haute disponibilité. Si sqlserver.exe est en cours d’exécution, arrêtez-le à l’aide du Gestionnaire des tâches ou de PowerShell.

Étape 3. Maintenant, apportez une modification triviale au site, par exemple, modifiez la description d’un groupe de mise à disposition en ajoutant un « . », puis supprimez-le à nouveau. Ensuite, démarrez le service de haute disponibilité ; cela devrait démarrer sqlserver.exe et une synchronisation doit se produire.

Une réduction excessive de la mémoire affectera les performances et n’est pas recommandée. Cependant, l’augmenter à 2 Go n’améliore pas les performances de manière significative, et la ressource CPU est plus un goulot d’étranglement que la RAM.

Activation ou désactivation du cache hôte local

La location de connexion et le cache hôte local peuvent être désactivés, mais un seul d’entre eux peut être actif à la fois.

Set-BrokerSite –ConnectionLeasingEnabled $False

Set-BrokerSite –LocalHostCacheEnabled $True

Limitations

Les postes de travail doivent avoir été affectés avant de pouvoir être utilisés en mode panne. Les postes de travail non affectés ne seront pas disponibles pour le courtage. Cela peut entraîner l’indisponibilité des postes de travail et la création de rapports « en mode maintenance » si une panne se produit avant que toutes les affectations aient été synchronisées, bien qu’un utilisateur ait effectivement été affecté à un poste de travail.

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 en matière de sécurité et de performances. Si vous configurez un groupe de mise à disposition contenant des postes de travail groupés pour ne pas redémarrer à la fermeture de session, tous les postes de travail groupés sous tension de ce groupe seront disponibles en mode panne. Toutefois, après la déconnexion d’un utilisateur, le Bureau ne sera pas dans un état propre car le Bureau 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 peuvent ê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 postes de travail groupés non redémarrés en mode panne.

Comme dans le cas de la location de connexion, aucune modification de site ne peut être apportée en cas de panne ; la base de données est effectivement un instantané de la base de données du site principal et est supprimée chaque fois qu’une nouvelle synchronisation se produit.

Comparaison des performances du broker vCPU 6 et 8 dans des conditions de stress

Un site a été configuré avec 50 travailleurs RDS et 5075 VDA VDI. Chaque travailleur RDS est capable de prendre en charge 2500 utilisateurs simulés. Un taux de lancement de 20 utilisateurs par seconde a été fixé. Différents nombres de demandes publiées ont été ajoutés au site.

Pour les travailleurs RDS, 100 000 utilisateurs ont été lancés, pour VDI 5075.

Les tests ont été effectués en mode normal et local Host Cache opérationnel (panne).

Dans le système 6 vCPU, il y a très peu d’espace CPU, et un petit nombre d’exceptions (< 10) se sont produites lorsque le nombre d’applications publiées était > 0.

Les mises à jour Windows ont été désactivées par la stratégie de groupe car au cours d’un certain nombre d’exécutions, le processus tiworker.exe (Windows Installer Module) a été trouvé utiliser presque un noyau entier pendant des périodes prolongées. Cela a entraîné un grand nombre d’échecs de lancement, de sorte que les tests ont été réexécutés. Le processeur de broker est assez ancien, mais le processus tiworker consommera un seul cœur d’un nouveau, affectant le test.

Configuration de l’hyperviseur

  • XenServer 7.0
  • AMD Opteron 8431 2,4 GHz — 4x6 cœurs
  • 128 GO DE RAM
  • Mise en cache en lecture activée
  • Windows Storage Server 2012R2 avec stockage basé sur SSD

Configuration du broker

  • 2 prises avec 3 cœurs et 2 prises avec 4 cœurs
  • 10 GO DE RAM
  • Windows Server 2016
  • Groupe de mise à disposition unique pour chaque type de VDA
  • Toutes les applications visibles par l’utilisateur
  • XenDesktop 7.12

Configuration du StoreFront

  • 6 serveurs StoreFront
  • Windows Server 2016
  • 4 processeurs virtuels
  • 10 GO DE RAM

Configuration de NetScaler

  • VPX 8000 version 11.063.16

Configuration de SQL Server

  • Intel E5-2630 2,3 GHz 2x12 cœurs
  • SQL Server 2012
  • 64 GO DE RAM

Remarque : Seule la base de données du site a été mise hors ligne ; les bases de données de surveillance et de configuration étaient toujours accessibles pendant le test. Cela signifie que le service Monitor consomme du CPU pendant les tests.

graphique montrant les temps de réponse d'ouverture de session

En général, à mesure que le nombre d’applications augmente, le temps de réponse d’ouverture de session augmente et les temps de réponse d’interruption sont pires que le fonctionnement normal. L’augmentation du nombre de vCPU améliore les temps de réponse. Gardez à l’esprit que le CPU utilisé dans les tests est assez vieux et les CPU plus modernes donneront généralement de meilleures performances.

graphique indiquant le temps d'ouverture de session

La ligne ‘min théorique’ est le temps minimum absolu que 100.000 utilisateurs prendrait pour ouvrir une session si l’environnement était capable de traiter 20 lancements par seconde, donnant 1 heure 23 minutes 20 secondes. Dans ces tests, la ligne 0 applications a géré 1:30:57 dans le cas de 6 vCPU, et 1:30:48 dans le cas de 8 vCPU. Les performances du domaine Active Directory auront un impact sur la rapidité avec laquelle les utilisateurs sont authentifiés.

graphique montrant l'utilisation de la mémoire de base de données locale du cache d'hôte local

Dans des conditions normales, l’utilisation de la mémoire LocalDB augmente pendant le fonctionnement et s’accroche à cette mémoire à moins qu’il n’y ait une pression sur le système ; plus les utilisateurs sont traités, plus la mémoire utilisée est grande, jusqu’à la limite de 1 Go. Dans le premier test VDI, LocalDB n’avait pas libéré de mémoire de l’exécution RDS précédente. Pour les tests VDI suivants, le broker a été redémarré avant le test et moins de mémoire a été utilisée.

graphique montrant l'utilisation de la mémoire du service haute disponibilité du cache de l'hôte local

graphique montrant l'utilisation du CPU du cache hôte local

Remarque : les valeurs ont été normalisées à la CPU totale du système, donc 33,33% sont deux cœurs sur six, 30% sont 2-1/2 sur la configuration de 8 vCPU.

Le terme « off » fait référence au fonctionnement normal du site ; « on » signifie que le cache hôte local est actif.

Le taux de lancement de la demande de 20 utilisateurs par seconde est assez exigeant pour le broker, même en fonctionnement normal. En fonctionnement normal, le système 6 vCPU n’a pas de marge de manœuvre ; le processeur du broker augmente à mesure que le nombre d’applications publiées augmente, ce qui entraîne des temps de réponse plus lents. Lorsque le cache hôte local est actif, le service de broker secondaire doit rivaliser avec LocalDB (SQL) pour la ressource CPU, ce qui donne des temps de réponse plus mauvais que le fonctionnement normal.

Dans le système 8 vCPU, il y a une certaine marge de manœuvre et le LocalDB va augmenter, mais dans cet environnement, il a atteint un sommet de 2 à 1/2 cœurs, bien qu’il y ait une petite quantité de CPU encore disponible.

Pendant le fonctionnement normal, LocalDB ne consomme pas de CPU à moins qu’une synchronisation n’ait lieu.

En cas de panne, le broker principal utilisera pratiquement aucun processeur.

Taille de la base de données

Pour la configuration VDI 5075, le LocalDB était d’environ 40 Mo, pour les 100 000 RDS, cela variait entre 100 et 300 Mo, selon le nombre d’applications et d’ouvertures de session. Comme une copie de la base de données est effectuée avant le début d’une nouvelle importation, autorisez 1 Go d’espace pour LocalDB.

Résumé

Lors d’une panne de base de données de site, le cache hôte local prend en charge un plus grand nombre de ressources et de conditions que la location de connexion, mais nécessite plus de CPU et de mémoire lors de l’exploitation.

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 de broker n’est faite, donc dans un site avec des brokers moins puissants et plus puissants, il est possible que le broker le moins puissant soit élu en cas de 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 publiées aura un effet sur les temps de réponse d’ouverture de session et le débit maximal d’ouverture de session.

Les brokers avec une ressource CPU insuffisante peuvent entraîner des lancements échoués.

Deux cœurs supplémentaires et 2 Go de RAM constituent un bon point de départ pour tester les performances en mode d’interruption du cache hôte local par rapport à la location de connexion.

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

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

Cet article a été écrit par Joe Deller.