Mit dem Aufkommen skalierbarer Plattformen sind auch skalierbare Speicher in den Mittelpunkt des Interesses gerückt. Logisch: Wer eine Compute-Plattform baut, die sich beliebig erweitern lassen soll, erreicht mit klassischem NAS-Storage wenig. Denn der kann in Sachen Wachstum mit der ihn umgebenden Plattform kaum mithalten.

Mehrere kommerzielle Produkte buhlen hier um die Gunst der IT-Verantwortlichen. Ceph gilt als Veteran der Speicherart und hat bereits einige Jahre auf dem Buckel. Andere Ansätze wie MinIO sind ähnlich gut skalierbar, beschränken aber die unterstützten Technologien im Hinblick auf sich verbindende Clients. Vergleichsweise jung ist SeaweedFS. Das "FS" im Namen verheißt dabei, dass es sich um ein Dateisystem handelt. Doch sollte sich der Administrator davon nicht blenden lassen: Wie fast in allen Produkten dieser Art werkelt auch hier unter der Haube ein Objektspeicher.

SeaweedFS ließ sich im Test vergleichsweise schnell an den Start bringen. Es liegt in Container-Form vor und es genügt, die entsprechenden Container herunterzuladen und lokal zu starten. Gaben wir den laufenden Volume-Instanzen dann noch eine Liste der zugriffsbereiten lokalen Laufwerke mit auf den Weg, konnte die Party auch schon losgehen. Gerade in Anbetracht der Tatsache, dass SeaweedFS bereits über zehn Jahre auf dem Buckel hat, ist dies eine beeindruckende Leistung, die dem Admin das Leben erheblich leichter macht.

"Kennst Du einen, kennst du alle" lautet eine Binsenweisheit, die im Kontext skalierbarer Speicher gar nicht so weit hergeholt ist. Ein Blick auf die Architektur von SeaweedFS offenbart Parallelen zu vergleichbaren Ansätzen wie Ceph oder MinIO. Insbesondere der direkte Vergleich mit Ceph bietet sich an. Denn bei beiden Angeboten werkelt unter der Haube ein skalierbarer Objektspeicher. Auch SeaweedFS betrachtet jede in den Cluster hochgeladene Datei also zunächst als binäres Objekt. Für dieses fungiert es dann zwischen Client und Datenträger (Volume) als Vermittlerschicht.

Die Anzahl der Volumes ist dabei nur theoretisch beschränkt, in der Praxis dürften Umgebungen die Grenze unterstützter Volumes – diese liegt bei etlichen Millionen – nicht erreichen. Dabei gilt es zu beachten, dass SeaweedFS nicht eine große monolithische Plattform ist. Stattdessen setzt sie sich aus mehreren Teilen zusammen (Bild 1). Der Master enthält die Metadaten der Software selbst. Hier ist also lediglich verzeichnet, welche Volume-Instanzen an die Masterserver angeschlossen sind, nicht aber, welche Daten auf ihnen liegen. Letzteres ist bei HPC-Dateisystemen wie LustreFS der Fall. Dort gilt der clusterweite Metadatendienst aber stets als SPOF und möglicher Performance-Flaschenhals. Der Master bei SeaweedFS hingegen lässt sich mehrfach redundant betreiben.

Volumes bilden die Speichersilos in SeaweedFS. Zusammen sind Master und Volume ein Schlüssel-Wert-Speicher, wobei sich bei SeaweedFS und Ceph mittlerweile die Bezeichnung "Key→Blob-Store", also "Schlüssel→Daten-Speicher" etabliert hat. Denn im Kern funktionieren diese Produkte wie eine große Datenbank für Pärchen aus Schlüssel und Wert. Der Wert ist im Kontext skalierbarer Speicher aber eben selten ein einzelner String, sondern ein binärer Datensatz, also ein "Klecks" oder im Englischen eben ein "Blob". Weil Objektspeicher per se die meisten Anwendungen aber noch nicht glücklich macht, kommt bei SeaweedFS noch eine weitere Komponente hinzu: Der Filer, der den Zugriff auf SeaweedFS in Form eines POSIX-kompatiblen Dateisystems ermöglicht.

