Windows Failover Clustering – Hochverfuegbarkeit fuer Fileserver und SQL

Was ein Failover Cluster wirklich loest

Ein Windows Failover Cluster (WSFC, Windows Server Failover Clustering) ist kein Load Balancer und keine Backup-Loesung. Es ist ein Gruppe von Servern (Knoten), die gemeinsam ueberwacht werden und eine Rolle – zum Beispiel einen Fileserver, eine SQL-Instanz oder eine Hyper-V-VM – automatisch von einem ausgefallenen Knoten auf einen gesunden Knoten verschieben. Der Client merkt im Idealfall nichts ausser einer kurzen Unterbrechung.

Das Kernproblem, das ein Cluster loest, ist simpel formuliert: Ein einzelner Server ist ein Single Point of Failure. Faellt das Mainboard aus, geht ein Windows Update schief oder muss die Firmware aktualisiert werden, steht der Dienst still. Ein Cluster verteilt dieses Risiko auf mehrere physische oder virtuelle Maschinen, die sich gegenseitig ueberwachen und im Fehlerfall automatisch uebernehmen.

Wichtig fuer die Erwartungshaltung im KMU: Failover Clustering schuetzt vor Hardware- und Betriebssystemausfaellen, nicht vor Datenverlust durch Ransomware, Fehlbedienung oder einer korrupten Datenbank. Ein Cluster ersetzt kein Backup – die beiden Themen ergaenzen sich, ersetzen sich aber nicht.

Cluster-Grundarchitektur: Knoten, Netzwerke, Ressourcen

Ein WSFC besteht aus mehreren Bausteinen, die zusammenspielen muessen:

• Knoten (Nodes): Physische oder virtuelle Server mit identischer (oder sehr aehnlicher) Konfiguration, Feature “Failover-Clustering” installiert.
• Cluster-Netzwerke: Mindestens ein Client-Netzwerk (fuer den Zugriff der Anwender) und idealerweise ein separates Netzwerk fuer Cluster-internen Heartbeat/Replikationsverkehr. Bei Storage Spaces Direct oder S2D-aehnlichen Szenarien kommt noch ein dediziertes Storage-Netzwerk dazu.
• Cluster-Ressourcen: Das, was tatsaechlich failovern soll – eine IP-Adresse, ein Netzwerkname (Cluster-Name-Objekt, CNO), ein Datentraeger, ein Dienst wie der Dateiserver oder SQL Server.
• Rollen (frueher “Cluster-Gruppen”): Buendel von Ressourcen, die gemeinsam auf denselben Knoten wandern, z.B. IP + Name + Disk + Dateiserver-Dienst als eine Rolle.
• Quorum: Der Mechanismus, der entscheidet, welche Teilmenge des Clusters bei einer Netzwerktrennung (Split-Brain) “das echte” Cluster ist und weiterlaufen darf.

Die Mindestanforderung fuer ein produktives Cluster sind zwei Knoten. In der Praxis empfehle ich fuer KMU-Umgebungen wo moeglich drei Knoten, weil dann ein Node-Majority-Quorum ohne zusaetzliche Witness-Komponente funktioniert und der Cluster einen Knotenausfall verkraftet, waehrend noch Wartungsarbeiten auf einem zweiten Knoten laufen.

Cluster erstellen – Validierung zuerst

Vor jeder Cluster-Erstellung steht die Validierung. Microsoft-Support verlangt bei Produktionsclustern einen bestandenen Validierungsbericht, sonst gilt der Cluster als “nicht unterstuetzt”.

# Cluster-Feature auf allen Knoten installieren
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

# Konfiguration validieren, bevor der Cluster erstellt wird
Test-Cluster -Node srv-file01, srv-file02, srv-file03 -Include "Speicher", "Netzwerk", "Systemkonfiguration"

