Ceph-Cluster mit 2 OSDs: Warum 3 MONs kein HA bieten

Ein Proxmox-Cluster mit drei Ceph-MONs und nur zwei OSDs lässt sich technisch problemlos in Betrieb nehmen. Dennoch ergibt diese Kombination ein denkbar ungeeignetes Konzept für hochverfügbaren Speicher.

Es ist leicht nachvollziehbar, wie Administratoren bei diesem Setup landen: Drei MONs sichern das Monitor-Quorum von Ceph, sodass die Steuerungsebene fehlerfrei arbeitet. Zwei OSDs können zwei Datenkopien vorhalten, womit der Pool im Normalbetrieb ebenfalls als intakt angezeigt wird. Ergänzt man ein separates Ceph-Netzwerk, wirkt das Schaubild auf den ersten Blick redundant. Sobald jedoch ein Storage-Knoten ausfällt, wird der fundamentale Unterschied zwischen MON-Quorum und echter Datenredundanz schmerzhaft spürbar.

Proxmox konfiguriert Ceph-Pools standardmäßig mit drei Replikaten, von denen mindestens zwei für Lese- und Schreibzugriffe verfügbar sein müssen. Ein Setup mit nur zwei OSDs kann diese 3/2-Richtlinie strukturell nicht erfüllen. Reduziert man den Pool auf zwei Kopien, passt er zwar zur vorhandenen Hardware, verschenkt jedoch genau die Sicherheitsmargen, für die man Ceph überhaupt einsetzt. Ceph zu starten ist einfach; entscheidend ist, was nach einem Ausfall übrig bleibt.

Machen drei MONs einen Ceph-Cluster mit zwei OSDs hochverfügbar?

Nein, denn MON-Quorum und OSD-Redundanz lösen völlig unterschiedliche Aufgaben. Ein Ceph-Monitor (MON) verwaltet Cluster-Maps und sichert den Konsens über den Gesamtzustand des Clusters. MONs werden in ungerader Zahl betrieben, damit die Mehrheit den Ausfall eines Monitors übersteht. Ein Object Storage Daemon (OSD) speichert hingegen die tatsächlichen Nutzdaten.

Wenn drei MONs aktiv sind, ein Pool jedoch zu viele OSD-Replikate verloren hat, kann auch ein intaktes Quorum die fehlenden Daten nicht herbeizaubern. Die Monitore werden sich lediglich einig darüber sein, dass der Speicher degradiert oder schlicht nicht mehr erreichbar ist.

Die meisten Missverständnisse rühren daher, dass diese beiden Ebenen vermischt werden. In der Ausgangskonfiguration gab es drei Proxmox-Knoten und drei MONs, OSDs liefen jedoch nur auf zweien davon. Die dritte Maschine war absichtlich leistungsschwächer ausgelegt und sollte hardwaregebundene Aufgaben übernehmen, etwa Home Assistant mit einem Zigbee-Stick.

Ein Proxmox-Knoten ohne OSD ist als Ceph-Client völlig unproblematisch. Er benötigt keine lokale OSD, um einen RBD-Pool einzubinden, sondern greift über das Public-Netzwerk auf Ceph zu wie jeder externe Client. Der Schwachpunkt bleibt, dass der gesamte Datensatz an lediglich zwei physischen Orten liegt, und daran ändert die dritte OSD-freie Maschine rein gar nichts.

Warum setzt Proxmox Ceph-Pools standardmäßig auf size 3 und min_size 2?

Drei Kopien bieten einen soliden Schutz vor Datenverlust und erlauben weiterhin Ein- und Ausgaben, wenn ein Replikat vorübergehend ausfällt.

Unter Proxmox VE lauten die Standardwerte für Ceph-Pools:

• size = 3
• min_size = 2

size definiert die Anzahl der Replikate, die Ceph für jedes Objekt vorhalten soll. min_size gibt die minimale Anzahl verfügbarer Kopien vor, damit der Pool Schreib- und Lesezugriffe (I/O) akzeptiert.

