Cluster Shared Volume ist optimal für Live Migration

Erst seit dem Einsatz des Cluster Shared Volume (CSV) kann der Hyper-V mehrere Virtuelle Maschinen (VMs) auf eine LUN zugreifen lassen. Das CSV kann man sich als eine zusätzliche Ebene vorstellen, die aus einem gemeinsamen Speicher auf Basis des Dateisystems NTFS ein Cluster-Dateisystem für die VMs bereitstellt. Kenner des ESX-Ansatzes stellen fest: Das gibt es in anderer Form mit dem Virtual Machine File System (VMFS) auf der Virtualisierungs-Plattform von Vmware seit Jahren.

Als die größte Verbesserung feiert das Microsoft-Lager bei der Vorstellung des Release 2 für den Hyper-V (beziehungsweise beim Hyper-V im Zuge des Windows Server 2008, Release 2) die Hochverfügbarkeitsansätze. Hier tritt nun die Live Migration auf den Plan, die – ähnlich wie es bei VMware mit Vmotion schon seit Jahren möglich ist – ein Verschieben von virtuellen Maschinen (VMs) von einem physikalischen Server auf einen zweiten erlaubt, ohne dass die angeschlossenen Applikationen davon etwas bemerkt. Damit der gleichzeitige Zugriff von mehreren Host auf dieselbe LUN (Logical Unit Number) im Dateisystem Änderungen nötig gemacht.
Bei einem Cluster-Ansatz mit einem Verschieben der VMs von einem physischen Host auf einen anderen, muss das Dateisystem einige Herausforderungen meistern. Denn mehrere Einheiten (Knoten eines Clusters oder mehrere VMs) müssen in einem derartigen Szenario auf eine LUN synchronisiert zugreifen können. Dazu speichert zum Beispiel das VMFS den gesamten Zustand einer virtuellen Maschine an einem zentralen Speicherort.
Traditionelle Dateisysteme wie etwa NTFS lassen immer nur einen Server zu einem Zeitpunkt im Lese- und Schreibmodus auf dieselbe Datei zugreifen. Dagegen handelt es sich bei VMFS um ein speziell konzipiertes Cluster-Dateisystem, das gemeinsamen Speicher (zum Beispiel über ISCSI oder Fibre Channel angebunden) nutzt, um mehreren Instanzen von ESX- oder Vsphere-4-Servern den gleichzeitigen Lese-Schreibzugriff auf denselben Speicherort zu ermöglichen.
Über das Sperren von Festplatteninhalten stellt das VMFS sicher, dass eine virtuelle Maschine nicht von mehreren ESX Server-Installationen zur selben Zeit gestartet wird. Fällt ein Server aus, wird die Sperre für alle betroffenen virtuellen Maschinen aufgehoben, sodass diese auf anderen physischen Servern neu gestartet werden können.

Microsofts Antwort auf VMFS

