Hyper-V Failover-Cluster bei Stromausfall

Ein Cluster fällt nicht als Ganzes aus — er fällt in Teilen aus

Bei einem einzelnen Hyper-V Host ist die Sache einfach: Strom weg, USV meldet kritisch, VMs geordnet herunterfahren, Host aus. Bei einem Windows Failover-Cluster mit mehreren Hyper-V Knoten ist das Bild komplizierter, weil der Cluster selbst ein verteiltes System ist, das eine Quorum-Mehrheit gesunder Knoten braucht, um überhaupt handlungsfähig zu bleiben.

Verliert nur ein Teil der Knoten unkoordiniert die Verbindung oder den Strom, während andere weiterlaufen, kann der Cluster-Dienst die Situation als Netzwerkpartition interpretieren — mit allen Risiken, die das für Cluster Shared Volumes (CSV) und laufende VMs mit sich bringt: hängende Handles, verzögerte Failover, im schlimmsten Fall ein Quorum-Verlust, der den gesamten Cluster lahmlegt, obwohl eigentlich noch genügend Knoten am Netz wären.

Deshalb gilt für Cluster eine Faustregel, die für einen Einzel-Host keine Rolle spielt: ein vollständig, synchron heruntergefahrener Cluster ist ungefährlicher als ein halb heruntergefahrener. Wer bei einem Stromausfall nur die Hosts einzeln und unkoordiniert abschaltet, für die gerade zufällig zuerst der Schwellwert erreicht wird, riskiert genau das Szenario, das eine USV-Überwachung eigentlich verhindern soll.

Eine USV für den ganzen Cluster — oder getrennte USVs pro Host?

Bevor man über Software nachdenkt, lohnt sich der Blick auf die eigene Stromversorgung. In der Praxis gibt es zwei grundverschiedene Ausgangslagen:

Migrieren, wenn möglich — synchron abschalten, wenn nicht

Für Szenario B (getrennte USVs je Host) reicht ein simples "USV kritisch → Host herunterfahren"-Skript nicht aus, weil es nicht weiß, ob der Rest des Clusters noch gesund ist. Der UPS Hyper-V Shutdown Monitor löst das über zwei zusammenspielende, pro Host konfigurierbare Mechanismen:

1. Live-Migration auf den gesunden Partner-Host
   Verliert ein Host seine Stromversorgung komplett, prüft die Software zuerst, ob ein konfigurierter Partner-Host — an einer anderen USV — noch gesund ist und genug Restlaufzeit hat. Ist das der Fall, wandern die laufenden VMs per Move-VM dorthin, bevor der geleerte Host sich selbst abschaltet. Das setzt entweder einen echten Failover-Cluster mit Shared Storage oder eine korrekt konfigurierte Shared-Nothing-Migration voraus.
2. Synchrone Komplettabschaltung, wenn keine Migration möglich ist
   Ist der Partner-Host ebenfalls betroffen — z.B. weil der Stromausfall größer ist als gedacht — migriert die Software bewusst nicht teilweise, sondern fährt beim Erreichen der Schwellwerte die gesamte konfigurierte Umgebung geordnet herunter. Genau das vermeidet den in Abschnitt 01 beschriebenen Zustand eines nur halb heruntergefahrenen Clusters.
3. USV-Redundanz mit Mindest-Restlaufzeit
   Hängt ein einzelner Host an zwei unabhängigen Einspeisungen (zwei Netzteile, zwei USVs), wird eine Abschaltung zurückgestellt statt ausgelöst, solange die zweite USV noch gesund ist und optional eine konfigurierte Mindest-Restlaufzeit meldet — der Host läuft ja weiterhin über die intakte Einspeisung.

Live-Migration und die Mindest-Restlaufzeit-Schwelle für das Migrationsziel sind Professional-Funktionen. Mehr dazu in der vollständigen Feature-Liste oder im Vergleich der Editionen.

Vor dem nächsten Stromausfall prüfen

1. Stromtopologie dokumentieren — welcher Knoten hängt an welcher USV, welchem Stromkreis, welchem Gebäudeteil? Ohne diese Information lässt sich Szenario A nicht von Szenario B unterscheiden.
2. Quorum-Zeuge (Witness) unabhängig platzieren — ein Datei-Witness auf einem eigenen, unbeteiligten Stromkreis oder ein Cloud-Witness (ohnehin außerhalb des eigenen Rechenzentrums) verhindert, dass derselbe Stromausfall gleichzeitig die Cluster-Knoten und den Zeugen lahmlegt und das Quorum dadurch unerreichbar wird.
3. Abschalt-Reihenfolge festlegen — VMs zuerst geordnet herunterfahren oder migrieren, dann den Cluster-Dienst, zuletzt den Host selbst. Nie den Host hart abschalten, solange der Cluster-Dienst noch aktiv ist.
4. Schwellwerte pro Host realistisch setzen — ein zu spät ausgelöstes Shutdown lässt keine Zeit mehr für eine geordnete Migration; die Restlaufzeit-Reserve muss die Migrationsdauer mit einplanen.
5. Testmodus vor dem Ernstfall nutzen — Abschalt-Sequenz und Live-Migration einmal im Testmodus durchspielen (Protokoll statt echter Aktion), bevor der erste reale Stromausfall der erste Test ist.
6. UpsMonitor selbst unabhängig platzieren — läuft die Management-VM mit UpsMonitor auf einem der überwachten Hosts oder an derselben USV, kann sie bei einem echten Ausfall mit wegbrechen, bevor die Abschaltsequenz für die übrigen Hosts fertig orchestriert ist. Eine reine Live-Migration dieser VM ist dabei unproblematisch (der laufende Prozess läuft während der Migration einfach weiter) — entscheidend ist, wo sie im Ernstfall steht, nicht ob sie zwischendurch migriert wurde.