Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 3
Generelle Informationen
Dieser Blogpost ist der dritte von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich vor kurzem geschrieben habe und welches exklusiv für Newsletter-Abonnenten zur Verfügung steht. Sie können das vollständige Whitepaper als PDF weiterhin erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.
Alle fünf Teile
Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 2
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 3
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 5
Die Einrichtung von RDMA over Converged Ethernet (RoCE)
Wenn Sie RDMA-fähige Netzwerkkarten in Ihrem Server besitzen, müssen Sie diese noch einrichten und vollständig konfigurieren. Da wir in unserem Fall mit RoCE arbeiten, müssen wir neben einer Installation der Treiber auch die Konfiguration von PFC vornehmen. Wir nutzen in unseren Systemen RoCE-Karten von Mellanox, dies hat den Vorteil, dass wir eine Konfiguration per PowerShell durchführen können.
# Clear previous configurations
Remove-NetQosTrafficClass
Remove-NetQosPolicy -Confirm:$False# Enable DCB
Install-WindowsFeature Data-Center-Bridging# Disable the DCBx setting:
Set-NetQosDcbxSetting -Willing 0# Create QoS policies and tag each type of traffic with the relevant priority
New-NetQosPolicy „SMB“ -NetDirectPortMatchCondition 445 -PriorityValue8021Action 5
New-NetQosPolicy „DEFAULT“ -Default -PriorityValue8021Action 5
New-NetQosPolicy „TCP“ -IPProtocolMatchCondition TCP -PriorityValue8021Action 1
New-NetQosPolicy „UDP“ -IPProtocolMatchCondition UDP -PriorityValue8021Action 1# Enable Priority Flow Control (PFC) on a specific priority. Disable for others
Enable-NetQosFlowControl -Priority 5
Disable-NetQosFlowControl 0,1,2,3,4,6,7# Enable QoS on the relevant interface
Enable-NetAdapterQos -InterfaceDescription „Mellanox ConnectX-3 Pro Ethernet Adapter“
Enable-NetAdapterQos -InterfaceDescription „Mellanox ConnectX-3 Pro Ethernet Adapter #2“# Optionally, limit the bandwidth used by the SMB traffic to 60%
New-NetQoSTrafficClass „SMB“ -Priority 5 -Bandwidth 60 -Algorithm ETS
Diese Konfiguration bewirkt folgendes:
Als erstes entfernen wir alle (möglicherweise) vorhandenen QoS-Klassen und Richtlinien. Danach installieren wir das DCB-Feature im Windows Server. Der dritte Schritt ist eine Deaktivierung von DCBx, diese Funktion ist bei der Nutzung von SMB Direct nicht unterstützt und wird daher deaktiviert. Nach der Deaktivierung erstellen wir vier unterschiedliche Richtlinien und legen fest, welche Art von Daten mit welcher Priorität belegt werden. Danach aktivieren wir PFC für die Priorität 5, für alle anderen sieben Prioritäten deaktivieren wir PFC. Im letzten benötigten Schritt müssen wir noch QoS für unsere RDMA-Karten aktivieren. Optional könnten wir noch eine Bandbreiten-Garantie mit Hilfe von ETS konfigurieren, dies ist aber in vielen Fällen nicht benötigt bzw. gewollt.
Tipp: Wenn Sie mit RDMA arbeiten möchten, wird Ihnen diese Beschreibung hier nicht ausreichen, da noch einige weitere Abhängigkeiten und Konfigurationen durchgeführt werden müssen. In unserem Blog finden Sie noch einige weitere Artikel zu diesem Thema, wir stehen Ihnen auch gerne mit Rat und Tat zur Seite.
Installation der benötigten Rollen und Features
Nun können wir die Installation von Hyper-V und der Failover Cluster Funktionalität starten. Da wir mit einem GUI-System arbeiten, installiere ich die Management-Konsolen (Hyper-V Manager und Failover Cluster Manager) mit.
Install-WindowsFeature -Name Hyper-V, Failover-Clustering –IncludeAllSubFeature -IncludeManagementTools –Restart
Nach der Installation und zwei Reboots der Systeme kann die Konfiguration von Hyper-V beginnen. Wir starten hier mit der Erstellung unserer Hyper-V Switch, an die später die VMs an das Netzwerk angebunden werden. Achten Sie darauf, dass die Namen auf allen Systemen identisch sind.
New-VMSwitch -Name “VM” -NetAdapterName VM-Team -AllowManagementOS 0
Überprüfung der Konfiguration
Nach der Erstellung können wir die Systeme mit dem Failovercluster-Manager gegenseitig testen lassen, um unsere Konfiguration zu verifizieren. Alternativ geht dies natürlich auch per PowerShell. Der Test ist wichtig, denn nur mit einem erfolgreichen Test ist sichergestellt, dass keine groben Fehler vorliegen. Ein weiterer wichtiger Aspekt ist, dass Sie nur mit einem erfolgreichen Test Support von Microsoft für Ihr Failover Cluster bekommen.
Bei dem Cluster Test gibt es drei Arten von Ergebnissen: Fehler, Warnung und Erfolgreich. Bekommen Sie einen oder mehrere Fehler, so müssen Sie diese beheben und den Test danach erneut ausführen. Ein Beispiel für einen Fehler ist z.B. unterschiedliche Namen bei der Hyper-V Switch. Warnungen sollten Sie genau betrachten und dann bewerten, ob sie behebbar sind oder nicht. Haben Sie einen unterschiedlichen Updatelevel bei den Systemen, so sollten Sie unbedingt vor der Cluster-Erstellung alle benötigten Updates einspielen. Bekommen Sie aber, wie ich im weiteren Verlauf auch, eine Meldung über ein "fehlendes" Standardgateway, so ist dies ok. Da die Systeme bewusst kein Gateway haben, kann ich diese Warnung natürlich nicht beheben.
Test-Cluster -Node Hyperv16, Hyperv17
Schauen Sie sich nach dem Test den Report an. Ist alles grün, können Sie sofort fortfahren. Gibt es Warnungen oder Fehler, so sollten Sie schauen ob Sie diese beheben müssen/sollten oder nicht und dann fortfahren.
Tipp: Fehler beim ersten Durchlauf
Ich habe es mit dem Windows Server 2016 jetzt schon mehrfach gehabt, dass der erste Durchlauf direkt auf Fehler läuft und weitere Tests in dem Unterbereich gar nicht mehr durchführt. Dies können Sie durch einen erneuten Test (ohne Neustart der Systeme oder so) beheben.
Wie man in dem Screenshot erkennen kann, gibt es ein paar Warnungen in meinem Fall. Sie können nun den Report in dem aufgeführten Pfad aufrufen, alternativ können Sie auch immer alle Reports unter C:WindowsClusterReports finden.
Wie man erkennen kann, gibt es Warnungen im Bereich Network und System Configuration, Storage wurde erst gar nicht überprüft. Dies liegt daran, dass wir keinen gemeinsam genutzten Speicher (z.B. LUNs) besitzen. Da wir mit SMB3 Shares arbeiten, gibt es hier im Hyper-V Cluster keinen Test. Da das SMB3 Storage in den meisten Fällen auch ein Failover Cluster ist, werden die Tests dort gemacht.
Die Warnungen schauen wir uns einmal näher an:
Die erste Meldung ist, wie bereits angesprochen, dass nicht vorhandene Standardgateway. Das Fehlen bewirkt, dass man bei der Erstellung des Failover Cluster manuell das Management-Netzwerk auswählen muss und dieses nicht automatisch passiert.
Die zweite Meldung zeigt an, dass die Server jeweils noch einen Neustart offen haben. Diesen mache ich vor der Erstellung des Failover Cluster, danach beginnen wir mit der Erstellunga des Failover Cluster.
New-Cluster -Name PowerCluster4 -Node Hyperv16, Hyperv17 -NoStorage -StaticAddress 192.168.209.44 -IgnoreNetwork 192.168.207.0/24, 192.168.206.0/24
Der Befehl sorgt dafür, dass die beiden Knoten Hyperv16 und Hyperv17 zu einem Cluster mit dem Namen PowerCluster4 zusammengefasst werden. Mit dem Parameter -StaticAddress vergebe ich die IP-Adresse des Clusters, mit -IgnoreNetwork werden die beiden SMB3-Netzwerke angegeben.
Die Warnung bezieht sich auf ein fehlendes Quorum im Cluster
Die Cluster-Konfiguration
Nach der Erstellung des Failover Cluster müssen wir nun noch einige Einstellungen vornehmen. Ich beginne meist mit der Konfiguration der Netzwerke (also quasi von unten nach oben im Failovercluster-Manager, die Reihenfolge hat aber keine Relevanz).
Umbenennung der Netzwerke
Die Netzwerke in einem Failover Cluster haben nach der Erstellung durchnummerierte Namen (Cluster Network 1, Cluster Network 2, ...). Diese passe ich an, damit ich mit sprechenden Namen arbeiten kann. Dies erleichtert mir die Arbeit mit den Netzwerken an anderen Stellen (Konfiguration der Metrik zum Beispiel), außerdem sieht es besser und aufgeräumter aus. Thanks to Aidan Finn for helping me out with the PowerShell cmdlets :)
(Get-ClusterNetwork | where-object {$_.Address -eq „192.168.208.0“}).Name = „Management“
(Get-ClusterNetwork | where-object {$_.Address -eq „192.168.207.0“}).Name = „SMB#1“
(Get-ClusterNetwork | where-object {$_.Address -eq „192.168.206.0“}).Name = „SMB#2“
Nach der Ausführung sehen die Netzwerke deutlich besser aus
Der nächste Schritt ist die Konfiguration der Livemigration, insbesondere die Reihenfolge der Netzwerke. In meinem Fall habe ich drei Netzwerke: SMB#1, SMB#2 und Management. Diese Netze sollen alle genutzt werden, die beiden SMB-Karten primär, Management soll als Fallback zur Verfügung stehen können. Direkt nach der Installation ist die Reihenfolge nicht so, wie ich sie gerne haben möchte:
Ich habe einige Zeit gesucht und probiert, bis ich letztendlich aus mehreren Beiträgen die passende Lösung ableiten konnte. Wie man es letztendlich löst ist nicht unbedingt toll, aber in meinem Fall hat es funktioniert. Eine kurze Erklärung der Befehle: Die Reihenfolge der Netzwerke wird über die ID der einzelnen Netzwerke gesetzt, diese bekomme ich mit den ersten drei Zeilen heraus. In die Variable $order setze ich dann die Reihenfolge zusammen, getrennt durch jeweils ein Semikolon. Hier muss man beachten, dass kein Leerzeichen enthalten ist. Danach kann ich diese Variable als Wert übergeben. Geholfen hat mir hierbei Mr. Hyper-V, Ben Armstrong, thanks for this :)
$1 = (Get-ClusterNetwork -Name „SMB#1“).ID
$2 = (Get-ClusterNetwork -Name „SMB#2“).ID
$3 = (Get-ClusterNetwork -Name „Management“).ID
$order = „$1;$2;$3“
Get-ClusterResourceType -Name “Virtual Machine” | Set-ClusterParameter -Name MigrationNetworkOrder -Value $order
Nun müssen wir noch die Metrik im Failover Cluster überprüfen. Die Metrik steuert, über welche Netzwerke die Knoten untereinander kommunizieren und woher möglicher Quertraffic geht. Abfragen können Sie die Metrik wie folgt:
Get-ClusterNetwork | ft Name, Metric, AutoMetric, Role
Die Werte sind so zu verstehen, dass eine kleinere Metrik eine höhere Priorität bedeutet (Metrik = Kosten). Je kleiner die Metrik, desto eher wird das Netzwerk genutzt. Befinden sich zwei oder mehr Netzwerke in einem Bereich, der kleiner als 16 voneinander getrennt ist (z.B. SMB#1 und SMB#2 in meinem Screenshot), so wird über diese Netzwerke eine Multichannel-Kommunikation per SMB3 gemacht.
Ich möchte die Netzwerke so haben, wie wir sie in dem Screenshot sehen, d.h. es werden erst die 10 Gbps Karten genutzt und erst danach das 2 Gbps Management-Team. Wären die Einstellungen falsch oder Sie möchten manuelle Werte festlegen, so können Sie dies wie folgt machen:
(Get-ClusterNetwork „Management“).metric = 40000
Im vierten Teil der Reihe schauen wir uns die Einrichtung des Quorum, das automatische Balancing der VMs und das neue Ausfall-Verhalten in einem Failover Cluster unter Windows Server 2016 an.
Enter your text here...
