Resilienz über zwei Standorte – eine technische Tiefenanalyse

Die Kombination von Proxmox VE und Ceph in einer hyperkonvergenten Architektur verspricht maximale Effizienz und eine zentrale Verwaltung. Doch unter der einheitlichen Weboberfläche agieren zwei Systeme mit fundamental unterschiedlichen Paradigmen: Das Proxmox-Cluster-Management, das auf dem Mehrheitsentscheid von Corosync basiert, und das Ceph Storage-Cluster, dessen Verhalten durch ein eigenes Monitor-Quorum und komplexe CRUSH-Regeln definiert wird. Die wahre Kunst der Systemarchitektur besteht darin, diese beiden Welten so zu orchestrieren, dass sie auch im Extremfall – dem Ausfall eines kompletten Brandabschnitts oder Rechenzentrums – als eine Einheit stabil bleiben.

Ein solches „Stretched Cluster“-Szenario ist keine triviale Erweiterung eines Standard-Setups. Es erfordert ein tiefes Verständnis der zugrundeliegenden Mechanismen und eine Architektur, die von vornherein auf den Ernstfall ausgelegt ist. Zwei Aspekte sind dabei von entscheidender, nicht verhandelbarer Bedeutung: die Quorum-Architektur und das Sizing des Ceph-Clusters.

Die Architektur des Quorums: Warum der dritte Standort den Unterschied macht

Ein Cluster, das auf zwei Standorte verteilt ist, steht vor einem unlösbaren Problem: Bei einem Verbindungsausfall können beide Seiten nicht feststellen, ob die Gegenseite oder nur die Verbindung ausgefallen ist. Es entsteht ein klassischer Split-Brain-Zustand. Die Lösung ist ein dritter, unabhängiger Standort, der als „Tie-Breaker“ oder Schiedsrichter fungiert.

Unsere Best Practice für dieses Szenario ist unmissverständlich: Dieser Tie-Breaker darf kein ressourcensparendes QDevice sein, sondern muss ein vollwertiger Proxmox VE Node sein. Der Grund dafür ist die duale Natur des Clusters:

• Proxmox Corosync Quorum: Der Node am dritten Standort liefert die entscheidende Stimme, damit das Proxmox-Cluster bei Ausfall eines Hauptstandorts quorate und damit handlungsfähig bleibt.
• Ceph Monitor Quorum: Auf diesem Node wird zwingend ein Ceph Monitor installiert. Dieser liefert die entscheidende Stimme für das Ceph-Quorum und stellt sicher, dass auch das Storage-System bei einem Standortausfall eine klare Mehrheit bilden kann.

Die entscheidende, oft übersehene Anforderung an diesen Quorum-Node ist seine Netzwerkintegration. Er muss in allen drei relevanten Netzwerken erreichbar sein: dem Proxmox Corosync-Netzwerk, dem Proxmox Management-Netzwerk und dem Ceph Public-Netzwerk. Nur so ist gewährleistet, dass sowohl die Hypervisor- als auch die Storage-Ebene im Fehlerfall eine stabile, clusterweite Entscheidung treffen können.

Ceph-Redundanz: Die Logik hinter size=4 und min_size=2

Die Resilienz des Storage-Systems hängt maßgeblich von zwei Parametern ab: size und min_size. Für ein Stretched-Cluster-Szenario über zwei Standorte ist die Konfiguration size=4 und min_size=2 zwingend erforderlich. Um ihre Bedeutung zu verstehen, muss man sie als Soll- und Mindest-Zustand betrachten:

• size (der Soll-Zustand): Dieser Parameter definiert die Gesamtzahl der Kopien (Replicas), die Ceph von jedem Datenblock im Cluster anlegen und vorhalten soll. Eine size=4 ist eine Anweisung an das Cluster: „Stelle sicher, dass von jedem einzelnen Datenblock immer vier identische Kopien auf unterschiedlichen OSDs existieren.“ Dies ist das Ziel, das Ceph unter normalen Umständen anstrebt.
• min_size (der Mindest-Zustand): Dieser Parameter definiert die absolute Mindestanzahl an verfügbaren Kopien, die vorhanden sein müssen, damit Ceph einen Schreibvorgang überhaupt zulässt. Er ist die entscheidende Sicherheitsschwelle, um Datenkonsistenz zu garantieren. Eine min_size=2 bedeutet: „Erlaube Schreibvorgänge nur, wenn du garantieren kannst, den Datenblock auf mindestens zwei OSDs erfolgreich zu schreiben.“ Fällt die Anzahl der erreichbaren Kopien unter diesen Wert, schaltet der betroffene Teil des Clusters automatisch in einen Read-Only-Modus, um inkonsistente Daten zu verhindern.

