# Windows Failover Clustering: Die Architektur der Ausfallsicherheit

TL;DR / Management Summary Ein Windows Failover Cluster (WFC) ist eine Gruppe von Servern (Knoten), die zusammenarbeiten, um die Verfügbarkeit von Anwendungen und Diensten zu erhöhen. Stirbt ein Knoten, übernimmt ein anderer automatisch dessen Aufgaben. Für Senior Admins ist der Cluster die Basis für HCI (Storage Spaces Direct), SQL-Cluster und hochverfügbare Hyper-V Umgebungen. Der Erfolg steht und fällt mit einem stabilen Netzwerk-Design und der korrekten Wahl des Quorum-Modells.

# 1. Einführung & Konzepte

Kein Single Point of Failure (SPOF).

Ein Cluster ist mehr als die Summe seiner Teile. Er benötigt:

  1. Geteiltes Verständnis: Wer ist online? (Heartbeat).
  2. Geteilte Ressourcen: Wer darf auf die Disk schreiben? (SCSI Reservations oder CSV).
  3. Mehrheitsentscheidung: Wer darf den Cluster am Leben erhalten? (Quorum).

# 2. Einrichtung in der Praxis

Das Fundament bauen.

# Schritt 1: Feature installieren

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

# Schritt 2: Validierung (Kritisch!)

Führen Sie niemals einen Cluster ohne vollständigen Validierungs-Report in Produktion. Microsoft gibt nur Support für validierte Konfigurationen.

Test-Cluster -Node "KNOTEN01", "KNOTEN02"

# 3. Deep Dive: Quorum-Modelle

Die Mathematik des Überlebens.

Das Quorum stellt sicher, dass bei einem Netzwerksplit (“Split Brain”) nur eine Seite des Clusters weiterarbeitet.

# 4. Day-2 Operations: Cluster-Wartung

Patchen ohne Angst.

# Cluster-Aware Updating (CAU)

Automatisieren Sie den Patch-Vorgang:

# Prüft auf verfügbare Updates für den Cluster
Invoke-CauScan -ClusterName "PROD-CLUSTER"

# 5. Troubleshooting & “War Stories”

Wenn der Cluster ‘auseinanderfällt’.

# Top 3 Fehlerbilder

  1. Symptom: Der gesamte Cluster fährt herunter, obwohl nur ein Knoten ausgefallen ist.

    • Ursache: Quorum-Loss. In einem 2-Knoten-Cluster ohne Witness führt der Ausfall eines Knotens zum Verlust der Mehrheit (50% ist keine Mehrheit!).
    • Lösung: Immer einen Witness (FSW oder Cloud) konfigurieren.

  2. Symptom: CSV (Cluster Shared Volume) ist im Status Redirected Access.

    • Ursache: Ein Knoten hat den physischen Pfad zum SAN verloren. Der I/O läuft nun über das LAN eines anderen Knotens.
    • Lösung: MPIO (Artikel 503) und Hardware-Verkabelung prüfen.

  3. Symptom: Fehler “The computer object for the cluster could not be updated in AD”.

    • Lösung: Dem Computer-Objekt des Clusters (CNO) Berechtigungen im Active Directory geben.

# “War Story”: Der schweigende Heartbeat

Ein Cluster in einem Proxmox-Umfeld verlor ständig Knoten (Status: Isolated). Die Entdeckung: Der Admin hatte den Cluster-Traffic (UDP 3343) über die gleiche virtuelle Bridge wie den Backup-Traffic geschickt. Wenn das Backup nachts die Leitung sättigte, kamen die Heartbeats zu spät an. Der Cluster dachte, die anderen Knoten seien tot und löste einen Failover-Sturm aus. Lehre: Heartbeat-Netzwerke benötigen absolute Priorität oder physikalische Trennung!

# 6. Monitoring & Reporting

Dashboard der Uptime.

# Wichtige KPIs

# 7. Fazit & Empfehlung

Ein Failover-Cluster ist komplex, aber unschlagbar für Mission-Critical Workloads.

# Anhang: Cheatsheet

Aufgabe Befehl
Cluster Manager cluadmin.msc
Ressourcen prüfen Get-ClusterResource
Quorum Status Get-ClusterQuorum
Log-File erstellen Get-ClusterLog -Destination C:\Temp

# Referenzen