# Cluster erstellen (Beispiel: 3 Knoten, statische Cluster-IP)
New-Cluster -Name clu-fileserver01 -Node srv-file01, srv-file02, srv-file03 `
  -StaticAddress 10.10.20.50 -NoStorage

Der Parameter -NoStorage verhindert, dass beim Erstellen automatisch alle sichtbaren Datentraeger dem Cluster hinzugefuegt werden – das ist bei mehreren LUNs oft unerwuenscht und du willst Storage kontrolliert per Add-ClusterDisk oder ueber CSV nachziehen.

Quorum: Warum die Mehrheit entscheidet

Das Quorum ist das wichtigste und am meisten missverstandene Konzept im Failover Clustering. Es beantwortet eine einzige Frage: Wenn das Netzwerk zwischen Knoten unterbrochen ist, welche Seite darf weiterlaufen?

Ohne Quorum-Mechanismus koennten beide Haelften eines getrennten Clusters glauben, sie seien die “echte” Instanz, und beide gleichzeitig auf denselben Datentraeger schreiben – das nennt man Split-Brain und es fuehrt zu Datenkorruption. Der Quorum-Mechanismus stellt sicher, dass nur die Seite mit der Mehrheit der Stimmen (Votes) online bleibt; die Minderheit faehrt ihre Rollen automatisch herunter.

Jeder Knoten hat normalerweise eine Stimme. Optional kann ein Witness (Zeuge) eine zusaetzliche Stimme beisteuern, um bei einer geraden Anzahl Knoten Patt-Situationen zu vermeiden.

Die vier Quorum-Modelle im Detail

Seit Windows Server 2012 R2 verwaltet der Cluster die Gewichtung der Stimmen selbst automatisch (Dynamic Quorum) und passt sie bei Knotenausfaellen live an, damit ein Cluster auch mit weniger als der urspruenglichen Mehrheit weiterlaufen kann, wenn das sicher moeglich ist. Trotzdem bleibt die Faustregel bestehen: Immer eine ungerade Anzahl an stimmberechtigten Elementen anstreben.

Cloud Witness einrichten

Der Cloud Witness braucht nur ein Azure-Storage-Konto und legt dort ein kleines Blob als Marker ab. Kein drittes Rechenzentrum, keine zusaetzliche VM notwendig.

# Quorum auf Cloud Witness umstellen
Set-ClusterQuorum -CloudWitness `
  -AccountName "clustatwitnessfabrikag" `
  -AccessKey "<Storage-Account-Access-Key>" `
  -Endpoint "core.windows.net"

Seit Windows Server 2025 unterstuetzt der Cloud Witness zusaetzlich Managed Identities statt eines statischen Access Keys – das reduziert das Risiko, dass ein Schluessel in Skripten oder der Cluster-Datenbank im Klartext landet. Fuer bestehende 2019/2022-Cluster bleibt der Access-Key-Weg der Standard, sollte aber in einem sicheren Secret Store (nicht im Klartext-Skript) verwaltet werden.

# Aktuelle Quorum-Konfiguration und Stimmverteilung pruefen
Get-ClusterQuorum
Get-ClusterNode | Select-Object Name, State, DynamicWeight

Entscheidungshilfe: Welches Quorum-Modell?

1. Habt ihr eine ungerade Anzahl Knoten (3 oder 5) und Shared Storage? -> Node Majority reicht theoretisch, ein zusaetzlicher Disk-Witness schadet aber nicht und wird von Microsoft empfohlen.
2. Habt ihr genau 2 Knoten? -> Zwingend Witness. Wenn Azure-Konnektivitaet vorhanden ist: Cloud Witness. Sonst: File-Share-Witness auf einem dritten, unabhaengigen Server (z.B. einem DC, der nicht Teil des Clusters ist).
3. Multi-Site-Cluster ueber zwei Standorte? -> Cloud Witness bevorzugt, weil kein drittes Rechenzentrum noetig ist und beide Standorte gleichberechtigt bleiben.
4. Kein Internetzugang, keine dritte Site, kein zusaetzliches Storage? -> File-Share-Witness ist die einzige Option, aber dokumentiere das Risiko, dass dieser Server selbst zum kritischen Element wird.

