Dimensionnement des instances de VDA sur Google Cloud Compute Engine

Introduction

Ce document fournit l’évolutivité de l’instance unique et des conseils économiques pour les entreprises qui déploient des charges de travail Citrix (VDA) sur Google Cloud Compute Engine. L’accent est mis sur les charges de travail partagées hébergées (VDA Windows Server avec rôle RDSH installé) exécutées sur des instances de machines virtuelles Google Compute Engine. Les tests à l’échelle ont été réalisés à l’aide d’une charge de travail synthétique lourde et reproductible, dans le but de fournir des conseils conservateurs mais exploitables. Nous terminerons par quelques conseils de dimensionnement pour Google Cloud VMware Engine.

Sommaire

Les résultats de cette étude suggèrent ce qui suit :

  • Pour un grand pourcentage de cas d’utilisation (charges de travail), les performances d’un VDA Citrix ont tendance à être limitées par le processeur par rapport au disque ou au réseau.
  • La meilleure expérience utilisateur final (telle que mesurée, compte tenu de notre charge de travail de référence élevée) a été fournie par les derniers processeurs disponibles sur Google Cloud au moment de la publication. Ils sont disponibles dans les familles d’instances N2, N2D et C2, et exploitent les processeurs Cascade Lake d’Intel et Milan d’AMD.
  • La famille de machines virtuelles Tau de Google n’était pas disponible pour ce test, mais elle vaut probablement la peine d’être prise en compte pour les charges de travail Citrix VDA.
  • Les tailles d’instance à 4 et 8 processeurs virtuels ont tendance à offrir la densité la plus élevée et les coûts par utilisateur les plus faibles.
  • Pour notre lourde charge de travail de test, le type d’instance N2D-Standard-8, (avec le processeur AMD Milan), était le plus rentable, avec des coûts aussi bas que 0,028$ par heure utilisateur selon la tarification publiée.
  • Avec les derniers processeurs, le type de stockage utilisé pour les disques persistants n’a pas d’impact significatif sur l’évolutivité des instances.
  • Bien qu’elles ne soient pas explicitement testées dans le cadre de cette étude, les charges de travail qui nécessitent un GPU doivent être exécutées sur des types d’instances N1. Lorsque l’accélération GPU est une exigence, l’exploitation des processeurs Skylake et du stockage sur disque persistant SSD Premium permettra probablement d’obtenir les meilleures performances et la plus grande évolutivité.

Considérations relatives à l’

Dans cette section, nous abordons certains des facteurs clés qui influent sur l’évolutivité d’un serveur unique, tels que la charge de travail, la surcharge du processeur, l’architecture du processeur et la sélection du stockage.

La sélection de la charge de travail utilisée pour les tests doit correspondre approximativement aux utilisateurs de votre environnement. Par exemple, si 50 % de vos utilisateurs génèrent une charge utilisateur légère, que 30 % d’entre eux génèrent une charge modérée et que les 20 % restants génèrent une charge de travail lourde, l’utilisation d’une charge de travail modérée vous donnera une idée approximative de ce à quoi vous attendre. Toutefois, si vous aviez un environnement dans lequel 20 % des utilisateurs génèrent une charge utilisateur légère et 80 % une charge de travail lourde, l’utilisation d’une charge de travail lourde vous donnerait la meilleure approximation.

L’idéal est d’effectuer des tests d’évolutivité à l’aide de votre propre charge de travail, plutôt que de vous fier aux chiffres d’évolutivité dérivés de nos tests. L’une des fonctionnalités utiles de Login Enterprise est que vous pouvez facilement créer vos propres charges de travail personnalisées ou créer une charge de travail à partir des flux de travail d’application fournis prêts à l’emploi. Pour ce test, nous voulions sélectionner une charge de travail représentative de la plupart des utilisateurs et fournir des données pertinentes à des fins de comparaison, tout en fournissant des estimations prudentes pour les entreprises qui n’effectuent pas de tests d’évolutivité sur leurs propres charges de travail.

