VMware – Best Practices Numa / vNuma

Synopsis

Je me lance aujourd’hui dans un nouveau type de post style « Best Practice » sur Numa & vNuma, il vont permettre de comprendre en détail une fonctionnalité et ainsi éviter des erreurs liées au design, au choix du matériel voir de débattre.

Pour cette nouvelle aventure de virtualisation je débute avec Numa et vNuma, histoire d’éclaircir les interrogations sur ce mot barbare.

Définition

Numa pour Non-Uniform Memory Access est une architecture matérielle, c’est-à-dire que le serveur physique ou plus particulièrement la liaison physique entre la RAM et le CPU qui a évoluée.

Avant cette évolution, la liaison était généralement de type UMA (Uniform Memory Access), c’est une architecture mémoire partagée entre les multiples CPU du serveur physique via un contrôleur mémoire (MCH), il y a donc des limitations d’évolution, de bande passante et de latences.

uma

frankdenneman.nl

Pour pallier à ces facteurs limitants, les ingénieurs ont fait évoluer le hardware vers une du Numa, ils ont ainsi supprimé la topologie centralisée via contrôleur mémoire.

En Numa la mémoire est directement liée à son CPU, on se retrouve ainsi avec une mémoire dite « Local » et « Remote » pour celle liée à un autre CPU.

Vous l’aurez compris, la mémoire dite « Local » sera la plus performante, l’utilisation de la mémoire « Remote » obligeant l’utilisation du pont d’interconnexion entre les CPU.

numa

frankdenneman.nl

L’architecture physique évoluant, les ingénieurs VMware se sont ainsi adapté et l’ESXi est devenu Numa Aware, pour ainsi se rendre compte de cette architecture et l’utiliser le mieux possible.

vNuma se résumé au Numa Aware mais coté VM, cela permet au Guest OS d’être conscient qu’il se trouve sur une architecture Numa et ainsi gérer au mieux sa répartition de RAM.

Avec la plupart des CPU on peut corréler 1 CPU = X Cores Physique = 1 Numa Node.

Toutefois certains CPU « 12-cores » sont deux « 6-cores » aggrégés, ce qui engendre deux Numa Nodes sur un seul CPU : 1 CPU = 2x X Cores Physique = 2 Numa Nodes.

On se retrouve donc à dire Cores physique par Numa Nodes pour être précis…

Scheduler NUMA

Au démarrage d’une VM, si celle-ci à un nombre de vCPU plus petit ou égal au nombre de Cores d’un node, le Numa Scheduler va assigner un node par défaut et lui assigner le plus possible de mémoire locale. En revanche si le nombre de vCPU dépasse (Wide-VM), elle va être séparée sur plusieurs nodes avec un risque d’avoir du remote.

Cependant il peut arriver dans certains cas comme un grand nombre de VM, qu’il ne soit pas possible de mettre tout en local. Dans le cas où plus de 20% est en remote, le scheduler va essayer de changer de Numa Node pour améliorer le ratio. La gestion Numa est donc complètement automatisée, par contre dans le cas où l’administrateur souhaite gérer en manuel il y a l’option avancée numa.nodeAffinity.

Quand vous spécifiez une « Numa Node Affinity », le scheduler Numa est toujours en charge de la gestion de localité, par contre avec une affinité CPU ce n’est pas le cas, d’ailleurs je vous déconseille fortement d’en mettre…

numa_affinity

ESXTOP

Cas pratique avec un ESXTOP, on se place en affichage Mémoire (m), on modifie les champs (f) pour choisir le Nom (d) et les Stats Numa (g) puis on passe en affichage VM (V)

esxtop_fields

On se retrouve donc avec deux Numa Nodes (Rouge), ayant 2 CPU et 524GB. Le split est bon avec environ 262GB de RAM par Node.

esxtop_numa

Dans mon cas j’ai deux VM, la première utilisant le Numa Node 0 (NHN) et 98% en local (N%L) soit 95.36MB en Remote (NRMEM). La deuxième quand a elle est parfaitement bien séparée entre les deux Numa Nodes et utilise 100% en Local, donc 50% sur le CPU0 et 50% sur le CPU1.

