CephFS vs. GlusterFS vs. SeaweedFS 2026: Eine Entscheidungsmatrix für die Praxis

Guide: MinIO als S3-kompatibles Backup-Ziel

Selbst gehosteter, S3-kompatibler Objektspeicher für Backups: MinIO hinter einem Nginx-Proxy, dazu ein rclone-basierter Backup-Agent mit versionierten Buckets. Ihre Offsite-Backups ohne Cloud-Rechnung

CephFS, GlusterFS und SeaweedFS werden alle "verteiltes Dateispeichersystem" genannt — und dieser Begriff trägt viel. Sie gehen von unterschiedlichen architektonischen Prämissen aus, altern unterschiedlich und passen zu unterschiedlichen Ausfallbudgets. 2026 ist die Lücke zwischen ihnen größer denn je: Ceph liefert jährlich ein neues Release, GlusterFS wird nach dem Rückzug des Sponsors nur noch von einer Rumpf-Community gepflegt, und SeaweedFS veröffentlicht monatlich mit einer Feature-Geschwindigkeit, die die anderen beiden statisch wirken lässt.

Dieser Artikel vergleicht die drei Systeme hinsichtlich Architektur, Metadaten-Handling, Konsistenz, Betrieb und Workload-Eignung — mit einer Entscheidungsmatrix am Ende. Es ist eine Bewertung, kein Benchmark: Performance-Zahlen hängen so stark von Hardware, Netzwerk und Workload-Mix ab, dass das Zitieren von Drittanbieter-Werten ohne eigenen Testlauf irreführend wäre.

Die drei Ausgangspunkte

CephFS: ein Dateisystem auf einem vereinheitlichten Storage-Cluster

CephFS ist kein eigenständiges Dateisystem. Es ist die POSIX-Fassade eines vollständigen Ceph-Clusters — Monitore (MONs) für den Cluster-Zustand, Manager (MGRs) für die Orchestrierung, OSDs für die Datenplatzierung über den CRUSH-Algorithmus sowie ein oder mehrere Metadaten-Server (MDS), die den Namespace und den Inode-Zustand verwalten. Derselbe RADOS-Objektstore darunter bedient auch Block (RBD) und Objekt (RADOSGW / S3) — genau diese Vereinheitlichung ist Cephs Existenzgrund.

Zwei Konsequenzen folgen daraus. Erstens: Betrieb ist der eigentliche Preis — ein Produktionscluster läuft mit 5–7 Daemon-Typen, jeder mit eigener Konfiguration und eigenem Ausfallmodus. Zweitens ist CephFS die vollständigste POSIX-Implementierung der drei — mehrere aktive MDS für Metadaten-Skalierung, Snapshots, Quotas, ein Kernel-Client im Mainline-Linux (schneller als FUSE) und ein Ökosystem (Rook auf Kubernetes, cephadm für den Betrieb), das kein Wettbewerber erreicht. Stand Oktober 2026 ist Ceph 19 "Squid" das ausgereifte Release; 20 "Tentacle" kam im November 2025 heraus und wird aktiv zurückportiert.

Der ehrliche Trade ist Komplexität gegen Obergrenze. Ein gesunder Cluster will mindestens drei Knoten, fünf sind komfortabel. Der Speicherbedarf ist real (als Planungsregel gilt grob 1 GB pro TB OSD-Speicher). Wenn Sie bereits Ceph betreiben, kommt CephFS fast kostenlos dazu. Wenn Sie nur Dateien brauchen, zahlen Sie für Block- und Objektspeicher, den Sie vielleicht nie nutzen.

GlusterFS: Hashing-basierte Platzierung, kein Metadaten-Server — und ein Loch in der Sponsoren-Landschaft

GlusterFS setzt auf das Gegenteil: kein dedizierter Metadaten-Dienst. Eine verteilte Hashtabelle (DHT, das "elastische Hashing") berechnet den Speicherort einer Datei aus ihrem Namen — jeder Knoten kann jede Anfrage beantworten. Die Daten liegen als normale Dateien auf dem nativen Dateisystem jedes Bricks — ein Design mit echten Resilienz-Vorteilen (kein Metadaten-Server, der verloren gehen kann; Dateien bleiben lesbar, selbst wenn der gesamte Cluster-Manager ausfällt) und echten Kosten (Verzeichnis-Traversierung berührt jeden Knoten; metadatenlastige Workloads leiden).