Um eine entsprechende Funktionalität zu bieten, bringt Microsoft das Cluster Shared Volume (CSV) ins Spiel. Dabei wurde allerdings kein neues Dateisystem konzipiert. Vielmehr setzt diese Technik auf dem bekannten Dateisystem NTFS auf. Das CSV wurde in Form eines zusätzlichen Filtertreibers realisiert. So stellt Microsoft dann eine Synchronisierung der Zugriffe auf eine LUN sicher.
Für die Funktion der Live Migration, also dem Verschieben einer laufenden VM von einem physischen Host auf einen zweiten, ist unbedingt das CSV nötig. Bei Windows Server 2008 R2 benötigt man mindestens die Enterprise Edition, mit dem Failover Cluster, denn nur mit einem aktivierten Cluster steht CSV zur Verfügung. Wer dagegen auf Microsofts kostenlose Variante, den Hyper-V R2, zurückgreift, der bekommt diese Funktion auch kostenlos.
Mit Hilfe des Failover Cluster Manager ist der Administrator in der Lage, für beliebige Volumes das CSV zu aktivieren. Ohne diese Technologie müsste man ein irgendwie geartetes Umschalten einer LUN von einem Rechner-Knoten zum anderen Knoten machen. Üblicherweise entspricht das einem Aushängen (Unmounten) an einem System und einem Einhängen (»Mounten«) an dem zweiten System. Doch das dauert mehrere Sekunden, selbst wenn man diese Aufgaben über Skripting weitgehend automatisiert. Damit würde dieser Ansatz zu lange dauern, denn die angeschlossenen VMs würden die fehlende Verbindung zum Speicher bemerken und die Applikationen müssten dann neu gestartet werden. Zudem ergeben sich Probleme mit der Zuweisung der LUN-Bereiche. Bis zu 16 Knoten im Cluster-Verbund können mit den CSV auf eine einzige LUN gleichzeitig und somit auch alle auf dasselbe Filesystem zugreifen.
Beim CSV haben die Redmonder nach wie vor NTFS im Einsatz – wer gedacht hatte, es gebe ein komplett neues Dateisystem, er wird enttäuscht. Allerdings kommt beim CSV ein Gerätetreiber mit ins Spiel:
Je nach Zugriffsart auf die Disk entscheidet der CSV-Treiber, ob direkt auf die Disk geschrieben wird oder ob ein Umweg nötig ist. Das ist abhängig von der  betreffenden Art der Ein-Ausgabeoperation. Ist es ein Zugriff auf eine VHD, wird direkt geschrieben. Handelt es sich dagegen um einen Zugriff, um die Datei anzulegen – was nichts mit VHD zu tun hat – dann wird das über den so genannten Coordinator Node durchgeführt.
Innerhalb des Failover Clusters gibt es für die CSV einen Owner. Und dieser Owner trägt die Bezeichnung Coordinator Node. Er wickelt alle dateibasierten Aktionen ab, wie das Anlegen einer Datei oder das Löschen, Verschieben einer Datei.
Was parallel von verschiedenen Knoten erfolgen kann, ist der Zugriff auf die VHD-Dateien, also für eine VM. Man kann diese Technologie daher auch nur für Hyper-V verwenden, nicht für andere Szenarien wie etwa SQL Server. CSV gehören, Stand heute, nur zum Hyper-V.
Die Abbildung 3 zeigt ein Beispiel für eine Filesystem-Operation wie das Anlegen deiner Datei. Angenommen ein Knoten, der nicht Coordinator Node sein soll, will eine Datei anlegen. Dann wird er nicht direkt auf der LUN arbeiten, sondern er wird über seinen Coordinator Node mit der LUN verbunden. Der Benutzer merkt da nichts, der Verkehr geht über das Netz und der Coordinator Node ändert die Dateitabelle auf dem NTFS wie gewünscht.
Im Gegensatz dazu, wenn es nun direkt aus einer VHD gelesen werden soll, entscheidet der Gerätetreiber, dass es der Knoten direkt machen (siehe Abbildung 4) kann.
Wenn ein Coordinator Node ausfällt der Eigentümer der LUN ist, entstehen keine größeren Probleme. Denn der Coordinator Node ist nur eine Ressource im Cluster. Wenn sie ausfällt, übernimmt eine andere diese Aufgabe und wird dann eben zum Coordinator für diese CSV.
Das wird noch schwieriger, denn normalerweise verwendet man ja nicht nur eine LUN sondern gleich mehrere. Das heißt bei zehn LUNs müssen auch zehn Coordinator Nodes vorhanden sein. Sollten aber nur fünf physische Knoten existieren, würde jeder dieser Knoten eben für zwei Einheiten der Coordinator Node sein.
Die Vorteile in Bezug auf die Ausnützung des vorhandenen Festplattenplatzes gegenüber Hyper-V in der ersten Version verdeutlicht die Abbildung 5. Früher musste man entweder eine LUN von Knoten A auf B umschalten und wenn dort zehn VMs lagen, musste man alle zehn VMs mitnehmen. Oder das andere Extrem: eine jede VM bekommt eine eigene LUN zugewiesen. Das führt zu einer enormen Platzverschwendung, wenn man zu viel Platz einer einzelnen LUN zugewiesen hat. Mit dem Hyper-V R2 wird das nun anders.

Der Administrator kann eine große LUN anlegen, auf die viele VMs zugreifen. Die teilen sich dann den vorhandenen Platz.
Schaut sich der Administrator mit dem Windows Explorer die Volumes an, zeigt sich, dass CSV auf allen Knoten identische Pfade angelegt hat – nach dem folgenden Muster:

C:\ClusterStorage\Volume1\<root>
C:\ClusterStorage\Volume2\<root>
C:\ClusterStorage\Volume3\<root>

Beim Windows Server 2008 R2 benötigt man die Enterprise-Variante, um an das CSV zu kommen. Doch beim kostenlosen Hyper-V Server R2 ist nun auch die Rolle des Failover Cluster (zusätzlich zur Hyper-V-Rolle) verfügbar. Damit gibt es kostenlose Hochverfügbarkeit und Live Migration. Nur die Gastbetriebssysteme und Applikationen in den VMs sind dann noch zu lizenzieren.
Im Produktivbetrieb ist ein spezielles Netz für die Live Migration sinnvoll, es sollte kein Clientverkehr auf diesem Netz aktiv sein. Prozessorhersteller muss identisch sein und im selben Subnetz liegen. Generell wird maximal eine Live Migration zwischen zwei Knoten zu einer Zeit unterstützt.