Différence entre UMA, NUMA et vNUMA
Cet article a pour but d’expliquer la différence entre trois types d’architecture serveur.
UMA (architecture précédent NUMA), NUMA et vNUMA. D’autres architectures auraient pu être traitées dans ce post, telles que hUMA, qui est une architecture UMA hétérogène, ou bien COMA qui est une architecture de mémoire cache, mais ce n’est pas l’objet de cet article.
Architecture UMA
UMA, (Uniform Memory Access), est une ancienne architecture de serveur. Celle-ci n’est plus d’actualité. La raison est simple : le contrôleur de mémoire est rapidement devenu un goulot d’étranglement. Il est facile de comprendre pourquoi, car chaque CPU demandant de la mémoire ou des I/O, devait passer par cette couche.
En fait, dans une architecture UMA, le temps d’accès à un emplacement mémoire est indépendant du processeur qui effectue la requête, car tous les processeurs du modèle UMA partagent la mémoire physique de manière uniforme.
L’arrivée de l’architecture NUMA a changé ce process.
Architecture NUMA
NUMA s’éloigne d’un pool de mémoire centralisé et a introduit un nouveau concept. En classant les emplacements de mémoire en fonction de la longueur du chemin du signal entre le processeur et la mémoire, les goulots d’étranglement au niveau de la latence et de la bande passante ont pu être évités. Pour cela, il a fallu repenser l’ensemble du système de processeur et de chipset. Les architectures NUMA ont gagné en popularité à lorsqu’elles ont été utilisées sur des supercalculateurs. Pour ce type de système, NUMA a permis à identifier l'emplacement de la mémoire.
AMD a introduit le concept NUMA dans les environnements d’entreprise, où l’on ne trouvait pratiquement que des systèmes UMA.
Les processeurs AMD Opteron ont été introduits en 2003, avec des contrôleurs de mémoire intégrés avec chaque CPU possédant ses propres canaux de mémoire dédiés. Chaque CPU a maintenant son propre espace d’adressage mémoire. Un système d’exploitation optimisé NUMA tel qu’ESXi permet au workload de consommer de la mémoire à partir des deux espaces d’adresses mémoire tout en optimisant l’accès à la mémoire locale.
Exemple d’accès mémoire local et distant, d’un serveur composé de deux processeurs :
La mémoire connectée au contrôleur de mémoire du CPU 0 est considérée comme une mémoire locale. La mémoire connectée à un autre socket CPU (CPU1) est considérée comme étrangère ou distante pour CPU 0. L’accès à la mémoire à distance a une surcharge de latence supplémentaire par rapport à l’accès à la mémoire locale, car il doit traverser une interconnexion (liaison point à point) et se connecter au contrôleur de mémoire distant. En raison des différents emplacements de mémoire, ce système subit un temps d’accès à la mémoire « non uniforme ».
Comportement SANS VNUMA
Dans cet exemple, une machine virtuelle avec 12 vCPU s’exécute sur un hôte avec quatre nœuds NUMA contenant six cœurs chacun. Cette machine virtuelle n’est pas présentée avec la configuration NUMA physique et, par conséquent, le système guest OS et l’application ne voient qu’un seul nœud NUMA. Cela signifie que la machine guest n’a aucune chance de placer des processus et de la mémoire dans un nœud NUMA physique.
Il y a donc un mauvais emplacement mémoire.
Comportement AVEC vNUMA
Depuis la version 5 de vSphere, ESXi dispose de la fonction vNUMA (NUMA virtuel) qui peut présenter plusieurs nœuds NUMA au à un guest OS. Jusque-là, les machines virtuelles étaient présentées qu’avec un seul nœud NUMA, quelle que soit la taille de la machine virtuelle et son matériel sous-jacent. Des workloads de plus en plus importants sont virtualisés, il est donc de plus en plus important que le guest OS et les applications puissent prendre des décisions sur l'emplacement d’exécution des applications et l'emplacement de la mémoire.
VMware ESXi prend en charge NUMA et essaie toujours d’adapter une machine virtuelle dans un seul nœud NUMA physique lorsque c’est possible. Cependant, avec des « monsters VMs », ce n’est pas toujours possible.
Si nous prenons l’exemple d’une machine virtuelle avec 12 processeurs virtuels s’exécute sur un hôte qui possède quatre nœuds NUMA avec six cœurs chacun, cette machine virtuelle est présentée avec la configuration NUMA physique et, par conséquent, le guest OS et l’application voient deux nœuds NUMA. Cela signifie que le guest OS peut placer les processus et la mémoire associée dans un nœud NUMA physique lorsque c’est possible.
Nous avons donc un bon emplacement de mémoire.
Nous traiterons du dimensionnement de vNUMA, dans l’article suivant.