Nicht unerwähnt bleiben soll an dieser Stelle die Weboberfläche, die jeder einzelne SeaweedFS-Dienst zur Verfügung stellt. Ganz gleich ob Volume-Server oder Filer: Sie alle haben ein einfaches HTTP(S)- basiertes Webinterface, über das sich die Konfiguration des Dienstes ebenso einsehen lässt wie aktuelle Nutzungsstatistiken. Wer vorrangig auf der Kommandozeile unterwegs ist, mag das für eine Spielerei halten. Die Erfahrung zeigt aber, dass diese Art von Schnittstelle durchaus gefragt ist. Nicht aus Versehen haben etwa auch die Ceph-Entwickler in den vergangenen Jahren viel Zeit in die Entwicklung ihres Dashboards gesteckt.

Neben den offensichtlichen Gemeinsamkeiten zwischen SeaweedFS und vergleichbaren Produkten ergeben sich zur Konkurrenz auch deutliche Unterschiede. Während etwa Ceph unter der Haube einen Algorithmus namens CRUSH nutzt, um die Platzierung von Daten im Objektspeicher zu realisieren, setzt SeaweedFS auf eine dezentrale Metadaten-Datenbank in Form der Volume-Dienste. Die Masterserver (Bild 2) sind lediglich dafür zuständig, sich zu merken, welche Volume-Dienste (Bild 3) existieren. Die einzelnen Volume-Instanzen managen ihre Daten und Metadaten dann selbst.

Sind abgelegte Daten also einmal einem Volume in SeaweedFS zugeordnet, ist nur noch dieses für den Zugriff und das Ausliefern zuständig. Daraus ergibt sich eine "O(1)"-Zugriffszeit, wie die Entwickler gebetsmühlenartig betonen: Für das Ausliefern einer Datei an einen Client ist in SeaweedFS stets nur ein einzelner Lesevorgang auf der jeweiligen Volume-Instanz notwendig. Daran zeigt sich, dass Performance bei der Entwicklung von SeaweedFS eine große Rolle spielt.

In Sachen Redundanz und Datensicherheit gibt sich das Werkzeug keine Blöße. Innerhalb des Speichers, also zwischen den Volume-Instanzen, lässt sich Replikation konfigurieren. Dabei glänzt SeaweedFS mit einiger Vielfalt. Anders als beispielsweise bei Ceph, wo nur 1-zu-1-Replikation synchron sowie Erasure Coding mit Einschränkungen zur Verfügung steht, hat der Administrator bei SeaweedFS die Wahl zwischen einfacher Replikation, Erasure Coding und anderen Mechanismen. Das umfasst auch die Möglichkeit, den Speicher über Fehlerdomänen, also etwa über Brandschutzzonen oder wenigstens einzelne Racks, hinweg zu sichern.

Ein skalierbares Werkzeug muss die Möglichkeit bieten, während des laufenden Betriebs leicht erweiterbar zu sein. Hier leistet sich die Konkurrenz bisweilen böse Patzer: Ceph beispielsweise, das als Platzhirsch im Marktsegment der freien Netzwerkspeicher gilt, berechnet die Platzierung von Daten im Hintergrund mittels des CRUSH-Algorithmus. Weil es sich dabei um einen Algorithmus auf Grundlage von Hashwerten handelt, in deren Berechnung die momentane Topologie des Clusters einfließt, führt die Veränderung derselben auch zu massiv abweichenden Placement-Entscheidungen.

Das gilt bei RADOS, dem Kern von Ceph, dann nicht nur für neue Dateien, sondern auch für den bereits bestehenden Datensatz. Wer einen Ceph-Cluster um etliche neue Server zeitgleich erweitert, wird unfreiwillig Zeuge des großen Schaufelns: Um die Soll-Verteilung nach CRUSH zu erreichen, verschiebt Ceph innerhalb des Clusters dann nämlich eine riesige Menge an Daten. Andere Produkte wie GlusterFS haben im Design ähnliche Defizite.

SeaweedFS geht die Sache anders an: Hier findet die Placement-Entscheidung lediglich beim Hochladen einer neuen Datei in den Cluster statt. Liegt eine Information einmal auf einer Volume-Instanz, bleibt sie dort. Fügt der Administrator also zusätzliche Volume-Instanzen hinzu, hat das auf den bestehenden Datensatz keine Auswirkungen. Unbenommen bleibt dem Administrator dabei die Option zur händischen Rebalancierung der Daten.