Ein gesunder 3/2-Pool hält drei Kopien. Fällt eine OSD oder ein kompletter Host aus, verschwindet eine Kopie, zwei bleiben erhalten. Der Pool arbeitet uneingeschränkt weiter, während Ceph im Hintergrund die Redundanz wiederherstellt.

Mit nur zwei OSDs lassen sich keine drei getrennten Replikate anlegen. Es bleiben zwei offensichtliche Optionen, von denen sich keine wie ein Standard-Ceph verhält.

Die erste Variante lautet size=2, min_size=2. Hierbei sind zwingend beide Kopien für I/O erforderlich. Fällt eine der beiden OSDs aus, stoppt der Pool sofort alle I/O-Zugriffe, da nur noch ein Replikat übrig ist.

Die zweite Variante ist size=2, min_size=1. Der Pool arbeitet mit der einzigen verbliebenen Kopie weiter. Das klingt zunächst nach höherer Verfügbarkeit, bis man sich klarmacht, dass der verteilte Speicher nun von einer einzigen Festplatte abhängt. Ein weiterer Sektorfehler, ein Bitfehler oder ein Bedienfehler genügen, um aus einem degradierten Pool einen endgültigen Datenverlust zu machen.

Entwickler von Proxmox warnen in Foren regelmäßig davor, ein 2/1-Setup als Standardlösung anzusehen. Ein Ausfall auf der letzten verbliebenen Kopie führt direkt zum Datenverlust. Das Standardprofil 3/2 sollte beibehalten werden, sofern keine sehr spezifischen Sonderfälle vorliegen. I/O-Fluss und Datensicherheit sind getrennte Ziele; ein 2/1-Pool opfert Sicherheit für scheinbare Betriebszeit.

Ist das Netzwerk tatsächlich das größte Problem?

In diesem Entwurf nicht. Die geringe OSD-Anzahl stellt das primäre architektonische Problem dar; eine unzureichende Netzwerkauslegung kann ein zweites hinzufügen.

Proxmox empfiehlt mindestens 10 Gbps dediziert für den Ceph-Datenverkehr. Die Dokumentation warnt ausdrücklich davor, dass Ceph-Recovery das latenzempfindliche Corosync-Clusternetzwerk stören und zum Verlust des Cluster-Quorums führen kann. Im diskutierten Entwurf sollte der Ceph-Public-Traffic auf demselben Netzwerk wie Corosync liegen. In einer Laborumgebung mag das genügen; für ein produktionsnahes System mit verlässlichem Ausfallverhalten ist davon dringend abzuraten.

Corosync benötigt nur minimale Bandbreite, reagiert jedoch extrem empfindlich auf Latenzen und Jitter. Ceph generiert Last genau in den kritischen Momenten: wenn die Infrastruktur durch OSD-Ausfälle, Wiederherstellungsläufe, Backfills oder Rebalancing ohnehin gestresst ist. Ein ruhiger Cluster sieht in synthetischen Tests immer gut aus. Der Härtetest besteht darin, eine OSD unter Last abzuziehen. Wenn Ceph-Recovery dann die Corosync-Leitung überlastet, gefährdet der Speicherausfall plötzlich die Cluster-Mitgliedschaft. Aus zwei unabhängigen Problemen wird ein Totalausfall.

Weiterführende Konzepte zur Dimensionierung kleiner Cluster bündelt der Mr.PlanB Proxmox-Hub, in dem Storage, Clustering, Migration und Ausfallkonzepte gemeinsam betrachtet werden.

Wozu dienen Ceph-Public- und Cluster-Netzwerk wirklich?

Das Public-Netzwerk als reines „MON-Netzwerk" zu bezeichnen, greift deutlich zu kurz. Ceph-Clients kommunizieren über das Public-Netzwerk direkt mit den OSDs. Monitore sind dort ebenfalls erreichbar, doch vor allem der VM-Speicherverkehr von den Proxmox-Knoten läuft über diese Front-Schnittstelle.

