Windows Server 2025 / Einen Failovercluster planen

Windows Server Failover Clustering (WSFC), die Failoverclusterfunktion von Windows Server, koordiniert unterstützte Rollen auf mehreren Servern und kann sie nach Ausfällen neu starten oder verschieben. Zwei Server allein ergeben noch keine vollständige Lösung: Anwendung, Speicher, Netz, Quorum, Validierung und Wiederherstellungsziele müssen zusammenpassen.

Abzufangende Ausfälle definieren

Ein Knoten ist ein teilnehmender Server. Eine Clusterrolle ist eine vom Cluster verwaltete Gruppe von Dienst- oder VM-Ressourcen. Fehlererkennung und Übergang können Verbindungen unterbrechen. Prüfen Sie deshalb, wann Clients wieder verbunden sind und die Anwendung tatsächlich nutzbar ist, statt lediglich auf einen grünen Ressourcenstatus zu achten.

Hochverfügbarkeit ersetzt weder Datensicherung noch Notfallwiederherstellung. Zwei virtuelle Maschinen auf demselben physischen Host können gemeinsam ausfallen; auch getrennte Hosts können von derselben Speichereinheit, Stromversorgung oder demselben Switch abhängen. Die Clusterfunktion auf gewöhnlichen IIS-Servern macht deren Websites nicht automatisch hochverfügbar. Klären Sie zuerst, welche Architektur die Anwendung unterstützt.

Definieren Sie die geschützte Rolle, das Recovery Time Objective (RTO), also die zulässige Wiederherstellungsdauer, und das Recovery Point Objective (RPO), also den gegenüber einem Wiederherstellungspunkt zulässigen Datenverlust. Halten Sie Beginn und Ende der Zeitmessung sowie benötigte Nachweise fest. Unterbrechungsfreiheit oder ein Datenverlust von null sind keine automatische Eigenschaft eines Clusters.

Knoten, Netz und verbleibende Kapazität prüfen

Gleichen Sie die Hardware- und Speicheranforderungen für Cluster mit Windows-Server-Version, unterstützten Geräten, Treibern und Firmware ab. Für einen neuen Entwurf eignen sich vergleichbare Windows-Server-2025-Knoten, deren Gesamtkonfiguration unterstützt und validiert werden kann. Beim üblichen Domänenverfahren gelten Bedingungen zu gleicher Version und Domäne; Arbeitsgruppencluster besitzen abweichende Voraussetzungen. Vermischen Sie die Verfahren nicht.

• Erfassen Sie Verwaltungs-, Cluster-, Speicher- und gegebenenfalls VM-Migrationsverkehr. Planen Sie Bandbreite und konkurrierende Übertragungen während Ausfall und Wiederherstellung.
• Identifizieren Sie einzelne Ausfallpunkte bei Netzadaptern, Switches, Stromversorgung und Speicherpfaden. Dokumentieren Sie gemeinsame Abhängigkeiten unabhängig von unterschiedlichen Knotennamen.
• Berechnen Sie verbleibende CPU-, Arbeitsspeicher- und Speicherkapazität nach einem Knotenausfall, einschließlich übernommener Arbeitslast und Resynchronisierung. Genügend Gesamtkapazität im Normalbetrieb beweist keine ausreichende Ausfallkapazität.
• Prüfen Sie beim Domänenverfahren internes DNS, Zeitsynchronisierung, Clusteridentität und Namensregistrierungsrechte. Halten Sie Clusterknoten und Domänencontroller entsprechend dem Bereitstellungsverfahren getrennt.

Dokumentieren Sie Adressen, Namen, virtuelle lokale Netze (VLANs) und Firewallanforderungen in einem gemeinsamen Netzplan. Mehrere Adapter am selben Switch oder Kabelweg schaffen keine unabhängigen Pfade. Beschreiben Sie beispielsweise beim Verlust eines Hosts den übernehmenden Knoten und dessen freie Ressourcen. Beim Verlust des gemeinsam verwendeten Speichers müssen Sie erklären können, ob die verbliebenen Knoten noch Daten erreichen. Diese Szenarien gehören vor der Kapazitätsbeschaffung in den Entwurf.

Zur Rolle passenden Speicher auswählen

Gemeinsame Datenträger, Server-Message-Block-Speicher (SMB) und Storage Spaces Direct besitzen jeweils Bedingungen zu Rolle, Hardware, Edition und Unterstützung. Sie sind nicht beliebig für jede Arbeitslast austauschbar. Gleich benannte lokale Ordner stellen keine gemeinsamen Daten bereit; DFS-Namespaces erzeugen nicht automatisch Replikation oder Clusterspeicher. Die gewählte Lösung muss dem übernehmenden Knoten unterstützten Zugriff auf die aktuellen Daten ermöglichen.

