Netzwerkkonfiguration im Hyper-V Cluster

Ein Hyper-V Cluster soll möglichst viele Netzwerkkarten besitzen. Das ist vielen bekannt. Wie konfiguriert man aber jetzt die Netze, wenn man, wie in unserem Beispiel, sechs davon hat? Nachdem ich bereits in unserem Artikel “Hyper-V Cluster und Netzwerkkarten Bindungen” auf die einzelnen Protokolle und Bindungen der Netzwerkkarten eingegangen bin, beschreibe ich in diesem Artikel unsere momentane “Best Practice” zur Hyper-V Cluster Netzkonfiguration. Diese basieren neben unseren Erfahrungen auch auf Empfehlungen und Support Richtlinien von Microsoft.

Bevor wir aber mit den “Best Practice” loslegen, möchte ich erst mal, anhand der Grafik rechts, unseren Testaufbau verdeutlichen. In der Mitte sieht man unsere zwei HP Proliant DL160 G6 Server Systeme, aus denen später der Hyper-V Cluster gebaut wird. Ganz unten haben wir einen SAN Storage, eine NetApp FSA2050, die wir per iSCSI redundant anbinden. Jeder der blauen Balken stellt dabei ein Netzwerk dar. Diesen sind von oben nach unten:

• Management – Über dieses Netz wird der Cluster verwaltet (Remote Administration, Updates, SystemCenter Agenten, Host und VM Backup)
• VM – Netzwerk über das die virtuellen Maschinen mit der “Außenwelt” kommunizieren
• CSV – Heartbeat und (Privates) Cluster Netzwerk über das der Cluster Informationen austauscht und auch der „Redirect Access“ der Cluster Shared Volumes abgewickelt wird
• Livemigration – Netz über das der Speicher einer VM, die auf einem anderen Host migriert, übermittelt wird
• iSCSI – SAN Netzwerk für die Kommunikation der Hyper-V Hosts mit dem Storage (Redundant per MPIO)
• iSCSI2 – SAN Netzwerk für die Kommunikation der Hyper-V Server mit dem Storage (Redundant per MPIO)

In der Grafik sieht man auch die Beispiel IPv4 Konfiguration. Es sind insgesamt fünf private Netze involviert. Das Management und VM Netzwerk sind in dem allgemeinen Kommunikationsnetz, in dem sich auch andere Server und Clients befinden (hier 192.168.210.0/23). Es kann geroutet werden und mit dem Internet über einen Firewall kommunizieren. Allen anderen vier Netze zwischen den Hosts und dem Storage ist gemeinsam, dass sie nicht geroutet werden. Die Aufgabe dieser Netze habe ich oben schon angerissen. Im Verlauf des Artikels werden wir nochmal bei der Bindung und Priorisierung der Adapter etwas genauer darauf eingehen.

Anmerkung: Auch wenn einem sechs Netzwerkadapter viel vorkommen, so ist diese Konfiguration, zumindest wenn man iSCSI einsetzt, noch nicht optimal. Im Idealfall benötigt man noch ein bis zwei Adapter mehr. Wieso? Zum einen sollte das Private Cluster Netzwerk, bei uns kurz CSV genannt, in zwei Netze aufgeteilt werden: das Heartbeat Netz und das eigentliche Cluster Shared Volume Netzwerk. Dann kann man die Cluster Kommunikation (der Cluster Heardbeat) und den Redirected Access von einander trennen (Empfehlung Microsoft). Genauso wird man auch das VM Netz oft mit mehr als einem Adapter betreiben und dazu auf Teaming zurückgreifen (Einen guten Artikel hierzu findet man bei Michel Lüscher auf dem Blog: How-To: Netzwerkkarten Teaming mit Hyper-V). Unsere gezeigte Konfiguration ist allerdings ein guter Kompromiss und ist auch so in unserem Lab aufgebaut.

Netz Überlegungen

Nun aber zur eigentlichen Konfiguration. Nach der Installation des Betriebssystems Windows Server 2008 R2 SP1, wurden alle sechs Netzwerkkarten erkannt. Wichtig ist, dass man nun die neusten Netzwerkkartentreiber installiert.

