Proxmox Cluster

Corosync bei Proxmox VE

Grundprinzip

Corosync ist das Cluster-Kommunikations-Framework, das Proxmox VE für seinen HA-Cluster nutzt. Es bildet zusammen mit dem Proxmox Cluster File System (pmxcfs) das Rückgrat der Cluster-Kommunikation.

Kernfunktionen

Totem-Protokoll (Single Ring Ordering)

Corosync nutzt das Totem-Protokoll, um eine zuverlässige, geordnete Nachrichtenzustellung zwischen allen Cluster-Knoten sicherzustellen. Alle Nachrichten werden in einem virtuellen "Ring" an alle Knoten gleichzeitig verteilt – so hat jeder Knoten denselben Informationsstand.

Quorum / Abstimmung

Jeder Knoten hat standardmäßig eine Stimme. Ein Cluster ist nur dann handlungsfähig ("quorate"), wenn mehr als 50 % der Stimmen verfügbar sind. Bei einem 3-Node-Cluster darf also maximal ein Knoten ausfallen. Ohne Quorum werden keine HA-Aktionen (VM-Migration, Failover) ausgeführt – das verhindert Split-Brain-Szenarien.

Heartbeat / Membership

Corosync sendet regelmäßig Multicast- oder Unicast-Heartbeats zwischen den Knoten. Bleibt ein Heartbeat aus, wird der Knoten nach einem Timeout als ausgefallen markiert und das Quorum neu berechnet.

Netzwerkkonfiguration

Eigenschaft	Details
Corosync-Links	Proxmox unterstützt bis zu 8 redundante Links (link0, link1, …) für Ausfallsicherheit. Fällt ein Link aus, übernimmt automatisch der nächste.
Netzwerktrennung	Es wird empfohlen, ein dediziertes Cluster-Netzwerk zu verwenden, das vom Storage-Traffic und VM-Traffic getrennt ist. So wird verhindert, dass z.B. eine Storage-Migration die Cluster-Kommunikation blockiert.
Ports	UDP 5405–5412. Diese Ports müssen zwischen allen Cluster-Knoten in der Firewall freigegeben sein.
Transportmodus	Kann Multicast oder Unicast nutzen. Unicast ist mittlerweile Standard bei neueren Proxmox-Versionen und wird über Kronosnet (knet) realisiert. Kronosnet bietet gegenüber dem klassischen Multicast-Transport zusätzliche Features wie Kompression, Verschlüsselung und besseres Link-Management.

Konfigurationsdatei

Die zentrale Konfigurationsdatei liegt unter /etc/pve/corosync.conf und wird über pmxcfs automatisch auf alle Knoten synchronisiert. Sie enthält:

• Knoten-IDs und Adressen – welche Knoten zum Cluster gehören und über welche IPs sie erreichbar sind
• Totem-Einstellungen – Token-Timeout und Consensus-Timeout, also wie lange gewartet wird, bevor ein Knoten als ausgefallen gilt
• Quorum-Konfiguration – wie viele Stimmen für ein gültiges Quorum benötigt werden

Zusammenspiel mit HA

Der HA-Stack von Proxmox baut direkt auf Corosync auf. Der Ablauf sieht folgendermaßen aus:

Corosync (Kommunikation + Quorum)
    ↓
pve-ha-lrm (Local Resource Manager – läuft auf jedem Knoten)
    ↓
pve-ha-crm (Cluster Resource Manager – läuft auf einem Knoten)
    ↓
Entscheidung: VM/CT migrieren, neustarten, stoppen

Der HA-Manager verlässt sich komplett auf Corosync für die Knoten-Membership. Fällt ein Knoten aus dem Corosync-Ring, erkennt der CRM dies und triggert ein Fencing/Failover der betroffenen VMs. Das bedeutet: Ohne funktionierendes Corosync gibt es kein HA – die beiden Komponenten sind untrennbar miteinander verbunden.

Vergleich: Corosync vs. XCP-ng HA

Bei XCP-ng übernimmt XAPI mit dem eigenen HA-Mechanismus und Pool-Master-Konzept eine ähnliche Rolle – allerdings mit einem grundlegend anderen Ansatz. XCP-ng nutzt kein Totem-Ring-Protokoll, sondern ein Master-Slave-Modell mit Heartbeat-SRs (Shared Storage zur Überwachung). Corosync ist deutlich generischer und wird auch außerhalb von Proxmox in Pacemaker-Clustern eingesetzt.

---

Proxmox Cluster File System (pmxcfs)

Was ist pmxcfs?

pmxcfs ist ein spezielles, datenbankgestütztes Dateisystem, das unter /etc/pve gemountet wird. Es nutzt im Hintergrund eine SQLite-Datenbank, die über Corosync in Echtzeit auf alle Cluster-Knoten repliziert wird.

Das heißt: Jede Änderung, die auf einem Knoten unter /etc/pve gemacht wird, ist sofort auf allen anderen Knoten verfügbar – ohne rsync, ohne NFS, ohne manuelles Kopieren.

Inhalte von /etc/pve

Pfad	Beschreibung
corosync.conf	Die Cluster-Kommunikationskonfiguration selbst
storage.cfg	Welche Storage-Backends definiert sind (Ceph, NFS, ZFS, iSCSI …)
user.cfg / priv/	Benutzer, Rollen, Berechtigungen, API-Tokens
datacenter.cfg	Cluster-weite Einstellungen (HA, Migration, Konsole …)
nodes/<hostname>/	Knotenspezifische Configs (Netzwerk, QEmu-VMs, LXC-Container)
firewall/	Cluster-weite und VM-spezifische Firewall-Regeln
ha/	HA-Gruppen und Ressource-Zuordnungen
sdn/	Software Defined Networking Konfiguration
authkey.pub / TLS-Zertifikate	Cluster-Authentifizierung

Warum braucht man pmxcfs?

Problem ohne pmxcfs

Man stelle sich einen 5-Node-Cluster vor. Es wird eine Firewall-Regel geändert oder ein neues Storage hinzugefügt. Ohne pmxcfs müsste diese Änderung irgendwie auf alle 5 Knoten synchronisiert werden – per Ansible, rsync oder manuell. Das ist fehleranfällig und hat Race Conditions.

Lösung mit pmxcfs

• Die Änderung wird auf einem beliebigen Knoten durchgeführt
• Corosync verteilt die Änderung atomar und konsistent an alle anderen Knoten
• Alle Knoten haben immer denselben Stand – kein Drift, kein Konflikt
• Schreibzugriffe sind nur möglich, wenn der Cluster quorate ist (>50% der Knoten erreichbar) → das verhindert Split-Brain-Inkonsistenzen

Schutzmechanismus

Dies ist ein entscheidender Punkt: Ohne Quorum ist /etc/pve read-only. Wenn ein 3-Node-Cluster 2 Knoten verliert, kann der verbleibende Knoten nichts mehr ändern. Das klingt zunächst hinderlich, schützt aber davor, dass zwei isolierte Cluster-Hälften widersprüchliche Änderungen machen.

Vergleich: pmxcfs vs. XCP-ng XAPI-Datenbank

Bei XCP-ng übernimmt die XAPI-Datenbank eine ähnliche Rolle – sie liegt auf dem Pool-Master und wird von dort an die Pool-Member verteilt. Der entscheidende Unterschied: Bei Proxmox/pmxcfs gibt es keinen dedizierten Master – jeder Knoten kann Änderungen schreiben, und Corosync sorgt für den Konsens. Bei XCP-ng muss immer über den Pool-Master gegangen werden (oder bei dessen Ausfall erst ein neuer Master promotet werden).

Eigenschaft	Proxmox (pmxcfs)	XCP-ng (XAPI)
Architektur	Symmetrischer Cluster – jeder Knoten kann schreiben	Master-Slave – Änderungen nur über Pool-Master
Replikation	Über Corosync in Echtzeit an alle Knoten	XAPI-Datenbank auf Pool-Master, Verteilung an Member
Master-Ausfall	Kein Master nötig, Quorum entscheidet	Neuer Master muss erst promotet werden
Konsistenzmechanismus	Quorum-basiert (Corosync)	Heartbeat-SR (Shared Storage LUN)

Das ist einer der architektonischen Hauptunterschiede: Proxmox = symmetrischer Cluster, XCP-ng = Master-Slave-Modell.

---

Split-Brain

Das Szenario

Ausgangslage: Ein 4-Node-Cluster, bei dem die Netzwerkverbindung zwischen zwei Standorten ausfällt:

[Node A] ←→ [Node B]     ✗ Verbindung unterbrochen ✗     [Node C] ←→ [Node D]
      Seite 1                                                    Seite 2

Beide Seiten können sich gegenseitig nicht mehr erreichen. Aus Sicht von Seite 1 sind Node C und D "ausgefallen" – und umgekehrt. Beide Seiten glauben, sie seien der überlebende Cluster.

Was passiert ohne Schutz?

Wenn beide Seiten jetzt eigenständig weiterarbeiten, passiert Folgendes:

• Beide Seiten starten dieselbe HA-VM, weil jede Seite denkt, die andere ist tot → die VM läuft doppelt mit derselben IP, derselben Identität
• Beide Seiten schreiben auf denselben Shared Storage → Datenkorruption, weil zwei Instanzen gleichzeitig auf dieselbe virtuelle Festplatte schreiben
• Konfigurationsänderungen divergieren → wenn das Netz wiederkommt, hat jede Seite unterschiedliche Zustände und es ist unklar, welcher der "richtige" ist

Das ist Split-Brain – das Gehirn des Clusters ist gespalten, und beide Hälften handeln unkoordiniert.

Warum ist das so gefährlich?

Die Datenkorruption auf dem Shared Storage ist das Worst-Case-Szenario. Wenn zwei VMs gleichzeitig auf dasselbe Disk-Image schreiben, ist das Dateisystem danach in der Regel unwiederbringlich zerstört. Das ist kein theoretisches Risiko – das passiert tatsächlich und ist einer der häufigsten Gründe für Datenverlust in Clustern.

Wie schützt Quorum davor?

Hier kommt das Quorum-Prinzip ins Spiel. Bei 4 Knoten mit je einer Stimme braucht man 3 Stimmen für Quorum (>50%):

• Seite 1 hat 2 Stimmen → kein Quorum → wird inaktiv, startet keine VMs
• Seite 2 hat 2 Stimmen → kein Quorum → wird ebenfalls inaktiv

Ergebnis: Lieber steht alles still, als dass Daten zerstört werden.

Deshalb empfiehlt man ungerade Knotenanzahlen (3, 5, 7) – bei einem 3-Node-Cluster hat die Seite mit 2 Knoten immer Quorum und kann weiterarbeiten.

Split-Brain-Schutz bei XCP-ng

XCP-ng löst das Problem anders: Dort nutzt man eine Heartbeat-SR (ein kleines Shared-Storage-LUN), über die sich die Knoten gegenseitig überwachen. Fällt der Pool-Master aus, wird über diese SR entschieden, wer neuer Master wird. Das Prinzip ist dasselbe – verhindern, dass zwei Hälften gleichzeitig aktiv werden – nur der Mechanismus unterscheidet sich von Corosync/Quorum.

Bei einer TrueNAS-basierten Storage-Lösung wäre eine solche Heartbeat-SR typischerweise eine kleine iSCSI-LUN auf dem TrueNAS.