Un autre facteur à prendre en compte est le ratio utilisateurs/processeurs virtuels sur une instance. Ce ratio est exprimé en fonction du nombre d’utilisateurs attendus par rapport au nombre de processeurs virtuels présents sur la machine virtuelle. Par exemple, si nous attendons 2 utilisateurs pour chaque processeur virtuel, le ratio sera exprimé par 2:1. Étant donné que les charges de travail CVAD sont gourmandes en ressources processeur, le taux de survalidation est couramment utilisé pour l’estimation et nous le fournissons pour les types d’instances recommandés. Le nombre d’utilisateurs par processeur virtuel peut varier en fonction de la charge de travail, de l’architecture du processeur du processeur ou même de la quantité de mémoire disponible sur un hôte.

L’architecture du processeur a également un impact sur les résultats d’évolutivité, comme on peut s’y attendre avec les charges de travail gourmandes en ressources processeur. L’un des objectifs de cette étude était de déterminer quelles familles et formes d’instances de calcul sont les plus rentables sur Google Cloud. Toutes choses étant égales, les processeurs plus rapides fournissent généralement plus d’utilisateurs par instance que les processeurs plus lents, mais entraînent généralement un coût supplémentaire.

Le type et la taille du stockage utilisé pour le disque persistant sur la machine virtuelle peuvent avoir un impact sur l’évolutivité d’un serveur unique, car le disque local est utilisé pour échanger de la mémoire et stocker les profils utilisateur. Les disques plus rapides réduisent la latence du disque, ce qui entraîne des opérations de lecture/écriture plus rapides. Si un disque manque d’espace pour stocker les profils utilisateur ou si le temps de récupération de l’échange de mémoire est long, les performances globales de l’hôte se dégradent. L’utilisation du stockage SSD Premium pour les disques persistants sur Google Cloud devrait minimiser les goulots d’étranglement du stockage et garantir que nous testons le calcul du type d’instance et non du stockage. Pour évaluer le stockage, nous conservons le type d’instance statique et changeons le type de disque.

Un autre facteur est le taux de lancement des sessions. Si les sessions sont lancées rapidement (disons 1 session toutes les 10 secondes) par rapport à modérément (1 séance par minute), vous obtiendrez des résultats différents. Les tempêtes d’ouverture de session vont stresser un environnement et vous devez toujours prévoir de disposer d’une capacité suffisante pour prendre en charge vos périodes de pointe d’ouverture de session. Cependant, les tests d’évolutivité sont généralement effectués à un taux d’ouverture de session modéré d’une session toutes les 30 secondes ou 60 secondes en fonction de l’intensité de la charge de travail. Les intervalles plus longs fournissent une vue plus précise du nombre de sessions actives pouvant être prises en charge dans un état stable.

Environnement de test

Pour les tests d’évolutivité, les machines virtuelles de l’infrastructure ont été configurées comme suit :

  • Appliance virtuelle One Login Enterprise exécutant la version 4.5.11
  • Quatre lanceurs Login Enterprise s’exécutant sur des instances e2-standard-2 avec un intervalle de lancement de session d’une minute
  • Un Citrix Cloud Connector
  • Un contrôleur de domaine Active Directory agissant également en tant que serveur de profils et serveur DNS

Les charges de travail Citrix ont été exécutées sur une seule instance de centre de données Windows Server 2019 avec les logiciels configurés suivants :

  • Rôle Microsoft RDSH installé, y compris l’expérience utilisateur
  • VDA avec OS multisession Citrix Server 2103.0.0.29045
  • Microsoft Office 2019
  • Microsoft Defender avec paramètres par défaut
  • Dernières mises à jour Windows disponibles au moment des tests (septembre 2021)
  • Les paramètres prêts à l’emploi ont été utilisés sauf indication contraire

Types d’instances

Pour cette étude, nous avons d’abord sélectionné des familles de machines pour lesquelles nous attendions une utilisation optimale des ressources, notamment les suivantes :

  • N1 (Intel Skylake à usage général avec prise en charge du processeur graphique)
  • N2 (Intel Cascade Lake à usage général)
  • N2D (AMD à usage général)
  • C2 (charge de travail optimisée pour le calcul Intel Cascade Lake)
  • E2 (Intel Skylake à coût optimisé)

Remarque :

Les instances T2D de la série Tau de Google n’étaient pas disponibles au moment des tests, mais sur la base des résultats détaillés ici, nous avons de grandes attentes à leur égard.

