Guido Vrola - Fotolia

Strategien für ein erfolgreiches Memory Overcommitment

Das Overcommitment von Arbeitsspeicher kann die Performance virtueller Maschinen deutlich erhöhen. Dabei sollten aber einige Dinge beachtet werden.

Im gleichen Maße, in dem Prozessoren immer leistungsfähiger und mit immer mehr CPU-Kernen ausgestattet werden, wird der Arbeitsspeicher in zunehmendem Maße zur größten Leistungsbremse virtueller Maschinen.

Dabei ist es natürlich nicht so, dass Arbeitsspeicher nicht auch schneller geworden wäre, ganz im Gegenteil, aber damit ist Arbeitsspeicher eben auch teurer geworden. Gleichzeitig sind aber auch die Anforderungen moderner Betriebssysteme und Applikationen an den Arbeitsspeicher deutlich gestiegen.

Administratoren können diesen Kostenanstieg aber durch Strategien zum Memory Overcommitment bis zu einem gewissen Grad ausgleichen, um die vorhandenen Ressourcen effizienten zu nutzen – zumindest dann, wenn sie dabei nicht zu weit gehen und die VM-Performance beeinträchtigen.

Die Herausforderung des richtigen Memory Overcommitment

Die Nutzung des VM-Arbeitsspeichers ist eine große Herausforderung, weil hier unterschiedliche Ebenen verwaltet werden müssen. Für jede virtuelle Maschine weist der Hypervisor einen Teil oder sogar den ganzen physischen Arbeitsspeicher zu, den die VM benötigt. Die genaue Menge hängt normalerweise davon ab, welche Reservierungen oder Vorgaben für das Teilen des Arbeitsspeichers unter mehreren virtuellen Maschinen vorliegen.

Zusätzlich zum physischen Arbeitsspeicher erstellt der Hypervisor oft auch eine korrespondierende Swap-Datei auf der Festplatte, falls die physischen Memory-Ressourcen des Hosts nicht ausreichen sollten. Der Vorgang hierbei ist dem Vorgehen herkömmlicher Betriebssysteme sehr ähnlich, die ebenfalls Swap- oder Page-Dateien anlegen. Das gibt dem Gastbetriebssystem die Möglichkeit, sowohl den physischen Arbeitsspeicher als auch die Swap-Datei so zu nutzen, als wäre es der eigene Arbeitsspeicher oder Swap-Bereich. Der phyische Arbeitsspeicher kann dabei aber wiederum eine Swap-Datei sein.

Dieser unterschiedliche Zugang zum Arbeitsspeicher auf verschiedenen Ebenen bildet die größte Herausforderung bei der Memory-Nutzung virtueller Maschinen, da Administratoren unterschiedliche Ebenen des Overcommitments verwalten müssen und diese Ebenen nicht miteinander kommunizieren.

Eine Management-Möglichkeit für Administratoren besteht hier in Virtual Guest Tools, mit denen sich Gastbetriebssysteme besser an virtuelle Umgebungen anpassen lassen. Meist werden damit Balloon-Treiber des Memory Balloning genutzt, mit dem das Gastbetriebssystem daran gehindert werden kann, zu viel Arbeitsspeicher für das Caching in Anspruch zu nehmen. Die meisten Betriebssysteme sind ihrem Ursprung entsprechend nicht für die Virtualisierung ausgelegt, Virtual Guest Tools können in diesem Fall helfen, diese Lücke zu füllen.

Das Dilemma des Transparent Page Sharing

Neben den Komplikationen des vielschichtigen Memory-Zugriffs gibt es aber noch ein weiteres Problem, das sich auf die Nutzung des Memory Overcommitments auswirkt. Aus Sicherheitsgründen hat VMware Transparent Page Sharing standardmäßig deaktiviert, eine Funktion zum Teilen einer Memory Page durch mehrere virtuelle Maschinen, so als wäre die Memory Page in allen VMs dieselbe.

Durch dieses Memory Sharing lässt sich zwar enorm viel Arbeitsspeicher einsparen, es kann gleichzeitig aber auch zu erheblichen Sicherheitsproblemen führen, weil virtuelle Maschinen damit nicht mehr vollständig voneinander isoliert sind. Damit kann man Transparent Page Sharing zwar noch immer nutzen, die Funktion muss aber manuell aktiviert werden.

Wenn die Funktion deaktiviert ist, lässt sich aber auch das VM-Overcommitment leichter nachverfolgen und verstehen. Der kritische Punkt ist hier erreicht, wenn der physische Arbeitsspeicher nicht mehr ausreicht und eine Swap-Datei angelegt werden muss. Allerdings erkennt man diesem Punkt sehr leicht und kann so das Disk-Swapping, bei dem die VM-Performance rapide absinkt, leicht vermeiden.

Beim Memory Overcommitment gibt es allerdings einigen Spielraum, weil natürlich nicht jede virtuelle Maschine gleich ist. Damit empfiehlt es sich für eine effiziente Nutzung des Overcommitments, produktive Workloads mit Test- und Entwicklungs-VMs auf dem gleichen Host zu mischen, um durch die unterschiedlichen Anforderungen immer ausreichend Ressourcen zur Verfügung zu haben.

Sollte es zur Ressourcenknappheit kommen, dann können weniger kritische virtuelle Maschinen über Reservierungen und Limits an Swap-Dateien statt an den physischen Arbeitsspeicher verwiesen werden. Damit bleibt geschäftskritischen Workloads genügend Arbeitsspeicher zur Verfügung, während weniger wichtige virtuelle Maschinen dann mit einer geringeren Leistung ausgeführt werden. Allerdings ist hierbei zu beachten, dass das erzwungende Page-Swapping den Storage-Traffic erhöhen wird, auch wenn es sich nur um Test-VMs handelt, und so das gesamte System in Mitleidenschaft gezogen wird.

Eine weitere Möglichkeit besteht darin, lokale SSDs zu installieren, um die Swap-Datei zu hosten. Damit können die Performance-Einbußen bis zu einem gewissen Grad ausgeglichen werden. Allerdings bedeutet das auf der anderen Seite auch, dass keine VM-Migration per vMotion oder ähnlichen Technologien mehr möglich ist, weil die Swap-Datei dann lokal auf der physischen Hardware liegt.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!

Erfahren Sie mehr über Server- und Desktop-Virtualisierung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close