Prinzipien des Dynamic Memory beim Hyper-V

Mit dem Servicepack 1 für den Windows Server 2008 Release 2 und den zugehörigen alleinstehenden Hyper-V Server 2008 Release 2 kommt die dynamische Zuteilung von physischen Speicher für virtuellen Maschinen (VMs) ins Spiel: das Dynamic Memory. Diese Umkonfiguration erfolgt im laufenden Betrieb und lässt damit eine flexible Reaktion auf geänderte Arbeitslasten für einzelne VMs zu. Dazu müssen die Gastbetriebssysteme allerdings einen entsprechend „enlightened“ Kernel verfügen. Aber Vorsicht: Ist eine VM erst einmal für den Einsatz von Dynamic Memory konfiguriert, dann wird diese VM nicht mehr auf Hosts  mit früheren Versionen (also vor dem Servicepack 1) eingesetzt werden können.

Mit dem Servicepack 1 für Windows Server 2008 Release2 (R2) bringt Microsoft die Funktionalität des Dynamic Memory für Hyper-V-Hosts ins Spiel. Alle hier beschriebenen Features beziehen sich noch auf die erste Betaversion des Servicepack 1 für diese Plattform.

Wer in seinen Servern genügend Arbeitsspeicher installiert hat, der kann von dieser Funktion profitieren. Wer nur die Minimalausstattung an DRAM im System stecken hat – für den ist das eine gute Argumentation, in eine Speicherweiterung zu  investieren.

Die bisher im Einsatz befindlichen Versionen des Hyper-V arbeiten mit einer statischen Zuweisung von Arbeitsspeicher für virtuelle Maschinen (VMs). Üblicherweise wird beim Erstellen einer VM eine bestimmte Arbeitsspeicherkapazität aus dem kompletten physischen Arbeitsspeichers des realen Servers für diese VM reserviert. Dieser Betrag ändert sich während der Ausführung der VM nicht. Er lässt sich nur modifizieren, wenn die VM heruntergefahren wird.

Dazu steht zum Beispiel eine grafische Schnittstelle mit dem Hyper-V-Manager zur Verfügung. Unter den Einstellungen für jede VM lassen sich hier passende Werte vorgeben. Wenn sich in der Praxis allerdings erweist – und das passiert auch bei einer ausgiebigen Testphase und somit vor dem Einsatz in der Produktivumgebung – dann muss man die VM herunterfahren. Damit wird der Service beziehungsweise die Applikation in der VM für diesen Zeitpunkt nicht verfügbar sein. Doch diese Downtime möchte eine IT-Abteilung möglichst vermeiden.

Ein weiterer Aspekt betrifft die Parent Partition (sie ist auch nur eine VM) auf dem Hyper-V. Sie ist für einige Aufgaben – speziell im Ein-Ausgabebereich zuständig. Wenn auch sie mit einem dynamischen Arbeitsspeicherkonzept arbeitet, lassen sich Konfigurationen vermeiden, in denen dieser Partition zu viel DRAM zur Verfügung steht, wobei die anderen VMs darben müssen.
In letzter Konsequenz werden bei der dynamischen Arbeitsspeicher-Zuteilung der vorhandenen physischen Ressourcen der Maschine effektiver ausgenutzt.

Damit lassen sich dann auch höhere Konsolidierungsraten beim Zusammenlegen der VMs auf einem System erreichen. Vor allem beim Aufbau einer VDI (Virtual Desktop Infrastructure), wenn die einzelnen Desktops in Form einer VM auf einem zentralen Server laufen, sollten sich einige Optimierungspotenziale realisieren lassen.

Der Einsatz von Dynamic Memory verfolgt ein einfaches Muster: Die Zuteilung des physischen Speichers für einzelne VMs erfolgt je nachdem, welche Arbeitslast von der VM bearbeitet werden muss und wie viel freier Arbeitsspeicher zur Verfügung steht. Dazu muss der Administrator nicht länger einen festen Arbeitsspeicherbereich zuweisen. Er gibt dafür einen Speicherbereich (mit minimalen und maximalen Wert), und vor allem eine „Speicherpriorisierung“ für die VM an. Damit lassen sich verschiedene Prioritäten bei der dynamischen Speicherzuweisung an einzelne VMs erzielen – je nach dem, welche VM eine wichtigere Applikation oder einen wichtigeren Dienst anbietet.

