Hyper-V-Cluster unter Server 2012 Release 2 optimal einrichten, Teil 1

Bei der Konfiguration von Cluster-Netzwerken mit dem Hyper-V lauern viele Fallstricke. Zudem führen wie im Windows-Umfeld üblich viele Wege zum Ziel. Um sich in diesem administrativen Konfigurations-Dschungel nicht zu verirren, nimmt das NT4ADMINS-Team eine mögliche Konfiguration für einen Hyper-V-Cluster mit angebundenen iSCSI-Storage unter die Lupe. Hier hält sich das Labteam an die von Microsoft vorgegebenen „Best Practice“-Vorgaben und stellt eine durchdachte und reproduzierbare Variante eines Cluster-Netzwerks mit zwei Server-Knoten und unterschiedlichen Netzwerken bereit.

Benötigt ein Unternehmen eine hochverfügbare IT-Infrastruktur, gibt es einige sinnvolle Vorgehensweisen: Neben redundanten Serverbauteilen, mehrfach gesicherten Datenbeständen und unterschiedlichen Netzwerkrouten empfiehlt sich vor allem die Möglichkeit eines Hyper-V-Clusters. So gelangt man zu einer sinnvollen EDV-Konfiguration.

Besonders in dieser „Königsklasse“ der Cluster-Systeme müssen von der Planung, über die Beschaffung, Ausführung, Konfiguration und Dokumentation viele Schritte bedacht werden. Auch ein längerer Testbetrieb des Systems sollte von den Verantwortlichen durchgespielt werden. Denn damit kommt man (Denk-) Fehlern, Konfigurationsproblemen oder Engpässen auf die Schliche.

Grundliegende Planung

Generell lässt sich eine Cluster-Konfiguration mit einer unterschiedlichen Anzahl von Servern betreiben. Die einzelnen Cluster-Mitglieder werden als Knoten oder Nodes bezeichnet, für einen Cluster-Betrieb sind naturgemäß mindestens zwei Server Voraussetzung. Im der aktuellen Version beim Windows Server 2012 Release 2 steigt die maximale Anzahl der unterstützten Knoten pro Cluster auf 64.

In unserer Beispielkonfiguration wird ein Cluster-System mit zwei Nodes aufgesetzt. Die Anbindung des Cluster-Massenspeichers erfolgt über das iSCSI-Protokoll. Für die Kommunikation der Nodes und den Informationsaustausch mit dem Verwaltungsnetz sowie dem Internet kommen unterschiedliche Netzwerke zum Einsatz. Diese werden über dedizierte Netzwerkschnittstellen (NICs) untereinander verknüpft.

Die Überlegungen des NT4ADMINS-Teams führten unter Berücksichtigung der Microsoft-Vorgaben für Cluster-Netzwerke zu einem Cluster-Schema wie in Bild 1 dargestellt. Hierbei kommen insgesamt vier Server zum Einsatz. Diese setzten sich wie folgt zusammen:

• SRV-2012-R2-DC ein physikalischer Domänencontroller auf Basis von Windows Server 2012 R2
• SRV-2012-R2-RDP ein physikalischer Server für den Remotezugriffe aus dem Internet
• SRV-2012-R2-C1 ein physikalischer Server als Cluster-Knoten 1
• SRV-2012-R2-C2 ein physikalischer Server als Cluster-Knoten 2

Des Weiteren wird ein NAS-System vom Hersteller Seagate mit vier Festplatten (jeweils 4 TByte Kapazität) zur Verfügung gestellt. Auch drei weitere Switches sowie ein Router komplettieren neben zwei Client-Systemen den Testaufbau im NT4ADMINS-Labor. Drei der Server kommen vom Hersteller Dell, dagegen stellt der RDP-Server ein Build to Order (BTO) System dar.

Netzwerkplanung

