Considérations sur le dimensionnement et la scalabilité du cache d’hôte local

La fonctionnalité Cache d’hôte local de Citrix Virtual Apps and Desktops Service permet d’établir des connexions dans un site afin de continuer en cas de panne. Une panne se produit si la liaison WAN entre le site et la console de gestion échoue dans un environnement Citrix Cloud. Pour plus d’informations, veuillez consulter Cache d’hôte local. En décembre 2017, nous avons testé la configuration de machines Citrix Cloud Connector à l’aide de la fonctionnalité de cache d’hôte local et d’un minimum de trois Cloud Connector. Les résultats des tests fournis dans cet article détaillent les maximums testés en décembre 2017. Les recommandations en matière de meilleures pratiques sont basées sur les maximums testés.

Le cache d’hôte local prend en charge uniquement un StoreFront local dans chaque emplacement de ressources ou zone. La fonction de cache d’hôte local utilise un seul socket pour les processeurs multicœurs pour la configuration des VM de connecteur. Dans ce scénario, nous recommandons une configuration à 4 cœurs et à 1 socket.

Synthèse

Tous les résultats de ce récapitulatif sont basés sur les conclusions des environnements de test que nous avons configurés comme indiqué dans les sections suivantes. Des configurations de système différentes peuvent donner des résultats différents.

Principales recommandations basées sur les résultats des tests :

  • Nous vous recommandons, pour les sites à haute disponibilité n’hébergeant pas plus de 5 000 postes de travail ou 500 VDA de serveur, de configurer 3 VM dédiées au Cloud Connector. Chaque VM Cloud Connector nécessite 4 vCPU avec 4 Go de RAM. Cette configuration est une configuration à haute disponibilité N+1. Les Cloud Connector sont déployés dans des groupes à haute disponibilité. La charge des Cloud Connector n’est pas répartie. Étant donné que chaque processeur peut traiter un nombre limité de connexions, le processeur est le facteur limitatif le plus important lié au nombre de postes de travail ou de VDA de serveur pris en charge.
  • Bien que ce document se concentre sur des environnements de test comportant deux Cloud Connector, un ensemble N+1 de trois Cloud Connector est recommandé.
  • Nous avons effectué des tests de lancement de session pour comparer le mode de panne actif/inactif du cache d’hôte local après la synchronisation et l’importation d’une nouvelle configuration. Les tests de lancement ont couvert des scénarios portant sur le lancement de 5 000, 20 000 et 1 000 sessions avec un certain nombre de postes de travail disponibles.
    • 5 000 sessions lancées avec 5 000 VDA de poste de travail
      • Les tests ont utilisé 2 VM Cloud Connector, chacune disposant de 4 vCPU et de 4 Go de RAM. Selon la recommandation d’une configuration N+1, les environnements de production doivent inclure 3 VM Cloud Connector répondant à ces spécifications.
      • Le pic du service de cache d’hôte local a consommé 91 % des ressources du processeur, avec une moyenne de 563 Mo de mémoire disponible.
      • Il a fallu environ 10 minutes à partir du moment où le High Availability Service a détecté une panne pour que tous les VDA se réenregistrent auprès du High Availability Service, qui est désormais le broker. Nous avons mesuré à partir du moment où le High Availability Service est entré en mode de panne jusqu’à ce qu’il soit à nouveau prêt à établir des sessions.
    • 20 000 sessions lancées avec 500 VDA serveur
      • Les tests ont utilisé 2 VM Cloud Connector, chacune disposant de 4 vCPU et de 4 Go de RAM. Selon la recommandation d’une configuration N+1, les environnements de production doivent inclure 3 VM Cloud Connector répondant à ces spécifications.
      • Le pic du service de cache d’hôte local a consommé 90 % des ressources du processeur, avec une moyenne de 471 Mo de mémoire disponible.
      • Il a fallu environ 8 minutes à partir du moment où le High Availability Service a détecté une panne pour que tous les VDA se réenregistrent auprès du High Availability Service. Nous avons mesuré à partir du moment où le High Availability Service est entré en mode de panne jusqu’à ce qu’il soit à nouveau prêt à établir des sessions.
    • 1 000 sessions lancées avec 1 000 VDA de poste de travail
      • Les tests ont utilisé 2 VM Cloud Connector, chacune disposant de 2 vCPU et de 4 Go de RAM. Selon la recommandation d’une configuration N+1, les environnements de production doivent inclure 3 VM Cloud Connector répondant à ces spécifications.
      • Le pic du service de cache d’hôte local a consommé 95 % des ressources du processeur, avec une moyenne de 589 Mo de mémoire disponible.
      • Il a fallu environ 7 minutes à partir du moment où le High Availability Service a détecté une panne pour que tous les VDA se réenregistrent auprès du High Availability Service, qui est désormais le broker. Nous avons mesuré à partir du moment où le High Availability Service est entré en mode de panne jusqu’à ce qu’il soit à nouveau prêt à établir des sessions.

