Vous êtes sur la page 1sur 32

Topologie CPU & VMware vSphere

6 juillet 2017eniokaPierre Coppe

Quelle est la performance des processeurs dans un contexte virtualis ? Larchitecture des
processeurs ne peut tre compltement oublie quand il sagit de virtualiser des infrastructures
importantes. NUMA ? Virtual CPU ? Virtual Socket ? Wide VM ? Cet article fait le point sur
ces concepts cls de la virtualisation, leur impact sur la performance des VM et comment cela
se matrialise avec VMware vSphere.

Introduction
Contexte

Au cours dune mission chez un de mes clients, jai accompagn un certain nombre de projets
sur la partie architecture infrastructure. Lun de ces projets reposait sur la technologie Active
Pivot. Ce logiciel permet, partir dun jeu de donnes, de crer des cubes en mmoire et de
loffrir aux utilisateurs sous la vue dun tableau crois dynamique.

La question de la configuration et loptimisation des processeurs sur ce type de technologie


dans un environnement ddi et virtualis (VMware) sest pos. Lenjeu tait de valider les
performances des traitements sur un gros volume de donnes en mmoire (128/256 Go par VM)
et comprendre limpact de la virtualisation.

Problmatique

La premire fois que lon voit linterface de vSphere, certains paramtres peuvent sembler
tranges sur la partie CPU. En particulier :

Le paramtre core per socket


Le paramtre vSocket

Plus globalement, il faut comprendre que, chercher optimiser le traitement CPU dune
machine virtuelle revient sinterroger sur loptimisation CPU de la totalit de la stack de
virtualisation: lhte lhyperviseur le matriel virtuel. Ces deux paramtres ont des
impacts sur deux des composants de cette stack. Nous allons expliquer pourquoi dans cet article.

Primtre de larticle

Le sujet est large. Cest pourquoi cet article se limite volontairement limpact de la topologie
des processeurs sur la virtualisation avec VMware et ESXi. Par exemple, le CPU scheduling
nest pas trait et pourra faire lobjet dun autre article.

Rappel des composants VMware vSphere


Dans un datacenter, on va trouver des serveurs physiques sur lesquels sont installs des
hyperviseurs natifs (type 1) nomms ESXi. Ces serveurs (des hosts) par le biais des ESXi
portent des VMs (des guests). Le tout est opr par une suite logicielle nomme vCenter.
Ladministrateur laide de lIHM web ou du client lourd vSphere administre lensemble de
cette ferme. Un lexique technique est propos en fin darticle.

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

Structure dun processeur et NUMA


En vrai

Une socket est lemplacement 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 rapproches de certaines sockets
que dautres. Cette affinit entre les processeurs et la mmoire est au cur de la problmatique
NUMA (cf. chapitre suivant).
Ici on peut imaginer deux nuds NUMA qui comprennent une socket chacun et la RAM
immdiatement positionne au dessus et en dessous de la dite socket.

Les nuds NUMA

Mais quest-ce donc quun noeud NUMA ? Et pourquoi est-ce important de le comprendre ?

Une socket peut contenir plusieurs processeurs, des curs physiques. Ces curs font partie
dun ensemble que lon nomme CPU package. Un CPU package contient donc X curs et un
cur ne peut faire parti que dune seul CPU package.

Un nud NUMA est lassociation entre un CPU package et la mmoire accessible localement
par lensemble des curs du CPU package. Quand on parle dun nud NUMA, on parle autant
de processeurs que de mmoire.
Dans cette exemple, nous avons un serveur de 512 Go de RAM et de 16 cores rpartis sur deux
sockets.

Serveur physique de 512Go de RAM et de 16 cores


o Socket 0:
Un package CPU
8 curs
A accs 256Go de mmoire en local et 256 Go en distant
o Socket 1:
Un package CPU
8 curs
A accs 256Go de mmoire et 256 Go en distant

Il existe diffrents types de sockets et de processeurs. On peut trouver des sockets avec plusieurs
CPU packages et donc plusieurs nuds NUMA. On parle dans ce cas darchitecture Cluster-
On-Die.

