Proxmox Cluster: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(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…“)
 
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 =
 +
 +
== Was ist ein Cluster? ==
 +
 +
Ein Cluster ist ein '''Verbund aus mehreren Servern (Knoten/Nodes)''', die zusammenarbeiten und nach außen wie ein einziges System erscheinen. Die Knoten kommunizieren untereinander über ein Netzwerk und koordinieren sich, um gemeinsam Aufgaben zu erfüllen.
 +
 +
Ein Cluster ist '''nicht''' einfach "mehrere Server im selben Netzwerk". Der entscheidende Unterschied ist, dass die Knoten '''voneinander wissen''', sich gegenseitig '''überwachen''' und '''gemeinsam Entscheidungen treffen''' – z.B. welcher Knoten welche VM betreibt, oder was passiert, wenn ein Knoten ausfällt.
 +
 +
== Warum braucht man einen Cluster? ==
 +
 +
Ein einzelner Server hat immer eine Schwachstelle: '''Fällt er aus, ist alles weg.''' Egal wie gut die Hardware ist – jeder Server kann ausfallen (Netzteil, Mainboard, Stromausfall, Kernel-Panic). Ein Cluster löst dieses Problem, indem die Last auf mehrere Knoten verteilt wird und bei einem Ausfall andere Knoten übernehmen können.
 +
 +
Weitere Gründe:
 +
 +
* '''Zentrale Verwaltung:''' Alle Knoten werden über eine gemeinsame Oberfläche verwaltet, statt sich auf jeden Server einzeln einzuloggen.
 +
* '''Gemeinsame Konfiguration:''' Änderungen (z.B. Storage, Firewall, Benutzer) werden automatisch auf alle Knoten synchronisiert.
 +
* '''Live-Migration:''' VMs können im laufenden Betrieb zwischen Knoten verschoben werden – z.B. für Wartungsarbeiten an einem Host.
 +
* '''Skalierbarkeit:''' Neue Knoten können zum Cluster hinzugefügt werden, um mehr Kapazität zu erhalten.
 +
 +
== Cluster-Typen ==
 +
 +
{| class="wikitable"
 +
|-
 +
! Typ !! Beschreibung !! Beispiel
 +
|-
 +
| '''Compute-Cluster''' || Mehrere Knoten berechnen gemeinsam eine Aufgabe (z.B. wissenschaftliche Simulationen). || HPC-Cluster, Beowulf-Cluster
 +
|-
 +
| '''Load-Balancing-Cluster''' || Eingehende Anfragen werden auf mehrere Knoten verteilt, um Last zu verteilen. || Webserver-Cluster mit HAProxy oder Nginx
 +
|-
 +
| '''High-Availability-Cluster''' || Der Fokus liegt auf Ausfallsicherheit: Fällt ein Knoten aus, übernimmt ein anderer. || Proxmox HA, XCP-ng HA, Pacemaker
 +
|-
 +
| '''Storage-Cluster''' || Mehrere Knoten stellen gemeinsam Speicher bereit (verteilt oder repliziert). || Ceph, GlusterFS, TrueNAS HA
 +
|}
 +
 +
Proxmox-Cluster sind primär '''High-Availability-Cluster''', können aber durch Ceph-Integration auch gleichzeitig als Storage-Cluster fungieren.
 +
 +
== Cluster ≠ High Availability ==
 +
 +
Ein sehr wichtiger Punkt: '''Ein Cluster ist nicht automatisch hochverfügbar.''' Ein Proxmox-Cluster mit 3 Knoten bietet zunächst nur:
 +
 +
* Zentrale Verwaltung über eine Weboberfläche
 +
