Proxmox Cluster - Versionsgeschichte

Maximilian.pottgiesser: /* Glossar */

2026-02-13T06:27:27Z

Glossar

Maximilian.pottgiesser am 13. Februar 2026 um 06:25 Uhr

2026-02-13T06:25:11Z

Maximilian.pottgiesser am 13. Februar 2026 um 06:24 Uhr

2026-02-13T06:24:37Z

Änderungen zeigen

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Corosync bei Proxmox VE = == Grundprinzip == Corosync ist das '''Cluster-Kommunikations-Framework''', das Proxmox VE für seinen HA-Cluster nutzt. Es bilde…“

2026-02-13T06:13:29Z

Die Seite wurde neu angelegt: „= Corosync bei Proxmox VE = == Grundprinzip == Corosync ist das '''Cluster-Kommunikations-Framework''', das Proxmox VE für seinen HA-Cluster nutzt. Es bilde…“

Neue Seite

= 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|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 ==

{| class="wikitable"
|-
! 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 <code>/etc/pve/corosync.conf</code> 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:

<pre>
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
</pre>

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 <code>/etc/pve</code> 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 <code>/etc/pve</code> gemacht wird, ist '''sofort auf allen anderen Knoten verfügbar''' – ohne rsync, ohne NFS, ohne manuelles Kopieren.

== Inhalte von /etc/pve ==

{| class="wikitable"
|-
! Pfad !! Beschreibung
|-
| <code>corosync.conf</code> || Die Cluster-Kommunikationskonfiguration selbst
|-
| <code>storage.cfg</code> || Welche Storage-Backends definiert sind (Ceph, NFS, ZFS, iSCSI …)
|-
| <code>user.cfg</code> / <code>priv/</code> || Benutzer, Rollen, Berechtigungen, API-Tokens
|-
| <code>datacenter.cfg</code> || Cluster-weite Einstellungen (HA, Migration, Konsole …)
|-
| <code>nodes/<hostname>/</code> || Knotenspezifische Configs (Netzwerk, QEmu-VMs, LXC-Container)
|-
| <code>firewall/</code> || Cluster-weite und VM-spezifische Firewall-Regeln
|-
| <code>ha/</code> || HA-Gruppen und Ressource-Zuordnungen
|-
| <code>sdn/</code> || Software Defined Networking Konfiguration
|-
| <code>authkey.pub</code> / 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 <code>/etc/pve</code> 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).

{| class="wikitable"
|-
! 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:

<pre>
[Node A] ←→ [Node B] ✗ Verbindung unterbrochen ✗ [Node C] ←→ [Node D]
Seite 1 Seite 2
</pre>

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.

← Nächstältere Version		Version vom 13. Februar 2026, 06:27 Uhr
Zeile 363:		Zeile 363:

	----		----
−
−	~~= Glossar =~~
−
−	~~{\| class="wikitable"~~
−	\|-
−	~~! Begriff !! Erklärung~~
−	\|-
−	~~\| '''Hypervisor''' \|\| Software, die Virtualisierung ermöglicht und virtuelle Maschinen auf physischer Hardware betreibt.~~
−	\|-
−	~~\| '''VM (Virtuelle Maschine)''' \|\| Ein virtueller Computer, der auf einem Hypervisor läuft und sich wie ein eigenständiger Server verhält.~~
−	\|-
−	~~\| '''Container (LXC)''' \|\| Eine leichtgewichtige Virtualisierungsform, bei der sich mehrere isolierte Umgebungen einen gemeinsamen Kernel teilen.~~
−	\|-
−	~~\| '''Knoten (Node)''' \|\| Ein physischer Server, der Teil eines Clusters ist.~~
−	\|-
−	~~\| '''Cluster''' \|\| Ein Verbund aus mehreren Knoten, die koordiniert zusammenarbeiten.~~
−	\|-
−	~~\| '''Quorum''' \|\| Die Mindestanzahl an Stimmen (>50%), die nötig ist, damit der Cluster handlungsfähig ist.~~
−	\|-
−	~~\| '''Quorate''' \|\| Zustand des Clusters, wenn genügend Stimmen für ein Quorum vorhanden sind.~~
−	\|-
−	~~\| '''HA (High Availability)''' \|\| Hochverfügbarkeit – Architektur und Maßnahmen, die Ausfallzeiten minimieren.~~
−	\|-
−	~~\| '''Failover''' \|\| Der automatische Schwenk einer VM oder eines Services auf einen anderen Knoten bei Ausfall des ursprünglichen Knotens.~~
−	\|-
−	~~\| '''Fencing''' \|\| Das aktive Abschalten eines ausgefallenen Knotens (z.B. per IPMI), um sicherzustellen, dass er keine Ressourcen mehr hält.~~
−	\|-
−	~~\| '''Live-Migration''' \|\| Das Verschieben einer laufenden VM von einem Knoten auf einen anderen ohne Unterbrechung.~~
−	\|-
−	~~\| '''Shared Storage''' \|\| Ein Speichersystem, auf das alle Knoten eines Clusters zugreifen können (z.B. NFS, iSCSI, Ceph).~~
−	\|-
−	~~\| '''Split-Brain''' \|\| Ein Zustand, bei dem ein Cluster in zwei (oder mehr) Teile zerfällt, die unabhängig voneinander handeln.~~
−	\|-
−	~~\| '''Token''' \|\| Ein Nachrichtenpaket im Totem-Protokoll, das im Ring kreist und die Senderechte regelt.~~
−	\|-
−	~~\| '''Totem-Protokoll''' \|\| Das Kommunikationsprotokoll von Corosync, das über einen Token-Ring die geordnete Nachrichtenzustellung garantiert.~~
−	\|-
−	~~\| '''Corosync''' \|\| Das Cluster-Kommunikations-Framework, das Proxmox VE für die Knoten-Kommunikation und Quorum-Verwaltung nutzt.~~
−	\|-
−	~~\| '''pmxcfs''' \|\| Das Proxmox Cluster File System – ein datenbankgestütztes Dateisystem unter <code>/etc/pve</code>, das über Corosync repliziert wird.~~
−	\|-
−	~~\| '''Kronosnet (knet)''' \|\| Der Netzwerk-Transport-Layer, den neuere Corosync-Versionen für Unicast-Kommunikation verwenden.~~
−	\|-
−	~~\| '''CRM (Cluster Resource Manager)''' \|\| Die Komponente von Proxmox HA, die entscheidet, auf welchem Knoten eine HA-Ressource laufen soll.~~
−	\|-
−	~~\| '''LRM (Local Resource Manager)''' \|\| Die Komponente auf jedem Knoten, die die lokalen HA-Ressourcen startet, stoppt und überwacht.~~
−	\|-
−	~~\| '''IPMI / iDRAC / iLO''' \|\| Out-of-Band-Management-Interfaces für Server, die ein Fencing (Fernabschaltung) ermöglichen.~~
−	\|}

← Nächstältere Version		Version vom 13. Februar 2026, 06:25 Uhr
Zeile 1:		Zeile 1:
−	~~= Grundlagen: Virtualisierung =~~
−
−	~~== Was ist Virtualisierung? ==~~
−
−	Virtualisierung bedeutet, dass auf '''einem physischen Server''' (dem sogenannten '''Host''') mehrere virtuelle Maschinen (VMs) gleichzeitig laufen. Jede VM verhält sich wie ein eigenständiger Computer – mit eigenem Betriebssystem, eigener IP-Adresse, eigenem Speicher und eigener CPU-Zuweisung – obwohl sie sich in Wirklichkeit die Hardware des Hosts teilt.
−
−	~~Die Software, die das ermöglicht, nennt man '''Hypervisor'''. Es gibt zwei Typen:~~
−
−	~~{\| class="wikitable"~~
−	\|-
−	~~! Typ !! Beschreibung !! Beispiele~~
−	\|-
−	\| '''Typ 1 (Bare-Metal)''' \|\| Der Hypervisor läuft direkt auf der Hardware, ohne ein darunterliegendes Betriebssystem. Das ist der Standard in professionellen Umgebungen, da es weniger Overhead und bessere Performance bietet. \|\| Proxmox VE, XCP-ng, VMware ESXi, Microsoft Hyper-V Server
−	\|-
−	\| '''Typ 2 (Hosted)''' \|\| Der Hypervisor läuft als Anwendung auf einem normalen Betriebssystem (z.B. Windows oder Linux). Eher für Entwicklung und Tests geeignet. \|\| VirtualBox, VMware Workstation, Parallels
−	\|}
−
−	~~== Warum virtualisiert man? ==~~
−
−	* '''Ressourceneffizienz:''' Ein physischer Server ist selten voll ausgelastet. Statt 10 Server mit jeweils 5 % CPU-Last zu betreiben, laufen 10 VMs auf einem Server mit 50 % Last.
−	* '''Isolation:''' Jede VM ist von den anderen isoliert. Ein Absturz oder Sicherheitsvorfall in einer VM betrifft die anderen nicht.
−	* '''Flexibilität:''' Neue VMs lassen sich in Minuten erstellen, anstatt neue Hardware bestellen und einbauen zu müssen.
−	* '''Snapshots und Backups:''' Der komplette Zustand einer VM kann als Snapshot gesichert werden – inkl. RAM, CPU-State und Festplatten.
−	* '''Migration:''' VMs können im laufenden Betrieb von einem Host auf einen anderen verschoben werden (Live-Migration).
−
−	~~== Was ist ein Container? ==~~
−
−	~~Neben VMs gibt es '''Container''' (z.B. LXC bei Proxmox, Docker in anderen Umgebungen). Der Unterschied:~~
−
−	~~{\| class="wikitable"~~
−	\|-
−	~~! Eigenschaft !! Virtuelle Maschine !! Container~~
−	\|-
−	~~\| '''Kernel''' \|\| Eigener Kernel pro VM \|\| Teilt sich den Kernel des Hosts~~
−	\|-
−	~~\| '''Overhead''' \|\| Höher (volles OS pro VM) \|\| Geringer (nur die Anwendung + Abhängigkeiten)~~
−	\|-
−	~~\| '''Isolation''' \|\| Stark (Hardware-Ebene) \|\| Schwächer (Prozess-Ebene)~~
−	\|-
−	~~\| '''Startzeit''' \|\| Sekunden bis Minuten \|\| Millisekunden bis Sekunden~~
−	\|-
−	~~\| '''Einsatzgebiet''' \|\| Unterschiedliche Betriebssysteme, hohe Isolation nötig \|\| Microservices, Anwendungen gleichen OS-Typs~~
−	\|}
−
−	~~Proxmox unterstützt '''beides''' – KVM-basierte VMs und LXC-Container – und kann diese auch im Cluster und mit HA betreiben.~~
−
−	~~----~~
−
	= Grundlagen: Cluster =		= Grundlagen: Cluster =