Die Netzwerkkonfiguration besteht in diesem Beispiel aus sechs einzelnen Netzwerksegmenten. Diese Netzwerke sind über dedizierte Netzwerkschnittstellen realisiert. Naturgemäß sollten die IT-Verantwortlichen im Produktivbetrieb darauf achten, dass hier kein Flaschenhals entsteht. Gegebenenfalls müssen die Systembetreuer zunächst die zu erwartende Netzwerklast anhand der virtuellen Maschinen (VMs) und den angebundenen Clients abschätzen.

Nachdem im Vorfeld meist nicht klar ist, mit welcher Auslastung im Netzwerkbereich kurz-, mittel- und langfristig zu rechnen ist, werden hier oftmals hohe Reserven eingeplant. Gegebenenfalls sollten die beschafften Server bei Bedarf auch mit zusätzlichen Netzwerkerweiterungskarten bestückt werden können. Die voraussichtlich hoch beanspruchten Netze werden dann sinnvollerweise mittels mehrerer Netzwerkschnittstellen (NIC-Teaming) verbunden. Zudem planen vorausschauende Systemverantwortliche bei Bedarf weitere eigenständige iSCSI-Netzwerkleitungen ein.

Beide Themen wurden bereits im E-Paper April 2014 (es steht für angemeldete Abonnenten von NT4ADMINS zum Download bereit) näher beleuchtet. Dort befassen sich zwei Beiträge mit der redundanten Speicheranbindung per iSCSI, sowie dem Bündeln von Netzwerkleitungen, um Performance und Verfügbarkeit zu erhöhen.

In der NT4ADMINS-Beispielkonfiguration werden einige der Netzwerkleitungen mittels eines Cross-Over-Kabels realisiert, da es sich um ein System mit nur zwei Knoten handelt. Bei mehr Nodes muss naturgemäß auf eine Netzwerkstruktur mit weiteren Switches zurückgegriffen werden. Für die Kommunikation der Cluster-Knoten und dem restlichen Netzwerk werden in der NT4ADMINS-Konfiuration folgende Netze eingesetzt:

• iSCSI Netzwerk – für die Anbindung des Netzwerkspeicherbereichs
• iSCSI-2 Netzwerk – zusätzlicher Pfad zur Anbindung des Netzwerkspeicherbereichs
• Management Netzwerk – für die Verwaltung / Domänennetzwerk
• VM Netzwerk – für VMs und Clients / Domänennetzwerk
• Live Migration Netzwerk – für die Kommunikation der Clusterknoten bei Live-Migrationen
• CSV-Netzwerk – für Cluster Shared Volume (CSV) und Heartbeat.

Netzwerke im Detail

Die Konfiguration der beiden iSCSI-Netzwerke basiert auf einer rein manuellen IP-Konfiguration. Die jeweiligen NICs werden ohne DNS- und Gateway-Einträge eingerichtet. Bei höherer Netzwerklast können je nach Bedarf und Ausstattung der Server und Speichergeräte weitere Netzwerkleitungen hinzugefügt werden. Nachdem beim iSCSI-Protokoll in den meisten Fällen NIC-Teaming nicht eingesetzt werden soll, müssen hier „mehrfache Pfade für die Ein-Ausgabe“ (Multi Path Input Output, MPIO) herangezogen werden, um die Netzwerklast zu verteilen. Nachdem hier verhältnismäßig wenige Hosts konfiguriert werden, genügt meist ein kleineres Subnetz wie etwa ein Klasse-C-Netzwerk aus unserem Fallbeispiel.

Das Managementnetzwerk steht naturgemäß für Verwaltungsaufgaben zur Verfügung. Hier kommunizieren ebenfalls DHCP- und DNS-Server mit den jeweiligen Knoten, auch Anfrage an den Active Directory Domänencontroller (SRV-2012-R2-DC) werden hier abgewickelt. Ja nach Anforderung und Serveranzahl muss hier ein Subnetz im passenden Bereich gewählt werden. Auch hier kann bereits ein Klasse-C-Netzwerksegment ausreichen.

Eigenes Netzwerk für die VMs

