Ceph on SecretMine.de

Verteilter Speicher im Homelab

Sun, 17 May 2026 00:00:00 +0000

Ich habe bekanntlich seit einiger Zeit Docker Swarm im Einsatz. Als Storage war anfangs ein mit NFS geteiltes DRBD-Volume im Einsatz, also replizierter Blockspeicher. Funktioniert hat das, war aber langsam.

Daher habe ich mir diverse Lösungen für verteilten bzw. replizierten Speicher angesehen und ausprobiert. Ziel war einerseits, replizierten und ausfallsicheren Storage für Docker Swarm zu bekommen, andererseits aber auch, einen größeren Speicherbereich für unwichtige Daten zu erhalten.

Anforderungen

Um eine vernünftige Auswahl treffen zu können, sollten vorher natürlich die konkreten Anforderungen klar sein.

Muss:

Unterstützung von verteiltem und repliziertem Storage
Hochverfügbarkeit (weiterhin funktionsfähig bei Ausfall von 1/3 Nodes)
Kostenfrei nutzbar
(halbwegs) aktives Projekt, nicht abgekündigt bzw. sichtbar inaktiv

Soll:

Open Source

Kann:

Metriken/Monitoring

Softwarelösungen

Ceph

Ceph ist eine gängige Lösung für hochverfügbaren Speicher und wird im sehr großen Stil eingesetzt. Es ist zudem in Proxmox VE integriert, womit sich schnell ein hyperconverged Cluster einrichten lässt.

Die Performance hat mir sehr gut gefallen, es war die schnellste getestete Lösung. Ceph lässt sich auch super konfigurieren und Pools mit verschiedenen Replikationsregeln erstellen. Der Ausfall einer Node wurde gut verkraftet, nach dem Hinzufügen war die Redundanz auch sehr schnell wiederhergestellt.

Problematisch für mich ist hier allerdings der Ressourcenbedarf. Ceph hat mit allen Komponenten pro Node 2-3 GB an RAM verbraucht, das ist mir mit den Thin Clients zu viel. Außerdem ist Ceph bekannt dafür, eine hohe Schreiblast auf den Datenträgern zu erzeugen. Auf Dauer könnte Ceph aber trotzdem die präferierte Lösung sein.

GlusterFS

Im Vergleich zu Ceph arbeitet GlusterFS auf Datei- und nicht auf Blockebene. Replizierte und verteilte Volumes werden unterstützt, auch erasure-code-basierte Volumes sind möglich. Es ist trotzdem weniger flexibel als Ceph, was die Replikationsoptionen angeht. Monitoring ist leider auch eher schwierig, es gibt aber einen halbwegs gepflegten Prometheus-Exporter.

GlusterFS wurde irgendwann von Red Hat gekauft, die es dann neben der Open-Source-Version als Red Hat Gluster Storage vermarktet haben. Das Red Hat Produkt hat allerdings Ende 2024 das Ende seines Lebenszyklus erreicht. Die Aktivität bei Github ist in den letzten Jahren auch stark gesunken, letztes Jahr waren es ~20 Commits im Repo. Das spricht deutlich gegen GlusterFS.

Vom Ressourcenbedarf her ist es angenehm, ich sehe kaum nennenswerten RAM- und CPU-Bedarf. Die Performance ist insgesamt auch okay, wenn auch geringer als bei Ceph.

MooseFS

Vom Prinzip her gefällt mir MooseFS. Man kann pro Verzeichnis die Anzahl der Kopien festlegen, beim über- oder unterschreiten durch Entfernen bzw. Hinzufügen von Volumes wird dann automatisch nachgesteuert. Die Performance ist ebenfalls in Ordnung, auch wenn es primär für Medien und andere größere Dateien ausgelegt ist. Bei vielen kleinen Dateien habe ich - zumindest bei den Forks von MooseFS - deutlich geringere Performance als bei Ceph gesehen.

Das Ausschlusskriterium für MooseFS war allerdings die fehlende Hochverfügbarkeit in der Open-Source-Version. Für dieses Feature benötigt man eine Pro-Lizenz.

LizardFS

Das ist ein Fork von MooseFS, der von den Funktionen her ziemlich gleich ist, allerdings auch Hochverfügbarkeit enthält. LizardFS wird allerdings seit mehreren Jahren nicht mehr weiterentwickelt, das Repo bei Github ist inaktiv.