Nous avons commencé par évaluer les versions à 8 processeurs virtuels des familles de machines sélectionnées et avons évalué les résultats afin de déterminer les meilleures performances. Nous sommes ensuite allés plus loin et avons évalué les versions à 4 processeurs virtuels et à 16 processeurs virtuels dans ces familles de machines. Des tests ont été effectués sur les types d’instances de machines virtuelles suivants :

  • n1-standard-8 (Skylake)
  • n1-highcpu-8 (Skylake)
  • n1-highmem-8 (Skylake)
  • n2-standard-8 (Cascade Lake)
  • c2-standard-4 (Cascade Lake)
  • c2-standard-8 (Cascade Lake)
  • c2-standard-16 (Cascade Lake)
  • e2-standard-8 (Skylake)
  • n2d-standard-4 (Rome)
  • n2d-standard-8 (Rome)
  • n2d-standard-16 (Rome)
  • n2d-standard-4 (Milan)
  • n2d-standard-8 (Milan)
  • n2d-standard-16 (Milan)

Nous avons appris très tôt que les versions à 2 processeurs virtuels des familles de machines ne sont pas bien adaptées à notre charge de travail de référence lourde. Pour cette raison, nos tests se sont concentrés sur les formes d’instance à 4 processeurs virtuels, 8 processeurs virtuels et 16 processeurs virtuels.

Les sessions utilisateur ont été simulées à l’aide de Login Enterprise sur chaque type d’instance dans différentes exécutions de test afin d’analyser l’évolutivité des différents types et formes d’instances de machines virtuelles.

Architecture du laboratoire

Toute l’infrastructure pour le courtage et l’administration de sessions a été fournie par le service Citrix Cloud Virtual Apps and Desktops. Un contrôleur de domaine Active Directory et Cloud Connector ont été installés dans un VPC, créant ainsi un emplacement de ressources sur Google Cloud. La figure ci-dessous décrit l’architecture de test.

Architecture du laboratoire

Remarque :

Les instances N2 et N2D n’étaient pas disponibles dans la région US-West2, elles ont donc été créées dans la région US-West1.

Login Charge de travail des travailleurs du savoir d’entreprise avec score d’expérience utilisateur final (EUX)

Cette version de Login Enterprise permet de créer un flux de travail d’utilisateur virtuel en une charge de travail commune pour les travailleurs du savoir Office 365. Travaillant en étroite collaboration avec Login VSI, ce test a également utilisé un système de notation expérimental appelé score EUX. Le score EUX est un moyen de quantifier la réactivité de l’expérience ou de la sensation d’un utilisateur au cours d’une session de bureau ou d’application. Le flux de travail de cet utilisateur inclut les applications suivantes :

  • Connexion Demande de score VSI EUX
  • Microsoft Outlook
  • Microsoft Word
  • Microsoft Excel
  • Microsoft PowerPoint
  • Microsoft Edge
  • Youtube

Login Enterprise Knowledge Worker est une charge de travail lourde, gourmande en ressources processeur lorsqu’elle est utilisée à 100 % de simultanéité, et autorisée pour environ 2 utilisateurs par processeur virtuel en moyenne sur les instances cloud testées.

Plusieurs fois au cours de la session, l’application de notation EUX exécute un ensemble d’instructions et enregistre le temps nécessaire pour exécuter chaque étape. Les résultats peuvent ensuite être utilisés pour générer le score EUX d’une session. Les personnes familiarisées avec l’ancienne application Login VSI trouveront ces opérations familières.

Le score maximum théorique de l’EUX est de 10, cependant, le score est plus utile par rapport à lui-même sur différentes charges de travail. Par exemple, si nous regardons la même charge utilisateur sur un c2-standard-8 avec un score moyen EUX de 7,59, nous voyons ce graphique où la ligne continue représente l’instance n2d-standard-8 et la ligne pointillée représente l’instance c2-standard-8. Le graphique montre clairement l’instance n2d-standard-8, avec un score EUX moyen de 8,07, surpassant l’instance c2-standard-8 tout au long du test. Vous pouvez également voir comment le score baisse légèrement lorsque le système est occupé.

Ligne de tendance du score EUX

Le score EUX moyen, bien qu’il ne soit pas une représentation parfaite de l’ensemble du test, fournit un indicateur de la façon dont une configuration particulière est susceptible de fonctionner dans les conditions de charge de travail. Le tableau ci-dessous indique les scores EUX pour différentes configurations de type de machine pour un seul utilisateur exécutant la charge de travail EUX.

  Processeurs virtuels Mémoire (Gio) Score EUX (utilisateur unique)