Die dynamische Zuteilung des Speichers an eine VM setzt voraus, dass es sich beim Gastbetriebssystem in der VM um ein „enlightened“ Betriebssystem handelt. Darunter versteht Microsoft den Umstand, dass ein entsprechendes Gastbetriebssystem in einer VM von der Existenz des Virtualisierungs-Hosts (also des Hyper-V) Kenntnis hat.  Die Abbildung 1 verdeutlicht die prinzipielle Architektur des Hyper-V mit den verschiedenen Arten von Gastbetriebssystemen in einer VM.

Der Hyper-V und das „enlightened“ Gastbetriebssystem in einer laufenden VM kommunizieren miteinander und bestimmen dabei den aktuellen Arbeitsspeicherbedarf der VM. Steigt die Auslastung in einer VM an und wird daher mehr DRAM-Kapazität notwendig, um die notwendige Applikations-Performance bereit zu stellen, bekommt diese VM automatisch mehr Kapazität zugeteilt. Verringert sich dagegen die Last in der VM, oder aber andere VMs auf dem Host mit einer höheren Speicherpriorität fragen nach mehr DRAM nach, dann wird automatisch aus der VM Speicherbereich abgezogen.

Dieses Hinzufügen oder Entnehmen von Speicher ist die Aufgabe der Treiberarchitektur, die aus VSP (Virtual Service Provider), VSC (Virtual Service Consumer) und VMBus (Virtual Machine Bus) besteht und letztendlich  für ein „enlightened“ Gastbetriebssystem sorgt. Auf der Seite des Hosts kümmert sich der VSP um die Zuteilung des physischen Speichers zwischen den VMs, die auf diesem Host laufen. Auf der Seite der VMs sammelt der VSC die notwendigen Informationen ein, und bestimmt damit die Speicheranforderungen einer virtuellen Maschine. Danach stößt der VSC die notwendigen Operationen an, um Speicherbereiche hinzufügen oder sie zu entfernen.

Aus diesen Ausführungen ist zu erkennen, dass ein Gastbetriebssystem in einer VM in der Lage sein muss, das automatische Hinzufügen von physischen Speicherbereichen entsprechend zu unterstützen. Dazu ist das „Kernel Enlightment“ mit der Unterstützung von Dynamic Memory nötig. Eine Liste mit den Gastbetriebssystemen, die derzeit mit Dynamic Memory passend umgehen können, ist am Ende des Beitrags zu sehen.

Kompliziert wird beim Dynamic Memory das Entnehmen von Speicherbereichen aus einer VM. Dazu hat Microsoft das so genannte „Ballooning“ eingeführt. Dieser Prozess basiert auf einer Vereinbarung zwischen der betreffenden VM und dem Host-System. Sie müssen genau definieren, dass bestimmte Speicherseiten nicht länger vom Gastbetriebssystem in Anspruch genommen werden dürfen. Damit wird effektiv der für das Gastbetriebssystem verfügbare Speicherbereich reduziert.

Ballooning als Nothelfer

Nur die wenigsten Gastbetriebssysteme können damit umgehen, dass der dynamisch zugeteilte Arbeitsspeicher vom Gastbetriebssystem im laufenden Betrieb wieder weggenommen wird. Deswegen hat man bei Microsoft einen Weg gewählt, um VMs Arbeitsspeicher zu entziehen: Diese Aufgabe übernimmt der Balloon Driver. Er nimmt den Speicherbereich vom Gastbetriebssystem weg und richtet sich dabei nach einem Zielwert, den der Hyper-V vorgibt.

Angenommen der Hypervisor möchte 200 MByte Arbeitsspeicher von einer VM wegnehmen, dann weist der Hypervisor den Balloon Driver an, eine Größe von 200 MByte im Gastbetriebssystem zu belegen – sprich sich entsprechend aufzublähen. Damit blockiert der Treiber die 200 MByte im Arbeitsspeicherbereich des Gastbetriebsystem-Kernels. Ist dieser Vorgang abgeschlossen, informiert der Balloon Driver den Hypervisor darüber, welche Speicherseiten er bekommen hat. Danach kann der Hypervisor diesen Speicherbereich aus der Zuweisung für die VM weg nehmen, denn dieser Arbeitsspeicher wird nicht mehr vom entsprechenden Gastbetriebssystem benützt.