* Synchronisierte Konfiguration via [[#Proxmox Cluster File System (pmxcfs)|pmxcfs]]
 +
* Die ''Möglichkeit'' zur Live-Migration von VMs
 +
 +
'''Aber:''' Fällt ein Knoten aus, passiert ohne explizit aktiviertes HA '''gar nichts''' – die VMs auf dem ausgefallenen Knoten bleiben einfach weg. Erst wenn man HA aktiviert und VMs als HA-Ressourcen konfiguriert, werden sie bei einem Knotenausfall automatisch auf einen anderen Knoten neu gestartet.
 +
 +
Das heißt:
 +
* '''Cluster ohne HA:''' Gemeinsame Verwaltung, manuelle Migration, kein automatisches Failover
 +
* '''Cluster mit HA:''' Gemeinsame Verwaltung, automatisches Failover bei Knotenausfall
 +
 +
----
 +
 +
= High Availability (HA) =
 +
 +
== Was ist High Availability? ==
 +
 +
High Availability (Hochverfügbarkeit) bedeutet, dass ein System so aufgebaut ist, dass es auch bei Ausfällen einzelner Komponenten '''weiter funktioniert'''. Das Ziel ist, Ausfallzeiten zu minimieren – idealerweise auf wenige Sekunden oder Minuten pro Jahr.
 +
 +
== Verfügbarkeitslevel ==
 +
 +
Die Verfügbarkeit eines Systems wird üblicherweise in "Neunen" gemessen:
 +
 +
{| class="wikitable"
 +
|-
 +
! Bezeichnung !! Verfügbarkeit !! Max. Ausfallzeit pro Jahr !! Max. Ausfallzeit pro Monat !! Typischer Einsatz
 +
|-
 +
| '''One Nine''' || 90 % || 36,5 Tage || 72 Stunden || Unwichtige interne Systeme
 +
|-
 +
| '''Two Nines''' || 99 % || 3,65 Tage || 7,2 Stunden || Einfache Bürosysteme
 +
|-
 +
| '''Three Nines''' || 99,9 % || 8,76 Stunden || 43,8 Minuten || Geschäftskritische Anwendungen
 +
|-
 +
| '''Four Nines''' || 99,99 % || 52,6 Minuten || 4,38 Minuten || E-Commerce, Datenbanken
 +
|-
 +
| '''Five Nines''' || 99,999 % || 5,26 Minuten || 25,9 Sekunden || Telekommunikation, Finanzsektor
 +
|-
 +
| '''Six Nines''' || 99,9999 % || 31,5 Sekunden || 2,6 Sekunden || Lebenskritische Systeme (z.B. Medizintechnik)
 +
|}
 +
 +
'''Wichtig:''' Jede zusätzliche "Neun" wird '''exponentiell teurer und komplexer'''. Der Sprung von 99,9 % auf 99,99 % erfordert oft eine komplett andere Architektur – redundante Hardware, redundante Netzwerkanbindung, redundanter Storage, automatisiertes Failover, und regelmäßige Tests.
 +
 +
== Was gehört alles zu HA? ==
 +
 +
Hochverfügbarkeit ist '''kein einzelnes Feature''', sondern ein Zusammenspiel vieler Komponenten:
 +
 +
=== Redundanz der Hardware ===
 +
 +
* '''Redundante Netzteile''' – doppelte Stromversorgung pro Server, idealerweise an getrennten Stromkreisen/USVs
 +
* '''RAID oder verteilter Storage''' – Festplattenausfälle werden transparent abgefangen
 +
* '''Redundante Netzwerkanbindung''' – mehrere NICs, ggf. an verschiedene Switches (NIC-Bonding/Teaming)
 +
* '''Redundante Knoten''' – mindestens 3 Knoten, damit bei Ausfall eines Knotens Quorum erhalten bleibt
 +
 +
=== Redundanz der Software/Services ===
 +
 +
* '''Cluster-Software''' – wie [[#Corosync bei Proxmox VE|Corosync]] zur Überwachung und Koordination
 +
* '''Automatisches Failover''' – VMs werden bei Knotenausfall automatisch auf anderen Knoten neu gestartet
 +
* '''Fencing''' – ein ausgefallener Knoten wird aktiv "abgeschossen" (z.B. über IPMI/iLO/iDRAC), damit er nicht als Zombie weiterläuft und Split-Brain verursacht
 +
* '''Shared Storage''' – alle Knoten müssen auf dieselben VM-Festplatten zugreifen können, damit VMs auf einem anderen Knoten gestartet werden können
 +
 +
=== Redundanz der Infrastruktur ===
 +
 +
* '''Redundante Internetanbindung''' – mehrere ISPs oder Leitungen
 +
* '''USV (Unterbrechungsfreie Stromversorgung)''' – überbrückt Stromausfälle
 +
* '''Geographische Redundanz''' – Standorte an verschiedenen Orten (schützt vor Feuer, Überschwemmung etc.)
 +
 +
=== Organisatorische Maßnahmen ===
 +
 +
* '''Monitoring''' – ständige Überwachung aller Komponenten (z.B. mit Zabbix, CheckMK, Wazuh)
 +
* '''Backup-Strategie''' – HA schützt vor Hardwareausfällen, aber '''nicht''' vor Datenverlust durch Fehlbedienung, Ransomware oder logischen Fehlern. Backups sind auch mit HA '''unverzichtbar'''.
 +
* '''Regelmäßige Failover-Tests''' – HA, das nie getestet wurde, funktioniert im Ernstfall oft nicht
 +
* '''Dokumentation''' – was passiert bei welchem Ausfall, wer ist zuständig, welche Schritte sind nötig
 +
 +
== HA bei Proxmox VE ==
 +
 +
Bei Proxmox VE setzt HA auf dem [[#Corosync bei Proxmox VE|Corosync-Cluster]] auf. VMs und Container werden als '''HA-Ressourcen''' markiert und HA-Gruppen zugeordnet, die festlegen, auf welchen Knoten sie bevorzugt laufen sollen.
 +
 +
Der Ablauf bei einem Knotenausfall:
 +
 +
# Corosync erkennt über den [[#Totem-Protokoll – Funktionsweise im Detail|Token-Ring]], dass ein Knoten nicht mehr antwortet
 +
# Das Quorum wird neu berechnet
 +
# Falls Quorum vorhanden: Der '''Cluster Resource Manager (pve-ha-crm)''' ordnet die betroffenen HA-VMs einem anderen Knoten zu
 +
# Optional: '''Fencing''' – der ausgefallene Knoten wird per IPMI/iDRAC/iLO zwangsweise ausgeschaltet
 +
# Der '''Local Resource Manager (pve-ha-lrm)''' auf dem Zielknoten startet die VMs neu
 +
 +
'''Voraussetzung:''' Shared Storage. Die VM-Festplatten müssen auf einem Storage liegen, das von allen Knoten erreichbar ist (z.B. Ceph, NFS, iSCSI). Ohne Shared Storage kann kein Failover stattfinden, da der Zielknoten keinen Zugriff auf die Daten der VM hätte.
 +
 +
----
 +
 
= Corosync bei Proxmox VE =
 
= Corosync bei Proxmox VE =
  
 
== Grundprinzip ==
 
== 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.
+
Corosync ist das '''Cluster-Kommunikations-Framework''', das Proxmox VE für seinen HA-Cluster nutzt. Es bildet zusammen mit dem '''Proxmox Cluster File System ([[#Proxmox Cluster File System (pmxcfs)|pmxcfs]])''' das Rückgrat der Cluster-Kommunikation.
  
 
== Kernfunktionen ==
 
== 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 ===
 
=== Quorum / Abstimmung ===
Zeile 18: Zeile 190:
  
 
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.
 
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.
 +
 +
== Totem-Protokoll – Funktionsweise im Detail ==
 +
 +
Das Totem-Protokoll (vollständig: '''Totem Single Ring Ordering and Membership Protocol''') ist der Kern der Corosync-Kommunikation.
 +
 +
=== Der virtuelle Ring ===
 +
 +
Alle Knoten im Cluster werden logisch in einem '''Ring''' angeordnet. Bei einem 3-Node-Cluster sieht das so aus:
 +
 +
<pre>
 +
    Node A
 +
  ↗      ↘
 +
Node C ← Node B
 +
</pre>
 +
 +
Ein spezielles Nachrichtenpaket – das '''Token''' – kreist ständig im Ring von Knoten zu Knoten. '''Nur der Knoten, der gerade das Token hält, darf Nachrichten senden.''' Danach gibt er das Token an den nächsten Knoten weiter.
 +
 +
=== Warum ein Token? ===
 +
 +
Das löst ein fundamentales Problem in verteilten Systemen: '''Nachrichtenordnung'''. Wenn alle Knoten gleichzeitig senden dürften, müsste man nachträglich sortieren, welche Nachricht zuerst kam. Durch das Token ist die Reihenfolge automatisch garantiert – wer das Token hat, sendet, alle anderen empfangen. So sehen alle Knoten alle Nachrichten in '''exakt derselben Reihenfolge'''.
 +
 +
=== Total Order Multicast ===
 +
 +
Das entscheidende Feature heißt '''Total Order Multicast''': Jede Nachricht, die über den Ring gesendet wird, kommt bei allen Knoten in derselben Reihenfolge an. Das ist die Grundlage dafür, dass [[#Proxmox Cluster File System (pmxcfs)|pmxcfs]] funktioniert – wenn zwei Admins gleichzeitig auf zwei verschiedenen Knoten eine Config ändern, sorgt das Totem-Protokoll dafür, dass beide Änderungen in einer klar definierten Reihenfolge auf allen Knoten ankommen. Kein Konflikt, keine Race Condition.
 +
 +
=== Token-Timeout und Ausfallerkennung ===
 +
 +
Das Token hat einen '''Timeout''' (bei Proxmox standardmäßig ca. 1 Sekunde, konfigurierbar in der <code>corosync.conf</code> als <code>token</code>-Wert in Millisekunden).
 +
 +
Der Ablauf bei einem Knotenausfall:
 +
 +
# Node A gibt das Token an Node B weiter
 +
# Node B sollte das Token innerhalb des Timeouts an Node C weitergeben
 +
# '''Node B antwortet nicht''' → Token-Timeout läuft ab
 +
# Node A erkennt: "Node B hat das Token nicht weitergegeben"
 +
# Es wird ein '''Reconfiguration-Prozess''' ausgelöst
 +
# Node B wird aus dem Ring entfernt, der Ring wird neu gebildet: <code>Node A ↔ Node C</code>
 +
# Das '''Quorum wird neu berechnet''' – hat der verbleibende Ring noch genug Stimmen?
 +
 +
=== Consensus-Timeout ===
 +
 +
Neben dem Token-Timeout gibt es den '''Consensus-Timeout'''. Das ist die Zeit, die der Cluster den Knoten gibt, sich auf eine neue Ring-Konfiguration zu einigen, nachdem ein Ausfall erkannt wurde. Erst wenn sich alle verbleibenden Knoten einig sind ("ja, Node B ist weg, wir sind jetzt zu zweit"), wird der neue Ring aktiv.
 +
 +
=== Zusammenfassung des Token-Ring-Ablaufs ===
 +
 +
<pre>
 +
Token kreist im Ring:  A → B → C → A → B → C → ...
 +
                      ↑
 +
                  Nur wer das Token hat, darf senden.
 +
                  Alle anderen empfangen.
 +
                  → Garantierte Nachrichtenreihenfolge.
 +
 +
Token bleibt aus:      A → B → ✗ (Timeout!)
 +
                      ↑
 +
                  Ring-Reconfiguration.
 +
                  B wird entfernt.
 +
                  Neuer Ring: A → C → A → C → ...
 +
                  Quorum-Neuberechnung.
 +
</pre>
  
 
== Netzwerkkonfiguration ==
 
== Netzwerkkonfiguration ==
Zeile 36: Zeile 267:
 
== Konfigurationsdatei ==
 
== Konfigurationsdatei ==
  
−
Die zentrale Konfigurationsdatei liegt unter <code>/etc/pve/corosync.conf</code> und wird über pmxcfs automatisch auf alle Knoten synchronisiert. Sie enthält:
+
Die zentrale Konfigurationsdatei liegt unter <code>/etc/pve/corosync.conf</code> und wird über [[#Proxmox Cluster File System (pmxcfs)|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
 
* '''Knoten-IDs und Adressen''' – welche Knoten zum Cluster gehören und über welche IPs sie erreichbar sind
Zeile 178: Zeile 409:
  
 
Bei einer TrueNAS-basierten Storage-Lösung wäre eine solche Heartbeat-SR typischerweise eine kleine iSCSI-LUN auf dem TrueNAS.
 
Bei einer TrueNAS-basierten Storage-Lösung wäre eine solche Heartbeat-SR typischerweise eine kleine iSCSI-LUN auf dem TrueNAS.
 +
 +
----
 +
 +
= 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.
 +
|}

Version vom 13. Februar 2026, 06:24 Uhr

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:

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:

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

Was ist ein Cluster?

Ein Cluster ist ein Verbund aus mehreren Servern (Knoten/Nodes), die zusammenarbeiten und nach außen wie ein einziges System erscheinen. Die Knoten kommunizieren untereinander über ein Netzwerk und koordinieren sich, um gemeinsam Aufgaben zu erfüllen.

Ein Cluster ist nicht einfach "mehrere Server im selben Netzwerk". Der entscheidende Unterschied ist, dass die Knoten voneinander wissen, sich gegenseitig überwachen und gemeinsam Entscheidungen treffen – z.B. welcher Knoten welche VM betreibt, oder was passiert, wenn ein Knoten ausfällt.

Warum braucht man einen Cluster?

Ein einzelner Server hat immer eine Schwachstelle: Fällt er aus, ist alles weg. Egal wie gut die Hardware ist – jeder Server kann ausfallen (Netzteil, Mainboard, Stromausfall, Kernel-Panic). Ein Cluster löst dieses Problem, indem die Last auf mehrere Knoten verteilt wird und bei einem Ausfall andere Knoten übernehmen können.

Weitere Gründe:

  • Zentrale Verwaltung: Alle Knoten werden über eine gemeinsame Oberfläche verwaltet, statt sich auf jeden Server einzeln einzuloggen.
  • Gemeinsame Konfiguration: Änderungen (z.B. Storage, Firewall, Benutzer) werden automatisch auf alle Knoten synchronisiert.
  • Live-Migration: VMs können im laufenden Betrieb zwischen Knoten verschoben werden – z.B. für Wartungsarbeiten an einem Host.
  • Skalierbarkeit: Neue Knoten können zum Cluster hinzugefügt werden, um mehr Kapazität zu erhalten.

Cluster-Typen

Typ Beschreibung Beispiel
Compute-Cluster Mehrere Knoten berechnen gemeinsam eine Aufgabe (z.B. wissenschaftliche Simulationen). HPC-Cluster, Beowulf-Cluster
Load-Balancing-Cluster Eingehende Anfragen werden auf mehrere Knoten verteilt, um Last zu verteilen. Webserver-Cluster mit HAProxy oder Nginx
High-Availability-Cluster Der Fokus liegt auf Ausfallsicherheit: Fällt ein Knoten aus, übernimmt ein anderer. Proxmox HA, XCP-ng HA, Pacemaker
Storage-Cluster Mehrere Knoten stellen gemeinsam Speicher bereit (verteilt oder repliziert). Ceph, GlusterFS, TrueNAS HA

Proxmox-Cluster sind primär High-Availability-Cluster, können aber durch Ceph-Integration auch gleichzeitig als Storage-Cluster fungieren.

Cluster ≠ High Availability

Ein sehr wichtiger Punkt: Ein Cluster ist nicht automatisch hochverfügbar. Ein Proxmox-Cluster mit 3 Knoten bietet zunächst nur:

  • Zentrale Verwaltung über eine Weboberfläche
  • Synchronisierte Konfiguration via pmxcfs
  • Die Möglichkeit zur Live-Migration von VMs

Aber: Fällt ein Knoten aus, passiert ohne explizit aktiviertes HA gar nichts – die VMs auf dem ausgefallenen Knoten bleiben einfach weg. Erst wenn man HA aktiviert und VMs als HA-Ressourcen konfiguriert, werden sie bei einem Knotenausfall automatisch auf einen anderen Knoten neu gestartet.

Das heißt:

  • Cluster ohne HA: Gemeinsame Verwaltung, manuelle Migration, kein automatisches Failover
  • Cluster mit HA: Gemeinsame Verwaltung, automatisches Failover bei Knotenausfall

High Availability (HA)

Was ist High Availability?

High Availability (Hochverfügbarkeit) bedeutet, dass ein System so aufgebaut ist, dass es auch bei Ausfällen einzelner Komponenten weiter funktioniert. Das Ziel ist, Ausfallzeiten zu minimieren – idealerweise auf wenige Sekunden oder Minuten pro Jahr.

Verfügbarkeitslevel

Die Verfügbarkeit eines Systems wird üblicherweise in "Neunen" gemessen:

Bezeichnung Verfügbarkeit Max. Ausfallzeit pro Jahr Max. Ausfallzeit pro Monat Typischer Einsatz
One Nine 90 % 36,5 Tage 72 Stunden Unwichtige interne Systeme
Two Nines 99 % 3,65 Tage 7,2 Stunden Einfache Bürosysteme
Three Nines 99,9 % 8,76 Stunden 43,8 Minuten Geschäftskritische Anwendungen
Four Nines 99,99 % 52,6 Minuten 4,38 Minuten E-Commerce, Datenbanken
Five Nines 99,999 % 5,26 Minuten 25,9 Sekunden Telekommunikation, Finanzsektor
Six Nines 99,9999 % 31,5 Sekunden 2,6 Sekunden Lebenskritische Systeme (z.B. Medizintechnik)

Wichtig: Jede zusätzliche "Neun" wird exponentiell teurer und komplexer. Der Sprung von 99,9 % auf 99,99 % erfordert oft eine komplett andere Architektur – redundante Hardware, redundante Netzwerkanbindung, redundanter Storage, automatisiertes Failover, und regelmäßige Tests.

Was gehört alles zu HA?

Hochverfügbarkeit ist kein einzelnes Feature, sondern ein Zusammenspiel vieler Komponenten:

Redundanz der Hardware

  • Redundante Netzteile – doppelte Stromversorgung pro Server, idealerweise an getrennten Stromkreisen/USVs
  • RAID oder verteilter Storage – Festplattenausfälle werden transparent abgefangen
  • Redundante Netzwerkanbindung – mehrere NICs, ggf. an verschiedene Switches (NIC-Bonding/Teaming)
  • Redundante Knoten – mindestens 3 Knoten, damit bei Ausfall eines Knotens Quorum erhalten bleibt

Redundanz der Software/Services

  • Cluster-Software – wie Corosync zur Überwachung und Koordination
  • Automatisches Failover – VMs werden bei Knotenausfall automatisch auf anderen Knoten neu gestartet
  • Fencing – ein ausgefallener Knoten wird aktiv "abgeschossen" (z.B. über IPMI/iLO/iDRAC), damit er nicht als Zombie weiterläuft und Split-Brain verursacht
  • Shared Storage – alle Knoten müssen auf dieselben VM-Festplatten zugreifen können, damit VMs auf einem anderen Knoten gestartet werden können

Redundanz der Infrastruktur

  • Redundante Internetanbindung – mehrere ISPs oder Leitungen
  • USV (Unterbrechungsfreie Stromversorgung) – überbrückt Stromausfälle
  • Geographische Redundanz – Standorte an verschiedenen Orten (schützt vor Feuer, Überschwemmung etc.)

Organisatorische Maßnahmen

  • Monitoring – ständige Überwachung aller Komponenten (z.B. mit Zabbix, CheckMK, Wazuh)
  • Backup-Strategie – HA schützt vor Hardwareausfällen, aber nicht vor Datenverlust durch Fehlbedienung, Ransomware oder logischen Fehlern. Backups sind auch mit HA unverzichtbar.
  • Regelmäßige Failover-Tests – HA, das nie getestet wurde, funktioniert im Ernstfall oft nicht
  • Dokumentation – was passiert bei welchem Ausfall, wer ist zuständig, welche Schritte sind nötig

HA bei Proxmox VE

Bei Proxmox VE setzt HA auf dem Corosync-Cluster auf. VMs und Container werden als HA-Ressourcen markiert und HA-Gruppen zugeordnet, die festlegen, auf welchen Knoten sie bevorzugt laufen sollen.

Der Ablauf bei einem Knotenausfall:

  1. Corosync erkennt über den Token-Ring, dass ein Knoten nicht mehr antwortet
  2. Das Quorum wird neu berechnet
  3. Falls Quorum vorhanden: Der Cluster Resource Manager (pve-ha-crm) ordnet die betroffenen HA-VMs einem anderen Knoten zu
  4. Optional: Fencing – der ausgefallene Knoten wird per IPMI/iDRAC/iLO zwangsweise ausgeschaltet
  5. Der Local Resource Manager (pve-ha-lrm) auf dem Zielknoten startet die VMs neu

Voraussetzung: Shared Storage. Die VM-Festplatten müssen auf einem Storage liegen, das von allen Knoten erreichbar ist (z.B. Ceph, NFS, iSCSI). Ohne Shared Storage kann kein Failover stattfinden, da der Zielknoten keinen Zugriff auf die Daten der VM hätte.

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

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.

Totem-Protokoll – Funktionsweise im Detail

Das Totem-Protokoll (vollständig: Totem Single Ring Ordering and Membership Protocol) ist der Kern der Corosync-Kommunikation.

Der virtuelle Ring

Alle Knoten im Cluster werden logisch in einem Ring angeordnet. Bei einem 3-Node-Cluster sieht das so aus: 

    Node A
   ↗      ↘
Node C ← Node B

Ein spezielles Nachrichtenpaket – das Token – kreist ständig im Ring von Knoten zu Knoten. Nur der Knoten, der gerade das Token hält, darf Nachrichten senden. Danach gibt er das Token an den nächsten Knoten weiter.

Warum ein Token?

Das löst ein fundamentales Problem in verteilten Systemen: Nachrichtenordnung. Wenn alle Knoten gleichzeitig senden dürften, müsste man nachträglich sortieren, welche Nachricht zuerst kam. Durch das Token ist die Reihenfolge automatisch garantiert – wer das Token hat, sendet, alle anderen empfangen. So sehen alle Knoten alle Nachrichten in exakt derselben Reihenfolge.

Total Order Multicast

Das entscheidende Feature heißt Total Order Multicast: Jede Nachricht, die über den Ring gesendet wird, kommt bei allen Knoten in derselben Reihenfolge an. Das ist die Grundlage dafür, dass pmxcfs funktioniert – wenn zwei Admins gleichzeitig auf zwei verschiedenen Knoten eine Config ändern, sorgt das Totem-Protokoll dafür, dass beide Änderungen in einer klar definierten Reihenfolge auf allen Knoten ankommen. Kein Konflikt, keine Race Condition.

Token-Timeout und Ausfallerkennung

Das Token hat einen Timeout (bei Proxmox standardmäßig ca. 1 Sekunde, konfigurierbar in der corosync.conf als token-Wert in Millisekunden).

Der Ablauf bei einem Knotenausfall:

  1. Node A gibt das Token an Node B weiter
  2. Node B sollte das Token innerhalb des Timeouts an Node C weitergeben
  3. Node B antwortet nicht → Token-Timeout läuft ab
  4. Node A erkennt: "Node B hat das Token nicht weitergegeben"
  5. Es wird ein Reconfiguration-Prozess ausgelöst
  6. Node B wird aus dem Ring entfernt, der Ring wird neu gebildet: Node A ↔ Node C
  7. Das Quorum wird neu berechnet – hat der verbleibende Ring noch genug Stimmen?

Consensus-Timeout

Neben dem Token-Timeout gibt es den Consensus-Timeout. Das ist die Zeit, die der Cluster den Knoten gibt, sich auf eine neue Ring-Konfiguration zu einigen, nachdem ein Ausfall erkannt wurde. Erst wenn sich alle verbleibenden Knoten einig sind ("ja, Node B ist weg, wir sind jetzt zu zweit"), wird der neue Ring aktiv.

Zusammenfassung des Token-Ring-Ablaufs

Token kreist im Ring:  A → B → C → A → B → C → ...
                       ↑
                  Nur wer das Token hat, darf senden.
                  Alle anderen empfangen.
                  → Garantierte Nachrichtenreihenfolge.

Token bleibt aus:      A → B → ✗ (Timeout!)
                       ↑
                  Ring-Reconfiguration.
                  B wird entfernt.
                  Neuer Ring: A → C → A → C → ...
                  Quorum-Neuberechnung.

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.

Glossar

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 /etc/pve, 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.
Abgerufen von „http://wiki.ixheim.de/index.php?title=Proxmox_Cluster&oldid=66852“