Hyper-V-Cluster: die drei Konfigurationsfehler, die wir in fast jedem Review finden

Ein Hyper-V-Cluster kann jahrelang völlig unauffällig laufen und trotzdem falsch konfiguriert sein – das klingt zunächst widersprüchlich, ist aber typisch für alles, was mit Hochverfügbarkeit zu tun hat. Viele Fehler zeigen sich erst, wenn etwas anderes ausfällt. Ein Cluster mit zwei funktionierenden Nodes, funktionierendem Storage und funktionierendem Netzwerk beweist deshalb erst einmal nur eines: dass der Normalbetrieb funktioniert. Ob das Design auch unter Fehlerbedingungen trägt, ist eine ganz andere Frage, und genau die drei Bereiche, an denen sich das entscheidet, schaue ich mir bei jedem Review zuerst an.

Fehler 1: Das Netzwerk ist redundant – aber nicht als Gesamtsystem

Hyper-V braucht Netzwerk nicht nur für die virtuellen Maschinen. Je nach Design transportiert es gleichzeitig Management, Clusterkommunikation, Live Migration, Storage, CSV Redirected I/O, Backup, Replikation und die VM-Netzwerke selbst. Microsoft empfiehlt unter anderem, den Live-Migration-Verkehr gezielt zu isolieren und dafür feste Netzwerke festzulegen, und CSV kann bei einem Verlust des direkten Storagepfads I/O über andere Clusterknoten umleiten – womit das Netzwerk plötzlich, oft unbemerkt, Teil des Storagepfads wird.

Die entscheidende Frage ist deshalb nie, ob zwei Netzwerkkarten vorhanden sind, sondern welche Funktionen tatsächlich noch verfügbar bleiben, wenn eine Karte, ein Switch, ein VLAN oder ein Uplink ausfällt. Typische Schwachstellen, die mir in Reviews begegnen: Beide Uplinks enden am selben Switch, VLANs sind auf einem der beiden Pfade gar nicht identisch verfügbar, Live Migration nutzt ungewollt das Managementnetz, Storage- und VM-Traffic konkurrieren ohne sinnvolles QoS um dieselbe Bandbreite, SMB Multichannel ist zwar eingerichtet, aber in der Praxis nicht wirksam, oder die Clusterkommunikation funktioniert am Ende nur über einen einzigen Pfad, obwohl das Diagramm etwas anderes verspricht. Physische und logische Redundanz werden dabei erstaunlich oft miteinander verwechselt.

Ein Review sollte deshalb nie beim Diagramm aufhören, sondern reale Fehlerbilder durchspielen: Was passiert tatsächlich, wenn Switch A ausgeschaltet wird – nicht auf dem Papier, sondern im laufenden Cluster?

Ein Wort noch zur Technik dahinter, weil sie in vielen Umgebungen falsch eingeschätzt wird: Klassisches NIC-Teaming und RDMA vertragen sich nicht, weil ein Team die RDMA-Fähigkeiten der zugrunde liegenden Karten schlicht nicht durchreichen kann. Genau deshalb wurde Switch Embedded Teaming eingeführt – SET erlaubt es, dieselben Karten gleichzeitig zu teamen und für RDMA zu nutzen, was mit klassischem Teaming nie möglich war. Wer RDMA einsetzt, ob RoCE oder iWARP, sollte trotzdem wissen, dass beide Varianten unterschiedliche Anforderungen an die Switch-Konfiguration stellen, insbesondere bei RoCE an PFC und DCB, und dass ein sauber eingerichtetes SET-Team mit aktiviertem RDMA nicht automatisch bedeutet, dass diese Priorisierung im Netz auch wirklich greift. Das gehört für mich in jedes Hyper-V-Review mit hinein, weil genau hier die Grenze zwischen einer Konfiguration, die auf dem Papier modern aussieht, und einer, die im Fehlerfall tatsächlich trägt, oft verläuft.

Fehler 2: Das Quorum wurde eingerichtet – aber nie wirklich verstanden

