Immer wieder sehe ich viele Fragezeichen in den Augen wenn es um Memory und ESX geht. Auf diesem Grund möchte ich hier einfach mal versuchen mit Begriffen aufzuräumen und einige Werte erklären.

Sollte es Fragen geben oder noch etwas unklar ist bitte in den Kommentaren posten. Ich werde es dann entsprechend ergänzen.

Es gibt ein paar Begriffe die zum Verständnis wichtig sind, damit man weiß welches RAM gerade gemeint ist. Klingt komisch, ist aber so.

 

Begriffe:

Host physical memory: Dies ist der RAM der der vom Hypervisor gesehen wird,  also physikalisch im Server verbaut ist.

Guest physical memory: Ist der RAM der der vom Gast Betriebssystem gesehen wird,  also der Hauptspeicher der einer VM zugewiesen wurde.

Guest virtual memory: Ist ein virtueller Adressbereich der vom Gast Betriebssystem den Applikationen zur Verfügung gestellt wird.

Weitere wichtige Begriffe kommen aus dem Bereich des Swapping. Zwischen paging und swapping ist nämlich ein kleiner aber feiner Unterschied:

Werden Daten vom physikalischen Gastspeicher in die Auslagerungsdatei des  Gastsystems geschrieben nennt man das „paging“. Dies wird direkt vom Gast Betriebssystem initiiert.

Daten die vom physikalischen Gastspeicher in den Swap Speicher des Hypervisor geschrieben werden, nennt man „swapping“ und ist direkt vom Hypervisor initiiert.

 

Jetzt, da wir vom gleichen reden, kommen wir mal zu den eigentlichen Techniken. Der folgende Abschnitt erklärt wie Speicher zugewiesen wird.

Wenn eine virtuelle Maschine läuft erstellt der ESX Host einen zusammenhängenden Speicher Bereich für diese virtuelle Maschine. Dieser Bereich hat dieselben Eigenschaften wie der Bereich der vom Gast OS an die Applikationen weitergegeben wird. Das erlaubt dem ESX mehrere VMs gleichzeitig zu betreiben ohne dass Bereiche von anderen VMs eingesehen werden können. Das ist auch der Grund warum ein Crash einer einzelnen VM den anderen Maschinen nichts ausmacht. Es gibt also drei ‚ÄûSchichten‚Äú: ¬†Mapping des physikalischen Host Speicher auf den physikalischen Gast Speicher und der physikalische Gast Speicher auf den virtuellen Gast Speicher.

 

Das Memory Management von ESX ist so effizient da verschiedene Techniken eingesetzt werden. Hat das irgendwas mit Seiten und Ballons zu tun? Genau, hier wird es erklärt:

Transparent Page Sharing

Wenn mehrere VMs auf einem Host betrieben werden ist es oft der Fall, das identische Daten im RAM von den einzelnen VMs vorhanden sind. Ein sehr gutes Beispiel ist wenn man 40 Windows VMs auf einem ESX Host betreibt. Viele der Daten die im Speicher abgelegt werden sind identisch. Mit Transparent Page Sharing kann der ESX sich dies zu Nutze machen und Speicher einsparen, indem eine ‚ÄûDeduplizierung‚Äú stattfindet. ESX sucht solche redundanten Einträge und behält davon nur noch eine für alle VMs.

Über ein Hash Verfahren scannt ESX den physikalischen Speicher der VMs nach geeigneten Daten für das Transparent Page Sharing. Der Hash Wert wird anhand des Inhaltes des Speicher erstellt. Dieser Wert wird anschließend in eine Tabelle geschrieben. Ist dieser Wert dann exakt derselbe wie ein Wert der bereits in der Tabelle steht wird noch einmal ein bit-Abgleich der Bereiche gemacht, um 100% sicher zu gehen, dass die Inhalte gleich sind. Dies dient zur Sicherheit das keine Fehler auftreten die den Gast zum Absturz bringen könnten. Wenn dieser Test in Ordnung ist, wird die Adresse des Bereichs auf den shared Bereich geändert und der doppelte Eintrag wird gelöscht.

Was aber passiert wenn dieser Bereich geändert werden muss? Dann wird ein normales Copy on Write ausgelöst. Beim Versuch auf den Bereich zu schreiben wird ein page fault ausgelöst der vom page fault handler des ESX erkannt wird. ESX erstellt dann einen neuen, privaten, Bereich und passt die Adresse an damit der Gast auf den neuen Bereich zugreift.

 

Ballooning

Ballooning ist eines der Funktionen die sich von Transparent Page Sharing komplett unterscheiden. Ballooning kommt erst dann zum Einsatz wenn physikalischer RAM im Host knapp wird (also am besten nie).

Da die VM nicht weiß, dass sie auf einem Host als virtuelle Maschine läuft interessiert sie auch der RAM des ESX nicht. Wird der RAM auf dem Host knapp, geben die virtuellen Maschinen also keinen RAM selbstständig frei den sie gerade nicht benötigen. ¬†Genau hier setzt Ballooning ein.

Voraussetzung für Ballooning ist ein Treiber der im Gast Betriebssystem installiert sein muss. Dieser kommt über die VMware Tools und wird automatisch installiert und konfiguriert.