Aus dem Blickwinkel des Gastbetriebssystems wird allerdings der Wert für den kompletten physischen RAM-Bereich bestehen bleiben – also seit die VM gestartet wurde plus der zusätzliche zugewiesene Wert (sprich der statische Anteil beim Start, plus der im späteren Verlauf zugewiesene, dynamische Anteil). Die Größe des Balloon-Anteils lässt sich im Gastbetriebssystem nicht ermitteln – dazu muss man die Performance Counter in der Parent Partition des Hyper-V bemühen. Systemnahe Tools wie etwa der Task Manager im Gastbetriebssystem zeigen keine Reduzierung des Speicherbereichs an.

Sollte die zuvor in ihrem Speicherbedarf reduzierte VM zu einem späteren Zeitpunkt wieder zusätzlichen Speicher vom Host anfordern, werden genau  die Speicherseiten, die zuvor über das Ballooning nicht mehr verfügbar gemacht wurden, genommen und über den gegenteiligen Vorgang (auch als „Unballooning“ bezeichnet) der VM wieder zugewiesen. Hier ist allerdings darauf hinzuweisen, dass der Speicher beim Ballooning nicht sofort von einer VM weg genommen wird. Erst wenn eine andere VM danach anfragt, erfolgt die Umverteilung.

Mechanismen bestimmen den Speicherbedarf

Den Speicherbedarf einer VM bestimmt der Dynamic-Memory-Mechanismus mit Hilfe einer Berechnung der so genannten „Memory Pressure“. Dazu berechnet der Hyper-V über eine Division aus dem gesamten ursprünglich zugewiesenen Speicherbereich für das Gastbetriebssystem (das „Total Committed Memory“) und dem Speicherbereich, den die VM zusätzlich haben möchte, diesen Wert für den „Memory Pressure“ – das ist somit ein Verhältnis, sprich eine Prozentangabe. Diesen Speicherbereich weist der Hyper-V  der VM zu und addiert etwas zusätzlichen Speicher (als Puffer). Dieser Puffer ist pro VM vom Administrator in Form einer Prozentangabe konfigurierbar.

Ein Pufferwert von 50 Prozent bedeutet, dass ein zusätzlicher Speicherbereich von bis zu 50 Prozent des „Committed Memory“ für die VM zugewiesen werden kann. Das Gastbetriebssystem in der VM verwendet diesen zusätzlichen Speicherbereich für den System-File-Cache und kann damit die Performance des Betriebssystems selbst sowie der Applikationen verbessern.

Ein konkretes Rechenbeispiel soll das verdeutlichen: Angenommen der Hyper-V hat ermittelt, dass das Total Committed Memory für eine VM 4 GByte entspricht. Wenn in diesem Fall der Pufferwert für das Dynamic Memory noch mit 50 Prozent konfiguriert wurde, kann der Hyper-V noch 2 GByte an zusätzlichen Speicherbereich für den Einsatz als File-System-Cache der VM zur Verfügung stellen. Der gesamte physische Speicher für die VM darf dann bis zu 6 GByte betragen.

Allerdings garantiert das Dynamic Memory nicht, dass die Summe des Total Committed Memory im jeden Fall einer VM zur Verfügung steht. Auch der zusätzliche Speicherbereich für den Puffer wird vom Dynamic Memory nicht garantiert einer VM zur Verfügung gestellt. Denn der Hyper-V-Host berechnet auch den Memory Pressure für die anderen VMs – daher kann es dazu kommen, dass nicht genügend physischer Speicher bereit steht, um alle Vorgaben zu erfüllen.

Prioritätsregelung beim Dynamic Memory

In einer typischen Produktivumgebung haben einige VMs andere Anforderungen in Bezug auf ihre Performance als andere. Das liegt an den Applikationen, die sie für die Anwender bereitstellen. Unternehmenskritischere Anwendungen brauchen häufiger kürzere Antwortzeiten als das bei unterstützenden Funktionen (wie etwa einem DHCP-Dienst) der Fall ist. Darauf kann der Administrator mit dem Dynamic Memory reagieren:

