Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Ungeplante Ausfallzeiten können erhebliche finanzielle Folgen haben. Eine einstündige Unterbrechung kritischer Anwendungen kann Unternehmen Kosten in Höhe von Tausenden bis Millionen US-Dollar durch entgangene Umsätze, Produktivitätseinbußen und Rufschäden verursachen. Aus diesem Grund ist Hochverfügbarkeit (HA) heute eine grundlegende Anforderung moderner IT-Infrastrukturen.
Wenn Ihre Server mit Windows Server betrieben werden, bietet sich das Microsoft-eigene Windows Server Failover Clustering (WSFC) als Lösung an. Es handelt sich um eine Gruppe unabhängiger Server (Knoten), die zusammenarbeiten, um die Verfügbarkeit und Skalierbarkeit von Anwendungen und Servern – sogenannte Clusterrollen – zu erhöhen.
Bei Hardware- oder Softwarefehlern an einem oder mehreren Knoten übernehmen die verbleibenden Knoten automatisch die Arbeitslast in einem Vorgang namens Failover, wodurch Dienstunterbrechungen minimiert werden.
WSFC ist keine einfache „Backup-Server“-Konfiguration, sondern eine ausgefeilte Orchestrierungsengine, die Ressourcen über mehrere unabhängige Systeme koordiniert.
Jeder Server in einem WSFC-Cluster ist ein Knoten, der entweder ein physischer Rechner oder eine virtuelle Maschine sein kann. Die Knoten kommunizieren über Netzwerke, die standardmäßig alle Heartbeat-Signale übertragen können (kleine UDP-Pakete mit 134 Byte über Port 3343). Der Cluster unterscheidet Netzwerke nicht klassisch in „öffentlich“ oder „privat“; jedes für den Cluster aktivierte Netzwerk überträgt Heartbeats und weiteren Cluster-Datenverkehr.
Trotzdem empfehlen Microsoft und erfahrene Administratoren als Best Practice, mindestens ein Netzwerk ausschließlich für die interne Cluster-Kommunikation zu reservieren. Über dieses Netzwerk laufen Gesundheitschecks, Umleitungen für Cluster Shared Volumes (CSV) und Verwaltungsbefehle – abgetrennt vom clientseitigen Anwendungsverkehr.
Eine zuverlässige Verbindung mit geringer Latenz für diese Kommunikationen senkt das Risiko falscher Fehlererkennungen deutlich. Dennoch handelt es sich nicht um ein reines „Heartbeat-Netzwerk“: Es überträgt sämtlichen kritischen Datenverkehr zwischen den Knoten.
WSFC-Knoten können in zwei Hauptmodi bereitgestellt werden:
Die größte Gefahr in jedem verteilten System ist das Split-Brain-Szenario: Cluster-Knoten verlieren die Kommunikation zueinander und gehen jeweils davon aus, der allein aktive Cluster zu sein – das führt zu Datenbeschädigungen. WSFC verhindert dies mithilfe eines Quorum-Mechanismus.
Quorum ist die Mindestanzahl an Stimmen von Cluster-Mitgliedern, die erforderlich ist, damit der Cluster online bleibt. Bei einer Netzwerkpartition führt nur der Teil mit gültigem Quorum die Arbeitslasten weiter; die übrigen Knoten werden gestoppt, um die Datenintegrität zu schützen.
Windows Server unterstützt mehrere Quorum-Typen:
Moderne Windows Server-Versionen (2012 R2 und neuer) beinhalten standardmäßig aktiviertes Dynamisches Quorum. Dadurch kann der Cluster automatisch die Anzahl der Stimmen von Knoten und Zeuge anpassen, wenn Knoten hinzugefügt oder entfernt werden. Wenn beispielsweise ein Knoten ordnungsgemäß heruntergefahren wird, berechnet der Cluster neu und weist den verbleibenden Knoten ggf. zusätzliches Gewicht zu, um das Quorum aufrechtzuerhalten. Dies erhöht die Ausfallsicherheit des Clusters ohne manuellen Eingriff erheblich.
In diesem Abschnitt werden detaillierte Schritte zur Einrichtung eines Failover-Clusters unter Windows Server 2008/2012/2016/2019/2022/2025 erläutert.
Variante A: Installation über den Server-Manager (GUI)
1. Öffnen Sie den Server-Manager auf jedem Knoten.
2. Klicken Sie auf „Verwalten“ > „Rollen und Features hinzufügen“ > „Features“.
3. Wählen Sie „Remoteserver-Verwaltungstools“ > „Feature-Verwaltungstools“ > „Failover-Clustering“ aus und schließen Sie die Installation ab. Wiederholen Sie diesen Vorgang auf jedem Knoten.
Variante B: Installation per PowerShell
Führen Sie PowerShell auf jedem Knoten als Administrator aus und geben Sie folgenden Befehl ein:
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
Der Parameter „-IncludeManagementTools“ installiert sowohl die Funktion als auch das Snap-In des Failover-Cluster-Managers.
Dieser Schritt prüft Hardware, Netzwerk, Speicher und Systemkonfigurationen auf Kompatibilität.
1. Öffnen Sie den Failover-Cluster-Manager (oder verwenden Sie das Windows Admin Center).
2. Klicken Sie im mittleren Bereich auf „Konfiguration überprüfen“.
3. Fügen Sie alle Servernamen hinzu, die als Cluster-Knoten verwendet werden sollen.
4. Wählen Sie „Alle Tests ausführen“ (empfohlen) und prüfen Sie die Ergebnisse sorgfältig.
5. Beheben Sie alle Fehler und relevanten Warnungen, bevor Sie fortfahren.
Vorgehen mit dem Windows Admin Center:
1. Navigieren Sie im Windows Admin Center zum Cluster-Manager.
2. Fügen Sie die Server als Knoten hinzu, konfigurieren Sie die Netzwerkeinstellungen (Name, IP-Adresse, Subnetzmaske, VLAN-ID) und klicken Sie auf „Weiter“.
3. Geben Sie auf der Seite „Cluster erstellen“ einen eindeutigen Cluster-Namen und eine IP-Adresse ein und klicken Sie auf „Cluster erstellen“.
4. Bei Verzögerungen bei der DNS-Verbreitung (Fehler: „Verbindung zum Cluster über DNS nicht herstellbar“) klicken Sie auf „Konnektivitätsprüfungen wiederholen“.
Vorgehen mit PowerShell:
# Erstellt einen neuen Cluster namens MyCluster mit Server1 und Server2 und statischer IP-Adresse
New-Cluster -Name MyCluster -Node Server1, Server2 -StaticAddress 192.168.1.100
Fügen Sie den Parameter „-NoStorage“ hinzu, wenn Sie den Speicher später ergänzen möchten.
Überprüfen Sie nach der Erstellung, ob der Cluster-Name im Navigationsbaum des Failover-Cluster-Managers angezeigt wird. Es kann einige Zeit dauern, bis der Name über DNS repliziert wird und im Bereich „Alle Server“ des Server-Managers als „Online“ markiert ist.
Bei einem Zwei-Knoten-Cluster ist ein Zeuge zwingend erforderlich. Bei größeren Clustern mit gerader Knotenanzahl wird er dringend empfohlen. So konfigurieren Sie einen Cloud-Zeugen:
Stellen Sie sicher, dass Sie über ein aktives Azure-Abonnement, ein universelles Speicherkonto verfügen und Port 443 auf allen Cluster-Knoten geöffnet ist, um die REST-Schnittstelle des Azure-Speicherdiensts zu erreichen.
1. Klicken Sie im Failover-Cluster-Manager mit der rechten Maustaste auf den Cluster > „Weitere Aktionen“ > „Cluster-Quorum-Einstellungen konfigurieren“.
2. Folgen Sie dem Assistenten und wählen Sie „Quorum-Zeuge auswählen“.
3. Im Fenster „Quorum-Zeuge auswählen“ empfehlen wir die Option „Einen Cloud-Zeugen konfigurieren“.
4. Geben Sie Ihren Azure-Speicherkontonamen und den Zugriffsschlüssel ein. Der Assistent erstellt automatisch einen Container namens „msft-cloud-witness“, um die für die Abstimmung benötigte Blob-Datei abzulegen. (Hinweis: Windows Server 2025 unterstützt zudem verwaltete Identitäten, sodass keine Zugriffsschlüssel verwaltet werden müssen.)
CAU ermöglicht das Einspielen von Windows-Updates auf Cluster-Knoten ohne Ausfallzeiten für die Clusterrollen. Es entlädt automatisch die Rollen eines Knotens, installiert die Aktualisierungen, startet den Knoten neu, schaltet ihn wieder online und fährt mit dem nächsten Knoten fort.
1. Wählen Sie im Failover-Cluster-Manager Ihren Cluster in der Konsolenstruktur aus. Klicken Sie im Aktionsbereich oder auf der Hauptseite auf „Clusterbewusstes Update“.
2. Klicken Sie im Fenster „Clusterbewusstes Update“ auf „Optionen für das selbstständige Cluster-Update konfigurieren“.
3. Aktivieren Sie auf der Seite „Clusterrolle hinzufügen“ das Kontrollkästchen „CAU-Clusterrolle hinzufügen mit aktiviertem Modus für selbstständige Aktualisierungen“. Wenn Sie ein vorbereitetes Computerobjekt in Active Directory für diese Rolle besitzen, aktivieren Sie zudem „Ich habe ein vorbereitetes Computerobjekt für die CAU-Clusterrolle“ und geben Sie den Objektnamen an.
4. Konfigurieren Sie anschließend die Update-Quelle und den Zeitplan:
5. Bei Bedarf klicken Sie auf „Erweiterte Optionen“:
Nach der Konfiguration klicken Sie auf „Weiter“ und anschließend auf „Übernehmen“, um den Assistenten abzuschließen.
Failback bezeichnet die automatische Rückverschiebung einer Clusterrolle auf ihren bevorzugten Besitzer, nachdem dieser Knoten nach einem Ausfall wiederhergestellt wurde. In vielen Produktivumgebungen wird automatisches Failback nicht empfohlen. Fällt ein Knoten um 2 Uhr nachts aus und wird um 10 Uhr wiederhergestellt, kann ein sofortiges automatisches Failback eine zweite kurze Unterbrechung zur Hauptnutzungszeit der Benutzer verursachen.
So konfigurieren Sie die Rolle für manuelles oder zeitgesteuertes Failback:
1. Erweitern Sie im Failover-Cluster-Manager Ihren Cluster in der Konsolenstruktur und klicken Sie im linken Bereich auf „Rollen“.
2. Klicken Sie mit der rechten Maustaste auf die Clusterrolle (z. B. eine virtuelle Maschine, eine SQL Server-Instanz oder eine Dateiserver-Rolle) und wählen Sie „Eigenschaften“ aus.
3. Auf der Registerkarte „Allgemein“ wählen Sie unter „Bevorzugte Besitzer“ einen oder mehrere Knoten in der gewünschten Prioritätsreihenfolge aus.
4. Wechseln Sie zur Registerkarte „Failover“. Unter „Failback“ wählen Sie eine der folgenden Optionen:
5. Klicken Sie auf „OK“, um die Einstellungen zu übernehmen.
Sie können bevorzugte Besitzer und Failback-Richtlinien auch per PowerShell-Cmdlets aus dem Modul FailoverClusters konfigurieren:
# Anzeigen der aktuellen bevorzugten Besitzer einer Rolle
Get-ClusterOwnerNode -Cluster MyCluster -Group "SQL Server (MSSQLSERVER)"
# Festlegen bevorzugter Besitzer (sortiert nach Priorität)
Set-ClusterOwnerNode -Cluster MyCluster -Group "SQL Server (MSSQLSERVER)" -Owners Node1, Node2
# Konfigurieren des Failback-Verhaltens
# Parameter: -FailbackType Immediate | Prevent | Policy; -FailbackWindowStart/End bei Policy
Set-ClusterGroup -Cluster MyCluster -Name "SQL Server (MSSQLSERVER)" -FailbackType Prevent
# Alternativ: Failback nur innerhalb eines bestimmten Zeitfensters zulassen
Set-ClusterGroup -Cluster MyCluster -Name "SQL Server (MSSQLSERVER)" `
-FailbackType Policy `
-FailbackWindowStart 1 `
-FailbackWindowEnd 4
Wichtige Parameter:
Auch gut konzipierte Cluster können durch Versäumnisse bei der Einrichtung ausfallen. Basierend auf realen Ausfallfällen sind dies die häufigsten Ursachen.
Das Problem: Cluster-Kommunikationsdatenverkehr konkurriert mit Anwendungsverkehr auf derselben Netzwerkkarte, was zu Latenzspitzen oder Paketverlusten führt. Falsche DNS-Einstellungen oder Firewall-Regeln blockieren den UDP-Port 3343 (Kommunikationsport des Clusterdiensts).
Die Lösung: Nutzen Sie eine dedizierte Netzwerkschnittstelle (oder ein Netzwerkteam) für die Cluster-Kommunikation, getrennt vom clientseitigen Zugriffsverkehr. Überprüfen Sie die DNS-Auflösung aller Cluster-Namen auf allen Knoten. Stellen Sie sicher, dass Firewall-Regeln UDP-Port 3343 für die Cluster-Kommunikation zulassen. Überwachen Sie Paketverluste mit dem Leistungsmonitor. Netzwerkinstabilitäten sind die Hauptursache für unnötige Failovers und schlimmstenfalls Situationen, in denen ein erforderliches Failover nicht ausgeführt werden kann.
Das Problem: Ein Zwei-Knoten-Cluster ohne ordnungsgemäß konfigurierten Zeugen. Eine einfache Netzwerkunterbrechung führt dazu, dass keiner der Knoten das Quorum erreichen kann – es kommt zu einem vollständigen Dienstausfall, obwohl beide Server technisch einwandfrei laufen.
Die Lösung: Konfigurieren Sie stets einen Zeugen bei Clustern mit gerader Knotenanzahl. Stellen Sie sicher, dass die Zeugenressource (Datenträger, Dateifreigabe oder Azure-Blob) von allen Knoten aus erreichbar ist. Beachten Sie, dass das standardmäßig aktivierte Dynamische Quorum Stimmen automatisch anpasst, aber eine korrekte Basis-Quorum-Konfiguration als Voraussetzung benötigt.
Das Problem: Abweichende Laufwerksbuchstaben oder Einhängepunkte auf den Knoten. Bei replikationsbasierten Clustern wurde die Volumes vor dem Produktivstart nicht vollständig synchronisiert. Unzureichende Bandbreite für den Speicherreplikationsverkehr.
Die Lösung: Überprüfen Sie die Einheitlichkeit von Laufwerksbuchstaben und Einhängepunkten auf allen lokalen Knotenfestplatten. Bei gemeinsam genutztem Speicher testen Sie vor der Clustererstellung, ob alle Knoten auf alle LUNs zugreifen können. Bei Storage Spaces Direct (S2D) sicherstellen, dass alle Festplatten die Hardwareanforderungen erfüllen und ordnungsgemäß initialisiert wurden.
Diagnosetools
Nutzen Sie bei der Fehleranalyse diese Werkzeuge:
Trotz seiner Stärken ist Windows Server Failover Clustering keine universelle Lösung. Es erfordert umfangreiches Fachwissen für die korrekte Einrichtung, hängt stark von gemeinsam genutztem Speicher ab und kann Hochverfügbarkeit nicht auf Nicht-Windows-Systeme ausweiten.
Zudem ist der native Failover-Mechanismus speicherzentriert und nicht anwendungsorientiert. Fehlererkennung und Umschaltung können viel Zeit in Anspruch nehmen.
Hier kommt i2Availability ins Spiel. Die von Info2soft entwickelte Plattform i2Availability ist eine Drittanbieter-Lösung für Hochverfügbarkeit und Disaster Recovery, die Echtzeit-Replikation auf Byte-Ebene mit anwendungsbewusster Gesundheitsüberwachung kombiniert. Sie schützt kritische Anwendungen unter Windows, Linux und heterogenen Virtualisierungsplattformen.
Diese Vorteile von i2Availability beseitigen direkt die Schwächen, die WSFC allein nicht vollständig lösen kann:
Sehen Sie sich das Demovideo an, um die praktische Einrichtung robuster Hochverfügbarkeit mit i2Availability zu sehen:
Klicken Sie auf den Button unten, um eine kostenlose 60-Tage-Testversion anzufragen:
Failover-Clustering unter Windows Server bleibt eine grundlegende Hochverfügbarkeits-Technologie für Microsoft-Umgebungen. In dieser Anleitung wurden alle Schritte zur Einrichtung eines Failover-Clusters unter Windows Server detailliert erläutert.
Zusätzlich bietet i2Availability von Info2soft eine leistungsstarke Alternative für Unternehmen, die eine flexiblere, anwendungsorientierte und plattformübergreifende Hochverfügbarkeitslösung benötigen. Mit integrierter Echtzeit-Replikation, subsekunden-schnellem Failover und zentralisierter Verwaltung löst es die Komplexität, Speicherabhängigkeit und Plattformbeschränkungen, die häufig bei nativem WSFC auftreten.
