L’architecture NUMA est sans doute un des concepts que j’ai le plus souvent expliquer à mes clients, j’ai donc décidé d’en faire maintenant un article pour pouvoir y référer directement .
Comment fonctionne le scheduler NUMA d’un ESXi ?
A la mise sous tension d’une VM, le scheduler NUMA assigne la VM à un nœud. Lorsque de la mémoire est allouée à cette VM, l’ESXi l’alloue depuis ce même nœud pour optimiser les performances d’accès.
Lorsque la VM est assignée à un nœud, le scheduler peut la déplacée sur un autre nœud si des contentions sont détectées.
Le client NUMA
L’ESXi groupe les vCPUs et la mémoire dans des unités logiques appelées « clients NUMA ».
C’est donc le client NUMA qui est ensuite placé dans un nœud. Lorsqu’une VM présente des caractéristiques CPU et mémoire inférieures ou égales à la taille d’un nœud NUMA, alors la VM est égale à un client.
Et les Monster VMs ?
Dans le cas où une VM possède plus de vCPUs que le nombre de cœurs dans un nœud NUMA, elle est alors découpée en plusieurs clients NUMA qui seront répartis entre les différents nœuds. On parle alors de « Wide VM »
Prenons le cas d’une VM avec 10 vCPUs, sur un ESXi avec 2 sockets de 8 cœurs chacun (l’hyperthreading n’est pas pris en compte, seuls les cœurs physique servent à déterminer les clients NUMA). La VM va être automatiquement découpée en 2 clients NUMA de 5 vCPU chacun.
Concernant les vSockets, la recommandation de VMware est de toujours laisser le paramètre de Coeur/Socket = 1, ainsi la construction des clients NUMA est facilité pour vSphere.
Si toutefois, pour des raisons de licensing principalement, le nombre de sockets est un problème, il faut bien veiller à respecter l’architecture physique des noeudes NUMA dans le dimensionnement.
Depuis l’exemple ci dessus, si je souhaite passer à seulement deux sockets, il faudra spécifier un nombre de 5 coeurs/sockets pour arriver à ceci :
Considérations mémoire
Seuls les vCPUs comptent dans la création automatique des clients NUMA, que se passe t-il si mo client NUMA à plus de mémoire que son nœud ?
Et bien la VM sera obligée d’accéder à la mémoire d’un autre nœud du même serveur en utilisant « Remote Memory Access«
Pour des applications à forte utilisation de la mémoire, la latence induite par ce mécanisme peut devenir problématique, il faut alors forcer la construction des clients NUMA pour correspondre à l’architecture physique, pour cela il faut éditer directement le fichier .vmx de la VM et définir le paramètre numa.vcpu.maxPerMachineNode
Dans l’exemple ci-dessus, il convient de créer 2 clients NUMA de chacun 96GB de mémoire , pour cela, on force la répartition des 8 vCPUs en 2 sockets de 4 coeurs : numa.vcpu.maxPerMachineNode = 4