Le schma ci-dessous illustre ce concept. On a une socket de 16 curs mais ces cores sont
rpartis en deux CPU packages de 8 curs. Chacun de ces CPU Packages ont un accs local
une partie de la RAM (256 Go pour tre prcis) ce qui fait deux nuds NUMA pour un seul
processeur.
Un autre exemple avec le processeur AMD Opteron 6174. Cette gamme de processeur dispose
de 12 curs par socket mais rpartis en deux CPU Packages de 6 curs. Si on dispose donc de
4 sockets, on va voir apparatre 8 nuds NUMA de 6 curs.

Accs la mmoire

Nous avons dit prcdemment quun nud NUMA est lassociation entre un ensemble de curs
regroups dans un CPU Package et la mmoire (RAM). Pourquoi ?

Tout simplement parce quavec le concept NUMA (Non Unified Memory Access) il existe
deux types daccs la mmoire :

Un accs dit local (un accs direct la mmoire proche , cest dire sans passer par
les liaisons QPI (QuickPath Interconnect, bus de donnes entre les CPU) pour les
technologies Intel
Un accs dit en remote, cest--dire que lon est oblig de passer travers les liens QPI
pour avoir accs la mmoire

On trouve lquivalent de la technologie QPI chez AMD sous le nom de HyperTransport.

Ce quil faut retenir cest que laccs, du fait que lon soit oblig de passer par des bus
supplmentaire, augmente le temps daccs la mmoire. Cette problmatique daccs la

mmoire est au cur ( ) des enjeux des constructeurs de CPU, et larrive dune nouvelle
gamme de CPU est souvent accompagne doptimisations ct QPI ou HyperTransport.
La mmoire cache

Laccs la mmoire est au centre des problmatiques de performance, parce quun accs long
la mmoire bloque un processeur (qui attend, iowait ). Plus le temps daccs la mmoire
est long plus le processeur sera bloqu et terminera son calcul tardivement.

Pour palier cette problmatique les constructeurs ont implment diffrents niveaux de cache
pour amliorer les temps daccs. Limage ci dessous montre quoi ressemble ces caches au
sein dun CPU.

Il existe deux grands types de cache:

Les caches non partags (L1 et L2) cest dire ceux qui appartiennent un cur
physique
Les caches partags entre les curs dune mme socket physique. Cest le cas des
caches type L3 et L4 qui font partis dun ensemble que lon nomme LLC (Last Level
Cache)

Ce quil est intressant de regarder, dans le tableau ci-dessus, sont les temps daccs aux caches
et la mmoire. On remarque globalement une grande diffrence entre les temps daccs aux
diffrents niveaux de caches (Lx) et la RAM quelle soit locale ou non. Ces temps daccs nous
permettent de nous rendre compte de limportance de rester le plus possible dans un contexte
mmoire local et donc au sein dun mme nud NUMA.

Rsum et Hyperthreading

Deux grands axes intimement lis quand on parle des nuds NUMA :

Laccs mmoire qui se doit dtre le plus local et optimis possible


les curs sur lesquels repose la VM doivent faire partis du mme nud NUMA pour
optimiser lallocation et laccs mmoire par ces curs

Le schma ci-dessous rsume les diffrentes couches que nous avons vu dans les chapitres
prcdents:
LhyperThreading (HT) est un terme commercial Intel. On trouve lquivalent chez AMD avec
larchitecture Bulldozer, qui implmente du CMT (Cluster Multi Threading), et plus rcemment
sur larchitecture Zen qui implmente du SMT (Simultaneous Multi Threading).

Il est noter que dans le cas dune utilisation de technologies type HyperThreading, les caches
L1 et L2 sont partags entre les deux curs logiques dun mme cur physique.

Lenjeu du NUMA alignment


Lenjeu de cette partie est de dcrire et expliquer limportance des nuds NUMA dans un
contexte non virtualis dans un premier temps et dans un contexte virtualis dans un second
temps.

Les nuds NUMA sur du bare metal

Les nuds NUMA nont pas une importance quau sein de contextes virtualiss.

Prenons lexemple ici dun serveur physique sur lequel est install un systme dexploitation.
LOS quel quil soit voit la topologie NUMA des processeurs qui lui sont rattachs. Par des
appels systme, lOS optimise lui mme les allocations mmoires affectes aux applications
installes. Cette optimisation se fait, tant que faire se peut, en fonction de la quantit de RAM
demande initialement par lapplication et les espaces mmoires disponibles sur le serveur.

Au cours du temps, si lapplication demande plus de RAM lOS ces mme optimisations
peuvent tre assures par lOS ou par un administrateur systme avec des outils type numad
sous Linux.

Exemple :
Les nuds NUMA pour une VM

Les nuds NUMA, sils sont mal grs, peuvent poser deux problmes :

1. Le cas le plus classique : des curs sont allous une VM mais rpartis sur deux
nuds NUMA distincts. Dans lexemple ci-dessous, nous avons une VM de 8 vCPU
rpartis sur deux nuds NUMA. Si on part du principe que la RAM alloue la VM a
t provisionne sur la mmoire accessible en local par le nud NUMA 0, les deux
curs du nud NUMA 1 y accdent en remote

2. Le second cas possible : la quantit de RAM demande par la VM est plus importante
que la quantit de RAM au sein dun nud NUMA. Dans ce cas, la RAM de la VM
va tre partage au sein des deux nuds NUMA et un accs en remote cette mmoire
va avoir lieu

Nous verrons dans les chapitres suivants comment se prmunir et superviser ces
comportements.

Revenons la problmatique
On la vu en premire partie de cet article, la dfinition dune VM passe par la dfinition
dlments de configuration quil est important de comprendre.

Une VM dans VMware vSphere

Une VM, cest :

un OS
des resources de stockage
des interfaces rseaux
de la mmoire RAM
des resources de traitement (un nombre de vCPU)

Sur ce dernier point, celui qui nous intresse le plus, on remarque que plusieurs lments,
configurables, dfinissent le nombre de vCPU :

vCPU = nombre de vSocket x cores per socket


Comme le montre limage ci-dessus, le paramtre vSocket correspond la socket physique
vue par lOS. Dans la VM de test Archlinux utilise ici, dont le paramtrage sur lhyperviseur
VMware Fusion apparait droite, on identifie clairement grce la commande lscpu :

2 sockets
2 processeurs (lOS voit une socket de 1 cur physique, chaque cur possde un thread
unique, il ny a pas dhyperthreading)
1 nud NUMA

Dans la suite de la prsentation, ces paramtrages seront reprsents 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 prcdentes il ny avait pas possibilit de paramtrer
le nombre de curs par vSocket :

Le vSocket est vu par lOS comme tant le CPU (la socket)


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

Les lments
de configuration vSocket et cores per sockets :

Affectent les performances lorsque le nombre de vCPU (totaux) paramtrs sur la VM


est plus grand que le nombre de CPU dans le CPU package
Naffectent (normalement) pas les performances dans le cas contraire et peuvent
permettre dconomiser 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.
Rsum : sur une VM dont les vCPU ne tournent pas dans un seul noeud NUMA (non wide),
toucher au cores per socket na normalement pas de consquences mais rien ne permet den tre
certain. Chaque cas ncessite dtre test.
Lobjectif nest pas de tourner en drision les propos de VMware, dans de nombreux cas (rel)
la gestion des fermes VMware changent du tout au tout :

diffrentes gammes de serveurs au sein dune mme ferme


diffrentes gammes de CPU au sein dune mme ferme
parfois les administrateurs VMware privilgient la modification des cores per socket
plutt que le nombre de vSocket (ce qui va lencontre des best practices VMware)
souvent la configuration de la VM dpend plus de ladmin que des standards
dinfrastructure

Pour conclure, dans une entreprise qui a un SI depuis plusieurs annes, une ferme VMware est
en gnral trs htrogne et ce sur plusieurs plans (software, hardware, etc.).

Dans ce genre de contexte, difficile de dterminer lvolution 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 dplacement automatique de la VM sur les hosts qui composent la ferme VMware

vSocket vs cores per socket

Pour vous montrer les consquences de ces paramtrages depuis la machine invite, voici
quelques exemples:
LOS voit 4 processeurs de 1 cur physique (1 thread montre quil ny a pas de HT parce que:
x threads = x curs).
LOS voit 2 sockets de 2 curs physiques.
LOS voit 1 sockets de 4 curs physiques.

Les bonnes pratiques

Dans la littrature, il est recommand de laisser le nombre de core per sockets 1.

Pour de nombreuses raisons (en gnral 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 dterminer la taille des
vNUMA exposs la VM (cf. chapitre suivant)
Pour une non-wide VM, modifier cette configuration peut, dans de rares cas,
amliorer ou dtriorer 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 prsenter au systme invit la topologie NUMA via la
technologie vNUMA. Le terme vNUMA est un terme spcifique VMware.

a a donc pour effet de permettre :

des optimisations NUMA depuis lOS invit


des optimisations NUMA pour le/les application(s) du systme invit

Par dfaut, une VM est considre comme wide VM si :

Le nombre de vCPU vu par la VM est strictement suprieur 8 (chiffre par dfaut dans
la configuration VMware vSphere)
Le nombre de vCPU de la machine invite dpasse le nombre de curs dun nud
NUMA

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

Ce quil faut retenir: Quand une VM est une wide VM, la topologie NUMA est remonte
lOS. On parle alors de vNUMA.

Faire remonter la topologie NUMA au guest

Plusieurs lments de configuration permettent de paramtrer et grer lexposition de la


topologie NUMA lOS de la VM. Ces configurations peuvent se faire par VM ou directement
par host.

Comment vrifier la topologie NUMA remonte


De manire gnrale, sur un OS (ex avec Linux)

Nous lavons vu, la topologie concerne autant les machines physiques que les VMs. Regardons
ici comment afficher les informations lies la topologie NUMA et comment les interprter.

Nous lavons vu, lscpu permet davoir des informations gnriques sur tout ce qui est li aux
processeurs:

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

1 core physique ( curs par socket )


de 1 thread (pas de HT, ligne threads par cur )
1 nud NUMA ( nuds NUMA )
la taille des caches et leur nombre (cf. chapitre prcdent)

On peut obtenir la correspondance et les relations entre ces diffrentes informations avec
loption -p ou -e :

Il faut lire cette sortie comme un tableau double entre. Le cur physique 0 ( core dans le
tableau) appartient au nud NUMA 0 (tout comme le core 1) et est sur la socket 0. Il a un
unique cur logique ( CPU dans le tableau). Aucun des caches ne sont partags (logique
puisque sur des sockets distinctes, rappelez-vous).

Lexemple nest ici pas trs complexe, en voici un autre avec loption -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 curs logiques (CPU) 0 et 12 partagent un certain nombre de choses :

ils sont sur la mme socket (0)


ils sont sur le mme cur physique (0)
ils sont sur le mme nud NUMA (0)
ils partagent les mme caches
o L1i et L1d (vident, ils sont sur le mme cur physique)
o L2 (idem)
o L3 (parce que sur la mme socket)

A propos des caches, on peut voir que le cur logique (CPU) numro 2 nappartient pas au
mme cur physique (core) que les 0 et 12 mais la mme socket. Il na donc pas les mmes
cache L1x/L2 mais le mme cache L3.

La commande numactl hardware permet davoir plus de dtails sur ce qui nous intresse :

La distance ici exprime la latence daccs la mmoire. La configuration de cet exemple tant
simple, voici un autre exemple avec cette fois-ci 8 nuds 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 reprsente un accs local la mmoire (entre les nuds 0 et 0 ou les nuds 1 et
1, etc). les autres des accs en remote.

Vu de la machine invite (VM VMware) : coreinfo

Configuration des machines de linfra 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 mme informations que dans le chapitre prcdent mais sous une autre forme :

la quantit de curs physiques et le mapping par rapport aux curs logiques


la quantit de sockets et le mapping des curs physique par rapport aux sockets
des infos sur les nuds NUMA et les curs physiques associs
des infos sur les caches

Vu du host

La commande vmdumper permet davoir les configurations dune machine allume sur un
ESXi :
On y retrouve nos configurations VMware vSphere :

Mmoire/CPU de la VM
Cores per socket
vSocket
Nuds NUMA
Nous parlerons des autres mtriques dans le chapitre suivant

La commande esxtop permet de sortir des mtriques plus lies la vie de la VM au sein de
lESX :
Les mtriques intressantes :

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 mmoire accde en local par la VM
NMIG : NUMA migration: Nombre de fois que la VM migr dun NUMA un autre

La topologie processeur par VMware vSphere


Les couches

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

Reprenons notre modle de nud NUMA sur un host :

Ajoutons ce modle la couche ajoute par lESX (hyperviseur de VMware).

On retrouve de nouveaux concepts :


NUMA Home Node : Surcouche de lESX qui interprte la topologie NUMA prsente
sur le host
pCPU : pour physical CPU, reprsente un cur physique ou un cur logique dans
lhyperviseur
NUMA Client : ensemble curs/mmoire remont la VM. a ne veut pas forcment
dire que la VM voit la topologie NUMA

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

Dcomposition du vNUMA

Plongeons donc au sein de ce NUMA Client qui nous intresse tant. En le dcomposant, on
retrouve deux choses :

le Physical Proximity Domain (PPD)


o il assure la corrlation entre un pool de vCPU et un pool de cur physique au
sein du mme CPU package
o Cest la garant de la relation suivante :
jassure 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 nest pas du pinning
o il se construit automatiquement partir du nombre de curs physiques prsents
au sein dun CPU Package (sauf si le paramtrage core per socket nest pas
gal 1, dans ce cas, cest ce paramtrage qui dtermine la taille du PPD)
o il est utilis pour le placement initial des vCPU et pour le load-balancing
le Virtual Proximity Domain (VPD)
o il expose la topologie vNUMA la VM
o sa taille dpend du nombre de vCPU et du nombre de curs physiques sur la
machine physique ou du paramtrage core per socket (pour les version ESX
infrieures 6.5)
o Peut reposer sur plusieurs PPDs

Reprenons notre modle et ajoutons les VPDs et les PPDs. Vous trouverez ci-dessous, sous
forme de schmas, 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 recommandes 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 modlisation suivante :
Le VMdumper nous confirme cette modlisation :
On remarque cependant un commentaire intressant : Exposing multicore topology with
cpuid.CoresPerSocket = 8 is suggested for best performance .

Il serait donc intressant, selon VMware, de modifier la configuration cores per socket pour
avoir de meilleurs performances. Ce qui est normal :

Comme vu dans le chapitre prcdent sur les Wides VMs, une VM est
considre comme tant une wide VM si la machine possde plus de 8 vCPU (paramtre
par dfaut)
ou si le nombre de vCPU de la machine invite dpasse le nombre de curs dun
nud NUMA

Ce log est cohrent 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). Its 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 cre 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 modlisation suivante :

Nos PPD sont rpartis sur nos deux nuds NUMA et se composent de lintgralit des
processeurs du host
On trouve autant de VPDs que de PPDs et ceux ci se composent dautant de cores que
ces derniers

Bref, tout est bien align On voit qua travers cette configuration le travail du CPU Scheduler
sen retrouve simplifi. Vous aurez le temps de vous en rendre compte en jetant un il aux

modlisations suivantes

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

Prenons lexemple de llve qui tout compris de travers et qui a toujours modifi le nombre
de cores per socket plutt que le nombre de vSocket.

Configuration de notre nouvelle VM:


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

La modlisation associe :

un VPD de 12 curs et rparti sur deux PPDs


deux PPDs de 6 curs rpartis sur les deux nuds NUMA

On sent que a va bien se passer

On a donc une VM dont lOS va voir un nud NUMA au lieu de deux. La mmoire va vite se
retrouver rpartie entre les deux NHN (NUMA Home Node) et des accs en remote vont
apparaitre. Le travaille du CPU scheduler au sein de lESXi va sen trouver affect et on peut
sattendre beaucoup de context switch.

Prenons maintenant llve qui a compris peu prs la moiti de tous les concepts et qui, pour
se rassurer, va donc tout mlanger.

Configuration de notre nouvelle VM :

cores per socket: 2


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

La modlisation associe :

six VPDs de 2 curs


six PPDs de 2 curs

Un carnage, la VM va voir une topologie de six nuds NUMA au lieu des deux qui existent
rellement. Au niveau de lESXi, le CPU scheduler va devoir scheduler 6 PPD au lieu de 2.
LOS quant lui va tre amen faire beaucoup plus doptimisations que ncessaire et qui, au
final, nen seront pas.

Tous ces exemples montrent bien limpacte de loption cores per socket sur la taille des
VPDs/PPDs et toutes les horreurs associes si lon ne fait pas attention.

Larticle Does corespersocket Affect Performance publi sur le blog de VMware appuie ces
thories.

Faut-il le rpter ? Le plus simple reste tout de mme de faire en sorte de noccuper quun seul
nud NUMA. Pourquoi ? Tout simplement parce que le travail de lOS de la VM et de lESXi
vont sen trouver simplifis. Comment faire si la quantit de vCPU de la VM dpasse le nombre
de curs dun nud NUMA ? (Je pars ici du principe que la quantit de RAM souhaite sur la
VM soit infrieur la quantit de RAM du nud NUMA.)

Cest l que loption PerferHT entre en jeux. Pour rappel, cette option va faire en sorte que les
curs 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 modlisation associe :

un VPD de 12 curs
un PPD de 10 curs
Au final notre VM, mme si elle a plus de vCPU que de curs physiques sur notre nud
NUMA, tient au sein dun mme NUMA Home Node. Attention cependant, il faut avoir en tte
que ce sont des curs logiques (HyperThreading ici) qui vont tre utiliss. En fonction de
lapplicatif de la VM cela peut dgrader ou amliorer les performances.

Et si on validait cela avec un vrai benchmark ?

Pour valider ces diffrentes configurations et les thories associes, enioka prpare un
benchmark qui prendra en compte :

les config CPU (dans un contexte de stress sur lhost ou non)


lapplicatif sur la VM (workload court et long)
dautres technologies de virtualisation

Ds que ce benchmark sera ralis, un compte rendu sera fait dans ce blog.

Les nouveauts (vSphere 6.5)

vSphere 6.5 permet de rattraper beaucoup de btises, en particulier, pour la topologie vNUMA
:

Loption cores per socket est dcouple 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 paramtre 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 paramtres prendre en compte et deux bonnes
questions se poser :

Ai-je vraiment besoin de ce niveau de performance ?


Ai-je vraiment vraiment besoin dautant de vCPU ?

Diagramme de choix

Si la rponse ses deux questions est oui , vous pouvez-vous aider de ce diagramme de
choix pour dterminer la configuration CPU faire sur votre VM.

Faites tout de mme attention, ce diagramme na pas la prtention de vous donner coup sr la
bonne configuration pour votre VM et surtout il ne remplace en rien des tests de performance
et dintgration. Il est peut probable que votre VM soit seule au monde, mais plutt ajoute au
sein dune 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 diffrentes et donc avec des topologies NUMA diffrentes. Les impacts peuvent tre
trs visibles si le DRS en mode automatique est activ.

Webo/Biblio/Humanographie
Le Web:
o http://frankdenneman.nl (architecte CPU VMware) : pour ses articles
NUMA Deep Dive
o http://www.exitthefastlane.com/ : vSphere Design for NUMA Architecture
and Alignment
o http://kendrickcoleman.com/ : vSphere 5 Hardware Version 8 & New vCPU
Config for Licensing Trickery
o https://blogs.vmware.com/ (euh oui mais non) : Does corespersocket Affect
Performance?
o http://superuser.com/ : Pour les explications sur les caches processeur
Les livres :
o The CPU scheduler in VMware vSphere 5.1 : pour les impacts du NUMA
alignment
o VMware vSphere Performance : Designing CPU, Memory, Storage, and
Networking for Performance-Intensive Workloads. Pour les lments de
configuration et plus tard pour le CPU scheduling
Et les hommes :
o Gael Lalleman : pour nos discussions passionnes sur le sujet

Lexique
vCenter : API et IHM qui permet doprer 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 installe ESXi et qui hberge les VMs cres
Guest: Une VM qui repose sur un host
NUMA: Non Unified Memory Access, architecture rpartissant la mmoire physique
par ensemble de curs processeurs
Hyperthreading: Technologie Intel (HyperTransport chez AMD) permettant de
prsenter deux curs logique partir dun cur physique
Socket: Connexion physique dun processeur la carte mre (HW)
vCPU: Virtual CPU, le matriel prsent la machine virtuelle
Wide VM : Une VM dont la topologie NUMA lui est remonte par la technologie
vNUMA
PPD: Physical Proximity Domain, pool de curs physiques associs un CPU package
VPD: Virtual Proximity Domain, (ensemble de) pool(s) de curs logiques/physiques
associ(s) un ou plusieurs PPD
pCPU: Physical CPU vu par lESX (peut-tre associe un processeur logique ou
physique)
vSocket: Virtual Socket (vu par la VM comme une socket physique)
core/coeur physique: processeur physique intgr une socket physique
core/coeur logique: processeur logique sexcutant sur un processeur physique

Pour aller plus loin


Des articles complmentaires sont en cours de rdaction pour prolonger la rflexion :

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


valider/rfuter les thories avances ci-dessus en fonction des contextes et des
paramtrages) venir
VMware CPU Scheduling: fonctionnement et principes venir
Virtualisation des CPU venir

Vous aimerez peut-être aussi