Deren Art und Umfang lassen sich regeln, sodass nicht etliche TByte im schlechtesten Fall gleichzeitig umziehen. Implizit verhindert SeaweedFS anders als die Konkurrenz damit auch jede Menge des gefürchteten "Recovery"-Traffics – selbst nach einem Ausfall blockiert der Speicher also nicht stundenlang das lokale Netz.

Schlechter als die Konkurrenz schneidet SeaweedFS hingegen ab, was die Vielzahl der verfügbaren Schnittstellen betrifft. Hier kann Ceph beispielsweise darauf verweisen, dass es in Form von RBD auch eine Emulation für virtuelle Blockspeichergeräte im Gepäck hat. Für diese existiert in Qemu eine eigene Schnittstelle, sodass dieses unmittelbar mit dem Objektspeicher RADOS im Kern von Ceph reden kann. Ein Umweg über den Kernel des jeweiligen Hosts ist nicht nötig.

SeaweedFS bietet eine solche Funktion nicht. Zwar finden sich im Netz einzelne Berichte von Anwendern, die SeaweedFS lokal als POSIX-Dateisystem einhängen und darauf dann Abbilder für Qemu ablegen. Ein sonderlich häufiger Einsatzfall dürfte das aber nicht sein.

Wie erwähnt handelt es sich bei SeaweedFS im Kern um einen Objektspeicher. Damit wäre es prinzipiell gut für Einsatzgebiete geeignet, die einen echten Objektspeicher benötigen – etwa als Ersatz für Amazon S3 in der Cloud. Praktisch ist der Nutzen eines verteilten Speichers, der nur ReST spricht, allerdings begrenzt. Aus diesem Grund stellen die SeaweedFS-Entwickler einem Masterserver und seinen Volume-Instanzen einen zusätzlichen Dienst an die Seite, der bei Bedarf durch den Administrator zu installieren ist: Den Filer. Der erweitert die Metadaten von Objekten in SeaweedFS um echte POSIX-Semantiken.

Filer-Instanzen selbst sind dabei zustandslos; sie beziehen ihre Daten mitsamt der korrespondierenden Metadaten direkt aus den verbundenen Volume-Instanzen. Die Filer selbst speichern allerdings in ihren Metadaten die Information ab, welche Objekte wo liegen. Im Hinblick auf die unterstützten Backends für seine eigenen Metadaten gibt der Filer sich dabei vielfältig. Wichtig hierbei: Die Art und Weise, wie Storage-Systeme für den Dateizugriff ihre Metadaten speichern, spielt für das Ausliefern der eigentlichen Dateien und die Geschwindigkeit dieses Vorgangs eine entscheidende Rolle. Die Ceph-Entwickler haben für ihr Produkt beispielsweise gar ein eigenes Dateisystem namens BlueFS entwickelt, das auf weite Teile der POSIX-Semantiken auf den Datenträgern verzichtet und stattdessen einen einfachen Key-Value-Speicher auf RocksDB-Basis implementiert. Der ist allerdings fest in die OSDs, also die Datensilos in Ceph, integriert.

Weil der Filer de facto eine separate, zusätzlich zu verwendende Komponente für SeaweedFS ist, handhaben die Entwickler die Dinge lockerer. Je nach Einsatzszenario kann der Administrator entscheiden, in welchem Backend die Filer-Instanzen ihre Metadaten ablegen können. Abhängig vom Einsatzzweck kann die beste Variante deshalb MySQL sein. Infrage kommen aber auch PostgreSQL, Redis, Cassandra, HBase, MongoDB, CockroachDB oder Etcd. Der Filer kümmert sich dabei stets um das Ausliefern der Metadaten für POSIX in Richtung Client. Der gewählten Datenbank kommt im Hintergrund die Aufgabe zu, die Metadaten des Filers flott zu speichern und zu verwalten.

Wie beschrieben lässt sich der Filer auch als HTTP(S)-basierter Objektspeicher im Stil von Amazon S3 nutzen. Ähnlich der Konkurrenz bringt SeaweedFS dabei eine eigene API-Schnittstelle mit, die in weiten Teilen kompatibel zu S3 ist. "In weiten Teilen" deshalb, weil die einzige, wirklich S3-kompatible Variante eben das Original bleibt. Auch wenn angesichts der diversen S3-Nachbauten im Softwareumfeld oft der Eindruck entsteht, S3 sei ein offener Standard, trifft das nicht zu.

