SeaweedFS: skaliert den Objektspeicher im Rechenzentrum S3-API, Dateisystem und Iceberg-Katalog vereint

Anbieter zum Thema

RITTAL GmbH & Co. KG

DAXTEN GmbH

dtm Datentechnik Moll GmbH

Objektspeicher im eigenen Rechenzentrum muss Milliarden kleiner Dateien effizient verwalten. SeaweedFS setzt dafür auf eine schlanke Architektur, eine S3-kompatible Schnittstelle und einen integrierten Katalog für Analysedaten.

„SeaweedFS“ legt Daten als Blobs in Volumes ab und hält je Datei nur 40 Byte an Metadaten im Arbeitsspeicher, sodass ein Server im laufenden Betrieb auch bei Milliarden Objekten mit knappem Speicher auskommt. Ein Master-Dienst verwaltet die Zuordnung von Volume zu Server, die Volume-Server halten die eigentlichen Objekte. Ein optionaler Filer ergänzt die Verzeichnisstruktur samt POSIX-Attributen für Anwendungen, die einen klassischen Dateizugriff erwarten. Der Zugriff auf eine einzelne Datei benötigt eine Festplattenoperation, denn der Master hält je Eintrag nur 16 Byte aus 64-Bit-Schlüssel, 32-Bit-Offset und 32-Bit-Größe vor. Das Projekt steht unter der Apache-Lizenz 2.0. Der Dienst läuft als kompiliertes Go-Programm.

Speicher für S3 und Dateien

Über die S3-kompatible Schnittstelle binden Anwendungen SeaweedFS wie einen Cloud-Bucket an, ohne den Anbieter zu wechseln. Der Filer stellt dieselben Daten zusätzlich als klassisches Dateisystem bereit, das sich per FUSE-Mount oder über einen CSI-Treiber in einem Kubernetes-Cluster einhängt und zustandsbehafteten Anwendungen wie Datenbanken persistenten Speicher liefert. Für kalte Daten senkt Erasure Coding den belegten Platz und hält die Redundanz aufrecht. SeaweedFS erreicht die Objekte über mehrere Zugangspfade:

• S3-API: bindet Objekte als Bucket an bestehende Werkzeuge an

• Filer: stellt dieselben Daten als Dateisystem per FUSE bereit

• CSI-Treiber: hängt Volumes als persistenten Speicher in Kubernetes-Pods ein

• ceberg-Katalog: liefert Tabellen-Metadaten an Trino, Spark und DuckDB

Verteilung über Racks und Standorte

SeaweedFS ordnet die Knoten in eine Hierarchie aus Rechenzentrum, Rack und Datenknoten. Eine dreistellige Notation steuert, wie viele Kopien das System auf jeder Stufe anlegt. Die erste Stelle steht für Kopien in weiteren Rechenzentren, die zweite für Kopien in anderen Racks, die dritte für Kopien auf weiteren Servern im selben Rack. Der Master verteilt neue Volumes nach diesen Vorgaben und hält die Kopien über die genannten Standorte hinweg konsistent.

Ein Wert von 001 legt eine zusätzliche Kopie auf einem zweiten Server im selben Rack an, ein Wert von 100 verteilt eine Kopie in ein zweites Rechenzentrum, sodass Betreiber die Ausfallsicherheit pro Datensatz an ihre eigene Standortstruktur anpassen. Die anpassbaren Erasure-Coding-Verhältnisse bleiben der Enterprise-Version vorbehalten, die freie Version nutzt feste Vorgaben. Kalte Daten legt SeaweedFS nach Regel in Erasure-codierte Volumes ab und senkt so den Platzbedarf gegenüber voller Replikation.

Katalog für Analysedaten

Neben Objekten und Dateien verwaltet SeaweedFS in den aktuellen Versionen Tabellen im Apache-Iceberg-Format. Ein Table Bucket ist ein S3-Bucket mit eigenem Iceberg-Namespace, davor sitzt ein eingebauter REST-Katalog für die Tabellen-Metadaten.

Abfrage-Engines wie Trino, Spark, Dremio, DuckDB und ClickHouse binden diesen Katalog direkt an und lesen die Daten ohne Zwischenschicht, sodass eine Analyseumgebung dieselben Tabellen abfragt, die das Rechenzentrum als Objekte im selben Cluster vorhält. Tabellen-Commits nutzen ein Compare-and-Swap-Verfahren, das gleichzeitige Schreibzugriffe ordnet und verlorene Aktualisierungen bei parallel laufenden Jobs verhindert.

Fazit

SeaweedFS deckt Objektspeicher, Datei-Zugriff und Analyse-Katalog mit einem Projekt ab und bleibt bei Milliarden Dateien im Arbeitsspeicher schlank, da die Metadaten je Datei gering ausfallen.

Die Apache-Lizenz erlaubt den Betrieb ohne Lizenzkosten. Die dreistellige Replikationsnotation regelt die Verteilung über Racks und Standorte. Der eingebaute Iceberg-Katalog verbindet den Speicher direkt mit den Abfrage-Engines der Analyseumgebung. Betreiber halten Rohdaten und Tabellen auf derselben Hardware.

SGLang: mehr Durchsatz für die LLM-Inferenz

RadixAttention nutzt den KV-Cache über Anfragen hinweg

GPUStack: bündelt GPUs verschiedener Hersteller zum KI-Cluster

OpenAI-kompatible API für Nvidia, AMD und Ascend

Coroot: eBPF liefert Telemetrie ohne Code-Eingriff

Service-Map und Analyse aus dem Kernel

HAMi: teilt GPUs im Kubernetes-Cluster auf

Speicher- und Core-Isolation für geteilte Beschleuniger

(ID:50936422)