n2d-standard-4-Milan AMD 4 16 8.61
n2d-standard-8-Milan AMD 8 32 8.54
c2-standard-8-Cascade Lake 8 32 8.5
c2-standard-16-Cascade Lake 16 64 8.4
n2d-standard-16-Milan AMD 16 64 8.35
c2-standard-4-Cascade Lake 4 16 8.13
n1-highmem-8-Skylake 8 42 7.75
n1-standard-8-Skylake 8 30 7.7
n2d-standard-8-Rome AMD 8 32 7.7
n2d-standard-16-Rome AM 16 64 7.7
n1-highcpu-8-Skylake 8 7.2 7.56
n2-standard-8-Cascade Lake 8 32 7.56
e2-standard-8-Broadwell 8 32 7.45
n2d-standard-4-Rome AMD 4 16 7.29

Lorsqu’il est utilisé seul pour un seul utilisateur, le score EUX fournit un indicateur relativement bon du potentiel de performance maximal de la machine virtuelle pour la charge de travail de test. Malheureusement, le score EUX ne fournit pas suffisamment de données pour déterminer le nombre d’utilisateurs qu’un type d’instance particulier peut prendre en charge. Pour cela, nous devons mesurer et évaluer des critères supplémentaires tels que l’utilisation du processeur et les nouveaux compteurs de performance Windows User Input Delay.

Méthode de notation

L’analyse des résultats de test sur n’importe quel système est toujours un défi et nécessite une analyse de plusieurs composants du système. Comme nous utilisons le même test sur chaque hôte, les résultats des tests sont suffisamment cohérents pour permettre la comparaison entre les configurations d’instance. Pour obtenir une estimation du nombre d’utilisateurs qu’un type d’instance particulier prendrait en charge, nous avons également mesuré deux compteurs de performances clés : l’utilisation du processeur et le délai d’entrée utilisateur.

Utilisation du processeur : ce compteur (Processor (_Total) % Processor Time) mesure le pourcentage de temps écoulé pendant lequel tous les processeurs virtuels du processeur sont occupés à exécuter des tâches de thread non inactives. L’utilisation du processeur a toujours été l’un des meilleurs indicateurs de l’expérience utilisateur, car lorsque l’utilisation du processeur approche de sa pleine charge, l’expérience utilisateur se dégrade rapidement.

Pour cette analyse, une moyenne mobile d’une minute a été calculée sur la base du temps processeur total. Nous avons examiné le nombre d’utilisateurs sur le système lorsque la moyenne mobile atteignait 85 %, puis 90 %.

Délai d’entrée utilisateur : Ce compteur (User Input Delay per Session (Max) \ Max Input Delay) mesure le temps nécessaire pour que les entrées utilisateur, telles qu’une souris ou un clavier, soient retirées de la file d’attente et traitées. Ce compteur est une bonne indication de l’expérience utilisateur car le retard est quelque chose que l’utilisateur remarquera lorsqu’il atteindra plus d’une seconde.

Pour cette analyse, une moyenne mobile d’une minute a été calculée sur la base du délai maximal subi par l’utilisateur sur l’hôte de la session. Par exemple, si 3 utilisateurs étaient sur le système et que les trois ont subi des retards d’utilisation, l’utilisateur avec le délai d’entrée le plus élevé serait celui sélectionné pour la moyenne mobile. Nous avons examiné le nombre d’utilisateurs sur le système lorsque la moyenne mobile de la pire expérience atteignait un délai de 1 seconde (1 000 ms) et de nouveau lorsqu’il atteignait un délai de 2 secondes (2 000 ms). N’oubliez pas que tous les utilisateurs ne subiront pas ce type de retard, mais qu’un seul utilisateur suffit à justifier un appel au service d’assistance lorsqu’un délai de 2 secondes est courant pour tous les mouvements de la souris et du clavier.

Ces deux plages nous ont fourni des points de données sur le nombre d’utilisateurs qu’un type d’instance pouvait prendre en charge.

Nombre minimum d’utilisateurs : calculé en comparant le nombre d’utilisateurs à 85 % d’utilisation de l’UC et le délai d’entrée utilisateur de 1 seconde et en sélectionnant le nombre le plus faible. Nombre maximum d’utilisateurs : calculé en comparant le nombre d’utilisateurs à 90 % d’utilisation de l’UC et le délai d’entrée utilisateur de 2 secondes et en sélectionnant le nombre le plus faible.

