VMWare vSphere und vNUMA Nodes
Gerade im Bereich von virtualisierten High-Performance Applikationen kann die korrekte Konfiguration von NUMA Nodes eine entscheidende Rolle spielen und bei einer fehlerhaften Verteilung einen Performanceverlust bedeuten. In diesem Artikel möchte ich auf die Grundsätze einer NUMA Node eingehen und aufzuzeigen, welche Punkte in einer virtualisierten Serverinfrastruktur beachtet werden müssen, damit eine optimale Konfiguration gewährleistet werden kann.
Was sind NUMA Nodes?
Allgemein
Bevor wir uns tiefer mit der richtigen Skalierung einer virtuellen Maschine beschäftigen, sollten wir die Frage klären, was NUMA überhaupt ist. NUMA steht für Non-Uniform Memory Access und kommt bei Systemen zum Einsatz, die über mehrere Sockets und somit auch mehrere Prozessoren verfügen. Jeder Prozessor verfügt physisch am Motherboard eigenen, lokalen Arbeitsspeicher bei welchem die Zugriffszeiten und somit auch die Latenzen sehr gering sind – eine solche Konstellation aus CPU und lokalem RAM nennt man einen NUMA Node.
Das bedeutet allerdings nicht, dass der Prozessor ausschließlich auf seinen eigenen, lokalen Arbeitsspeicher zugreifen darf. Denn beide Systeme sind über einen Highspeed Interconnect Bus miteinander verbunden und können so auch auf den RAM des jeweils anderen Prozessor problemlos zugreifen. Folgende Grafik illustriert den Aufbau eines solchen zwei Sockets Servers.
Auch wenn beide NUMA Nodes mittels eines Highspeed Interconnect Buses verbunden sind, ist ein sogenannter „remote access“ immer bedeutend langsamer, als ein direkter Zugriff auf den lokalen Arbeitsspeicher. Diese erhöhte Latenz wirkt sich negativ auf High-Performance Applikationen wie zum Beispiel eines MSSQL aus. Somit sollten wir aus Sicht der Performanceoptimierung sicherstellen, dass ein „remote access“ nur dann stattfindet, wenn es unvermeitbar ist.
Praxisbeispiel
Zur besseren Veranschaulichung ein vereinfachtes Praxisbeispiel: Man stelle sich einen herkömmlichen Dell PowerEdge Server mit 2 CPUs (jeweils 16 Cores) und insgesamt 256GB RAM vor. Bei gleichmäßiger DIMM Installation verfügt jeder Prozessor dabei über insgesamt 128GB lokalen Arbeitsspeicher. Wie vorhin besprochen besteht diese Plattform daher aus 2 NUMA Nodes*.
Installiert man darauf als OS Windows Server, würde das Betriebssystem (da es NUMA Aware ist) erkennen, dass der Host 2 NUMA Nodes bereitstellt und die Speicherzuweisung dementsprechend intelligent aufteilen. Somit wäre sichergestellt, dass das Betriebssystem und die darauf laufenden Applikationen optimale Latenzen in Bezug auf RAM-Zugriffe hätte.
*Ich möchte an dieser Stelle noch erwähnen, dass manche Hersteller ggf. Optionen im BIOS anbieten, die die Anzahl der NUMA Nodes je nach Bedarf erhöhen lassen. Da dies allerdings nicht der Standard ist und ich das Beispiel sehr einfach darstellen möchte, lasse ich diese Option weg.
Doch wie sieht die NUMA Konfiguration aus, wenn der Host mittels VMWare virtualisiert wurde und virtuelle Maschinen darauf betrieben werden? Genau dieser Frage widmen wir uns im nächsten Kapitel.
VMWare und vNUMA Nodes
Allgemein
Als führender Anbieter für virtualisierte Serverinfrastrukturen hat VMWare dafür eine Lösung namens vNUMA parat, die mit einigen kleineren Stolpersteinen sehr gut funktioniert. Als Architekt einer solchen virtualisierten Infrastruktur sollte man diese Stolpersteine kennen und in die Planung mit einbeziehen.
VMWare vSphere ab Version 5.0 stellt dem Gastbetriebssystem virtuelle NUMA Nodes (vNUMA) zur Verfügung und übernimmt damit bereits die optimale Bereitstellung auf physischer Seite. Dieses Feature wird automatisch aktiviert, wenn für die virtuelle Maschine folgende Bedingungen zutreffen:
- Sie besitzt 9 oder mehr vCPUs
- Die gesetzten vCPUs der VM übersteigt der Anzahl der Cores der physischen NUMA Node
- CPU Hotplug für die VM ist deaktiviert
Das für die VM konfigurierte vCPUs / Sockets Verhältnis spielt für die vNUMA Bereitstellung übrigens keine direkte Rolle mehr (ab ESXi 6.5). Als Grundregel versucht vSphere dabei die größtmögliche Anzahl an vCPUs in die kleinstmögliche Anzahl an NUMA Nodes zu packen.
vNUMA Bereitstellung & Kalkulation
Schauen wir uns einmal an, anhand welcher Metriken vSphere die optimale vNUMA Bereitstellung berechnet. Als primäre und wichtigste Metriken werden der vCPU Count der VM und die Anzahl der Cores einer NUMA Node herangezogen. Der zugewiesene Arbeitsspeicher spielt keine Rolle, was unter umständen zu Problemen führen kann. Zum besseren Verständnis bleiben wir bei unserem oben genannten Praxisbeispiel:
- Server: Dell PowerEdge
- CPUs: 2 CPUs mit jeweils 16 Kerne
- NUMA: insgesamt 2 NUMA Nodes
- RAM: 128GB pro Prozessor (256GB insgesamt)
Wir möchten nun verschiedene virtuelle Maschinen auf diesem Hypervisor bereitstellen:
| vCPUs | vRAM | automatische vNUMA Nodes |
optimale vNUMA Nodes |
| 8 | 24GB | 1 | 1 |
| 32 | 48GB | 2 | 2 |
| 32 | 256GB | 2 | 2 |
| 16 | 256GB | 1 | 2 |
Übersteigen die gesetzten vCPUs der VM die Anzahl der Cores der physischen NUMA Node, so werden dem Gastbetriebssystem automatisch zwei vNUMA Nodes bereitgestellt. Übersteigt der zugewiesene Arbeitsspeicher diesen Wert, zeigt die automatisierte vNUMA Konfiguration allerdings erste Nachteile auf, denn obwohl die optimale vNUMA Verteilung zwei wäre, wird dem OS nur eine bereitgestellt.
Ein wichtiger Fakt, der hier unbedingt erwähnt werden muss, ist, dass das Aktivieren von CPU Hotplug diesen Automatismus vollständig deaktiviert. Sobald die virtuelle Maschine CPU Hotplug aktiv hat, wird dem Gastbetriebssystem immer nur eine vNUMA Node zugewiesen und die Latenz auf den Speicherzugriff kann entsprechend höher sein. Daher sollte dieses Feature vor allem bei VMs deaktiviert werden, die optimalerweise aufgrund der vCPU oder vRAM Zuweisung auf mehreren, physikalischen NUMA Nodes laufen soll. Bei kleinen VMs, die ohnehin nur eine vNUMA Node benötigen, spielt dies allerdings aus Sicht der Performance keine Rolle.
Performanceimpact von vNUMA Nodes
Da dieses Kapitel durchaus sehr umfangreich ist, gibt es dazu einen eigenen Blogpost. Siehe dazu: VMWare ESXi Performanceimpact von CPU Hotplug.
Guidelines für optimale vNUMA Konfiguration
Aus den oben genannten Automatismen und Problemen ergeben sich folgende Guidelines für die optimale vNUMA Konfiguration des Gastbetriebssystems:
- CPU Hotplug hebelt die automatische Konfiguration von vNUMA Nodes aus und sollte daher standardmäßig deaktiviert sein
- Das Verhältnis zwischen Cores / Sockets spielt aus Sicht von vSphere ab ESXi Version 6.5 für vNUMA keine Rolle mehr. Es kann allerdings sehr wohl eine Rolle für die Applikation oder Lizenzierung jener spielen. Wird ESXi 6.0 verwendet, muss auf das korrekte Verhältnis zwischen Cores / Sockets geachtet werden.
- Es sollte keine ungerade Anzahl an vCPUs gesetzt werden, wenn die VM auf mehrere vNUMA Nodes zurückgreifen muss
- Sollte die VM mehr Arbeitsspeicher besitzen als eine NUMA Node physisch bereitstellen kann, kann es sinnvoll sein, die automatische vNUMA Konfiguration durch manuell gesetzte Werte auszuhebeln. Siehe dazu die Advanced vNUMA Attributes.