Die VMs mit den wichtigeren Anwendungen oder Diensten erhalten eine höhere Speicherpriorität als die anderen auf demselben Host-System. Damit erfolgt die Zuteilung des Arbeitsspeichers nach einem ähnlichen Muster als die Verteilung der CPU-Ressourcen. Und das alles funktioniert auf Basis der einzelnen VMs.
Die Memory Priority tritt in Erscheinung, wenn der komplette verfügbare physische Speicherbereich eines Host-Systems auf alle laufenden VMs verteilt wurde.

Anders ausgedrückt: Verfügt der Host noch über nicht verteilte Speicherbereiche, hat die Memory Priority keinerlei Effekte. Doch im anderen Fall – wenn der physische Speicher  mehr als knapp ist – wird der Erhöhen der Speicherpriorität einer VM dazu führen, dass die Speicherkontingente für die anderen laufenden VMs sich reduzieren. Ihnen wird Speicher weg genommen und an die VM zugeteilt, die eine höhere Speicherpriorität genießt.

Voraussetzungen für den Einsatz von Dynamic Memory

Um einen Host mit dieser Funktionalität zu betreiben, muss das Servicepack 1 (es ist derzeit als Betaversion verfügbar) zum Einsatz kommen. Dazu benötigt der Host als Betriebssystem den kompletten Windows Server 2008 Release 2 mit der installierten Hyper-V-Rolle oder aber den alleinstehenden Hyper-V  Server 2008 R2.

Auf Seiten der Gastbetriebssysteme werden von der Betaversion derzeit nur Windows Server 2008 R2 (Enterprise und Datacenter Edition) mit Servicepack 1, Windows Server 2008 mit Servicepack 2 (in der Enterprise und der Datacenter Edition), Windows Server 2003 Release 2 mit Servicepack 2 (oder neuer; ebenfalls nur in Enterprise und Datacenter Edition) sowie Windows Server 2003 mit Servicepack 2 (oder neuer; Enterprise und Datacenter Edition) unterstützt.

Dabei ist es unerheblich, ob die 64- oder 32-Bit-Varianten dieser Betriebssysteme zum Einsatz kommen – so es diese Plattformen noch in der 32-Bit-Version gibt.

Im Bereich der Client-Betriebssysteme unterstützt Microsoft bei 32- und 64-Bit-Plattformen Windows 7 (Enterprise und Ultimate Edition), Windows Vista mit Servicepack 2 (Enterprise und Ultimate Edition).

Mit der Verfügbarkeit der endgültigen Servicepack-1-Version für Windows Server 2008 Release 2 und Windows 7 kommen weitere Gastbetriebssysteme aus dem Haus Microsoft dazu. Es wird erwartet, dass dazu die folgenden Plattformen gehören:
Windows Server 2008 R2 Standard Edition mit Servicepack 1,

Windows Server 2008 Web Edition mit Servicepack 1, 

Windows Server 2008 Standard Edition mit Servicepack 2,

Windows Server 2008 Web Edition mit Servicepack 2,

Windows Server 2003 Release 2 Standard Edition mit Servicepack 2 (oder neuer),

Windows Server 2003 Release 2 Web Edition mit Servicepack 2 (oder neuer),

Windows Server 2003 Standard Edition mit Servicepack 2 (oder neuer) sowie

Windows Server 2003 Web Edition mit Servicepack 2 (oder neuer).

Eine Frage der Kompatibilität

Eine weitere Besonderheit kommt noch beim Failover-Clusterung mit dem Dynamic Memory mit ins Spiel: Ist eine VM erst einmal so konfiguriert, dass sie Dynamic Memory verwendet (indem die neueste Version der Integrationsdienste im Gastbetriebssystem installiert wurden), dann wird diese VM nicht mehr auf Hosts  mit früheren Versionen (also vor dem Servicepack 1) eingesetzt werden können. Sie kann daher auch nicht von einem Cluster-Knoten mit Windows Server 2008 Release 2 und Servicepack 1 auf einen anderen Knoten  mit demselben Betriebssystem aber noch nicht installierten Servicepack 1 Verwendung finden.

Rainer Huttenloher