Hochverfuegbarkeit und Cluster fuer virtuelle Umgebungen

Warum Hochverfuegbarkeit mehr ist als “zwei Server hinstellen”

Die Vorstellung ist verlockend: zwei Hosts, ein gemeinsamer Storage, fertig ist der Cluster. In der Praxis scheitert Hochverfuegbarkeit (HA) in KMU-Umgebungen selten an der Grundinstallation, sondern an drei unterschaetzten Themen: Quorum-Logik, die im Ernstfall genau das Gegenteil von dem tut, was man erwartet; Shared Storage, der selbst zum Single Point of Failure wird; und Failover-Prozesse, die seit der Installation vor drei Jahren nie getestet wurden. Dieser Artikel geht auf Expertenniveau durch die Architektur der drei gaengigen Cluster-Plattformen in Schweizer KMU-Umgebungen: Windows Failover Cluster (Hyper-V), VMware vSphere HA/DRS und Proxmox VE HA.

Quorum: das Fundament, das niemand sieht, bis es fehlt

Ein Cluster besteht aus mehreren Knoten, die sich gegenseitig per Heartbeat ueberwachen. Faellt die Netzwerkverbindung zwischen zwei Standorten aus, sehen beide Haelften den jeweils anderen Teil als “tot” an. Ohne Schutzmechanismus wuerden beide Haelften versuchen, dieselben VMs zu starten und auf denselben Storage zu schreiben. Das Ergebnis heisst Split-Brain: korrupte Datenbanken, doppelt vergebene IP-Adressen, im schlimmsten Fall ein zerstoertes Dateisystem.

Die Loesung ist in allen drei Plattformen strukturell identisch: Mehrheitsentscheidung durch Quorum (lateinisch “von denen”). Ein Cluster darf nur dann Ressourcen online halten, wenn er die Mehrheit der Stimmen (Votes) hat.

Windows Failover Cluster: Node Majority und Witness

Bei Windows Server Failover Clustering (WSFC) hat jeder Knoten standardmaessig eine Stimme. Bei einer geraden Anzahl Knoten (z. B. 2 oder 4) braucht es einen zusaetzlichen Stimmentraeger, den Quorum-Witness, damit die Gesamtzahl der Stimmen ungerade ist und ein eindeutiges Mehrheitsergebnis moeglich bleibt. Es gibt drei Witness-Typen:

Zusaetzlich gibt es Dynamic Quorum und Dynamic Witness: Faellt ein Knoten geordnet aus, entzieht ihm der Cluster automatisch die Stimme, sodass die Gesamtzahl der Stimmen sinkt und die verbleibenden Knoten weiterhin eine Mehrheit bilden koennen — bis hinunter zu einem einzigen ueberlebenden Knoten. Der Witness selbst bekommt dynamisch nur dann eine Stimme, wenn die Zahl der Knoten sonst gerade waere.

# Aktuellen Quorum-Modus und Witness-Ressource anzeigen
Get-ClusterQuorum -Cluster PRODCLUSTER01