Utilisateurs attendus

Avant de déterminer les coûts prévus, nous devions d’abord déterminer le nombre d’utilisateurs qui s’exécutent correctement sur un type d’instance. Cela s’est avéré un peu plus difficile que prévu à l’origine, car le système de notation EUX ne nous indiquait pas le nombre total d’utilisateurs pouvant intégrer le système avant que les performances ne se dégradent à un niveau inacceptable, mais plutôt l’expérience en général de tous les utilisateurs du système.

En utilisant la combinaison des compteurs d’utilisation du processeur et de délai d’entrée utilisateur décrits ci-dessus, nous avons pu identifier la plage d’utilisateurs attendus sur un type d’instance particulier. Certes, le choix des limites métriques (85-90 % CPU et délais d’entrée de 1 à 2 secondes) semble un peu arbitraire, mais pour nos besoins, il fournit un point de référence à utiliser en combinaison avec le score EUX. Finalement, nous avons décidé d’utiliser le chiffre le plus prudent pour les utilisateurs attendus en utilisant le calcul suivant :

Utilisateurs attendus : Calculé en prenant la valeur minimale de chacun des éléments suivants pour un test réussi avec 99 % ou plus :

  1. Utilisateurs se connectant pendant le test
  2. Utilisateurs connectés lorsque la moyenne mobile UID maximale sur 1 minute était supérieure à 1 seconde
  3. Utilisateurs connectés lorsque la moyenne mobile UID maximale sur 1 minute était supérieure à 2 secondes
  4. Utilisateurs connectés lorsque la moyenne mobile sur 1 minute du processeur était supérieure à 85 %
  5. Utilisateurs connectés lorsque la moyenne mobile sur 1 minute du processeur était supérieure à 90 %

Coûts attendus

Les graphiques ci-dessous indiquent le coût par utilisateur et par heure pour chacune des instances à 8 processeurs virtuels testées dans le cadre de cette étude. Tous les hôtes sont tarifés avec un disque de performance de 100 Go et les coûts de licence Windows applicables sont inclus dans le total.

Comparaison des familles de 8 processeurs virtuels

Comme vous pouvez le voir d’après les données, les configurations de famille de machines les plus rentables pour cette charge de travail sont les normes C2 (Cascade Lake), n2d standard (Rome) et n2d standard (Milan). Nous avons pu atteindre un coût total de calcul et de stockage de 0,028$ par heure et par utilisateur avec la configuration n2d-standard-8 (Milan) en utilisant les coûts des machines pour la région US-Central1 au 1er novembre 2021.

Recommandations de calcul

Comme mentionné précédemment, lorsque nous discutons des ratios utilisateur/processeur virtuel, voici les résultats de nos principaux concurrents lors de nos tests :

Nombre d'utilisateurs attendus par processeur virtuel

Comme vous pouvez le voir sur le graphique, les instances à 4 processeurs virtuels et à 8 processeurs virtuels sont capables d’atteindre et de dépasser l’objectif de 2 utilisateurs par processeur virtuel, le n2d-standard-8 Milan étant en tête du peloton. Un point important à retenir ici est que les instances de 16 processeurs virtuels ont moins d’utilisateurs par processeur virtuel que prévu. Cela nous a surpris autant que cela vous surprend en ce moment, puisque normalement ces instances plus grandes ont de meilleurs numéros d’échelle que celui-ci. Cependant, pour cette charge de travail sur ces types d’instances, nous allons nous en tenir à recommander les instances à 4 ou 8 processeurs virtuels qui obtiennent au moins 2 utilisateurs par type d’instance.

D’une manière générale, les processeurs de dernière génération devraient offrir la meilleure évolutivité sur une charge de travail gourmande en ressources processeur, telle que le Knowledge Worker que nous avons utilisé pour cette étude. Les types qui comptent le plus grand nombre d’utilisateurs par processeur virtuel comprennent deux générations de puces AMD EPYC (Rome et Milan) et uniquement le dernier processeur Intel (Cascade Lake), car nous avons choisi d’inclure uniquement les 3 types les plus performants.