Verwenden Sie eine getrennte Testumgebung, bevor produktiv genutzte Datenträger für Konfiguration oder Speichervalidierung bereitgestellt werden. Dokumentieren Sie Datenträgereigentum, Reservierungen, Pfade und Lizenzbedingungen der Architektur. Ein sichtbarer Datenträger ist nicht zwangsläufig frei zur Übernahme. Produktionsdaten gehören erst nach einem abgestimmten Schutz- und Ablaufplan in eine Speicherprüfung.

Quorum und Fehlerbereiche der Zeugen planen

Das Quorum entscheidet, ob der Cluster weiterarbeiten darf, auch wenn Netzunterbrechungen seine Bestandteile voneinander trennen. Es hilft, konkurrierenden Besitz derselben Ressourcen zu verhindern. Ein Zeuge beteiligt sich an dieser Entscheidung; er ist weder Sicherung der Dienstdaten noch ein zusätzlicher Arbeitslastknoten. Ein erreichbarer Zeuge beweist deshalb keinen funktionierenden Daten- oder Anwendungszugriff.

Vergleichen Sie Datenträger-, Dateifreigabe- und Cloudzeugen anhand des Leitfadens zur Bereitstellung von Quorumzeugen. Bewerten Sie neben der Knotenzahl Standort, Berechtigungen, Netzpartitionen und externe Konnektivität. Die Typen haben unterschiedliche Voraussetzungen; ein Cloudzeuge benötigt beispielsweise freigegebene Azure-Ressourcen und HTTPS-Verbindungen von den Knoten. Dynamisches Quorum übersteht nicht jede beliebige Kombination oder Reihenfolge von Ausfällen.

Ein Zeuge im selben Fehlerbereich kann gemeinsam mit beiden Knoten verschwinden. Räumliche Entfernung allein genügt nicht, wenn gemeinsame Leitungen ausfallen oder die Autorisierung fehlt. Erstellen Sie eine Matrix für Knotenausfall, getrennte Knotenverbindung, verlorenen Speicherpfad und vollständigen Standortausfall. Notieren Sie jeweils verbleibende Teilnehmer, Zeugenstandort, Datenzugriff und erwartetes Verhalten. Prüfen Sie diese Matrix mit den Vorgaben des gewählten Zeugentyps, bevor Sie Kontinuität als nachgewiesen betrachten.

Validierung zur Voraussetzung der Bereitstellung machen

1. Dokumentieren Sie Knoten, Netze, Speicher, Konten, Namen und geschützte Rollen. Ordnen Sie Zuständige zu und verknüpfen Sie Abhängigkeiten mit den möglichen Ausfällen.
2. Gleichen Sie Funktionen, Updates, Treiber und Supportvorgaben ab. Prüfen Sie die vollständige Konfiguration, nicht nur die einzelnen Komponenten.
3. Planen Sie die Konfigurationsvalidierung vor der Clustererstellung. Beheben oder erläutern Sie jede Warnung und jeden Fehler mit Auswirkung und Maßnahme; das bloße Speichern eines Befunds ist keine Prüfung.
4. Testen Sie geplante Verschiebungen getrennt von unerwarteten Ausfällen in einer autorisierten Umgebung. Ein erfolgreicher geplanter Wechsel beweist nicht dieselbe automatische Fehlererkennung und Wiederherstellung.
5. Messen Sie Clientwiederverbindung, Datenkonsistenz, Wiederherstellungsdauer und Alarmzustellung. Vergleichen Sie beobachtete Werte mit RTO und RPO und halten Sie Abweichungen fest, ohne Messergebnisse zu erfinden.
6. Prüfen Sie Rücksicherung und vollständigen Verlust eines Fehlerbereichs separat. Dokumentieren Sie Wiederherstellungsreihenfolge, Abhängigkeiten, Zuständigkeiten und Bedingungen für die Rückkehr zum Normalbetrieb.

Folgen Sie dem zur Architektur passenden Leitfaden zur Clustererstellung und Validierung. Speichertests können Dienste beeinträchtigen; führen Sie daher nicht ungeprüft sämtliche Tests in der Produktion aus. Bewahren Sie Bericht sowie Ursache, Auswirkung und Maßnahme jedes Befunds auf. Planen Sie beim Domänenverfahren die nötigen Rechte zur Knotenverwaltung und zum Erstellen oder Vorabbereitstellen der Computerobjekte. Um einen Berechtigungsfehler zu umgehen, ist keine pauschale Domänenadministration erforderlich.

Diese Planungsübung wandelt DC1, FS1 oder andere Kursserver nicht in einen Cluster um. Ihr Ergebnis sind unterstützte Rollen, Ressourcenbedarf, eine Fehlerbereichskarte, Unterbrechungsziele und ein Validierungsplan mit Verantwortlichen. Bleibt offen, was beim Speicherausfall geschieht oder wie gelöschte Dateien zurückkehren, halten Sie das als offene Entscheidung fest. Ein weiterer Knoten löst diese Fragen nicht von selbst.