Le client voulait du VDI. J'ai vraiment regardé la combinaison SimpliVity + VDI Citrix Virtual Desktop. Pour tous les opérateurs, employés de la mairie, etc. Rien que lors de la première vague de migration, il y a cinq mille utilisateurs et ils ont donc insisté sur les tests de charge. VDI peut commencer à ralentir, il peut s'allonger calmement - et cela n'arrive pas toujours en raison de problèmes avec la chaîne. Nous avons acheté un package de test très puissant spécifiquement pour le VDI et avons chargé l'infrastructure jusqu'à ce qu'elle devienne trop lourde sur les disques et le processeur.
Nous aurons donc besoin d’une bouteille en plastique et du logiciel LoginVSI pour des tests VDI sophistiqués. Nous l'avons avec des licences pour 300 utilisateurs. Ensuite, nous avons pris le matériel HPE SimpliVity 380 dans un package adapté à la tâche de densité maximale d'utilisateurs par serveur, découpé des machines virtuelles avec un bon surabonnement, installé des logiciels bureautiques sur Win10 et commencé les tests.
Allons-y!
Système
Deux nœuds HPE SimpliVity 380 Gen10 (serveurs). Sur chaque:
- 2 processeurs Intel Xeon Platinum 8170 26c 2.1 GHz.
- RAM : 768 Go, 12 x 64 Go LRDIMM DDR4 2666 MHz.
- Contrôleur de disque principal : HPE Smart Array P816i-a SR Gen10.
- Disques durs : 9 x SSD SATA 1.92 Gb/s de 6 To (en configuration RAID6 7+2, c'est à dire qu'il s'agit d'un modèle Medium en termes HPE SimpliVity).
- Cartes réseau : 4 x 1 Go Eth (données utilisateur), 2 x 10 Go Eth (backend SimpliVity et vMotion).
- Cartes FPGA spéciales intégrées dans chaque nœud pour la déduplication/compression.
Les nœuds sont connectés les uns aux autres via une interconnexion Ethernet 10 Go directement sans commutateur externe, qui est utilisé comme backend SimpliVity et pour transférer les données de la machine virtuelle via NFS. Les données de la machine virtuelle dans un cluster sont toujours mises en miroir entre deux nœuds.
Les nœuds sont combinés dans un cluster Vmware vSphere géré par vCenter.
Pour les tests, un contrôleur de domaine et un courtier de connexion Citrix ont été déployés. Le contrôleur de domaine, le courtier et vCenter sont placés sur un cluster distinct.
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 est une copie complète de l'image originale de la machine virtuelle et enregistre toutes les modifications apportées par les utilisateurs.
Chaque machine virtuelle dispose de 2 vCPU et de 4 Go de RAM :
Le logiciel suivant requis pour les tests a été installé sur les machines virtuelles :
- Windows 10 (64 bits), version 1809.
- Adobe Reader XII.
- Agent de livraison virtuelle Citrix 1811.1.
- Doro PDF 1.82.
- Java 7 mise à jour 13.
- Microsoft Office Professionnel Plus 2016.
Entre nœuds - réplication synchrone. Chaque bloc de données du cluster possède deux copies. Autrement dit, il existe désormais un ensemble complet de données sur chacun des nœuds. Avec un cluster de trois nœuds ou plus, les copies des blocs se trouvent à deux endroits différents. Lors de la création d'une nouvelle VM, une copie supplémentaire est créée sur l'un des nœuds du cluster. Lorsqu'un nœud tombe en panne, toutes les machines virtuelles qui y étaient précédemment exécutées sont automatiquement redémarrées sur les autres nœuds où elles disposent de réplicas. Si un nœud tombe en panne pendant une longue période, la restauration progressive de la redondance commence et le cluster revient à la redondance N+1.
L'équilibrage et le stockage des données se produisent au niveau du stockage logiciel de SimpliVity lui-même.
Les machines virtuelles exécutent un cluster de virtualisation, qui les place également sur le stockage logiciel. Les pupitres eux-mêmes ont été pris selon un gabarit standard : les pupitres des financiers et des opérationnels sont venus pour le test (ce sont deux gabarits différents).
Test
Pour les tests, la suite de tests logiciels LoginVSI 4.1 a été utilisée. Le complexe LoginVSI, composé d'un serveur de contrôle et de 12 machines pour tester les connexions, a été déployé sur un hôte physique distinct.
Les tests ont été effectués selon trois modes :
Mode benchmark - cas de charge 300 travailleurs du savoir et 300 travailleurs du stockage.
Mode standard - cas de charge 300 Power Workers.
Pour permettre aux travailleurs Power de travailler et d'augmenter la diversité de charge, une bibliothèque de fichiers Power Library supplémentaires a été ajoutée au complexe LoginVSI. Pour garantir la répétabilité des résultats, tous les paramètres du banc de test ont été laissés par défaut.
Les tests Knowledge et Power Workers simulent la charge de travail réelle des utilisateurs travaillant sur des postes de travail virtuels.
Le test Storage Workers a été créé spécifiquement pour tester les systèmes de stockage de données ; il est loin des charges de travail réelles et implique principalement que l'utilisateur travaille avec un grand nombre de fichiers de différentes tailles.
Pendant les tests, les utilisateurs se connectent aux postes de travail pendant 48 minutes à raison d'environ un utilisateur toutes les 10 secondes.
résultats
Le principal résultat des tests LoginVSI est la métrique VSImax, qui est compilée à partir du temps d'exécution de diverses tâches lancées par l'utilisateur. Par exemple : le temps d'ouvrir un fichier dans le Bloc-notes, le temps de compresser un fichier dans 7-Zip, etc.
Une description détaillée du calcul des métriques est disponible dans la documentation officielle de .
En d'autres termes, LoginVSI répète un modèle de chargement typique, simulant les actions des utilisateurs dans une suite bureautique, la lecture d'un PDF, etc., et mesure diverses latences. Il existe un niveau critique de délais « tout ralentit, il est impossible de travailler »), avant lequel on considère que le nombre maximum d'utilisateurs n'est pas atteint. Si le temps de réponse est 1 000 ms plus rapide que cet état « tout est lent », alors le système est considéré comme fonctionnant normalement et d'autres utilisateurs peuvent être ajoutés.
Voici les principales mesures :
Métrique
Les mesures prises
Détaillé description
Composants chargés
N.S.L.D.
Heure d'ouverture du texte
fichier pesant 1 500 Ko
Le Bloc-notes s'ouvre et
ouvre un document aléatoire de 1 500 Ko qui est copié à partir du pool
ресурсов
CPU et E/S
NFO
Heure d’ouverture du dialogue
fenêtres dans le bloc-notes
Ouvrir un fichier VSI-Notepad [Ctrl+O]
CPU, RAM et E/S
ZHC*
Il est temps de créer un fichier Zip hautement compressé
Compression locale
Fichier .pst aléatoire de 5 Mo copié à partir de
pool de ressources
CPU et E/S
ZLC*
Il est temps de créer un fichier Zip faiblement compressé
Compression locale
Fichier .pst aléatoire de 5 Mo copié à partir de
pool de ressources
I / O
Processeur
Calculer gros
tableau de données aléatoires
Création d'un grand tableau
données aléatoires qui seront utilisées dans le timer d'entrée/sortie (timer E/S)
Processeur
Lorsque les tests sont effectués, la métrique de base VSIbase est initialement calculée, ce qui indique la vitesse à laquelle les tâches sont exécutées sans charge sur le système. Sur cette base, le seuil VSImax est déterminé, qui est égal à VSIbase + 1 000 ms.
Les conclusions sur les performances du système sont basées sur deux métriques : VSIbase, qui détermine la vitesse du système, et le seuil VSImax, qui détermine le nombre maximum d'utilisateurs que le système peut gérer sans dégradation significative.
Référentiel de 300 travailleurs du savoir
Les travailleurs du savoir sont des utilisateurs qui chargent régulièrement de la mémoire, du processeur et des E/S avec divers petits pics. Le logiciel émule la charge de travail des utilisateurs de bureau exigeants, comme s'ils fouinaient constamment quelque chose (PDF, Java, suite bureautique, visualisation de photos, 7-Zip). À mesure que vous ajoutez des utilisateurs de zéro à 300, le délai pour chacun augmente progressivement.
Données statistiques VSImax :
VSIbase = 986 ms, le seuil VSI n'a pas été atteint.
Statistiques de charge du système de stockage issues de la surveillance SimpliVity :
Avec ce type de charge, le système peut supporter une charge accrue sans pratiquement aucune dégradation des performances. Le temps nécessaire pour effectuer les tâches utilisateur augmente progressivement, le temps de réponse du système ne change pas pendant les tests et peut aller jusqu'à 3 ms en écriture et jusqu'à 1 ms en lecture.
Conclusion: 300 utilisateurs de connaissances travaillent sans problème sur le cluster actuel et n'interfèrent pas les uns avec les autres, atteignant un surabonnement pCPU/vCPU de 1 à 6. Les délais globaux augmentent uniformément à mesure que la charge augmente, mais la limite stipulée n'a pas été atteinte.
Benchmark de 300 travailleurs du stockage
Ce sont des utilisateurs qui écrivent et lisent constamment dans un rapport de 30 à 70, respectivement. Ce test a été réalisé davantage dans un souci d’expérimentation. Données statistiques VSImax :
VSIbase = 1673, Seuil VSI atteint sur 240 utilisateurs.
Statistiques de charge du système de stockage issues de la surveillance SimpliVity :
Ce type de charge est essentiellement un test de contrainte du système de stockage. Lors de son exécution, chaque utilisateur écrit de nombreux fichiers aléatoires de différentes tailles sur le disque. Dans ce cas, on constate que lorsqu'un certain seuil de charge est dépassé pour certains utilisateurs, le temps nécessaire pour effectuer les tâches d'écriture de fichiers augmente. Dans le même temps, 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 actuellement impossible de déterminer exactement la cause des retards.
Les conclusions sur les performances du système à l'aide de ce test ne peuvent être tirées qu'en comparaison avec les résultats des tests sur d'autres systèmes, car ces charges sont synthétiques et irréalistes. Cependant, dans l’ensemble, le test s’est bien passé. Tout s'est bien passé jusqu'à 210 sessions, puis des réponses étranges ont commencé, qui n'ont été suivies nulle part sauf Login VSI.
300 travailleurs de l'énergie
Ce sont des utilisateurs qui aiment le processeur, la mémoire et les E/S élevées. Ces « utilisateurs expérimentés » exécutent régulièrement des tâches complexes sur de longues périodes, telles que l'installation de nouveaux logiciels et le décompression d'archives volumineuses. Données statistiques VSImax :
VSIbase = 970, le seuil VSI n'a pas été atteint.
Statistiques de charge du système de stockage issues de la surveillance SimpliVity :
Lors des tests, le seuil de charge du processeur 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 peut supporter une charge accrue sans dégradation significative des performances. Le temps nécessaire pour effectuer les tâches utilisateur augmente progressivement, le temps de réponse du système ne change pas pendant les tests et peut aller jusqu'à 3 ms en écriture et jusqu'à 1 ms en lecture.
Les tests réguliers n'étaient pas suffisants pour le client, et nous sommes allés plus loin : nous avons augmenté les caractéristiques de la VM (nombre de vCPU pour évaluer l'augmentation du surabonnement et de la taille du disque) et ajouté une charge supplémentaire.
Lors de la réalisation de tests supplémentaires, la configuration de stand suivante a été utilisée :
300 bureaux virtuels ont été déployés dans une configuration 4vCPU, 4 Go de RAM et 80 Go de disque dur.
Configuration d'une des machines de test :
Les machines sont déployées dans l’option Dédié – Copie Complète :
Benchmark de 300 travailleurs du savoir avec surabonnement 12
Données statistiques VSImax :
VSIbase = 921 ms, le seuil VSI n'a pas été atteint.
Statistiques de charge du système de stockage issues de la surveillance SimpliVity :
Les résultats obtenus sont similaires au test de la configuration précédente de la VM.
300 Power Workers avec 12 surabonnements
Données statistiques VSImax :
VSIbase = 933, le seuil VSI n'a pas été atteint.
Statistiques de charge du système de stockage issues de la surveillance SimpliVity :
Lors de ces tests, le seuil de charge du processeur a également été atteint, mais cela n'a pas eu d'impact significatif sur les performances :
Les résultats obtenus sont similaires au test de la configuration précédente.
Que se passe-t-il si vous exécutez la charge pendant 10 heures ?
Voyons maintenant s’il y aura un « effet d’accumulation » et effectuons des tests pendant 10 heures d’affilée.
Les tests à long terme et la description de la section devaient viser au fait que nous voulions vérifier si des problèmes surviendraient avec la ferme sous une charge prolongée.
Benchmark de 300 travailleurs du savoir + 10 heures
De plus, un cas de charge de 300 travailleurs intellectuels a été testé, suivi d'un travail utilisateur pendant 10 heures.
Données statistiques VSImax :
VSIbase = 919 ms, le seuil VSI n'a pas été atteint.
VSImax Données statistiques détaillées :
Le graphique montre qu’aucune dégradation des performances n’est observée tout au long du test.
Statistiques de charge du système de stockage issues de la surveillance SimpliVity :
Les performances du système de stockage restent les mêmes tout au long du test.
Tests supplémentaires avec ajout de charge synthétique
Le client a demandé d'ajouter une charge sauvage au disque. Pour ce faire, une tâche a été ajoutée au système de stockage dans chacune des machines virtuelles de l’utilisateur pour exécuter une charge synthétique sur le disque lorsque l’utilisateur se connecte au système. La charge a été assurée par l'utilitaire fio, qui permet de limiter la charge sur le disque par le nombre d'IOPS. Sur chaque machine, une tâche a été lancée pour lancer une charge supplémentaire d'un montant de 22 IOPS 70 %/30 % de lecture/écriture aléatoire.
Benchmark de 300 travailleurs du savoir + 22 IOPS par utilisateur
Lors des tests initiaux, il a été constaté que fio imposait une surcharge CPU importante aux machines virtuelles. Cela a entraîné une surcharge rapide du processeur des hôtes et a grandement affecté le fonctionnement du système dans son ensemble.
Charge du processeur hôte :
Dans le même temps, les retards du système de stockage ont également naturellement augmenté :
Le manque de puissance de calcul est devenu critique autour de 240 utilisateurs :
En raison des résultats obtenus, il a été décidé d'effectuer des tests moins gourmands en CPU.
Benchmark de 230 employés de bureau + 22 IOPS par utilisateur
Pour réduire la charge sur le processeur, le type de charge Office Workers a été sélectionné et 22 IOPS de charge synthétique ont également été ajoutées à chaque session.
Le test a été limité à 230 sessions afin de ne pas dépasser la charge CPU maximale.
Le test a été réalisé avec des utilisateurs fonctionnant pendant 10 heures pour vérifier la stabilité du système lors d'un fonctionnement à long terme à une charge proche de la charge maximale.
Données statistiques VSImax :
VSIbase = 918 ms, le seuil VSI n'a pas été atteint.
VSImax Données statistiques détaillées :
Le graphique montre qu’aucune dégradation des performances n’est observée tout au long du test.
Statistiques de charge CPU :
Lors de l'exécution de ce test, la charge sur le processeur des hôtes était presque maximale.
Statistiques de charge du système de stockage issues de la surveillance SimpliVity :
Les performances du système de stockage restent les mêmes tout au long du test.
La charge sur le système de stockage pendant le test était d'environ 6 500 IOPS dans un rapport 60/40 (3 900 IOPS en lecture, 2 600 IOPS en écriture), soit environ 28 IOPS par poste de travail.
Le temps de réponse était en moyenne de 3 ms en écriture et jusqu'à 1 ms en lecture.
Total
Lors de la simulation de charges réelles sur l'infrastructure HPE SimpliVity, des résultats ont été obtenus confirmant la capacité du système à prendre en charge des bureaux virtuels d'au moins 300 machines Full Clone sur une paire de nœuds SimpliVity. Dans le même temps, le temps de réponse du système de stockage a été maintenu à un niveau optimal tout au long des tests.
Nous sommes très impressionnés par l'approche des tests longs et de la comparaison des solutions avant la mise en œuvre. Nous pouvons également tester les performances de vos charges de travail si vous le souhaitez. Y compris d’autres solutions hyperconvergées. Le client mentionné termine actuellement les tests sur une autre solution en parallèle. Son infrastructure actuelle est simplement constituée d'un parc de PC, d'un domaine et de logiciels sur chaque lieu de travail. Passer au VDI sans tests est bien entendu assez difficile. Plus précisément, il est difficile de comprendre les capacités réelles d’une ferme VDI sans y migrer de vrais utilisateurs. Et ces tests vous permettent d'évaluer rapidement les capacités réelles d'un système particulier sans avoir besoin d'impliquer les utilisateurs ordinaires. C’est de là qu’est née cette étude.
La deuxième approche importante est que le client s’engage immédiatement à une mise à l’échelle appropriée. Ici vous pouvez acheter un serveur supplémentaire et ajouter une ferme, par exemple, pour 100 utilisateurs, tout est prévisible au prix utilisateur. Par exemple, lorsqu’ils auront besoin d’ajouter 300 utilisateurs supplémentaires, ils sauront qu’ils ont besoin de deux serveurs dans une configuration déjà définie, plutôt que de reconsidérer la mise à niveau de l’ensemble de leur infrastructure.
Les possibilités de la fédération HPE SimpliVity sont intéressantes. L'entreprise est géographiquement séparée, il est donc logique d'installer votre propre matériel VDI distinct dans un bureau distant. Dans la fédération SimpliVity, chaque machine virtuelle est répliquée selon un planning avec la possibilité de se répliquer entre clusters géographiquement distants très rapidement et sans charge sur le canal - c'est une sauvegarde intégrée d'un très bon niveau. Lors de la réplication de VM entre sites, le canal est utilisé le moins possible, ce qui permet de construire des architectures DR très intéressantes en présence d'un centre de contrôle unique et d'un ensemble de sites de stockage décentralisés.
Tout cela ensemble permet d’évaluer de manière très détaillée l’aspect financier, de superposer les coûts du VDI aux plans de croissance de l’entreprise, et de comprendre à quelle vitesse la solution sera rentable et comment elle fonctionnera. Parce que tout VDI est une solution qui permet en fin de compte d'économiser beaucoup de ressources, mais en même temps, très probablement, sans la possibilité rentable de la modifier dans les 5 à 7 ans d'utilisation.
De manière générale, si vous avez des questions qui ne sont pas destinées à un commentaire, écrivez-moi par email [email protected].
Source: habr.com