# Proxmox HA Setup: Schritt-für-Schritt zur hochverfügbaren Infrastruktur

TL;DR / Management Summary Ein HA Cluster in Proxmox verwandelt eine Gruppe von Einzelservern in ein resilientes System. Fällt ein physischer Knoten aus, übernimmt der Cluster-Manager die Kontrolle und startet die betroffenen VMs auf gesunden Knoten neu. Ein Senior Admin konfiguriert hierfür HA-Gruppen zur Steuerung der Lastverteilung und achtet streng auf das N+1 Prinzip, um sicherzustellen, dass im Fehlerfall genug Ressourcen für alle Workloads vorhanden sind.

# 1. Voraussetzungen für HA

Die Pflicht vor der Kür.

Damit HA zuverlässig funktioniert, müssen folgende Bedingungen erfüllt sein:

  1. Quorum: Mindestens 3 Knoten (oder 2 + QDevice, Artikel 665).
  2. Shared Storage: Alle Knoten müssen Zugriff auf die VM-Disks haben (Artikel 685) oder ZFS-Replikation nutzen.
  3. Netzwerk: Konsistente Bridge-Namen auf allen Knoten (z.B. vmbr0).
  4. Hardware-Watchdog: Aktiviert in den Node-Optionen.

# 2. Einrichtung des HA-Managers

Den Autopilot aktivieren.

# Schritt 1: HA Gruppe erstellen

Datacenter -> HA -> Groups -> Create.

# Schritt 2: VM zur HA hinzufügen

Datacenter -> HA -> Add.

  1. VMID: Wählen Sie Ihre kritische VM.
  2. Group: Wählen Sie die in Schritt 1 erstellte Gruppe.
  3. Max Restart: Wie oft soll Proxmox versuchen, die VM bei einem Fehler neustarter (Standard: 1).
  4. Max Relocate: Wie oft soll die VM auf einen anderen Knoten verschoben werden.

# 3. Deep Dive: HA-Zustände (States)

Die Logik hinter dem Failover.

Der HA-Manager überwacht jede Ressource:

# 4. Day-2 Operations: Wartungsmodus (Maintenance)

Arbeiten ohne Alarm.

Bevor Sie einen Host für Updates neustarten:

  1. Migrieren Sie die HA-VMs manuell (Live Migration).
  2. Alternativ: Setzen Sie den Host in den Maintenance Mode unter Node -> Management -> Maintenance.
  3. Wirkung: Der HA-Manager ignoriert diesen Host temporär und löst keine Failover-Alarme aus.

# 5. Troubleshooting & “War Stories”

Wenn der Schwenk hakt.

# Top 3 Fehlerbilder

  1. Symptom: VM startet nicht am Ziel-Knoten.

    • Ursache: RAM-Mangel am Ersatz-Host.
    • Lösung: Nutzen Sie Dynamic Memory (Ballooning) (Artikel 668), um im Notfall Platz zu schaffen.

  2. Symptom: Host führt ständig Selbst-Reboots durch.

    • Ursache: Netzwerk-Latenz im Corosync-Netz ist zu hoch (> 5ms). Der Watchdog denkt, der Host sei isoliert und löst STONITH aus.
    • Fix: Separates 10G Netz für Corosync nutzen.

  3. Symptom: VM bleibt im Status Error hängen.

    • Lösung: ha-manager status prüfen und ggf. Lock manuell via CLI entfernen.

# “War Story”: Das “No-Backup” HA-Blindvertrauen

Ein Admin dachte, mit HA sei er sicher vor Datenverlust. Er verzichtete auf Backups (“Der Cluster spiegelt ja alles”). Das Ereignis: Ein Dateisystem-Bug in einer VM korrumpierte die Datenbank. Das Ergebnis: HA erkannte, dass die VM noch “lief” und tat nichts. Als die VM schließlich abstürzte, startete HA sie brav auf Knoten B neu – inklusive der korrupten Datenbank. Lehre: HA schützt vor Hardware-Ausfall, nicht vor Daten-Korruption. Backups (Artikel 613) sind auch im HA-Cluster zwingend erforderlich!

# 6. Monitoring & Reporting

Status der Verfügbarkeit.

# HA-Log Analyse (Shell)

# Zeigt alle HA-Entscheidungen der letzten Stunde
journalctl -u pve-ha-crm -u pve-ha-lrm --since "1 hour ago"

# 7. Fazit & Empfehlung

Ein gut konfigurierter HA-Cluster ist der Stolz jedes Admins.

# Anhang: Cheatsheet (HA CLI)

Aufgabe Befehl
Globaler Status ha-manager status
VM zu HA hinzufügen ha-manager add vm:100
Ressource entfernen ha-manager remove vm:100
CRM Log sehen tail -f /var/log/pve-ha-crm.log

# Referenzen