Topologie CPU & VMware vSphere

6 juillet 2017 enioka Pierre Coppée

Quelle est la performance des processeurs dans un contexte virtualisé ?

L’architecture des processeurs ne peut être complètement oubliée quand il s’agit de
virtualiser des infrastructures importantes. NUMA ? Virtual CPU ? Virtual Socket ?
Wide VM ? Cet article fait le point sur ces concepts clés de la virtualisation, leur
impact sur la performance des VM et comment cela se matérialise avec VMware
vSphere.

Introduction
Contexte

Au cours d’une mission chez un de mes clients, j’ai accompagné un certain nombre
de projets sur la partie architecture infrastructure. L’un de ces projets reposait sur la
technologie Active Pivot. Ce logiciel permet, à partir d’un jeu de données, de créer
des cubes en mémoire et de l’offrir aux utilisateurs sous la vue d’un tableau croisé
dynamique.

La question de la configuration et l’optimisation des processeurs sur ce type de

technologie dans un environnement dédié et virtualisé (VMware) s’est posé. L’enjeu
était de valider les performances des traitements sur un gros volume de données en
mémoire (128/256 Go par VM) et comprendre l’impact de la virtualisation.

Problématique

La première fois que l’on voit l’interface de vSphere, certains paramètres peuvent
sembler étranges sur la partie CPU. En particulier :

Le paramètre « core per socket »

Le paramètre « vSocket »

Plus globalement, il faut comprendre que, chercher à optimiser le traitement CPU

d’une machine virtuelle revient à s’interroger sur l’optimisation CPU de la totalité
de la stack de virtualisation: l’hôte -> l’hyperviseur-> le matériel virtuel. Ces deux
paramètres ont des impacts sur deux des composants de cette stack, nous allons
expliquer pourquoi dans cet article.

Périmètre de l’article

Le sujet est large. C’est pourquoi cet article se limite volontairement à l’impact de la
topologie des processeurs sur la virtualisation avec VMware et ESXi. Par exemple, le
CPU scheduling n’est pas traité et pourra faire l’objet d’un autre article.

Rappel des composants VMware vSphere

Dans un datacenter, on va trouver des serveurs physiques sur lesquels sont installés
des hyperviseurs natifs (type 1) nommés ESXi. Ces serveurs (des hosts) par le biais
des ESXi portent des VMs (des guests). Le tout est opéré par une suite logicielle
nommée vCenter. L’administrateur à l’aide de l’IHM web ou du client lourd vSphere
administre l’ensemble de cette ferme. Un lexique technique est proposé en fin
d’article.

Dans la suite de cet article, nous ne parlerons que de VMware vSphere.

Structure d’un processeur et NUMA

En vrai

Une socket est l’emplacement physique sur lequel se branche le composant qui
contient le ou les processeur(s).

Sur cette image on voit que les barrettes de RAM sont plus rapprochées de certaines
sockets que d’autres. Cette affinité entre les processeurs et la mémoire est au cœur
de la problématique NUMA (cf. chapitre suivant).
Ici on peut imaginer deux nœuds NUMA qui comprennent une socket chacun et la
RAM immédiatement positionnée au dessus et en dessous de la dite socket.

Les nœuds NUMA

Mais qu’est-ce donc qu’un noeud NUMA ? Et pourquoi est-ce important de le

comprendre ?

Une socket peut contenir plusieurs processeurs, des cœurs physiques. Ces cœurs
font partie d’un ensemble que l’on nomme CPU package. Un CPU package contient
donc X cœurs et un cœur ne peut faire parti que d’une seul CPU package.

Un nœud NUMA est l’association entre un CPU package et la mémoire accessible

localement par l’ensemble des cœurs du CPU package. Quand on parle d’un nœud
NUMA, on parle autant de processeurs que de mémoire.

Dans cette exemple, nous avons un serveur de 512 Go de RAM et de 16 cores répartis
sur deux sockets.

Serveur physique de 512Go de RAM et de 16 cores

Socket 0:
 Un package CPU
8 cœurs
A accès à 256Go de mémoire en local et 256 Go en distant
Socket 1:
Un package CPU
8 cœurs
A accès à 256Go de mémoire et 256 Go en distant

Il existe différents types de sockets et de processeurs. On peut trouver des sockets

avec plusieurs CPU packages et donc plusieurs nœuds NUMA. On parle dans ce cas
d’architecture Cluster-On-Die.

Le schéma ci-dessous illustre ce concept. On a une socket de 16 cœurs mais ces

