Unsere Best Practice-Erfahrungen – Teil 1 – Die Installation eines Hyper-V Failover Cluster unter Windows Server 2012 R2
Dieser Artikel behandelt die Installation eines Failover Cluster unter Windows Server 2012 R2, welches zur Ausführung von Hyper-V VMs genutzt wird. Gegenüber den vorherigen Artikeln zur Einrichtung unter Windows Server 2008 R2 und Windows Server 2012 hat sich teilweise etwas geändert, das “Grundrauschen” ist allerdings gleich geblieben. Die größte Änderung liegt darin, dass durch unterschiedliche Techniken die Anzahl der Möglichkeiten enorm gestiegen sind. Dadurch gibt es nicht mehr “die eine” optimale Lösung, es muss nun anhand der jeweiligen Hardware entschieden werden, was die beste Lösung in diesem einen Fall ist. Zusätzlich habe ich an einigen Stellen noch die genutzten PowerShell-Befehle mit aufgeführt. Diese hier beschriebene Konfiguration eignet sich primär bei der Nutzung eines Scale-Out File Servers. Dieser ist bereits eingerichtet und in diesem Artikel wird nicht auf die Einrichtung eingegangen, dies wird komplett im zweiten Teil der Serie gemacht.
Egal was Sie einsetzen möchten, was Sie bereits haben oder wo Sie ansetzen: Sprechen Sie uns an, wir können diese Konfiguration gerne an Ihre Bedürfnisse anpassen.
Die genutzte Hardware
Die Demoumgebung
Die hier genutzte Hardware sind zwei Rechner aus unserem Hyper-V Powerkurs und einem Scale-Out Fileserver unter Windows Server 2012 R2 als SMB3-Ziel. Die Rechner besitzen zwei 1Gbit NICs und vier 10Gbit NICs, 24 GB RAM und eine Quadcore-CPU. Beide Server sind Mitglied der Active Directory powerkurs.local. Der Scale-Out File Server hat jeweils zwei 10Gbit-Ports für SMB3 und zwei 1Gbit-Ports zur Anbindung an die Active Directory pro Knoten.
Ein paar Worte zu der Hardware, den Verbesserungs- und den Sparmöglichkeiten
Diese hier beschriebene Konfiguration entsprecht von den Eckdaten her dem, was wir empfehlen und was wir bereits in Projekten mehrfach erfolgreich eingesetzt haben. Natürlich sollte als Server ein wirklicher Server zum Einsatz kommen, der für den 24/7-Betrieb geeignet ist. Von einer Nutzung von PCs oder Workstations ist natürlich absolut abzuraten, wegen der Verfügbarkeit habe ich diese Systeme aber als Demoumgebung genutzt.
Wir geben Ihnen als Empfehlung zwei 10Gbit-Adapter mit jeweils zwei Ports vor, d.h. jeder Hyper-V Host ist mit 40 Gbit angebunden, hinzu kommen noch zwei oder mehr 1 Gbit-Adapter. Diese Anbindung könnte theoretisch noch erhöht werden auf sechs 10 Gbit-Adapter, prinzipiell spricht hier nichts gegen. Dies bewirkt eine Erhöhung der Gesamtbandbreite, ändert aber nichts an der Performance der einzelnen Adapter. Hier kommen RDMA bzw. SMB Direct-Karten ins Spiel. Mit Hilfe dieser Technik können Sie eine deutliche Steigerung der Performance bei sehr geringer Latenz erreichen. Wenn alle Netzwerk-Komponenten diese Technik beherrschen haben Sie eine enorm hohe Bandbreite zwischen Hyper-V Failover Cluster und Scale-Out File Server. Informationen zu dem Thema gibt es unter anderem im Hyper-V Podcast Folge 35 von meinem Kollegen Carsten Rachfahl.
Wenn Sie nicht den Bedarf von 40 Gbit pro Knoten haben oder die Hardware bereits vorhanden ist, können Sie den Betrieb auch mit einer 10 Gbit DualPort-Karte realisieren. In diesem Fall wären die VMs mit zwei oder mehr 1 Gbit-Karten angebunden, die 20 Gbit ständen dann exklusiv für die Anbindung an den Storage zur Verfügung.
Die Installation und Einrichtung des Betriebssystems
Die Einrichtung beginnt mit einer frischen Installation eines Windows Server 2012 R2 in der Datacenter Edition auf beiden Hosts. Nach der Grundinstallation werden die Netzwerkkarten umbenannt und teilweise zu einem Team konfiguriert.
Beide 1Gbit-Adapter werden zu einem Team zusammengefasst, zusätzlich werden zwei 10Gbit-Adapter (jeweils auf einem der beiden Adapter) zu einem Team zusammengefasst. Das 2Gbit-Team wird als Management-Netzwerk genutzt, das 20Gbit-Team wird zur Anbindung der VMs an das Netzwerk genutzt. Insgesamt existieren vier Netzwerke, auf drei der Karten hat der Host eine eigene IP-Adresse. Das VM-Netzwerk wird exklusiv für die virtuellen Computer genutzt.
Die Konfiguration per PowerShell wäre wie folgt:
New-NetLBFOTeam -Name „Management-Team“ -TeamNICName „Management-Team“ -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false
New-NetLBFOTeam -Name „VM-Team“ -TeamNICName „VM-Team“ -TeamMembers 10GBit#1, 10GBit#3 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false
Die Karte Management-Team wird mit einer IP-Adresse im Bereich 192.168.209.0/24 konfiguriert. In meinem Fall arbeite ich mit den Systemen Hyperv10 und Hyperv15, daher bekommt Hyperv10 die Adresse 192.168.209.10 und Hyperv15 die Adresse 192.168.209.15. Die Endadresse bleibt in allen Netzen gleich, so kann eine eindeutige Zuordnung erfolgen. Eine gleichmäßige Zuweisung von Adressen sowie eine durchgängige Benamung machen den Betrieb und die Administration an vielen Stellen einfacher. Die Karte VM-Team wird zu diesem Zeitpunkt nicht konfiguriert, sie wird später als Hyper-V Netzwerk genutzt. Bei der Wahl der Adapter wird jeweils ein Adapter pro Hardware-Karte gewählt, dies ermöglicht einen Betrieb auch dann, wenn einer der beiden Hardware-Karten ausfallen würde. Die Bindungen der Karte werden nicht geändert und sehen wie folgt aus:
Die beiden 10Gbit-Adapter, die nicht Mitglied des Teams sind, werden mit einer IP-Adresse aus den Storage-Bereichen versehen. Hierbei achten wir ebenfalls darauf, dass die End-Adresse jeweils identisch ist mit der Adresse im Management-Netz. Nach der korrekten Konfiguration sehen die Eigenschaften der Karten wie folgt aus:
Unter IP-Einstellungen werden keine Änderungen vorgenommen, die Einstellungen der Karte 10GBit#2 (die zweite Storage-Karte) sind bis auf die IP-Adresse identisch.
Die Konfiguration per PowerShell:
Set-NetIPInterface -InterfaceAlias „10GBit#2“ -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias „10GBit#2“ -IPAddress 192.168.208.10
Set-DnsClientServerAddress -InterfaceAlias „10GBit#2“ -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name „10GBit#2“ -ComponentID ms_tcpip6 -Enabled $FalseSet-NetIPInterface -InterfaceAlias „10GBit#2“ -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias „10GBit#4“ -IPAddress 192.168.207.10
Set-DnsClientServerAddress -InterfaceAlias „10GBit#4“ -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name „10GBit#2“ -ComponentID ms_tcpip6 -Enabled $False
Beide Server werden nun auf den aktuellen Patchlevel geupdatet.
Nach der Installation und dem anschließenden Neustart kann die Einrichtung mit der Installation der Hyper-V Rolle fortgesetzt werden.
Über den Server-Manager oder per PowerShell kann nun die Hyper-V Rolle installiert werden. Bei der während der Installation durchgeführten Konfiguration wählen wir keine der Karten für das Hyper-V Netzwerk aus, dies wird im späteren Verlauf manuell konfiguriert. Die Livemigration wird nicht konfiguriert, bei der Wahl der Pfade wird ebenfalls an dieser Stelle keine Änderung vorgenommen. Das System startet nun zwei Mal durch und steht danach wieder zur Verfügung.
Alternativ kann die Installation natürlich auch per PowerShell gemacht werden:
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart
Wenn der Parameter –ComputerName noch mit angegeben wird können sogar alle Server fast gleichzeitig installiert werden:
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart -ComputerName Hyperv10
Die Einrichtung von Hyper-V zur Vorbereitung auf den Betrieb als Failover Cluster-Knoten
Nach der Installation von Hyper-V müssen noch ein paar lokale Einstellungen vorgenommen werden, bevor das Failover Cluster eingerichtet werden kann. Im Hyper-V-Manager werden auf beiden Systemen unter dem Manager für virtuelle Switches eine neue externe Switch erstellt und auf den VM-Team-Adapter gebunden. Achten Sie darauf, den korrekten Adapter auszuwählen.
Wie Sie die virtuelle Switch nennen ist Ihnen überlassen, wichtig ist das sie auf allen Hyper-V Hosts gleich heißt. Achten Sie zusätzlich unbedingt darauf, nicht die gemeinsame Verwendung zu aktivieren. Bei Nutzung der gemeinsamen Verwendung bekommt der Host eine weitere, virtuelle Netzwerkkarte, die nicht benötigt und nicht gewollt ist. Der PowerShell-Befehl hierzu ist:
New-VMSwitch -Name „VM“ -NetAdapterName VM -AllowManagementOS 0 -ComputerName Hyperv10
Danach kann Hyperv10 durch den Namen des zweiten Knoten ersetzt werden.
Die Installation und Einrichtung des Failover Cluster
Nachdem nun die Vorbereitungen abgeschlossen sind können wir mit der Installation und Einrichtung des Failover Cluster beginnen.
Die Installation der benötigten Features
Für die Einrichtung eines Failover Cluster wird das Feature Failoverclustering benötigt
Wenn Sie das System lokal administrieren möchten oder müssen sollten Sie die Failovercluster-Verwaltungstools sowie das Failoverclustermodul für Windows PowerShell ebenfalls installieren
Per PowerShell:
Install-WindowsFeature Failover-Clustering –IncludeAllSubFeature –IncludeManagementTools -ComputerName Hyperv10
Die Einrichtung des Failover Cluster
Nach der Installation öffnen Sie den Failovercluster-Manager und beginnen mit dem Menüpunkt Konfiguration überprüfen….
Im Assistenten fügen Sie die Server hinzu, die überprüft werden sollen (Tipp: das lokale System kann mit einem Punkt ( . ) oder “localhost” hinzugefügt werden)
Danach können Sie auswählen, welche Tests durchgeführt werden sollen. Falls dies der erste Durchlauf ist sollten Sie unbedingt alle Tests auswählen, falls Sie nur einen oder mehrere spezielle Tests durchführen möchten (z.B. bei einem erneuten Durchlauf) können Sie diese manuell auswählen.
Es werden nun alle Tests durchgeführt, dies dauert je nach Anzahl der Server.
Nach dem Durchlauf erhalten Sie eine Übersicht der Tests und haben die Möglichkeit, sich den kompletten Bericht anzeigen zu lassen.
Schauen Sie sich unbedingt die Warnungen und Fehler an. Je nach Art der Fehler können diese entweder ignoriert werden oder sie müssen aktiv korrigiert werden. In meinem Fall steckte ein Kabel in einem falschen VLAN, wodurch die folgende Meldung in dem Bericht auftaucht:
Solche Fehler werden meist durch den Assistenten erkannt und angemerkt, eine Behebung vor der Erstellung und Nutzung des Failover Cluster macht deutlich mehr Spaß als die nachträgliche Suche.
Andere Warnungen können ggf. ignoriert werden, z.B. ein fehlender Datenträger oder eine permanente SCSI-3-Reservierung. Da wir mit SMB3-Shares arbeiten sind keine Datenträger im Failover Cluster vorhanden.
Wenn keine Fehler während der Überprüfung auftauchen aktiviert der Assistent direkt die Möglichkeit, den Failover Cluster mit den überprüften Knoten zu erstellen
Während der Erstellung werden wir nach dem Namen des Failover Cluster und der IP-Adresse gefragt, unter der eine Administration möglich ist. Die Frage nach dem Netzwerk erscheint nur, weil keine der Netzwerkkarten ein Gateway eingetragen hat. Sobald ein Gateway vorhanden ist wird automatisch dieses Netzwerk als Zugriffspunkt definiert.
Wir benötigen in unserem Fall eine IP-Adresse im Netzwerk 192.168.209.0/24 und einen eindeutigen Namen
Nach einem Klick auf Weiter wird überprüft, ob Name und IP-Adresse bereits vorhanden bzw. belegt sind, falls dies nicht der Fall ist erscheint eine Übersicht über die getätigten Einstellungen.
Die Option Der gesamte geeignete Speicher soll dem Cluster hinzugefügt werden bewirkt an dieser Stelle keine Änderung, da keine Datenträger hinzugefügt wurden. Wir haben uns angewöhnt diese Option grundsätzlich zu deaktivieren, da wir den Speicher manuell zuweisen wollen. Nach einem Klick auf Weiter wird der Cluster erstellt, danach verbindet sich der Failovercluster-Manager automatisch mit dem gerade erstellten Cluster. In der Zusammenfassung bekommen wir noch einen Hinweis angezeigt, dass kein geeigneter Datenträgerzeuge vorhanden ist. Um diese Einstellungen kümmern wir uns später.
Die Konfiguration des Netzwerks
Die ersten Anpassungen im gerade erstellten Cluster werden im Netzwerk gemacht. Die Netze werden automatisch durchnummeriert, diese Namen ändern wir auf die Funktion des einzelnen Netzwerks.
Um welches Netz es sich handelt können Sie sehen, wenn Sie auf das Netzwerk klicken und im unteren Teil auf den Reiter Netzwerkverbindungen wechseln.
Das Ergebnis sind drei vollständig benannte Netzwerke. Die Eigenschaften der Karten sehen wie folgt aus:
In den Einstellungen für Livemigration muss nun die Reihenfolge der Netzwerke definiert werden, über die eine Livemigration gemacht wird.
Hier werden die beiden Storage-Karten als primäre Karten definiert und in der Reihenfolge nach oben geschoben, falls dies nicht automatisch der Fall ist. Der Adapter Management bleibt ebenfalls aktiviert, wird aber ganz nach unten verschoben.
Als nächstes muss die Metrik der Netzwerke im Failover Cluster definiert werden. Die Metrik bestimmt, über welches Netzwerk die Daten während eines umgeleiteten Modus zwischen den einzelnen Knoten laufen. Diese Einstellung kann ausschließlich per PowerShell ausgelesen und gesetzt werden, eine Administration per GUI ist nicht möglich. Öffnen Sie eine administrative PowerShell oder die PowerShell ISE und nutzen Sie die folgenden Befehle zum Auslesen und manuellen Setzen der Werte.
Get-ClusterNetwork | ft Name, Metric, AutoMetric
Je kleiner die Metrik, desto höher ist die Priorität. Standardmäßig wird in dem oberen Screenshot das Netzwerk Storage2 genutzt, da die Metrik 30240 die kleinste der drei ist. Grundsätzlich ist diese Reihenfolge (Erst Storage2, dann Storage1 und dann Management) in Ordnung, wir möchten aber gerne die Prioritäten manuell auf die folgenden Werte setzen:
| Storage1 | 100 |
| Storage2 | 101 |
| Management | 110 |
Die entsprechenden Befehle dazu sind
(Get-ClusterNetwork "Storage1").Metric = 100
(Get-ClusterNetwork "Storage2").Metric = 101
(Get-ClusterNetwork "Management").Metric = 110
Diese Einstellungen müssen nur auf einem der Knoten gemacht werden, da hier clusterweite Einstellungen verändert und konfiguriert werden.
Die folgende Einstellung muss auf jedem Cluster-Knoten gesetzt werden, da es sich um eine lokale Einstellung handelt. Wechseln Sie in die Netzwerkverbindungen und wählen Sie in der Menüleiste (Falls nicht sichtbar “Alt” drücken) unter Erweitert die Option Erweiterte Einstellungen….
Schieben Sie dort den Adapter Management-Team ganz nach oben.
An dieser Stelle sind wir mit der Konfiguration des Netzwerks lokal und im Cluster fertig.
Die Einrichtung des Datenträgerzeugen / Quorum
Ganz wichtige Änderung unter Windows Server 2012 R2 in Bezug auf das Quorum: Erstellen Sie immer (egal welche Anzahl von Knoten und ob gerade oder ungerade) ein Quorum und weisen Sie dieses auch immer! zu. Das Failover Cluster verwendet dieses Quorum dynamisch, und zwar immer nur dann wenn es eins benötigt. Weitere Informationen und eine Bestätigung seitens Microsoft finden Sie im Technet: What’s New in Failover Clustering in Windows Server 2012 R2.
Da wir bei der Nutzung eines Scale-Out File Server keine CSV-Datenträger in unserem Failover Cluster haben müssen wir eine Dateifreigabe verwenden. Es existieren zu diesem Zeitpunkt drei Freigaben auf dem Scale-Out File Server. Die Freigabe HVQuorum wird für den Hyper-V Failover Cluster genutzt.
Wechseln Sie im Hauptmenü des Failover Cluster unter Weitere Aktionen auf Clusterquorumeinstellungen konfigurieren….
Es öffnet sich ein Assistent, der Sie bei der Einrichtung unterstützt. Nach der Vorbemerkung werden Sie nach der Art der Einrichtung gefragt. Die erste Option Standardquorumkonfiguration verwenden ist in diesem Fall nicht möglich, dies führt dazu das kein Quorum verwendet wird. Wir nutzen daher die zweite Option Quorumzeugen auswählen.
Im nächsten Schritt werden Sie nach der Art des Quorum gefragt, hier wählen Sie die Option Dateifreigabezeuge konfigurieren.
Schreiben oder Kopieren Sie nun den Pfad der Freigabe in den Assistenten.
Bestätigen Sie die Einstellungen und schließen Sie den Assistenten ab.
Nachdem Sie die Einrichtung abgeschlossen haben können Sie sehen, dass an besagtem Ort nun ein Ordner erstellt wurde, in dem eine Textdatei liegt.
Kurze Zeit später erscheint eine zweite Datei
Die Konfiguration ist nun abgeschlossen.
Die Einrichtung von Bandbreitenmanagement für SMB-Traffic
Wenn, wie in unserem Fall, die Livemigration und der Storage-Traffic über eine Leitung laufen, könnte dies ungewünschte Folgen bei vielen gleichzeitigen Livemigrationen haben. Zusätzlich werden Daten zwischen den einzelnen Hosts ebenfalls über diese Netze gesendet (Metric-Konfiguration weiter oben, bei der Storage1 die geringste Metric besitzt. In solch einem Fall können wir ein Bandbreitenmanagement für SMB-Traffic einführen. Die Installation kann auf Wunsch per Server-Manager gemacht werden, die Konfiguration muss allerdings zwingend per PowerShell gemacht werden. Das Feature versteckt sich hinter dem Namen SMB Bandwidth Limit.
Die Installation per PowerShell erfolgt mit dem Befehl
Add-WindowsFeature FS-SMBBW
Nach der Installation erfolgt die Einrichtung per PowerShell. Um die Livemigration auf z.B. 8 Gbit/s zu begrenzen, kann der folgende Befehl angewendet werden
Set-SmbBandwidthLimit -Category LiveMigration -BytesPerSecond 1000MB
Als Kategorie steht neben LiveMigration noch VirtualMachine und Default zur Verfügung.
Die Nutzung von SMB Multi Channel
Wir nutzen in unserem Fall mehrere Wege zu unserem Scale-Out File Server, daher haben wir beim Netzwerk-Design und bei der Einrichtung weiter oben zwei Storage-Karten konfiguriert. Grundsätzliches zum Thema SMB3 hat Carsten unter anderem in diesem Video gezeigt und erklärt: Hyper-V-Server.de: Videocast rund um Hyper-V auf SMB. Damit die Multi Channel-Funktionalität in einem Failover Cluster (egal ob Hyper-V oder Scale-Out File Server) greift, müssen sich die Storage-Karten in unterschiedlichen Subnetzen befinden. Multi Channel in einem Subnetz funktioniert nur bei Konfigurationen, in dem das Failover Cluster-Feature noch nicht installiert ist.
