Mit dem Windows Server 2008 R2 und dem aktualisierten Hyper-V hat Microsoft mittlerweile seine eigene Lösung zum Aufbau virtueller Infrastrukturen auf den Markt geworfen die sich mittlerweile auch neben den etablierten Lösungen wie VMWare sehen lassen kann.
Dadurch dass der Hyper-V in der Windows Server Lizenz bereits integriert ist entsteht hier gerade für kleinere IT-Umgebungen eine attraktive Möglichkeit zum schnellen Aufbau ein virtualisierten Umgebung.
Doch sobald die ersten betriebswichtigen Server virtualisiert sind fällt schnell wieder der neidische Blick auf Features wie Live-Migration, die es ermöglichen die Virtualisierung auf mehreren Servern als Basis aufzubauen und damit auch den Ausfall einzelner Host-Server zu überbrücken.
Dieser Erfahrungsbericht beschreibt den Aufbau eines Hyper-V Clusters in einer kleinen IT-Umgebung und soll damit den Beweis antreten dass Hyper-V nicht nur was für große IT-Infrastrukturen ist.
Los geht’s .. erst mal ein SAN in Betrieb nehmen
Ohne einen gemeinsamen Speicher sind unsere Ziele nicht zu erreichen, also muss als erstes ein kleines SAN aufgebaut werden.
Um hier in einer kleinen Umgebung die Kosten nicht explodieren zu lassen haben wir uns für iSCSI als Basis entschieden da so schon für rund 1000 EUR unser SAN mit einer Kapazität von 2 TB aufgebaut werden konnte. Als Speicher kann ein Gerät aus den Hause QNAP zum Einsatz, das zusätzlich zur Bereitstellung der iSCSI Laufwerke auch Daten als Windows Netzlaufwerk direkt anbieten kann.
Für die Verbindung zwischen den Servern und dem Storage wurde ein eigenes Gigabit-Netzwerk installiert, so dass alle Server sowie der Storage mit einem Netzwerkinterface im regulären LAN und mit einem Interface in SAN verbunden sind.
Dass iSCSI hier nicht die Leistungsfähigkeit von SAS oder FibreChannel erreicht wurde aufgrund der geringeren Kosten in Kauf genommen. Auch die Tatsachen dass mit dem Storage ja noch ein Single Point of Failure existiert ist angesichts der Tatsache dass hier einen kleine Infrastruktur betrachtet wird erst einmal akzeptabel.
Um die Performance zu verbessern wurde auf den SAN-Netzwerkadaptern die Option Jumbo Frames aktiviert. In einfachen Tests konnte so eine Steigerung der Schreibgeschwindigkeit von ca. 90 MB/Sekunde auf 140 MB/Sekunde erzielt werden.
Einrichtung des Windows Clusters
Nachdem das SAN eingerichtet ist geht es jetzt an die Einrichtung des Clusters.
Auf beiden Servern muss zuerst das Feature Failover-Cluster installiert werden, anschließend werden die beiden Server wird mit dem Assistenten zu einem Cluster zusammengefügt. Der Cluster erhält eine neu IP im LAN und auch ein virtuelles Computerkonto im Active Directory.
Über den Failovercluster-Manager werden abschließend noch die Freigegebenen Clustervolumes (Cluster Shared Volumes) aktiviert.
Einrichtung des Cluster Shared Volumes
Aus dem SAN wurde zur Speicherung der virtuellen Maschinen ein iSCSI Laufwerk erstellt und dieses wurde auf dem ersten Server über den iSCSI-Initiator hinzugefügt. Die daraufhin in der Datenträgerverwaltung erscheinende neue Festplatte wurde online geschaltet, initialisiert und es wurde eine große NTFS Partition angelegt.
Auf dem zweiten Server wurde das iSCSI Laufwerk ebenfalls hinzugefügt und erscheint auch dort als Laufwerk.
Im Failovercluster-Manager können wir jetzt unter Speicher einen neuen Speicher hinzufügen, unser neues Laufwerk wird hier nur aufgelistet wenn es zuvor auf allen Servern als Laufwerk eingebunden wurde.
Anschließend wird unser neuer Speicher im Failovercluster-Manager unter Freigegebene Clustervolumes ebenfalls hinzugefügt. Unser Laufwerk hat jetzt keinen Laufwerksbuschstaben mehr sondern es steht unter C:\ClusterVolumes\Volume1 zur Verfügung.
Der Ordner “Volume1” kann über den Windows Explorer umbenannt werden und steht dann auf allen Clusterknoten unter diesem Namen zur Verfügung.
Einrichtung der Virtuellen Maschinen
Die Virtuellen Maschinen werden jetzt nicht mehr über die Hyper-V Verwaltung angelegt sondern über den Failover-Cluster als neuer Dienst hinzugefügt.
Die Erstellung der Virtuellen Maschine erfolgt dann wie gewohnt mit dem Assistenten des Hyper-V Managers hierbei muss jedoch darauf geachtet werden, dass die Konfiguration und die virtuellen Festplatten auf dem Cluster Shared Volume gespeichert werden.
Nach der Einrichtung erscheint die neue Virtuelle Maschine sowohl in dem Failovercluster-Manager als auch in dem Hyper-V Manger des jeweiligen Servers.
Wenn die Server in dem Cluster nicht exakt die gleiche CPU verwenden sollte zudem über die Einstellungen der virtuellen Maschine im Hyper-V Manager die Prozessorkompatibilität aktiviert werden um Probleme bei einer späteren Live-Migration der Maschinen auszuschließen. Trotz dieser Einstellung ist eine Migration Zwischen Intel und AMD-CPUs jedoch nicht möglich.
Erster Test: Schnellmigration (Quick Migration)
Jetzt wird es ernst und in unserer neuen Umgebung können die angelegten Virtuellen Maschinen migriert werden. Die Schnellmigration dauert erwartungsgemäß einige Minuten, da hierfür ja die virtuelle Maschine gespeichert und wider gestartet wird. Dafür lief die ohne weitere Probleme und ist gut nutzbar solange ein Ausfall der virtuellen Maschine verkraftet werden kann.
Zweiter Test: Live-Migration
Die Schnellmigration verlief schon mal gut, also ist es jetzt an der Zeit die Live-Migration zu testen. Da in diesem Setup die Performance nicht so optimal wie in einer richtigen Enterprise-Umgebung ist merkt man auch eine Live-Migration mit einem Ausfall von ca. 5 Sekunden für den Transfer der virtuellen Maschine was in der hier vorgestellten Umgebung jedoch einen akzeptablen Ausfall darstellt.