Ceph auf 2.5GbE läuft, doch das Drumherum ist das Problem

Die Hardware sah nahezu ideal für einen kompakten Proxmox-Cluster aus: zwei Lenovo M920q-Systeme, ein M720q, jeweils 32 GB RAM, eine kleine SATA-Boot-SSD und eine 1 TB NVMe-SSD für Daten. Ein deutlich stärkerer Dell-Tower betrieb weiterhin alle VMs und LXC-Container. Der neue Cluster sollte den Ausfall eines Knotens überstehen, ohne dass die Wiederherstellung ein ganzes Wochenende verschlingt.

Bei der Speicherfrage wurde das saubere kleine Setup plötzlich kompliziert. Ceph wirkte wie die naheliegende Antwort: gemeinsam genutzter verteilter Speicher, automatische Redundanz und bessere Ausnutzung mehrerer Nodes. Das Problem waren die Begleiterscheinungen: Netzwerk-Upgrades, mehr Schreibzugriffe, weniger nutzbare Kapazität, möglicher Verschleiß bei Consumer-SSDs, Kühlung, zusätzliche Netzwerkkarten, vielleicht ein eigener Switch oder am Ende doch 10GbE. An diesem Punkt planen Sie vollwertige Infrastruktur, was deutlich aufwendiger ist als das bloße Einrichten einer Virtualisierung.

Die 2.5GbE-Frage lenkt vom Wesentlichen ab

Die am lautesten diskutierte Frage war, ob Ceph über 2.5GbE funktionieren kann. Nutzer kleiner Ceph-Umgebungen bejahten das.

Ein Anwender berichtete, Ceph problemlos über 2.5GbE zu betreiben. Ein anderer beschrieb einen Mini-PC-Cluster mit gebündelten 2.5GbE-Verbindungen, der in diesem speziellen Aufbau Spitzenwerte von rund 750 MB/s beim Schreiben und fast 900 MB/s beim Lesen erreichte. Jemand anderes merkte an, dass ein privates Ceph-Setup selbst auf 1GbE akzeptabel lief. Keine dieser Anekdoten beweist, dass 2.5GbE ideal ist, aber sie zeigen, dass Ceph auch unterhalb von 10GbE funktionsfähig bleibt.

Das relevantere Argument drehte sich darum, was passiert, wenn der Cluster stark ausgelastet ist, Rebuilds durchführt oder sich nach einem Ausfall wiederherstellt. Ceph überträgt replizierte Daten kontinuierlich zwischen den Knoten, weshalb das Speichernetzwerk deutlich mehr Last trägt als bei normalen VM-Workloads. Eine Verbindung, die bei leichter Homelab-Nutzung völlig ausreicht, wird extrem langsam, sobald eine Disk ausfällt und der Rebuild startet.

Aus diesem Grund rieten etliche Kommentatoren dennoch zu 10GbE. Einer schlug Dual-Port-Mellanox-Karten in einem direkten Ring zwischen den drei Lenovo-Nodes vor. Ein anderer betrieb bereits Intel X520- oder X550-Adapter in vergleichbaren Tiny-Systemen. Der Vorteil war praxisnah: Gebrauchte 10GbE-Hardware verhindert, dass das Netzwerk zum ersten Engpass wird, und beschleunigt Migrationen spürbar.

Die offizielle Dokumentation von Proxmox fällt vorsichtiger aus als die Homelab-Berichte. Proxmox empfiehlt mindestens 10 Gbps dediziert für den Ceph-Traffic und warnt davor, dass Wiederherstellungsverkehr die latenzkritische Cluster-Kommunikation beeinträchtigen kann, wenn alles über ein einziges Netzwerk läuft. Für NVMe-basierten Speicher wird darauf hingewiesen, dass bereits ein einzelnes schnelles Laufwerk mehr Durchsatz liefern kann, als 10GbE zuverlässig transportiert. 2.5GbE ist also möglich, bleibt aber keineswegs die wichtigste Architekturentscheidung.

Ceph kostet denselben Speicherplatz, den man bei ZFS sparen wollte

Das ursprüngliche Zögern gegenüber ZFS-Replikation lag an der Kapazität. Das Replizieren von VM- und LXC-Speicher über mehrere Nodes erschien teuer, da die Kopien Speicherplatz belegen. Ein Teil der Anziehungskraft von Ceph bestand in der Hoffnung, die drei 1 TB NVMe-Laufwerke effizienter zusammenzufassen.

Mehrere Kommentatoren wiesen darauf hin, dass auch Ceph-Replikation Kopien anlegt. Eine typische Konfiguration mit drei Replikaten speichert Daten dreifach, sodass einem kleinen Cluster für eindeutige Nutzdaten oft nur etwa ein Drittel der Bruttokapazität bleibt. Ein Nutzer brachte es trocken auf den Punkt: Ceph zaubert nicht magisch mehr nutzbaren Speicherplatz herbei. Ein anderer verglich die Optionen und kam zum selben Ergebnis. ZFS-Replikation und Ceph tauschen beide Kapazität gegen Redundanz ein.

