Hyper-V 3.0: Was (wahrscheinlich) kommt, Teil 3

Dies ist der dritte Teil unserer kleinen Artikelserie zu den Neuerungen in Hyper-V 3.0 unter Windows Server “8”. Zur Erinnerung: Das neue Server-Windows ist noch in der Pre-Beta-Phase, daher sind alle Informationen nur eine Illustration dessen, was vielleicht kommen wird.

In diesem Artikel geht es vor allem um Funktionen zur Verfügbarkeit virtueller Maschinen. Das ist selbstverständlich eine Kernanforderung an die Virtualisierung: Schließlich will man sich auf seine virtuellen Server verlassen können. In der aktuellen Fassung von Hyper-V gibt es dazu die Clusterfunktion und die “Live Migration”, obwohl letztere nur die Verfügbarkeit in planbaren Situationen gewährleistet und keine Ausfallsicherheit bietet. Der Nachteil: Ein Cluster erzeugt erheblichen Aufwand und – wenn man es richtig macht – durchaus auch erhebliche Kosten. Mit Windows Server 2008 R2 gibt es kaum eine sinnvolle Möglichkeit, unterhalb der Cluster-Ebene die Verfügbarkeit zu erhöhen, jedenfalls nicht mit Bordmitteln.

In Hyper-V 3.0 ändert sich diese Situation dramatisch. Im Vordergrund stehen dabei die Replikations-Funktion, die Live Migration und der Cluster-Aufbau.

Replikation

Hyper-V kann in der neuen Version einzelne virtuelle Maschinen von einem auf einen anderen Host replizieren. Diese Übertragung erfolgt asynchron auf Basis von VM-Snapshots: Die replizierte VM ist also kein synchrones Abbild des Originals, sondern steht immer in einer gewissen Latenz. Das Szenario, das man hiermit bedienen kann, ist das schnelle Umschalten auf ein “nahezu” aktuelles Ausweich-System mit derselben Identität im Netzwerk. Das Prinzip unterscheidet sich also von der Funktion “Fault Tolerance” in VMware oder der Marathon-Integration in Citrix XenServer.

Die Voraussetzungen für die Replikation sind sehr gering. Man benötigt keinen Cluster, kein SAN und zumindest grundsätzlich auch keine spezielle Infrastruktur. Sobald man zwei oder mehr Hyper-V-Hosts hat, kann man die Replikation aktivieren und dann für einzelne VMs einrichten. Die Hosts müssen dabei auch nicht demselben Active Directory angehören (auch wenn dies die Konfiguration erleichtert). Man kann problemlos VMs von einer lokalen Host-Festplatte auf die lokale Platte eines anderen Hosts replizieren.

Folgende Einstellungen kann man in der Developer Preview auf Host-Ebene vornehmen, um die Replikation vorzubereiten:

Für einzelne VMs hilft dann ein Assistent durch die nötigen Einstellungen:

Eine interessante Zusatzfunktion: Die Replikation kann nicht nur den jeweils aktuellen Stand der VM auf einem anderen Host vorhalten, sondern auch eine Historie. Das ermöglicht in bestimmten Situationen, Fehler “rückgängig” zu machen. Vorsicht aber: Nicht jede Applikation wird damit klarkommen, dass plötzlich ein “alter” Zustand aktiv ist (beispielsweise Active Directory bis einschließlich Windows Server 2008 R2).

Sollte die zu replizierende VM bzw. der Inhalt ihrer Festplatte(n) bereits sehr groß sein, so kann man die Erstreplikation auch auf Basis eines Mediums vornehmen, etwa einer transportablen Festplatte. Danach kann die Hyper-V-Replikation dann die Unterschiede (Delta) replizieren.

Live Migration

Die Live Migration kam in Hyper-V erst recht spät hinzu. Während sie ursprünglich schon im ersten Release mit Windows Server 2008 geplant war, hat es noch etwa anderthalb Jahre länger bis zum Nachfolger 2008 R2 gedauert,  bis das Verschieben einer VM von einem Host auf einen anderen ohne Funktionsunterbrechung möglich war. Nun macht Microsoft den nächsten Schritt.

In der aktuellen Fassung von Hyper-V ist für die Live Migration ein Cluster nötig. Das erfordert auf jeden Fall ein SAN und darüber hinaus eine clusterfähige Version des Betriebssystems, also entweder den spartanischen (und im Support eingeschränkten) kostenlosen Hyper-V Server 2008 R2 oder aber die teure Enterprise oder Datacenter Edition von Windows. In Windows Server “8” wird das Cluster-Erfordernis entfallen: Die Live Migration wird auch zwischen “einzeln stehenden” Hostservern funktionieren, und als Ablage für die virtuellen Maschinen kommt auch eine Netzwerkfreigabe (ein CIFS-Share) in Betracht – oder gleich die lokalen Platten des Hostsystems. Um es deutlich zu sagen: Für die Live Migration in Windows Server “8” wird man kein gemeinsames Speichermedium an den Hosts mehr benötigen. Natürlich erfordert dies entsprechend leistungsfähige Hardware und ein performantes Netzwerk, denn die Speicherdaten müssen so von einem Host zum anderen gelangen. Allerdings ist Microsoft derzeit der einzige Virtualisierungsanbieter, der VM-Übertragungen im laufenden Betrieb ohne gemeinsamen Speicher ermöglicht (wenn auch derzeit nur in Pre-Beta-Fassung).

Ebenso ermöglicht potente Hardware im neuen Windows-Server auch eine höhere Zahl gleichzeitiger Live Migrations. Um das Abbruchrisiko einzuschränken, kann man die Zahl paralleler Übertragungen pro Host einschränken.

Cluster

Für viele Zwecke bleibt trotz Replikation und verbesserter Live Migration das Clustering von Host-Servern die Methode der Wahl, denn nur sie ermöglicht das automatisierte Fail-over in unerwarteten Fehlersituationen. Neben den deutlich erweiterten Limits, die wir im ersten Teil unserer Artikelserie vorgestellt haben – bis zu 64 Server pro Cluster, bis zu 4000 gleichzeitig aktive VMs – steht hier vor allem die Datenablage auf klassischen Dateifreigaben im Vordergrund. Sie erlaubt hochverfügbare Installationen ohne SANs. Gleichzeitig hat Microsoft einiges getan, um Cluster-Konstrukte noch flexibler zu machen. Die Hardware der Hosts darf sich noch mehr voneinander unterscheiden als bislang bereits.

Eine weitere Serverkomponente ist auch für kleinere Virtualisierungsumgebungen interessant. Im neuen Server-Windows ist das iSCSI-Target enthalten, das Microsoft für Windows Server 2008 R2 erst vor kurzem als kostenlosen und unterstützten Aufsatz freigegeben hat.