Shared Storage und Cluster Shared Volumes (CSV)

Klassische Failover-Cluster brauchen Shared Storage – also einen Datentraeger, den mehrere Knoten sehen koennen (iSCSI-SAN, Fibre-Channel-SAN oder Storage Spaces Direct). Ohne CSV kann ein Datentraeger im Cluster aber immer nur von einem Knoten gleichzeitig aktiv gemountet sein; beim Failover muss das Volume erst offline und dann auf dem Zielknoten online genommen werden, was Sekunden bis Minuten kostet.

Cluster Shared Volumes (CSV) loesen das: Ein CSV-formatiertes NTFS- oder ReFS-Volume ist gleichzeitig auf allen Knoten als C:\ClusterStorage\VolumeX sichtbar und beschreibbar, koordiniert durch einen Cluster-eigenen Redirected-I/O-Mechanismus. Das ist die Grundlage fuer Hyper-V-Cluster (mehrere VMs auf demselben Volume, auf unterschiedlichen Knoten aktiv) und fuer Scale-Out-File-Server.

# Datentraeger dem Cluster hinzufuegen und als CSV aktivieren
Get-ClusterAvailableDisk | Add-ClusterDisk
Add-ClusterSharedVolume -Name "Datenträger für Cluster 1"

# CSV-Status und zustaendigen "Coordinator Node" pruefen
Get-ClusterSharedVolume | Format-Table Name, State, OwnerNode

Failover-Fileserver vs. Scale-Out-Fileserver (SOFS)

Windows Failover Clustering kennt zwei grundsaetzlich unterschiedliche Fileserver-Architekturen, die oft verwechselt werden:

Die Faustregel: Fuer klassische Benutzer-Dateifreigaben in einem KMU (Projektablagen, Home-Laufwerke) ist der klassische Failover-Fileserver meist die richtige und einfachere Wahl. SOFS lohnt sich vor allem, wenn viele kleine, zufaellige I/O-Operationen gleichzeitig von mehreren Clients kommen – etwa als Storage-Backend fuer Hyper-V-VMs oder SQL-Server-Datenbanken auf SMB-Share. Fuer normale Office-Workloads mit Word/Excel-Dateien bringt SOFS keinen spuerbaren Vorteil, erhoeht aber die Komplexitaet unnoetig.

# Klassische Fileserver-Rolle erstellen
Add-ClusterFileServerRole -Name fs-projekte -Storage "Datenträger für Cluster 1"

# Scale-Out-Fileserver-Rolle erstellen (setzt CSV voraus)
Add-ClusterScaleOutFileServerRole -Name sofs-hypervdata

Cluster Aware Updating (CAU): Patchen ohne Downtime

Ein Cluster nuetzt wenig, wenn jedes Windows-Update-Wochenende manuell koordiniert werden muss. Cluster-Aware Updating (CAU) automatisiert genau das: Es versetzt einen Knoten nach dem anderen in den Wartungsmodus, verschiebt dessen Rollen auf die verbleibenden Knoten, installiert Updates, startet bei Bedarf neu, holt den Knoten zurueck und macht mit dem naechsten weiter – vollstaendig unbeaufsichtigt.

# CAU-Feature auf allen Knoten installieren
Install-WindowsFeature -Name RSAT-Clustering-PowerShell

# Vorabpruefung, ob der Cluster CAU-faehig ist
Test-CauSetup -ClusterName clu-fileserver01

# Self-Updating-Modus aktivieren mit woechentlichem Zeitplan
Add-CauClusterRole -ClusterName clu-fileserver01 -MaxFailedNodes 1 `
  -RequireAllNodesOnline -EnableFirewallRules `
  -StartDate "2026-07-12 22:00:00" -DaysOfWeek 1 -WeeksOfMonth 3 `
  -MaxRetriesPerNode 3

# Manuellen Updating-Run anstossen (Remote-Updating-Modus)
Invoke-CauRun -ClusterName clu-fileserver01 -MaxFailedNodes 1 `
  -RequireAllNodesOnline -Force