Wenn man jetzt die Netzwerkkonfiguration öffnet, geht man aus Gründen der Übersicht zuerst hin und deaktiviert alle Netzwerkkarten, bis auf das Management Interface. Als Nächstes macht man sich Gedanken, wie die Netzwerk Adapter am besten verteilt werden, damit auch die Redundanz richtig gewährleistet ist. Dabei soll verhindert werden, dass z.B. iSCSI und iSCSI2 auf dem gleichen Netzwerk Adapter konfiguriert sind. Wenn man unterschiedliche Netzwerkkarten in dem Hyper-V Host verbaut hat, dann spielen bei der Verteilung auch die Fähigkeiten der Adapter eine Rolle. Was heißt das in unserem Fall? Die beiden HP Proliant DL160 G6 haben jeweils eine onboard Intel Dualport und eine zusätzliche Intel Quadport Netzwerkkarte I340-T4 verbaut. Die I340-T4 besitzt verschiedene Optimierungen für iSCSI und Virtualisierung (z.B. TCP Segmentation and Checksum Offload, RSS und VMDq hier sind die Specs). Nach Abwägen der Optionen haben wir die Funktionen der Netzwerke wie folgt verteilt:

onboard Dualport Adapter: Management und iSCSI

Quadport Adapter: VM, Livemigration, CSV und iSCSI2

Danach sieht das Ganze wie im Screenshot rechts aus.

Jetzt vergeben wir für alle Netzwerk Ports, bis auf das VM Netz, eine feste IP Adresse aus den jeweiligen Netzen. Wir haben uns dabei angewöhnt, dass das letzte Oktett der IP-Adressen der Hyper-V Hosts in allen Netzen gleich ist. Ein Beispiel: Wenn, wie in unserer Konfiguration, HyperV6 in unserem Management-Netz die IP-Adresse 192.168.210.26 hat, dann bekommt er auch in allen anderen Netzen die Endadresse “x.x.x.26”. Unten sehen Sie exemplarisch die IP-Konfiguration des Livemigration Netzes.

Bei der IP-Konfiguration wird, außer beim Management Netzerk, nirgendswo ein Gateway oder ein DNS Server eingetragen. Zusätzlich wird bei diesen privaten Netzwerken unter DNS die Checkbox “Adresse dieser Verbindung im DNS registrieren” entfernt. Das ist wichtig, damit sich der Hyper-V Host nicht unter den IP-Adressen der Netze Livemigraton, CSV, iSCSI und iSCSI2 beim DNS registriert. Weiterhin sollte man unter dem Reiter WINS die Option “NetBIOS über TCP/IP deaktivieren” aktivieren (siehe Screenshot oben).

Anmerkung: Weitere Optimierungen, welche früher für einen Cluster vorgenommen wurden, sollten bei einem Hyper-V Cluster nicht durchgeführt werden (Siehe Michels Artikel: Error “Cluster Shared Volume is no longer available” mit Hyper-V Failover Cluster)

Nochmals, all das geschriebenen gilt nicht für das Management Netzwerk. Dieses wird wie gehabt mit Gateway und DNS Server konfiguriert. Auch wird die DNS und NetBIOS Konfiguration mit den Standardwerten belassen.

Hyper-V Rolle installieren

Bevor wird die Hyper-V Rolle installieren, achten wir darauf, dass auf dem VM Netzwerkinterface DHCP eingeschaltet ist. Dann starten wir die Hyper-V Rolleninstallation und wählen im Dialog “Virtuelle Netzwerke erstellen”, das VM Netz aus (siehe Screenshot).

Nach der Installation des Hypervisors gehen wir in die Konfiguration der Hyper-V Manager und wählen auf der rechten Seite den Punkt “Manager für virtuelle Netzwerke” aus. In dem daraufhin erscheinenden Dialog wählen wir das virtuelle Netzwerk “VM – virtuelles Netzwerk” aus. Jetzt entfernen wir die Checkbox “Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen” (siehe Screenshot).

Hyper-V Cluster konfigurieren

Um die Netzwerkkonfiguration für den Cluster fortzusetzen, müssen wir nun einen Cluster einrichten. Nachdem das erfolgt ist, finden wir im Failovercluster-Manager, unter dem Punkt “Netzwerke”, die Netze “Clusternetzwerk 1” bis “Clusternetzwerk 5” (Screenshot unten links). Diese werden automatisch anhand der Subnetze angelegt. In deren Detail Ansicht findet man dann auch die Netzwerk Adapter der jeweiligen Cluster Nodes / Hyper-V Hosts. Da die Bezeichnung “Clusternetzwerk x” nicht wirklich sprechend ist, ändern wir die Netze in unsere Netzbezeichnungen um (Screenshot unten rechts).

Bis jetzt haben wir erreicht, dass unsere Netzwerke für uns einen logischen Sinn ergeben. Jetzt müssen wir auch dem Cluster beibringen, welcher Adapter er für welche Funktion benutzen soll. Das geschieht an mehreren Stellen in der Konfiguration, auf die wir jetzt für jedes der Netze eingehen.

CSV Netz

Über diesen Adapter laufen zwei Funktionen: die Clusterkommunikation (oder Cluster Heartbeat) und die Cluster Shared Volumes. Wie oben schön erwähnt, würden wir diese Funktionen auf getrennte Netzwerkkarten legen, wenn weitere zur Verfügung ständen.