LeilFS (vorher SaunaFS)

LeilFS ist ein Fork von LizardFS, laut den Infos, die ich finden konnte, sind wohl diverse Entwickler von LizardFS dort nun aktiv. Prinzipiell sieht LeilFS gut aus, es gibt bisher allerdings nur für Ubuntu fertige Pakete. Ich habe aber mit wenig Aufwand Pakete für Debian 13 kompilieren können.

Die Dokumentation lässt (zumindest bisher) auch sehr zu wünschen übrig. Das meiste habe ich mir bei LizardFS angesehen und nur die entsprechenden Bezeichnungen angepasst. Trotzdem hinterlässt das einen etwas faden Beigeschmack.

Dennoch ist es eine flexible und eher ressourcensparsame Option.

Weitere Lösungen

Folgende Möglichkeiten möchte ich zumindest erwähnt haben, auch wenn ich nicht im Detail darauf eingehen werde:

LINSTOR: Verteilte Block-Devices, basiert auf DRBD
S3 plus JuiceFS: Mit hochverfügbarem S3 in Verbindung mit JuiceFS lässt sich theoretisch auch ein hochverfügbares Dateisystem aufsetzen
DRBD plus NFS: Etwas klassischer, aber funktioniert
ZFS mit Replikation: Proxmox bietet Unterstützung dafür. Nicht direkt volles HA, aber für Homelab und kleine Produktion wahrscheinlich ausreichend

Fazit

Ceph ist eine gebräuchliche Lösung, weit verbreitet, aktiv gepflegt und auch schnell. Also eigentlich ideal. Es benötigt aber leider zu viele Ressourcen, ist also bei den aktuellen RAM-Preise eher eine Lösung für “irgendwann”.

Aktuell wird jetzt DRBD erst einmal durch GlusterFS ersetzt. Ich habe damit in der Vergangenheit viel zu tun gehabt und kenne mich weit genug aus, auch wenn es seine Nachteile hat. Regelmäßige Sicherungen mache ich natürlich, daher halte ich das Risiko für Datenverlust für überschaubar.

Für Massenspeicher kommt neben GlusterFS auch LeilFS zum Einsatz, da liegen z.B. ISOs/Templates für Proxmox, Medien und anderer Kram darauf. Ich habe mir verschiedene Storage-Klassen konfiguriert, die teilweise auch hochverfügbar sind. Dazu aber in einem weiteren Beitrag mehr.

GlusterFS ist für mich trotzdem nur eine Zwischenlösung, auf Dauer bleibt Ceph (inkl. CephFS) das Ziel. Einfach weil es verbreiteter und besser gepflegt ist. Aber das wird auf niedrigere RAM-Preise warten müssen. Als Massenspeicher für Dinge wie Medien, Backups, ISOs und co werde ich erst einmal LeilFS evaluieren.

Storage-Cluster - Part 2: Erster PoC und Planänderungen

Sat, 28 Mar 2026 00:00:00 +0000

Storage-Cluster - Ein erster PoC

Der Plan sieht Futro S740er mit SATA-Controllern vor. Einen entsprechenden Controller auf Basis des ASM1166 (energieeffizienter und gut unterstützter SATA-Controller) habe ich gekauft und mit einem NVMe-Adapter verbaut.

Zugegeben, der PoC sieht etwas wild aus. Am HBA hängen drei SSDs, den Strom bekommen die SSDs über USB zu SATA-Strom-Adapter. Das funktioniert, da 2,5-Zoll-Laufwerke normalerweise nur 5V und keine 12V benötigen, SATA hat eigentlich auch 12V anliegen.

Auf dem Futro läuft Proxmox, der Thin Client ist in meinen normalen Cluster eingebunden.

Ergebnisse vom PoC

Erst habe ich Ceph getestet. Hier hat sich schnell gezeigt, dass 4GB RAM für Ceph einfach zu wenig ist. Das ist schade, da ich Ceph eigentlich gerne genutzt hätte. Es war aber absehbar, dass das nicht klappt.

Ohne Proxmox und weitere Services würde es vermutlich knapp passen, es ist mir allerdings zu heikel.

Alternative zu Ceph