Il s’est avéré que nous avons pu fournir des chiffres comparatifs entre les générations de processeurs lorsque les types d’instances offraient le choix entre les deux types de processeurs. Malheureusement, cela signifie que nous n’avons pas pu comparer les processeurs Cascade Lake exécutés dans des instances N2 ou C2 directement avec les générations précédentes s’exécutant dans des instances N1. Cependant, nous avons pu comparer les processeurs Broadwell et Skylake d’Intel ainsi que les processeurs EPYC Rome et Milan d’AMD. Le tableau ci-dessous montre cette comparaison de processeurs.

Comparaison des processeurs

Comme le montre le graphique, la tendance générale est que les dernières générations offrent les meilleures performances. L’un des avantages de Google Cloud est que vous pouvez choisir la génération de votre processeur pour les types de machines N1 et N2D et que les coûts restent les mêmes quel que soit le processeur sélectionné. Par conséquent, à moins que vous n’ayez besoin d’un processeur de génération antérieure, veillez à définir la génération de processeur vCPU sur la dernière génération.

Bien que les processeurs Cascade Lake soient la dernière génération d’Intel et qu’ils soient susceptibles d’être les plus performants étant donné que le test est gourmand en ressources processeur, vous ne voudrez peut-être pas toujours opter pour la dernière génération. Bien que cela ne soit pas indiqué sur ce graphique, une constatation étrange est que le processeur Broadwell a parfois surpassé les nouveaux processeurs Skylake sur le n1-standard-8. Nous pensons que cela est possible pour les applications aux graphismes intensifs, car les processeurs Broadwell prennent en charge la mémoire à quatre canaux alors que les processeurs Skylake ne prennent en charge que la mémoire bicanale.

Il y a également des facteurs non liés à la performance à prendre en compte. Outre les performances d’un processeur sur votre charge de travail, les éléments suivants doivent également être pris en compte lors du choix des familles de machines et de la configuration :

GPU virtuel : Si votre charge de travail nécessite un GPU, la seule famille de machines testée prenant en charge un GPU est la famille N1.

Disponibilité : Toutes les générations de processeurs ou même les familles de machines ne sont pas disponibles dans chaque région. Examinez les régions dans lesquelles vous souhaitez déployer et déterminez les options de calcul dont vous disposez avant de choisir une configuration de machine virtuelle particulière.

Coût : Les coûts varient selon les régions. Pour ce document, nous utilisons la région US-Central1 pour toutes les informations sur les coûts, car elle présente généralement les coûts les plus bas et possède tous les types de machines disponibles. Dans certains cas, les remises sur engagement d’utilisation peuvent également ne pas être disponibles dans certaines régions.

Considérations en matière

Google Cloud propose différents types de stockage en mode bloc à utiliser pour les disques persistants sur les instances de calcul, chacun avec un ensemble de critères de performance pour les besoins des applications. Au cours de cette étude, nous avons testé les trois types les plus largement disponibles : Standard, Balanced et SSD.

|Coûts réduits|<——>|Performances supérieures| |—|—|—| |Standard|équilibré|SSD| Big Comput/Big Data, analyse des journaux, disques froids|La plupart des applications d’entreprise, des bases de données simples, des applications métier à l’état stable, des disques de démarrage|Dans la plupart des bases cache persistant, analyses scale-out| |1 200 IOPS, débit de 2 000 Mio/s | 80 000 IOPS, débit de 1 200 Mio /s|100 000 IOPS, débit de 1 200 Mio/s | |0,04 $ par Gio|0,10 $ par Gio|0,17 $ par Gio|

Nous avons effectué un certain nombre de tests sur différentes familles de machines à 8 processeurs virtuels, C2, N2D et N1, au cours desquelles nous avons varié les types de disques tout en maintenant la puissance de calcul constante. Ces tests nous ont permis d’effectuer une comparaison rapide entre les disques standard, équilibrés et SSD. Les résultats sont présentés dans le tableau ci-dessous.

Comparaison des types de disques

L’une des choses les plus intéressantes qui ressort de ce graphique est que plus le processeur virtuel est rapide, moins le type de disque risque d’avoir un impact sur le nombre attendu d’utilisateurs. Par exemple, les familles de machines C2 et N2D n’ont eu que très peu d’impact suite au changement de type de disque, mais la famille N1 a connu une différence significative (près de 33 % d’augmentation) en termes d’évolutivité. Cependant, gardez à l’esprit que le coût d’un disque standard est inférieur de moitié à celui d’un disque équilibré et inférieur au quart du coût d’un disque SSD. Par conséquent, si les performances sont les mêmes, des coûts de stockage inférieurs peuvent être rentables à long terme.