Vue d'ensemble de l'environnement Citrix Cloud gère les services Cloud Connector et le client gère les machines.

Méthodologie des tests

Nous avons effectué des tests en ajoutant de la charge et en mesurant les performances des composants de l’environnement :

  • UC
  • Mémoire
  • Charge de la base de données
  • Citrix Remote Broker Provider Service
  • Citrix High Availability Service

Nous avons collecté des données de performances, de durée de connexion ou les deux. Dans certains cas, des outils de simulation propriétaires Citrix ont été utilisés pour simuler des VDA et des sessions. Ces outils de simulation sont conçus pour utiliser les composants Citrix de la même manière que des sessions et des VDA traditionnels, sans avoir à héberger de sessions et VDA réels.

Le cache d’hôte local prend en charge un High Availability Service par zone et non par site. Par exemple, si vous disposez de cinq zones, un connecteur est choisi comme broker dans chaque zone. Le Citrix Config Synchronizer Service est chargé de l’importation de la base de données du site gérée par Citrix. Chaque synchronisation de la configuration crée une base de données. Des configurations initiales sont donc nécessaires, telles que la compilation des procédures stockées lors de la première utilisation de la base de données. Nous avons exécuté tous les tests après synchronisation de la configuration.

Tests de lancement de session

Sur des serveurs StoreFront gérés par le client, nous avons démarré 5 000 et 20 000 tests de session. Les outils de monitoring collectent les durées de connexion, d’énumération des ressources et de récupération des fichiers ICA de StoreFront.

Citrix utilise des outils de simulation pour faciliter le test d’un grand nombre d’utilisateurs. Les outils de simulation, qui sont la propriété de Citrix, nous permettent d’effectuer des tests avec moins de matériel que nécessaire pour exécuter des tests utilisant des sessions réelles à ces niveaux (5 000 et 20 000 sessions). Ces sessions simulées suivent le même processus, à savoir connexion à StoreFront, énumération des ressources et récupération des fichiers ICA, mais elles ne démarrent pas de bureaux actifs. Au lieu de cela, l’outil de simulation indique à la pile ICA que la session a démarrée et que toutes les communications entre l’agent Broker et le Broker Service sont cohérentes avec celles d’une session réelle. Les mesures de performance sont collectées à partir des Citrix Cloud Connector. Pour déterminer la réponse de l’environnement aux lancements de session, 25 sessions simultanées ont été lancées pendant toute la durée du test. Les mesures montrent donc les résultats d’un système soumis à une charge tout au long du test.

Résultats des tests

Lancement de session

Les tableaux suivants comparent les tests de lancement de session entre le mode de panne actif et inactif du cache d’hôte local après la synchronisation et l’importation d’une nouvelle configuration. Chaque tableau montre les résultats du nombre de sessions lancées dans le test.

5 000 sessions VDA de poste de travail

  Mode de panne du cache d’hôte local inactif (opérations normales)/Délai moyen Mode de panne du cache d’hôte local actif/Délai moyen