Im VM-Netzwerk werden die einzelnen virtuellen Maschinen unseres Cluster-Netzwerks zusammengefasst. In unserem Beispiel ist das VM-Netz und das Managementnetz im selben Subnetz zusammengefasst. In produktiven Umgebungen müssen auch hier noch die jeweilige Anzahl der Client-Systeme der Unternehmensmitarbeiter mit eingerechnet werden, so dass hier unter Umständen mit einer deutlich höheren Anzahl von benötigten Hostadressen zu rechnen ist. Dies gilt es bei der Wahl der Subnetzmaske zu beachten.Für die Funktion der Live Migration, also der Verschiebung von laufenden VMs von einem Cluster-Knoten auf einen anderen ohne Unterbrechungen, sollte in jedem Fall eigenes Netz zur Verfügung gestellt werden, um laufende Zugriffe bei solchen Verschiebungen nicht zu beeinträchtigen.

Im CSV-Netzwerk läuft die Kommunikation der Cluster-Knoten ab. Hier werden beispielsweise die Zugriffe auf Cluster Shared Volumes (CSV) koordiniert. Damit sind die freigegebenen Cluster-Speicherdatenträger, also die freigegebenen Logical Unit Numbers (LUNs) gemeint. Denn die Zugriffe auf diese Speicherbereiche müssen entsprechend abgeglichen werden. Erfolgen diese doch teilweise gleichzeitig von unterschiedlichen Knoten.

Inkonsistenzen vermeiden

Ohne eine gesonderte Koordination dieser Zugriffe würden ansonsten Inkonsistenzen auftreten. Zudem wird in unserem Beispiel auf diesem Netzwerk noch die direkte Kommunikation der Cluster-Knoten gelegt. Damit ist der sogenannte Cluster Interconnect (auch als Heartbeat bezeichnet) gemeint. Diese Funktion stellt unter anderem sicher, dass die Nodes untereinander Systemeinstellungen, Dienste oder die Erreichbarkeit der einzelnen Cluster-Systeme abgeglichen werden können.

Da diese Verbindung für die Funktionalität des Clusters essentiell ist, kommen hier je nach Konfiguration ebenfalls zusammengefasste Netzwerkleitungen und redundante System zur verbesserten Absicherung zum Einsatz. Auch können die einzelnen Cluster-Knoten bei einem Verlust des Cluster Interconnects oder des Heartbeat-Signals nicht zwischen einem Netzwerkfehler oder abgestürzten Systemen unterscheiden. Somit sind vom Heartbeat-Netzwerkpaketen isolierte Cluster-Nodes bis zur Wiederherstellung dieser wichtigen Anbindung praktisch nutzlos, selbst wenn alle anderen NICs fehlerfrei laufen sollten. In seinen „Best Practices“ gibt Microsoft vor, hier mindestens eine dedizierte Netzwerkleitung, oder besser noch eine mehrfach abgesicherte Kommunikationsleitung beispielsweise per NIC-Teaming zu nutzen.

Vorbereitung für den Cluster-Betrieb

Als vorbereitende Maßnahmen konfigurierte das NT4ADMINS-Team zunächst die schon angesprochenen Netzwerkverbindungen. Hier bewährt es sich, bei den unterschiedlichen Subnetzwerken allen Endgeräten die gleichen IP-Endadressen zuzuweisen. Beispielsweise erhalten alle Netzwerkkarten des Servers „SRV-2012-R2-C1“ die Endadresse 251. Beachten muss der Administrator hier einiges. Denn nicht alle IP-Eigenschaften werden für die insgesamt sechs unterschiedlichen Netze gleich konfiguriert. Auch die Netzwerkmetrik einzelner Verbindungen muss entsprechend angepasst werden, denn die Cluster-Kommunikation wird über die Netzwerkschnittstelle mit der niedrigsten Metrik abgewickelt. Dazu später mehr.