# Cloud Witness konfigurieren (empfohlen ab Server 2016)
Set-ClusterQuorum -Cluster PRODCLUSTER01 -CloudWitness `
  -AccountName "stprodclusterwitness" `
  -AccessKey "<Storage-Account-Key>" `
  -Endpoint "core.windows.net"

# Node-Gewichtung pruefen (z.B. Stimmrecht einem DR-Standort-Knoten entziehen)
(Get-ClusterNode -Cluster PRODCLUSTER01).NodeWeight
Get-ClusterNode -Name "DR-Node01" | Set-ClusterNode -NodeWeight 0

vSphere HA: Primary/Secondary-Modell und Netzwerk-Heartbeat

VMware vSphere HA arbeitet fundamental anders als WSFC: Es gibt kein klassisches Quorum-Voting im gleichen Sinn, sondern einen vom vCenter gewaehlten Master-Host pro Cluster, der die Herzschlaege der uebrigen Hosts ueber das Management-Netzwerk und zusaetzlich ueber Heartbeat-Datastores (Shared Storage) ueberwacht. Faellt die Netzwerkverbindung zu einem Host aus, aber der Host antwortet noch auf dem Datastore-Heartbeat, erkennt vSphere HA korrekt “Host isoliert, aber nicht tot” und verhindert so einen ungewollten Doppelstart der VMs (das Aequivalent zum Split-Brain-Schutz). Empfohlen sind mindestens zwei Heartbeat-Datastores, idealerweise auf unterschiedlichen Storage-Arrays.

DRS (Distributed Resource Scheduler) ist kein HA-Feature im engeren Sinn, sondern Lastverteilung: DRS beobachtet CPU-/RAM-Auslastung aller Hosts und verschiebt VMs per vMotion automatisch, um die Last auszugleichen. In Kombination mit HA sorgt DRS zusaetzlich dafuer, dass nach einem Failover-Ereignis die neu gestarteten VMs sinnvoll auf die verbliebenen Hosts verteilt werden, statt alle auf einem einzigen Host zu landen.

# ESXi: HA-Status und Heartbeat-Datastores pruefen (via esxcli / PowerCLI)
Get-Cluster "Prod-Cluster" | Get-View | Select Name, @{N="HAEnabled";E={$_.Configuration.DasConfig.Enabled}}

# Admission Control Policy anzeigen (wie viel Host-Ausfall wird toleriert)
(Get-Cluster "Prod-Cluster").ExtensionData.Configuration.DasConfig.AdmissionControlPolicy

Proxmox VE HA: Corosync-Quorum und Fencing per Watchdog

Proxmox nutzt fuer das Cluster-Management Corosync, das strikt nach Mehrheitsprinzip funktioniert: Jeder Node hat eine Stimme, und der Cluster braucht floor(n/2) + 1 Stimmen, um quorate (handlungsfaehig) zu sein. Bei geraden Knotenzahlen — vor allem beim in KMU sehr verbreiteten 2-Knoten-Cluster — entsteht dasselbe Problem wie bei WSFC: Faellt ein Knoten aus, hat der verbleibende Knoten nur 1 von 2 Stimmen, also keine Mehrheit, und der HA-Stack fenced sich selbst weg, statt VMs zu retten.

Die Loesung ist ein QDevice (Corosync External Vote): ein leichtgewichtiger Dienst (corosync-qnetd) auf einem dritten, unabhaengigen Host (z. B. einem Raspberry Pi oder einer kleinen VM ausserhalb des Cluster-Blast-Radius), der eine zusaetzliche Stimme beisteuert.

# QDevice-Paket auf dem dritten, externen Host installieren
apt install corosync-qnetd

# Auf einem Proxmox-Node das QDevice dem Cluster hinzufuegen
pvecm qdevice setup 10.10.1.250 -f

# Quorum-Status pruefen
pvecm status

# Watchdog-basiertes Fencing ist bei Proxmox HA standardmaessig aktiv (softdog)
# Pruefen, ob das Watchdog-Modul geladen ist:
lsmod | grep softdog

Proxmox setzt fuer die Fencing-Sicherheit auf einen Watchdog-Timer: Verliert ein Node den Quorum-Kontakt, muss er sich innerhalb einer festen Zeitspanne (Standard: ca. 60 Sekunden) selbst per Watchdog neu starten (Reset), bevor die anderen Knoten die betroffenen VMs anderswo starten. Das ist ein zentraler Unterschied zu WSFC/vSphere: Proxmox verlaesst sich auf einen garantierten Selbst-Reset statt auf aktives Storage-Fencing von aussen.

Quorum-Entscheidungsbaum bei Netzwerk-Split

Netzwerkverbindung zwischen Cluster-Standorten faellt aus
│
├─ Hat meine Cluster-Haelfte die Mehrheit der Stimmen (> 50%)?
│   ├─ JA  → Ressourcen bleiben online / werden gestartet
│   └─ NEIN → Ressourcen gehen offline (WSFC) / Node fenced sich selbst (Proxmox)
│             oder Host gilt als isoliert, VMs bleiben laufen falls Storage-Heartbeat noch da (vSphere)
│
├─ Genau 50/50 Stimmenteilung (z.B. 2 von 4 Knoten je Standort)?
│   └─ Witness/QDevice/Tie-Breaker entscheidet, welche Seite die Mehrheit erhaelt
│
└─ Kein Witness konfiguriert und Stimmen exakt geteilt?
    └─ Cluster haelt beide Seiten fuer nicht-quorate → kompletter Ausfall (Worst Case)

Shared Storage: die Grundlage, die den Failover ueberhaupt erst ermoeglicht

Damit eine VM nach einem Host-Ausfall auf einem anderen Knoten starten kann, muessen die virtuellen Festplatten fuer alle Cluster-Knoten gleichzeitig sichtbar sein. Dafuer gibt es grundsaetzlich zwei Architekturansaetze: klassisches Shared Storage (SAN/NAS) oder Software-Defined-Storage/HCI (Hyperconverged Infrastructure), bei dem die Knoten ihre lokalen Platten zu einem verteilten Pool zusammenschliessen.

Cluster Shared Volumes (CSV) bei Hyper-V

Ein haeufiger Anfaengerfehler bei Hyper-V-Clustern: ein LUN pro VM anzulegen. Besser ist der Einsatz von Cluster Shared Volumes (CSV), bei denen mehrere Knoten gleichzeitig lesend und schreibend auf dasselbe NTFS-/ReFS-Volume zugreifen koennen, waehrend Hyper-V im Hintergrund pro Datei die Ownership koordiniert. Das ermoeglicht Live Migration ohne LUN-Umhaengen und deutlich einfacheres Kapazitaetsmanagement.

# Vorhandenes Cluster-Laufwerk in ein CSV umwandeln
Add-ClusterSharedVolume -Cluster PRODCLUSTER01 -Name "Cluster Disk 3"

# CSV-Status und Owner-Node pruefen
Get-ClusterSharedVolume -Cluster PRODCLUSTER01 | Format-Table Name, State, OwnerNode

iSCSI-Grundkonfiguration als Beispiel fuer die Storage-Anbindung

# Windows Server: iSCSI-Initiator mit Ziel-Portal verbinden
New-IscsiTargetPortal -TargetPortalAddress 10.10.5.10

Connect-IscsiTarget -NodeAddress "iqn.2005-10.com.storage:target01" `
  -IsPersistent $true -IsMultipathEnabled $true

