Mit dem Dynamic Memory ab dem Servicepack 1 für den Hyper-V 2008 Release 2 lassen sich für virtuelle Maschinen dynamische Arbeitsspeicher-Kapazitäten vorgeben.  Doch nur wenn die Applikationen und Gastbetriebssysteme in der VM damit umgehen können, bringt das eine höhere Flexibilität im IT-Betrieb.

Der Einsatz von Dynamic Memory ab dem Servicepack 1 für den Windows Server 2008 Release 2 (R2) oder den Hyper-V 2008 Release 2 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. Mehr Details zur Technik hinter dem Dynamic Memory gibt das Portal www.nt4admins.de.

Ist eine virtuelle Maschine für den Einsatz von dynamischem Speicher konfiguriert, bringt das allerdings nur dann eine Verbesserung, wenn die Applikation und das Gastbetriebssystem in der VM damit umgehen können. Virtuelle Maschinen mit Linux als Gastbetriebssystem profitieren daher nicht von dieser Neuerung. Denn Linux kann derzeit nicht damit umgehen, dass zur Laufzeit mehr Arbeitsspeicher hinzugefügt wird.

Anzeige

Speicherpuffer beträgt normalerweise 20 Prozent

Generell kümmert sich der Virtual Machine Management Service Memory Balancer im Hyper-V um alle anstehenden Details beim Zuweisen und Entfernen von Speicherbereichen. Aufgrund seiner Vorgaben bekommen die VMs aus dem dynamischen Speicher entsprechende Kapazitäten zugewiesen.  Damit einen VM nicht über zu wenig Speicher verfügt, ehe ihr zusätzliche Kapazität dynamisch zugeweisen wird, gibt es einen Speicherpuffer, der standardmäßig 20 Prozent beträgt. Dadurch verfügen die VMs 20 Prozent verfügbaren Speicher (damit sind der freie Speicher und der für den Cache vorgesehene Speicher gemeint). Wenn der verfügbare Speicher unter die 20-Prozent-Marke fällt, wird mehr Speicher der betreffenden VM zugewiesen – wenn generell Speicher verfügbar ist.

Die Standardvorgabe mit den 20 Prozent passt sehr gut, da der Dynamic Memory Virtual Service Consumer (Dynamic Memory VSC) im Gastbetriebssystem sich darum kümmert, wie der Speicher hier verwendet wird. Dabei sind die 20 Prozent ein passender Wert für das Gastbetriebssystem, wie sich bei Tests von Microsoft ergeben hat.

Kommen aber Applikationen ins Spiel wie der SQL Server oder Java, sind die 20 Prozent keine gute Vorgabe. Denn derartige Arbeitslasten verwenden eigene Mechanismen für das Caching, die der Dynamic Memory VSC nicht erkennen kann. Selbst wenn der Speicher für das Caching des SQL Server oder bei Java zum Einsatz kommt, sieht der Dynamic Memory VSC nur, dass der betreffende Prozess den Speicher verwendet, dadurch interpretiert er die Situation dann so, dass es zu wenig verfügbaren Speicher gibt – da der SQL Server oder auch Java den gesamten verfügbaren Speicher für den eigenen Cache verwenden.

Dieser Zustand veranlasst den Dynamic Memory VSC zu melden, dass der Wert für den verfügbaren Speicher unter die vorgegebene Größe gefallen ist. Dann wird weiterer Speicher zugefügt und der SQL Server oder Java verwenden den neuen Speicher erneut und die Sache beginnt von neuem. Daher wird es nicht funktionieren, einen Wert von 20 Prozent für derartige Applikationen einzuhalten.

Legt man aber den Pufferspeicher auf nur 5 Prozent, wird das permanente Hinzufügen und Aufbrauchen von dynamischem Speicher vermieden. Denn diese Dienste erlauben es dem Betriebssystem, diesen Speicherbereich von verfügbarem Speicher für sich selbst zu verwenden.

Dynamic Memory und Exchange

 In der aktuellen Form des Exchange Server 2010 rät das Exchange-Team davor ab, die Software in einer virtuellen Maschine (VM) einzusetzen, bei der das Dynamic Memory aktiviert ist. Als Grund wird angegeben, dass Exchange generell mit Overcommitment beim Speicher und auch beim Dynamic Memory schlecht klar kommt, weil Exchange eine spezielle Speicherzuweisung verfolgt und zudem die Prozesse rund um den verfügbaren Speicher selbst optimiert.
Rainer Huttenloher