2026 zählt der Kontext mehr als die Architektur. Red Hat hat das Ende des Wartungsbetriebs für sein Gluster-Storage-Produkt angekündigt — End-of-Life bis Ende 2024 — und das Community-Wartungsprojekt wurde von geplanten drei Jahren auf ein Jahr fokussierter Arbeit reduziert. Die Gluster-11.x-Linie (Februar 2023) ist aktuell; der 12.0-Fahrplan ist Wunschdenken. Die Kubernetes-Integration (Heketi) wurde eingestellt. Das Community-Packaging baut 11 und 10 weiterhin für gängige Distributionen, aber neue Funktionalität kommt praktisch nicht mehr.

Das ist die entscheidende Tatsache für die Matrix unten: GlusterFS ist keine Greenfield-Wahl für 2026. Es bleibt ein vernünftiges "Weiterlaufen lassen"-System für bestehende, stabile, überwiegend große Dateien — aber jede ehrliche 2026-Vergleichsarbeit muss das laut aussprechen, weil der eigene Fahrplan des Projekts immer noch neue Nutzer anlockt.

SeaweedFS: ein Objekt-Speicher, der gelernt hat, wie ein Dateisystem auszusehen

SeaweedFS begann als ein von Facebooks Haystack inspirierter Objekt-Speicher und bekam später eine POSIX-Fassade. Der Architektur-Split ist unter den dreien einzigartig: Volume-Server speichern (weitgehend unveränderliche) Daten append-only in großen Container-Dateien, ein Master verfolgt die Volumes, und ein Filer hält den Namespace — gespeichert in einem handelsüblichen Metadaten-Store (SQLite, MySQL, Postgres, Redis o. ä.) statt in einer eigenen Journaling-Engine.

Dieser Split liefert die Kernstärke von SeaweedFS: massive Dichte kleiner Dateien bei flachem Speicherverbrauch, weil der dateisystem-sichtbare Inode-Zustand im Filer-Store lebt, während die Volume-Server append-only bleiben. Er erklärt auch die Einschränkungen, die die Community selbst diskutiert: Der Filer ist der Koordinationspunkt für alles, was knotenübergreifende Konsistenz braucht, und "korrekte" Dateisystem-Semantik musste wachsen statt vorausgesetzt werden.

Genau dieses Wachstum macht SeaweedFS 2026 interessant. Der FUSE-Mount erreichte 100 % POSIX-Konformität (Release 4.21, April 2026), erhielt Peer-to-Peer-Chunk-Sharing für KI/LLM-Workloads, und das Projekt fügte einen NFS-Server hinzu — ein Cluster bedient nun S3, WebDAV, NFS, FUSE/POSIX, eine HDFS-kompatible Schnittstelle und Iceberg-Kataloge aus denselben Daten. Der Release-Rhythmus ist monatlich (4.49 im Oktober 2026). Darüber gibt es eine kommerzielle Enterprise-Edition; dieser Artikel behandelt den Open-Source-Kern.

Konsistenz: die Dimension, die niemand erklärt

Die drei Systeme unterscheiden sich nicht nur darin, wie sie Daten speichern — sondern darin, was passiert, wenn zwei Clients zur gleichen Zeit dieselbe Datei schreiben. Genau das entscheidet, ob Ihre Anwendung funktioniert — und genau dieser Teil fehlt in den meisten Übersichtsartikeln.

CephFS ist stark konsistent. Metadaten-Operationen werden über die (ggf. mehreren) MDS-Ranks serialisiert; ist ein Schreibzugriff bestätigt, sieht ihn jeder Leser überall. Diese Strenge ist Fluch und Segen — sie ist der Grund, warum die Metadaten-Ebene von CephFS wirklich dimensioniert werden will und das System sich schwerer im Betrieb anfühlt.

GlusterFS ist auf letztliche Konsistenz (eventual consistency) ausgelegt. Ohne Metadaten-Dienst und mit Hintergrund-Self-Healing konvergieren replizierte Volumes asynchron: Ein Read direkt nach einem Write kann einen Brick treffen, der das Update noch nicht erhalten hat, und Split-Brain auf einem Replicate-Set braucht explizite Auflösung. Für Medien, Backup und überwiegend append-lastige Workloads ist das in der Praxis unsichtbar; für streng geordnete Anwendungs-Schreibzugriffe ist es eine echte Einschränkung.

