Was ein Hyper-V-Cluster leistet und wo seine Grenzen liegen

„Wir brauchen Hochverfügbarkeit“ ist ein häufiger Satz in Beschaffungsgesprächen, und fast immer ist damit etwas anderes gemeint als das, was ein Cluster tatsächlich liefert. Ein Failover-Cluster mit Hyper-V verhindert nicht, dass Systeme stehen; er verkürzt die Zeit, in der sie stehen, und verlegt planbare Arbeiten aus der Nacht in den Arbeitstag. Wer das vorher ausspricht, vermeidet die Enttäuschung nach dem ersten Zwischenfall – und erkennt, welche Bauteile wirklich nötig sind.

Die vier Bauteile

Warum es einen Zeugen braucht

Reißt die Verbindung zwischen zwei Knoten, sieht jeder Knoten nur noch sich selbst – und beide halten sich für den Überlebenden. Würden beide die Maschinen starten, schrieben zwei Instanzen auf dieselben Daten. Um das zu verhindern, arbeitet ein Cluster mit Stimmenmehrheit: Weiter darf nur die Seite, die mehr als die Hälfte der Stimmen hält. Bei zwei Knoten ist das ohne dritte Stimme unmöglich, und genau diese liefert der Zeuge.

Drei Bauformen stehen zur Wahl, jede mit eigenen Anforderungen. Der Datenträger-Zeuge nutzt eine gemeinsam erreichbare Platte, die keinen Laufwerksbuchstaben trägt, als Basisdatenträger eingerichtet und größer als 512 MB ist. Der Dateifreigabe-Zeuge nutzt eine Freigabe mit mindestens SMB 2, die nur diesem einen Cluster dient, wenigstens 5 MB frei hat und möglichst räumlich getrennt steht – bei einer Freigabe außerhalb der Domäne verlangt Microsoft mindestens Windows Server 2019, und der Einsatz replizierter Ablagen wird ausdrücklich nicht unterstützt. Der Cloud-Zeuge legt eine kleine Datei in einem Speicherkonto bei Microsoft Azure ab und benötigt dafür ausgehend Port 443 von allen Knoten.

Die häufigste Nachlässigkeit ist die Platzierung. Ein Dateifreigabe-Zeuge auf einem virtuellen Server, der auf demselben Cluster läuft, ist kein Zeuge, sondern Dekoration. Er muss außerhalb stehen: auf einem anderen physischen Gerät, an einer anderen Stromversorgung, bei zwei Standorten an einem dritten Ort. Microsoft nennt genau diese Trennung nach Netz, Strom, Rack und Raum als Ziel, damit Knoten oder Standorte auch dann handlungsfähig bleiben, wenn die Verbindung zwischen ihnen abreißt.

Für kleine Umgebungen ist der Cloud-Zeuge deshalb oft die unaufwendigste Lösung: Microsoft nennt als unterstützte Fälle ausdrücklich kleine Verbünde in Zweigstellen, auch solche mit nur zwei Knoten, sowie Verbünde, die über zwei Standorte gespannt sind. Wer keinen Anbieterzugang außerhalb des Hauses nutzen möchte, braucht dagegen ein drittes, unabhängiges Gerät – dann ist die Dateifreigabe auf einem kleinen, separat versorgten System die naheliegende Wahl.

Live-Migration ist die Hälfte des Nutzens

Die Live-Migration verschiebt eine laufende virtuelle Maschine von einem Wirt auf einen anderen, ohne dass Nutzer eine Unterbrechung wahrnehmen. Microsoft beschreibt als eigentlichen Gewinn die Beweglichkeit: Ein Wirt lässt sich vor Firmware-Updates, Speichererweiterung oder Außerbetriebnahme leeren. Seit Windows Server 2016 funktioniert die Live-Migration auch ohne Failover-Cluster zwischen einzelnen Wirten – wer nur tagsüber warten möchte, braucht also nicht zwingend einen Verbund.

