Le client a souhaité une VDI. Il était très intéressé par l'association SimpliVity + VDI Citrix Virtual Desktop. Pour tous les opérateurs, employés de bureaux dans les villes, etc. Il y a cinq mille utilisateurs rien que dans la première vague de migration, et c'est pourquoi ils ont insisté sur des tests de charge. La VDI peut commencer à ralentir, elle peut s'effondrer tranquillement - et ce n'est pas toujours dû à des problèmes de bande passante. Nous avons acheté un package de tests très puissant spécialement pour la VDI et avons chargé l'infrastructure jusqu'à ce qu'elle tombe en panne au niveau des disques et du processeur.
Ainsi, nous aurons besoin d'une bouteille en plastique, du logiciel LoginVSI pour des tests VDI avancés. Nous en avons une avec des licences pour 300 utilisateurs. Ensuite, nous avons pris le matériel HPE SimpliVity 380 dans une configuration adaptée à la tâche de densité maximale des utilisateurs sur un seul serveur, nous avons créé des machines virtuelles avec une bonne sur-souscription, installé leur logiciel de bureau sur Win10 et avons commencé à tester.
Allons-y !
Le système
Deux nœuds (serveurs) HPE SimpliVity 380 Gen10. Sur chacun :
- 2 x Intel Xeon Platinum 8170 26c 2.1GHz.
- Mémoire vive : 768 Go, 12 x 64 Go LRDIMMs DDR4 2666 MHz.
- Contrôleur de disque principal : HPE Smart Array P816i-a SR Gen10.
- Disques durs : 9 x 1.92 To SATA 6Gb/s SSD (en configuration RAID6 7+2, c'est-à-dire que c'est le modèle Medium en termes de HPE SimpliVity).
- Cartes réseau : 4 x 1Gb Eth (données des utilisateurs), 2 x 10Gb Eth (backend SimpliVity et vMotion).
- Cartes FPGA intégrées spéciales dans chaque nœud pour dé-duplication/compression.
Les nœuds sont interconnectés par un interconnect 10Gb Ethernet directement sans commutateur externe, qui est utilisé comme backend SimpliVity et pour le transfert de données des machines virtuelles via NFS. Les données des machines virtuelles dans le cluster sont toujours miroitées entre deux nœuds.
Les nœuds sont regroupés dans un cluster VMware vSphere sous la gestion de vCenter.
Pour effectuer les tests, un contrôleur de domaine et un courtier de connexions Citrix ont été déployés. Le contrôleur de domaine, le courtier et vCenter ont été placés dans un cluster séparé.
En tant qu'infrastructure de test, 300 bureaux virtuels ont été déployés dans la configuration Dedicated – Full Copy, c'est-à-dire que chaque bureau virtuel est une copie complète de l'image d'origine de la machine virtuelle et conserve toutes les modifications apportées par les utilisateurs.
Chaque machine virtuelle dispose de 2vCPU et 4 Go de RAM :
Le logiciel suivant a été installé sur les machines virtuelles, requis pour effectuer les tests :
- Windows 10 (64 bits), version 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Entre les nœuds, il y a une réplication synchrone. Chaque bloc de données dans le cluster a deux copies. Cela signifie qu'un ensemble complet de données est actuellement présent sur chaque nœud. Dans un cluster de trois nœuds ou plus, les copies des blocs sont situées à deux endroits différents. Lors de la création d'une nouvelle VM, une copie supplémentaire est créée sur un des nœuds du cluster. Si un nœud tombe en panne, toutes les VM qui y étaient en cours d'exécution redémarrent automatiquement sur les autres nœuds où elles ont des répliques. Si un nœud reste hors service trop longtemps, une restauration progressive de la redondance commence, et le cluster revient à une configuration de sauvegarde N+1.
La répartition et le stockage des données se font au niveau du stockage logiciel de SimpliVity.
Les machines virtuelles lancent un cluster de virtualisation, qui les positionne sur le stockage logiciel. Les postes de travail eux-mêmes étaient basés sur un modèle standard : le test a inclus des postes de travail pour les financiers et les opérateurs (ce sont deux modèles différents).
Test
Pour effectuer les tests, un complexe de logiciels de test LoginVSI 4.1 a été utilisé. Le complexe LoginVSI, composé d'un serveur de gestion et de 12 machines pour les connexions de test, a été déployé sur un hôte physique distinct.
Les tests ont été effectués en trois modes :
Mode Benchmark — variantes de charge de 300 Knowledge workers et 300 Storage workers.
Mode standard — variante de charge de 300 Power workers.
Pour permettre le fonctionnement des Power workers et accroître la diversité de la charge, une bibliothèque de fichiers supplémentaires a été ajoutée au complexe LoginVSI. Pour garantir la répétabilité des résultats, toutes les configurations du banc d'essai ont été laissées par défaut.
Les tests Knowledge et Power workers simulent la charge réelle des utilisateurs travaillant sur des stations de travail virtuelles.
Le test Storage workers a été spécialement créé pour tester les systèmes de stockage de données, il est éloigné des charges réelles et se concentre principalement sur le travail de l'utilisateur avec un grand nombre de fichiers de différentes tailles.
Au cours du testing, les utilisateurs accèdent aux stations de travail pendant 48 minutes, environ un utilisateur toutes les 10 secondes.
Résultats
Le principal résultat des tests LoginVSI est la métrique VSImax, qui est composée du temps mis pour effectuer différentes tâches initiées par les utilisateurs. Par exemple : le temps d'ouverture d'un fichier dans le bloc-notes, le temps de compression d'un fichier dans 7-Zip, etc.
Une description détaillée du calcul des mesures est disponible dans la documentation officielle sur .
Autrement dit, LoginVSI reproduit un modèle de charge typique, en simulant les actions d'un utilisateur dans une suite bureautique, en lisant des PDF, etc., et mesure divers délais. Il existe un niveau critique de délais « tout est lent, il est impossible de travailler » ; jusqu'à atteindre ce point, on considère que le maximum d'utilisateurs n'est pas atteint. Si le temps de réponse est de 1 000 ms plus rapide que cet état « tout est lent », on considère que le système fonctionne normalement et que l'on peut ajouter d'autres utilisateurs.
Voici les principales mesures :
Mesure
Actions effectuées
Détails des commandes.
Composants chargés
NSLD
Temps d'ouverture d'un fichier texte
de 1 500 Ko
Le bloc-notes est lancé et
ouvre un document aléatoire de 1 500 Ko, copié depuis le pool
de ressources
CPU et I/O
NFO
Temps d'ouverture de la boîte de dialogue dans le bloc-notes
Ouverture de fichier VSI-Notepad [Ctrl+O]
CPU, RAM et I/O
ZHC*
Temps de création d'un fichier Zip avec forte compression
Compression d'un fichier local aléatoire au format .pst de 5 Mo, copié depuis
le pool de ressources
ZLC*
Temps de création d'un fichier Zip avec faible compression
CPU et I/O
I/O
Calcul d'un grand tableau de données aléatoires
le pool de ressources
ZLC*
Temps de création d'un fichier Zip avec faible compression
Création d'un grand tableau de données aléatoires, utilisé dans le minuteur I/O
CPU
Lors des tests, la métrique de base VSIbase est d'abord calculée, montrant la vitesse d'exécution des tâches sans charge sur le système. À partir de celle-ci, le seuil VSImax est déterminé, égal à VSIbase + 1 000 ms.
Les conclusions sur la performance du système sont basées sur deux mesures : VSIbase, qui définit la vitesse de fonctionnement du système, et le seuil VSImax, qui définit le maximum d'utilisateurs que le système pourra supporter sans dégradation significative.
300 Benchmark de travailleurs du savoir
Les travailleurs du savoir sont des utilisateurs qui chargent régulièrement la mémoire, le processeur et l'I/O avec diverses petites pointes. Le logiciel simule la charge d'utilisateurs de bureau exigeants, comme s'ils cliquaient constamment sur quelque chose (PDF, Java, suite bureautique, visualisation de photos, 7-Zip). À mesure que des utilisateurs sont ajoutés de zéro à 300, le délai de chacun augmente progressivement.
CPU
Données statistiques de VSImax :
VSIbase = 986 ms, le seuil VSI n'a pas été atteint.
Statistiques de charge sur le système de stockage issues de la surveillance SimpliVity :
Les travailleurs du savoir sont des utilisateurs qui chargent régulièrement la mémoire, le processeur et l'I/O avec différents pics mineurs. Le logiciel émule la charge des utilisateurs de bureau exigeants, comme s'ils cliquaient constamment sur quelque chose (PDF, Java, suite bureautique, visionnage de photos, 7-Zip). À mesure que le nombre d'utilisateurs augmente de zéro à 300, les délais de chacun augmentent progressivement.
Données statistiques VSImax :
VSIbase = 986 ms, le seuil VSI n'a pas été atteint.
Statistiques de charge sur le système de stockage issues du monitoring SimpliVity :
Avec ce type de charge, le système supporte une augmentation de la charge pratiquement sans dégradation des performances. Le temps d'exécution des tâches des utilisateurs augmente progressivement, le temps de réponse du système ne change pas pendant le test et est de jusqu'à 3 ms pour l'écriture et jusqu'à 1 ms pour la lecture.
Conclusion : 300 utilisateurs knowledge fonctionnent sans aucun problème sur le cluster actuel et ne se gênent pas mutuellement, atteignant un ratio de souscription pCPU/vCPU de 1 à 6. Les délais globaux augmentent régulièrement avec l'augmentation de la charge, mais le seuil conditionné n'a pas été atteint.
Banc d'essai de 300 Storage workers
Ce sont des utilisateurs qui écrivent et lisent constamment dans un ratio de 30 à 70 respectivement. Ce test a été effectué plutôt à titre expérimental. Données statistiques VSImax :
VSIbase = 1673, seuil VSI atteint à 240 utilisateurs.
Statistiques de charge sur le système de stockage issues du monitoring SimpliVity :
Ce type de charge est essentiellement un test de stress du système de stockage. Lors de son exécution, chaque utilisateur écrit sur le disque de nombreux fichiers aléatoires de différentes tailles. Dans ce cas, il est visible qu'en dépassant un certain seuil de charge, le temps d'exécution des tâches d'écriture de fichiers augmente pour une partie des utilisateurs. Cependant, la charge sur le système de stockage, le processeur et la mémoire des hôtes ne change pas de manière significative, il est donc impossible de déterminer précisément la cause des délais pour le moment.
Les conclusions sur la performance du système avec ce test ne peuvent être faites qu'en comparaison avec les résultats de tests sur d'autres systèmes, car de telles charges sont synthétiques, irréalistes. Néanmoins, globalement, le test s'est bien déroulé. Jusqu'à 210 sessions, tout se passait bien, puis des réponses incompréhensibles ont commencé, qui, par ailleurs, n'ont été suivies nulle part, sauf dans Login VSI.
300 Power workers
Ce sont des utilisateurs qui aiment le processeur, la mémoire et les IO élevés. Ces « utilisateurs avancés » effectuent régulièrement des tâches complexes avec de longs pics comme l'installation de nouveaux logiciels et l'extraction de gros fichiers compressés. Données statistiques VSImax :
VSIbase = 970, seuil VSI non atteint.
Statistiques de charge sur le système de stockage issues du monitoring SimpliVity :
Lors du test, un seuil de charge des processeurs a été atteint sur l'un des nœuds du système, mais cela n'a pas eu d'impact significatif sur son fonctionnement :
Dans ce cas, le système supporte une augmentation de la charge sans dégradation significative des performances. Le temps d'exécution des tâches des utilisateurs augmente progressivement, le temps de réponse du système reste constant pendant les tests et s'élève à 3 ms pour les écritures et à 1 ms pour les lectures.
Les tests ordinaires n'étaient pas suffisants pour le client, nous avons donc poussé plus loin : nous avons amélioré les caractéristiques de la VM (nombre de vCPU pour évaluer l'augmentation de la surallocation et taille du disque) et ajouté une charge supplémentaire.
Pour les tests supplémentaires, la configuration suivante a été utilisée :
300 bureaux virtuels déployés avec une configuration de 4 vCPU, 4 Go de RAM, 80 Go de HDD.
Configuration de l'une des machines de test :
Les machines sont déployées en option Dedicated – Full Copy :
300 benchmarks de Knowledge workers avec une surallocation de 12
Données statistiques VSImax :
VSIbase = 921 ms, le seuil VSI n'a pas été atteint.
Statistiques de charge sur le système de stockage issues du monitoring SimpliVity :
Les résultats obtenus sont similaires à ceux du test de la précédente configuration de la VM.
300 benchmarks de Power workers avec une surallocation de 12
Données statistiques VSImax :
VSIbase = 933, le seuil VSI n'a pas été atteint.
Statistiques de charge sur le système de stockage issues du monitoring SimpliVity :
Lors de ce test, le seuil de charge des processeurs a également été atteint, mais cela n'a pas eu d'impact significatif sur les performances :
Les résultats obtenus sont similaires à ceux du test de la configuration précédente.
Que se passera-t-il si nous appliquons une charge pendant 10 heures ?
Nous allons maintenant vérifier s'il y aura un « effet d'accumulation » et lancer des tests pendant 10 heures d'affilée.
Les tests prolongés et la description de la section doivent viser à vérifier si des problèmes surgiront avec la ferme sous une pression prolongée.
300 benchmarks de Knowledge workers + 10 heures
Un test supplémentaire a été réalisé avec une charge de 300 knowledge workers, suivie d'une activité des utilisateurs pendant 10 heures.
Données statistiques VSImax :
VSIbase = 919 ms, le seuil VSI n'a pas été atteint.
Données statistiques VSImax détaillées :
Le graphique montre qu'aucune dégradation des performances n'est observée pendant tout le test.
Statistiques de charge sur le système de stockage issues du monitoring SimpliVity :
Les performances du système de stockage restent constantes tout au long du test.
Tests supplémentaires avec ajout de charge synthétique.
Le client a demandé d'ajouter une charge de travail importante sur le disque. Pour cela, une tâche a été ajoutée à chaque machine virtuelle des utilisateurs pour exécuter une charge synthétique sur le disque lors de la connexion de l'utilisateur au système. La charge était assurée par l'outil fio, qui permet de limiter la charge sur le disque en fonction du nombre d'IOPS. Sur chaque machine, une tâche a été lancée pour ajouter une charge supplémentaire de 22 IOPS avec un ratio de 70 % / 30 % pour la lecture/écriture aléatoire.
300 benchmarks de travailleurs du savoir + 22 IOPS par utilisateur
Lors des tests initiaux, il a été constaté que fio générait une charge supplémentaire significative sur le processeur des machines virtuelles. Cela a entraîné une surcharge rapide des hôtes en CPU et a fortement impacté le fonctionnement global du système.
Charge sur le CPU des hôtes :
Les latences du système de stockage ont également logiquement augmenté :
Le manque de puissance de calcul est devenu critique à environ 240 utilisateurs :
Suite aux résultats obtenus, il a été décidé de procéder à des tests moins exigeants pour le CPU.
230 benchmarks de travailleurs de bureau + 22 IOPS par utilisateur
Pour réduire la charge sur le CPU, le type de charge des travailleurs de bureau a été choisi, et 22 IOPS de charge synthétique ont également été ajoutés à chaque session.
Le test a été limité à 230 sessions afin de ne pas dépasser la charge maximale sur le CPU.
Le test a été lancé avec le travail continu des utilisateurs pendant 10 heures pour vérifier la stabilité du système lors d'une utilisation prolongée sous une charge proche du maximum.
Données statistiques VSImax :
VSIbase = 918 ms, aucun seuil VSI n’a été atteint.
Données statistiques VSImax détaillées :
Le graphique montre qu'aucune dégradation des performances n'est observée pendant tout le test.
Données statistiques sur la charge du CPU :
Lors de l'exécution de ce test, la charge sur le CPU des hôtes était presque à son maximum.
Statistiques de charge sur le système de stockage issues du monitoring SimpliVity :
Les performances du système de stockage restent constantes tout au long du test.
La charge sur le système de stockage pendant le test était d'environ 6 500 IOPS avec un rapport de 60 / 40 (3 900 IOPS pour la lecture, 2 600 IOPS pour l'écriture), ce qui représente environ 28 IOPS par station de travail.
Le temps de réponse moyen était de 3 ms pour l'écriture et jusqu'à 1 ms pour la lecture.
Conclusion
En modélisant des charges réelles sur l'infrastructure HPE SimpliVity, des résultats ont été obtenus, confirmant la capacité du système à faire fonctionner au moins 300 machines Full Clone sur une paire de nœuds SimpliVity. Pendant ce temps, le temps de réponse du système de stockage est resté à un niveau optimal tout au long des tests.
Nous apprécions beaucoup l'approche consistant à réaliser des tests prolongés et à comparer les solutions avant leur mise en œuvre. Nous pouvons tester les performances également pour vos charges de travail, si vous le souhaitez. Cela inclut d'autres solutions hyperconvergentes. Le client mentionné termine actuellement des tests sur une autre solution en parallèle. Son infrastructure actuelle est simplement un parc de PC, un domaine et un logiciel sur chaque poste de travail. Passer à un VDI sans tests est, bien sûr, assez difficile. Il est particulièrement compliqué de comprendre les réelles capacités d'une ferme VDI sans y avoir migré de véritables utilisateurs. Ces tests permettent d'évaluer rapidement les capacités réelles d'un système donné sans avoir besoin d'impliquer des utilisateurs ordinaires. C'est de là qu'est née cette étude.
Un autre aspect crucial est que le client a immédiatement prévu une bonne scalabilité. Il est possible d'acheter un serveur supplémentaire et d'ajouter par exemple une ferme de 100 utilisateurs, avec un coût par utilisateur prévisible. Par exemple, lorsqu'ils auront besoin d'ajouter 300 utilisateurs supplémentaires, ils sauront qu'ils auront besoin de deux serveurs dans une configuration déjà définie, et non de réviser les possibilités de modernisation de leur infrastructure dans son ensemble.
Les possibilités de fédération d'HPE SimpliVity sont intéressantes. L'entreprise est géographiquement divisée, il est donc logique d'installer un matériel VDI distinct dans un bureau éloigné. Dans la fédération SimpliVity, chaque machine virtuelle est répliquée selon un calendrier avec la possibilité de le faire entre des clusters géographiquement distants très rapidement et sans charge sur le canal — c'est une sauvegarde intégrée de très haut niveau. Lors de la réplication de VM entre sites, le canal est utilisé de manière à rester au minimum, ce qui permet de concevoir des architectures DR très intéressantes avec un centre de gestion unique et de nombreux sites de stockage décentralisés.
Tout cela permet d'évaluer également très en détail le côté financier et de superposer les coûts du VDI aux plans de croissance de l'entreprise, tout en comprenant la rapidité avec laquelle la solution sera rentabilisée et comment elle fonctionnera. Car tout VDI est une solution qui, en fin de compte, fait économiser une multitude de ressources, mais qui, très probablement, ne donnera pas la possibilité économiquement avantageuse de le changer au cours des 5 à 7 années d'utilisation.
En gros, si vous avez des questions qui ne sont pas destinées aux commentaires, écrivez-moi à l'adresse mk@croc.ru.
Source : habr.com
