Verteilte Dateispeicherung erklärt: So funktioniert sie

Verteilte Dateispeicherung verteilt Daten über viele Knoten, sodass kein einzelner Rechner ein Engpass oder Single Point of Failure ist. Die DSGVO verlangt unter Artikel 32, dass personenbezogene Daten durch geeignete technische Maßnahmen gegen unbeabsichtigten Verlust geschützt werden — genau hier liefert verteilter Storage mit Replikation oder Erasure Coding den entscheidenden technischen Nachweis. Die Designentscheidungen — wie Daten platziert, repliziert und bei Knotenausfällen konsistent gehalten werden — unterscheiden Systeme wie Ceph, GlusterFS, HDFS, MinIO und IPFS. Jedes zielt auf unterschiedliche Workloads ab, und die Tradeoffs sind real.

Replikation versus Erasure Coding

Zwei Strategien schützen gegen Knotenausfall. Replikation speichert mehrere vollständige Kopien: Cephs Standard ist 3-fache Replikation, was bedeutet, dass ein 1-GB-Objekt 3 GB Rohspeicher belegt. Einfach nachzuvollziehen, schnell beim Lesen, teuer beim Storage. Erasure Coding teilt Daten in k Daten-Chunks plus m Paritäts-Chunks nach Reed-Solomon-Codes auf, sodass ein (10,4)-Schema 14 Chunks speichert und 4 Ausfälle mit nur 40 Prozent Overhead toleriert statt 200 Prozent. MinIO setzt standardmäßig auf Erasure Coding; Backblaze Vaults nutzen 17+3 Reed-Solomon. Erasure-Coding-Lesevorgänge sind langsamer, da Rekonstruktion mehrere Chunks erfordern kann — heiße Daten nutzen oft Replikation, kalte Daten Erasure Coding.

Consistent Hashing und Datenplatzierung

Wie entscheidet ein System, welcher Knoten welches Objekt speichert? Consistent Hashing, eingeführt in akademischer Arbeit von Karger et al. (1997) und durch DynamoDB und Cassandra popularisiert, hasht Schlüssel auf einen Ring und ordnet jeden Bereich einem Knoten zu. Das Hinzufügen oder Entfernen eines Knotens mischt nur einen Bruchteil der Schlüssel, nicht den gesamten Datensatz. Ceph nutzt CRUSH (Controlled Replication Under Scalable Hashing), einen deterministischen Algorithmus, der Objekte basierend auf einer Topologiekarte (Rack, Reihe, Rechenzentrum) platziert, sodass Replikate auf diversen Failure-Domains landen. Virtual Nodes (vnodes) pro physischem Knoten glätten Lastungleichgewichte.

Konsistenzmodelle: Stark, Eventual und Kausal

Das CAP-Theorem besagt, dass man Konsistenz, Verfügbarkeit und Partitionstoleranz nicht gleichzeitig haben kann — man wählt zwei. Starke Konsistenz (Linearisierbarkeit) bedeutet, dass Reads den neuesten Write sehen; Systeme wie Spanner und etcd bieten dies via Konsensprotokollen wie Paxos oder Raft. Eventual Consistency (DynamoDB, Cassandra, S3 für einige Operationen historisch) bedeutet, dass Replikate gegeben Zeit konvergieren, mit möglichen veralteten Reads während der Propagierung. Kausale Konsistenz bewahrt Ursache-Wirkungs-Reihenfolge ohne volle Linearisierbarkeit. Dateispeicher akzeptiert oft Eventual Consistency für Metadaten (Listing, Größe) mit starker Konsistenz für Read-After-Write desselben Objekts.

Ceph-Architektur: OSDs, Monitore, Manager und MDSes

Ceph betreibt vier Daemon-Typen. OSDs (Object Storage Daemons) speichern Objekte und replizieren sie; ein Cluster hat typischerweise 10 bis 1.000 OSDs auf Spinning- oder NVMe-Disks. Monitore (MONs) pflegen den Cluster-Zustand via Paxos; 3 oder 5 MONs bieten Quorum. Manager (MGRs) exponieren Metriken und hosten Dashboards. MDSes (Metadata Server) bedienen die CephFS-POSIX-Dateisystem-Schicht. Objektspeicher via RADOS Gateway (RGW) präsentiert S3- und Swift-APIs. Blockspeicher via RBD backing OpenStack Volumes und VM-Disks. Ein Codebase, drei Persönlichkeiten.

