NUMA und Dynamic Memory in Hyper-V konfigurieren

    Ein unausgewogenes NUMA-System kostet PerformanceSeit Windows Server 2008 R2 SP1 ermöglicht Hyper-V die dynamische Zuweisung von Arbeitsspeicher zu VMs, um eine höhere Dichte an virtuellen Maschinen pro Host zu erzielen. Parallel dazu unterstützt der Microsoft-Hypervisor NUMA, wobei der Support dafür in Windows Server 2012 deutlich erweitert wurde. Die meisten neuen Server implementieren NUMA, um die Performance des Systems zu verbessern. Im Zusammenspiel mit einem ungünstig konfigurierten dynamischen RAM kann NUMA aber auch das Gegenteil bewirken.

    Beim Non-Uniform Memory Access (NUMA) handelt es sich um ein Hardware-Konzept für Multi-Prozessor-Systeme, das jeder CPU einen eigenen Bereich des Arbeitsspeichers (in Form von Speicherbänken) zuordnet. Der Zugriff auf dieses lokale RAM kann schneller erfolgen als auf ein solches, das sich bei UMA (Uniform Memory Access) mehrere Prozessoren teilen müssen.

    Bremsende Zugriffe auf andere NUMA-Knoten

    Wenn aber die Anwendungen, die auf einer bestimmten CPU ausgeführt werden, nicht mit dem dort zur Verfügung stehenden RAM auskommen, dann darf der Prozessor auch Arbeitsspeicher in Beschlag nehmen, der eigentlich anderen CPUs zugeteilt ist. Allerdings führt dieser Ausflug in Nachbars Garten zu Performance-Einbußen.

    Während vor nicht allzu langer Zeit NUMA noch ein Feature von Highend-SMP-Systemen war, wird es mittlerweile dank Multi-Core-CPUs von den meisten neuen Servern unterstützt. Unter Umständen muss man es erst im BIOS aktivieren.

    Geändert hat sich zudem, dass nicht nur einige leistungshungrige Anwendungen wie SQL-Server für NUMA entwickelt wurden und die Vorteile dieser Architektur in Anspruch nehmen können. Vielmehr ist es in Zeiten der x86-Virtualisierung nun besonders der Hypervisor, der Arbeitslasten in Form von virtuellen Maschinen so zwischen den Prozessoren verteilen muss, dass der Zugriff auf das lokale RAM anderer CPUs vermieden wird.

    Ausbalanciertes NUMA-System zusammenstellen

    Diese Aufgabe fällt ihm natürlich leichter, wenn die virtuellen Maschinen mit einer festen Menge an Arbeitsspeicher versehen sind. Aber selbst bei einer solchen statischen Konfiguration ist es nicht ganz trivial, den Rechner so auszustatten, dass das Verhältnis zwischen der Zahl der Prozessoren und der Menge des Arbeitsspeichers ausgewogen ist.

    Auf den ersten Blick scheint die Rechnung einfach: Zu jedem NUMA-Knoten gehört ein CPU-Kern, so dass man den verfügbaren Arbeitsspeicher nur durch die Zahl der Cores teilen muss, um herauszufinden, wie viel RAM ihm zugeteilt sind. Im Fall eines Servers mit zwei 4-Core-CPUs und 64 GB RAM entfielen auf jeden NUMA-Knoten 64/8, also 8 GB Arbeitsspeicher. Damit stünde auch jeder VM, die auf einem Prozessorkern ausgeführt wird, genau diese Menge an RAM zur Verfügung.

    Nicht immer 1 Core pro NUMA-Knoten

    In der Realität sind die Verhältnisse nicht so einfach. Das beginnt damit, dass bei der Konfiguration von VMs logische CPUs zugeteilt werden, die bei modernen Systemen mit Support für Hyperthreading nicht identisch mit einem CPU-Kern sind. Vielmehr repräsentiert dann ein Core zwei logische Prozessoren.

    Würden die Hardware-Hersteller die NUMA-Knoten auf einen Thread herunterbrechen, dann wären das im Fall einer 2-Wege-Maschine mit 6-Core-CPUs gleich 24 Knoten. Dies würde die Konfiguration unnötig verkomplizieren, so dass bei den neuesten Prozessoren die Grenzen zwischen NUMA-Knoten oft anders verlaufen, beispielsweise indem mehrere Cores zusammengefasst werden. Daher hilft letztlich nur, dass man mit Tools wie Sysinternals Coreinfo das tatsächliche Design des Rechners überprüft.

    NUMA-Spanning konfigurieren

    Hat man auf dieser Basis die passende Hardware-Konfiguration für die geplanten Workloads zusammengestellt und weiß über die Speicherausstattung der NUMA-Knoten Bescheid, dann kann man anschließend Hyper-V entsprechend einrichten. Microsoft unterstützt auch schon in Windows Server 2008 R2 NUMA, indem der Hypervisor versucht, VMs so zu verteilen, dass die CPUs möglichst wenig auf den Arbeitsspeicher anderer Knoten zugreifen müssen. Es liegt auf der Hand, dass man dieses Bestreben nicht dadurch konterkarieren soll, indem man einer VM mehr RAM zuweist als ein NUMA-Knoten auf dieser Maschine besitzt.

    Auf der Ebene des Hyper-V-Hosts kann man bestimmen, ob VMs auf mehrere NUMA-Knoten verteilt werden dürfen.

    In das Verhalten von Hyper-V kann man dabei eingreifen, indem man das so genannte NUMA Spanning zulässt oder unterbindet. Auf diese Weise legt man fest, ob Prozessoren auf das lokale RAM anderer CPUs zugreifen dürfen. Diese Einstellung erfolgt pro Host und findet sich im Hyper-V Manager im Kontextmenü eines Servers unter Hyper-V Einstellungen => Aufteilung auf NUMA zulassen. Verweigert man dem Hypervisor das Aufteilen von VMs über mehrere Knoten, dann kommt dies der Performance der VMs zugute - vorausgesetzt, die sind ausreichend dimensioniert. Der Nachteil dieser Entscheidung besteht darin, dass weniger VMs pro Host untergebracht werden.

    Dynamic Memory als Störfaktor für NUMA

    Umgekehrt dient gerade die mit Windows Server 2008 R2 SP1 eingeführte dynamische Zuteilung von RAM zu VMs dazu, den vorhandenen physikalischen Arbeitsspeicher optimal zwischen den virtuellen Maschinen aufzuteilen. Man definiert dabei pro VM eine Mindestmenge an Arbeitsspeicher, den sie beim Start erhält und die nie unterschritten wird (Start-RAM). Gleichzeitig legt man eine Obergrenze fest, bis zu der eine VM bei Bedarf zusätzlichen Speicher anfordern kann. Darüber hinaus kann man die VMs in Bezug auf ihre Speicherforderungen priorisieren, so dass solche mit wichtigen Workloads bei RAM-Knappheit bevorzugt werden.

    Es liegt auf der Hand, dass die Gefahr für Konflikte mit der NUMA-Konfiguration steigt, je mehr Spielräume man den VMs bei der dynamischen Speicherzuteilung einräumt. Durch die laufende Veränderung des RAM-Konsums nimmt die Wahrscheinlichkeit zu, dass Prozessoren auf den Speicher eines anderen Knotens zugreifen müssen und dadurch die Performance leidet. Hat man das NUMA-Spanning deaktiviert, dann droht den VMs in dieser Situation ein Speicherengpass.

    Performance versus VM-Dichte

    Bei der Konfiguration der VMs auf NUMA-Maschinen muss man daher abwägen, ob die Performance oder die optimale Auslastung des Hosts im Vordergrund steht. Daher empfiehlt es sich, VMs mit kritischen und anspruchsvollen Anwendungen auf NUMA-Maschinen ohne Dynamic Memory zu definieren und das RAM statisch festzulegen. Überhaupt sollte die flexible Zuweisung von Arbeitsspeicher auf die VMs beschränkt bleiben, die davon tatsächlich profitieren können.

    Virtual NUMA in Windows Server 2012

    Während in Windows Server 2008 R2 der Hypervisor die Vorteile der NUMA-Architektur nutzen kann, sieht ein Gastsystem innerhalb der VMs immer nur eine UMA-Konfiguration. Anwendungen, die für NUMA optimiert wurden, beispielsweise SQL Server oder die aktuelle Version der Internet Information Services (IIS), können daher unter Hyper-V diese Fähigkeiten nicht ausspielen.

    Windows Server 2012 präsentiert den Gästen in den VMs eine virtuelle NUMA-Konfiguration.

    Dies ändert sich nun mit Windows Server 2012, der den Gastsystemen innerhalb der VMs ein Virtual NUMA präsentiert. Mit diesem Feature reagierte Microsoft vor allem auf die gesteigerte Skalierbarkeit von Hyper-V, das nun einer VM bis zu 64 virtuelle CPUs und 1 TB RAM zur Verfügung stellen kann. Die bisherigen Maximalwerte von 4 vCPUs und 64 GB RAM ließen sich in der Regel auf einem physikalischen NUMA-Knoten abbilden, das klappt bei großen VMs künftig nicht mehr.

    Berechnung der NUMA-Topologie

    Wenn man in Hyper-V Manager in den Eigenschaften einer VM die Zahl der virtuellen Prozessoren einstellt, dann findet sich direkt darunter der Menüpunkt NUMA-Konfiguration. Dort kann man die NUMA-Topologie konfigurieren, wobei das Mapping von Virtual NUMA auf die physikalischen Gegebenheiten alles andere als trivial ist. Hyper-V kalkuliert den Wert jedoch selbständig, so dass im Normalfall hier keine manuelle Anpassung erforderlich ist.

    Eine ausführliche Beschreibung von Virtual NUMA bietet ein zweiteiliger Beitrag im Windows Server Blog von Microsoft.

    Keine Kommentare