Welche Netze der Cluster Heartbeat benutzen darf, wird im Failovercluster-Manager eingestellt. Hier wählt man unter dem Punkt Netzwerke das Netz aus, welches für die Clusterkommunikation benutzt werden soll. Als nächstes rechtsklickt man und wählt Eigenschaften aus (Screenshot rechts). Im erscheinenden Dialog clickt man den Punkt “Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen” an. Im Screenshot sieht man links die Bindungen der Netzwerkkarte und rechts die Einstellungen des Clusters für diese Netzwerkschnittstelle.

Wie zuvor bereits erwähnt und bei Michel gebloggt, dürfen hier die Protokolle „Client für Microsoft Netzwerke“ und „Datei für Druckerfreigabe“ nicht deaktiviert werden. Dies wird für den Redirected Access vom CSV benötigt.

Die Einstellung der Funktion Cluster Shared Volumes und damit des Redirected Access, definiert man in der PowerShell. Jede Netzwerkschnittstelle im Cluster hat eine Metrik zugeordnet. Diese Metrik bestimmt der Cluster anhand der Netzwerkeigenschaften, wie z.B. die Geschwindigkeit des Interfaces, das Vorhandensein eines Gateways und die DNS Einträge. Der Cluster nutzt nun für die CSV Kommunikation die Karte mit der tiefsten Metrik. Wenn Sie selber bestimmen wollen, welche Karte da ist, so müssen sie die automatisch vergebenen Metriken modifizieren. Und eben hierzu benötigt man die PowerShell.

Zuerst laden wir in der PowerShell die FailoverCluster CmdLets:

Import-Module FailoverClusters

Dann lassen wir uns die Metrik der einzelnen Schnittstellen mit dem Befehl:

Get-ClusterNetwork | ft Name, Metric, AutoMetric

anzeigen. Das Ergebnis sieht so aus:

Momentan wird der CSV Adapter automatisch für die Clusterkommunikation benutzt. Wir möchten aber, dass die Auswahl nicht zufällig passiert, weswegen wir diese fest mit dem Wert 900 zuordnen. Weiterhin möchten wir, dass die Livemigration auf 1100 gesetzt wird. Dazu benutzen wir folgende PowerShell Befehle:

(Get-ClusterNetwork “CSV”).Metric=900
(Get-ClusterNetwork “Livemigration”).Metric=1100

Danach lassen wir uns wieder die Metriken der einzelnen Netzwerke anzeigen:

Damit haben wir die Interfaces nach unseren Vorstellungen “geordnet”.

Management Netz

Das Management Netzwerk ist Mitglied im normalen Clientnetzwerk und für die Kommunikation des Clusters mit der “Außenwelt” zuständig. Über dieses kann z.B. per Remote Desktop auf die Konsole zugegriffen werden und die System Center Agenten kommunizieren mit ihren Management Servern. Wie bereits weiter oben beschrieben, hat dieses Netz in der Regel ein Gateway und DNS konfiguriert. Die Konfiguration der Netzwerkkarte sieht man im Screenshot unten links und die der Clusternetzwerks im Screenshot unten rechts.

Im rechten Screenshot sehen wir, dass der Cluster auch eine IPv6 Netz für die Kommunikation benutzt. Das ist vollkommen in Ordnung und bei unserer Umgebung sogar gewünscht! (siehe Kapitel IPv6). Zusätzlich wird dieses Netz als Backup für die Cluster Heartbeat Kommunikation genutzt. Deshalb ist hier, wie beim CSV und Livemigration Netz, der Radiobutton ”Netzwerkkommunikation für Cluster in diesem Netzwerk zulassen” ausgewählt.

iSCSI und iSCSI2 Netze

Die Konfiguration ist für beide Adapter im Wesentlichen gleich, weswegen wir nur eine besprechen. Über dieses Netzwerk wird das SAN System, auf dem unsere VMs liegen, angesprochen. Wenn, wie in unserem Fall, für die Kommunikation mehrere Netzwerke (iSCSI und iSCSI2) benutzt werden, dann sollte das Feature MPIO korrekt konfiguriert sein. Die eigentliche Netzwerkkonfiguration der iSCSI Interface ist relativ simpel. Auf der Netzwerkschnittstelle wird nur IP gebunden (Screenshot unten links) und in der Clusternetzwerkkonfiguration wird die Netzwerkkonfiguration für den Cluster unterbunden (Screenshot unten rechts).

Livemigration Netz

