Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 4
Generelle Informationen
Dieser Blogpost ist der vier 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 3
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 4
Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016 – Teil 5
Die Einrichtung des Datenträgerzeugen / Quorum
Seit dem Windows Server 2012 müssen wir in einem Failover Cluster immer ein Quorum setzen, da das Cluster dem Quorum selbstständig, an Hand seiner Knoten-Anzahl, ein Stimmrecht gibt oder nicht. Mit dieser Änderung entfällt ein manueller Eingriff nach einem Wechsel bzw. einer Erweiterung der Knoten.
Ein Quorum setzen können wir in meinem Fall mit dem folgenden Befehl:
Set-ClusterQuorum -FileShareWitness \sofsShare
Nun sind wir mit dem Teil der Konfiguration, der in nahezu allen Clustern gleich ist, durch. Je nach Art des Clusters und dem Bedarf gibt es natürlich noch weitere Einstellungen, Optionen und Möglichkeiten, die man anpassen kann. Ich werde im Weiteren auf andere Arten von Storage und die damit geänderte Art der Konfiguration eingehen sowie auf ein paar Neuerungen im Cluster unter Windows Server 2016.
Ein automatisches Rebalancing der VMs
Mit der aktuellen Version des Failover Clusters hat Microsoft eine Funktion mit aufgenommen, die bisher nur über den Virtual Machine Manager (oder mit einem manuellen PowerShell-Skript) verfügbar war: Eine automatische Verteilung der VMs über die Cluster-Knoten. Die Funktion ist standardmäßig eingeschaltet und über die Eigenschaften des Failover Cluster selbst zu finden:
In dieser Einstellung wird immer ein Ausgleich vorgenommen, alternativ könnte ein Ausgleich nur dann passieren, wenn ein Knoten aus einem "Down"-Zustand dem Cluster wieder aktiv beitritt, zum Beispiel nach der Installation von Updates und einem Neustart. Die zweite Option regelt, wann eine automatische Verteilung passiert. Hier können Sie zwischen drei Stufen wählen:
Low: Es erfolgt ein Ausgleich, wenn mehr als 80% Belastung auf einem Host festgestellt wird
Medium: Es erfolgt ein Ausgleich, wenn mehr als 70% Belastung festgestellt wird
High: Es erfolgt ein Ausgleich, wenn mehr als 5% Unterschied zwischen den Hosts besteht
Als Bewertung für die Last werden zwei Dinge betrachtet: Current Memory Pressure (Wie viel RAM ist in Nutzung) und CPU Utilization (Hier wird pro Knoten ein 5-Minuten Durchschnittswert betrachtet). Weitere Informationen dazu inkl. den entsprechenden PowerShell-Befehlen zur Steuerung finden Sie im TechNet: Failover Cluster VM Load Balancing in Windows Server 2016
Ich setze die Aggressivität mal auf High, um die Wirkung zu beobachten.
(Get-Cluster).AutoBalancerLevel = 3
Tipp
Tipp: Wenn Sie System Center Virtual Machine Manager im Einsatz haben und eine dynamische Optimierung dort aktiviert haben, wird dieser genutzt und die lokalen Einstellungen im Failover Cluster greifen nicht.
Die neuen Verhaltensweisen bei einem Ausfall (Cluster Resiliency)
Microsoft hat das Standard-Verhalten im Failover Cluster bei einem Ausfall mit dem Windows Server 2016 geändert. Je nach Art des Failover Clusters sind diese Einstellungen anzupassen, aber erst einmal eine kurze Erklärung, was sich geändert hat.
Wo sind die Einstellungen?
Wenn Sie sich die Cluster-Einstellungen per Windows PowerShell anschauen, gibt es dort einige relevante Einträge:
ResiliencyLevel
Diese Einstellung definiert, wie mit Fehlern im Failover Cluster umgegangen wird. Der Standardwert ist 2; das bedeutet, dass ein Knoten in einen Isolated-Modus geschickt werden kann und das eine gewisse Zeit vergehen kann, bis dieser Knoten wieder den Besitz / Betrieb einer VM übernehmen kann.
ResiliencyPeriod
Dieser Wert definiert, wie lange eine VM in einem isolated-Zustand verbleiben kann. Der Standardwert ist 240 Sekunden, das entspricht vier Minuten. Wir kommen direkt nach dieser Auflistung auf diesen Eintrag zurück, da er verantwortlich für die Dauer von einem Failover ist.
QuarantineThreshold
Dieser Wert beschreibt die Häufigkeit, wie oft ein Cluster Knoten innerhalb von 60 Minuten das Cluster unerwartet verlässt, bevor er für eine bestimmte Zeit (der nachfolgende Wert) in Quarantäne gesetzt wird und das nicht nicht aktiv betreten darf. Diese Einstellung soll ein "flapping" verhindern, d.h. ein Server wechselt häufig zwischen online / offline oder stürzt mehrfach hintereinander ab oder die Verbindung zu diesem Knoten ist nicht dauerhaft stabil.
QuarantineDuration
Dieser Wert definiert die Dauer in Sekunden, wie lange ein Server in Quarantäne ist bzw. nach welcher Zeit er wieder aktiv dem Cluster beitreten darf. Der Standardwert liegt hier bei 7200 Sekunden bzw. 2 Stunden.
Die Option ResiliencyPeriod ist eine sehr wichtige Einstellung, da sie definiert wann im Fehlerfall eine Übernahme der VMs gemacht werden soll, die auf dem Hyper-V Host betrieben wurden, der ausgefallen ist. Ich beschreibe die Situation und das Verhalten mal an einem Beispiel, das ich auch immer im Hyper-V Powerkurs zeige: Das Failover Cluster besteht aus zwei Knoten, die ihre VMs auf einem oder mehreren SMB3 Shares betreiben. Beide Knoten betreiben eine Handvoll VMs.
Ich gehe nun zu einem der beiden Server hin und entferne die Stromzufuhr, indem ich die Netzstecker ziehe. Ein paar Sekunden nach dem Ausfall springt der Knoten im Failovercluster Manager in den Zustand isolated.
Die VMs, die auf dem Hyperv17 liefen, sind in diesem Moment im Status Unmonitored.
Dieser Zustand hält nun 4 Minuten (die oben aufgeführten 240 Sekunden) an, erst danach werden die VMs auf dem Hyperv16 wieder gestartet und stehen nach der Bootphase wieder zur Verfügung. Warum ist das so?
Diese Einstellung kann Sinn machen, wenn die VMs auf einem Speicher abgelegt wird, der lokal verfügbar ist. Dies ist z.B. bei Storage Spaces Direct der Fall. Hier könnte es Sinn machen, dass die VMs nicht sofort per Failover auf einen anderen Knoten übertragen und wieder gestartet werden, sondern dass es eine gewisse Wartezeit gibt, wenn z.B. die Kommunikation der Knoten untereinander unterbrochen ist. Dies könnte durch einen Reboot / Kernel Panic vom Netzwerk ausgelöst werden oder durch sonstige Ausfälle im Rechenzentrum.
Ich habe bisher bei einem Cluster mit SMB3 / iSCSI / Fibre Channel Storage noch keinen Mehrwert dieser Option erkennen können. Unsere Server sind immer über mehrere Netzwerke und mehrere Netzwerk-Komponenten verbunden, so dass schon mehrere Komponenten gleichzeitig ausfallen müssten, damit die Verbindung der Server untereinander unterbrochen wird und der Server trotzdem noch läuft. Aus diesem Grund stelle ich diese Option auf 0 Sekunden, um einen sofortigen Failover-Prozess zu haben. Vier Minuten sind bei einem Ausfall häufig eine ziemlich lange Zeit. Umstellen können Sie die Option mit der PowerShell.
(Get-Cluster).ResiliencyDefaultPeriod = 0
Falls Sie einen Knoten, der sich in Quarantäne befindet, wieder in den Regelbetrieb überführen möchten, können Sie dies ebenfalls per PowerShell durchführen. Dies ist zum Beispiel bei Ausfalltests wichtig oder wenn Sie den Fehler, der die Ausfälle verursacht hat, behoben haben.
Start-ClusterNode –ClearQuarantine
Im fünften und letzten Teil schauen wir uns die Konfiguration und Einrichtung von Storage-LUNs per iSCSI oder Fibre Channel an. Weiterhin habe ich eine Konfiguration des CSV Block Cache vorgenommen.
