Einen Proxmox-Cluster mit Hochverfügbarkeit auf dedizierten Servern aufbauen

Zuerst die Antwort: was es braucht, was man dafür bekommt

Die Anforderungen, laut Proxmox' eigener Dokumentation und ungebeugt von Wunschdenken:

• Mindestens drei Knoten für zuverlässiges Quorum. (Ein Zwei-Knoten-Cluster funktioniert mit einer externen QDevice als Tie-Breaker, Details weiter unten, aber drei ist, wo das Design eigentlich hin will.)
• Ein zuverlässiges Netzwerk mit niedriger Latenz zwischen den Knoten, unter 5 ms, mit Cluster-Traffic idealerweise auf einer eigenen NIC. Das ist eine Anforderung für denselben Standort, ein privates LAN, kein Netzwerk, das man über Regionen hinweg spannt.
• Storage, auf den die überlebenden Knoten zugreifen können: hyperkonvergentes Ceph, ZFS-Replikation pro Gast, oder externer Shared Storage.

Was man dafür bekommt, ebenso schlicht gesagt: Stirbt ein Knoten, startet HA dessen Gäste automatisch auf den überlebenden Knoten neu, innerhalb weniger Minuten. Das ist Crash Recovery ohne Menschen dabei, enorm wertvoll, aber es ist keine Zero-Downtime-Fehlertoleranz: Die Gäste starten neu. Live Migration (für geplante Umzüge) ist die unsichtbare Variante; Failover ist ein Neustart.

Ist Ihr eigentlicher Bedarf "Ausfälle innerhalb eines Arbeitstages beheben", dann ist eine gute Backup- und Restore-Praxis auf einem soliden Host weniger Maschinerie. Clustering rechtfertigt seine Komplexität, wenn Minuten zählen, oder wenn Sie genug Gäste betreiben, dass zentrale Verwaltung und Live Migration sich täglich auszahlen.

Clustering vor HA: schon für sich allein lohnenswert

Eine verbreitete Verwechslung: Cluster ≠ HA. Knoten zu einem Cluster zusammenzuschließen (pvecm) liefert, ganz ohne konfiguriertes HA: eine Web-UI, die jeden Knoten verwaltet, Live Migration von VMs zwischen Knoten (Hardware-Wartung ohne Ausfallzeit), clusterweites SDN-Networking und Firewall-Konfiguration, sowie gemeinsame Job- und Rechteverwaltung. Viele Produktivcluster laufen genau so (Menschen entscheiden, wann Gäste umziehen) und fügen HA später selektiv hinzu, pro Gast, für die Dienste, die automatisiertes Failover rechtfertigen.

Quorum: warum drei Knoten

Das Problem, das Quorum löst, ist Split-Brain. Fallen Cluster-Verbindungen aus und können sich Knoten nicht mehr sehen, muss jede Seite entscheiden: "Bin ich jetzt der Cluster?" Sagen beide Seiten Ja, starten beide dieselben VMs auf demselben Shared Storage, und Sie lernen, wie beschädigte Disk-Images aussehen. Die Regel, die das verhindert: nur eine Gruppe mit einer Mehrheit der Stimmen darf handeln. Bei drei Knoten hat jede Partition eine Mehrheitsseite (2) und eine Minderheitsseite (1), die einfriert; bei zwei Knoten macht eine unterbrochene Verbindung beide Seiten zu Minderheiten: Keine kann handeln, und die Verfügbarkeit ist jetzt schlechter als bei einem einzelnen Knoten.

Daher die zwei zulässigen Formen: drei oder mehr Knoten, oder zwei Knoten plus eine QDevice, ein winziger Corosync-Daemon, der auf einer beliebigen dritten Maschine als Zeuge fungiert (eine VPS oder ein kleiner Server genügt; sie betreibt keine Gäste, sie stimmt nur ab). Niemals zulässig ist der Workaround, den Foren um Mitternacht vorschlagen: die erwarteten Stimmen manuell auf 1 setzen, um einen partitionierten Knoten gewaltsam aktiv zu schalten. Genau dieser Schalter ist der Weg, wie Split-Brain zur persönlichen Erfahrung wird.

Das Corosync-Netzwerk: Latenz ist Gesetz

Corosync, die Membership- und Messaging-Schicht des Clusters, ist die Komponente, deren Anforderungen am wenigsten verhandelbar und am häufigsten verletzt sind:

• Latenz unter 5 ms zwischen allen Knoten. Das ist LAN-Physik: derselbe Standort, ein privates Netzwerk. Knoten in verschiedenen Städten sind kein Cluster; sie sind zwei Cluster und eine Replikationsstrategie.
• Bandbreite ist irrelevant; Contention ist fatal. Corosync braucht nur Kilobit, aber sobald es sich eine Verbindung mit Backup-Jobs, Storage-Traffic oder VM-Migration teilt und diese Verbindung sättigt, kommen Membership-Pakete zu spät an, Knoten werden für tot erklärt, und HA beginnt, Gäste zu "retten", denen nichts fehlte. Die offizielle Empfehlung, es wert, wörtlich befolgt zu werden: eine dedizierte NIC (1 Gbit reicht völlig) für Cluster-Traffic, und bis zu acht redundante Corosync-Links, falls Sie noch freie Pfade übrig haben. Mindestens ein zweiter Link auf einem anderen Netzwerk als Fallback.
• Storage-Traffic (besonders bei Ceph) will ebenfalls eine eigene Spur; siehe unten.