# MPIO-Richtlinie fuer Round Robin (Lastverteilung ueber mehrere Pfade)
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

RTO und RPO: HA-Design beginnt mit Zielwerten, nicht mit Technik

Bevor du dich fuer eine Cluster-Architektur entscheidest, muss klar sein, welche Ausfallzeit (Recovery Time Objective, RTO) und welcher Datenverlust (Recovery Point Objective, RPO) fuer den jeweiligen Dienst akzeptabel sind. Ein Cluster fuer ein internes Wiki braucht andere Zielwerte als das ERP-System der Buchhaltung.

Wichtig: Ein lokaler Failover-Cluster schuetzt nur vor Hardware-Ausfall innerhalb des Rechenzentrums. Faellt der ganze Serverraum aus (Wasserschaden, Stromausfall, Brand), hilft nur ein zweiter Standort mit asynchroner Replikation (Stretched Cluster, Hyper-V Replica, VMware SRM/vSphere Replication) — das ist RPO-technisch eine andere Liga als synchrones Shared Storage im selben Rack.

Wartung ohne Downtime: Live Migration im Detail

Der grosse betriebliche Vorteil eines Clusters ist nicht nur der ungeplante Failover, sondern die Moeglichkeit, Wartungsarbeiten (Patchday, Firmware-Update, RAM-Tausch) ohne Downtime der VMs durchzufuehren.

• Hyper-V Live Migration: Verschiebt eine laufende VM zwischen Cluster-Knoten. Der Arbeitsspeicherinhalt wird iterativ ueber das Netzwerk kopiert, waehrend die VM weiterlaeuft; erst im letzten Sekundenbruchteil wird kurz pausiert und der Besitz umgeschaltet. Voraussetzung: gemeinsames CSV oder SMB-Storage, identische oder kompatible Prozessorgeneration (bzw. Processor Compatibility Mode aktiv).
• vSphere vMotion: Technisch das Vorbild fuer Live Migration, funktioniert nach demselben Prinzip. Mit Storage vMotion laesst sich zusaetzlich die virtuelle Festplatte selbst bei laufendem Betrieb auf ein anderes Datastore verschieben — praktisch bei Storage-Wartung oder Kapazitaetsproblemen.
• Proxmox Live Migration: Bei Shared Storage (Ceph/NFS/iSCSI) laeuft die Migration analog; bei lokalem Storage unterstuetzt Proxmox seit einigen Versionen auch Live Migration mit Storage-Migration in einem Schritt, allerdings mit laengerer Kopierzeit.

# Hyper-V: gezielte Live Migration eines Knotens in den Wartungsmodus versetzen
# (verschiebt automatisch alle VMs auf andere Knoten)
Suspend-ClusterNode -Name "HV-Node02" -Drain

# Nach Wartung: Knoten wieder aktivieren, VMs optional zurueckverschieben
Resume-ClusterNode -Name "HV-Node02" -Failback

# Proxmox: VM live auf anderen Node migrieren
qm migrate 105 pve-node02 --online

# Proxmox: Node in den Wartungsmodus (Maintenance) versetzen -> HA verschiebt VMs automatisch
ha-manager crm-command node-maintenance enable pve-node01

Testing von Failover: der am meisten uebersprungene Schritt

Die unbequeme Wahrheit: Die meisten KMU-Cluster wurden nach der Installation nie mit einem echten Node-Ausfall getestet. Das faellt genau dann auf, wenn es zu spaet ist. Ein strukturierter Failover-Test gehoert in jeden Wartungsplan.

Schritt-fuer-Schritt-Ablauf fuer einen kontrollierten Failover-Test

