Proxmox Cluster – der vollständige Guide Drucken

Wer mehrere Proxmox-Server betreibt, stößt früher oder später auf das Thema Cluster. Dabei geht es zunächst gar nicht zwingend um Hochverfügbarkeit oder verteilten Storage. Schon die gemeinsame Verwaltung mehrerer Hosts und die Möglichkeit, virtuelle Maschinen zwischen den Systemen zu verschieben, machen einen Cluster interessant.

Mit zunehmender Größe kommen allerdings weitere Themen hinzu: Quorum, Corosync, Ceph, High Availability und die Frage, wie sich ein Ausfall einzelner Nodes auf den Cluster auswirkt.

In diesem Guide geben wir einen Überblick über die wichtigsten Bausteine eines Proxmox-Clusters. Die einzelnen Themen behandeln wir zusätzlich in separaten Anleitungen, damit dieser Artikel nicht zu einer Sammlung aus hundert einzelnen Kommandos wird.

Was ist ein Proxmox Cluster?

Ein Proxmox-Cluster verbindet mehrere Proxmox-VE-Hosts zu einer gemeinsamen Verwaltungsumgebung.

Die einzelnen Server werden dabei als Nodes bezeichnet. Jeder Node bleibt ein eigenständiger Proxmox-Server, ist nach dem Beitritt zum Cluster aber Teil einer gemeinsamen Konfiguration.

Das bringt unter anderem folgende Vorteile:

• zentrale Verwaltung aller Nodes über eine Weboberfläche
• gemeinsame Cluster-Konfiguration
• Migration von virtuellen Maschinen und Containern zwischen Hosts
• clusterweite Firewall- und Berechtigungskonzepte
• Grundlage für High Availability
• Möglichkeit, verteilten Storage wie Ceph aufzubauen

Proxmox verwendet für die Kommunikation zwischen den Nodes Corosync. Die Cluster-Konfiguration wird über das Proxmox Cluster File System pmxcfs zwischen den Nodes verteilt. Proxmox VE

Ein Cluster bedeutet allerdings nicht automatisch, dass virtuelle Maschinen hochverfügbar sind. Das ist ein häufiger Irrtum.

Ein einfacher Zwei- oder Drei-Node-Cluster ermöglicht zunächst vor allem die gemeinsame Verwaltung. Für echte Hochverfügbarkeit müssen zusätzliche Voraussetzungen erfüllt sein.

Wie viele Nodes braucht ein Proxmox Cluster?

Technisch lässt sich bereits mit zwei Proxmox-Hosts ein Cluster aufbauen.

Für produktive Umgebungen ist die Anzahl der Nodes allerdings eng mit dem Thema Quorum verbunden.

Ein Cluster muss jederzeit entscheiden können, welcher Teil des Clusters noch gültig ist. Dafür verwendet Proxmox ein Mehrheitsprinzip.

Bei drei Nodes ist das einfach:

Node 1 ─┐
Node 2 ─┼── Quorum
Node 3 ─┘

Fällt ein Node aus, besitzen die beiden verbleibenden Nodes weiterhin die Mehrheit.

Bei einem Cluster mit nur zwei Nodes entsteht dagegen ein Problem:

Node 1      Node 2
   │           │
   └──── X ────┘

Wenn die Verbindung zwischen beiden Hosts ausfällt, kann keiner der beiden Nodes sicher feststellen, ob der jeweils andere Node ausgefallen oder lediglich nicht mehr erreichbar ist.

Für kleinere Zwei-Node-Cluster kann deshalb ein QDevice eingesetzt werden, das eine zusätzliche Stimme bereitstellt. Proxmox empfiehlt für zuverlässiges Quorum insbesondere bei HA-Konfigurationen mindestens drei Stimmen beziehungsweise Nodes; für Zwei-Node-Cluster ist ein QDevice eine mögliche Lösung. Proxmox VE

Dieses Thema behandeln wir ausführlicher in unserem Artikel:

→ Proxmox Cluster mit 2 Nodes: Quorum, QDevice und Best Practices

Wie wird ein Proxmox Cluster aufgebaut?

Der grundsätzliche Ablauf ist überschaubar.

Zunächst werden alle Proxmox-Nodes unabhängig voneinander installiert und vollständig konfiguriert. Anschließend wird auf einem der Hosts ein neuer Cluster erstellt.

Die weiteren Nodes treten diesem Cluster danach bei.

Vereinfacht sieht das so aus:

Proxmox Node 1
      │
      │ Cluster erstellen
      ▼
   Cluster
      ▲
      │
 ┌────┴─────┐
 │          │