Auf unseren dedizierten Servern überträgt sich das eins zu eins: das private Netzwerk zwischen Ihren Maschinen führt Corosync (und Storage) auf Interfaces, die nie mit öffentlichem Traffic konkurrieren.

Storage: die eigentliche Architekturentscheidung

Die Prämisse von HA ist, dass die Disks eines Gastes den Knoten überleben, auf dem er lief. Drei Wege, das zu erreichen:

Ceph: hyperkonvergent, die vollständige Antwort

Proxmox integriert Ceph nativ: jeder Knoten steuert Disks bei (OSDs), Ceph repliziert Daten über die Knoten hinweg (standardmäßig 3 Kopien), jeder Knoten sieht den gesamten Storage, und der Verlust eines Knotens kostet nichts. Selbstheilend, kein externes SAN, skaliert durch Hinzufügen von Knoten. Das ist der klassische hyperkonvergente Cluster, und die offiziellen Anforderungen sind ehrlich, was den Appetit angeht: drei oder mehr, vorzugsweise identische Server, ein dediziertes Netzwerk mit 10 Gbit/s+ ausschließlich für Ceph (25 Gbit/s+, sobald NVMe im Spiel ist: eine einzelne moderne NVMe kann 10 Gbit/s allein sättigen), Disks auf HBAs, nicht auf RAID-Controllern (Ceph übernimmt die Redundanz selbst; eine RAID-Schicht darunter schadet aktiv), grob ein CPU-Thread pro Ceph-Dienst und ~8 GiB RAM pro OSD für Komfort. Kalkulieren Sie diese Ressourcen als Infrastruktur-Overhead pro Knoten ein, zusätzlich zur Gast-Dimensionierung.

ZFS-Replikation: der pragmatische Mittelweg

Wo die Anforderungen von Ceph das Budget sprengen, repliziert pvesr Gast-Volumes nach Zeitplan zwischen Knoten (so eng wie jede Minute) über das Migrationsnetzwerk, ZFS-zu-ZFS. Failover startet den Gast dann von seiner Replik neu, mit einem Vorbehalt, den Ceph nicht hat: einem expliziten Datenverlustfenster. Alles, was sich seit dem letzten Sync geändert hat (bis zu einer Minute, oder dem eigenen Zeitplan), ist weg. Für viele Workloads ist dieser Tausch ausgezeichnet: keine Komplexität durch Shared Storage, lokale NVMe-Geschwindigkeit für jeden Gast, Redundanz pro Gast statt clusterweit. Erfordert ZFS-basierten Gast-Storage auf beiden Seiten.

Externer Shared Storage

NFS oder iSCSI, erreichbar von allen Knoten, erfüllt HA ebenfalls, konzeptionell am einfachsten, und verlagert das Problem: Diese Storage-Box ist jetzt der Single Point of Failure, den der Cluster nicht abdeckt. Sinnvoll, wenn es ein wirklich resilientes Storage-System ist; falsche Sparsamkeit, wenn es ein einzelner NFS-Server im selben Rack ist.

Wie ein Failover tatsächlich aussieht

Der Mechanismus verdient es, entmystifiziert zu werden, denn "der Cluster kümmert sich darum" verbirgt ein pikantes Detail. Jeder Knoten, der HA-Gäste betreibt, schaltet einen Watchdog scharf, einen Totmannschalter (Hardware-Watchdog, wo konfiguriert, sonst der Kernel-Softdog). Verliert ein Knoten sein Quorum, hört er auf, den Watchdog zu füttern, und nach dem Timeout (~60 Sekunden) wendet der Knoten Fencing auf sich selbst an: er startet neu, was garantiert, dass seine Gäste wirklich tot sind und ihre Disks freigegeben wurden. Die Mehrheit mit Quorum wartet dieses Fenster ab und startet dann die HA-Gäste des per Fencing isolierten Knotens von Shared oder replizierten Storage neu.

Insgesamt erlebte Ausfallzeit für einen Gast: Watchdog-Fenster + Scheduling + Boot des Gastes, typischerweise wenige Minuten. Die Konfiguration erfolgt pro Gast (Datacenter → HA): die Gäste markieren, die es rechtfertigen, Gruppen-/Affinitätsregeln steuern, wo sie landen (PVE 9 brachte richtige Resource-Affinity-Regeln, und der dynamische Load Scheduler von 9.2 kann nach Echtzeitnutzung ausbalancieren). Zwei betriebliche Hinweise, die selbstverschuldete Vorfälle verhindern: Nutzen Sie den Maintenance Mode (und die clusterweite HA-Deaktivierung von PVE 9.2) vor bewussten Neustarts, damit die Watchdog-Mechanik nicht einen Knoten "rettet", den Sie gerade patchen; und wissen Sie, dass Fencing auch der Grund ist, warum man auf einem partitionierten Knoten nie ein Quorum vortäuscht: Der Watchdog ist die letzte Linie, die verhindert, dass zwei Kopien Ihrer Datenbank auf dieselbe Disk schreiben.

