Découvrez comment, en tant que cloud provider, nous optimisons les workloads de nos clients grâce à vCloud Director (vCD) et nos puissantes optimisations. De l’importance de vNUMA pour les workloads GPU NVIDIA à la création d’environnements cloud optimisés, nous vous révélons les secrets d’un cloud provider qui place l’optimisation au cœur de nos services.
Chapitre 1: Qu’est-ce que vCloud Director et ses optimisations.
Fleuron de VMware, vCloud Director (vCD) est la solution développée par VMware pour le Cloud Public permettant ainsi aux clouds providers de proposer une offre IaaS, Longtemps, vCD été utilisé par les clients comme du Cloud privé, ce n’est qu’à partir de la version 10 où vCloud Director a pris un tout autre tournant.
Aujourd’hui VMware investi une grande partie sur la branche technologique Cloud pour en faire une solution stable et fiable. D’ailleurs cela a donné naissance à plusieurs Cloud Provider sur le marché, et c’est sans compter l’enjeu grandissant des “Sovereign Cloud Provider” qui ont pu naître grâce à cette solution.
A ce sujet VMware délivre des homologations aux Cloud Provider respectant le cahier des charges VMware.
Chapitre 2 : Détail technique concernant les optimisations de vCD
vCD a plusieurs paramètres d’optimisations pour permettre aux cloud provider d’optimiser leur capacity planning en trouvant le meilleur rapport performance/consommation des workloads.
- vCPU Speed sur les « OrgVDC »
- vCPU Speed sur les « VM Sizing »
- Storage sizing des « Storage Policy».
- Network quota
- Sizing des « vGPU Policy”
vCPU Speed sur les « OrgVDC »
Ce paramètre permet de limiter la consommation en « GHz » sur chaque VM de l’OrgVDC, il est semblable au paramètre « limit » sur les VM côté vCenter.
Exemple concret, en prenant notre ESXi de l’article précédent qui est un Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz avec 18 cœurs par socket il faut comprendre que chaque cœur physique aura/pourra consommer 3GHz.
Si un cluster constitué de 3 nœuds Intel Xeon Gold 6354 nous avons ~162 GHz potentiellement consommable au total.
(18 cœurs * 3 GHz * 3 ESXi)
Si ce paramètre n’était pas présent même une VM de 18vCPU pourraient consommer l’ensemble de la fréquence du cluster.
N.B : Etant donné que l’hyperthreading est activé il faut multiplié le nombre de cœur par 2 (18 cœurs * 2 = 36 cœurs = 108 GHz)
La configuration de la VM sur le vCenter
Exemple d’une VM avec un benchmark OCCT
Consommation en GHz sur la VM
Consommation de la VM sous OCCT sur le vCenter
Côté vCD sur l’OrgVDC si le vCPU Speed est configuré à 1 GHz cela veut dire que chaque workload présent sur l’OrgVDC se verra affecter une limite de 1GHz par cœur, et peu importe que la VM ait 1 ou X vCPU.
Ici nous avons une VM avec 16 vCPU ce qui donne 16GHz d’allocations sur le cluster.
Nous pouvons le vérifier sur la vue « provider » vCD qui est la vue d’administration de l’infrastructure.
Deuxième exemple avec le même paramètre mais cette fois-ci à 10GHz
Cette fois-ci nous configuration la même VM mais avec le « vCPU Speed Limit » à 10 GHz ce qui donne automatiquement 160 GHz d’alloués sur le cluster. Ce qui, dans ce cas n’est pas adapté parce qu’un ESXi peut contenir une VM ayant maximum 107.71 GHz comme vu précédemment.
Nous pouvons voir clairement que ce paramètre est indispensable, et encore plus dans le cas d’une infrastructure mutualisée comme un cloud provider où chaque mauvaise configuration peut vite devenir un gros problème (remédiation avec planification et arrêt des workloads dans certain cas) . Si nous prenons l’exemple de la VM ci-dessus avec une limite à 10GHz la VM pourra consommer plus de CPU/GHz que ce que propose le cluster, imaginez-vous quelques minutes que cette VM se fasse compromettre. C’est une infrastructure de production qui peut être perturbée par une mauvaise configuration complexe à identifier, dans le sens où très peu de workload consomment autant, sauf les outils de benchmarks qui eux n’ont pas de limite à par celle du physique.
vCPU Speed sur les «VM Sizing»
Le paramètre « vCPU Speed » a le même effet que le « vCPU Speed » mais au niveau des VM Sizing directement lié au gabarit de la VM.
L’idée de ce paramètre et de pouvoir dimensionner la consommation GHz en fonction de la taille du profil (meilleure rapport peformance/capacity planning).
NB : sur la version vCD 10.3.2 il y a un bug d’affichage sur « CPU allocation used » il faut éteindre puis rallumer la VM pour que l’ancienne valeur d’allocation soit remise à zéro et que la nouvelle s’affiche :
- Si par exemple une VM tourne avec 8 vCPU sans vCPU Speed sur son VM Sizing et qu’on l’éteint cette VM puis qu’on change son gabarit par un 16 vCPU c’est toujours la valeur de 8 GHz (8vCPU) qui est affichée. Il faut allumer la VM une première fois puis l’éteindre pour que cette valeur « CPU allocation used » soit mise à jour.
Storage sizing des «Storage Policy»
Ce paramètre quant à lui permet de limiter les ressources de stockage qu’une OrgVDC peut consommer sur le cluster.
Exemple :
Si nous avons un cluster vSAN de 700To nous avons possibilité de limiter tous les workloads de l’OrgVDC à 20To maximum. (Évidemment pour les exemples ci-dessous je ne prends pas en compte les limitations OS sur le storage sizing)
- Une VM Windows de 10To
- Une VM Linux de 5To
Même principe avec une VM qui se fait compromettre et où il n’y a aucune limitation sur l’OrgVDC elle pourrait très bien consommer l’ensemble des ressources stockage du cluster.
Network quota
Nous avons évidemment la possibilité de limiter les ressources côté network.
N.B : sur la version 10.3.2 de vCD il y a un bug qui fait que le compteur network ne fonctionne plus lorsqu’un DCGroup est configuré au niveau du tenant.
Sizing des «vGPU Policy»
Les vGPU policy ont les mêmes effets que les VM Sizing à la différence que sur les vGPU Policies il y a un VM Group à définir (VM/Host group côté vCenter) afin de regrouper les VMs au sein d’un ESXi.
N.B : Les VM ayant un profil vGPU ont obligatoirement une réservation côté RAM ESXi et RAM GPU.
Si une VM a un profil 8Q qui correspond à 8Go de RAM elle aura 8Go réservée sur l’ESXi/Carte graphique qui porte ce workload
Chapitre 3: vNUMA sur des workload GPU NVIDIA
Il existe très peu de littérature sur le sujet, autour de la topologie vNUMA et GPU Nvidia. Dans la continuité des tests, nous allons découvrir dans cet article le lien entre les deux
Pour rappel l’infrastructure pour nos benchmark est la suivante :
- Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz (2x CPU physique)
- Cores per socket : 18
- Logical Processors: 72
- Hyperthreading enabled
- RAM: 1024Go (à diviser par deux, 512Go par socket)
Comparaison des benchmarks :
Ces variations sont très certainement dues à une charge côté VM ou ESXi, nous pouvons donc en conclure qu’il n’y a aucune différence de performance sur une VM ayant un profil GPU attaché ou non mais il est aussi à noter que cela va dépendre des softwares qui vont être utilisés par la carte vGPU.
N.B : Ces tests ont été effectués à travers vCD mais le concept reste le même s’ils avaient été effectués sur le vCenter (la différence entre un workload GPU et non GPU est l’association d’un device PCIe).
Conclusion
Il est à noter que l’ensemble de ces benchmark couvre une grande partie des use cases/workloads que peuvent avoir des clients de Cloud Provider et également des infrastructures on-premise (CPU, chiffrement, traitement vidéo avec ou sans CUDA,..) mais ils ne peuvent représenter la réalité en tout point étant donné qu’une infrastructure est majoritairement composée de workload hétérogène, cet article est donc là pour vous aider à trouver le bon compromis entre performance et optimisation de votre infrastructure mais des tests sont indispensables sur l’infrastructure en question.
A vos tests ! 😉
– Kevin DOS SANTOS, System Engineer – VMware Cloud