Für den Anfang setzt der Systemadministrator aussagekräftige Benennungen für die einzelnen Schnittstellen fest, wie in Bild 2 zu sehen. Nachdem der Domänen-Controller (Hostname SRV-2012-R2-DC) bereits im Management Netzwerk verfügbar ist, werden im nächsten Schritt die Netzwerkkarten entsprechend verkabelt. VM- und Managementnetzwerk werden in diesem Beispiel über einen Switch miteinander verbunden. Anschließend werden die entsprechenden Server der Domäne hinzugefügt und neu gestartet. Nach einer Prüfung der Netzwerkverbindungen und DNS-Anfragen werden die weiteren NICs verkabelt.

Die Verbindungen für das CSV- und Live-Migration-Netzwerk werden in diesem Aufbau über Crossover-Kabel realisiert, hier kommen manuell konfigurierte Netzwerkeinstellungen zum Einsatz. Zudem laufen die iSCSI-Netzwerke über separate Switches und sind ebenfalls mit manuell zugewiesenen IP-Adressparametern versehen.

Nun muss noch die Metrik der CSV- und Live-Migration-Netzwerkverbindung verringert werden, damit die jeweils passenden Netzwerkleitungen für den Heartbeat, Cluster Interconnect und Live Migration herangezogen wird. Dazu bediente sich das NT4ADMINS-Team der Powershell. Hier liest der Systembetreuer zunächst die Metrik-Einstellungen aller Adapter aus, setzt die Metrik des CSV Netzwerks auf einen Wert von 100 (bei Live Migration 500) und überprüft die korrekte Konfiguration wie in Bild 3 zu sehen ist. Das Powershell-Kommando sieht wie folgt aus:

Import-Module FailoverClusters
Get-Clusternetwork | ft Name, Metric, Autometric
( Get-ClusterNetwork "CSV" ).Metric = 100
( Get-ClusterNetwork "Live Migration" ).Metric = 500

Gegebenenfalls ändert der Systembetreuer diese Werte in der grafischen Benutzeroberfläche (GUI). Diese Option ist in den erweiterten Einstellungen des TCP/IPv4-Netzwerkprotokolls versteckt. Hier ist standardmäßig die Option „Automatische Metrik“ aktiviert, dies kann an dieser Stelle abgeändert werden und benutzerdefinierte Werte eingetragen werden.

Im nächsten Schritt werden die passenden Rollen und Features auf den beiden Servern installiert wie in Bild 4 zu sehen. Die Punkte Failover-Cluster und MPIO werden für diesen Vorgang herangezogen. Das MPIO-Feature ist wie bereits angesprochen für die redundante Anbindung des iSCSI-Targets vorgesehen.

Zwar sind die Netzwerkverbindungen bereits sinnvoll benannt, so dass die Systembetreuer den Zweck der einzelnen NICs sofort erfassen können, allerdings müssen die Netzwerkverbindungen auch noch für das Clusternetzwerk dediziert hinzugefügt werden. Dazu werden die einzelnen NIC-Einstellungen noch weiter angepasst. Hier muss vor allem darauf geachtete werden, dass bei den privaten Netzwerken (iSCSI, Live Migration und CSV) die jeweiligen IP-Adressen nicht in Diensten zur Namensauflösung (DNS, NetBIOS) registriert werden.

Dazu navigiert der Systembetreuer bei den betroffenen Adaptern in die erweiterten Einstellungen des IPv4-Protokolls und deaktiviert im Reiter „DNS“ die Option „Adressen dieser Verbindung in DNS registrieren“ wie in Bild 5 zu sehen. Zusätzlich ist der Eintrag „NetBIOS über TCP/IP deaktivieren“ im Reiter WINS auszuwählen.