Das optionale Cluster-Netzwerk erfüllt einen anderen Zweck: Sofern konfiguriert, wickelt Ceph darüber OSD-Heartbeats, Objektreplikation und Recovery-Datenverkehr zwischen den OSDs ab.

Ein Proxmox-Knoten ohne eigene OSD benötigt folglich eine leistungsfähige Anbindung an das Ceph-Public-Netzwerk, wenn er VMs betreiben soll, deren Festplatten im Ceph-Pool liegen. Dass auf ihm ein MON läuft, verpflichtet ihn nicht zur Teilnahme an der OSD-Replikation. Ein Teilnehmer der Diskussion brachte dies präzise auf den Punkt: Der dritte Knoten kann den Pool voll nutzen, ohne selbst OSDs zu beherbergen.

Aus diesem Grund fällt das langsamste Netzwerk-Interface im Cluster stark ins Gewicht. Wenn ein Compute-Knoten nur über 1GbE an das Ceph-Public-Netzwerk angebunden ist, während die Storage-Knoten über 2.5GbE oder 10GbE verfügen, werden VMs auf dem langsamen Knoten durch dessen Schnittstelle ausgebremst. Das drosselt zwar nicht den gesamten Cluster auf 1 Gbps, mindert die Performance auf dem betroffenen Host jedoch drastisch.

Funktioniert Ceph über 1GbE oder 2.5GbE?

Ja, allerdings klafft zwischen „funktioniert grundsätzlich" und „funktioniert während eines Recovery-Vorgangs zufriedenstellend" eine enorme Lücke.

Ein Administrator, der ein vergleichbares Drei-Knoten-Setup mit zwei OSDs betrieben hatte, beschrieb das Verhalten als funktional, aber träge. Das System fühle sich an wie VMs auf sehr langsamem Flash-Speicher, mit spürbar hohen Latenzen und einem Durchsatz, der einer ausgelasteten 1GbE-Verbindung entspricht. Das ist zwar ein individueller Erfahrungsbericht, das zugrundeliegende Limit ist jedoch systemimmanent.

Ceph-Clients sprechen OSDs direkt an, die OSDs replizieren untereinander, und Recovery- sowie Backfill-Prozesse erzeugen massive Zusatzströme. Das Netzwerk transportiert weit mehr als nur den ursprünglichen Schreibzugriff des Gastsystems. Das Ceph-Projekt weist darauf hin, dass die OSD-Replikation das Storage-Netzwerk stark belastet. Ein einzelnes Public-Netzwerk genügt für viele kleinere Installationen, doch bei hoher Last bringt ein dediziertes Cluster-Netzwerk spürbare Entlastung.

Proxmox gibt für hyperkonvergente Umgebungen klarere Richtlinien vor und empfiehlt mindestens 10 Gbps für Ceph. Bei modernen NVMe-Datenträgern stellt selbst 10GbE oft den Engpass dar.

Für eine Lernumgebung ist 2.5GbE völlig legitim. Für Produktivspeicher, der auch im Fehlerfall berechenbar und schnell bleiben soll, lässt sich das schwer rechtfertigen.

Was geschieht, wenn einer der beiden OSD-Knoten ausfällt?

Das hängt von den Replikationseinstellungen des Pools ab, und keines der beiden Szenarien überzeugt. Bei zwei Kopien und min_size=2 blockiert der Verlust einer OSD sofort alle I/O-Vorgänge, weil der Pool das erforderliche Minimum unterschreitet. Man ist vor unvollständigen Schreibvorgängen geschützt, das Gesamtsystem ist jedoch nicht hochverfügbar.