Wann man nicht clustern sollte

• Zwei Knoten, nirgendwo eine dritte Stimme. Fügen Sie eine QDevice hinzu (irgendeine kleine VM anderswo) oder bleiben Sie ungeclustert: Ein Zwei-Knoten-Cluster ohne QDevice fällt schlimmer aus als unabhängige Knoten.
• Knoten durch echte Latenz getrennt. >5 ms bedeutet Nein. Multi-Site-Resilienz löst man mit unabhängigen Standorten plus Replikation und Backups, nicht mit einem überdehnten Cluster.
• Wenn die ehrliche Anforderung "bis morgen wiederhergestellt" lautet. Ein gut gesicherter Host mit Reprovisioning in unter einer Minute im Hintergrund ist deutlich weniger Betriebsaufwand, und PBS Live-Restore verkleinert den Abstand weiter.
• Nicht zusammenpassende Hardware für Ceph. Stark unterschiedliche Knoten machen Ceph unglücklich (die langsamste Disk gibt das Tempo vor); ZFS-Replikation verträgt Asymmetrie deutlich besser.

Häufig gestellte Fragen

Kann ich einen Zwei-Knoten-Cluster aufbauen?

Ja, mit der QDevice als obligatorischer dritter Stimme: corosync-qnetd auf einer beliebigen, dauerhaft laufenden Maschine außerhalb des Paars (eine kleine Cloud-Instanz ist die klassische Wahl; sie betreibt keine Gäste und braucht kaum Ressourcen). Damit kann jeder der beiden Knoten ausfallen, und der überlebende behält das Quorum und führt die HA-Wiederherstellung aus. Ohne QDevice lässt man es besser: Jeder Verbindungs- oder Knotenausfall friert den gesamten Cluster ein, was strikt schlechter ist als zwei unabhängige Hosts.

Bietet mir HA Zero-Downtime-Failover?

Nein. Und zu wissen, warum, sorgt für die richtigen Erwartungen. Ungeplantes Failover bedeutet Fencing und dann Neustart: Die Gäste des ausgefallenen Knotens starten nach dem Watchdog-Fenster frisch auf den überlebenden Knoten, also plant man mit Minuten an Ausfallzeit und entwirft Anwendungen so, dass sie sich sauber von einem harten Stopp erholen (das sollten sie ohnehin können). Tatsächlich Zero-Downtime ist die geplante Verschiebung: Live Migration entlastet einen Knoten vor Wartungsarbeiten, während die Gäste durchgehend weiterlaufen. HA kümmert sich um die Überraschungen; Live Migration übernimmt den Zeitplan.

Können meine Knoten in unterschiedlichen Rechenzentren stehen?

Verschiedene Racks oder Räume innerhalb einer Einrichtung mit privater Anbindung unter 5 ms: ja, und das ist gute Failure-Domain-Hygiene. Verschiedene Städte: nein. Sowohl die Corosync-Membership als auch (schlimmer noch) synchrone Ceph-Replikation werden bei WAN-Latenzen instabil. Das Multi-Region-Muster besteht aus unabhängigen Clustern pro Standort mit asynchroner Replikation und Backup-Sync dazwischen, und Failover als bewusster Akt statt als automatischer.

Brauchen alle Knoten identische Hardware?

Für den Cluster selbst nicht. Gemischte Knoten clustern problemlos, und Live Migration zwischen unterschiedlichen CPU-Generationen funktioniert mit einem gemeinsamen Baseline-CPU-Typ, der auf den Gästen eingestellt ist (der Preis: Gäste können keine neueren Befehlssätze nutzen). Für Ceph ist nahezu identische Hardware die dringende Empfehlung: Kapazität und Leistung balancieren sich über die OSDs, und ein langsamer Knoten bremst den gesamten Pool. Pragmatisches Muster für gemischte Flotten: alle zusammen für die Verwaltung clustern, Ceph (oder Replikationspaare) über die passende Teilmenge betreiben, und HA-Gäste dort fixieren.

Deployment auf Serverside

Der in diesem Artikel beschriebene Cluster übersetzt sich in eine konkrete Bestellung: drei identische dedizierte Server (Proxmox vorinstalliert, NVMe auf HBAs für Ceph oder ZFS für Replikation), verbunden über unser privates Netzwerk für Corosync- und Storage-Traffic (Ihre öffentliche Bandbreite bekommt den Cluster-Datenverkehr nie zu sehen), jeweils mit KVM-over-IP für den Tag, an dem ein Knoten Out-of-Band-Zugriff braucht. Provisioning dauert unter einer Minute auf ASN 55285, was sogar das QDevice-Muster trivial macht: jede kleine dritte Maschine genügt.

Arbeiten Sie sich mit der Serie dorthin vor: Einrichtung, Networking, LXC vs. VMs und Backups, die Sie trotzdem noch brauchen; ein Cluster repliziert Ihre Fehler mit exzellenter Verfügbarkeit.