Node 2     Node 3
beitreten  beitreten

In der Praxis sollte man sich vor dem Erstellen des Clusters allerdings etwas mehr Zeit nehmen.

Insbesondere Hostnamen, IP-Adressen und das Netzwerk sollten bereits endgültig feststehen. Proxmox weist ausdrücklich darauf hin, dass Nodes vor dem Clusteraufbau mit ihrer finalen Hostname- und IP-Konfiguration eingerichtet werden sollten. Proxmox VE

Die eigentliche Einrichtung beschreiben wir separat:

→ Proxmox Cluster erstellen – Schritt-für-Schritt-Anleitung

Das Cluster-Netzwerk ist wichtiger, als es zunächst aussieht

Einer der häufigsten Fehler bei Cluster-Testumgebungen ist, sämtliche Kommunikation über dasselbe Netzwerk laufen zu lassen.

Das kann beispielsweise bedeuten:

Management
VM-Traffic
Storage
Backup
Corosync

alles über eine einzelne Verbindung.

Für kleine Testumgebungen kann das funktionieren. In einer produktiven Installation sollte man das Cluster-Netzwerk aber bewusst planen.

Corosync benötigt vergleichsweise wenig Bandbreite, reagiert dafür empfindlich auf hohe oder stark schwankende Latenzen. Proxmox empfiehlt deshalb ein separates physisches Netzwerk beziehungsweise eine eigene Netzwerkkarte für die Cluster-Kommunikation. Eine dedizierte 1-Gbit-Verbindung reicht in vielen Szenarien bereits aus. Proxmox VE

Ein typischer Aufbau könnte beispielsweise so aussehen:

                ┌─────────────────────┐
                │     Proxmox Node    │
                └─────────────────────┘
                     │      │      │
                     │      │      │
             Management   Corosync  Storage
                 │          │         │
              vmbr0      eigenes    Ceph /
                          Netz       Storage

Bei größeren oder produktiven Clustern sollte auch die Cluster-Kommunikation redundant ausgelegt werden.

Corosync kann mehrere Links verwenden und bei Ausfall eines Netzwerkpfades auf einen anderen wechseln. Proxmox VE

Was macht Corosync eigentlich?

Corosync bildet gewissermaßen das Kommunikationssystem des Clusters.

Die Nodes tauschen darüber Informationen aus und stellen fest, welche Systeme aktuell erreichbar sind.

Dabei geht es unter anderem um Fragen wie:

• Welche Nodes gehören zum Cluster?
• Welche Nodes sind erreichbar?
• Besitzt der Cluster noch Quorum?
• Ist ein Node ausgefallen?
• Welche Cluster-Konfiguration ist aktuell?

Corosync selbst benötigt keine enorme Bandbreite. Viel wichtiger ist eine stabile Verbindung mit möglichst geringer Latenz.

Genau deshalb sollte Cluster-Traffic nicht ohne weiteres mit stark ausgelastetem Storage- oder Backup-Traffic auf derselben Verbindung konkurrieren.

→ Corosync in Proxmox erklärt: Kommunikation, Quorum und Cluster-Netzwerk

Was bedeutet Quorum?

Das Quorum gehört zu den wichtigsten Konzepten eines Clusters.

Vereinfacht gesagt entscheidet das Quorum, ob ein Teil des Clusters noch die Mehrheit besitzt und somit Änderungen an der Cluster-Konfiguration durchführen darf.

Das verhindert sogenannte Split-Brain-Situationen.

Ein Beispiel:

        Netzwerkverbindung fällt aus

Node 1 + Node 2      Node 3
      │                │
   2 Stimmen        1 Stimme
      │                │
   Quorum ✓         Quorum ✗

Die beiden miteinander verbundenen Nodes besitzen weiterhin die Mehrheit.

Der einzelne isolierte Node dagegen nicht.

Ohne dieses Verfahren könnten beide Seiten davon ausgehen, sie seien weiterhin der gültige Cluster und unabhängig voneinander Änderungen durchführen.

Das wäre insbesondere bei gemeinsam genutztem Storage gefährlich.

Virtuelle Maschinen zwischen Nodes verschieben

Einer der praktischen Vorteile eines Clusters ist die Migration virtueller Maschinen.

Damit lässt sich beispielsweise eine VM von:

Node 1

nach:

Node 2

verschieben.

Wie einfach das funktioniert, hängt allerdings vom Storage ab.

Bei lokalem Storage müssen die VM-Daten gegebenenfalls zusammen mit der VM übertragen werden.