Authentification 193 ms 95 ms
Énumération 697 ms 75 ms
Temps total d’ouverture de session 890 ms 170 ms
Récupération du fichier ICA 4 191 ms 156 ms

20 000 sessions VDA de serveur

  Mode de panne du cache d’hôte local inactif (opérations normales)/Délai moyen Mode de panne du cache d’hôte local actif/Délai moyen
Authentification 135 ms 112 ms
Énumération 317 ms 91 ms
Temps total d’ouverture de session 452 ms 203 ms
Récupération du fichier ICA 762 ms 174 ms
  • Test portant sur le lancement de 5 000 sessions VDA de poste de travail
    • Il y avait une latence d’environ 30 ms entre les Citrix Cloud Connector et Citrix Delivery Controller lorsque le mode de panne du cache d’hôte local était inactif.
    • Il existe une différence de 720 ms dans le processus de connexion lorsque le mode de panne du cache d’hôte local est actif par rapport au mode inactif, alors que StoreFront est en condition de charge.
    • La plus grande différence de temps réside dans la récupération du fichier ICA, qui est de 4 secondes. Cela est dû en grande partie au fait que le connecteur effectue le brokering, alors que normalement le trafic StoreFront traverse les connecteurs jusqu’au Citrix Delivery Controller dans Azure et inversement.
  • Test de lancement de 20 000 sessions VDA de serveur
    • Il existe une différence de 249 ms dans le processus de connexion lorsque le mode de panne du cache d’hôte local est actif par rapport au mode inactif, alors que StoreFront est en condition de charge.
    • La différence dans la récupération du fichier ICA est d’environ 1 seconde.
  • Par rapport au lancement de 5 000 sessions VDA de poste de travail, le test de lancement de 20 000 sessions ne contient que 500 VDA de serveur, ce qui entraîne moins d’appels du Citrix Delivery Controller aux VDA, et réduit les temps de réponse.

Comparaison de l’utilisation moyenne du processeur

Test de lancement de session   % d’UC moyenne % de pic d’UC
5 000 sessions VDA de poste de travail Connector 1 8.3 38.2
  Connector 2 8.4 33.3
5 000 sessions VDA de poste de travail - Mode de panne du cache d’hôte local actif Connector 1 (High Availability Service sélectionné) 42 91
  Connector 2 0.8 5
20 000 sessions VDA de serveur Connector 1 . 62
  Connector 2 . 55
20 000 sessions VDA de server - Mode de panne du cache d’hôte local actif Connector 1 (High Availability Service sélectionné) 57 90
  Connector 2 0.8 6.6
  • Le tableau compare l’utilisation processeur de Citrix Cloud Connector avec le mode de panne du cache d’hôte local actif et inactif durant les tests portant sur le lancement de 5 000 sessions VDA de poste de travail et 20 000 sessions VDA de serveur.
  • Tous les Cloud Connector sont équipés de 4 vCPU et de 4 Go de RAM
  • Les machines High Availability Service sélectionnées ont culminé à respectivement 91 % et 90 % d’utilisation globale du processeur. Il convient de noter que, même si le High Availability Service non sélectionné n’est pas très utilisé, il peut devenir actif en cas de panne du High Availability Service sélectionné. Il est donc essentiel que les connecteurs aient des spécifications de connecteur identiques.

Utilisation de la mémoire disponible

Test de lancement de session   Mémoire moyenne disponible (plage de travail en Mo) Mémoire maximale disponible (plage de travail en Mo)
5 000 sessions VDA de poste de travail Connector 1 636 657
  Connector 2 786 801
5 000 sessions VDA de poste de travail - Mode de panne du cache d’hôte local actif Connector 1 (High Availability Service sélectionné) 563 618
  Connector 2 912 918
20 000 sessions VDA de serveur Connector 1 1 030 1 195
  Connector 2 1 178 1 329