Bei zwei Kopien und min_size=1 bedient die verbliebene OSD weiterhin Zugriffe. Der Dienst bleibt erreichbar, die Daten hängen jedoch an einer einzigen physischen Disk, exakt der Zustand, den verteilter Speicher verhindern soll.

Drei MONs ändern an beiden Resultaten nichts. Das Monitor-Quorum kann voll funktionsfähig sein, während der Pool nur einen Hardwarefehler vom Datenverlust entfernt ist. Eine treffende Antwort in der technischen Diskussion fasste es zusammen: Man kann es so bauen, eine gute Idee ist es nicht.

Würde eine dritte OSD die Architektur verändern?

Ja. Eine dritte OSD in einer dritten separaten Ausfalldomäne verändert das Fehlermodell grundlegend, weit mehr als ein weiterer MON.

Mit drei Storage-Hosts kann Ceph drei Replikate auf drei unterschiedliche Rechner verteilen und die bewährte 3/2-Richtlinie anwenden. Fällt ein Host komplett aus, bleiben weiterhin zwei Datenkopien verfügbar. Das entspricht dem, was man gemeinhin unter Ceph-Hochverfügbarkeit versteht.

Die Herausforderung im konkreten Fall lag darin, dass der dritte Rechner bewusst leistungsschwächer gewählt wurde, womit das Thema Hardware-Symmetrie ins Spiel kommt. Ceph arbeitet am effizientesten, wenn Kapazität und Performance der OSDs auf allen Hosts ausgewogen sind. Ein deutlich langsamerer Storage-Knoten beeinträchtigt Recovery-Zeiten und bremst den gesamten Pool aus. Asymmetrische Ceph-Cluster sind machbar, doch einen schwachen Rechner in die Speicherebene zu zwingen, ist selten besser als ein simplerer Architekturansatz.

Ist ZFS-Replikation die bessere Wahl für ein Drei-Knoten-Homelab?

In vielen Fällen ja, insbesondere wenn sich nur zwei Knoten als echte Storage-Server eignen.

Mehrere erfahrene Administratoren rieten dazu, auf Ceph zu verzichten und stattdessen auf lokales ZFS mit Proxmox-Speicherreplikation zu setzen. Dieser Ansatz wird oft unterschätzt, obwohl ZFS-Replikation nahtlos in das HA-Konzept von Proxmox integriert ist: Proxmox spiegelt VM-Festplatten asynchron vom lokalen ZFS-Speicher auf einen Zielknoten. Fällt der Quellknoten aus, startet Proxmox HA die VM auf Basis der letzten Replikationskopie auf dem Zielsystem neu.

Der Kompromiss liegt im RPO (Recovery Point Objective). Die Replikation erfolgt zeitgesteuert; eine wiederhergestellte VM verliert Änderungen, die nach dem letzten erfolgreichen Durchlauf angefallen sind. Der Standardintervall von pvesr liegt bei 15 Minuten und lässt sich bei leistungsfähiger Hardware und schnellem Netzwerk weiter verkürzen.

Ceph strebt eine synchrone, kontinuierliche Datenhaltung an. ZFS-Replikation akzeptiert ein kurzes Zeitfenster für den Datenverlust, verlangt dafür aber eine weitaus einfachere Infrastruktur. In einem Homelab, in dem manche VMs ohnehin fest an bestimmte Knoten gebunden sind, stellt dies häufig den pragmatischeren Kompromiss dar.

Ein Diskussionsteilnehmer berichtete, dass er beruflich Ceph einsetzt, zu Hause jedoch ZFS-Replikation nutzt, weil Performance- und Kapazitäts-Overhead von Ceph in einem Homelab mit drei Knoten und sechs OSDs kaum zu rechtfertigen seien. Es geht darum, die Architektur an die Betriebsgröße anzupassen, nicht um ein pauschales Werturteil.

Was spricht für LINSTOR bei nur zwei Storage-Knoten?

LINSTOR ist eine interessante Option, tauscht jedoch eine Form von Komplexität verteilter Systeme gegen eine andere ein.

