Hyper-V Failover Cluster aufbauen: Quorum, freigegebene Cluster-Volumes und Live-Migration
Der Aufbau ist in einem Tag zu schaffen. Entscheidend sind die Prüfungen davor und die eine Prüfung danach: Übersteht der Cluster den Ausfall eines Knotens wirklich?
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Cluster steht, aber niemand hat den Ernstfall geprobt
Die häufigste Schwachstelle ist eine übersprungene Validierung. Microsoft unterstützt Clusterlösungen laut Dokumentation nur dann, wenn die vollständige Konfiguration alle Validierungstests besteht und ausschließlich zertifizierte Hardware für die eingesetzte Windows-Version verwendet wird. Der Assistent macht das Überspringen leicht, und im Störungsfall ist es die erste Frage, die gestellt wird. Dazu kommt ein praktischer Punkt: Mit nur einem Knoten laufen viele der kritischen Speichertests gar nicht, die Prüfung braucht also mindestens zwei.
Die zweite Schwachstelle ist das Quorum. Bei zwei Knoten und ohne Zeugen ist eine gerade Stimmenzahl im Spiel, und beim Wegfall eines Knotens ist nicht entschieden, welche Seite weiterlaufen darf. Microsoft empfiehlt für Windows Server 2012 R2 und neuer ausdrücklich, immer einen Zeugen einzurichten, weil neuere Fassungen die Stimme des Zeugen und die Stimmen der Knoten über das dynamische Quorum selbst verwalten. Das kostet zehn Minuten und entscheidet, ob aus einem Netzfehler ein Ausfall wird.
Die dritte Schwachstelle liegt beim Speicher, und sie ist besonders unangenehm, weil sie nicht als Fehler auffällt, sondern als schleichend schlechte Leistung. Ein freigegebenes Cluster-Volume auf SAN-Speicher sollte mit NTFS formatiert sein, weil damit Direct I/O möglich ist. Dasselbe Volume mit ReFS arbeitet ausdrücklich im umgeleiteten Modus, unabhängig davon, ob alle anderen Voraussetzungen für Direct I/O erfüllt wären. Auf Storage Spaces Direct ist es genau andersherum, dort ist ReFS die empfohlene Wahl.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Aufbau in sechs Schritten
Die Reihenfolge ist bewusst gewählt. Wer den Speicher vor der Validierung einbindet, prüft eine Konfiguration, die er anschließend noch ändert. Wer die Live-Migration vor dem Quorum einrichtet, hat einen Cluster, der Maschinen verschieben, aber einen Ausfall nicht überstehen kann.
- 1
Voraussetzungen schaffen und die Rolle installieren
Bring alle Knoten auf dieselbe Windows-Version, binde sie in dieselbe Domäne ein und stell die Zeitzone gleich. Verschieb die Computerkonten in eine eigene Organisationseinheit für Cluster. Installier auf jedem Knoten die Hyper-V-Rolle und das Failoverclustering samt Verwaltungswerkzeugen, unter PowerShell mit Install-WindowsFeature und dem Schalter für die Verwaltungswerkzeuge. Verbind anschließend alle Knoten mit dem gemeinsamen Speicher, damit die Validierung ihn prüfen kann.
Geschafft, wenn: Identisch aufgesetzte Knoten mit installierten Rollen und Zugriff auf denselben Speicher.
- 2
Validieren, und zwar vollständig
Führ die Validierung mit allen Tests aus, über den Assistenten oder mit Test-Cluster und der Angabe aller Knoten. Das Cmdlet legt sein Protokoll im aktuellen Arbeitsverzeichnis ab. Lies den Bericht, statt nur auf die Zusammenfassung zu schauen: Eine Warnung heißt, dass der Cluster funktionieren wird, aber von der empfohlenen Konfiguration abweicht, und genau diese Abweichungen sind es, die später Zeit kosten. Erst wenn der Bericht sauber ist, geht es weiter.
Geschafft, wenn: Ein Validierungsbericht ohne Fehler, den du für den Supportfall aufbewahrst.
- 3
Den Cluster anlegen
Leg den Cluster mit New-Cluster an, mit Namen, Knotenliste und einer festen IP-Adresse, oder ohne Speicher, wenn du ihn bewusst später hinzufügen willst. Der Name wird dabei als Clusternamensobjekt in Active Directory registriert, standardmäßig dort, wo auch die Computerkonten der Knoten liegen. Willst du es woanders haben, gibst du den vollständigen Namen der Organisationseinheit an. Rechne damit, dass die Namensauflösung im Verzeichnisdienst und im DNS eine Weile braucht.
Geschafft, wenn: Ein Cluster mit registriertem Namensobjekt, der in der Verwaltungskonsole erscheint.
- 4
Quorum und Zeugen einrichten
Setz den Zeugen passend zur Topologie. Für einen Cloudzeugen brauchst du Kontonamen und Zugriffsschlüssel des Speicherkontos und Port 443 auf allen Knoten; der Cluster erzeugt darin einen eigenen Container und legt statt des Schlüssels ein zeitlich begrenztes Zugriffstoken ab. Für einen Dateifreigabezeugen auf einem nicht in die Domäne eingebundenen Gerät ist PowerShell der einzige Weg, und der Cluster muss mindestens Windows Server 2019 sein. Prüf die Einstellung anschließend mit Get-ClusterQuorum.
Geschafft, wenn: Ein Cluster mit ungerader Stimmenzahl, der einen Knotenausfall entscheiden kann.
- 5
Speicher als freigegebenes Cluster-Volume bereitstellen
Formatier den Datenträger passend zum Speicher darunter, bevor du ihn zum freigegebenen Cluster-Volume machst: NTFS bei SAN-Anbindung, ReFS bei Storage Spaces Direct. Danach erscheint das Volume unter dem Pfad ClusterStorage auf dem Systemlaufwerk, und zwar auf allen Knoten gleich. Benenn Volumes gleich zu Beginn um, wenn du das willst, denn bei geöffneten Handles, also bei laufenden Maschinen, geht das nicht mehr. Plan mindestens ein Volume je Knoten ein.
Geschafft, wenn: Freigegebene Cluster-Volumes, auf die alle Knoten gleichzeitig lesend und schreibend zugreifen.
- 6
Live-Migration einrichten und den Ausfall proben
Aktivier die Migration mit Enable-VMMigration, begrenz den eingehenden Verkehr mit Set-VMMigrationNetwork auf das dafür vorgesehene Netz und stell die Authentifizierung mit Set-VMHost auf Kerberos. Die Leistungsoption steht standardmäßig auf Kompression, SMB nutzt bei entsprechender Hardware SMB Direct und mehrere Kanäle. Die Zahl gleichzeitiger Migrationen ist mit zwei vorbelegt. Prüf zum Schluss beides: eine geplante Verschiebung und einen harten Ausfall eines Knotens.
Geschafft, wenn: Maschinen wandern ohne spürbare Unterbrechung, und ein abgeschalteter Knoten führt zum automatischen Neustart seiner Maschinen anderswo.
Fünf Weichen, die vor dem ersten Befehl gestellt werden
- 01 Gleiche Windows-Version, gleiche Domäne, gleiche Zeitzone, kein Domänencontroller auf einem Knoten
- 02 Getrennte Netze für Cluster, Live-Migration und Speicher, mit abgeschalteter Clusternutzung auf dem Speichernetz
- 03 Zeugenform: Datenträger, Dateifreigabe oder Cloud, passend zur Zahl der Standorte
- 04 Dateisystem des freigegebenen Cluster-Volumes: NTFS auf SAN, ReFS auf Storage Spaces Direct
- 05 Authentifizierung der Live-Migration: Kerberos mit eingeschränkter Delegierung statt CredSSP
Was vor dem ersten Knoten feststehen muss
Sechs Festlegungen, die den Aufbau danach zu einer Abfolge von Befehlen machen. Jede einzelne nachträglich zu ändern, bedeutet Ausfallzeit.
Gleiche Windows-Version auf allen Knoten
Alle Server, die Clusterknoten werden sollen, müssen dieselbe Version von Windows Server ausführen und in derselben Active-Directory-Domäne und derselben Zeitzone wie der lokale Domänencontroller liegen. Ein Domänencontroller darf außerdem nicht auf einem der Clusterknoten laufen. Diese vier Punkte stehen so in der Dokumentation und sind der Grund für einen erheblichen Teil aller Fehlversuche beim Anlegen.
Eine eigene Organisationseinheit für den Cluster
Microsoft empfiehlt, Failovercluster in einer eigenen Organisationseinheit abzulegen. Damit steuerst du gezielt, welche Gruppenrichtlinien und Sicherheitsvorlagen auf die Knoten wirken, und verhinderst nebenbei das versehentliche Löschen der Clustercomputerobjekte. Das Konto, das den Cluster anlegt, braucht in dieser Organisationseinheit die Berechtigung zum Erstellen von Computerobjekten, oder ein Domänenadministrator legt das Clusternamensobjekt vorher an.
Netze trennen und die Rollen festlegen
Für den Datenverkehr des Clusters, für die Live-Migration und für den Speicher gehören getrennte Wege eingerichtet, damit sich die Lasten nicht gegenseitig verdrängen. Netze, die der Cluster nicht nutzen soll, etwa iSCSI-Netze, deaktivierst du ausdrücklich für die Clusterkommunikation. Für die Live-Migration ist die Trennung nicht nur eine Leistungsfrage: Der Datenverkehr ist nicht verschlüsselt, deshalb empfiehlt Microsoft als bewährte Praxis ein vertrauenswürdiges, abgetrenntes Netz.
Den Zeugen passend zur Topologie wählen
Es gibt drei Formen. Ein Datenträgerzeuge ist ein gemeinsam erreichbarer Datenträger ohne Laufwerksbuchstaben, als Basisdatenträger eingerichtet, mit NTFS oder ReFS formatiert und größer als 512 MB. Ein Dateifreigabezeuge braucht SMB 2 oder neuer, mindestens 5 MB freien Platz und eine Freigabe, die ausschließlich diesem Cluster dient. Ein Cloudzeuge nutzt ein Azure-Speicherkonto vom Typ Standard General Purpose v2 und braucht Port 443 nach außen.
Das Dateisystem zum Speicher darunter passend wählen
Für freigegebene Cluster-Volumes auf SAN-Speicher empfiehlt Microsoft NTFS, weil das Direct I/O ermöglicht. Für Volumes auf Storage Spaces Direct empfiehlt Microsoft ReFS, wegen der Integritätsfunktionen, Block Cloning und der Optimierungen für diese Lasten. Ein freigegebenes Cluster-Volume kann außerdem nicht als Datenträgerzeuge dienen. Diese Entscheidung fällt vor dem Formatieren, denn nachträglich bedeutet sie einen Datenumzug.
Die Authentifizierung für die Live-Migration klären
Es gibt zwei Verfahren. Kerberos verlangt eine eingeschränkte Delegierung, erspart dir dafür die Anmeldung am Quellserver. CredSSP erspart die Delegierung, verlangt dafür aber eine Anmeldung auf dem jeweiligen Quellserver. Wichtig für Neuaufbauten: Ab Windows Server 2025 ist Credential Guard auf domänengebundenen Servern standardmäßig aktiv, und Live-Migration über CredSSP funktioniert damit nicht mehr. Für neue Cluster ist Kerberos mit eingeschränkter Delegierung deshalb der Weg.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Quorum verstehen, statt es einmal zu setzen
Das Quorum beantwortet eine einzige Frage: Welche Teilmenge der Knoten darf weiterlaufen, wenn die Verbindung untereinander abreißt? Ohne diese Antwort könnten beide Seiten weiterlaufen und dieselben Daten schreiben, was der teuerste aller Ausgänge wäre. Neuere Windows-Versionen verwalten die Stimmen der Knoten und die Stimme des Zeugen dynamisch, was die Sache robuster macht. Die Empfehlung, immer einen Zeugen einzurichten, gilt trotzdem, und zwar seit Windows Server 2012 R2.
Die Wahl der Form hängt an der Topologie. Ein Datenträgerzeuge setzt gemeinsam erreichbaren Speicher voraus, üblicherweise ein SAN, und muss ein Basisdatenträger ohne Laufwerksbuchstaben sein, größer als 512 MB und ausschließlich für diesen Zweck verwendet. Ein Dateifreigabezeuge braucht nur SMB 2 und 5 MB Platz, sollte aber physisch von den Knoten getrennt stehen, also möglichst in einem anderen Raum, an einem anderen Strang und in einem anderen Netzsegment. Verteilte Dateisysteme und replizierte Speichertechniken sind für diesen Zweck ausdrücklich nicht unterstützt.
Der Cloudzeuge ist die pragmatische Antwort für zwei Standorte oder für einen Cluster in einer kleinen Außenstelle. Er braucht ein Azure-Speicherkonto vom Typ Standard General Purpose v2, weil nur dieser Typ unterstützt ist, und auf allen Knoten ausgehenden Zugriff auf Port 443. Läuft der Verkehr über einen Proxy, konfigurierst du diesen für die HTTP-Dienste von Windows, denn der Cluster nutzt genau diesen Weg. Ein Speicherkonto kann als Zeuge für mehrere Cluster dienen.
Freigegebene Cluster-Volumes und die Frage nach Direct I/O
Ein freigegebenes Cluster-Volume erlaubt es mehreren Knoten, gleichzeitig lesend und schreibend auf dieselbe logische Einheit zuzugreifen. Genau das ist die Voraussetzung dafür, dass eine Maschine den Knoten wechseln kann, ohne dass ein Volume abgehängt und woanders wieder eingehängt werden muss. Ein Knoten ist dabei immer der Koordinator und besitzt die Datenträgerressource. Seit Windows Server 2012 R2 wird die Zuständigkeit gleichmäßig über die Knoten verteilt und nach einem Ausfall, einem Neustart oder dem Hinzufügen eines Knotens automatisch neu ausbalanciert.
Für die Leistung ist der Zugriffsweg entscheidend. Im Normalfall spricht jeder Knoten direkt mit dem Speicher. Fällt die Verbindung eines Knotens zum Speicher aus oder erzwingt ein Vorgang wie eine Sicherung den umgeleiteten Modus, laufen die Ein- und Ausgaben über das Clusternetz zum Koordinator. Deshalb gehört bei der Netzplanung eine Reserve für genau diesen Fall eingerechnet. Es gibt zwei Formen der Umleitung: die auf Dateisystemebene je Volume und die schnellere auf Blockebene, die bei Verlust der Speicherverbindung greift. Mit Get-ClusterSharedVolumeState siehst du je Knoten, welcher Zustand gerade gilt.
Die Wahl des Dateisystems ist damit keine Geschmacksfrage. Auf einem SAN mit NTFS ist Direct I/O möglich, mit ReFS ausdrücklich nicht, auch dann nicht, wenn alle übrigen Voraussetzungen erfüllt sind. Auf Storage Spaces Direct ist ReFS die Empfehlung, wegen der Integritätsfunktionen und Block Cloning, und auch dort läuft ein ReFS-Volume ohne Direct I/O. Wer eine gemischte Umgebung betreibt, hält diese Regel schriftlich fest, sonst formatiert der nächste Kollege nach Gefühl.
Live-Migration einrichten und danach nicht mehr anfassen
Für die Einrichtung ohne Cluster gibt es drei Cmdlets, und im Cluster gelten dieselben Einstellungen auf Hostebene: Enable-VMMigration schaltet ein- und ausgehende Migrationen frei, Set-VMMigrationNetwork begrenzt den eingehenden Verkehr auf ein bestimmtes Netz, und Set-VMHost setzt Authentifizierung und Leistungsoption. Die Zahl gleichzeitiger Migrationen ist mit zwei vorbelegt und lässt sich ändern, sollte aber zur Bandbreite des dafür vorgesehenen Netzes passen.
Bei der Leistungsoption stehen drei Wege zur Wahl. TCP/IP überträgt den Arbeitsspeicher der Maschine unverändert über eine TCP-Verbindung. Kompression komprimiert den Inhalt vorher und ist die Vorgabe. SMB überträgt über eine SMB-3.0-Verbindung, nutzt bei Netzkarten mit RDMA automatisch SMB Direct und bei passender Konfiguration mehrere Kanäle gleichzeitig. Für ein Netz mit RDMA ist SMB deshalb die interessanteste Wahl, für ein gewöhnliches Netz bleibt Kompression eine gute Vorgabe.
Bei der Authentifizierung ist die eingeschränkte Kerberos-Delegierung der Weg, den du einmal einrichtest und danach vergisst. Sie wird je Computerkonto gesetzt, für die Verschiebung des Speichers über den Dienst cifs und für die Verschiebung der Maschinen über den Dienst Microsoft Virtual System Migration Service, und zwar wechselseitig für jedes Knotenpaar. Die Einrichtung braucht ein Konto aus der Gruppe der Domänenadministratoren und wird erst wirksam, wenn die Änderung repliziert und ein neues Kerberos-Ticket ausgestellt ist.
Den Cluster im Betrieb halten
Für Aktualisierungen gibt es Cluster-Aware Updating. Es nimmt jeden Knoten nacheinander in den Wartungsmodus, verschiebt die Clusterrollen weg, installiert die Aktualisierungen samt Abhängigkeiten, startet bei Bedarf neu, holt den Knoten zurück und stellt die Rollen wieder her. Bei durchgehend verfügbaren Lasten wie Hyper-V mit Live-Migration geschieht das ohne Auswirkung auf die Verfügbarkeit. Es gibt zwei Betriebsarten: die selbstaktualisierende, bei der der Cluster sich als eigene Rolle selbst aktualisiert, und die ferngesteuerte über einen Rechner, der nicht Mitglied des Clusters ist.
Ein zweites Werkzeug ist der Lastausgleich für virtuelle Maschinen. Er bewertet die Auslastung anhand des Speicherdrucks und der über fünf Minuten gemittelten Prozessorauslastung und verschiebt Maschinen per Live-Migration von überlasteten auf weniger ausgelastete Knoten, wobei Regeln wie Antiaffinität und mögliche Besitzer eingehalten werden. Unter Windows Server ist standardmäßig der Modus aktiv, der beim Beitritt eines Knotens ausgleicht; die Stufe für die Aggressivität steht auf niedrig, also erst ab achtzig Prozent Auslastung. Für laufendes Nachregeln alle dreißig Minuten stellst du das ausdrücklich um.
Der wichtigste Betriebspunkt bleibt die Probe. Ein Cluster, dessen Knotenausfall nie ausgelöst wurde, ist ein Cluster mit einer Annahme. Nimm einmal im Quartal einen Knoten hart vom Netz und miss, wie lange die Maschinen bis zum Neustart brauchen und ob alle wieder hochkommen. Prüf dabei auch, ob die verbleibende Kapazität ausreicht: Ein Cluster aus zwei Knoten, die beide zu siebzig Prozent ausgelastet sind, kann den Ausfall eines Knotens rechnerisch nicht auffangen, egal wie gut das Quorum eingestellt ist.
Dazu passende Kurse
Weil sich das Zusammenspiel von Quorum, Speicher und Migration schlecht am Schreibtisch erschließt, sind Hyper-V-Kurse zu Cluster und Hochverfügbarkeit der schnellste Weg zu einer belastbaren Konfiguration.
Wenn Hochverfügbarkeit über die Virtualisierung hinaus geplant werden soll, findest du bei cmt Trainings zu Hochverfügbarkeit im Serverbetrieb .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Reichen zwei Knoten für einen produktiven Hyper-V-Cluster?
Können wir die Validierung überspringen, wenn wir wissen, dass die Hardware passt?
Wo speichern wir die virtuellen Maschinen, auf einem großen oder auf mehreren Volumes?
Wir haben auf Windows Server 2025 aktualisiert, und die Live-Migration bricht ab. Woran liegt das?
Wie groß darf ein Hyper-V-Cluster werden?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Einen Cluster einmal selbst aufbauen und ausfallen lassen
Quorum, freigegebene Cluster-Volumes und Live-Migration lassen sich lesen, aber erst der selbst ausgelöste Knotenausfall zeigt, ob die Konfiguration trägt. Genau das steht in den Hyper-V-Kursen bei cmt auf dem Programm.
Passt dazu
- Hyper-V oder VMware vSphere: was für welchen Serverraum passt
- Virtuelle Maschine unter Hyper-V ist langsam: CPU, Arbeitsspeicher und Speicher prüfen
- Backup-Konzept für Hyper-V: Prüfpunkte sind keine Sicherung
- ReFS oder NTFS: welches Dateisystem für welchen Server