Ceph hat andere Stärken. Der Speicher ist verteilt und im gesamten Cluster verfügbar, was einer echten hyperkonvergenten Infrastruktur viel näher kommt. Ein Laufwerksausfall nimmt nicht zwangsläufig den gesamten Rechenknoten außer Betrieb, und die Speicherschicht kann die Redundanz auf den verbleibenden Datenträgern eigenständig wiederherstellen, was ein starkes Feature ist.

Drei kleine Systeme mit jeweils nur einer zentralen NVMe-SSD liegen jedoch gefährlich nah an der Minimalgrenze eines Ceph-Clusters, und mehrere erfahrene Nutzer sahen genau darin die Schwachstelle. Einer bezeichnete drei Nodes als technisch machbar, aber extrem anfällig bei Ausfällen. Ein anderer meinte, Ceph auf drei Knoten ergebe als Lernprojekt Sinn, sei aber überdimensioniert, wenn das einzige Ziel darin bestehe, private Dienste zuverlässig am Laufen zu halten.

Bauen Sie das Lab auf, um Ceph zu verstehen, gehört dieser Aufwand zum Lernprozess. Bauen Sie es auf, um DNS, Home Assistant, Speicher oder Dienste für die Familie bereitzustellen, gelten andere Kriterien.

Das SSD-Problem wiegt schwerer als das Netzwerkproblem

Richtig interessant wurde die Diskussion beim Wechsel von der Ethernet-Geschwindigkeit zur Haltbarkeit der SSDs. Die vorgeschlagenen Nodes nutzten NVMe-Laufwerke für Endverbraucher. Mehrere Anwender warnten umgehend davor, dass Ceph Consumer-Flash-Speicher stark zusetzt, da verteilter Speicher enorme Mengen an Schreibvorgängen erzeugt. Ein Kommentator hatte Consumer-SSDs in einer kleinen Ceph-Umgebung eingesetzt und berichtete, dass diese nach etwa sechs Monaten verschlissen waren, woraufhin er sie durch Intel-Rechenzentrums-SSDs ersetzte. Das ist ein Einzelfall und kein universelles Gesetz für die Lebensdauer, doch ein solcher Erfahrungsbericht relativiert vermeintlich günstige Homelab-Hardware.

Ein weiterer Nutzer mit einem fast identischen Lenovo-Cluster erklärte, dass genau diese Einschränkung dazu führte, dass die Rechner letztlich ungenutzt blieben. Dessen neue Plattform konnte neben einem Boot-Laufwerk zwei dedizierte Ceph-SSDs aufnehmen. Andere empfahlen Enterprise-SSD-Modelle, was sofort ein Platzproblem aufwarf: Manche preiswerten Enterprise-NVMe-Laufwerke nutzen längere Bauformen, die schlicht nicht in Tiny-PCs passen.

Von da an wächst der ursprüngliche 2.5GbE-Plan immer weiter. Ein PCIe-Riser nimmt eine 10GbE-Netzwerkkarte auf. Der WLAN-Steckplatz lässt sich per Adapter manchmal für eine weitere NVMe-SSD nutzen, und manche Bastler verlegten das Proxmox-Boot-Laufwerk in diesen Slot, um SATA- oder NVMe-Kapazitäten freizumachen. Andere entfernten SSD-Gehäuse, montierten kleine Lüfter, druckten eigene Luftführungen im 3D-Drucker oder nutzten SATA-Stromadapter, um heiße Netzkarten zu bändigen. All das funktioniert, verwandelt einen sauberen Cluster aus drei Nodes aber in ein handfestes Ingenieursprojekt.

Auch Hitze war ein Dauerthema. Die Gehäuse sind winzig, das Rack ist dicht bestückt und 10GbE-Adapter werden heiß. Ein Nutzer mit einem vergleichbaren M920-Aufbau ergänzte einen eigenen 40 mm Lüfter für die Netzwerkkarte. Ein anderer Kommentator berichtete von handfesten Problemen durch thermisches Throttling. Das bestehende Rack verfügte immerhin schon über eine offene Rückseite und einen 120 mm Lüfter.

Spätestens hier lautet die Frage, wie viele Kompromisse Sie eingehen wollen, bevor das Ganze nicht mehr das einfache HA-Setup ist, das Sie eigentlich wollten. Ob Ceph auf 2.5GbE laufen kann, tritt dabei völlig in den Hintergrund.

ZFS-Replikation und PBS überzeugen im Alltag

