ra2 studio - Fotolia
Calculer le dimensionnement d’un environnement VDI Citrix en 6 étapes
Tous les environnements Citrix nécessitent une planification différente des ressources. Mais les administrateurs peuvent utiliser ces 6 étapes pour calculer et estimer le dimensionnement de leur environnement Citrix Virtual Apps and Desktops.
Le dimensionnement correct d’un environnement Citrix Virtual Apps and Desktops (CVAD) est l’une des étapes les plus critiques de son déploiement.
En tant qu’administrateur de postes de travail virtuels Citrix, vous voulez vous assurer que tous les utilisateurs bénéficient de la meilleure expérience utilisateur possible dans les limites de votre budget. Mais il existe de nombreux facteurs qui peuvent influencer le dimensionnement d’un environnement.
Pour commencer par quelques avertissements, chaque environnement est unique, et ce qui fonctionne pour un environnement ne fonctionnera pas avec un autre environnement. Si vous voulez être précis dans le dimensionnement de votre environnement, il n’y a qu’une seule façon de le faire : l’analyse comparative.
Des outils tels que Login VSI et LoadGen vous permettent de créer une charge de traitement synthétique et d’évaluer votre nouvel environnement. De cette façon, vous pouvez tester si le matériel peut supporter vos différents types d’utilisateurs finaux.
Le deuxième avertissement est que le dimensionnement n’est jamais terminé. Chaque mise à jour du système peut affecter les performances et modifier le dimensionnement nécessaire. Un cas de test de Go-EUC a montré qu’un exemple de migration de Windows Server 2019 vers Windows Server 2022 a un impact de 30 % sur la capacité CPU. Pour garantir une bonne expérience stable aux utilisateurs finaux, surveillez les performances avec des outils tels que ControlUp, Liquidware Stratusphere et Goliath.
Il est également essentiel de se projeter dans l’avenir avec la budgétisation et la planification globale de la capacité. Il est fréquent que les environnements de VDI fonctionnent correctement au début, mais que deux ans plus tard, ils commencent à ralentir. Si l’on ne prévoit pas de budgétiser à l’avance, il peut être difficile de justifier un financement alors qu’un investissement important est déjà en place.
La notion d’achat d’un nouveau matériel tous les trois à cinq ans, puis de son remplacement, n’est peut-être plus d’actualité : des fournisseurs comme Citrix et Microsoft travaillent avec des itérations de leurs produits tous les trois à six mois, ce qui affecte les performances des environnements VDI de manière continue.
En gardant tout cela à l’esprit, vous devriez établir un plan de dimensionnement pour un environnement VDI Citrix Virtual Apps and Desktops en tenant compte de ces six facteurs.
6 facteurs pour créer un plan de dimensionnement de Citrix Virtual Apps and Desktops
Un plan de dimensionnement solide vous permet de calculer la quantité de matériel dont votre environnement a besoin. Il convient de noter qu’avec les services cloud tels que Microsoft Azure, vous n’achetez pas de matériel, mais pouvez créer les serveurs directement dans Azure. En tant que tel, ce guide de dimensionnement est plus pertinent pour les déploiements VDI ou les approches hybrides de la virtualisation des postes de travail.
1. Utilisateurs finaux
La première chose que nous devons savoir pour un plan de dimensionnement, ce sont les utilisateurs finaux. Combien d’utilisateurs finaux seront connectés à l’environnement ? Il est essentiel d’examiner le nombre total d’utilisateurs dans l’environnement et le nombre d’utilisateurs simultanés pour déterminer le nombre maximum de connexions que l’environnement connaîtra par jour.
Ces chiffres peuvent varier considérablement d’un secteur à l’autre ; imaginez un hôpital dont le personnel infirmier travaille par roulement 24 heures sur 24. Ce cas d’utilisation peut avoir trois à quatre fois plus d’utilisateurs finaux au total que le nombre de connexions simultanées à l’environnement.
Le nombre d’utilisateurs requis peut également dicter le volume correct de stockage nécessaire pour tous les profils d’utilisateurs. Il vous permettra également de définir la charge maximale simultanée pour dimensionner correctement les vCPU et la RAM.
2. Charge de traitement bureautique
Si le nombre d’utilisateurs est essentiel, vous devrez comprendre ce que les utilisateurs finaux feront dans l’environnement. Cela peut être un peu difficile, car ce que votre entreprise pourrait considérer comme un utilisateur standard pourrait être un utilisateur lourd pour une autre entreprise.
Un type commun de travailleur est connu sous le nom d’employé de bureau standard. Ce type d’utilisateur travaille principalement avec Microsoft Office, navigue un peu sur Internet et utilise des applications professionnelles telles que les ERP.
Lorsque ce même utilisateur effectue des calculs importants au sein d’Office ou de l’ERP, par exemple en exportant une grande quantité de données de la suite ERP vers Excel et en travaillant ensuite avec ces données, on parle de travailleur de bureau lourd.
Un utilisateur qui n’a besoin que d’envoyer des courriels et de naviguer un peu sur Internet ou qui effectue une petite tâche dans une application de gestion peut être considéré comme un employé de bureau léger.
En général, les travailleurs légers sont rares, car la plupart des utilisateurs ont besoin d’au moins une application métier. Cependant, il peut arriver que vous deviez vous préparer à accueillir des employés qui utilisent rarement l’environnement. Ces travailleurs peuvent être considérés comme des employés de bureau légers.
3. Charge de traitement du GPU
Si un utilisateur a une quelconque charge de traitement susceptible de nécessiter un GPU, vous devez en tenir compte séparément. Vous devrez identifier les types de charges de traitement GPU qui seront nécessaires. La charge est-elle lourde, single threat ou multi-thread ? Les utilisateurs effectuent-ils des rendus, ou se contentent-ils d’éditer des images ?
Une grosse erreur que j’ai souvent vue en ce qui concerne les charges de traitement des GPU consiste à ajouter un gros GPU à un serveur de virtualisation ordinaire. Cela ne fonctionne pas avec une charge de traitement de conception assistée par ordinateur (CAO) ; de nombreux programmes de CAO sont fortement single-thread. Vous pouvez obtenir un meilleur gain de performances en vous assurant que vous avez des CPU avec fonctionnant à une fréquence d’au moins 3 GHz.
En gardant tout cela à l’esprit, nous pouvons établir trois profils pour la charge de traitement GPU. Tout d’abord, l’utilisateur de CAO par défaut utilise principalement la CAO pour afficher et modifier des dessins et ne produit pas de rendus 3D. Ces utilisateurs sont les travailleurs GPU de CAO.
Ensuite, nous avons les utilisateurs qui utilisent l’environnement pour éditer des images dans des applications telles qu’Adobe Photoshop ; ces utilisateurs n’ont pas non plus besoin d’une grande quantité de puissance GPU brute, et le logiciel est souvent mieux optimisé pour les traitements multithread. C’est ce que nous appellerons le travailleur GPU standard.
Enfin, nous avons un utilisateur qui a besoin d’une grande quantité de puissance GPU ; cet utilisateur peut avoir besoin de créer des rendus 3D avec la CAO ou d’éditer des vidéos et d’en faire le rendu. Ce sont les utilisateurs de GPU lourds. Et ces trois types de travailleurs nécessitent un matériel différent dans votre plan de dimensionnement.
4. Multisessions contre monosession
Lors du dimensionnement de votre environnement, l’utilisation d’un hébergement multisessions ou monosession est un élément à prendre en compte. L’avantage du VDI à session unique est que vous garantissez à chaque utilisateur une partie des performances. Avec l’hébergement multisession – Remote Desktop Session Host – vous partagez les ressources du serveur virtuel ; cela peut conduire à ce qu’un utilisateur consomme trop de ressources, entravant ainsi les performances des autres utilisateurs sur le serveur.
L’inconvénient d’une session unique est la quantité de matériel dont vous aurez besoin. Elle sera beaucoup plus élevée, ce qui signifie des coûts plus importants. D’une manière générale, il est judicieux d’utiliser l’hébergement multisessions pour autant de bureaux, de machines, d’applications et de services que possible afin de limiter les coûts de matériel.
Prenons l’exemple d’une charge de traitement Microsoft Office. Les charges légère et standard liées à cette suite peuvent fonctionner en multisession. Le mode multisession peut également convenir pour une charge de traitement GPU standard.
5. Cloud ou sur site
Il faut ensuite déterminer si vous allez utiliser un environnement cloud ou sur site. Vous devez garder à l’esprit que les fournisseurs de clouds publics ont du mal à fournir les vitesses de processeur requises pour les charges de traitement de CAO et de GPU lourdes. Un autre facteur clé à retenir est le nombre d’utilisateurs par serveur autorisé dans un environnement multisessions.
Dans un environnement cloud, vous utiliserez un serveur plus petit et moins d’utilisateurs par serveur que sur place. C’est lié à l’autoscaling : Citrix peut créer et supprimer des serveurs à la demande, et moins votre environnement a besoin de serveurs, moins il est cher.
Mais l’autoscaling ne peut pas supprimer un serveur si les utilisateurs travaillent toujours dessus. Prenons l’exemple d’un grand serveur Cloud où 20 personnes peuvent se connecter la nuit ; le serveur est presque vide, sauf pour un utilisateur qui travaille encore dessus. À ce moment-là, vous devez continuer à payer ce gros serveur pour un seul utilisateur.
Vous devriez instancier des serveurs plus petits et les dimensionner pour cinq à dix utilisateurs chacun. De cette façon, il y a plus de chances que le serveur puisse être supprimé plus tôt, ce qui permet de réduire les coûts d’exploitation.
Par exemple, vous pouvez créer six serveurs si vous avez 100 utilisateurs et que vous souhaitez les répartir sur place sur des serveurs multisessions. Avec six serveurs, vous avez une densité d’utilisateurs d’environ 16 par serveur ; même si un serveur connaît une panne, la densité passe à 20, ce qui est acceptable.
Pour 100 utilisateurs en cloud, vous devez prévoir 20 serveurs plus petits avec une densité maximale de cinq utilisateurs. L’utilisation d’un cloud public comme Microsoft Azure a un impact significatif sur votre plan de dimensionnement.
6. Overhead
Bien qu’il soit facile de le négliger, la surcharge – ou overhead – constitue un facteur essentiel à prendre en compte. Malgré les plans les mieux conçus, votre environnement évoluera au fil du temps et pourrait avoir besoin d’espace pour se développer.
De nouveaux utilisateurs pourraient être embarqués et la charge de traitement s’alourdira au fil du temps du simple fait des mises à jour.
N’oubliez pas non plus que vous devez travailler avec N+1, ce qui signifie que nous prenons les serveurs normalement requis plus un serveur juste en cas de panne ou de maintenance.
Calcul d’un exemple d’environnement Citrix
Vous devez maintenant affecter les ressources aux types de travailleurs. Ceci est, bien sûr, sujet à des changements et à votre environnement spécifique, mais le tableau suivant fournit un bon point de départ :
| Traitement | vCPU | vRAM | vGPU | Mono ou multisessions |
| Travailleur bureautique léger | 0.5 Cœur (2 -- 2,6 GHz) | 1 Go | -- | Multi |
| Travailleur bureautique standard | 0.8 Cœur (2 -- 2,6 GHz) | 2 Go | -- | Multi |
| Travailleur bureautique lourd | 4 Cœurs (2 -- 2,6 GHz) | 8 Go | -- | Mono |
| Travailleur CAD GPU | 4 Cœurs (3 -- 3,6 GHz) | 16 Go | A16 (T4) | Mono |
| Travailleur GPU standard | 4 Cœurs (2,6 -- 3 GHz) | 8 Go | A16 (T4) | Multi |
| Travailleur GPU lourd | 8 Cœurs (3 -- 3,6 GHz) | 32 Go | A40 | Mono |
Pour les profils, pensez à utiliser FSLogix pour calculer au moins 5 Go de stockage par utilisateur lorsque vous utilisez Exchange en ligne et 1 Go de stockage par utilisateur si vous n’utilisez pas Exchange en ligne.
Voici un exemple d’un tel calcul : si vous avez 40 employés de bureau standard, vous aurez besoin de 40 x 0,8 = 32 vCPU et 40 x 2 Go de RAM = 80 Go. Dans ce cas, il serait logique de créer 3 – n’oubliez pas de travailler avec N+1 – serveurs multisessions de 16 vCPU et 40 Go de RAM s’il s’agit d’un environnement sur site.