20 000 sessions VDA de serveur - Mode de panne du cache d’hôte local actif Connector 1 (High Availability Service sélectionné) 471 687
  Connector 2 1 210 1 227
  • Le tableau compare l’utilisation de mémoire disponible avec le mode de panne du cache d’hôte local actif et inactif durant les tests portant sur le lancement de 5 000 sessions VDA de poste de travail et 20 000 sessions VDA de serveur.
  • Le nombre de sessions diminue la quantité de mémoire disponible.
  • L’utilisation de la mémoire augmente de 54,35 % (559 Mo) avec 20 000 sessions VDA de serveur lorsque le mode de panne du cache d’hôte local est actif, principalement en raison de la consommation de mémoire du serveur SQL.

Utilisation du processeur Cloud Connector par composant

Test de lancement de session Composant % d’UC moyenne % de pic d’UC
5 000 sessions VDA de poste de travail Connector 1 LSASS 2.4 10.7
  Connector 1 XaXdCloudProxy 3.5 18.5
  Connector 2 LSASS 2.5 12.9
  Connector 2 XaXdCloudProxy 3.5 21.2
5 000 sessions VDA de poste de travail - Mode de panne du cache d’hôte local actif Connector 1 (High Availability Service sélectionné) LSASS 12.9 29.5
  Connector 1 (High Availability Service sélectionné) HighAvailabilityService 14.7 49.7
20 000 sessions VDA de serveur Connector 1 LSASS 7 12.2
  Connector 1 XaXdCloudProxy 8.7 15.5
  Connector 2 LSASS 7 12.5
  Connector 2 XaXdCloudProxy 9 15.7
20 000 sessions - Mode de panne du cache d’hôte local actif Connector 1 (High Availability Service sélectionné) LSASS 4.3 17.2
  Connector 1 (High Availability Service sélectionné) HighAvailabilityService 4.5 18.2
  • Le tableau ci-dessus présente les processus qui consomment le plus de ressources processeur lorsque le mode de panne du cache d’hôte local est actif, par rapport au mode de panne du cache d’hôte local inactif durant les tests portant sur le lancement de 5 000 sessions VDA de poste de travail et 20 000 sessions VDA de serveur.
  • Le Citrix Remote Broker Provider Service (XaXdCloudProxy) est le principal consommateur de processeur lorsque le mode de panne du cache d’hôte local est inactif.
  • Le service LSASS (service de sous-système de l’autorité de sécurité locale) utilise le processeur lors des ouvertures de session. Toutes les authentifications provenant de services gérés par Citrix doivent traverser les Citrix Cloud Connector pour communiquer avec l’Active Directory géré par le client.

  • Le Citrix High Availability Service est utilisé pour négocier les sessions, ce qui entraîne une utilisation accrue du processeur lorsque le mode de panne du cache d’hôte local est actif. En outre, l’utilisation du processeur a atteint 49,7 % lors du lancement de 5 000 sessions VDA de poste de travail, contre 18,25 % seulement lors du lancement de 20 000 sessions VDA de serveur (500 VDA). La différence est due au nombre de VDA.
  • Le Connector 2 ne présentait aucun résultat significatif, car il ne s’agissait pas du High Availability Service sélectionné.

Durée de réenregistrement des VDA lors du passage au cache d’hôte local

Lors d’une panne d’un Delivery Controller, les 5 000 VDA de poste de travail doivent se réenregistrer auprès du broker de cache d’hôte local sélectionné. Cette durée de réenregistrement était d’environ 10 minutes. La durée de réenregistrement de 500 VDA de serveur était d’environ 8 minutes.

Nombre de VDA Durée de réenregistrement
5 000 VDA de poste de travail ~10 minutes
500 VDA de serveur ~8 minutes

Durée des pannes

Panne Nombre de VDA Heure
Entrer en mode panne   10 minutes
Durée de ré-enregistrement au High Availability Service sélectionné 500 ~8 minutes
  5000 ~10 minutes
