Proxmox VE Cluster-Manager (1)
Doppelt gemoppelt
Veröffentlicht in Ausgabe 09/2025 - PRAXIS
Leidgeprüfte Administratoren wissen: Die Liste der Dinge im Rechenzentrum, die schiefgehen können, ist lang. Kaum ein Systemverwalter ist um die Erfahrung herumgekommen, wie es ist, wenn am Wochenende des Bereitschaftsdiensts das gesamte Monitoring plötzlich rot gesprenkelt ist. Eine typische Ursache ist ein banaler Hardwaredefekt im Storage – derartige Situationen finden sich ganz weit oben auf der Hitliste der Fehlerquellen.
Zwar hat sich die Situation bei Festplatten mittlerweile etwas entspannt, weil vielerorts Flash-Laufwerke dominieren und "rotierender Rost", also klassische Festplatten, seltener geworden sind. Dass jene den Geist aufgeben liegt auf der Hand, denn schließlich arbeiten Enterprise-Festplatten mit bis zu 15.000 Umdrehungen. Andererseits ist die Vorstellung, dass Flash-Laufwerke weniger störanfällig sind, oft ein Trugschluss. Böse Zungen behaupten, diese gingen nicht seltener kaputt, sondern nur vorhersehbarer.
Auch Netzteile und RAM rangieren weit oben in der Liste fehleranfälliger Komponenten. Und äußere Faktoren haben wir dabei noch nicht einmal erwähnt: Baggern die Bauarbeiter die Strom- oder Netzwerkzuleitung des Rechenzentrums weg, ist ebenfalls Schicht im Schacht. Und tatsächlich ist für einen katastrophalen Ausfall eines Setups noch nicht mal der Ausfall einer technischen Komponente nötig. Es genügt auch, wenn sich ein Admin vertut und einen falschen Befehl ausführt. Das "Fat Fingering" ist ein probates Mittel, um selbst eine gut geölte Installation aus dem Tritt zu bringen.
Leidgeprüfte Administratoren wissen: Die Liste der Dinge im Rechenzentrum, die schiefgehen können, ist lang. Kaum ein Systemverwalter ist um die Erfahrung herumgekommen, wie es ist, wenn am Wochenende des Bereitschaftsdiensts das gesamte Monitoring plötzlich rot gesprenkelt ist. Eine typische Ursache ist ein banaler Hardwaredefekt im Storage – derartige Situationen finden sich ganz weit oben auf der Hitliste der Fehlerquellen.
Zwar hat sich die Situation bei Festplatten mittlerweile etwas entspannt, weil vielerorts Flash-Laufwerke dominieren und "rotierender Rost", also klassische Festplatten, seltener geworden sind. Dass jene den Geist aufgeben liegt auf der Hand, denn schließlich arbeiten Enterprise-Festplatten mit bis zu 15.000 Umdrehungen. Andererseits ist die Vorstellung, dass Flash-Laufwerke weniger störanfällig sind, oft ein Trugschluss. Böse Zungen behaupten, diese gingen nicht seltener kaputt, sondern nur vorhersehbarer.
Auch Netzteile und RAM rangieren weit oben in der Liste fehleranfälliger Komponenten. Und äußere Faktoren haben wir dabei noch nicht einmal erwähnt: Baggern die Bauarbeiter die Strom- oder Netzwerkzuleitung des Rechenzentrums weg, ist ebenfalls Schicht im Schacht. Und tatsächlich ist für einen katastrophalen Ausfall eines Setups noch nicht mal der Ausfall einer technischen Komponente nötig. Es genügt auch, wenn sich ein Admin vertut und einen falschen Befehl ausführt. Das "Fat Fingering" ist ein probates Mittel, um selbst eine gut geölte Installation aus dem Tritt zu bringen.
Virtualisierung ist für die Infrastruktur neuralgisch
Im Kontext von Virtualisierung kommt der Hochverfügbarkeit dabei nochmals ein ganz eigener Stellenwert zu. Denn hier potenziert sich der mögliche Schaden. In den USA sprechen Admins gern martialisch vom "Blast Radius". Der Begriff kommt eigentlich aus dem Militär und bezeichnet das Gebiet, das beim Abwurf einer Bombe allein durch deren Druckwelle zerstört wird. Sinnbildlich bezeichnet der Blast Radius im IT-Kontext den maximal möglichen Schaden, den eine Fehlfunktion oder unzureichende Bedienung anrichtet.
Es ist leicht nachvollziehbar, dass die Gefahr bei Virtualisierungsumgebungen größer ist als bei klassischer IT. Denn geht bei einer Proxmox-Installation ein aktiver Knoten offline, reißt er im schlimmsten Fall etliche VMs mit in den Abgrund, die allesamt wichtige Funktionen bieten. Der Ausfall eines physischen Servers sorgt dann, anders als bei Setups ohne Virtualisierung, dafür, dass viele zentrale Dienste nicht länger zur Verfügung stehen.
Deshalb spielt Hochverfügbarkeit in virtualisierten Umgebungen eine noch größere Rolle als im Rechenzentrum der Gegenwart ohnehin schon. Die Ziele sind bei beiden weitgehend deckungsgleich: Durch redundante Hardware versuchen IT-Verantwortliche, einzelne Systeme gegen defekte Komponenten ebenso abzuhärten wie gegen Fehlbedienung. Und selbst der Ausfall umgebender Infrastruktur lässt sich durch HA zum Teil gut abfedern.
Das Herzstück der HA-Architektur ist dabei stets ein Cluster-Manager. Das ist keine neue Erfindung und schon klassische UNIX-Systeme wie HP-UX oder AIX hatten bereits vor mehreren Jahrzehnten gut funktionierende Cluster-Manager. Diese waren bereits damals in der Lage, laufende Dienste von einem ausgefallenen Server woanders neu zu starten ("Failover"). Unter Linux lief die Entwicklung der Cluster-Manager allerdings deutlich langsamer ab. Hier gab erst Heartbeat 1 den Ton an, kaum mehr als ein Bretterverschlag von IBM. Daraus wurde erst Heartbeat 2 als Basis des Linux-HA-Stacks und später Pacemaker, das mittlerweile Corosync, Kronosnet und diverse andere Tools unter der Haube für die Cluster-Kommunikation nutzt. Mittlerweile gilt der Linux-HA-Stack als verlässlich, der Umgang damit birgt allerdings Herausforderungen. So werkelt im Kern von Pacemaker beispielsweise eine Konfigurationsdatenbank auf XML-Grundlage. Benutzerfreundlich ist das Konstrukt insofern nicht.
IT-Administrator Sonderheft "Lokal virtualisieren"
Die zunehmende gesetzliche Regulierung wie auch die sich verschärfende Sicherheits- und Datenschutzproblematik der Cloud bringt IT-Verantwortliche zunehmend dazu, über neue Ansätze der On-Premises-Virtualisierung nachzudenken. Die massiven Umwälzungen in Sachen vSphere-Lizenzierung seit der Übernahme durch Broadcom verschärfen diese Situation weiter. Das neue IT-Administrator Sonderheft "Lokal virtualisieren" setzt sich daher mit den Virtualisierungsumgebungen Proxmox VE, Hyper-V und Nutanix auseinander. Denn diese drei Systeme sind die wichtigsten Kandidaten, wenn kleine, mittlere und große Organisationen eine Transformation in Sachen virtueller Infrastruktur anstreben.So zeigt das Autorenteam für Proxmox VE, Hyper-V und Nutanix zunächst jeweils auf, welche Technologien die drei Plattformen jeweils mitbringen und welche Anforderungen sie an ihre Umgebung haben. Anschließend zeigen wir das Einrichten der Systeme und die Konfiguration zentraler Dienste wie die Storage-Anbindung, die Hochverfügbarkeit, das Verwalten virtueller Instanzen und mehr. Fehlen dürfen natürlich ebenfalls nicht das Betrachten der notwendigen Security-Maßnahmen und -Konfiguration und das übergeordnete Management der Gesamtstruktur.Das Sonderheft ist ab Oktober 2025 verfügbar und kostet für Abonnenten des IT-Administrator 24,90 Euro, für Nicht-Abonnenten werden 29,90 Euro fällig.
Proxmox verzichtet auf Pacemaker
Proxmox liefert HA-Software als Bordwerkzeug seines Virtual Environment. Diese setzt im Kern Komponenten des Linux-Cluster-Stacks ein, vorrangig Corosync für die Kommunikation der Cluster-Knoten. Mit Pacemaker [1] wollte sich Proxmox aber offensichtlich nicht so recht anfreunden und setzt unter der Haube stattdessen auf einen eigenen Cluster-Manager namens "ha-manager" [2]. Der Cluster-Stack trägt dabei den Namen "pvecm" ("Proxmox VE Cluster Manager"). Hinsichtlich der Konfiguration und des Betriebs des Clusters müssen Sie einige wichtige Details beachten. Das betrifft einerseits die Handhabung der Werkzeuge selbst und andererseits die Umgebung, in der Sie die Software ausrollen und nutzen.
Mit Pacemaker lässt sich praktisch jeder Dienst auf einem modernen Linux-System hochverfügbar aufsetzen. Das umfasst auch Komponenten wie MySQL und andere Serverdienste. Bei diesen ist die Herangehensweise allerdings deutlich komplexer als bei virtuellen Instanzen. Das liegt auch an der Art und Weise, wie klassische HA grundsätzlich funktioniert. Dienste wie MySQL kommunizieren mit ihren Clients über TCP/IP-Verbindungen. Im Hinblick auf Hochverfügbarkeit müssen Sie dabei die Art der Verbindung beachten, die zwischen Client und Server zustande kommt. Handelt es sich um Stateless-Verbindungen, also solche, die sich nach der Datenübermittlung automatisch terminieren, ist HA simpel umzusetzen. Geht es hingegen um Stateful-Verbindungen, die bestehen bleiben, ist das Thema etwas komplizierter, denn diese brechen bei einem Failover ab. Hier müssen Sie ein Auge darauf haben, dass die Clients eine abgebrochene Verbindung automatisch erneut aufbauen.
In beiden Fällen ist eine zentrale Frage aber die IP-Adresse, die Clients für die Verbindung mit ihrem Dienst nutzen. MySQL ist hier ein unrühmliches Beispiel, denn das MySQL-Protokoll sieht nicht vor, dem Client mehrere, zueinander alternative Verbindungen mit auf den Weg zu geben. Um MySQL mit Pacemaker hochverfügbar zu betreiben, konfigurieren Admins zusätzlich zu MySQL deshalb im Normalfall eine entsprechende IP-Adresse als Cluster-Dienst, die mit MySQL mitschwenkt.
Und damit ist das Thema noch nicht durch, denn HA-Instanzen von MySQL im Failover-Setup erfordern auch denselben Datensatz. Dieser muss auf einem geteilten, replizierten Speicher liegen, wahlweise aus einer SDS-Anwendung oder einem NAS oder SAN. Ohne Dateisystem ist dieses Laufwerk zudem nicht nutzbar. Für MySQL-HA über Pacemaker bedarf es im Regelfall neben MySQL also der IP-Adresse als vom Cluster verwalteten Dienst und einer Dateisystem-Ressource, die den Mountpoint einhängt, von dem MySQL dann seine Daten liest. Kommt eine SDS-Anwendung wie DRBD zum Einsatz, ist auch diese noch in Pacemaker zu integrieren.
Virtuelle Instanzen sind aus Cluster-Manager-Sicht pflegeleichter. Sie produzieren zwar durch ihren eigenen Gast-Kernel Overhead in Sachen Ressourcenverbrauch. Dafür hat eine VM jedoch, damit sie von einem System auf ein anderes schwenken kann, auch praktisch keinerlei zusätzliche Abhängigkeiten. Denn Dienste wie die IP-Adresse oder ein eventuell benötigtes Dateisystem liegen in der VM selbst. Das vereinfachte Handling von HA bei virtuellen Instanzen ist ohne Zweifel ein Grund dafür, dass Proxmox lieber einen eigenen Cluster-Manager nutzt statt auf Pacemaker zu setzen. Denn ein großer Teil der Vorsichtsmaßnahmen und Funktionen, die Pacemaker hat und braucht, wären in einem HA-Setup für VMs überflüssig.
Der beste Weg zum Speicher
Nicht verschont bleiben im Proxmox-Kontext virtuelle Instanzen von der Thematik des redundanten Speichers. Denn damit eine Instanz auf System B mit denselben Daten starten kann, die zuletzt auf System A gegeben waren, muss sie wahlweise denselben Speicher verwenden oder eine (replizierte) Kopie dieser Daten. Auch bei Proxmox ist aus diesem Grund die Verfügbarkeit redundanten Speichers eine zentrale Voraussetzung für den Cluster-Manager. Der Storage ist demnach die erste zentrale Frage, der Sie sich im Proxmox-Kontext stellen müssen.
Ein wichtiger Aspekt ist bei diesen Überlegungen, ob Sie den Speicher aus Proxmox heraus bereitstellen oder ihn extern zuliefern. Noch immer ist für viele Admins die naheliegendste Option ein geteilter Speicher nach SAN- oder NAS-Prinzip, wobei SAN-Storage zunehmend seltener wird. Stattdessen geben NAS-Appliances im Rechenzentrum heute üblicherweise den Ton an.
Wer aus der Vergangenheit hier noch an Fibre Channel (FC) gewöhnt ist, denkt im Idealfall um. Zwar haben mehrere Hersteller noch FC-Geräte im Portfolio, doch die Installation einer kompletten parallelen Netzwerkinfrastruktur ist mühsam. Auch deren Wartung verschlingt oft Ressourcen, die in vielen Unternehmen nicht vorhanden sind. Wohl auch deshalb ist FC in der Gunst von NAS-Herstellern in den vergangenen Jahren kontinuierlich gesunken.
Die einfachste Methode, einen Proxmox-Cluster mit redundantem Speicher zu versehen, besteht also in der Anbindung eines NAS-Speichers. Komfortabel ist das auf der Proxmox-Seite aber nur bedingt. Viel hängt vor allem davon ab, über welches Protokoll das NAS seine virtuellen Volumes zur Verfügung stellt. Hier kommt beispielsweise ein NFS-Share in Frage, das die Festplattenabbilder der virtuellen Maschinen direkt im NFS lagert. Ein solcher Speicher lässt sich unkompliziert in Proxmox als Backendspeicher für VMs anbinden. Weil NFS es erlaubt, von mehreren Stellen aus gleichzeitig zuzugreifen, ist es durchaus gängige Praxis, das jeweilige NFS einfach auf jedem betroffenen Proxmox-Node einzuhängen.
Vor eventuellen Split-Brain-Problemen müssen Sie sich dabei nicht fürchten. Ein solcher Fall tritt auf, sofern mehrere Proxmox-Knoten zur selben Zeit unkoordiniert auf das Festplattenabbild einer Instanz zugreifen. Wobei Split Brain in diesem Fall noch das beste Ergebnis wäre – viel wahrscheinlicher ist ein Schaden an der Image-Datei. Proxmox vermeidet diese Situationen jedoch, indem es als Teil des Cluster-Managers einen Fencing-Mechanismus mit ausrollt.
Etwas schwieriger wird die Angelegenheit, wenn der NAS-Speicher über iSCSI oder NVMe-over-Fabric (NVMe-oF) angebunden ist. Das geht in Proxmox zwar, aber nur über die Kommandozeile. Voraussetzung dafür ist zudem funktionierendes Multipathing. Es muss also möglich sein, auf eine iSCSI- oder NVMe-oF-LUN von mehreren Stellen und über mehrere Pfade gleichzeitig zuzugreifen. Auch hier kommt das Fencing von Proxmox ins Spiel, das unkoordinierte Schreibvorgänge unterbindet.
Software-defined Storage mit DRBD
Alternativ zum NAS bietet sich redundanter Speicher als Software an. Der klassische Ansatz ist das "Distributed Replicated Block Device" (DRBD). Das unterstützt Proxmox selbst zwar nicht, von seinem Hersteller Linbit steht allerdings eine entsprechende Integration Verfügung. DRBD [1] ist eine Art RAID 1 über das Netzwerk und seit seiner aktuellen Version 9 unterstützt es auch die Replikation zwischen mehr als zwei Knoten.
Das klappt am komfortabelsten, wenn Sie DRBD als Teil der SDS-Appliance Linstor ausrollen. Denn dann sind Managementfunktionen automatisch Teil des Pakets. DRBD ist unter der Haube vergleichsweise simpel. Hier kommen keine komplizierten Algorithmen zum Einsatz, die das Verteilen von Daten steuern. Stattdessen kopiert das DRBD-Kernel-Modul Daten, die auf den lokalen Datenträger zu schreiben sind, in den TCP/IP-Stack des Linux-Kernels und transferiert sie so zur DRBD-Instanz auf einem anderen Knoten. Obendrein ist DRBD freie Software und steht in der Community-Edition kostenlos zur Verfügung. Kommerzieller Support von Linbit ist obendrein verfügbar.
Ceph als Königsweg
Proxmox selbst verfolgt in Sachen Speicherredundanz allerdings längst einen anderen Ansatz und hat den verteilten Objektspeicher Ceph als Königsweg auserkoren, replizierten Speicher für virtuelle Instanzen zu implementieren. Das geht so weit, dass das System in der Lage ist, einen kompletten Ceph-Cluster aus dem eigenen GUI heraus auszurollen.
Innerhalb der Open-Source-Community stößt das nicht nur auf Gegenliebe. Denn Ceph, das unter der Ägide von Red Hat und damit indirekt unter jener von IBM steht, gibt mittlerweile einen eigenen Deployment-Weg für den Objektspeicher vor. Der fußt auf Containern und kommt mit einem eigenen Werkzeug zum Ausrollen namens "cephadm" daher. Doch Proxmox stellt für Ceph eigene Pakete zur Verfügung, mittels derer sich der Dienst auf einem Proxmox-VE-System betreiben lässt. Dabei sieht der Hersteller den Betrieb im Hyperkonvergenz-Modus explizit vor. Der Speicher kann also auch auf den Systemen liegen, auf denen die virtuellen Instanzen laufen. Vorausgesetzt natürlich, dort sind die entsprechenden Laufwerke vorhanden. Wegen des einfachen Deployments über das Proxmox-UI ist der Betrieb von Ceph als Speicher für HA-VMs sicher der einfachste Weg. Das Murren der Ceph-Entwickler hinsichtlich des Deployment-Mechanismus muss Sie nicht stören, zumal Proxmox bei Vorliegen eines Supportvertrags Ceph unterstützt. Auch alle gängigen Wartungsarbeiten wie das Hinzufügen oder Entfernen von Laufwerken lassen sich aus Proxmox heraus bewerkstelligen.
Durch die Schnittstelle RBD ("RADOS Block Device"), die Proxmox für die direkte Anbindung an KVM und Qemu nutzt, ist der Einsatz von Ceph für virtuelle Instanzen leicht möglich. Allerdings bringt der Objektspeicher RADOS, der im Kern von Ceph werkelt, Designmerkmale mit, die ihn nicht für jede VM-Umgebung geeignet erscheinen lassen.
Hinter den Kulissen werkelt bei Ceph ein Algorithmus namens CRUSH ("Controlled Replication Under Scalable Hashing", also in etwa "Kontrollierte Replikation mit skalierbaren Hash-Werten"). CRUSH ist dafür zuständig, für jede in den Cluster zu ladende Information ein primäres Laufwerk zu errechnen und ebenso die Laufwerke festzulegen, auf denen die Replikate der Daten landen. Dabei ist CRUSH verglichen mit anderen Algorithmen allerdings eher langsam. Die implizite Latenz in Ceph, die durch jeden Schreibvorgang und dadurch durch jede CRUSH-Kalkulation entsteht, ist deutlich größer als bei anderen SDS-Produkten. Im Gespann mit Ethernet, das selbst eine gute Schippe auf die Latenz-Problematik legt, leidet Ceph unter vergleichsweise hoher Latenz.
Indirekt wirkt sich das in virtuellen Instanzen auf die IOPS-Anzahl vor allem kleinerer Schreibvorgänge aus. Während eine lokale NVMe hunderttausende Schreibvorgänge mit 4K-Größe pro Sekunde abwickeln kann, ist selbst bei einem gut getunten Ceph meist bei 2000 4K-IOPS für einen einzelnen Thread Schluss. Sie müssen im Vorfeld einer Migration hin zu Proxmox also prüfen, ob diese Werte für die geplanten Anwendungen ausreichen. Wobei 2000 4K-IOPS nicht die Grenze des gesamten Clusters darstellen, wohl aber jene für einzelne Threads, wie etwa Datenbanken sie nutzen. Reichen Ihnen die genannten Werte, ist RADOS eine gute Wahl. Als Speicher sollte dann allerdings NVMe zum Einsatz kommen. Verteilen Sie das Setup über mehrere Standorte, sollten Sie zudem keinesfalls einen gestreckten Ceph-Cluster bauen. Denn dann ist die Netzwerklatenz so hoch, dass selbst die 2000 4K-IOPS pro Thread ein Wunschtraum bleiben.
Was Hochverfügbarkeit braucht
Bevor Sie sich mit dem HA-Thema via Proxmox-Cluster-Manager befassen, sollte das Speicherthema wie beschrieben abgehakt sein. Gerade bei Hyperkonvergenz-Setups ist penibel darauf zu achten, dass die genutzten Maschinen sowohl in der Lage sind, die anliegende Last von Ceph als auch jene der laufenden Instanzen zu tragen. Darüber hinaus gibt es einige weitere Vorbereitungen, die das Leben des Systemverwalters in Sachen Hochverfügbarkeit leichter machen.
Ein HA-Setup ergibt beispielsweise nur dann Sinn, wenn die Umgebung auch gegen den Ausfall einzelner Infrastrukturkomponenten gewappnet ist. Die Netzwerkverbindungen der einzelnen Systeme sollten Sie redundant auslegen. Dies lässt sich unter Linux mittels NIC-Bonding gut erreichen – LACP ist dabei der Standard. Vergessen Sie an dieser Stelle nicht, dies auch auf der Switch-Seite entsprechend einzurichten.
Redundante Switch-Paare bedingen entweder eine CLAG/MLAG-Verbindung oder EVPN mit Multihoming-Funktion. Auch die verfügbare Bandbreite spielt eine Rolle. Selbst simple Hypervisor-Systeme für KVM sollten Sie mit mindestens 10 GBit/s planen. Läuft Ceph auf denselben Systemen, sind 25 GBit/s die bessere Wahl. Das gilt zumindest, falls Sie Ceph für die interne Replikation keine eigene Netzwerkschnittstelle bereitstellen.
Darüber hinaus sollten Sie die Hardware im Blick haben. Server statten Sie mit redundanten Netzteilen aus und ECC-RAM hat sich bewährt, um Problemen durch defekten Arbeitsspeicher zu begegnen. Die Systempartitionen der Proxmox-Systeme sollten zudem auf einem RAID-Laufwerk liegen. Viele Server – auch von Supermicro – haben mittlerweile passende RAID-Controller direkt auf dem Mainboard integriert. Ansonsten stehen einfache Controller für RAID 1 auch in Form eigener Steckkarten zur Verfügung. Und komplett verzichten können Sie auf ein Hardware-RAID mit der MDRAID-Funktion des Linux-Kernels. Deren Einrichtung bietet Proxmox während der Installation an. Beachten Sie diese Regeln, reduzieren sich viele Problemfaktoren für die Stabilität des Systems bereits deutlich.
Eine Frage des Quorums
Für einen Proxmox-Cluster sind mindestens drei Proxmox-Instanzen erforderlich. Das hat vorrangig mathematische Gründe, denn einer der heikelsten Punkte bei HA-Clustern ist stets das Quorum. Wie bei einer Abstimmung auch meint der Begriff im HA-Kontext eine Mehrheitsentscheidung, für die eine Mindestmenge abgegebener Stimmen nötig ist. Dazu müssen Sie wissen, dass verteilte Systeme wie ein HA-Cluster im Hintergrund regen Austausch von Daten zwischen den Instanzen des Cluster-Managers über alle Knoten hinweg betreiben. Damit ein Cluster-Knoten aktiv werden kann, wenn ein anderer Knoten ausfällt, muss er sich in einer Quorum-Partition befinden.
Deutlich wird das Problem, wenn wir uns einen HA-Cluster vorstellen, der in mehrere Teile zerfällt. Das kann etwa dann der Fall sein, wenn die Netzwerkverbindung zwischen den Knoten verloren geht, weil ein zentraler Switch ausfällt. Ein einzelner Knoten ist dabei nicht in der Lage, zu entscheiden, in welchem Zustand der Cluster sich nach dem Ausfall befindet. Denn er selbst könnte ja auch jener Knoten sein, der vom Ausfall des Netzwerks betroffen ist.
Unter normalen Umständen initiiert ein Cluster-Knoten, wenn er den Ausfall anderer Nodes bemerkt, ein Failover der laufenden Ressourcen. In der beschriebenen Situation würde das dazu führen, dass die virtuellen Instanzen plötzlich mehrmals laufen – auf dem einzelnen Knoten und im verbliebenen Cluster der anderen beiden Knoten. Kommt noch ein verteilter Speicher wie Ceph dazu, zerfällt auch dieser in mehrere Teile, die sich unkoordiniert voneinander weg entwickeln – eine typische Split-Brain-Situation.
Um das Problem zu vermeiden, setzen Cluster auf das Quorum. Sie erklären sich selbst für defekt, wenn sie nach einem Netzwerkereignis nicht mehr Teil jener Cluster-Partition sind, die mehr als 50 Prozent aller ausschlaggebenden Systeme sieht. Zerfällt ein System aus drei Knoten also in zwei Partitionen, arbeitet jene mit zwei Knoten weiterhin, der einzelne Knoten jedoch ist nicht länger aktiv nutzbar. Das Problem, das sich hieraus für Systeme mit nur zwei Knoten ergibt, ist offensichtlich: Zerfällt ein solcher Cluster in zwei Teile, weiß keine der beiden Seiten, ob sie die aktive sein soll oder nicht. Das mathematische Quorum von zwei ist eins, das von drei ist zwei.
Hierin liegt übrigens auch die Begründung dafür, dass der Betrieb eines Clusters mit vier Knoten nur bedingt Sinn ergibt, denn dessen Quorum liegt ebenfalls bei zwei. Von vier Systemen darf also nur eines ausfallen, weil zwei eben nur 50 Prozent von vier sind – aber nicht mehr. Für einen Proxmox-Cluster sind mithin mindesten drei Knoten vorgegeben.
Fencing und Config-Dateien für HA
Das "Fencing" beschreibt im HA-Kontext die Möglichkeit, dass die verbliebenen Knoten eines Clusters einen ausgefallenen unschädlich machen. Das kann beispielsweise mittels Stromabschaltung per IPMI geschehen. Ebenfalls nutzbar sind so genannte Watchdog-Geräte auf der Netzwerkebene. Um Ihrem Proxmox-Cluster Hardware-basiertes Fencing zur Verfügung zu stellen, ist wahlweise ein Watchdog-fähiges Netzwerkgerät oder eine funktionierende IPMI-Anbindung erforderlich.
Auch die Steuerung über externe PDUs ist denkbar, also über schaltbare Steckdosen. In den meisten Fällen ist der Ansatz mittels Watchdog-Gerät aber ausreichend, wenn dieses in Hardware implementiert ist. Alternativ kann Proxmox den "Softdog"-Treiber des Linux-Kernels verwenden. Dieser ist aber nicht so zuverlässig wie ein entsprechendes, eigenständiges Gerät oder eine Funktion in einem Chip wie beispielweise von Super-I/O.
Übrigens benötigt der Proxmox-Cluster-Manager unter der Haube Konfigurationsdateien und eine Art "Cluster Information Base" (CIB). Anders als Pacemaker setzt der ha-manager dabei aber nicht auf XML, sondern nutzt das "Proxmox Cluster File System" (pmxcfs). Dieses enthält die Konfiguration des Clusters. Proxmox bindet das Dateisystem, das im Hintergrund eine Datenbank nutzt, dynamisch auf allen Cluster-Knoten ein. Dem Administrator entsteht hier also kein Mehraufwand. Zu beachten ist lediglich, dass pmxcfs aktuell nicht größer als 128 MByte sein kann. Laut Hersteller ist das ausreichend für mehrere Tausend VMs – eine Zielgröße also, die zu den meisten Proxmox-Installationen gut passen dürfte.
Fazit
Der Proxmox-Cluster-Manager ist deutlich weniger sperrig als Pacemaker. Sein Einsatz zwingt den Administrator jedoch trotzdem dazu, sich mit den grundsätzlichen Details in Sachen Hochverfügbarkeit vertraut zu machen. Darüber hinaus muss die Umgebung, in der Proxmox werkelt, so eingerichtet sein, dass der Betrieb eines HA-Clusters möglich ist. Wie die praktische Nutzung des Cluster-Managers aussieht und wie ein Ceph-Cluster als Grundlage für VMs in Proxmox entsteht, verrät in der Oktober-Ausgabe der zweite Teil dieser Vorabveröffentlichung aus dem neuen IT-Administrator Sonderheft "Lokal virtualisieren".
(jp)
Link-Codes
[1] Pacemaker: https://clusterlabs.org/projects/pacemaker/
[2] Proxmox ha-manager: https://github.com/proxmox/pve-ha-manager