SeaweedFS: Deep Dive!

Ceph Deep Dive: RADOS, BlueStore, CRUSH, and Running a Sovereign Storage Cluster

Everything a senior engineer needs to know about Ceph in 2026: the RADOS architecture, BlueStore internals, CRUSH data placement, cephadm operations, and what Squid 19.2 and Tentacle 20.2 change for production clusters.

The One-Binary Object Store

SeaweedFS ist ein verteilter Object Store, der in Go geschrieben wurde und in einer einzigen statischen Binärdatei namens weed untergebracht ist. Er ist der Anti-Ceph auf die beste mögliche Weise: Während Ceph eine Plattform mit Monitoren, Managern und einem Dashboard ist, besteht SeaweedFS aus einer Reihe kleiner Demons, die Sie auf einem Raspberry Pi ausführen können — und die sich auf Zettabytes skalieren lassen.

Seine Superkraft ist der Datenpfad. Ein Client fragt den Master ab, wo er schreiben soll, erhält die Adresse eines Volume Servers und spricht dann direkt mit diesem Volume Server — der Master ist nicht im Datenpfad, sodass die Durchsatzskalierung von der Anzahl der Volume Server abhängt, nicht von einem zentralen Koordinator.

Die vier beweglichen Teile:

• Master — kennt jeden Volume Server (sendet alle paar Sekunden Heartbeats), weist Volume-IDs zu und reicht den Clients die Adresse des Volume Servers, der ihre Daten hält. Kleiner Speicherfußabdruck; die Metadaten eines Masters sind die Volumenkarte, nicht Ihre Dateien.
• Volume Server — speichern logische Volumes: fester Größe (Standard 30 GB), append-only-Dateien mit 4 KB-ausgerichteten Einträgen. Das Löschen einer Datei hinterlässt ein Loch; eine Hintergrund-Kompaktion reclaimt den Platz. Ein einzelner Volume Server kann viele Volumes halten (-max=32 in der Referenz-Deployment).
• Filer — die Dateisystemschicht: Verzeichnisse, Namen und Dateimetadaten (gespeichert in einer eingebetteten DB, oder MySQL/Postgres für Skalier