Denn alle S3-Nachbauten fußen auf der S3-SDK-Dokumentation von AWS und einer ordentlichen Portion Reverse Engineering – auch jene von SeaweedFS. Dass das rechtlich ein Problem ist, weil Amazon theoretisch auf die Idee kommen könnte, Drittherstellern die Implementierung von S3-Kompatibilität zu verbieten: geschenkt. Denn von diesem Problem wäre nicht nur SeaweedFS betroffen, sondern auch die Konkurrenz von Ceph oder MinIO. Hier ergibt sich für SeaweedFS also weder ein Vor- noch ein Nachteil.

Die S3-Schnittstelle ermöglicht recht interessante Konfigurationen. So existieren beispielsweise für alle relevanten Frameworks der Webentwicklung heute S3-Integrationen. Das versetzt Entwickler indirekt in die Situation, sich eine Art eigenes Mini-CDN zu bauen: Verteilen wir S3-kompatible Dienste global, lassen sich Requests in einzelnen Regionen per DNS zur "lokalen" Instanz des Speichers routen. Das entlastet auch die Websetups per se: Wo es früher gang und gäbe war, geteilte Dateien auf ein geteiltes Dateisystem wie NFS zu legen und jeweils die Webserver auch Assets wie Bilder oder Videos ausliefern zu lassen, hat es sich vielerorts längst eingebürgert, im Quelltext einer Website für Assets direkt auf einen externen Dienst – etwa ein SeaweedFS mit S3-Schnittstelle – zu verweisen und den Client die Daten von dort direkt herunterladen zu lassen.

SeaweedFS bietet dabei noch einige nette Zusatzfunktionen. Über Parameter in der URL lässt sich das System beispielsweise dazu bringen, Bilddateien beim Ausliefern gleich passend zuzuschneiden: Anstelle von "http://localhost:8080/3/01637037d6.jpg" nutzt der Entwickler "http://localhost:8080/3/01637037d6.jpg?height=200& width=200&mode=fit" als URL, damit der Browser die Grafik gleich passend ausspielt. Darüber hinaus bietet SeaweedFS beim Ausliefern von Dateien per S3 viele Möglichkeiten, die Dateinamen dynamisch zu bestimmen. Anstelle der eigentlichen URL des Bildes "http://localhost:8080/3,01637037d6.jpg" lässt sich ohne weitere Konfiguration in der URL auch "http://localhost:8080/3/ 01637037d6.jpg" nutzen. SeaweedFS verteilt trotzdem die passende Datei. Insgesamt dürfte die S3-Schnittstelle mit ihren vielen Komfortfunktionen zu den unterschätzen Bestandteilen der Software gehören.

Eine zentrale Frage ist selbstverständlich jene nach der Performance. Denn gerade die ist es ja, die laut Aussage der SeaweedFS-Entwickler das Alleinstellungsmerkmal ausmacht und die Konkurrenz ausbooten soll. Papier indes ist geduldig, und Zahlen haben mit Tränen gemeinsam, dass sie nicht lügen. Ein paar grundlegende Versuche im Labor allerdings liefern gemischte Ergebnisse. Insbesondere im Hinblick auf Workloads mit vielen kleinen Dateien ist SeaweedFS tatsächlich signifikant schneller als Ceph in einer ähnlichen Konfiguration.

Das liegt aus den beschriebenen Gründen auf der Hand: In Ceph führt jeder Schreibvorgang in den Cluster zu mehreren Kalkulationen des CRUSH-Algorithmus. Zu dieser mehrfachen "Performance Penalty" gesellt sich die Latenz des Netzwerks hinzu, die ein einzelner Schreibvorgang in Ceph ebenfalls wegen der internen Replikation mehrmals abbekommt. Diese Rechnerei entfällt bei SeaweedFS, sodass es insbesondere im direkten Test von zufälligen Schreibzugriffen bei einer Queue Depth von 1 – also nur einem Schreibvorgang zur selben Zeit – dramatisch besser abschneidet als Ceph. Aus Ceph-Sicht sind die Werte dabei fast schon verheerend: Bei einer Blockgröße von einem MByte ist Ceph im direkten Vergleich nicht mal halb so schnell, und zwar bei aktivierter, doppelter Replikation. Reduzieren wir die Anzahl der Kopien in SeaweedFS auf eine, fällt der Performancevorteil noch größer aus.