Einige Nutzer schlugen LINSTOR mit DRBD vor, womit sich Blockspeicher synchron über eine kleine Anzahl von Knoten spiegeln lässt. Ein Teilnehmer berichtete von einer Proxmox-Umgebung mit drei Knoten, in der nur zwei Knoten den replizierten Speicher hielten, was stabil funktionierte. Das passt gut zu einer Topologie, bei der zwei Systeme als starke Storage-Knoten dienen und das dritte System primär Rechenleistung oder Quorum bereitstellt.

Allerdings bringt LINSTOR ein eigenes Betriebsmodell mit: DRBD-Konzepte, Controller, Satelliten und entsprechende Wartungsanforderungen. Wer gezielt lernen möchte, wie verteilter Speicher aufgebaut ist, findet hier ein spannendes Betätigungsfeld. Geht es jedoch primär darum, den Neustart eines Hosts abzufedern, ist die lokale ZFS-Replikation meist der unkompliziertere Weg.

Was sollten Sie aufbauen, um Ceph fundiert zu lernen?

Bauen Sie Ceph auf, und betrachten Sie es als das, was es ist: eine Testumgebung. Einen Cluster mit zwei OSDs gezielt zu betreiben, um das Zusammenspiel von MONs, MGRs, OSDs, Pools, CRUSH, RBD, Recovery und Netzwerkwegen zu verstehen, ist vollkommen legitim. Ein unvollkommenes Setup vermittelt oft tiefere Einblicke als eine fehlerfrei vorkonfigurierte Lösung. Verwechseln Sie eine erfolgreiche Installation jedoch nicht mit robuster Architektur, und testen Sie gezielt die kritischen Szenarien:

1. Ziehen Sie eine OSD ab.
2. Beobachten Sie, wie sich die I/O-Werte verhalten.
3. Prüfen Sie, ob der Pool degradiert, blockiert oder auf einer Kopie weiterläuft.
4. Lasten Sie das Ceph-Netzwerk vollständig aus.
5. Überwachen Sie parallel die Latenzen von Corosync.
6. Verschieben Sie eine VM auf den langsamsten Compute-Knoten.
7. Messen Sie die Festplattenlatenzen innerhalb des Gastsystems.
8. Binden Sie die ausgefallene OSD wieder ein und beobachten Sie den Recovery-Verkehr.
9. Simulieren Sie einen vollständigen Ausfall eines Hosts.
10. Stellen Sie eine Test-VM aus einem Backup wieder her, nachdem Sie das Original zerstört haben.

Ein Proxmox Health Check deckt Schwachstellen auf Host- und Clusterebene auf; für Ceph bleibt der aussagekräftigste Test jedoch der gezielte Fehler unter Last.

Ein funktionierender Zwei-OSD-Cluster beweist noch kein gutes Design

Das Faszinierende an diesem Architekturentwurf ist, dass fast jede Einzelkomponente für sich genommen stimmig wirkt: Drei MONs sind sinnvoll, ein Knoten ohne OSD kann den Ceph-Pool nutzen, ein separates Cluster-Netzwerk entlastet den Datenverkehr, zwei OSDs können zwei Kopien speichern, und Ceph startet auch auf 1GbE oder 2.5GbE. Setzt man diese isoliert korrekten Bausteine jedoch zusammen, erhält man dennoch ein System mit mangelhaftem Ausfallkonzept.

Für einen echten Drei-Knoten-Ceph-Cluster sollten Sie drei getrennte Storage-Ausfalldomänen anstreben, die normale 3/2-Replikationsrichtlinie beibehalten und Ceph ausreichend Netzwerkbandbreite spendieren, damit Recovery-Läufe Corosync nicht gefährden. Lässt die vorhandene Hardware das nicht zu, ist ZFS-Replikation oft die Architektur, die am besten zur Realität Ihres Clusters passt.