Ich brauche eine Lösung, die halbwegs brauchbare IOPS liefern kann. SaunaFS ist zwar sehr flexibel und kann natürlich auch Replikation, erreicht aber nicht die IOPS-Werte, die ich benötige.

Daher kommt vorerst GlusterFS zum Einsatz, das benutze ich auch jetzt schon für meinen Docker Swarm für persistenten Speicher. GlusterFS ist sehr viel schlanker als Ceph, allerdings auch langsamer und insgesamt schlechter zu administrieren. Ob es tatsächlich die bessere Wahl für mich ist wird sich mit der Zeit zeigen.

Wie es weitergeht

Ich habe die weitere Hardware für den Cluster hier schon liegen, von daher dürfte zeitnahe auch der Post zum vollständigen Setup kommen. Nebenbei bin ich dabei, Ansible-Rollen für die diversen Services zu entwickeln, da ich keine Lust habe, das meiste von Hand zu machen.

Auch habe ich ein 3D-Modell für eine alternative Abdeckung mit großer Öffnung für die SATA-Kabel erstellt, das habe ich auch schon gedruckt und getestet. Damit kann ich die Futros trotzdem schließen und muss die originale Abdeckung nicht beschädigen.

Zusätzlich habe ich auch ein Modell erstellt, was als Halterung für die Futros und die SSDs/HDDs dient. Davon passen dann auch drei nebeneinander in ein Kallax-Fach. Das dürfte insgesamt für mehr Ordnung sorgen und trotzdem Zugriff zu allem ermöglichen.

Storage-Cluster - Part 1: Der Plan

Sat, 28 Feb 2026 00:00:00 +0000

Storage-Cluster - der Plan

Wer regelmäßig mit Virtualisierung, Containern und Selfhosting arbeitet, kennt das Problem: der Storage wächst einem über den Kopf. Auch bei mir sind die bisherigen Nodes inzwischen so stark ausgelastet, dass für größere Storage-Aufgaben schlicht kein Platz mehr ist. Zeit also für den nächsten Ausbauschritt in meinem Homelab – ein (weitestgehend) dedizierter, energieeffizienter und möglichst robuster Storage-Cluster.

Das Ziel

Wie auch in größeren IT-Projekten üblich, beginnt alles mit der Zielsetzung bzw. der Erfassung der Anforderungen.

Ich brauche einerseits Storage, der schnell ist und den Ausfall einer von drei geplanten Nodes verkraftet, andererseits Massenspeicher für z.B. Medien, LXC-Templates, ISOs und co, der nicht hochverfügbar sein muss und auch nicht die selben Geschwindigkeiten erreichen muss. Auf dem schnellen Speicher sollen wichtige VMs/LXCs liegen (bspw. DNS und HomeAssistant), daneben soll dieser Bereich auch als Speicher für Docker Swarm dienen.

Am liebsten hätte ich hier natürlich vollständige Hochverfügbarkeit, also keinen einzelnen Single-Point-of-Failure (redundantes Netzwerk, redundante Stromversorgung, …). Das ist für Zuhause aber einerseits overkill und andererseits weder finanziell noch energetisch sinnvoll. Daher möchte ich eine möglichst gute Verfügbarkeit erreichen, ohne dabei komplett in den Enterprise-Bereich vorzudringen.

Die bisherigen Nodes sind mit ihren eigentlichen Aufgaben zu stark ausgelastet, um hier sinnvoll auch noch Storage machen zu können. Das ist so gerade zwar im Einsatz, ich merke allerdings, dass ich mich damit zu nahe an der Grenze bewege.

Der Plan

Ich habe über die letzten Wochen einen Plan erarbeitet, PoCs aufgesetzt und vieles ausprobiert. Bisher ist der Cluster noch nicht aufgebaut, aber ich denke, dass ich mit der Auswahl an Hardware und Software mein Ziel erreiche.

Hardware. Natürlich Thin-Clients

Die Hardwarebasis bilden drei Fujitsu Futro S740 Thin Clients. Dass ich die Dinger mag, ist bekannt. Die Wahl fiel auf dieses Modell, da es günstig ist, sehr energieeffizient läuft und genügend Erweiterungsmöglichkeiten bietet. Der Plan ist hierbei, in der ersten Ausbaustufe den WiFi-Slot für einen SATA-Controller zu nutzen. Später soll der SATA-Controller dann in den SSD-Slot (der laut Internet neben SATA auch PCIe-Anbindung hat) wandern und der WiFi-Slot für eine 2,5 GBit/s Netzwerkkarte genutzt werden.