Bei gemeinsamem Storage befinden sich die virtuellen Festplatten bereits an einem Ort, auf den beide Nodes zugreifen können.

Das führt unmittelbar zum nächsten wichtigen Thema.

Shared Storage oder Ceph?

Für viele Cluster stellt sich irgendwann die Frage:

Wo liegen eigentlich die virtuellen Festplatten?

Es gibt mehrere Möglichkeiten.

Beispielsweise:

Besonders interessant im Proxmox-Umfeld ist Ceph.

Ceph verteilt Daten über mehrere Hosts und Datenträger und kann dadurch hochverfügbaren Storage direkt innerhalb des Proxmox-Clusters bereitstellen.

Ein stark vereinfachtes Modell:

Node 1           Node 2           Node 3

OSD              OSD              OSD
 │                │                │
 └────────────────┼────────────────┘
                  │
               Ceph Pool
                  │
                  ▼
                 VM

Fällt ein Datenträger oder – abhängig von der Konfiguration – ein kompletter Node aus, können die Daten weiterhin über andere Ceph-Komponenten verfügbar bleiben.

Ceph bringt allerdings zusätzliche Komplexität mit sich. Netzwerk, Anzahl der Nodes, Datenträger und Replikationsstrategie müssen zusammenpassen.

Deshalb behandeln wir das Thema separat:

→ Proxmox Ceph Cluster einrichten – Schritt für Schritt

High Availability: Was passiert bei einem Node-Ausfall?

Ein Cluster allein macht eine VM noch nicht hochverfügbar.

Für High Availability (HA) muss Proxmox die VM auf einem anderen Node starten können.

Dafür benötigt der Cluster unter anderem:

• funktionierendes Quorum
• geeigneten Storage
• mindestens einen alternativen Node
• korrekt konfigurierte HA-Ressourcen
• zuverlässige Cluster-Kommunikation

Fällt beispielsweise Node 1 aus:

Vorher:

Node 1            Node 2            Node 3
  │
 VM01


Nach Ausfall:

Node 1            Node 2            Node 3
  X                  │
                    VM01

kann die VM auf einem anderen verfügbaren Node neu gestartet werden.

Wichtig ist dabei die Formulierung neu gestartet.

Proxmox HA bedeutet üblicherweise nicht, dass die gleiche VM auf zwei Hosts gleichzeitig weiterläuft. Der Cluster erkennt den Ausfall und startet die betroffene Ressource auf einem anderen Node.

→ Proxmox HA einrichten und einen Node-Ausfall testen

Einen Node zum Cluster hinzufügen

Cluster verändern sich.

Neue Hardware kommt hinzu, bestehende Hosts werden ersetzt oder eine Testumgebung soll erweitert werden.

Ein neuer Node kann einem bestehenden Proxmox-Cluster beitreten.

Dabei sollte der neue Host allerdings möglichst frisch installiert sein und noch keine produktiven Gäste enthalten, deren Konfiguration mit der Cluster-Konfiguration kollidieren könnte.

Wie der Vorgang funktioniert, zeigen wir separat:

→ Proxmox Node zu einem bestehenden Cluster hinzufügen

Einen Node wieder entfernen

Etwas mehr Aufmerksamkeit verlangt die umgekehrte Richtung.

Ein Node sollte nicht einfach ausgeschaltet und anschließend aus der Umgebung gelöscht werden.

Vorher muss geklärt werden:

• Laufen noch VMs oder Container auf dem Node?
• Befinden sich dort Ceph-OSDs?
• Verändert sich das Quorum?
• Sind HA-Ressourcen betroffen?
• Ist der Node noch Teil der Corosync-Konfiguration?

Gerade bei Ceph-Clustern kann das Entfernen eines Nodes zusätzliche Auswirkungen auf die Datenverteilung haben.

→ Proxmox Node sicher aus einem Cluster entfernen

Einen Proxmox Cluster wieder auflösen

Gerade in Labor- und Schulungsumgebungen kommt noch eine andere Situation häufig vor:

Ein Cluster wurde für einen Test aufgebaut und soll danach wieder vollständig zerlegt werden.

Hier sollte man zwischen zwei Szenarien unterscheiden:

Node aus bestehendem Cluster entfernen

und

Cluster vollständig auflösen

Das sind technisch nicht exakt dieselben Vorgänge.

Wer hier unüberlegt Cluster-Konfigurationen löscht, kann sich schnell unnötige Folgeprobleme einhandeln.

Deshalb widmen wir auch diesem Thema eine eigene Anleitung:

