Als neues Thema möchte ich in diesem Jahr mit ein paar kleinen Artikeln zum Resource Management in vmware vSphere Umgebungen erstellen. Starten möchte ich mit einem „brandaktuellen“ Thema:
Memory Overcommitment in vmware vSphere Umgebung
Allgemein bekannt, sollte die Tatsache sein, das man in einer vmware vSphere Umgebung mehr „virtuellen RAM“ (vRAM) an VMs verteilen kann als physikalisch vorhanden ist. Dieses nennt man „Overcommitment“.
Bis zu einem bestimmten Betrag ist dieses völlig problemlos zu betreiben. Grob geschätz kann ein Overcommitment von ca. 10% locker betrieben werden, ohne Betriebliche Resourcen Engpässe zu spüren. Die Idee ist einfach. Da man davon ausgeht das nie alle VMs gleichzeitig den zugewiesenen vRAM auch tatsächlich anfordern stehen immer genug Resourcen bereit. (Siehe Telefonnetze: Diese waren auch nur für max. 10-20% der angeschlossenen Teilnehmer ausgelegt. Da nie alle Teilnehmer gleichzeitig telefonieren funktioniert dieses, bis auf den Sylvester Abend ;-), auch ganz gut).
Wer also seine Umgebung völlig ohne Overcommitment betreibt braucht eigentlich nicht weiterlesen 😦
Was aber wenn es doch mal eng wird? Dann ist es gut wenn man weiss was vmware bzw. der vmkernel so anstellt um die Situation zu beherrschen.
Techniken zur Memory Resource Verwaltung in vmware vSphere
- Transparentes Memory Page Sharing
- Ballooning
- Memory Compession
- Swapping
Diese vier Techniken stehen dem vmkernel im Prinzip zur Verfügung. Was diese im Einzelnen tun möchte ich hier ein wenig betrachten. Die Techniken werden genau in dieser Reihenfolge von 1. – 4. durchgeführt. Es wird allso von 1. harmlos bis 4. Fatal immer schlimmer.
1. Transparentes Page Sharing
Transparentes Memory Page Sharing (TPS) ist praktisch immer aktiv und wird vom vmkernel permanent angewendet. Die Idee ist hierbei, Duplikate von gleichen Memory Pages nur einmal im physikalsichen Speicher zu halten (Deduplizierung von Memory Pages)
Transparentes Memory Page Sharing
(Bild 1: Quelle vmware http://www.vmware.com/files/pdf/mem_mgmt_perf_vsphere5.pdf)
Es werden also hierbei mehrfach identische Memory Pages dedupliziert (z.B. die Windows Kernel Pages mehrerer VMs). Dieses ergibt bei mehreren identischen oder ähnlichen VMs durchaus eine beträchtlichen Anteil an physiklasichem Memory welcher „wiedergewonnen“ werden kann.
ACHTUNG: Transparentes Page Sharing benötigt einige Zeit (nach den Start einer VM) bis dieses effizient greift! Der arme vmkernel benötigt einfach etwas Zeit (10-20min) um zu ermitteln welche Pages nun tatsächlich dedupliziert werden können, sprich „bei welchen es sich lohnt diese zu deduplizieren“.
2. Ballooning
Ballooning ist nun die nächste Stufe der „Mangelverwaltung“ des physiklischen Speichers. Hauptakteur ist hier ein kleiner Kerneltreiber der mit den vmware Tools in die VMs installiert wird. Sein Name „vmmemctl„. Dieser sorgt nun, in Zusammenarbeit mit dem vmkernel dafür das eine VM oder besser das Gast OS physikalischen Speicher an den vmkernel zurückgibt!
Wir geht das? Im Prinzip relativ einfach (praktisch durchaus nicht so trivial zu realisieren).
Wenn eine VM nun via VMM eine Memory Anforderung an den vmkernel stellt, die dieser nicht erfüllen kann, dann geht der vmkernel zu allen (bzw. erst zu den am niedrigsten priorisierten VMs -> siehe dazu „vmware Resource Management – Shares was ist das?„) VMs und bittet um physikalischen Speicher. Er geht quasi mit dem Hut herum und bittet für den VM Kollegen der Not hat.
Dabei spricht er den „vmmemctl“ an. Dieser läuft als höchstpriorisierter Kernelprozess im Gast OS und bittet dieses nun um Speicher. Das Gast OS fängt nun an zu swappen / pagen und lagert seinerseits nieder priorisierte Prozesse in sein Page-File (in der VMDK) aus. Den gewonnenen Speider gibt es an den vmmemctl der dieses Memory aber an den vmkernel weiterreicht (Bild 2 Ziffer 2).
Man könnte Ballooning als „Community Hilfe“ bezeichnen. Jeder gibt etwas um dem notleidenen Kollegen (der VM) zu helfen.
Ballooning in vmware
(Bild 2: Quelle vmware http://www.vmware.com/files/de/pdf/vsp_40_resource_mgmt_de.pdf)
Wenn sich der physikalsiche Memory Engpass nun wieder beruhigt hat, gibt der vmkernel den Speicher praktisch an den vmmemctl im Gast zurück. Dieser gibt in an das Gast OS zurück, die ausgelagerten Prozesse werden wieder aus dem Page-File geholt und alles ist hoffendlich wieder OK.
Somit haben wir ein paar Punkte zum Ballooning:
A: Ballooning ist NUR für kurzfristige Memory Engpässe gedacht. Sptzen sollen durch die Community der VMs auf einem Host abgefedert werden. Jeder gibt etwas, es tut idealerweise keinem weh und der Notfall ist behoben.
B: Ballooning gibt es nur mit den vmware Tools!
C: Es balloonen die VMs die KEIN Problem habe!!! Unter denen die nicht balloonen sind der oder die Konsumenten.
Übrigens: Eine VM die eine Memory Reservation = Konfiguriertes Memory hat balloont nicht!
3. Memory Compression
Memory Compression wurde mit vSphere 4.1 eingeführt und soll Memory Pages in einem speziellen Cache Bereich des Host-Memory komprimiert „swappen“. Idee ist, das die Kompession und Dekompression schneller geht als das Swappen auf Platte.
Memory Compression
(Bild 3: Quelle vmware http://www.vmware.com/files/pdf/techpaper/VMW-Whats-New-vSphere41-Performance.pdf)
Meine Erfahrung hat allerdings bisher leider gezeigt das der Schritt von 3. Memory Compression zu 4. Swapping nicht sehr weit ist.
4. Swapping
Kommen wir zur letzten und fatalsten Technik des vmkernel im Falle eines physikalsichen Memory Engpasses. Dann nämlich agiert der vmkernel wie jedes OS auch. Er lagert Teile oder ganze Prozesse in das Swap-File aus. Nur leider ist unser Prozess eine VM!!!
Das bedeutet das im Worst Case eine VM im Storage läuft (wobei von „laufen“ sicher keine Rede sein kann).
Zum Glück geschieht dieses nicht sofort am Stück, sondern es werden erst einzelne Memory Pages in das Swap-File geschoben.
Nun kommt an dieser Stelle die Idee ins Spiel, das Swap-File (bzw. die Swap-Files der VMs) auf schnelleren Speicher zu legen. Zum Beispiel indem man in jeden ESXi Host eine schnelle SSD einbaut und diese als Swap-Lokation der VMs benutzt. Alternativ natürlich auch gern SSD LUNs (was vMotion etwas erleichtert). Ich persönlich denke, das der Einbau von mehr RAM in die Host, wenn möglich, die einfachste und beste Lösung der Memory Problem ist.
Fazit
Von Transparentem Memory Page Sharing über Ballooning bis zum Swapping hat vmware viele Möglichkeiten um physikalisches Memory zu zuteilen bzw. Engpässe zu lösen. Bleibt der Vorschlag: „Monitoren Sie Ihr System um möglichst proaktiv handeln zu können“. Vielleicht sollte ich mal einen Artikel zu dne konkreten Performance Parameter bringen die das Thema unterstützen? Schreiben Sie doch einfach einen Kommentar.
dervirtuellewirt 