Zum Hauptinhalt springen
Infrastructure · · ~2 min Lesezeit

Proxmox Quorum Loss: Wie ein 2-Node-Cluster ausfällt — und wie man es verhindert

Ein Node geht offline, das Quorum ist verloren, keine VM startet mehr. Analyse des Incidents und die Lösung: Corosync QDevice als dritter Voter.

ProxmoxClusterIncidentCorosyncHA

Was passierte

Ein Node im Proxmox-Cluster wurde unerreichbar (ARP unreachable). In einem 2-Node-Cluster ohne externen QDevice bedeutet das: Quorum verloren — beide Nodes stellen sofort alle VM-Operationen ein. Kein Start, kein Stop, keine Migration.

Das ist kein Bug — es ist Corosync-Design. Ein 2-Node-Cluster braucht beide Nodes für Quorum (2/2 Votes = 100%). Fällt einer aus, gibt es keine Mehrheit mehr.

Diagnose

# Quorum-Status prüfen
pvecm status

# Output:
# Quorum information
# Nodes: 2
# Expected votes: 2
# Total votes: 1  ← Problem: nur 1/2 Votes
# Quorum votes: 2
# Flags: Quorate: no  ← Kein Quorum

VMs, die auf dem erreichbaren Node lagen, konnten nicht gestartet werden, obwohl der Node selbst vollständig online war.

Ursache

ARP-Tabellen-Inkonsistenz zwischen dem Node und dem Switch. Der Node war physisch erreichbar (SSH funktionierte), aber der Corosync-Heartbeat-Interface meldete unreachable wegen veralteter ARP-Einträge.

Sofortmaßnahme

# Auf dem noch erreichbaren Node:
# Quorum temporär mit 1 Vote erzwingen (ACHTUNG: nur im Notfall)
pvecm expected 1

# Dann VMs starten, System stabilisieren

Warnung: pvecm expected 1 ist eine Notfall-Maßnahme und erzeugt ein Split-Brain-Risiko wenn beide Nodes tatsächlich parallel laufen. Nur einsetzen wenn sicher ist, dass der andere Node wirklich offline ist.

Dauerhafte Lösung: Corosync QDevice

Ein QDevice ist ein leichtgewichtiger dritter Voter — kein vollständiger Proxmox-Node, sondern ein kleiner Dienst der auf einem beliebigen Linux-System läuft. Mit QDevice hat der Cluster 3 Votes (Node A + Node B + QDevice), Quorum bei 2/3. Fällt ein Node aus, haben die verbleibenden 2 noch Quorum.

# QDevice installieren (auf externem System, z.B. kleiner VPS)
apt install corosync-qnetd

# Im Proxmox-Cluster QDevice hinzufügen
pvecm qdevice setup <qdevice-host>

# Status prüfen
pvecm status
# Expected votes: 3
# Quorum votes: 2  ← Jetzt Quorum bei 1 ausgefallenen Node

Takeaways

  1. 2-Node-Cluster ohne QDevice = Single Point of Failure — unabhängig davon, welcher Node ausfällt.
  2. ARP-Probleme sind heimtückisch — der Node ist erreichbar, Corosync sieht ihn nicht.
  3. QDevice kostet kaum Ressourcen — ein t2.nano oder ähnlicher Mini-VPS reicht völlig.
  4. Recovery dokumentieren — der nächste Incident kommt, und dann will man keine Anleitung suchen.

Recovery-Zeit

Vom Erkennen des Problems bis zum Wiederherstellen des normalen Betriebs: ~25 Minuten. Davon 15 Minuten Diagnose (ARP als Ursache identifizieren), 10 Minuten Recovery.

Alle Artikel EN