In Kombination mit einer CRUSH-Regel, die eine Verteilung der Replicas auf die beiden Standorte erzwingt (zwei pro Standort), ergibt sich das gewünschte ausfallsichere Verhalten: Fällt ein kompletter Standort aus, gehen dessen zwei Kopien verloren. Das Cluster kann jedoch weiterarbeiten, da am verbleibenden Standort immer noch zwei Kopien vorhanden sind und somit die min_size=2 Bedingung erfüllt ist.

Herleitung der Mindest-Architektur: Warum 2+2+1 das Minimum ist

Aus den Anforderungen von Corosync und Ceph ergibt sich zwingend eine Mindest-Architektur von 4 operativen Hosts plus einem Quorum-Node. Hier ist die logische Herleitung:

1. Ceph-Anforderung (Datenverteilung): Das Ziel ist, den Ausfall eines kompletten Standorts zu überleben. Unsere CRUSH-Regel besagt, dass an jedem Standort zwei Replicas gespeichert werden müssen. Um zwei Replicas an einem Standort zu speichern, benötigt Ceph zwingend mindestens zwei physische Hosts an diesem Standort (da Ceph Replicas niemals auf demselben Host ablegt). Dies gilt für beide Standorte. Ergebnis: 2 Hosts in Standort A + 2 Hosts in Standort B = 4 operative Hosts.
2. Proxmox-Anforderung (Cluster-Quorum): Das Proxmox-Cluster benötigt für einen stabilen Betrieb eine klare Mehrheit an „Stimmen“. Bei 4 Hosts würde der Ausfall eines Standorts (2 Hosts) dazu führen, dass nur noch 2 von 4 Stimmen übrig sind. Das ist keine Mehrheit (50%), und das verbleibende Cluster wäre „inquorate“ und würde den Betrieb einstellen. Um dies zu verhindern, wird eine ungerade Anzahl an Stimmen benötigt. Durch den Quorum-Node am dritten Standort wird eine fünfte Stimme hinzugefügt. Fällt nun ein Standort mit 2 Hosts aus, verbleiben 3 von 5 Stimmen – eine klare Mehrheit, die den Weiterbetrieb des Clusters sicherstellt.

Fazit: Erst das Zusammenspiel dieser beiden Anforderungen führt zur robusten Mindest-Architektur von zwei operativen Hosts in Brandabschnitt A, zwei operativen Hosts in Brandabschnitt B und einem Quorum-Node an einem dritten, unabhängigen Ort.

‍

Achtung: Die Konsequenzen für das Sizing sind enorm. Eine size von 4 bedeutet eine vierfache Schreiblast und einen Netto-Speicherplatz von nur 25% der Brutto-Kapazität. Die Storage-Hardware (typischerweise NVMe-SSDs) und die Netzwerkverbindungen zwischen den Standorten müssen für diesen massiven Overhead dimensioniert sein. Ein zu knapp kalkuliertes Sizing führt hier unweigerlich zu Performance-Engpässen, die den gesamten Cluster lahmlegen können.

‍

Schlussfolgerung: Resilienz ist kein Zufall, sondern präzise Ingenieurskunst

Ein über zwei Brandabschnitte gespanntes Proxmox- und Ceph-Cluster bietet ein Höchstmaß an Verfügbarkeit, ist aber weit von einer Standardinstallation entfernt. Es ist ein komplexes System, dessen Stabilität von scheinbar kleinen Details wie der Netzwerkanbindung eines einzelnen Quorum-Nodes oder der korrekten size-Einstellung abhängt. Diese Details sind das Ergebnis präziser Planung und eines tiefen Verständnisses der zugrundeliegenden Technologien.

Bevor Sie den Schritt zu einer standortübergreifenden Infrastruktur wagen, lassen Sie uns sprechen. Vereinbaren Sie ein unverbindliches Erstgespräch, in dem wir die technischen und betrieblichen Anforderungen für eine Lösung analysieren, die Ihr Geschäft wirklich absichert – ohne Kompromisse.