Les données issues de nos tests de charge de travail spécifiques montrent que si le coût est la principale préoccupation lorsque vous passez à GCP, l’utilisation de disques moins chers n’affectera pas de manière significative les performances des dernières générations de processeurs. Toutefois, les résultats liés à votre charge de travail peuvent varier. Nous vous recommandons donc vivement de tester votre charge de travail avant de vous engager dans une architecture particulière.

Utilisation du score EUX

Bien que cet article n’ait pas pleinement utilisé l’algorithme de notation EUX, nous avons constaté qu’il présentait une forte corrélation avec les compteurs de performance que nous avons analysés. Nous avons fini par utiliser les trois points de données (score EUX, utilisation du processeur et délai d’entrée utilisateur) pour calculer le nombre d’utilisateurs attendus. Le graphique ci-dessous fournit une vue de la façon dont les scores EUX varient entre un seul utilisateur sur le système et le score EUX à notre charge d’utilisateurs attendue.

Comparaison des scores EUX

Comme vous pouvez le voir, à la seule exception du Broadwell E2 Standard-8 qui est arrivé à 6,93, tous les scores de l’EUX sont supérieurs à 7,0. Nous avons effectué plus de 300 essais au cours de cette analyse et, dans tous les essais où le score EUX était inférieur à 7,0, nous avons pu immédiatement identifier la cause de la baisse du score EUX. Le plus souvent, l’utilisation du processeur était supérieure à 90 % ou le délai maximal d’entrée utilisateur dépassait 2 secondes.

Nous irions plus loin en disant que même si un score EUX de 7,0 est le score le plus bas acceptable absolu, vous pouvez constater que les utilisateurs ne sont pas satisfaits à ce niveau non plus. Voici une bonne règle générale déduite de nos tests :

Le score EUX obtenu à partir d’un système chargé avec le nombre attendu d’utilisateurs doit être supérieur à 7,0 et le score EUS pour utilisateur unique moins un demi-point.

Guide d’évolutivité pour Google Cloud VMware Engine

À la date de publication, Citrix Engineering venait de terminer les tests requis pour que Google Cloud VMware Engine (GCVE) soit considéré comme une plate-forme officiellement prise en charge pour la virtualisation Citrix. Citrix n’avait effectué aucun test d’évolutivité formel pour GCVE. Cela dit, GCVE est un service géré par Google qui fournit des centres de données définis par logiciel (SDDC) optimisés par VMware sur la base de l’architecture Cloud Foundation (VCF) de VMware. Puisque VMware, ses clients et ses partenaires déploient Citrix sur des systèmes basés sur le VCF depuis de nombreuses années, il existe déjà une mine de connaissances disponibles en corrélation directe avec GCVE.

Par exemple : GCVE est actuellement disponible sur un type de nœud appelé ve1-standard-72. Ce type de nœud possède 36 cœurs physiques (72 cœurs hyperthreads) et 768 Go de RAM. Lors de l’estimation d’une charge de travail de bureau partagé hébergé sur Windows Server 2019 à l’aide du VDA avec OS de serveur et d’une configuration SDDC à 3 nœuds, vous aurez un total de 108 cœurs physiques disponibles ou 216 processeurs virtuels hyperthread. À titre de référence, nous constatons généralement l’évolutivité la plus efficace à l’aide d’un VDA avec OS de serveur Citrix avec une configuration à 4 processeurs virtuels (2 cœurs physiques) et suffisamment de mémoire pour prendre en charge la charge de travail de votre utilisateur. Après avoir réservé certaines ressources de calcul et de mémoire pour l’hôte VMware, nous nous attendons à ce que chaque nœud GCVE puisse héberger confortablement environ 17 instances de VDA Citrix avec chacune 4 vCPU et 36 Go de RAM.