cores sont répartis en deux CPU packages de 8 cœurs. Chacun de ces CPU Packages
ont un accès local à une partie de la RAM (256 Go pour être précis) ce qui fait deux
nœuds NUMA pour un seul processeur.

Un autre exemple avec le processeur AMD Opteron 6174. Cette gamme de

processeur dispose de 12 cœurs par socket mais répartis en deux CPU Packages de 6
cœurs. Si on dispose donc de 4 sockets, on va voir apparaître 8 nœuds NUMA de 6
cœurs.

Accès à la mémoire

Nous avons dit précédemment qu’un nœud NUMA est l’association entre un
ensemble de cœurs regroupés dans un CPU Package et la mémoire (RAM). Pourquoi
?

Tout simplement parce qu’avec le concept NUMA (Non Unified Memory Access) il
existe deux types d’accès à la mémoire :

Un accès dit local (un accès direct à la mémoire « proche », c’est à dire sans
passer par les liaisons QPI (QuickPath Interconnect, bus de données entre les
CPU) pour les technologies Intel
 Un accès dit en remote, c’est-à-dire que l’on est obligé de passer à travers les
liens QPI pour avoir accès à la mémoire

On trouve l’équivalent de la technologie QPI chez AMD sous le nom de

HyperTransport.

Ce qu’il faut retenir c’est que l’accès, du fait que l’on soit obligé de passer par des
bus supplémentaire, augmente le temps d’accès à la mémoire. Cette
problématique d’accès à la mémoire est au cœur ( ) des enjeux des constructeurs
de CPU, et l’arrivée d’une nouvelle gamme de CPU est souvent accompagnée
d’optimisations côté QPI ou HyperTransport.

La mémoire cache

L’accès à la mémoire est au centre des problématiques de performance, parce qu’un

accès long à la mémoire bloque un processeur (qui attend, « iowait »). Plus le temps
d’accès à la mémoire est long plus le processeur sera bloqué et terminera son calcul
tardivement.

Pour palier à cette problématique les constructeurs ont implémenté différents

niveaux de cache pour améliorer les temps d’accès. L’image ci dessous montre à
quoi ressemble ces caches au sein d’un CPU.

Il existe deux grands types de cache:

Les caches non partagés (L1 et L2) c’est à dire ceux qui appartiennent à un
cœur physique
 Les caches partagés entre les cœurs d’une même socket physique. C’est le cas
des caches type L3 et L4 qui font partis d’un ensemble que l’on nomme LLC
(Last Level Cache)

Ce qu’il est intéressant de regarder, dans le tableau ci-dessus, sont les temps
d’accès aux caches et à la mémoire. On remarque globalement une grande
différence entre les temps d’accès aux différents niveaux de caches (Lx) et la RAM
qu’elle soit locale ou non. Ces temps d’accès nous permettent de nous rendre
compte de l’importance de rester le plus possible dans un contexte mémoire local
et donc au sein d’un même nœud NUMA.

Résumé et Hyperthreading

Deux grands axes intimement liés quand on parle des nœuds NUMA :

L’accès mémoire qui se doit d’être le plus local et optimisé possible

les cœurs sur lesquels repose la VM doivent faire partis du même nœud NUMA
pour optimiser l’allocation et l’accès mémoire par ces cœurs

Le schéma ci-dessous résume les différentes couches que nous avons vu dans les
chapitres précédents:

L’hyperThreading (HT) est un terme commercial Intel. On trouve l’équivalent chez

AMD avec l’architecture Bulldozer, qui implémente du CMT (Cluster Multi Threading),
et plus récemment sur l’architecture Zen qui implémente du SMT (Simultaneous
Multi Threading).

Il est à noter que dans le cas d’une utilisation de technologies type HyperThreading,
les caches L1 et L2 sont partagés entre les deux cœurs logiques d’un même cœur
physique.

L’enjeu du NUMA alignment

L’enjeu de cette partie est de décrire et expliquer l’importance des nœuds NUMA
dans un contexte non virtualisé dans un premier temps et dans un contexte
virtualisé dans un second temps.

Les nœuds NUMA sur du bare metal

Les nœuds NUMA n’ont pas une importance qu’au sein de contextes virtualisés.

Prenons l’exemple ici d’un serveur physique sur lequel est installé un système
d’exploitation. L’OS quel qu’il soit voit la topologie NUMA des processeurs qui lui
sont rattachés. Par des appels système, l’OS optimise lui même les allocations
mémoires affectées aux applications installées. Cette optimisation se fait, tant que
faire se peut, en fonction de la quantité de RAM demandée initialement par
l’application et les espaces mémoires disponibles sur le serveur.

Au cours du temps, si l’application demande plus de RAM à l’OS ces même

optimisations peuvent être assurées par l’OS ou par un administrateur système avec
des outils type numad sous Linux.

Exemple :

Les nœuds NUMA pour une VM

Les nœuds NUMA, s’ils sont mal gérés, peuvent poser deux problèmes :

1. Le cas le plus classique : des cœurs sont alloués à une VM mais répartis sur
deux nœuds NUMA distincts. Dans l’exemple ci-dessous, nous avons une VM
de 8 vCPU répartis sur deux nœuds NUMA. Si on part du principe que la RAM
allouée à la VM a été provisionnée sur la mémoire accessible en local par le
nœud NUMA 0, les deux cœurs du nœud NUMA 1 y accèdent en remote

2. Le second cas possible : la quantité de RAM demandée par la VM est plus

importante que la quantité de RAM au sein d’un nœud NUMA. Dans ce cas,
la RAM de la VM va être partagée au sein des deux nœuds NUMA et un accès en
remote à cette mémoire va avoir lieu
Nous verrons dans les chapitres suivants comment se prémunir et superviser ces
comportements.

Revenons à la problématique
On l’a vu en première partie de cet article, la définition d’une VM passe par la
définition d’éléments de configuration qu’il est important de comprendre.

Une VM dans VMware vSphere

Une VM, c’est :

un OS
des resources de stockage
des interfaces réseaux
de la mémoire RAM
des resources de traitement (un nombre de vCPU)

Sur ce dernier point, celui qui nous intéresse le plus, on remarque que plusieurs
éléments, configurables, définissent le nombre de vCPU :

vCPU = nombre de vSocket x cores per socket

Comme le montre l’image ci-dessus, le paramètre vSocket correspond à la socket

« physique » vue par l’OS. Dans la VM de test Archlinux utilisée ici, dont le
paramétrage sur l’hyperviseur VMware Fusion apparait à droite, on identifie
clairement grâce à la commande « lscpu » :

2 sockets
2 processeurs (l’OS voit une socket de 1 cœur physique, chaque cœur possède
un thread unique, il n’y a pas d’hyperthreading)
1 nœud NUMA

Dans la suite de la présentation, ces paramétrages seront représentés sous la forme

suivante :
vSocket et cores per socket

La notion de vSocket a été introduite dans vSphere 4.1 pour passer outre les
restrictions des OS sur le nombre de CPU – dans les versions précédentes il n’y avait
pas possibilité de paramétrer le nombre de cœurs par vSocket :

Le vSocket est vu par l’OS comme étant le CPU (la socket)

Le nombre de « cores per socket » est vu comme le nombre de cœurs par CPU
Ex : Un Microsoft Windows Server 2008 R2 Standard Edition ne supporte que 4
processeurs maximum

Les éléments de configuration « vSocket» et « cores per sockets » :

Affectent les performances lorsque le nombre de vCPU (totaux) paramétrés

sur la VM est plus grand que le nombre de CPU dans le CPU package
N’affectent (normalement) pas les performances dans le cas contraire et
peuvent permettre d’économiser en licence

Je dis « normalement » parce que VMware est on ne peut plus claire (cf. VMware
Performance Best Practices on vSphere 6.0 White Paper) :

For non-wide virtual machines, the number of cores

per virtual socket is not as critical as for wide virtual
machines. On rare occasions, however, configuring
cores per socket to a value other than 1 could
influence guest CPU scheduling in either helpful or
harmful ways. Careful testing is therefore
recommended before changing this configuration.

Résumé : sur une VM dont les vCPU ne tournent pas dans un seul noeud NUMA (non
wide), toucher au cores per socket n’a normalement pas de conséquences mais rien
ne permet d’en être certain. Chaque cas nécessite d’être testé.
L’objectif n’est pas de tourner en dérision les propos de VMware, dans de nombreux
cas (réel) la gestion des fermes VMware changent du tout au tout :

différentes gammes de serveurs au sein d’une même ferme

différentes gammes de CPU au sein d’une même ferme
parfois les administrateurs VMware privilégient la modification des cores per
socket plutôt que le nombre de vSocket (ce qui va à l’encontre des best
practices VMware)
 souvent la configuration de la VM dépend plus de l’admin que des standards
d’infrastructure

Pour conclure, dans une entreprise qui a un SI depuis plusieurs années, une ferme
VMware est en général très hétérogène et ce sur plusieurs plans (software,
hardware, etc.).

Dans ce genre de contexte, difficile de déterminer l’évolution des performances de la

VM (que ce soit sur le CPU ou autre) au cours de son évolution dans le temps, en
particulier si on ajoute un déplacement automatique de la VM sur les hosts qui
composent la ferme VMware…

vSocket vs cores per socket

Pour vous montrer les conséquences de ces paramétrages depuis la machine invitée,
voici quelques exemples:

L’OS voit 4 processeurs de 1 cœur physique (1 thread montre qu’il n’y a pas de HT
parce que: x threads = x cœurs).
L’OS voit 2 sockets de 2 cœurs physiques.

L’OS voit 1 sockets de 4 cœurs physiques.

Les bonnes pratiques

Dans la littérature, il est recommandé de laisser le nombre de core per sockets à 1.

Pour de nombreuses raisons (en général du licencing), on peut être amené à mettre
plus de 1 core per socket, dans ce cas :

Pour une « wide » VM, le nombre de cores par socket va déterminer la taille des
vNUMA exposés à la VM (cf. chapitre suivant)
Pour une « non-wide » VM, modifier cette configuration peut, dans de rares
cas, améliorer ou détériorer les performances de la machine par son influence
sur le CPU scheduler (host)
Les « wides » VMs
Exposition du vNUMA

Depuis vSphere 5.0 il est possible de présenter au système invité la topologie NUMA
via la technologie vNUMA. Le terme vNUMA est un terme spécifique à VMware.

Ça a donc pour effet de permettre :

des optimisations NUMA depuis l’OS invité

des optimisations NUMA pour le/les application(s) du système invité

Par défaut, une VM est considérée comme « wide VM » si :

Le nombre de vCPU vu par la VM est strictement supérieur à 8 (chiffre par

défaut dans la configuration VMware vSphere)
Le nombre de vCPU de la machine invitée dépasse le nombre de cœurs d’un
nœud NUMA

La terminologie « wide VM » est un terme commercial utilisé par VMware.

Ce qu’il faut retenir: Quand une VM est une wide VM, la topologie NUMA est
remontée à l’OS. On parle alors de vNUMA.

Faire remonter la topologie NUMA au guest

Plusieurs éléments de configuration permettent de paramétrer et gérer l’exposition

de la topologie NUMA à l’OS de la VM. Ces configurations peuvent se faire par VM ou
directement par host.

Comment vérifier la topologie NUMA remontée

De manière générale, sur un OS (ex avec Linux)

Nous l’avons vu, la topologie concerne autant les machines physiques que les VMs.
Regardons ici comment afficher les informations liées à la topologie NUMA et
comment les interpréter.

Nous l’avons vu, lscpu permet d’avoir des informations génériques sur tout ce qui
est lié aux processeurs:

Sur notre machine de test, il y a deux sockets physiques, chacune contient:

1 core physique (« cœurs par socket »)

de 1 thread (pas de HT, ligne « threads par cœur »)
1 nœud NUMA (« nœuds NUMA »)
la taille des caches et leur nombre (cf. chapitre précédent)

On peut obtenir la correspondance et les relations entre ces différentes informations

avec l’option « -p » ou « -e »:

Il faut lire cette sortie comme un tableau à double entrée. Le cœur physique 0
(« core » dans le tableau) appartient au nœud NUMA 0 (tout comme le core 1) et est
sur la socket 0. Il a un unique cœur logique (« CPU » dans le tableau). Aucun des
caches ne sont partagés (logique puisque sur des sockets distinctes, rappelez-vous).

L’exemple n’est ici pas très complexe, en voici un autre avec l’option « -p » qui a un
peu plus la classe :
 $ lscpu -p
# The following is the parsable format, which can be fed to other
# programs. Each different item in every column has an unique ID
# starting from zero.
# CPU,Core,Socket,Node,,L1d,L1i,L2,L3
0,0,0,0,,0,0,0,0
1,1,1,1,,1,1,1,1
2,2,0,0,,2,2,2,0
3,3,1,1,,3,3,3,1
4,4,0,0,,4,4,4,0
5,5,1,1,,5,5,5,1
6,6,0,0,,6,6,6,0
7,7,1,1,,7,7,7,1
8,8,0,0,,8,8,8,0
9,9,1,1,,9,9,9,1
10,10,0,0,,10,10,10,0
11,11,1,1,,11,11,11,1
12,0,0,0,,0,0,0,0
13,1,1,1,,1,1,1,1
14,2,0,0,,2,2,2,0
15,3,1,1,,3,3,3,1
16,4,0,0,,4,4,4,0
17,5,1,1,,5,5,5,1
18,6,0,0,,6,6,6,0
19,7,1,1,,7,7,7,1
20,8,0,0,,8,8,8,0
21,9,1,1,,9,9,9,1
22,10,0,0,,10,10,10,0
23,11,1,1,,11,11,11,1

On peut voir que les cœurs logiques (CPU) 0 et 12 partagent un certain nombre de
choses :

ils sont sur la même socket (0)

ils sont sur le même cœur physique (0)
ils sont sur le même nœud NUMA (0)
ils partagent les même caches
L1i et L1d (évident, ils sont sur le même cœur physique)
L2 (idem)
L3 (parce que sur la même socket)

A propos des caches, on peut voir que le cœur logique (CPU) numéro 2 n’appartient
pas au même cœur physique (core) que les 0 et 12 mais la même socket. Il n’a donc
pas les mêmes cache L1x/L2 mais le même cache L3.

La commande « numactl –hardware » permet d’avoir plus de détails sur ce qui nous
intéresse :

La distance ici exprime la latence d’accès à la mémoire. La configuration de cet

exemple étant simple, voici un autre exemple avec cette fois-ci 8 nœuds NUMA :
 node 0 1 2 3 4 5 6 7
0: 10 21 21 21 21 21 21 21
1: 21 10 21 21 21 21 21 21
2: 21 21 10 21 21 21 21 21
3: 21 21 21 10 21 21 21 21
4: 21 21 21 21 10 21 21 21
5: 21 21 21 21 21 10 21 21
6: 21 21 21 21 21 21 10 21
7: 21 21 21 21 21 21 21 10

La valeur 10 représente un accès local à la mémoire (entre les nœuds 0 et 0 ou les

nœuds 1 et 1, etc…). les autres des accès en remote.

Vu de la machine invitée (VM VMware) : coreinfo

Configuration des machines de l’infra pour ces exemples.

Host :

Socket: 2
CPU Package: 10
NUMA: 2

VM :

vSocket : 16
Cores per socket : 1

la commande « coreinfo » (équivalent de « lscpu » sous Linux):

On retrouve ici les même informations que dans le chapitre précédent mais sous une
autre forme :

la quantité de cœurs physiques et le mapping par rapport aux cœurs logiques

la quantité de sockets et le mapping des cœurs physique par rapport aux
sockets
des infos sur les nœuds NUMA et les cœurs physiques associés
des infos sur les caches

Vu du host

La commande « vmdumper » permet d’avoir les configurations d’une machine

allumée sur un ESXi :
On y retrouve nos configurations VMware vSphere :

Mémoire/CPU de la VM
Cores per socket
vSocket
Nœuds NUMA
Nous parlerons des autres métriques dans le chapitre suivant

La commande « esxtop » permet de sortir des métriques plus liées à la vie de la VM

au sein de l’ESX :

Les métriques intéressantes :

NRMEM : NUMA Remote Memory (doit être le plus bas possible)

NLMEM : NUMA Local Memory (doit être le plus élevé possible)
N%L: pourcentage de la mémoire accédée en local par la VM
NMIG : NUMA migration: Nombre de fois que la VM à migré d’un NUMA à un
autre
La topologie processeur par VMware
vSphere
Les couches

Chaque couche qui compose la stack de virtualisation (ici ESX et VM) s’approprie et
enrichie la topologie CPU du host.

Reprenons notre modèle de nœud NUMA sur un host :

Ajoutons à ce modèle la couche ajoutée par l’ESX (hyperviseur de VMware).

On retrouve de nouveaux concepts :

NUMA Home Node : Surcouche de l’ESX qui interprète la topologie NUMA

présente sur le host
pCPU : pour physical CPU, représente un cœur physique ou un cœur logique
dans l’hyperviseur
NUMA Client : ensemble cœurs/mémoire remonté à la VM. Ça ne veut pas
forcément dire que la VM voit la topologie NUMA

On ajoute la couche VM. On retrouve les vSocket et vCPU :

Décomposition du vNUMA
Plongeons donc au sein de ce NUMA Client qui nous intéresse tant. En le
décomposant, on retrouve deux choses :

le Physical Proximity Domain (PPD)

il assure la corrélation entre un pool de vCPU et un pool de cœur
physique au sein du même CPU package
C’est la garant de la relation suivante :
« j’assure que tel groupe de vCPU sera affilié à tel CPU Package »
(qui peut changer au cours du temps en fonction des choix du CPU
scheduler)
Ce n’est pas du pinning
il se construit automatiquement à partir du nombre de cœurs physiques
présents au sein d’un CPU Package (sauf si le paramétrage « core per
socket » n’est pas égal à 1, dans ce cas, c’est ce paramétrage qui
détermine la taille du PPD)
il est utilisé pour le placement initial des vCPU et pour le load-balancing
le Virtual Proximity Domain (VPD)
il expose la topologie vNUMA à la VM
sa taille dépend du nombre de vCPU et du nombre de cœurs physiques
sur la machine physique ou du paramétrage « core per socket » (pour
les version ESX inférieures 6.5)
Peut reposer sur plusieurs PPDs

Reprenons notre modèle et ajoutons les VPDs et les PPDs. Vous trouverez ci-dessous,
sous forme de schémas, tous les impacts possibles en fonction de la configuration
pour laquelle on opte.

Dans cet exemple, on a créé une machine virtuelle. Ses configuration sont les
suivantes :

cores per socket: 1

vSocket: 16
Total vCPU: 16 (16 x 1)

On a donc suivi les bonnes pratiques de base recommandées par VMware (cf.
VMware Performance Best Practices on vSphere 6.0 White Paper) :

When creating a virtual machine you have the

option to specify the number of virtual sockets and
the number of cores per virtual socket. In general,
we recommend leaving this at the default value of
1 core per socket (with the number of virtual
sockets therefore equal to the number of vCPUs).

Ce qui nous donne la modélisation suivante :

Le VMdumper nous confirme cette modélisation :

On remarque cependant un commentaire intéressant : « Exposing multicore

topology with cpuid.CoresPerSocket = 8 is suggested for best performance ».

Il serait donc intéressant, selon VMware, de modifier la configuration « cores per

socket » pour avoir de meilleurs performances. Ce qui est normal :

Comme vu dans le chapitre précédent sur les Wides VMs, une VM est
considérée comme étant une wide VM si la machine possède plus de 8 vCPU
(paramètre par défaut)
ou si le nombre de vCPU de la machine invitée dépasse le nombre de
cœurs d’un nœud NUMA

Ce log est cohérent avec les bonnes pratiques de VMware dans le cas de wide WMs
(cf. VMware Performance Best Practices on vSphere 6.0 White Paper):

For wide virtual machines, be very careful about

setting cores per virtual socket to a value other
 than the default (1 core per socket). It’s best to first
try the default to determine what vNUMA size ESXi
selects for your virtual machine in your
environment. Once you know the vNUMA size, use it
to choose a value for cores per socket.

For example, when running a 16-vCPU virtual

machine on a host system with 10 cores per
physical socket, ESXi will select a vNUMA size of 8.
Once this vNUMA size is known, you would
configure this virtual machine to have 8 cores per
virtual socket.

Donc, si on crée une wide VM, cette fois-ci de 20 vCPU, et en suivant tous les conseils
de VMware :

cores per socket: 10

vSocket: 2
Total vCPU: 20 (10 x 2)

On a la modélisation suivante :

Nos PPD sont répartis sur nos deux nœuds NUMA et se composent de
l’intégralité des processeurs du host
On trouve autant de VPDs que de PPDs et ceux ci se composent d’autant de
cores que ces derniers

Bref, tout est bien aligné… On voit qu’a travers cette configuration le travail du CPU
Scheduler s’en retrouve simplifié. Vous aurez le temps de vous en rendre compte en
jetant un œil aux modélisations suivantes

Entrons maintenant dans la maison des horreurs de la configuration VMware.

Prenons l’exemple de l’élève qui à tout compris de travers et qui a toujours modifié
le nombre de cores per socket plutôt que le nombre de vSocket.

Configuration de notre nouvelle VM:

 cores per socket: 12
vSocket: 1
Total vCPU: 12 (12 x 1)

La modélisation associée :

un VPD de 12 cœurs et réparti sur deux PPDs

deux PPDs de 6 cœurs répartis sur les deux nœuds NUMA

On sent que ça va bien se passer…

On a donc une VM dont l’OS va voir un nœud NUMA au lieu de deux. La mémoire va
vite se retrouver répartie entre les deux NHN (NUMA Home Node) et des accès en
remote vont apparaitre. Le travaille du CPU scheduler au sein de l’ESXi va s’en
trouver affecté et on peut s’attendre à beaucoup de context switch.

Prenons maintenant l’élève qui a compris à peu près la moitié de tous les concepts
et qui, pour se rassurer, va donc tout mélanger.

Configuration de notre nouvelle VM :

cores per socket: 2

vSocket: 6
Total vCPU: 12 (2 x 6)

La modélisation associée :

six VPDs de 2 cœurs

six PPDs de 2 cœurs

Un carnage, la VM va voir une topologie de six nœuds NUMA au lieu des deux qui
existent réellement. Au niveau de l’ESXi, le CPU scheduler va devoir scheduler 6 PPD
au lieu de 2. L’OS quant à lui va être amené à faire beaucoup plus d’optimisations
que nécessaire et qui, au final, n’en seront pas.
Tous ces exemples montrent bien l’impacte de l’option « cores per socket » sur la
taille des VPDs/PPDs et toutes les horreurs associées si l’on ne fait pas attention.

L’article « Does corespersocket Affect Performance » publié sur le blog de VMware

appuie ces théories.

Faut-il le répéter ? Le plus simple reste tout de même de faire en sorte de n’occuper
qu’un seul nœud NUMA. Pourquoi ? Tout simplement parce que le travail de l’OS de
la VM et de l’ESXi vont s’en trouver simplifiés. Comment faire si la quantité de vCPU
de la VM dépasse le nombre de cœurs d’un nœud NUMA ? (Je pars ici du principe que
la quantité de RAM souhaitée sur la VM soit inférieur à la quantité de RAM du nœud
NUMA.)

C’est là que l’option PerferHT entre en jeux. Pour rappel, cette option va faire en
sorte que les cœurs logiques comptent lors de la contruction du NUMA Home Node.

Configuration de notre nouvelle VM :

cores per socket: 12

vSocket: 1
Total vCPU: 12 (12 x 1)

La modélisation associée :

un VPD de 12 cœurs
un PPD de 10 cœurs

Au final notre VM, même si elle a plus de vCPU que de cœurs physiques sur notre
nœud NUMA, tient au sein d’un même NUMA Home Node. Attention cependant, il
faut avoir en tête que ce sont des cœurs logiques (HyperThreading ici) qui vont être
utilisés. En fonction de l’applicatif de la VM cela peut dégrader ou améliorer les
performances.

Et si on validait cela avec un vrai benchmark ?

Pour valider ces différentes configurations et les théories associées, enioka prépare
un benchmark qui prendra en compte :

les config CPU (dans un contexte de stress sur l’host ou non)

l’applicatif sur la VM (workload court et long)
d’autres technologies de virtualisation

Dès que ce benchmark sera réalisé, un compte rendu sera fait dans ce blog.

Les nouveautés (vSphere 6.5)

vSphere 6.5 permet de rattraper beaucoup de bêtises, en particulier, pour la

topologie vNUMA :

L’option cores per socket est découplée de la taille du VPD

Le sizing du VPD se fait automatiquement par VMware

Conclusions
Quand on ne connait pas, on ne touche pas

Dans le doute, laissez le paramètre « cores per socket » à 1. Faites des tests dans le
cas contraire.

Les bonnes questions à se poser

Le sujet est complexe, il y a beaucoup de paramètres à prendre en compte et deux

bonnes questions à se poser :

Ai-je vraiment besoin de ce niveau de performance ?

Ai-je vraiment vraiment besoin d’autant de vCPU ?

Diagramme de choix

Si la réponse à ses deux questions est « oui », vous pouvez-vous aider de ce

diagramme de choix pour déterminer la configuration CPU à faire sur votre VM.

Faites tout de même attention, ce diagramme n’a pas la prétention de vous donner à
coup sûr la bonne configuration pour votre VM et surtout il ne remplace en rien des
tests de performance et d’intégration. Il est peut probable que votre VM soit seule au
monde, mais plutôt ajoutée au sein d’une ferme existante et potentiellement
vieillissante (la version des ESXi a une grande importance). Sans compter que les
hosts qui composent cette ferme peuvent porter des CPU de gammes différentes et
donc avec des topologies NUMA différentes. Les impacts peuvent être très visibles si
le DRS en mode automatique est activé.
Webo/Biblio/Humanographie
Le Web:
http://frankdenneman.nl (architecte CPU VMware) : pour ses articles
« NUMA Deep Dive »
http://www.exitthefastlane.com/ : vSphere Design for NUMA
Architecture and Alignment
http://kendrickcoleman.com/ : vSphere 5 Hardware Version 8 & New
vCPU Config for Licensing Trickery
https://blogs.vmware.com/ (euh oui mais non) : Does corespersocket
Affect Performance?
http://superuser.com/ : Pour les explications sur les caches processeur

Les livres :
The CPU scheduler in VMware vSphere 5.1 : pour les impacts du NUMA
alignment
VMware vSphere Performance : Designing CPU, Memory, Storage, and
Networking for Performance-Intensive Workloads. Pour les éléments de
configuration et plus tard pour le CPU scheduling
Et les hommes :
Gael Lalleman : pour nos discussions passionnées sur le sujet

Lexique
vCenter : API et IHM qui permet d’opérer les fermes vSphere VMware (permet
de communiquer avec les ESX)
vSphere : Solution qui comprend vCenter + ESXi + Modules vCenter (ex: vSAN)
ESXi: vSphere ESXi est un hyperviseur bare-metal (type 1 – natif)
Host: Machine physique sur laquelle est installée ESXi et qui héberge les VMs
crées
Guest: Une VM qui repose sur un host
NUMA: Non Unified Memory Access, architecture répartissant la mémoire
physique par ensemble de cœurs processeurs
Hyperthreading: Technologie Intel (HyperTransport chez AMD) permettant de
présenter deux cœurs logique à partir d’un cœur physique
Socket: Connexion physique d’un processeur à la carte mère (HW)
vCPU: Virtual CPU, le matériel présenté à la machine virtuelle
«Wide » VM : Une VM dont la topologie NUMA lui est remontée par la
technologie vNUMA
PPD: Physical Proximity Domain, pool de cœurs physiques associés à un CPU
package
VPD: Virtual Proximity Domain, (ensemble de) pool(s) de cœurs
logiques/physiques associé(s) à un ou plusieurs PPD
 pCPU: Physical CPU vu par l’ESX (peut-être associée à un processeur logique
ou physique)
vSocket: Virtual Socket (vu par la VM comme une socket physique)
core/coeur physique: processeur physique intégré à une socket physique
core/coeur logique: processeur logique s’exécutant sur un processeur
physique

Pour aller plus loin

Des articles complémentaires sont en cours de rédaction pour prolonger la réflexion
:

Benchmark sur les configurations CPU pour VMware/KVM/Hyper-V (permettra

de valider/réfuter les théories avancées ci-dessus en fonction des contextes et
des paramétrages) – à venir
VMware CPU Scheduling: fonctionnement et principes – à venir
Virtualisation des CPU – à venir

Partager :

 LinkedIn  Twitter  Google  Imprimer

Articles similaires

← Benchmark de l’Open Source dans les grandes sociétés

Manifeste pour du développement de haute-couture →
Laisser un commentaire
Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués
avec *

Commentaire

Nom *

Adresse de
messagerie *

Site web

Enregistrer mon nom, mon e-mail et mon site web dans le navigateur pour mon
prochain commentaire.

Laisser un commentaire

Prévenez-moi de tous les nouveaux commentaires par e-mail.

Prévenez-moi de tous les nouveaux articles par email.

managing IT complexity - enioka.com

Étiquettes

Architecture batch Big Data Business Intelligence Complexité Coût Décisionnel

développement Formats haute-couture Interfaces Intégration Java jqm Modélisation

mutualisation Méthode Open Source Organisation Orientation service Performance Pivot
Représentation visuelle Référentiels sécurité Transformation SI Urbanisme

Articles les plus consultés

Topologie CPU & VMware vSphere

Concevoir des interfaces inter-applicatives : les formats pivots

Problématiques des interfaces entre applications

Gérer la complexité des SI

Urbanisme des référentiels - partie I

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (3/5)

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (4/5)
Urbanisme des référentiels - partie III

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (1/5)

Commentaires sur l'article VMware "Does corespersockets Affect Performances ?"

Archives
mars 2018

juillet 2017

février 2017

octobre 2016

septembre 2015

juillet 2015

mai 2015

avril 2015

mars 2015

février 2015

décembre 2013

avril 2013

novembre 2012

octobre 2012

septembre 2012

août 2012

juillet 2012

décembre 2011

janvier 2011

Derniers articles
Commentaires sur l’article VMware « Does corespersockets Affect Performances ? »

Manifeste pour du développement de haute-couture

Topologie CPU & VMware vSphere

Benchmark de l’Open Source dans les grandes sociétés

Pour un urbanisme concret

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (5/5)

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (4/5)

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (3/5)

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (2/5)

Quelle organisation autour de la Business Intelligence et du Big data dans les grandes
entreprises ? (1/5)
 Recherche…

Derniers articles
Commentaires sur l’article
VMware « Does corespersockets
Affect Performances ? »

Manifeste pour du
développement de haute-
couture

Topologie CPU & VMware

vSphere

Benchmark de l’Open Source

dans les grandes sociétés

Pour un urbanisme concret

Archives
mars 2018

juillet 2017

février 2017

octobre 2016

septembre 2015

juillet 2015

mai 2015

avril 2015

mars 2015

février 2015

décembre 2013

avril 2013

novembre 2012

octobre 2012

septembre 2012

août 2012

juillet 2012

décembre 2011

janvier 2011

Catégories
Architecture et modélisation
des SI

Développement

enioka

Infrastructure
Organisation du SI

R&D enioka

Fièrement propulsé par WordPress