CAU kennt zwei Modi: Self-Updating (der Cluster patcht sich selbst nach Zeitplan, Add-CauClusterRole) und Remote-Updating (ein externer Rechner, z.B. via Task Scheduler, stoesst Invoke-CauRun regelmaessig an). Fuer KMU empfehle ich Remote-Updating mit einem Wartungsfenster ausserhalb der Geschaeftszeiten, weil so ein Mensch die Ergebnismail sehen und bei Problemen sofort reagieren kann, statt dass ein Self-Updating-Run unbemerkt fehlschlaegt.

SQL-Server-FCI-Grundlagen

Eine SQL Server Failover Cluster Instance (FCI) ist eine einzelne SQL-Server-Installation, die ueber mehrere WSFC-Knoten verteilt installiert wird, aber nach aussen als eine Instanz mit einem Netzwerknamen und einer IP erscheint. Nur ein Knoten ist zu jeder Zeit aktiv; faellt er aus, startet SQL Server auf einem anderen Knoten neu und uebernimmt denselben Netzwerknamen und dieselben Datenbankdateien vom Shared Storage.

Der entscheidende Architekturunterschied zu Always On Availability Groups (AG):

Fuer viele Schweizer KMU ist FCI die wirtschaftlichere Wahl, weil es mit der Standard Edition funktioniert und keine zusaetzlichen Datenbank-Repliken mit eigenem Storage braucht – man bezahlt “nur” die WSFC-Infrastruktur (Shared Storage), nicht zusaetzliche SQL-Lizenzkosten fuer eine Enterprise-AG-Loesung. Der Kompromiss: FCI schuetzt nicht vor Storage-Ausfall, weil alle Knoten auf denselben Datentraeger zugreifen.

-- Nach der FCI-Installation: Instanzname und aktiven Knoten pruefen
SELECT SERVERPROPERTY('ComputerNamePhysicalNetBIOS') AS AktuellerKnoten,
       SERVERPROPERTY('ServerName') AS InstanzName,
       SERVERPROPERTY('IsClustered') AS IstGeclustert;

# FCI-Rolle im Failover Cluster Manager pruefen (aus Windows-Sicht)
Get-ClusterGroup | Where-Object {$_.GroupType -eq "SqlServer"}

# Manuellen Failover einer SQL-FCI-Rolle testen (ausserhalb Geschaeftszeiten!)
Move-ClusterGroup -Name "SQL Server (MSSQLSERVER)" -Node srv-sql02

Netzwerk-Design: Heartbeat und Client-Traffic trennen

Ein haeufiger Fehler in KMU-Umgebungen: Cluster-Heartbeat und Client-Zugriff laufen ueber dieselbe, ueberlastete NIC. Best Practice ist mindestens eine physische Trennung:

• Client-Netzwerk: Fuer SMB-/SQL-Traffic der Anwender, mit Routing ins Produktivnetz.
• Cluster-/Heartbeat-Netzwerk: Isoliertes VLAN oder eigene NIC ausschliesslich fuer Cluster-internen Zustandsabgleich, idealerweise ohne Default Gateway, damit der Cluster es nicht faelschlicherweise als Client-Netzwerk priorisiert.
• Storage-Netzwerk (bei iSCSI/S2D): Eigenes, moeglichst redundantes Netz mit Jumbo Frames, getrennt von allem anderen Traffic.

# Cluster-Netzwerke auflisten und Rolle pruefen (1 = nur Cluster, 3 = Cluster + Client)
Get-ClusterNetwork | Format-Table Name, Role, Address

# Ein Netzwerk explizit nur fuer internen Cluster-Traffic konfigurieren
(Get-ClusterNetwork -Name "Cluster-Heartbeat").Role = 1

Sicherheit und Haertung

