Wie funktioniert eigentlich die Virtualisierung?
Immer wieder gibt es Fragen wie genau die verschiedenen Funktionen von VMware oder anderen Herstellen funktionieren. Themen wie VMotion oder HA sind nicht immer direkt verständlich. Auf dieser Seite möchten wir erklären wie diese Dinge funktionieren.
Microsoft Hyper-V Quick Migration
Microsoft hat mit der Veröffentlichung von Hyper-V die Funktion Quick Migration implementiert.
Bei Quick Migration handelt es sich um die Möglichkeit eine virtuelle Maschine von einem Host auf den anderen Host zu verschieben und dabei eine möglichst geringe Ausfallzeit zu haben. Das System fällt aber in jedem Fall für eine gewisse Zeitdauer aus, abhängig von der Hauptspeichergröße der virtuellen Maschine, da diese Daten auf Plattenspeicher kopiert werden müssen! Eine wirkliche Live Migration ohne Ausfall ist erst ab dem Release R2 im Jahre 2010 möglich.
Kopiert wird lediglich der RAM Inhalt der virtuellen Maschine. Die eigentlichen Konfigurationsdateien und Festplattendateien müssen auf einem shared Storage gespeichert sein.
Wie genau funktioniert Quick Migration?
Vom Prinzip her ist es sehr einfach. Eine virtuelle Maschine die auf Host-A arbeitet soll zum Beispiel auf Host-B verschoben werden. Vorausgesetzt ist natürlich das die virtuelle Maschine auf einem shared Storage liegt also nicht lokal (ein Cluster der Hostsysteme ist notwendig). Wird die Migration angestoßen wird die Maschine suspended. Das bedeutet das die Maschine abgeschaltet wird und der Hauptspeicherinhalt auf Platte geschrieben wird. Anschließend werden die Zugriffssperren auf die physikalischen Daten freigegeben und der Host-B registriert die virtuelle Maschine und macht einen resume. Dieser Resume lädt den Hauptspeicherinhalt von der Festplatte in den Hauptspeicher des Hostsystems und allokiert diese Ressourcen für die virtuelle Maschine. Erst nachdem alle Daten im Hauptspeicher sind, wird die CPU der VM wieder aktiv und die VM ist online.
Die Dauer der Migraton einer virtuellen Maschine hängt also vom RAM ab, da dieser kopiert wird. Bei einer VM mit nur 512 MB RAM dauert dies um die 6 Sekunden! Bei einer VM mit 4 GB RAM kann dies aber schon über 60 Sekunden dauern. Die virtuelle Maschine darf bei diesem Kopiervorgang keine Änderungen mehr im Hauptspeicher schreiben können, daher ist ab dem Startvorgang des Suspend bis zum vollständigen Resume keine Nutzung der VM möglich.
High Availability (Hochverfügbarkeit)
Die HA Funktion dient zu Ausfallminimierung der virtuellen Maschinen und wird im Folgenden anhand der VMware HA Funktion erklärt.
Wenn die Funktion HA in einem Cluster aktiviert wird, werden Agenten auf den Host installiert die diesem Cluster zugeordnet sind. Dieser Agent ist dafür verantwortlich, dass die Hosts untereinander überprüfen ob alle anderen Host noch verfügbar sind. Zusätzlich wird das Default Gateway der Service Console per Ping geprüft. Wenn der Heartbeat nicht mehr funktioniert werden die virtuellen Maschinen auf dem Host der ausgefallen ist auf den verbleibenden Host neugestartet. Allerdings ist dies abhängig von der Konfiguration des HA Clusters.
Konfiguriert wird der HA Cluster im vCenter. Sobald der HA Cluster fertig konfiguriert wurde, ist die Ausfallsicherheit allerdings nicht auf vCenter angewiesen. Das bedeutet das HA auch dann funktioniert, wenn das vCenter nicht erreichbar ist oder auf dem Host betrieben wurde der ausgefallen ist.
Die Entdeckung eines Host Fehler dauert ca. 15 Sekunden. Dabei ist zu beachten, dass die virtuellen Maschinen auf den verbleibenden Host neu gestartet werden. Das bedeutet das alle Daten die nicht gespeichert waren verloren sind und die VM, je nach Diensten, mehrere Sekunden oder Minuten nicht erreichbar ist.
Microsoft bietet ebenfalls eine HA Möglichkeit, welche durch die Konfiguration der Hostsysteme als Cluster ermöglicht wird.
Citrix unterstützt HA ebenfalls für die virtuellen Maschinen und hat das Marathon Produkt Level 1 integriert. Wird Marathon gesondert lizenziert ist ein HA bis Level 3 möglich, was dem geplanten VMware Fault Tolerance Feature entspricht.
Live Migration
Unterstützt ein Virtualisierungsprodukt das Verschieben einer virtuellen Maschine von einem physikalischen Hostsystem zu einem weiteren ohne Ausfall, wird diese Funktion Live Migration oder Hot Migration genannt.
VMware war Pionier und führte diese Funktion als erstes Unternehmen am Markt ein und benennt es VMotion. Microsoft bietet diese Form der Migration erst mit der nächsten Hyper-V Version R2 an, allerdings möchte Citrix mit einer Microsoft Essential Managementsoftware bereits vorher Abhilfe schaffen. Citrix Virtualisierungsprodukt XenServer unterstützt die Live Migration bereits seit einiger Zeit.
Damit die Live Migration möglich wird, müssen mehrere Voraussetzungen erfüllt werden:
1) Zentraler Ablageort für die virtuelle Maschine, auf der alle beteiligten Hostsysteme Zugriff besitzen
2) Im SAN wird ein Cluster Filesystem benötigt, um die gleichzeitigen Zugriffe zu ermöglichen – hier wird Fibre Channel und iSCSI SAN unterstützt. Handelt es sich um einen zentralen NAS Storage muss dieser NFS unterstützen.
3) Die beteiligten Hostsysteme müssen über das Netzwerk in angemessener Geschwindigkeit (mindestens GBit) kommunizieren können
4) CPU Vendor, Family und Stepping sollte identisch sein. Durch Nutzung verschiedener Technologien kann diese strikte Gleichheit jedoch aufgeweicht werden. Allerdings besteht keine Möglichkeit AMD mit Intel Prozessoren zu mischen.
5) Die virtuellen Netzwerke der zu migrierenden virtuellen Maschine müssen identisch sein
6) Das Zielsystem muss genügend freie Ressourcen für die zu migrierende virtuelle Maschine besitzen.
Am Beispiel von VMware VMotion wird passiert Live Migration wie folgt:
Zuerst findet eine Überprüfung der Kompatibilität und der verfügbaren Ressourcen statt. Ist dieser Test erfolgreich folgt der nächste Schritt, in dem die Ressourcen der virtuellen Maschine auf dem Ziel-Host „nachgebaut wird“.
Nun wird auf dem Quellsystem der virtuelle Hauptspeicher der VM „eingefroren“ und alle Änderungen ähnlich des Snapshots in einen anderen Hauptspeicherteil geschrieben. Es beginnt die Übertragung des Hauptspeicherinhalts auf den Zielhost. Da während der Übertragung weitere Hauptspeicheränderungen stattfinden, wird dieser Vorgang wiederholt, bis die zu übertragende Datenmenge so klein ist, dass kein Ausfall zu befürchten ist.
VMotion sorgt durch Nachverfolgung der stattfindenden Speichertransaktionen in einer Bitmap-Datei dafür, dass der Übertragungszeitraum für Anwender nicht wahrnehmbar bleibt.
Hier wird auch schnell klar, warum eine Gbit Verbindung zwingend notwendig ist, da die zu übertragenden Daten recht groß sein können (mehrere GByte) und die Zeitspanne sehr klein zu halten ist.
Sobald der gesamte Speicher- und Systemzustand auf das ESX Server-Zielsystem kopiert wurde, unterbricht der VMotion Prozess die Ausführung der virtuellen Maschine (Anhalten der virtuellen CPU) auf dem Quellsystem, kopiert die letzten Änderungen im Hauptspeicher zum Zielsystem und dieses übernimmt den kompletten Zugriff auf die Ressourcen der virtuellen Maschine. Die virtuelle CPU wird mit allen benötigten Ressourcen und Daten daraufhin wieder gestartet. Die Applikationen merken von diesem Vorgang nichts, da diese nicht weiterrechnen konnten.
VMotion übernimmt im Rahmen des beschriebenen Vorgangs auch die Verwaltung der virtuellen MAC-Adresse.
Wichtig ist daher, dass dem angeschlossenen physikalischen Switch durch ein Reverse ARP Paket mitgeteilt wird, dass die MAC Adresse der virtuellen Maschine nun über einen anderen Port zu finden ist.
Für den gesamten Vorgang werden in einem Gigabit Ethernet-Netzwerk weniger als 1 Sekunde benötigt.
Da bei der Migration einer virtuellen Maschine der exakte Ausführungszustand, die Netzwerkidentität und die aktiven Netzwerkverbindungen erhalten bleiben, entstehen keine Ausfallzeiten und keine Unterbrechungen von Anwendersitzungen. Testet man dies mit einem Dauerping, kommt es im Normalfall zum Verlust eines Netzwerkpaketes.
VMware Primary and Secondary nodes
In einem Cluster gibt es zwei verschiedene Arten von Cluster Nodes. Einmal gibt es die Primären Nodes und die Sekundären Nodes.
Die ersten fünf Hosts die in einem Cluster hinzugefügt werden sind automatisch Primäre Hosts. Alle weiteren Hosts die hinzugefügt werden sind automatisch Sekundäre Nodes. Wird ein Reconfigure gemacht dann werden die Rollen neu verteilt! Dies geschieht auf dann durch Zufall.
Was genau unterscheidet die beiden Rollen? Die Primären Hosts halten Informationen über Cluster Einstellungen und den Status aller Nodes. Die Sekundären Nodes senden Ihre Informationen über Ressourcen an die Primären Nodes.
Jede Sekunde senden die Hosts einen ping zu den Primären Nodes. Dies geht von Primären als auch von Sekundären Nodes aus! Über „das.failuredetectioninterval” kann der Zeitabstand geändert werden.
Das es 5 Primäre Nodes gibt erkennt man auch an der Einstellung wie viele Hosts im Cluster ausfallen dürfen. Dies liegt daran das ein Sekundärer Node nicht zu einem primären Node hinaufgesteugt wird wenn ein solcher ausfällt. Aus diesem Grund ist es nicht möglich mehr als 4 Nodes ausfallen zu lassen da dann keine primären Nodes mehr zur Verfügung stehen könnten.
Ein Sekundärer Node kann zu einem primären Node heraufgestuft werden wenn ein primärer Node aus dem Cluster entfernt wird.
