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 on SecretMine.de