vNuma

vNuma est très utile si vous utilisez des Wide-VM, il va permettre de mitiger les latences mémoire en prenant part dans la gestion Numa de l’ESXi, son utilisation requière au minimum la VM Version 8 et 8 vCPU (Par défaut).

La topologie vNuma affichée à la VM est set au premier démarrage et ne change pas jusqu’à modification du nombre de vCPU, voilà pourquoi il est conseillé d’avoir des hosts dans le cluster ayant la même topologie Numa,  les performances ne seront donc pas dégradées suite à un vMotion.

Advanced Settings

Vous pouvez être amené à vouloir spliter une VM sur plusieurs Numa Nodes, si vous souhaitez privilégier la bande passante à la latence il peut être utile de limiter le nombre de vCPU par node.

maxPerMachineNode

Sur des serveurs utilisant l’HyperThreading avec des VM configurés avec plus de vCPU que de Core Numa mais moins que de Cores logique, il peut être bénéfique d’utiliser le core logique avec mémoire local que physique avec mémoire remote.

numa.vcpu.preferHT

vNuma est activé de base pour les VM de plus de 8 vCPU, il peut être utile de revoir cette valeur à la baisse sur des serveur ayant des CPU de moins de 8 Cores physique.

numa.vcpu.min

Design VM

Essayez de sizer vos VMs pour qu’elles s’alignent sur Numa, c’est-à-dire qu’avec un host de 6 Cores physique on va utiliser des multiple de 6 (6, 12, 18, 24 … vCPU)

Quand vous choisissez le nombre de vCPU d’une VM, vous avez le choix entre nombre de Sockets et de Cores. A part pour des raison de licensing, il est fortement conseillé d’utiliser seulement les Sockets et de laisser les Cores à 1.

Il a été prouvé que les performances sont dégradés, surtout dans le cas de Wide-VM. Dans ce cas essayez de déterminer la configuration que vNuma aurait associé à votre VM.

Ex. VM de 16 vCPU sur un serveur de CPUs ayant 10 Cores physique, 2 Sockets & 8 Cores est le plus logique dans ce cas.

Optimisation RAM

En construction, grosse partie à venir …

Le dernier point concernant Numa est la gestion de la RAM au niveau des slots physique.

Quand on parle de modules RAM, il faut prendre en compte deux aspects, la latence et la bande passante qui sont impactés suivant la topologie choisie entre Fréquence, Quantité, Régions et Canaux.

Ce qu’il faut prendre en compte est que plus il y a de DIMM par canal, plus la fréquence diminue et plus la latence augmente. Pour des raisons de scalabilité, blinder de RAM le serveur n’est pas non plus une bonne idée, voilà pourquoi il vaut mieux partir sur un serveur à moitié remplis avec de plus grosses barrettes qu’un full avec des petites.

DIMM Type 1 DPC 2 DPC 3 DPC
1R RDIMM 2133 MHz 1866 MHz 1600 MHz

Conseils

  • Utiliser/configurer vNUMA pour les Wide-VM.
  • Sizer les Wide-VM pour s’aligner sur Numa.
  • Améliorer la répartition des modules RAM.
  • Utiliser le plus possible les Sockets et non les Cores (vCPU)
  • Utiliser ESXTOP, mais ça vous le savez déjà …

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-perfbest-practices-vsphere6-0-white-paper.pdf

http://frankdenneman.nl/2015/02/18/memory-configuration-scalability-blog-series/

https://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsphere.doc/GUID-1B959D6B-41CA-4E23-A7DB-E9165D5A0E80.html

 



...BofBienTrès BienTop ! 1 vote(s)
Loading...

Mathieu

Je suis actuellement Ingénieur Système spécialisé dans le design d'environnements cloud virtualisés. Adepte des technologies de VMware, Nutanix, Citrix ou Microsoft je propose à travers ce blog diverses astuces de troubleshooting.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *