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.

Proxmox Cluster

Inhaltsverzeichnis