Mehrere Nodes zu einem Verbund – Grundlage für HA und Live-Migration
Was ist ein Cluster?
Mehrere Nodes, eine gemeinsame Verwaltung über eine einzige Web-GUI – egal, an welchem Node man sich anmeldet, man sieht immer den ganzen Cluster
Gemeinsame Konfiguration liegt unter /etc/pve – kein normales Verzeichnis, sondern die Proxmox Cluster File System (pmxcfs), eine Fuse-Datenbank, die über Corosync in Echtzeit auf alle Nodes repliziert wird
Beitritt per pvecm add <ip-des-ersten-nodes> auf der Kommandozeile oder per Klick im Web-Interface – Proxmox tauscht dabei automatisch die nötigen SSH-Schlüssel zwischen den Nodes aus
Voraussetzung für Live-Migration und Hochverfügbarkeit – ohne Cluster-Verbund bleibt jeder Node eine Insel für sich, mit eigener Konfiguration und eigenem VM-Bestand
Empfohlene Obergrenze liegt bei etwa 32 Nodes je Cluster; mehr ist technisch möglich, verlangt dann aber ein sauber geplantes, latenzarmes Corosync-Netz
Diese clusterweite Sicht gilt auch für den Konsolenzugriff: Web-GUI und API kennen alle Nodes und proxyen eine noVNC-/SPICE-Verbindung automatisch zu dem Node, auf dem die jeweilige VM tatsächlich läuft – ein Login an einem beliebigen Node genügt für den Zugriff auf alle VMs im Cluster
Nach einer Live-Migration ändert sich am Zugriffsweg nichts: die Konsole „folgt" der VM automatisch zum neuen Node, weil jeder Node denselben, über pmxcfs synchronisierten Cluster-Zustand kennt – Details und Voraussetzungen dazu in Modul 1 – Grundlagen & Architektur
Synchronisierte Uhrzeit auf allen Nodes ist Pflicht, z. B. per chrony oder systemd-timesyncd – schon eine Abweichung von wenigen Sekunden kann bei Corosync und dem Cluster-Dateisystem zu unnötigen Fehlalarmen und Konfigurationskonflikten führen.
🎧 Block 1: Cluster & Quorum-Grundlagen
Corosync & Quorum
Corosync ist der Herzschlag-Dienst: über das Totem-Protokoll tauschen alle Nodes ständig Status-Pakete aus, standardmäßig über den modernen knet-Transport (Nachfolger von klassischem UDP-Multicast)
Konfiguriert wird das in /etc/pve/corosync.conf – Werte wie token (Timeout, bis ein Node als tot gilt, Standard 1000 ms) und expected_votes stehen genau hier
Quorum: die Mehrheit der Stimmen muss sich einig sein, bevor VMs gestartet, gestoppt oder verschoben werden – jeder Node bringt in der Standardkonfiguration eine Stimme mit
Zuständig dafür ist votequorum, ein Bestandteil von Corosync – Status jederzeit einsehbar per pvecm status
Verhindert widersprüchliche Entscheidungen bei Netzproblemen: ohne Mehrheit verweigert der Cluster riskante Aktionen, statt zu raten und im Zweifel falsch zu handeln
Mit pvecm status sieht man auf einen Blick, wie viele Stimmen aktuell vorhanden sind, wie viele für Quorum nötig sind und ob der Cluster gerade quorat ist – der erste Befehl bei jedem Cluster-Problem.
Wie viele Nodes?
Mindestens drei Nodes für ein sicheres Quorum – bei drei Stimmen sind zwei für die Mehrheit nötig (floor(3/2)+1 = 2), der Cluster verkraftet also genau einen Node-Ausfall
Fünf Nodes verkraften zwei gleichzeitige Ausfälle, sieben Nodes drei – die Ausfalltoleranz wächst mit jeder zusätzlichen Zweiergruppe an Nodes
Alternativ zwei Nodes plus QDevice als dritte, „leichte" Stimme: corosync-qnetd läuft auf einem externen Gerät, corosync-qdevice auf beiden Cluster-Nodes
Ungerade Stimmenzahl wird bevorzugt – vermeidet Patt-Situationen wie 2 zu 2 bei vier Nodes, bei denen keine Seite eine Mehrheit erreicht
Zwei Nodes ganz ohne dritte Stimme sind für Testbetrieb in Ordnung, für Hochverfügbarkeit aber ungeeignet: fällt einer aus, steht es 1:1, und der verbleibende Node bekommt kein Quorum
Für das KMU-Referenz-Szenario dieses Lernbereichs (1–2 Nodes, siehe Modul 0) ist zwei Nodes plus QDevice damit fast immer die richtige Zielgröße – drei echte Nodes lohnen sich meist erst, wenn ohnehin mehr Rechenleistung gebraucht wird
🎧 Block 2: Wie viele Nodes?
Best Practice 2-Node-Setup
QDevice (z. B. auf NAS, Mini-PC oder einem Raspberry-Pi-Klasse-Gerät) ist zwingend – ohne dritte Stimme bleibt der 2-Node-Cluster für HA unbrauchbar
Einrichtung in zwei Schritten: apt install corosync-qnetd auf dem externen Gerät, danach pvecm qdevice setup <ip-des-qnetd> auf einem der beiden Cluster-Nodes – Proxmox verteilt die Konfiguration automatisch an beide Nodes
Der QDevice selbst hostet keine VMs und trägt keine Nutzlast, er beantwortet im Zweifel nur die Quorum-Abstimmung – entsprechend genügt sehr bescheidene Hardware
Wichtig für die Platzierung: möglichst eigene Stromversorgung und eigener Netzwerk-Switch – sonst reißt ein einzelner Stromausfall Node und QDevice gleichzeitig weg, und die dritte Stimme nützt nichts
Zwei Nodes allein ergeben kein sicheres Quorum: bei Ausfall eines Node steht es 1:1, keine Mehrheit, HA-Ressourcen bleiben eingefroren statt automatisch umzuziehen
Damit wird das Setup erst richtig HA-fähig für KMU – bei überschaubaren Zusatzkosten für ein einziges kleines QDevice-Gerät
🎧 Block 3: Best Practice 2-Node
Dediziertes Corosync-Netz
Eigene NIC (oder zumindest ein eigenes VLAN) für Corosync, mit niedriger und vor allem konstanter Latenz – Corosync reagiert empfindlicher auf Latenz-Spitzen als auf die absolute Bandbreite
Getrennt vom Storage- und Nutzverkehr, idealerweise auch vom Migrations- und Backup-Netz – ein sättigender Backup-Job auf derselben Leitung kann Herzschläge spürbar verzögern
Corosync unterstützt redundante Links über mehrere Ringe (knet) – ein zweites, physisch getrenntes Netz für Corosync selbst erhöht die Ausfallsicherheit der Cluster-Kommunikation nochmal zusätzlich
Verhindert Cluster-Zittern unter Last: wird das token-Timeout (Standard 1000 ms) wiederholt überschritten, stuft der Cluster einen eigentlich gesunden, nur überlasteten Node fälschlich als tot ein
Praxiswert: deutlich unter 2 ms Round-Trip-Zeit gilt als komfortabel – über WAN-Strecken oder stark ausgelastete Switches wird Corosync schnell nervös und meldet Fehlalarme
🎧 Block 4: Corosync-Netz, Split-Brain & Fencing
Split-Brain & Fencing
Fencing/Watchdog verhindert doppelten VM-Start bei Split-Brain – Proxmox setzt dabei standardmäßig auf einen Software-Watchdog (Kernel-Modul softdog, Gerät /dev/watchdog) statt auf klassisches externes IPMI-Fencing
Das Prinzip ist „Selbst-Fencing": verliert ein Node das Quorum, füttert der watchdog-mux-Dienst den Watchdog-Timer nicht mehr weiter – nach spätestens rund 60 Sekunden löst die Hardware einen harten Reset dieses Nodes aus, ganz ohne Eingriff eines anderen Nodes
Der spezielle two_node-Modus (kombiniert mit wait_for_all in corosync.conf) ist nur ohne echte HA vertretbar – er erzwingt Quorum bereits bei zwei Stimmen und wäre bei aktivem HA-Manager ein Split-Brain-Risiko
Sicherheit vor Datenchaos hat Vorrang vor Weiterlaufen um jeden Preis: lieber ein Node kontrolliert per Watchdog-Reset aus dem Rennen nehmen, als riskieren, dass zwei Nodes gleichzeitig auf dieselbe VM-Disk schreiben
Ohne funktionierenden Watchdog im Server (BMC/IPMI-Reset oder Software-Watchdog) startet der HA-Stack aus Sicherheitsgründen erst gar nicht – Fencing ist keine Option, sondern Voraussetzung
