Storage-Architektur für Hyper-V-Cluster – Teil 1
Ab Windows Server 2008 Release 2 steht mit den »Cluster Shared Volume« ein Speicherkonzept bereit, um auf der Virtualisierungs-Plattform Hyper-V zu ausfallsicheren Systemen zu kommen. Dabei ergeben sich für das Speicherdesign einige Herausforderungen.
Mit der Version des »Windows Server 2008 Release 2« (R2) ist der »Hyper-V« erwachsen geworden. Damit hat Microsoft eine sehr wichtige Funktionalität ins Spiel gebracht, die in einem unternehmensweiten Produktiveinsatz für eine Server-Virtualisierungs-Lösung unabdingbar ist: Man kann viele virtuelle Maschinen (VMs), die auf mehreren Hosts (sprich Knoten) in einem Cluster laufen, auf einem einzigen Speicher-Volume ablegen. Dieser Vorteil kommt für den Hyper-V mit den sogenannten »Cluster Shared Volume« (CSV) ins Spiel. Letztendlich wird damit auch eine Basis für das Verschieben von VMs im laufenden Betrieb (ohne dass eine Ausfallzeit anfällt) – die so genannte »Live Migration« – gelegt.
Cluster Shared Volume optimiert Live Migration
Mit einem Konzept wie den CSV lässt sich die Verwaltung für die gesamte Konfiguration deutlich vereinfachen und gleichzeitig gibt es weniger Fehlerquellen – verglichen mit der Alternative, jede VM in einem eigenen Volume abzulegen. Des Weiteren eröffnet genau diese Funktionalität auch den Weg in das Cloud Computing – sprich der Aufbau einer »Private Cloud« setzt eine derartige Funktionalität voraus. Und die Konkurrenz im Bereich der Server-Virtualisierung, VMware, bietet eine derartige Funktionalität schon seit Jahren.
Das Thema Hochverfügbarkeit/Ausfallsicherheit ist für die Server-Virtualisierung im Produktiveinsatz extrem wichtig. Denn bei der Server-Virtualisierung agieren eine Vielzahl von virtuellen Systemen mit geschäftskritischen Applikationen in den VMs auf der Hardware. Fällt hier ein System aus, zieht das die gesamten VMs mit herunter. Daher ist die Vermeidung eines »Single Point of Failure« oberste Priorität.
Mit dem Clustern von mehreren Hyper-V-Host lässt sich dieses Problem angehen. Hierzu kann man das WFC (»Windows Failover Clustering«) verwenden. Dabei wird eine VM zu einer »Cluster Resource Group« gemacht und die Daten für die VM (also die Dateien, die eine VM ausmachen) werden alle auf einer Speichereinheit abgelegt, auf die auch alle anderen Knoten (in diesem Fall handelt es sich um Hyper-V-Hosts) des Clusters Zugriff haben. Aus diesen Ausführungen leitet sich ebenfalls das Grundprinzip des Speicher-Designs ab: Ein Speichernetzwerk ist hier die Regel – als Basis von Fibre Channel oder iSCSI sind hierzu ausfallsichere Subsysteme anzubinden.
Beim Thema Clustering hatte sich Microsoft nicht mit allzu viel Ruhm bekleckert. Das ursprüngliche Konzept – noch aus den Tagen von »Windows NT 4.0 Server« (Codename »Wolfpack«) – arbeitete nach dem Prinzip des »Shared Nothing«. Dazu musste man eine LUN (Logical Unit) auf dem gemeinsamen Speicher erzeugen. Diese LUN wurde dann physikalisch mit allen Knoten des Clusters verbunden. Auf der LUN wurde dann ein neues Volume erzeugt und formatiert. Dieses neue Volume ist dann auch allen Knoten – der Einfachheit halber sprechen wir im Folgenden von nur zwei Knoten – des Clusters sichtbar, und zwar in Form eines Laufwerksbuchstabens. Dann war der gewünschte Dienst, der geclustert werden sollte, noch auf den Cluster zu bringen(sprich es musste damit eine Cluster Resource Group angelegt werden) und dann galt es noch, die Daten des Clusters auf dem gemeinsamen Volume abzulegen. Über die »Cluster Resource« wurden der geclusterte Dienst und das gemeinsame Volume dann zusammengehängt.
Angenommen es arbeiten die beiden Knoten in einem »Active/Passive Cluster« zusammen, dann wird der betreffende Dienst nur auf einem Knoten aktiv sein. Das gemeinsame Volume, das ja an die beiden Knoten angebunden ist, wird nur auf dem aktiven Knoten aktiv sein. Auf dem passiven Knoten wird es dagegen nicht – der Grund dazu liegt beim Windows-Betriebssystem: Zwei Windows-Systeme dürfen sich kein gemeinsames Volume teilen. Beim gleichzeitigen Zugriff von beiden Systemen könnte es zu Dateninkonsistenzen kommen – vor allem bei den Metadaten eines Dateisystems (wie etwa die Angaben der einzelnen Dateigrößen) ist da Ärger zu erwarten. Daher lautet die Vorgabe: Es darf immer nur ein Windows-System der Besitzer des Volume sein und somit die Aktionen auf das Volume ausführen.
Diese grundlegende Konzeption hat sich sozusagen über Jahrzehnte bei Windows nicht geändert. Selbst beim »Windows Server 2008«, der erstmals den Hyper-V als Virtualisierungs-Rolle mit sich brachte, wird das Prinzip noch verfolgt, dass nichts geteilt wird (»Nothing Shared«). Zwar war es machbar, dass die VMs in einem Cluster hochverfügbar sind, doch eine jede VM musste dazu auf einem eigenen Volume im Speichernetzwerk liegen.
Noch beim Windows Server 2008 sah die Praxis so aus, dass man für jede VM eine eigene LUN bereitstellen musste, wenn man die Hochverfügbarkeit als Designziel ausgegeben hatte. Die Dateien für die VM wurden auf der zugehörigen LUN gespeichert. Und diese LUN war immer nur auf dem Knoten im Cluster aktiv, auf dem die VM auch gerade lief. Damit war dann ein Failover für jede VM zwischen den Hosts im Cluster machbar.
Als Alternative gab es noch die Variante, eine Anzahl von VMs auf einem einzigen Host abzulegen. Dann müssten die VMs Bestandteil einer einzigen »Cluster Resource Group« sein. Doch dabei handelt man sich ein gravierendes Problem ein: Die VMs sind dann nicht mehr voneinander unabhängig, sprich die gesamte Gruppe müsste beispielsweise verschoben werden. Und zudem haben die Verwaltungs-Tools damit ihre Probleme: Der »System Center Virtual Machine Manager 2008« (SC VMM 2008) zum Beispiel unterstützen eine derartige Konstellation nicht.
Laufwerksbuchstaben bringen Probleme
Des Weiteren kommt noch eine Einschränkung ins Spiel: Jedes gemeinsame Volume bekommt einen Laufwerksbuchstaben zugewiesen. Doch ein Hyper-V-Cluster könnte ja auch unter Umständen 1000 und mehr VMs beherbergen. Das bedeutet dann aber auch, dass 1000 Volumes einen Laufwerksbuchstaben benötigen.
Doch dazu kann der Administrator auf Laufwerke ohne Laufwerksbuchstaben ausweichen – doch dabei wird ein jedes Laufwerk dann mit Hilfe einer schwer zu merkenden GUID (»Globally Unique Identifier«) angegeben. Für die Verwaltung dieser Einheiten bedeutet das dann eine Vielzahl von »Copy&Paste«-Vorgängen mit diesen GUIDs.