Quitter le mode panne   10 minutes
Durée de ré-enregistrement à Citrix Delivery Controller 500 ~5.5 minutes
  5000 ~1.5 minutes
  • Il faut un total de 20 minutes pour entrer (10 minutes) et quitter le mode panne (10 minutes). Ceci est dû au nombre de contrôles d’intégrité de Citrix Delivery Controller requis. Le temps requis pour réenregistrer les VDA s’ajoute à la durée totale de la panne.
  • Si le réseau connaît des interruptions répétées, forcer une panne jusqu’à la résolution des problèmes réseau empêche le basculement en continu entre les modes de fonctionnement normal et de panne.

Métriques de base de données et du High Availability Service avec cache d’hôte local

Test de lancement de session Transactions moyennes/s de base de données sur High Availability Service Pics de transactions/s de base de données sur High Availability Service
5 000 sessions VDA de poste de travail 436 1 344
20 000 sessions VDA de serveur 590 2 061

Le tableau précédent indique le nombre de transactions de base de données par seconde sur le High Availability Service sélectionné.

Comparaison de l’utilisation du processeur StoreFront

Test de lancement de session % d’UC moyenne % de pic d’UC
5 000 sessions VDA de poste de travail 4.5 32.4
5 000 sessions VDA de serveur - Mode de panne du cache d’hôte local 13.8 32.6
20 000 sessions VDA de serveur 11.4 22.1
20 000 sessions VDA de serveur - Mode de panne du cache d’hôte local 18.6 33.2
  • Le tableau précédent compare l’utilisation du processeur StoreFront lorsque le mode de panne du cache d’hôte local est actif, par rapport au mode inactif durant les tests portant sur le lancement de 5 000 sessions VDA de poste de travail et 20 000 sessions VDA de serveur.
  • La machine StoreFront présente les spécifications suivantes : Windows 2012 R2, 8 vCPU (2 sockets, 4 cœurs chacun), 8 Go de RAM
  • Lorsque le mode de panne du cache d’hôte local est actif, l’utilisation moyenne du processeur augmente d’environ 9 % dans les tests portant sur le lancement de 5 000 sessions VDA de poste de travail et d’environ 7 % sur le lancement de 20 000 sessions VDA de serveur. L’augmentation est principalement due au fait que le serveur IIS traite plus de demandes lorsque le mode de panne du cache de l’hôte local est actif. L’utilisation du processeur est plus élevée car StoreFront traite les lancements de session plus rapidement que lorsque le mode de panne est inactif.

Comparaison de l’utilisation de la mémoire disponible dans StoreFront

Test de lancement de session Mémoire moyenne disponible (plage de travail en Mo) Mémoire maximale disponible (plage de travail en Mo)
5 000 sessions VDA de poste de travail 5 731 6 821
5 000 sessions VDA de poste de travail - Mode de panne du cache d’hôte local 5 345 5 420
20 000 sessions VDA de serveur 4 671 4 924
20 000 sessions VDA de serveur - Mode de panne du cache d’hôte local 4 730 5 027
  • Le tableau précédent compare l’utilisation de la mémoire disponible dans StoreFront lorsque le mode de panne du cache d’hôte local est actif, par rapport au mode inactif durant les tests portant sur le lancement de 5 000 sessions VDA de poste de travail et 20 000 sessions VDA de serveur.
  • Lorsque le mode Cache d’hôte local est actif, l’utilisation de la mémoire augmente de 6,73 % au cours du test de lancement de 5 000 sessions VDA de poste de travail.

Le tableau ci-dessous compare le mode de panne actif/inactif après l’importation d’une nouvelle synchronisation de configuration, le lancement de 1 000 sessions sur 1 000 VDA de poste de travail avec cache d’hôte local et l’utilisation de Citrix Cloud Connector configurés avec 2 VM vCPU.

Comparaison du lancement de sessions

  Mode de panne du cache de l’hôte local inactif (opérations normales) Mode de panne du cache d’hôte local actif