Im Anschluss startet der Systembetreuer den Konfigurationsüberprüfungs-Assistenten. Hier werden die wichtigsten Punkte und Konfigurationseinstellungen nochmals geprüft. In unserem Fall gibt der Assistent grünes Licht, und das System ist bereit für das Erstellen des Clusters. Allerdings treten einige Warnungen auf, der detaillierte Bericht listet beispielsweise leicht unterschiedliche Hardware-Ausstattungen auf den beiden Servern auf, da unterschiedliche CPUs verbaut sind. Solche Warnungen können in unserem Beispiel ignoriert werden, im besten Fall kommen naturgemäß identische Systeme zum Zuge. Diesen Bericht sollte der Administrator genau durchforsten bevor weitere Schritte unternommen werden, schließlich könnten sonst im laufenden Betrieb Fehler auftreten.

Nun führt der nächste Weg den Administrator in den Failover-Cluster-Manager. Wie in Bild 6 zu sehen wählt der Systembetreuer die beiden vorgesehenen Server als Cluster-Knoten aus. Hier achtet der Systembetreuer darauf dem Cluster eine eigene, dedizierte IP-Adresse (in unserem Beispiel aus dem Managementnetzwerk) hinzuzufügen. In unserem Beispiel wird hier die Adresse 192.168.2.250 verwendet. Nach eine Wartezeit und obligatorischen Neustartvorgängen taucht der neu erstellte Cluster im Failover-Cluster-Manager auf: damit ist die Ersteinrichtung des Clusters abgeschlossen.

Zusammenfassung

Bei entsprechender Planung und gewissenhafter Konfiguration kann der Systembetreuer bereits mit wenigen Mittel einen hochverfügbaren Systemverbund erstellen. Besonders redundante MPIO-Leitungen zur Storage-Anbindung über preiswerte Ethernet-Verkabelung machen diese Konfiguration auch für kleine und mittlere Unternehmen interessant. Wenn einzelne Netzwerkleitungen für die erwartete Auslastung nicht ausreichend sein sollten, kann der Netzwerkadministrator beispielsweise auf 10 GBit/s-Ethernet-Schnittstellen erweitern, falls die eingesetzte Infrastruktur ( vor allem die Switches) dies auch unterstützt.
Auch durch den Einsatz von NIC-Teaming können Flaschenhälse umgangen werden. So fasst der Systembetreuer gegebenenfalls mehrere GBit/s- oder 10 GBit/s Ethernet-Leitungen zusammen. Hier behält der Netzwerkadministrator auch die Aufteilung der einzelnen Netzwerk-Ports und deren Aufteilung auf die Netzwerkswitches im Blick. Die meisten Netzwerkkarten sind im Serverbereich mit mehreren Netzwerkschnittstellen bestückt. So hilft es wenig, wenn beispielsweise vier Ports auf derselben Einsteckkarte zum Zwecke der Hochverfügbarkeit zu einer Leitung gebündelt werden. Denn bei Ausfall der Erweiterungskarte würde bei dieser Konfiguration die gesamte Verbindung ausfallen. Folglich gilt es bereits bei der Planung auf viele Details zu achten.

Ausblick auf die noch anstehenden Themen

Die Inbetriebnahme des Clusters, das korrekte Konfigurieren von Hyper-V, sowie das Anlegen von VMs und das Thema Live Migration behandelt das NT4ADMINS-Labteam im zweiten Teil dieses Beitrags. Zudem ist im Netzwerkbereich nach Abschluss der Cluster-Konfiguration noch eine weitere Option für die Live-Migration zu definieren, die einzelnen Netzwerkschnittstellen müssen im Failover-Custer-Manager noch in die richtige Reihenfolge gebracht werden.

Auch ist die Hochverfügbarkeit in diesem Testaufbau im Bereich des Storage-Systems nicht gegeben. Aufmerksame Leser können einwenden, dass der in unserem Beispiel per iSCSI angebundene Speicherbereich der NAS eine kritische Komponente darstellt. Das ist soweit korrekt, im dritten Teil dieser Beitragsserie werden wir auf das Thema Backup im Hyper-V-Cluster eingehen, und mögliche Problemlösungsstrategien bei Ausfällen der freigegebenen Cluster-Datenträgern aufzeigen.

Florian Huttenloher