Der stärkste Widerspruch gegen Ceph kam von Nutzern, die fragten, welches Problem eigentlich gelöst werden soll, ohne Ceph per se schlechtzureden.

Die genannte Priorität war die Wiederherstellung von VMs und LXC-Containern nach einem Knotenausfall, und viele Kommentatoren sahen das durch ZFS-Replikation abgedeckt. Die Proxmox-Speicherreplikation überträgt Gast-Volumes inkrementell auf einen anderen Node. Auch Hochverfügbarkeit lässt sich mit Replikation kombinieren, wenngleich Daten verloren gehen können, die zwischen der letzten Replikation und dem Ausfall geschrieben wurden. Dieser Kompromiss ist real, lässt sich aber auf drei kleinen Maschinen wesentlich einfacher beherrschen als verteilter Speicher.

Ein Nutzer berichtete, dass ein ähnliches Setup aus drei Mini-PCs mit lokalem ZFS und Replikation hervorragend funktionierte. Ein anderer riet, mit ZFS zu starten, da nur geschäftskritische Workloads repliziert werden müssen, was eine viel sparsamere Nutzung der 1 TB Laufwerke darstellt, als jedes Byte wie Goldstaub zu behandeln.

Wieder ein anderer hatte auf ZFS-basiertes HA vertraut, Node-Ausfälle erfolgreich simuliert und später erlebt, wie nach einem echten HA-Ereignis eine VM-Disk verschwunden war. Ein Backup rettete die Situation. Auch das ist eine Einzelerfahrung, die kein generelles ZFS-Versagen belegt, aber sie ruft in Erinnerung, dass Replikation niemals ein Backup ersetzt.

Genau an diesem Punkt kam immer wieder Proxmox Backup Server ins Spiel. Der Administrator betrieb PBS bereits als VM mit Ablage auf einem UNAS Pro und plante den Umzug auf Bare-Metal-Hardware. Etliche Kommentatoren hielten das für ein privates Setup für völlig ausreichend: Verteilen Sie die Last auf die Compute-Nodes, sorgen Sie für verlässliche Backups, akzeptieren Sie, dass ein ausgefallener Knoten einen Restore erfordert, und stecken Sie nicht unnötig viel Geld und Zeit hinein, nur um ein paar Stunden Ausfallzeit zu verhindern.

Das ist weniger glamourös als Ceph, aber wenn eine Ausfallzeit lediglich Unbequemlichkeit statt Umsatzeinbußen bedeutet, oft die vernünftigere Architektur.

Für weitere Planungsthemen rund um Proxmox beleuchtet die Mr.PlanB Proxmox-Übersicht Entscheidungen zu Clustering, Storage und Migration aus derselben pragmatischen Perspektive.

Die beste Homelab-Architektur hängt vom Lernziel ab

Die Uneinigkeit lief im Grunde darauf hinaus, worauf ein Homelab optimiert werden soll.

Eine Fraktion wünschte sich echten verteilten Speicher und echte Hochverfügbarkeit. Für sie gehörten 10GbE-Karten, Direct-Attach-Kabel, verbesserte Luftzirkulation, Enterprise-SSDs und zusätzliche Datenträger selbstverständlich dazu, und Ceph war der eigentliche Zweck des Projekts.

Eine zweite Gruppe legte mehr Wert darauf, dass Dienste stabil laufen, als auf die Komplexität der Infrastruktur. Deren Lösung hieß ZFS-Replikation für ausgewählte Gäste, PBS für die Wiederherstellung und deutlich schlankere Hardware. Fällt ein Host aus, wird das Nötige wiederhergestellt, denn ein paar Stunden Wartungsfenster kosten weniger, als jeden Tiny-PC für Ceph aufwendig umzubauen.

Dazwischen lag der pragmatische Mittelweg: Ceph jetzt auf 2.5GbE aufsetzen, das Verhalten im Betrieb beobachten und erst aufrüsten, wenn Grenzen spürbar werden. Mehrere Anwender hatten gezeigt, dass kleine Ceph-Umgebungen auf diese Weise funktionieren, sofern man Engpässe, Rebuild-Dauern, SSD-Verschleiß und thermische Limits als Teil des Experiments begreift.

Die Gesamtschau der Debatte zeigt, dass nicht 2.5GbE dieses Konzept riskant macht. Das Risiko entsteht, wenn man verteilten Speicher, Hochverfügbarkeit, maximale Kapazität, geringe Kosten, Standard-Consumer-Hardware und minimale Komplexität gleichzeitig aus drei winzigen Rechnern herausholen will. All das zusammen gibt es nicht.

In einem Testlabor macht das Ausloten dieser Kompromisse Spaß. Für eine Infrastruktur, die Tag für Tag unbemerkt funktionieren muss, bewährt sich meist die unspektakuläre Lösung.