# Failover Clustering > Quorum, Zeugenarten und Stimmenverteilung so wählen, dass ein Cluster den Ausfall übersteht, für den er gebaut wurde — und die Kapazitätsrechnung für den Ausfall vor der Konfigurationsfrage stellen. Track: [Windows Server Administration](https://physar.tech/learn/windows-server-administration) Kanonische Fassung: https://physar.tech/learn/windows-server-administration/failover-clustering Stand: 2026-09-04 Interaktiver Teil: 9 Checks (nur im Browser) ## Failover Clustering: Stimmen, Zeugen und die Rechnung für den Ausfall ### Was ein Cluster leistet — und was nicht Ein Failovercluster sorgt dafür, dass eine Rolle nach dem Ausfall eines Knotens auf einem anderen weiterläuft. Er verhindert keinen Ausfall, er verkürzt ihn. Und er tut das nur, wenn die übrigen Knoten die Last tatsächlich tragen können. Die zweite Hälfte dieses Satzes wird beim Aufbau regelmäßig übersehen. Ein Cluster aus vier Knoten, die im Normalbetrieb jeweils zu 80 Prozent ausgelastet sind, hat für den Ausfall eines Knotens keine Reserve — die verbleibenden drei müssten danach über 100 Prozent tragen. Hochverfügbarkeit ist deshalb zuerst eine Kapazitätsaussage und erst danach eine Konfigurationsfrage. > **Abgrenzung:** Der Nachbartrack `virtualization-private-cloud` behandelt Cluster als herstellerneutrale Disziplin. Hier geht es um Windows Server Failover Clustering als Rolle des Betriebssystems — es trägt nicht nur virtuelle Maschinen, sondern auch Dateiserver, DHCP und Datenbankinstanzen, und seine Quorumsmechanik ist Windows-spezifisch. ### Die Reserve, die es nicht gibt Ein Verbund aus vier Knoten trägt zwölf virtuelle Maschinen, drei je Knoten. Jeder Knoten läuft im Tagesbetrieb bei rund 75 Prozent Arbeitsspeicherauslastung. Der Betreiber gibt an, der Verbund verkrafte den Ausfall eines Knotens. **Anforderungen** - Die Aussage soll geprüft werden. - Das Ergebnis soll für die Planung nutzbar sein. **Schritte** - Gesamtbedarf ermitteln: vier Knoten zu 75 Prozent entsprechen dem Bedarf von drei vollen Knoten. - Verfügbare Kapazität nach einem Ausfall: drei Knoten. - Ergebnis rechnerisch: Es passt gerade, ohne jede Reserve und ohne Spielraum für Wachstum. - Zweiten Ausfall prüfen: zwei Knoten müssten den Bedarf von dreien tragen — das geht nicht. - Für die Aussage festhalten: Der Verbund verkraftet genau einen Ausfall, und danach ist er ohne Reserve. **Merksatz:** Die Angabe war nicht falsch, aber unvollständig. Ein Cluster hat zwei Kapazitätszahlen — die für den Normalbetrieb und die für den Ausfall —, und nur die zweite beantwortet die Frage, für die es ihn gibt. ### Quorum verhindert zwei Wahrheiten Das zentrale Problem eines Clusters ist nicht der Ausfall eines Knotens, sondern der Verlust der Verbindung zwischen ihnen. Können sich zwei Teilmengen nicht mehr erreichen, hält jede sich für die überlebende — und beide beginnen, dieselbe Rolle zu betreiben und auf dieselben Daten zu schreiben. **Quorum:** Der Mechanismus, der genau eine Teilmenge weiterlaufen lässt. Überlebende Knoten müssen belegen können, dass sie die Mehrheit stellen; können sie das nicht, gehen sie offline. > **Warum Offline die richtige Antwort ist:** Ein Knoten, der sich nicht als Mehrheit ausweisen kann, schaltet ab — auch wenn er technisch weiterarbeiten könnte. Das wirkt wie eine Selbstbeschädigung und ist die einzige Alternative zu zwei parallel schreibenden Systemen. Der Datenverlust aus einem geteilten Zustand ist regelmäßig schwerer zu reparieren als eine Ausfallzeit. Der Begriff für den zu vermeidenden Zustand ist geteiltes Bewusstsein: Zwei Teilmengen halten sich beide für den Cluster. Für einen Dateiserver heißt das, dass zwei Knoten dieselben Dateien schreiben; für eine Datenbank, dass zwei Instanzen dieselbe Datei ändern. Das Ergebnis ist in beiden Fällen kein Ausfall, sondern eine Beschädigung — und die fällt oft erst Tage später auf, wenn niemand mehr sagen kann, welcher Stand der richtige war. Deshalb ist die harte Abschaltregel keine Vorsicht, sondern der Kern des Verfahrens. ### Die Rechnung mit den Stimmen Mehrheit funktioniert sauber nur bei einer ungeraden Gesamtzahl. Bei vier Knoten und einer sauberen Teilung in zwei mal zwei kann keine Seite eine Mehrheit vorweisen — beide gehen offline, und der Cluster ist vollständig aus. _[Abbildung: Ohne ungerade Stimmenzahl gibt es Teilungen, bei denen keine Seite die Mehrheit hat.]_ | | | | --- | --- | | 2 Knoten | Ein Zeuge ist laut Dokumentation **erforderlich**. Ohne ihn nimmt jeder Ausfall den Cluster mit. | | 3 oder 4 Knoten | Ein Zeuge wird **dringend empfohlen**. | | 5 Knoten oder mehr | Ein Zeuge wird laut Dokumentation **nicht benötigt** und bringt keine zusätzliche Widerstandsfähigkeit. | > **Die Zeile, die überrascht:** Die dritte Zeile widerspricht der verbreiteten Annahme, ein Zeuge sei immer gut. Ab fünf Knoten trägt die ungerade Stimmenzahl die Entscheidung bereits allein; ein Zeuge fügt nichts hinzu und schafft eine zusätzliche Abhängigkeit, die selbst ausfallen kann. Wer ihn trotzdem einrichtet, hat eine Komponente mehr zu überwachen und keinen Gewinn. ### Drei Arten von Zeugen Ein Zeuge ist eine zusätzliche Stimme, die keine Rolle betreibt. Es gibt drei Bauformen, und ihre Wahl hängt davon ab, was in der Umgebung überhaupt erreichbar ist. | | | | --- | --- | | Cloudzeuge | Ein Blob in einem Azure-Speicherkonto. Braucht ausgehend Port 443 von **allen** Knoten. | | Datenträgerzeuge | Ein gemeinsam erreichbarer Datenträger, typischerweise aus einem Speichernetz. | | Dateifreigabezeuge | Eine SMB-Freigabe, ab SMB 2, mit mindestens 5 MB freiem Platz. | > **Die Anforderungen, die man überliest:** Der Datenträgerzeuge darf laut Dokumentation **keinen Laufwerksbuchstaben** haben und für nichts anderes benutzt werden — kein Platz für Daten oder Anwendungen —, und er muss ein Basisdatenträger sein. Der Dateifreigabezeuge darf auf einem Gerät liegen, das **nicht** Mitglied der Domäne ist: ein NAS, ein Arbeitsgruppenrechner, sogar ein Router mit USB-Speicher. Ein Dateiserver kann mit mehreren Freigaben als Zeuge für mehrere Cluster dienen. Für den Cloudzeugen ist der Firewallpunkt der entscheidende: Port 443 muss von jedem Knoten aus offen sein, nicht nur von einem. Ein praktischer Hinweis zur Auswahl: Der Dateifreigabezeuge ist der anspruchsloseste — 5 MB freier Platz und SMB 2 genügen, und das Gerät muss nicht einmal Mitglied der Domäne sein. Genau das macht ihn für kleine Umgebungen attraktiv und erzeugt zugleich die häufigste Fehlkonstruktion: Die Freigabe liegt auf einem der Cluster-Knoten selbst oder auf einem Server, der von derselben Stromversorgung, demselben Switch oder demselben Virtualisierungshost abhängt. Ein Zeuge, der mit dem Cluster gemeinsam ausfällt, ist keine zusätzliche Stimme, sondern eine zusätzliche Illusion. ### Der Zeuge am falschen Ort Ein Zeuge entscheidet mit, welche Teilmenge weiterlebt. Daraus folgt eine Anforderung, die in Standortkonstruktionen regelmäßig verletzt wird: Er darf nicht dort liegen, wo im Ausfallszenario ohnehin alles wegfällt. Ein Cluster über zwei Standorte mit je zwei Knoten und einem Zeugen im Standort A überlebt den Ausfall von Standort B — und stirbt beim Ausfall von Standort A vollständig, weil dort drei von fünf Stimmen lagen. Das ist genau die Konstruktion, die man vermeiden wollte, und sie sieht auf dem Papier symmetrisch aus. > **Deshalb der Cloudzeuge:** Für Cluster über zwei Standorte ist ein Zeuge an einem dritten Ort die einzige Konstruktion, die beide Ausfälle überlebt. Der Cloudzeuge ist dafür gebaut — und für Umgebungen ohne Internetzugang bleibt ein dritter Standort oder ein bewusst getragenes Restrisiko. Die Entscheidung gehört benannt, nicht gefunden. ### Dynamisches Quorum Neuere Windows-Server-Versionen verwalten die Stimmen laut Dokumentation automatisch: Sowohl die Knotenstimmen als auch die Zeugenstimme werden dynamisch angepasst, wenn sich die Zusammensetzung ändert. Praktisch heißt das: Fällt ein Knoten aus, wird ihm die Stimme entzogen, und die verbleibenden bilden eine neue Mehrheit. Ein Cluster kann dadurch nacheinander mehr Ausfälle überstehen, als eine statische Rechnung erlauben würde — nacheinander, nicht gleichzeitig. Der Unterschied ist entscheidend: Zwei aufeinanderfolgende Ausfälle mit Zeit dazwischen sind etwas anderes als zwei gleichzeitige. > **Was das für die Diagnose bedeutet:** Weil die Stimmen dynamisch sind, ist die aktuelle Stimmenverteilung eine Momentaufnahme und keine Konstante. Bei einer Bewertung der Widerstandsfähigkeit gehört deshalb der Ist-Zustand abgefragt statt aus der Knotenzahl gerechnet — `Get-ClusterQuorum` für die Konfiguration, `Get-ClusterNode` mit den Stimmeneigenschaften für die aktuelle Verteilung. | | | | --- | --- | | `Get-Cluster` | Grundzustand und die clusterweiten Eigenschaften. | | `Get-ClusterNode` | Knoten mit Zustand, `NodeWeight` und `DynamicWeight` — die aktuelle Stimmenverteilung. | | `Get-ClusterQuorum` | Welches Quorumsmodell und welcher Zeuge sind konfiguriert? | | `Get-ClusterGroup` / `Get-ClusterResource` | Welche Rolle läuft auf welchem Knoten, und welche Ressource ist offline? | | `Get-ClusterSharedVolume` | Zustand der gemeinsamen Volumes, einschließlich des umgeleiteten Zugriffs. | ### Gemeinsam genutzte Volumes Damit eine Rolle auf einem anderen Knoten weiterlaufen kann, muss dieser Knoten an ihre Daten kommen. Cluster Shared Volumes lösen das, indem alle Knoten gleichzeitig auf dasselbe Volume zugreifen — statt es bei jedem Failover umzuhängen. - Ein Umschalten der Rolle braucht dann kein Trennen und Einbinden des Datenträgers mehr, was den Failover erheblich verkürzt. - Mehrere Rollen können sich ein Volume teilen, ohne einander beim Umschalten zu blockieren. - Der Zugriff läuft über einen Pfad unterhalb von `C:\ClusterStorage` — auf jedem Knoten derselbe. - Fällt der Zugriffsweg eines Knotens auf das Speichersystem aus, kann der Verkehr umgeleitet werden; die Leistung sinkt dabei deutlich. > **Der Zustand, den man nicht übersieht:** Der letzte Punkt erzeugt ein Fehlerbild, das keine Störung meldet: Der Cluster läuft weiter, aber ein Knoten arbeitet im umgeleiteten Modus und alle seine Zugriffe laufen über einen anderen Knoten. Die Rolle ist verfügbar, die Leistung ist es nicht — und in der Verfügbarkeitsstatistik taucht nichts auf. Der umgeleitete Modus gehört deshalb ausdrücklich in die Überwachung, nicht nur der Zustand der Rolle. Zu beachten ist außerdem, was auf einem gemeinsamen Volume nicht laufen sollte. Werkzeuge, die von einem einzelnen Knoten aus exklusiv auf das Dateisystem zugreifen — bestimmte Virenscanner, Defragmentierungsläufe, Sicherungsagenten ohne Clusterunterstützung —, gehen von einer Annahme aus, die hier nicht gilt: dass sie allein sind. Vor dem Einsatz eines solchen Werkzeugs auf einem Cluster gehört die Frage an den Hersteller, ob es Cluster Shared Volumes unterstützt. Die Antwort steht selten im Datenblatt und fast immer in der Supportdokumentation. ### Wartung ist ein geplanter Failover Ein Knoten, der gepatcht oder neu gestartet werden soll, wird nicht einfach heruntergefahren. Der geordnete Weg entzieht ihm zuerst die Rollen und nimmt ihn dann aus der Beteiligung — beides mit einem Befehl, dessen Ergebnis prüfbar ist. Vorher prüfen, ob die verbleibenden Knoten die Last tragen können — die Kapazitätsfrage aus dem ersten Abschnitt. → `Suspend-ClusterNode -Drain` — Rollen geordnet auf andere Knoten verschieben. → Prüfen, dass die Rollen dort tatsächlich laufen, nicht nur, dass sie verschoben wurden. → Die Wartung durchführen, Neustart eingeschlossen. → `Resume-ClusterNode` — den Knoten wieder aufnehmen, gegebenenfalls mit Rückverlagerung der Rollen. → Den Clusterzustand und die Stimmenverteilung prüfen, bevor der nächste Knoten drankommt. Zu beachten ist außerdem die Reihenfolge über den ganzen Verbund: Ein Knoten nach dem anderen, mit vollständiger Rückkehr dazwischen. Wer zwei Knoten gleichzeitig in Wartung nimmt, weil das Fenster knapp ist, verwandelt einen geplanten Vorgang in genau die Situation, gegen die der Cluster gebaut wurde — und bei vier Knoten kann das die Mehrheit kosten. Ein Wartungsplan, der die Fensterlänge über die Reihenfolge stellt, ist keine Wartung, sondern ein kalkulierter Ausfall ohne Kalkulation. ### Was der Prüflauf beantwortet Vor dem Aufbau und nach jeder wesentlichen Änderung gibt es einen Prüflauf, der die Voraussetzungen einer Clusterkonfiguration durchgeht — Netzwerk, Speicher, Systemkonfiguration und Inventar der Knoten. Sein Wert liegt weniger im Ergebnis als in seinem Zeitpunkt: Er findet Unterschiede zwischen Knoten, die im Normalbetrieb keine Rolle spielen und beim Failover entscheidend werden — abweichende Treiberstände, unterschiedliche Netzwerkkonfiguration, ungleiche Patchstände. Genau diese Unterschiede entstehen zwischen zwei Wartungsfenstern und fallen sonst niemandem auf. > **Und seine Grenze:** Der Prüflauf bewertet die Plattform, nicht die Anwendung. Dass ein Cluster technisch einwandfrei umschaltet, sagt nichts darüber, ob die darauf laufende Datenbank den Umschaltvorgang verkraftet oder ob die Clients dem neuen Knoten folgen. Diese Prüfung ist eine eigene und läuft über den Weg, den die Clients benutzen. Praktisch lohnt es, den Prüflauf nicht nur vor dem Aufbau anzusetzen, sondern in einem festen Abstand zu wiederholen — etwa halbjährlich und nach jeder Erweiterung. Der Grund ist derselbe wie bei der Übernahmeprüfung anderer Module: Der Befund entsteht schleichend, meldet sich nicht von selbst und ist im Ernstfall nicht mehr korrigierbar. Ein Knoten, dessen Netzwerkkonfiguration seit einem Jahr von den übrigen abweicht, funktioniert im Normalbetrieb einwandfrei und scheitert genau dann, wenn eine Rolle auf ihn umschalten soll. ### Der Cluster ist nicht der Dienst Ein grüner Clusterzustand ist ein Signal über die Plattform. Zwischen ihm und einem funktionierenden Dienst liegen dieselben Schichten wie bei einem Einzelserver — plus zwei, die es nur im Cluster gibt. | | | | --- | --- | | Knotenzustand | Der Knoten ist Mitglied und stimmberechtigt. | | Rollenzustand | Die Rolle läuft auf einem Knoten. | | Netzwerkname und Adresse | Die Clientzugriffspunkte der Rolle sind online und lösen auf. | | Clientpfad | Ein echter Client erreicht die Rolle über ihren Namen und bekommt eine Antwort. | **Kurzcheck:** Nach einem Failover meldet der Cluster alle Rollen als online, aber Clients erreichen die Dateifreigabe nicht. Woran liegt es am ehesten? - [x] Der Clientzugriffspunkt löst nicht auf den neuen Knoten auf - [ ] Das Quorum ist verloren, deshalb antwortet der Cluster nicht - [ ] Der neue Knoten hat keinen Zugriff auf das gemeinsame Volume > Richtig. Eine Rolle bringt Netzwerkname und Adresse mit; wenn deren Registrierung oder Auflösung hinterherhängt, läuft die Rolle und ist trotzdem nicht erreichbar. Die vierte Zeile ist die einzige, die eine Aussage über den Dienstvertrag trägt. Alle drei darüber sind Signale des Clusters über sich selbst — nützlich für die Eingrenzung, ungeeignet als Abnahme. Nach einem Failover, geplant oder ungeplant, gehört deshalb dieselbe Prüfung wie nach jedem Change: eine echte Anfrage über den Namen, den die Clients benutzen, mit einem Konto, das ein Nutzer hätte. Alles andere bestätigt nur, dass der Cluster getan hat, was der Cluster tun sollte. ### Wenn ein Knoten dauerhaft fehlt Ein Knoten, der längere Zeit nicht zurückkommt, ist kein neutraler Zustand. Solange er als Mitglied geführt wird, zählt er in der Rechnung mit — und ein Cluster, der auf dem Papier vier Knoten hat und tatsächlich drei, ist gegen den nächsten Ausfall schlechter geschützt, als seine Dokumentation behauptet. > **Die Entscheidung, die niemand trifft:** Nach einem Hardwareausfall bleibt der defekte Knoten oft wochenlang im Cluster stehen, weil das Ersatzteil unterwegs ist und niemand die Konfiguration anfassen will. Das ist vertretbar, wenn es eine Entscheidung ist — und gefährlich, wenn es ein Versäumnis ist. Die Frage lautet: Wie viele Ausfälle verkraftet dieser Cluster **heute**, nicht wie viele er im Entwurf verkraften sollte. Technisch gibt es dafür zwei Wege mit unterschiedlicher Tragweite. Ein Knoten lässt sich vorübergehend aus der Beteiligung nehmen, ohne ihn zu entfernen — dann verliert er seine Stimme, bleibt aber Mitglied und kehrt später ohne Neuaufnahme zurück. Oder er wird aus dem Cluster entfernt, was die Konfiguration aufräumt und eine Wiederaufnahme zu einem eigenen Vorgang macht. Die erste Variante ist für Wochen richtig, die zweite für Monate. Beide sind besser als die dritte, die in der Praxis am häufigsten gewählt wird: nichts zu tun. ### Was in die Übergabe gehört - Wie viele gleichzeitige Ausfälle soll dieser Cluster überstehen — und trägt die Kapazität das? - Welche Zeugenart, an welchem Ort, und warum dieser Ort? - Wie sieht die aktuelle Stimmenverteilung aus, nicht die geplante? - Welche Rollen laufen worauf, und wohin schalten sie um? - Wie wird ein Knoten geordnet aus der Wartung und wieder hinein genommen? - Woran erkennt die Überwachung einen umgeleiteten Speicherzugriff? > **Der Preis eines Clusters:** Ein Cluster verdoppelt nicht die Verfügbarkeit und verdoppelt sicher die Komplexität: mehr Knoten zu patchen, eine Quorumskonfiguration zu verstehen, ein Speichersystem als gemeinsame Abhängigkeit, und ein Fehlerbild mehr — das des Clusters selbst. Für eine Anwendung, deren Ausfall eine Stunde kostet und die aus einer Sicherung in vierzig Minuten zurückkommt, ist er die teurere Lösung. Diese Rechnung gehört vor den Aufbau, nicht in die erste Störung. ## Quellen - Deploy a quorum witness for a failover cluster — https://learn.microsoft.com/en-us/windows-server/failover-clustering/manage-cluster-quorum - Understand cluster quorum — https://learn.microsoft.com/en-us/azure/azure-local/concepts/quorum - Fault tolerance and storage efficiency — https://learn.microsoft.com/en-us/azure/azure-local/concepts/fault-tolerance - SMB security enhancements — https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-security - Group Managed Service Accounts overview — https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview - Failover Clustering overview — https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview - learn.microsoft.com/en-us/windows-server/failo…torage-architectures — https://learn.microsoft.com/en-us/windows-server/failover-clustering/storage-architectures - learn.microsoft.com/en-us/windows-server/failo…ate-failover-cluster — https://learn.microsoft.com/en-us/windows-server/failover-clustering/create-failover-cluster