HDFS und sein Hadoop-Erbe

HDFS (Hadoop Distributed File System) zielt auf große sequenzielle Reads für MapReduce und Spark-Jobs ab. Dateien werden in 128-MB- oder 256-MB-Blöcke aufgeteilt; jeder Block repliziert standardmäßig 3-fach über DataNodes. Ein NameNode hält alle Metadaten im Speicher, was die Skalierung auf etwa 500 Millionen Dateien pro NameNode begrenzt. HDFS ist nicht ideal für kleine Dateien (Metadaten dominiert) oder POSIX-Kompatibilität, aber exzellent für Analytics auf TB-Datensätzen. Es wird zunehmend durch Objektspeicher (S3, GCS) verdrängt, da Compute sich in der Cloud-Ära vom Storage trennt.

Content-Addressed Storage: IPFS und Filecoin

IPFS (InterPlanetary File System) identifiziert Inhalte nach ihrem Hash (CID, Content IDentifier) statt nach Ort. Jeder, der eine Datei mit demselben Inhalt speichert, erzeugt dieselbe CID. Retrieval nutzt eine DHT (Distributed Hash Table, Kademlia-basiert), um Knoten zu finden, die den Inhalt halten. Filecoin fügt wirtschaftliche Anreize hinzu — Miner beweisen, dass sie Inhalte speichern via PoRep (Proof-of-Replication) und PoSt (Proof-of-Spacetime) und verdienen FIL-Token. IPFS eignet sich für Archivierung und dezentrale Veröffentlichung; es ist langsam für interaktive Workloads aufgrund von DHT-Lookup-Latenz (Hunderte von Millisekunden bis Sekunden).

Objektspeicher: S3, R2, B2 und MinIO

Objektspeicher präsentiert eine flache Key-Value-API: PUT ein Objekt mit einem Schlüssel, GET es zurück. Keine Verzeichnisse, keine POSIX-Semantik. Diese Einfachheit ermöglicht massive Skalierung — AWS S3 speichert Billionen von Objekten mit 11-Neunen-Durabilität. Klone wie Cloudflare R2, Backblaze B2, Wasabi und DigitalOcean Spaces implementieren die S3-API auf verschiedenen Backends. MinIO läuft on-premises als Open Source AGPL v3, oft in Kubernetes als StatefulSet, und bietet S3-kompatiblen Speicher auf Commodity-Hardware. Objektspeicher hat den Cloud-Speichermarkt weitgehend gewonnen.

Erasure Coding in der Praxis: Wie Rekonstruktion funktioniert

Wenn ein Knoten in einem Erasure-codierten System ausfällt, rekonstruieren verbleibende Knoten die verlorenen Chunks. Für einen (10,4)-Reed-Solomon-Code rekonstruieren beliebige 10 der 14 Chunks die ursprünglichen 10 Daten-Chunks via Matrixalgebra über einem endlichen Feld. Neuere Codes wie Local Reconstruction Codes (LRC, von Azure verwendet) und Hitchhiker Codes reduzieren Rekonstruktionsbandbreite durch partielle Reads.

Tail-Latenz und Hedged Requests

Verteilte Systeme haben lange Tails. Eine Anfrage, die auf eine langsame Disk oder ein überlastetes Netzwerk trifft, kann 10-mal den Median dauern. Googles Paper „The Tail at Scale" (Dean & Barroso, 2013) formalisierte Techniken: Hedged Requests senden doppelte Reads an zwei Knoten, brechen den Verlierer ab; Tied Requests koordinieren, sodass nur einer tatsächlich ausführt. Für Dateiübertragungssysteme senkt das parallele Lesen eines Objekts via mehrerer Replikate und das Nehmen der ersten Antwort die p99-Latenz drastisch.

HexaTransfer nutzt ein S3-kompatibles Backend mit clientseitiger AES-256-GCM-Verschlüsselung, sodass die verteilte Speicherschicht Durabilität übernimmt, während die Anwendungsschicht Dateiinhalte gegenüber jeder Schicht privat hält — konform mit DSGVO-Anforderungen an technische Schutzmaßnahmen nach Art. 32.

Jetzt ausprobieren: https://hexatransfer.com — kostenlos, kein Account, bis zu 10 GB.