Ein Cluster-Name-Objekt (CNO) ist ein eigenes Computerkonto in Active Directory und braucht die Berechtigung, weitere virtuelle Computerobjekte (VCOs) fuer Rollen anzulegen. In gehaerteten AD-Umgebungen mit restriktiven OU-Berechtigungen ist das ein haeufiger Stolperstein bei der Ersteinrichtung – das CNO-Konto muss “Computerobjekte erstellen” auf der Ziel-OU delegiert bekommen, sonst schlaegt New-Cluster an dieser Stelle fehl.

Weitere Haertungspunkte fuer produktive Cluster:

• Cluster-Kommunikation verschluesseln: Die Cluster-Eigenschaft SecurityLevel kennt drei Stufen – 1 (ClearText), 2 (Signed, Standardeinstellung) und 3 (Encrypted). Fuer Knoten in unterschiedlichen Racks oder Standorten empfiehlt sich (Get-Cluster).SecurityLevel = 3, allerdings auf Kosten von SMB Direct/RDMA, das bei Verschluesselung nicht mehr genutzt wird.
• Lokale Administratorgruppe auf allen Knoten synchron halten (idealerweise per LAPS/GPO, nicht manuell).
• Kein Domaenencontroller als Cluster-Knoten und kein Cluster-Knoten als DC – das ist offiziell nicht unterstuetzt.
• Firewallregeln fuer Cluster-Kommunikation (Failover Cluster Manager-Regelsatz) nicht pauschal deaktivieren, sondern gezielt aktivieren.

Typische Fallstricke im Schweizer KMU-Alltag

• Asymmetrisches Storage: Ein Knoten sieht eine LUN, ein anderer nicht (vergessenes Zoning/Masking auf dem SAN). Der Cluster laesst sich zwar erstellen, failt aber bei genau diesem Datentraeger nie erfolgreich auf den “blinden” Knoten.
• Unterschiedliche Windows-Update-Staende: Wird CAU nicht genutzt und Knoten manuell gepatcht, driften Patch-Level auseinander. Ein Failover auf einen aelteren Patch-Stand kann zu unerwartetem Verhalten fuehren, besonders bei SQL-FCI.
• Zwei-Knoten-Cluster ohne Witness “weil es ja lief”: Funktioniert im Normalbetrieb – bis genau der eine Knoten ausfaellt, der zufaellig die Quorum-Mehrheit haelt, und der gesamte Cluster geht offline, obwohl der zweite Knoten technisch gesund waere.
• Storage-Latenz unterschaetzt: Ein SOFS auf einem ueberlasteten, günstigen NAS-Backend bringt keine Performance-Vorteile – die Flaschenhals-Analyse gehoert vor die Architekturentscheidung, nicht danach.
• Vergessene DNS-Eintraege fuer den Cluster-Namen: Der Cluster-Netzwerkname registriert sich normalerweise selbst per dynamischem DNS-Update; in gehaerteten Zonen mit deaktivierten dynamischen Updates muss der Eintrag manuell gepflegt werden, sonst erreichen Clients die Rolle nach einem Namenswechsel nicht mehr.

Weiterlernen

• Deploy a quorum witness (Microsoft Learn)
• What is a failover cluster quorum witness? (Microsoft Learn)
• Uebersicht: Freigegebene Clustervolumes/CSV (Microsoft Learn, deutsch)
• Cluster-Aware Updating overview (Microsoft Learn)
• Scale-Out File Server for application data overview (Microsoft Learn)
• Always On Failover Cluster Instances (Microsoft Learn)

Verwandte Seiten:

• Windows Server Dateifreigaben – Grundlagen zu SMB-Freigaben, auf denen ein Failover-Fileserver aufbaut
• SQL Server Hochverfuegbarkeit im KMU – FCI und Always On im direkten Vergleich vertieft
• SAN-Grundlagen: iSCSI und Fibre Channel – das Shared Storage hinter jedem klassischen Cluster
• Virtualisierung und Hochverfuegbarkeit – Hyper-V-Cluster auf CSV im Detail
• SQL Server Grundlagen fuer den Support – Basiswissen, falls SQL-FCI-Themen neu sind

Videos

YouTube

YouTube