Das Livemigration Netzwerk hat die Aufgabe, bei dem Vorgang einer Livemigration, den Hauptspeicher einer VM von Host A (auf dem die VM noch läuft) auf Host B (auf den die VM migriert wird) zu übertragen. Damit das funktioniert, ist ein möglichst schnelles Netz notwendig (mindestens 1Gbit). In unserer Konfiguration dient der Livemigration Adapter auch noch als Backup für die Clusterkommunikation (Cluster Heartbeat). Deswegen schalten wir in der Cluster Netzwerkkonfiguration auch die Clusterkommunikation ein (siehe Screenshot rechts).

Das eigentliche Konfigurieren, welches Netzwerk für die Livemigration benutzt wird, geschieht aber auf der VM. Dazu rechtsklickt man auf eine VM und wählt “Eigenschaften” aus (Screenshot unten links). Dann wechselt man in den Reiter “Netzwerk für Livemigration” und wählt die Netze “Livemigration” und “Management” aus (Screenshot rechts). Das Netz Management soll dabei als Backup dienen, wenn das Netz Livemigration nicht zur Verfügung steht. Wenn Livemigration unterhalb von Management steht, dann müssen wir die Reihenfolge der Netze noch durch “Drücken” des Buttons “Nach Oben” verändern, da sonst die Livemigration über das Management Netz erfolgen würde.

Wie bereits beim Heartbeat beschrieben, dürfen auch hier die Protokolle „Client für Microsoft Netzwerke“ und „Datei für Druckerfreigabe“ nicht deaktiviert werden.

Wichtig: Die Konfiguration auf der VM lässt den Anschein erwecken, dass man bei jeder VM das Netz für die Livemigration auswählen kann/muss. Das ist nicht so. Was man auf einer VM konfiguriert gilt auch für alle anderen.

Reihenfolge der Netzwerkkarten

Zuletzt wollen wir noch sicherstellen, dass das System zuerst über das Management Netzwerk versucht, mit anderen Systemen zu kommunizieren (z.B: Active Directory oder DNS Auflösung). Deswegen müssen wir gegebenenfalls die Reihenfolge der Netzwerkschnittstellen umsetzen. Dazu öffnen wir das “Netzwerk- und Freigabecenter” und klicken auf “Adaptereinstellungen ändern”. Im Fenster “Netzwerkverbindungen” drücken wir die die ALT-Taste und können in dem erscheinenden Menü (Screenshot unten links) über “Erweitert” den Dialog ”Erweiterte Einstellungen” aufrufen. Hier sorgen wir durch umordnen der Netzwerkschnittstellen dafür, dass das Management als Erstes in der Auflistung erscheint (Screenshot unten rechts).

IPv6

Noch ein paar Wort zu IPv6. Microsoft empfielt mittlerweile IPv6 auf den Schnittstellen eingeschaltet zu lassen. Es ist sogar wichtig zu wissen, dass Microsoft inzwischen nur noch mit aktiviertem IPv6 testet. Warum haben wir es dann in dieser Beispielkonfiguration mit einer Ausnahme ausgeschaltet? Ein einfacher Grund: Wir wollten die Konfiguration nicht weiter verkomplizieren. In unserer Umgebung haben wir wegen DirectAccess einen IPv6 DHCP Server laufen (siehe auch How to: Einrichtung von DirectAccess). Dieser versorgt alle Adapter, wenn IPv6 eingeschaltet ist, mit IPv6 Adressen. Damit wären alle Adapter über IPv6 in einem Netz und könnten miteinander kommunizieren. Um das zu verhindern, müssten wir VLANs einfügen, was dann die Komplexität dieses Artikels stark erhöhen würde. Aber bitte nicht falsch verstehen, VLANs machen im Hyper-V Cluster durchaus Sinn und wir empfehlen Sie auch (zumindest bei etwas größeren Umgebungen).

Schlussbemerkung

Damit ist unser Netzwerk für das Hyper-V Cluster korrekt konfiguriert. Da diese Konfiguration den Anspruch erhebt sich innerhalb der Microsoft Empfehlungen und Supportrichtlinien zu bewegen, habe ich gerne Michel Lüschers Angebot den Artikel zu prüfen wahrgenommen. Danke Michel für die Zeit und deine sehr hilfereichen Kommentare. Wer Michel nicht kennt, er ist für Microsoft in der Schweiz tätig und betreibt den sehr guten Blog Server-Talk.eu (findet ihr übrigens auch in unserer Blogroll).

Links

Wer noch mehr zu dem Thema erfahren möchte, dem habe ich noch ein paar Links zusammengetragen:

TechNet Modify Network Settings for a Failover Cluster

Alessandro Cardoso : Hyper-V : Network Design, Configuration and Prioritization : Guidance

TechNet Configuring Network Prioritization on a Failover Cluster

Michel Lüscher: How-To: Verwaltung eines Cluster Shared Volume (CSV)