Beim Quorum sehe ich sehr oft eine Konfiguration, die vorhanden ist, ohne dass jemandem im Team klar wäre, wozu sie eigentlich dient. Dabei erfüllt sie eine zentrale Aufgabe: Sie verhindert, dass nach einer Kommunikationsunterbrechung zwei Clusterteile gleichzeitig glauben, der aktive Cluster zu sein. Microsoft empfiehlt für Zwei-Knoten-Cluster einen Witness und rät auch bei drei oder vier Nodes dringend dazu; moderne Windows-Server-Versionen arbeiten zusätzlich mit Dynamic Quorum und Dynamic Witness.

Problematisch wird es vor allem dann, wenn der Witness in derselben Ausfallzone liegt wie die Nodes selbst, von derselben Storageplattform abhängt, über denselben kritischen Netzwerkpfad erreichbar ist oder zwar konfiguriert, aber nie überwacht wird. Auf dem Papier existiert dann ein zusätzlicher Abstimmungspunkt – praktisch wurde damit oft keine einzige zusätzliche Resilienz geschaffen. Die richtige Frage lautet deshalb nicht, ob ein Witness konfiguriert ist, sondern welche konkrete Fehlerkombination die eigene Quorumkonfiguration überstehen soll. Erst aus dieser Antwort ergibt sich, ob File Share Witness, Cloud Witness oder eine andere Lösung überhaupt sinnvoll ist.

Fehler 3: Der Test-Cluster wurde einmal vor fünf Jahren ausgeführt

Cluster Validation wird in der Praxis fast immer als reiner Installationsschritt verstanden – Cluster bauen, Test-Cluster ausführen, Bericht ablegen, fertig. Dabei verändert sich ein produktiver Cluster ständig: Firmware wird aktualisiert, Treiber ändern sich, Nodes werden ersetzt, Netzwerke kommen hinzu, Storage wird erweitert, MPIO-Konfigurationen ändern sich, Windows-Versionen entwickeln sich weiter, neue Hardware kommt dazu.

Microsoft empfiehlt die vollständige Validierung vor der Clustererstellung und weist ausdrücklich darauf hin, dass auch Hardwareänderungen an bestehenden Clustern erneut geprüft werden sollten – die Tests decken unter anderem Clusterkonfiguration, Hyper-V, Netzwerk, Storage und Systemkonfiguration ab. Für mich ist ein aktueller Validierungsbericht deshalb kein Artefakt aus der Installationsphase, sondern ein laufender Gesundheitsnachweis der Clusterkonfiguration. Und eine Warnung darin sollte man sich nicht mit einem Schulterzucken schönreden – wenn sie unkritisch ist, dann sollte auch dokumentiert sein, warum das so eingeschätzt wurde.

Hochverfügbarkeit lässt sich nicht am grünen Dashboard ablesen

Genau das verbindet alle drei Fehler. Ein Cluster kann überall grün leuchten und trotzdem strukturelle Schwächen haben, weil Monitoring im Grunde nur eine Frage beantwortet: Funktioniert das System gerade jetzt? Ein belastbares Hochverfügbarkeitsdesign muss eine zweite Frage beantworten können, die viel seltener gestellt wird – was funktioniert noch, wenn eine Komponente ausfällt?

Deshalb gehören zu einem Clusterbetrieb, dem ich vertraue, regelmäßige kontrollierte Tests: Node-Failover, Live Migration, der gezielte Ausfall einzelner Netzwerkpfade, die Prüfung des Witness, ein simulierter Storagepfadausfall, die Wartung eines Hosts, das Startverhalten nach einem vollständigen Shutdown und der Wiederanlauf definierter Clusterrollen. Nicht jede dieser Prüfungen muss monatlich laufen, aber ein Failovercluster, dessen Failover noch nie getestet und als ausführbares Runbook dokumentiert wurde, basiert am Ende nur auf einer Annahme – und Annahmen sind in der Hochverfügbarkeit der teuerste Fehler, den man machen kann.

Fazit

Die meisten Clusterprobleme, die mir begegnen, sind gar nicht spektakulär. Es sind kleine Designentscheidungen, die unter Normalbedingungen völlig unauffällig bleiben – ein ungünstig geführter Netzwerkpfad, ein falsch platzierter Witness, eine Validierung, die seit Jahren nicht mehr gelaufen ist. Deshalb lohnt es sich, einen Cluster nicht nur nach seinem aktuellen Zustand zu beurteilen. Hochverfügbarkeit zeigt sich nicht daran, dass gerade alles läuft, sondern daran, was noch läuft, wenn etwas anderes ausfällt.