Noch schlimmer aus Ceph-Sicht werden die Zahlen bei kleineren Objekten, etwa 4K-Blöcken. Denn schon bei doppelter Replikation in SeaweedFS erreicht dieses noch immer ein Vielfaches der IOPS-Werte beim Schreiben mit 32 Threads. Stellen wir beim Schreiben mit einer Queue Depth von 1 – also exakt einem Thread – die IOPS-Werte von Ceph und SeaweedFS in einem Balkendiagramm gegenüber, ist der Balken von Ceph kaum noch zu erkennen: Hier liefert SeaweedFS 10.000 IOPS unter realistischen Bedingungen, während selbst ein perfekt getuntes Ceph kaum mehr als 2000 IOPS erreicht. Das eigene Versprechen, gerade für Workloads mit vielen kleinen Dateien und zufälligen Schreibvorgängen besser geeignet zu sein als die Konkurrenz, verwirklicht SeaweedFS also eindrucksvoll.

Allerdings lassen sich den Performancetests auch andere Details entnehmen. Lesevorgänge mit hoher Parallelität beispielsweise wickelt Ceph sowohl bei kleinen als auch bei großen Blockgrößen zuverlässig besser als SeaweedFS. Gerade das zufällige Lesen bei 32 Threads und 4K-Blockgröße fällt dabei auf, denn hier sind die Kräfteverhältnisse quasi umgekehrt: In einem Balkendiagramm verschwinden die SeaweedFS-Balken, weil jener von Ceph so viel größer ist. Einerseits fällt beim Lesen in Ceph die CRUSH-Performance-Strafe nicht so hoch aus. Denn beim Lesen verbinden sich Clients stets nur mit jener Festplatte, die als primär zuständig für ein bestimmtes Objekt gilt. Und andererseits ist die Form der internen Datenhaltung bei Ceph offensichtlich viel besser auf Lese- als auf Schreibvorgänge ausgelegt.

Damit gilt, was in der Storage-Welt so häufig der Fall ist: Ein Nagel ist ein guter Werkstoff für den, der ein Bild aufhängen möchte und einen Hammer hat. Wer einen Schrank an der Wand montieren will, braucht aber eher Schrauben und einen Bohrer. Je nach Einsatzzweck und Installation vor Ort können SeaweedFS und Ceph ihre Stärken voll ausspielen. Kompromisse müssen IT-Verantwortliche aber stets dort eingehen, wo die interne Technik der Speicherlösung nicht zum eigenen Use-Case passt.

SeaweedFS stellt eine gute Alternative zu etablierten Produkten wie Ceph oder GlusterFS dar, auch wenn es noch nicht für sich in Anspruch nehmen kann, eine vergleichbar große Benutzerbasis zu haben. Immerhin ist kommerzieller Support direkt vom Hersteller verfügbar. Technisch punktet SeaweedFS an mehreren Stellen mit klugen Designentscheidungen, die das Produkt im Rennen mit Ceph & Co. die Nase ein Stück weit vorne haben lassen: Weil kein Algorithmus zum Einsatz kommt, entfallen die langwierigen Placement-Kalkulationen, die Ceph-Administratoren regelmäßig die Laune verhageln.

Der Funktionalität tut das indes keinen Abbruch: Weder in Sachen Skalierbarkeit noch in Sachen Vielfalt gibt sich SeaweedFS großartig Blöße. Wollten wir das Haar in der Suppe finden, wäre der naheliegendste Kritikpunkt, dass SeaweedFS keine Schnittstelle für Blockspeicher zur Verfügung stellt. Damit ist es nicht ganz so nahtlos in Umgebungen mit Qemu oder VMware (über den Umweg von iSCSI oder NVMe-over-Fabric) einzusetzen wie die Konkurrenz. Allerdings lässt sich das Problem durch Verwendung des Filers mit POSIX-kompatiblen Dateisystem leicht umgehen. Kurzum: Wer auf der Suche nach einer skalierbaren Speicherlösung ist, sollte SeaweedFS wenigstens evaluieren.