→ Proxmox Cluster auflösen – Cluster sauber zurückbauen

Backup bleibt auch im Cluster notwendig

Ein HA-Cluster ersetzt kein Backup.

Das wird in der Praxis gerne verwechselt.

High Availability schützt vor bestimmten Ausfällen der Infrastruktur. Sie schützt aber nicht automatisch vor:

• versehentlich gelöschten Dateien
• fehlerhaften Updates
• beschädigten Daten innerhalb einer VM
• Ransomware
• Fehlkonfigurationen
• versehentlich gelöschten virtuellen Maschinen

Deshalb sollte auch ein hochverfügbarer Proxmox-Cluster über ein unabhängiges Backup-Konzept verfügen.

Eine naheliegende Lösung ist der Proxmox Backup Server (PBS).

→ Proxmox Backup Server an einen Cluster anbinden

Warum sich ein Proxmox Cluster besonders gut praktisch lernen lässt

Viele der Konzepte lassen sich theoretisch erklären. Wirklich verständlich werden sie aber meistens erst, wenn man sie selbst ausprobiert.

Beispiele dafür sind:

Gerade Themen wie Quorum oder HA wirken auf dem Papier relativ abstrakt. Sobald man jedoch einen Node absichtlich vom Netz trennt und beobachtet, wie der Cluster reagiert, wird das Konzept schnell nachvollziehbar.

Das Problem ist lediglich die benötigte Infrastruktur.

Für einen realistischen Test benötigt man schnell mehrere Proxmox-Nodes, ein separates Netzwerk und ausreichend Storage.

Proxmox Cluster ohne eigene Hardware testen

Genau für solche Szenarien bieten wir unsere Proxmox-Schulungsumgebung an.

Dabei wird für einen definierten Zeitraum eine isolierte Umgebung mit einem Jumphost und mehreren Proxmox-Nodes bereitgestellt.

Die Nodes können anschließend für eigene Übungen genutzt werden, beispielsweise:

• Cluster aufbauen
• Corosync konfigurieren
• Quorum testen
• Nodes hinzufügen und entfernen
• Ceph installieren
• Storage konfigurieren
• Migrationen testen
• HA-Szenarien durchspielen
• Fehlerzustände gezielt erzeugen

Der Vorteil gegenüber einer fertig konfigurierten Demo-Umgebung ist, dass die eigentliche Einrichtung Teil der Übung bleibt.

Die Systeme werden deshalb in einem Zustand bereitgestellt, in dem die Teilnehmer die Proxmox-Installation und Cluster-Konfiguration selbst durchführen können.

→ Proxmox-Schulungsumgebung ansehen

Welche Cluster-Größe ist für welchen Zweck sinnvoll?

Als grobe Orientierung:

Dabei geht es bei einem Lab nicht zwingend darum, eine perfekte Produktionsarchitektur nachzubauen.

Oft ist es sogar interessanter, bewusst Fehler zu erzeugen und zu beobachten:

Was passiert eigentlich, wenn Node 2 plötzlich nicht mehr erreichbar ist?

Genau solche Situationen machen aus einer reinen Installation eine echte Cluster-Übung.

Fazit

Ein Proxmox-Cluster besteht aus deutlich mehr als nur mehreren Servern in derselben Weboberfläche.

Erst das Zusammenspiel aus:

Nodes
+
Corosync
+
Quorum
+
Storage
+
HA
+
Backup

ergibt eine belastbare Cluster-Architektur.

Wer neu mit dem Thema beginnt, sollte deshalb nicht sofort mit Ceph und Hochverfügbarkeit starten. Sinnvoller ist es, zunächst einen kleinen Cluster aufzubauen, die Kommunikation zwischen den Nodes zu verstehen und gezielt mit Quorum und Migrationen zu experimentieren.

Darauf lassen sich anschließend Storage, Ceph und HA aufbauen.

In den folgenden Artikeln gehen wir die einzelnen Themen Schritt für Schritt durch.

Weiterführende Anleitungen

Grundlagen

• Proxmox Cluster erstellen – Schritt-für-Schritt-Anleitung
• Proxmox Cluster mit 2 Nodes: Quorum, QDevice und Best Practices
• Corosync in Proxmox erklärt

Cluster verwalten

• Proxmox Node zu einem Cluster hinzufügen
• Proxmox Node sicher aus einem Cluster entfernen
• Proxmox Cluster vollständig auflösen

Storage und Hochverfügbarkeit

• Proxmox Ceph Cluster einrichten
• Proxmox HA einrichten und testen
• Proxmox Backup Server an einen Cluster anbinden