Geplanter Ausbau pro Node:

4 GB RAM
1x 16/32GB für das OS (meistens dabei)
1× 480 GB SSD (für Ceph)
1× 1 TB HDD (für SaunaFS oder Alternativen)
SATA-Controller über den WiFi-Slot (Adapterlösung)
Später Upgrade auf 2,5 Gbit/s LAN

Das Netzwerk wird anfangs über meine bestehende 1 GBit/s-Infrastruktur gelöst, später ist hier ein zusätzlicher 2,5 GBit/s Switch geplant. Ich rechne ohne Datenträger mit Kosten von ca 75 € pro Knoten, was ich für nicht viel halte. Ohne Datenträger bekomme ich damit für etwas über 200 € einen weitestgehend redundanten Storage-Cluster.

Software

Für den Storage-Cluster sollen zwei Software-Lösungen zum Einsatz kommen. Ceph wird für den schnellen Speicher genutzt, der Massenspeicher wird nach aktuellem Stand auf SaunaFS aufbauen. Ceph habe ich ausgesucht, da es von Proxmox nativ unterstützt wird und dort sogar gut integriert ist. Neben Blockspeicher kann ich dort über CephFS auch Freigaben auf Dateiebene erzeugen, was ich für Docker Swarm benötige. Es ist zudem performant und im Enterprise-Bereich stark vertreten. Für den langsameren Speicher habe ich lange überlegt, was ich nutzen möchte. Erst hatte ich GlusterFS vorgesehen. Mittlerweile habe ich mich hier aber umentschieden und möchte SaunaFS einsetzen. Das ist ein Fork von LizardFS, was wiederum ein Fork von MooseFS ist. Es ist für verteilten Massenspeicher ausgelegt, hat eher wenig Overhead und bietet sogar die Option, die Anzahl der Replikas pro Ordner festzulegen.

Auf jedem der Futros wird dementsprechend Proxmox VE installiert und die Nodes in den bisherigen Cluster eingefügt. Die SSDs werden als OSDs für Ceph genutzt, die zusätzlichen Datenträger dann als Mountpoints an einen LXC pro Node angebunden. Dort wird dann SaunaFS installiert. SaunaFS kann ich aufgrund der Voraussetzung von Ubuntu als OS leider nicht direkt auf den Knoten installieren, die Variante mit SaunaFS habe ich jetzt aber auch schon eine Weile im Haupt-Cluster im Testbetrieb erfolgreich genutzt.

Das SaunaFS-Volume wird dann von einem Knoten via Samba und NFS freigegeben. Das hat den Hintergrund, dass es mit vielen Dingen kompatibel ist und sich so z.B. auch in Proxmox als Speicher für Templates und ISOs gut einbinden lässt.

Weitere Ideen und mögliche Dienste

Wenn die Performance passt, sollen auf dem Storage-Cluster später auch leichte Dienste laufen und damit die bestehenden Nodes etwas entlastet werden. Kandidaten dafür sind Dinge wie der Proxmox Backup Server oder auch Komponenten von meinem Monitoring-Stack.

Ob das mit 4 GB RAM pro Node praktikabel ist, wird sich erst zeigen - mehr RAM kaufen ist aber aufgrund der Lage am Markt gerade keine Option.

Nächste Schritte

Ich habe Hardware bestellt, um einen Futro mal mit einem SATA-Controller auszustatten und damit schonmal als Storage (ohne Ceph oder Replikation oder so) einzusetzen. Das dient als erster Test. Wenn das so funktioniert, wie ich mir das vorstelle, werden weitere Futro S740er gekauft und der Cluster aufgebaut.

Ich nehme dafür den Futro, den ich eigentlich für den 3D-Drucker gekauft hatte. Dort kommt einfach wieder der S520 hin. Das bietet sich an, da ich für den 3D-Drucker wenig Leistung brauche, der Futro S520 eh nichts zu tun hat und ich so gut etwas Geld sparen kann.