{"id":932,"date":"2023-04-23T19:51:29","date_gmt":"2023-04-23T17:51:29","guid":{"rendered":"https:\/\/kdslabs.fr\/?p=932"},"modified":"2023-04-23T20:34:24","modified_gmt":"2023-04-23T18:34:24","slug":"article-comment-optimiser-ses-workloads-vnuma-sur-vsphere-7-0-u3","status":"publish","type":"post","link":"https:\/\/kdslabs.fr\/index.php\/2023\/04\/23\/article-comment-optimiser-ses-workloads-vnuma-sur-vsphere-7-0-u3\/","title":{"rendered":"[GUIDE] Comment optimiser ses workloads vNUMA sur vSphere 7.0 U3"},"content":{"rendered":"\n

[GUIDE] Comment optimiser ses workloads vNUMA sur vSphere 7.0 U3<\/u><\/h4>\n\n\n\n

Cet article a \u00e9t\u00e9 r\u00e9dig\u00e9 pour Metanext vous pouvez le retrouver, ainsi que d’autres articles techniques sur Blog – Metanext<\/a><\/strong> <\/p>\n\n\n\n

Chapitre 1: Introduction<\/span>
Chapitre 2: Qu’est-ce que le vNUMA, et comment une VM se comporte face \u00e0 cette topologie ?<\/span>
Chapitre 3: Comportement des OS face \u00e0 vNUMA<\/span>
Chapitre 4 : benchmark des VMs avec modification du vCPU et de la valeur Core per Socket (CPS).<\/span>
Sp\u00e9cification d\u2019une VM 16 vCPU \/ 128Go RAM.<\/span>
Bonus : Qu\u2019est-ce que le param\u00e8tre \u00ab PreferHT \u00bb et comment interf\u00e8re-t-il sur les performances ?<\/span><\/em>
Conclusion<\/em><\/p>\n\n\n\n

Chapitre 1: Introduction<\/u><\/h4>\n\n\n\n

Vaste sujet deep dive de nombreux passionn\u00e9s VMware qu’est le vNUMA. Il a longtemps \u00e9t\u00e9 un sujet complexe pour de nombreux architectes VMware mais aujourd’hui avec les optimisations effectu\u00e9es par la R&D VMware il est plus simple et moins contraignant de g\u00e9rer le vNUMA, et ce depuis la version vSphere 6.7 (sans compter vSphere 8 qui a totalement aboli le fameux “Cores per socket” et qui l’a remplac\u00e9 par \u00ab assigned at power on \u00bb.)
A ce sujet un post complet pourrait lui \u00eatre d\u00e9di\u00e9.

Dans le billet d’aujourd’hui nous allons donc d\u00e9montrer ces optimisations sur la version vSphere 7.0 U3 \u00e0 travers vCloud Director qui, d’ailleurs lui aussi apporte son lot d’optimisations vCPU pour g\u00e9rer au mieux son capacity planning avec la notion de \u00ab vCPU Speed. \u00bb

Ce billet sera d\u00e9compos\u00e9 en deux parties.
La premi\u00e8re partie sera consacr\u00e9e \u00e0 vNUMA et sa topologie au sein des VMs, et la seconde partie sera quant \u00e0 elle consacr\u00e9e \u00e0 vCloud Director et ses optimisations\/sp\u00e9cificit\u00e9s. <\/p>\n\n\n\n

Chapitre 2: Qu’est-ce que le vNUMA, et comment une VM se comporte face \u00e0 cette topologie ?<\/u><\/h4>\n\n\n\n

Le vNuma est une topologie qui est connue depuis un bon nombre d\u2019ann\u00e9e, et c\u2019est d\u2019ailleurs parce que \u00e7a \u00e9t\u00e9 un \u00ab casse-t\u00eate \u00bb pour les architectes VMware qui devait optimiser au mieux leurs workloads que cette topologie est connue.<\/p>\n\n\n\n

Rentrons maintenant dans le vif du sujet, un \u00ab Numa Node \u00bb est l\u2019association d\u2019un processeur physique et de ses slots m\u00e9moire au sein d\u2019une carte-m\u00e8re.<\/p>\n\n\n\n

Un exemple concret d\u2019un n\u0153ud VxRail V670F :
– Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz (2x CPU physique)
– Cores per socket : 18
– Logical Processors: 72
– Hyperthreading enabled
– RAM: 1024Go (\u00e0 diviser par deux, 512Go par socket)<\/p>\n\n\n\n

Il faut comprendre que chaque \u00ab Numa Node \u00bb est en r\u00e9alit\u00e9 compos\u00e9 d\u2019un CPU physique Intel Gold 6354 de 18 \u00ab Cores per socket \u00bb et de 512Go pour un total de \u00ab 2 Numa Node \u00bb sur la carte-m\u00e8re. Nous avons donc 36 Cores per socket et 1024Go RAM.
((18 Cores per socket * 2 CPU physiques) + (512Go RAM * 2)).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Repr\u00e9sentation logique de vNUMA au sein d\u2019une carte m\u00e8re<\/em><\/p>\n\n\n\n

Avec cet exemple nous pouvons d\u2019ores et d\u00e9j\u00e0 d\u00e9terminer plusieurs limitations, et ce sans m\u00eame rentrer dans les d\u00e9tails si une VM venaient \u00e0 avoir 32 vCPU et 768Go de RAM (elle serait r\u00e9partie physiquement sur les 2 sockets pour la partie CPU et RAM).

Parmi les limitations nous pouvons citer le QuickPath Interconnect<\/em> qui est devenu le Ultra Path Interconnect<\/em> avec la g\u00e9n\u00e9ration Skylake<\/em> (passage \u00e0 10.4 GT\/s sur les liaisons point-\u00e0-point entre les 2 processeurs), la latence m\u00e9moire entre les 2 processeurs, et le mauvais mappage des Numa Node qui est propre au monde de la virtualisation.<\/p>\n\n\n\n

Petite apart\u00e9 pour les expert VMware :
Nous sommes totalement d\u2019accord pour dire que dans ce cas-l\u00e0 il n\u2019y a presque aucun int\u00e9r\u00eat, mais attention je dis bien \u00ab presque \u00bb parce qu\u2019il y aura toujours des avantages \u00e0 faire de la virtualisation avec des workloads qui pourraient prendre 80% de RAM et qui pourraient prendre toute la charge CPU plut\u00f4t que du baremetal, ne serait-ce que pour la partie \u00ab reserved CPU\/Memory \u00bb pour le HA.<\/p>\n\n\n\n

Alors oui les chiffres sont d\u00e9mesur\u00e9s mais c\u2019est pour l\u2019exemple afin d\u2019apercevoir les limitations c\u00f4t\u00e9 ESXi (limitation, qui je le rappelle ont \u00e9t\u00e9 grandement optimis\u00e9e aujourd\u2019hui).<\/p>\n\n\n\n

Chapitre 3: Comportement des OS face \u00e0 vNUMA<\/u><\/h4>\n\n\n\n

Tout d’abord notons une chose assez importante qui va vous \u00eatre utile pour comprendre la suite de ce chapitre.
Par d\u00e9faut la topologie vNUMA est pr\u00e9sent\u00e9e \u00e0 l’OS \u00e0 partir de 8 vCPU seulement<\/a>
Les commandes de bases permettant de v\u00e9rifier la topologie vNUMA sont :<\/p>\n\n\n\n