Si vous connaissez la « règle des 5 et 10 » deNick Rintalan, qui fournit des conseils sur l’évolutivité d’un serveur unique pour les centres de données sur site, vous vous souviendrez de ses recommandations d’environ 10 utilisateurs de session CVAD par cœur physique. Comme les serveurs GCVE sont hyperthreads, une machine virtuelle à 4 processeurs virtuels utilise 2 cœurs physiques pour chaque hôte de session Citrix. L’application de la règle de 10 pour les hôtes de session CVAD signifie que nous pouvons attendre environ 20 utilisateurs par machine virtuelle avec une charge de travail légère. Pour une charge de travail importante, ce nombre est d’environ la moitié ou d’environ 10 utilisateurs par machine virtuelle.

Ces calculs sont utilisés pour identifier le nombre approximatif d’utilisateurs attendus au sein de votre cluster GCVE et changeront en fonction d’une charge de travail particulière. Nous vous recommandons vivement de tester votre propre charge de travail et de décider quelle configuration convient le mieux à votre charge de travail.

Conclusion

Les résultats de cette étude suggèrent ce qui suit :

Comme prévu, les performances d’un VDA Citrix ont tendance à être limitées par le processeur plutôt que par les performances du disque ou la bande passante réseau.

La meilleure expérience utilisateur final (telle que mesurée, compte tenu de la charge de travail de référence de nos travailleurs du savoir) a été fournie par les derniers processeurs disponibles sur Google Cloud au moment de la publication. Ils sont disponibles dans les familles d’instances N2, N2D et C2, et tirent parti des processeurs Cascade Lake d’Intel et Milan et Rome d’AMD.

Pour le profil Knowledge Worker, les trois types d’instances les plus rentables sont :

  • Le type d’instance N2D-Standard-8 (avec le processeur AMD Milan), atteignant 2,875 utilisateurs par processeur virtuel, était le plus rentable, avec des coûts aussi bas que 0,0280$ par heure utilisateur selon la tarification à l’utilisation publiée.
  • Le type d’instance N2D-Standard-8 (avec le processeur AMD Rome) a suivi avec 2,25 utilisateurs par processeur virtuel, pour un coût aussi bas que 0,036$ par heure.
  • Le type d’instance C2-Standard-8, (avec le processeur Intel Cascade Lake), a également atteint 2,25 utilisateurs par processeur avec un coût légèrement supérieur à 0,040$ par heure utilisateur.

Les processeurs les plus rapides constituent la meilleure plateforme pour les charges de travail des travailleurs du savoir. Les résultats montrent que le point idéal est la taille d’instance de 8 processeurs virtuels et de 4 processeurs virtuels, tandis que le passage à des tailles d’instance de 16 processeurs virtuels réduit considérablement le nombre d’utilisateurs auxquels vous pouvez vous attendre par processeur virtuel.

Avec les derniers processeurs, le type de stockage utilisé pour les disques persistants n’a pas d’impact significatif sur l’évolutivité des instances. Bien que nous n’ayons trouvé aucune corrélation entre le type de performances du disque et le nombre d’utilisateurs attendus sur une machine virtuelle lorsque les types d’instances N2D et C2 étaient utilisés, nous avons constaté une différence de performance significative pour les instances N1.

Bien qu’elles ne soient pas explicitement testées dans le cadre de cette étude, les charges de travail qui nécessitent un GPU doivent être exécutées sur des types d’instances N1. Lorsque l’accélération GPU est une exigence, l’exploitation des processeurs Skylake et du stockage sur disque persistant SSD Premium permettra probablement d’obtenir les meilleures performances et la plus grande évolutivité.

Comme toujours, gardez à l’esprit qu’il s’agit d’un exemple de charge de travail qui est utilisé pour les tests et la validation et qu’il peut ne pas représenter votre charge de travail. Nous vous recommandons de tester vos charges de travail dans Google Cloud avant de vous engager dans une architecture spécifique. Vous pouvez utiliser l’outil Login Enterprise de Login VSI pour créer une charge de travail personnalisée qui approximera les activités quotidiennes de votre utilisateur et fournira un score EUX qui vous aidera à évaluer son expérience. Enregistrez le score EUX avec un utilisateur unique sur le système, puis ajoutez les utilisateurs un par un jusqu’à ce que le score baisse de 0,5 afin de déterminer les utilisateurs recommandés sur un système.

Merci tout particulièrement à l’équipe Login VSI qui a travaillé en étroite collaboration avec nous lorsque nous avons utilisé leurs algorithmes de notation EUX en préversion pour évaluer Google Cloud.

Dimensionnement des instances de VDA sur Google Cloud Compute Engine