Authentification 359 ms 89 ms
Énumération 436 ms 180 ms
Temps total d’ouverture de session 795 ms 269 ms
Récupération du fichier ICA 804 ms 549 ms
  • Lorsque StoreFront est soumis à des charges, il existe une différence de 526 ms dans le processus de connexion lorsque le mode de panne du cache d’hôte local est actif par rapport au mode inactif.
  • Il existe une différence de 255 ms dans la récupération du fichier ICA lorsque le mode de panne du cache de l’hôte local est actif par rapport au mode inactif. La différence augmente avec le nombre de sessions.

Comparaison de l’utilisation moyenne du processeur

Comparaison de l'utilisation moyenne du processeur

Le High Availability Service sélectionné a atteint un maximum de 95 % d’utilisation globale du processeur, ce qui indique que 1 000 VDA de poste de travail constituent une configuration optimale pour une VM connector à 2vCPU.

Comparaison de l’utilisation moyenne de mémoire

Comparaison de l'utilisation moyenne de mémoire

Le graphique précédent présente une comparaison de l’utilisation de la mémoire disponible de Citrix Cloud Connector lorsque le mode de panne du cache d’hôte local est actif par rapport au mode inactif lors du lancement de 1 000 sessions VDA de poste de travail. Il n’y a pas de différence significative dans l’utilisation de la mémoire en fonction du mode de panne du cache d’hôte local.

Comparaison d’utilisation du processeur par composant Cloud Connector

Comparaison d'utilisation du processeur par composant Cloud Connector

Le graphique précédent affiche les processus qui consomment le plus de ressources processeur lorsque le mode de panne du cache d’hôte local est inactif.

Ressources processeur

  • Le graphique précédent affiche les processus qui consomment le plus de ressources processeur lorsque le mode de panne du cache d’hôte local est actif.
  • Le Connector 2 ne présentait aucun résultat significatif.

Durée de réenregistrement des VDA lors du basculement vers le cache d’hôte local

Lors d’une panne d’un Delivery Controller, les 1 000 VDA de poste de travail doivent se réenregistrer auprès du broker de cache d’hôte local sélectionné. La durée de réenregistrement était d’environ 7 minutes.

Métriques de base de données et du High Availability Service avec cache d’hôte local

Métriques de base de données et du High Availability Service

Le graphique précédent affiche le nombre de transactions de base de données par seconde sur le High Availability Service sélectionné.

Impact de l’augmentation du nombre de zones sur les durées d’importation de base de données

Une zone supplémentaire (avec une paire de ses propres connecteurs) a été ajoutée au site de test pour en comprendre l’impact. La première zone comprend 5 500 objets uniques (2 catalogues). La zone secondaire est un miroir de la première zone et possède ses propres objets uniques, totalisant 11 000 objets. Il est important de noter que le cache d’hôte local est recommandé uniquement pour les zones ne contenant pas plus de 10 000 objets. Avant l’ajout de la zone secondaire, la durée d’importation de la base de données sur les connecteurs était d’environ 4 minutes, 20 secondes. Après avoir ajouté la zone secondaire et l’avoir renseignée avec 11 000 objets, la durée d’importation a augmenté d’environ 30 secondes à environ 4 minutes et 50 secondes. L’ajout de davantage de catalogues a un impact marginal sur les durées d’importation. Les principaux facteurs contribuant à la dégradation des performances et à l’augmentation des durées d’importation sont basés sur le nombre de machines attribuées, d’utilisateurs et de PC distants. De plus, 5 500 objets ont été répartis entre 2 zones et la durée d’importation est restée la même

Nombre de zones Nombre total d’objets Durée d’importation
1 5 500 4 minutes 20 secondes
2 11 000 4 minutes 50 secondes
2 5 500 4 minutes 20 secondes

Guide de dimensionnement des connecteurs