SeaweedFS ist das entspannteste der drei — bewusst. Der Filer serialisiert Namespace-Mutationen, aber Daten werden unabhängig in Volumes geschrieben, und gleichzeitige Writes auf dieselbe Datei werden nicht durch ein verteiltes Lock geordnet. Das Projekt hat diese Lücke 2026 zu schließen begonnen (verteilte POSIX-Locks), aber die ehrliche Erwartung für den Open-Source-Kern ist eventual consistency bei gleichzeitigen Schreibern. Für die „ein Schreiber, viele Leser“-Muster, auf die diese Architektur zielt, ist das ein fairer Trade.

Direktvergleich

Wo jedes System tatsächlich gewinnt

CephFS gewinnt, wenn man bereits einen Ceph-Cluster besitzt — oder wenn "ein Storage-Backend" selbst die Anforderung ist. Wenn RBD bereits die VMs bedient und RGW die Objekt-Buckets, ist das Hinzufügen von CephFS für Workloads, die echte Dateien brauchen, fast kostenlos. Auf Kubernetes gilt dieselbe Logik mit Rook: ein Operator, drei Interfaces. Man zahlt die Komplexität einmal.

GlusterFS gewinnt noch an einer engen Stelle: bestehende, stabile, blockgroße Deployments, die niemand anfassen will. Wenn ein Gluster-Pool seit Jahren gut läuft, ist der Ausbau ein Projekt mit eigenen Risiken. Die ehrliche 2026-Empfehlung: eine Migration über einen Horizont von 12–18 Monaten planen, solange die Distro-Pakete existieren — aber kein überstürzter Wechsel eines Systems, das gut selbst-heilt und sequenzielle Medien sauber ausliefert.

SeaweedFS gewinnt über die Form, nicht über einen einzelnen Benchmark. Die Kombination aus S3 + POSIX + NFS + Iceberg aus einem Cluster, flacher Speicher bei zig Millionen Dateien und ein FUSE-Mount, der 2026 volle POSIX-Konformität erreichte, macht es zur stärksten Wahl für den überraschend häufigen Workload "hauptsächlich Objekte, aber meine App besteht auf einem Dateisystempfad" — Medienbibliotheken, ML-Datensätze, Bild-Thumbnails, Backup-Ziele. Für objektartige Lasten konkurriert es direkt mit MinIO; die Dateisystem-Fassade ist das Unterscheidungsmerkmal (unser SeaweedFS-Backup-Guide zeigt, wie das im Betrieb aussieht).

Die Entscheidungsmatrix

1. Neues, multi-node, dateisystem-orientiertes Vorhaben? → CephFS, wenn Sie das Betriebsbudget akzeptieren und starke Konsistenz brauchen. GlusterFS ist für Greenfield vom Tisch (Sponsor-EOL, stagnierender Fahrplan, eingestellte K8s-Integration), und SeaweedFS ist im Kern ein Objekt-Speicher, dessen POSIX-Mount Ein-Schreiber-Viele-Leser-Muster gut abdeckt, aber jünger ist als CephFS' Kernel-Pfad.
2. Überwiegend Objekte / viele kleine Dateien / Medien, mit S3 und Mount? → SeaweedFS. Es ist das einzige der drei, das in beidem wirklich stark ist — und das aktivste Projekt dieser Liste.
3. Läuft bereits Ceph (RBD/RGW)? → CephFS. Dateizugriff auf vorhandene Infrastruktur schlägt den Aufbau von etwas Neuem.
4. Migration von einem bestehenden GlusterFS-Pool? → MooseFS (einfachster Ersatz), JuiceFS (wenn Sie bereits Objekt-Speicher + DB haben) oder CephFS (wenn Sie auch Block/Objekt wollen). Daten kopieren; es gibt kein Live-Migrationswerkzeug von Gluster zu X.
5. Ein einzelner Knoten, der "nur geteilt werden soll"? → Keines davon. Ein einfacher NFS-Server, Samba oder ein einfacher Single-Node-Store ist halb so viel Arbeit. Verteilter Speicher ist die Lösung für ein verteiltes Problem; Quorum- und Netzwerk-Partitions-Mathematik bestraft zu kleine Cluster bei allen drei Systemen.

Das Ein-Satz-Fazit

CephFS ist die Antwort des erfahrenen Betreibers, wenn unified Storage oder Kubernetes-first Block/Datei/Objekt die Anforderung ist; GlusterFS ist ein gut designtes System, das seinen Sponsor überlebt hat und ein Migrationskandidat ist, keine Greenfield-Wahl; SeaweedFS ist die am schnellsten bewegte Option und der natürliche Fit, wenn S3 und POSIX sich einen Pool kleiner, dateilastiger Daten teilen sollen.