Auch der ESX weiß nicht welche Speicher Bereiche von der VM verwendet werden und welche nicht, da dies komplett in der Verantwortung des Gastbetriebssystem liegt. Daher ist es für den ESX Host nicht möglich, sich vom Gast ungenutzte Speicherbereiche zurück zu holen. Benötigt der ESX Speicher zusätzlichen Speicher, der über den frei verfügbaren hinausgeht, unterstützt der Balloon Treiber.

Man muss sich das wie folgt vorstellen:

Über einen privaten Channel kommuniziert der ESX mit dem Balloon Treiber in der VM. Die virtuelle Maschine die gerade läuft hatte mal vier Speicher Bereiche, benötigt aber jetzt nur noch zwei. (Es wurde zum Beispiel eine Applikation beendet). Damit der ESX sich diese beiden Bereiche zurück holen kann werden diese vom Balloon Treiber innerhalb der virtuellen Maschine angefordert. Das Gast Betriebssystem weiß, dass zwei Bereiche frei sind und gibt diese an den Balloon Treiber. Der Balloon Treiber kennt jetzt die Adressen des Speicher und übermittelt diese über den privaten Channel zurück an den ESX. Auch der ESX kennt jetzt die Adressbereiche und kann sich diese von der VM zurück holen und anderweitig verwenden. Wenn die VM jetzt irgendwann wieder mehr RAM benötigt bekommt das der page handler von ESX mit und teilt zwei neue Bereiche zu. ¬†‚ÄûSchwubs‚Äú, so einfach ist das.

Was aber passiert wenn die VM selbst nicht genug RAM zur Verfügung hat? Die Antwort ist ganz einfach. Es wird ein normale paging ausgelöst und das Gast OS entscheidet welcher Speicher ins pagefile geschrieben werden muss.

 

Hypervisor Swapping

Für die Performance gibt es nichts schlimmeres als wenn der ESX VMkernel selbst in seine Swap schreibt, die im Standard als vswp Datei für jede virtuelle Maschine mit gleicher Größe wie dem Gast zugeordneten Hauptspeicher angelegt wird. Da aber Ballooning und Transparent Page Sharing ihre Zeit brauchen kann der ESX Host Swap immer mal wieder für kurze Zeit Speicher freischaufeln. Damit will ich nicht sagen, dass es völlig in Ordnung ist wenn ¬†der ESX Host 5x am Tag swappen muss. Dann sollte man allgemein sich mal die Architektur anschauen. Für den absoluten Notfall ist es aber sehr gut geeignet.

 

Memory Compression

Mit VMware vSphere 4.1 gibt es ein neues Feature genannt Memory Compression. Was genau passiert hier? Erst einmal Entwarnung, nicht der gesamte Memory der virtuellen Maschinen wird komprimiert sondern lediglich die Teile die auf Platte ausgelagert werden würden.

Im Detail… Bisher war es so das der ESX Server ein normales paging gemacht hat wenn alles andere nicht mehr hilft. Das bedeutet das Daten aus dem schnellen Speicher auf die meistens sehr viel langsamere Platte ausgelagert werden. Das ist auch mit 4.1 der Fall mit einem kleinen Zwischenschritt. Bevor die Daten ausgelagert werden versucht ESX diese zu komprimieren und weiterhin im Speicher zu halten. Das komprimieren und dekomprimieren ist dabei sehr viel schneller als es auf Platte zu schreiben. Es werden nur die Daten komprimiert die mit einer Kompression von 50% oder besser komprimiert werden können.

Wann aber werden Aktionen vom ESX eingeleitet um Speicher wieder freizuschaufeln? Beim Transparent Page Sharing ist es klar. Dies wird trotz des minimalen Overhead immer wieder aktiviert um Speicher einzusparen. Ballooning und Hypervisor Swapping dagegen wird nur dann ausgelöst wenn ein bestimmter Memory Status erreicht wurde.

ESX hat vier Zustände von ‚ÄûHost free memory states‚Äú: high, soft, hard und low. Dieser Status kann im ESX Top angeschaut werden und ist oben rechts in der Ecke zu finden.

 

High

Steht der Wert auf High so verwenden die VMs weniger Speicher als der ESX Host zur Verfügung hat auch wenn dieser überbucht (overcommited) ist. In diesem Status wird weder Ballooning noch Hypervisor Swapping verwendet um Speicher freizuschaufeln.

Soft

Erreicht der Status den Wert Soft so beginnt ESX via Ballooning Memory von den virtuellen Maschinen freizubekommen.

Hard

Da Ballooning seine Zeit braucht und es auch nicht garantiert ist, das genug Speicher durch Ballooning freigegeben wird, wird bei Hard das Hypervisor Swapping eingeschaltet. Ab jetzt macht‚Äôs keinen Spaß mehr, denn die Performance wird spürbar nachlassen. Es wird solange ausgelagert bis der Status wieder auf Soft steht.

Low

Bei Low wird nicht nur Ballooning und Swapping eingesetzt sondern es wird auch VMs nicht mehr erlaubt weiteren RAM zu allokieren.

 

Ich hoffe, dass dieser kleine Überblick euch etwas hilft. Es gibt natürlich noch viel mehr rund um dieses Thema wie zum Beispiel Reservierungen. Da bei mir aber gerade schön viel Schnee liegt gehe ich jetzt erst einmal raus! Ich werde diesen Artikel demnächst erweitern.