Proxmox High Availability (HA) Architektur-Deep Dive
Downtime ist in modernen Infrastrukturen keine Option. In diesem Deep Dive analysieren wir die Mechanik des Proxmox HA-Managers, verstehen das lebenswichtige Konzept des Fencings (STONITH) und zeigen, wie Sie eine ausfallsichere Umgebung entwerfen, die den Verlust eines kompletten Hosts ohne manuellen Eingriff übersteht.
# Proxmox HA Architektur: Hochverfügbarkeit jenseits von Marketing-Slides
TL;DR / Management Summary High Availability (HA) in Proxmox VE ist kein “Magic Button”, sondern ein Zusammenspiel aus Quorum, Shared Storage und einem gnadenlosen Fencing-Mechanismus. Der HA-Manager sorgt dafür, dass VMs bei einem Host-Ausfall auf gesunden Knoten neu gestartet werden. Ein Senior Admin weiß: Ohne funktionierendes Fencing (Watchdog) riskiert man bei einem Failover massiven Datenverlust durch Split-Brain-Szenarien. Dieser Artikel erklärt, wie Sie HA produktionsreif konfigurieren.
# 1. Die drei Säulen der Proxmox HA
HA basiert in Proxmox auf drei technologischen Fundamenten, die perfekt ineinandergreifen müssen.
- Quorum (Mehrheit): Ein Cluster muss immer eine Mehrheit seiner Knoten (oder Stimmen) online haben, um Entscheidungen zu treffen. Ohne Quorum stoppt der HA-Manager sofort alle Aktivitäten zum Schutz der Daten.
- Shared Storage: Damit eine VM auf einem anderen Knoten starten kann, müssen deren Daten (Disk-Images) für alle Knoten gleichzeitig erreichbar sein (Ceph, NFS, iSCSI).
- Fencing (Isolation): Bevor eine VM auf Knoten B gestartet wird, muss der Cluster zu 100% sicher sein, dass Knoten A (der ausgefallen ist) die VM nicht mehr ausführt und nicht mehr auf den Speicher schreibt.
# Der HA-Entscheidungsfluss (Mermaid)
graph TD
A[Start: Host Ausfall erkannt] --> B{Hat Cluster Quorum?}
B -- Nein --> C[Stop: Alle HA-Aktionen einfrieren]
B -- Ja --> D[Fencing: Warte auf Host-Isolation]
D --> E{Host erfolgreich isoliert?}
E -- Nein --> F[Wait: Erneuter Versuch / Manueller Eingriff]
E -- Ja --> G[CRM: Wähle neuen Zielknoten]
G --> H[LRM: Starte VM auf Zielknoten]
H --> I[Ende: VM wieder online]
style D fill:#f96,stroke:#333
style G fill:#9f9,stroke:#333# 2. Deep Dive: HA-Manager Komponenten
Der HA-Stack besteht aus zwei spezialisierten Diensten, die auf jedem Knoten laufen.
- PVE-HA-CRM (Cluster Resource Manager): Der “Stratege”. Nur ein CRM im Cluster ist der Master. Er analysiert den Cluster-Status und entscheidet, welche Ressource (VM/Container) wohin verschoben wird.
- PVE-HA-LRM (Local Resource Manager): Der “Arbeiter”. Er führt die Befehle des CRM lokal aus (Start/Stop/Migrate) und meldet den Status zurück.
- Watchdog (Fencing): Ein Hardware- oder Software-Timer im Kernel. Wenn der LRM den Kontakt zum Quorum verliert, löst der Watchdog einen harten Reset aus. Dies ist das STONITH Prinzip (Shoot The Other Node In The Head).
# 3. Quorum & Fencing: Der Schutz vor Split-Brain
Das schlimmste Szenario in einem Cluster ist, wenn zwei Knoten gleichzeitig denken, sie hätten das Recht, eine VM auszuführen und auf deren Disk zu schreiben.
# Fencing-Ablauf (Mermaid)
sequenceDiagram
participant N1 as Knoten 1 (Ausfall)
participant N2 as Knoten 2 (Healthy)
participant Q as Quorum (Cluster)
N1->>Q: [Netzwerkunterbrechung]
Note right of Q: Knoten 1 antwortet nicht mehr
Q->>N2: Knoten 1 für 'tot' erklärt
N2->>Q: Fordere Fencing für Knoten 1 an
Note over N1: Watchdog läuft ab (60s)
N1->>N1: HARD RESET (Fenced)
Note over N2: Fencing bestätigt
N2->>N2: Starte VM von Knoten 1# 4. Day-2 Operations: HA-Gruppen & Prioritäten
Ein professionelles HA-Design steuert den Failover gezielt über HA Groups.
# Konfigurations-Parameter
- Nodes: Liste der Knoten, auf denen die Ressourcen laufen dürfen.
- Restricted: Wenn aktiv, darf die VM nur auf den gelisteten Knoten starten.
- NoFailback: Verhindert, dass eine VM automatisch zum ursprünglichen Knoten zurückkehrt, wenn dieser wieder online ist (verhindert unnötige Downtime).
- Priorität: VMs mit hoher Priorität (z.B. Domain Controller) werden vom CRM zuerst verarbeitet.
# 5. Troubleshooting & “War Stories”
# Die “Fencing-Schleife”
Szenario: Ein Cluster wurde mit nur zwei Knoten ohne QDevice aufgebaut. Ein Switch-Port-Defekt unterbrach die Verbindung zwischen den Knoten. Symptom: Beide Knoten starteten sich alle 2 Minuten neu. Ursache: Da kein Knoten die Mehrheit (Quorum) hatte, lösten beide den Watchdog aus. Nach dem Booten fanden sie sich wieder nicht -> Reset. Lösung: Installieren Sie immer ein QDevice (z.B. auf einem Raspberry Pi oder einer kleinen VM), um eine ungerade Anzahl an Stimmen zu erhalten.
# Der hängende Mount
Szenario: Ein Host fiel aus. Der HA-Manager versuchte, die VMs auf Knoten 2 zu starten. Symptom: Der Start schlug fehl mit der Meldung “Storage not available”. Ursache: Das NFS-Storage war auf Knoten 2 nicht korrekt gemountet, da die Berechtigungen am NAS fehlten. Lösung: Führen Sie regelmäßige DR-Tests (Disaster Recovery) durch. Schalten Sie einen Host hart aus und beobachten Sie, ob der Failover auf alle anderen Knoten reibungslos klappt.
# 6. Experten-Checkliste für HA-Cluster
- [ ] Ungerade Anzahl an Stimmen (Knoten oder QDevice) vorhanden?
- [ ] Shared Storage (Ceph, NFS, iSCSI) für alle HA-VMs aktiv?
- [ ] Hardware Watchdog im BIOS und OS konfiguriert?
- [ ] N+1 Kapazität (RAM-Reserve) auf allen Knoten geprüft?
- [ ] HA Groups zur Lastverteilung und Priorisierung definiert?