1. Wartungsfenster ankuendigen und Stakeholder informieren, auch wenn der Test theoretisch unterbrechungsfrei sein sollte — im Fehlerfall soll niemand ueberrascht sein.
2. Aktuellen Zustand dokumentieren: Welche VM laeuft auf welchem Knoten, Storage-Pfad-Status, Cluster-Log-Baseline sichern.
3. Kontrollierten Failover ausloesen (nicht per Stromkabel ziehen, sondern per Software-Kommando, das den realen Node-Ausfall simuliert):
   • Hyper-V: Stop-ClusterNode gefolgt von einem harten Stopp des Dienstes, oder in Testumgebungen tatsaechlich Netzwerkkabel/vNIC deaktivieren.
   • vSphere: Host in “Isolation Response testen” versetzen oder in einer Testumgebung das Management-Netzwerk trennen.
   • Proxmox: pvecm expected 1 NICHT in Produktion nutzen; stattdessen in einer Staging-Umgebung testen oder den Node kontrolliert per Watchdog-Trigger zuruecksetzen.
4. Zeitmessung: Stoppuhr ab dem simulierten Ausfall bis zum Zeitpunkt, an dem die VM wieder erreichbar ist (Ping/HTTP-Check). Das ist deine reale RTO, nicht die Marketing-Zahl aus dem Datenblatt.
5. Datenintegritaet pruefen: Bei Datenbank-VMs Transaktionslogs und letzte Commits verifizieren — das ist deine reale RPO.
6. Failback durchfuehren und pruefen, ob die VM sauber auf den urspruenglichen (reparierten) Knoten zurueckwandert.
7. Ergebnisse dokumentieren in der IT-Dokumentation, inklusive gemessener RTO/RPO im Vergleich zu den Zielwerten.
8. Testintervall festlegen: Mindestens einmal jaehrlich, zusaetzlich nach jedem grossen Firmware-/Hypervisor-Update.

// Beispiel: Cluster-Failover-Ereignisse im Windows-Ereignisprotokoll auswerten (ueber Log Analytics/Sentinel)
Event
| where Source == "Microsoft-Windows-FailoverClustering"
| where EventID in (1135, 1177, 1230)
| project TimeGenerated, Computer, EventID, RenderedDescription
| order by TimeGenerated desc

Entscheidungshilfe: welche Plattform fuer welches KMU-Szenario

Haeufige Fallstricke in der Praxis

• Netzwerk-Redundanz vergessen: Cluster-Heartbeat, Live-Migration-Traffic und Storage-Traffic sollten auf getrennten physischen NICs bzw. VLANs laufen. Ein einzelner Netzwerkport als Single Point of Failure untergraebt die gesamte HA-Investition.
• Antivirus/EDR auf Cluster-Kommunikationsports: Ports wie TCP/UDP 3343 (Cluster-Kommunikation, WSFC) oder 5405 (Corosync, Proxmox) muessen von Sicherheitssoftware ausgenommen werden, sonst entstehen sporadische, schwer reproduzierbare Node-Ausfaelle.
• Asymmetrische Hardware: Unterschiedliche CPU-Generationen zwischen Cluster-Knoten koennen Live Migration verhindern oder erzwingen den langsameren Compatibility Mode fuer alle VMs.
• Quorum-Konfiguration nach Erweiterung nicht angepasst: Wird ein dritter Knoten hinzugefuegt, aber der Cloud Witness/QDevice nicht ueberprueft, kann die Stimmenverteilung unerwartet unguenstig werden.
• Storage-Latenz unterschaetzt: Gerade bei S2D/vSAN/Ceph ist die Netzwerklatenz zwischen den Knoten kritisch — 1GbE reicht fuer produktive HCI-Cluster in der Regel nicht aus.

Weiterlernen

• What is a failover cluster quorum witness in Windows Server? — offizielle Microsoft-Doku zu Quorum-Modi und Witness-Typen
• Proxmox VE High Availability Documentation — offizielle Doku zu HA-Manager, Fencing und QDevice
• VMware vSphere Availability Guide — offizielle Dokumentation zu vSphere HA und DRS
• Understand cluster and pool quorum on Windows Server clusters — Vertiefung Storage Spaces Direct und Quorum
• Thomas-Krenn-Wiki: Proxmox HA Cluster erstellen — praxisnahe deutschsprachige Schritt-fuer-Schritt-Anleitung

Fuer die Grundlagen der einzelnen Virtualisierungsplattformen siehe Hyper-V Grundlagen, VMware ESXi Grundlagen und Proxmox VE Grundlagen. Zum Aufbau eines Windows-Failover-Clusters im Detail lohnt sich zusaetzlich Windows Failover Cluster Grundlagen.

Videos

YouTube

YouTube