Proxmox Cluster

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.