Pour des performances optimales, les configurations suivantes sont recommandées pour Citrix Cloud Connector lorsque le mode Cache d’hôte local est activé.

Recommandation 1 : pour prendre en charge 1 000 VDA de poste de travail utilisant le mode cache d’hôte local avec Citrix Cloud Connector

  • 2 VM Windows 2012 R2, chacune dotée de 2 vCPU (1 socket, 2 cœurs), 4 Go de RAM
  • Ce dimensionnement recommandé est basé sur une utilisation maximale du processeur de 95 % et une moyenne d’utilisation de la mémoire disponible de 589 Mo de Citrix Cloud Connector lorsque le mode de cache d’hôte local est actif.

Recommandation 2 : pour prendre en charge 5 000 VDA de poste de travail OU 500 VDA de serveur utilisant le mode cache d’hôte local avec Citrix Cloud Connector

  • 2 VM Windows 2012 R2, chacune dotée de 4 vCPU (1 socket, 4 cœurs), 4 Go de RAM
  • Ce dimensionnement recommandé est basé sur
    • 5 000 sessions VDA de poste de travail lancées avec le mode cache d’hôte local actif
      • 91 % d’utilisation maximale du processeur
      • 563 Mo de mémoire disponible moyenne
    • 20 000 sessions VDA de serveur lancées avec le mode cache d’hôte local actif
      • 90 % d’utilisation maximale du processeur
      • 471 Mo de mémoire disponible moyenne

Consultez Considérations sur le dimensionnement et la scalabilité des Cloud Connector pour plus d’informations sur le dimensionnement et la scalabilité.

Environnement de test

L’environnement de test a utilisé des outils de test propriétaires développés en interne et des VM configurées selon les spécifications détaillées dans les sections suivantes.

Outils utilisés

Nous avons utilisé un outil de test interne pour collecter les données de performance et les mesures depuis les machines testées et pour initier les lancements de sessions. L’outil de test interne orchestre le lancement des sessions utilisateur dans l’environnement Citrix Virtual Apps and Desktops. L’outil de test fournit également un emplacement central à partir duquel nous recueillons des données de temps de réponse et des mesures de performance. En substance, l’outil de test administre les tests et collecte les résultats.

Configuration du test – Citrix Virtual Apps and Desktops Service

Vous trouverez ci-dessous une liste des spécifications de machine et de système d’exploitation utilisées lors des tests de Citrix Virtual Apps and Desktops Service.

  • Cloud Connector :
    • 2 VM Windows 2012 R2, chacune dotée de 4 vCPU (1 socket, 4 cœurs), 4 Go de RAM
    • 2 VM Windows 2012 R2, chacune dotée de 2 vCPU (1 socket, 2 cœurs), 4 Go de RAM
  • StoreFront (géré par le client) : Windows 2012 R2, 8 vCPU (2 sockets, 4 cœurs chacun), 8 Go de RAM
  • Hyperviseur : Citrix XenServer 7.0 + mises à jour, 5x HP Blade BL 460C Gen 9, 2x processeurs Intel E5-2620, 256 Go de RAM
  • Stockage d’hyperviseur : partage NFS 2 To sur NetApp 3250
  • VDA : Windows 2012 R2

Collecte des données

Nous recueillons les mesures suivantes pour chaque test :

  • Augmentation moyenne de l’utilisation globale du processeur, de la mémoire et des composants (processus du cloud)
  • Durée de ré-enregistrement des VDA lors du basculement vers le High Availability Service avec cache d’hôte local sélectionné
  • Métriques de base de données et du High Availability Service lorsque le mode de panne du cache d’hôte local est actif
  • Comparaison des lancements de session, durée moyennes pour
    • Authentification
    • Énumération
    • Récupération du fichier ICA
  • Impact de l’augmentation du nombre de zones sur les durées de synchronisation de la base de données
    • Temps requis pour la synchronisation après un changement de configuration

Considérations sur le dimensionnement et la scalabilité du cache d’hôte local