Aus dieser Beweglichkeit ergibt sich der eigentliche Alltagsnutzen: Die Knoten lassen sich reihum warten. Ein Knoten wird geleert, erhält Betriebssystem- und Firmware-Updates, wird geprüft und nimmt anschließend wieder Maschinen auf; danach ist der nächste an der Reihe. Damit dieses Verfahren trägt, muss die Reserve stimmen – ein Verbund, der nur im Vollausbau alle Maschinen tragen kann, lässt sich nicht im Betrieb warten. Zwei Voraussetzungen sind dabei leicht zu übersehen: Die Prozessoren der Knoten müssen zueinander passen, und für die Verschiebung braucht es Bandbreite, die nicht gleichzeitig den Speicherzugriff bedient.

Was die Live-Migration nicht abdeckt, ist der ungeplante Fall. Fällt ein Knoten unerwartet aus, werden die betroffenen Maschinen auf den verbliebenen Knoten neu gestartet; das ist ein kurzer Ausfall mit Anlaufzeit der Anwendungen, kein nahtloser Übergang. Für die Planung heißt das: Der Cluster begrenzt die Ausfalldauer auf Minuten, er beseitigt sie nicht. Ob Minuten genügen, entscheidet die Fachabteilung, nicht die Technik.

Wogegen ein Cluster nicht hilft

Ein Cluster deckt genau einen Fehlerfall ab: den Ausfall eines Wirts. Er hilft nicht gegen einen fehlerhaften Datenbankinhalt, gegen verschlüsselte Dateien, gegen ein missglücktes Update der Fachanwendung oder gegen einen Bedienfehler – all das wird auf dem neuen Knoten unverändert weiterlaufen. Er hilft auch nicht gegen den Ausfall des geteilten Speichers; ist dieser nicht selbst redundant ausgelegt, hat der Verbund seinen Schwachpunkt lediglich verlagert. Und er hilft nicht gegen den Verlust des Standorts, solange alle Knoten in einem Raum stehen.

Daraus folgt die Reihenfolge der Investitionen. Zuerst kommt eine geprüfte Datensicherung, dann ein redundanter Speicher, dann der Cluster. Wer diese Reihenfolge umdreht, kauft die teuerste Komponente zuerst und schützt damit gegen den Fehlerfall, der am seltensten eintritt. Das BSI weist im Baustein zur Virtualisierung ausdrücklich darauf hin, dass auch die Verwaltungssysteme einer virtuellen Infrastruktur besonders zu schützen sind, weil sie umfassenden Zugriff auf die gesamte Umgebung haben – ein Punkt, der bei Clusterprojekten regelmäßig untergeht.

Folgen für die Lizenzierung

Die Clusterfunktion selbst ist kein Aufpreis: Microsoft führt Failover Clustering und Hyper-V sowohl für die Standard- als auch für die Datacenter-Edition von Windows Server. Unterschiede gibt es bei zwei Punkten, die für Clusterpläne unmittelbar wichtig sind. Storage Spaces Direct – also der aus den Servern selbst gebildete geteilte Speicher – ist ausschließlich in der Datacenter-Edition enthalten. Und die Aufteilung von Grafikprozessoren auf virtuelle Maschinen ist in der Standard-Edition von Windows Server 2025 für einzelne, nicht geclusterte Server gedacht; wird Clusterbetrieb benötigt, verweist Microsoft auf die Datacenter-Edition.

Der zweite Kostenblock betrifft die Gastsysteme. Wie viele virtuelle Instanzen eine Edition abdeckt, regeln die Lizenzbedingungen und nicht die Technik – und im Cluster ist zusätzlich zu klären, wie mit Maschinen umzugehen ist, die zwischen Knoten wechseln können. Diese Frage gehört vor die Beschaffung, nicht in die Abnahme. Sie entscheidet in kleinen Verbünden häufiger über die Edition als jede technische Eigenschaft.

Prüffragen vor dem Bau

Ein Cluster ist kein Zustand, sondern ein Betriebsversprechen: Er trägt nur, wenn Reserve, Zeuge und Speicherwege nach jeder Änderung noch stimmen. Deshalb gehört nach dem Aufbau eine Prüfung der Konfiguration dazu und nach jeder Erweiterung noch einmal. Zwei Knoten mit einem sauber platzierten Zeugen und geprüfter Sicherung sind mehr wert als vier Knoten, deren Quorum niemand überprüft hat.

Verwandte Themen: Wer hier weiterdenkt, liest bei VMware Alternativen, RAID und Virtualisierung weiter.