Rozproszone przechowywanie plików: jak to działa

Rozproszone przechowywanie plików rozprzestrzenia dane po wielu węzłach, tak by żadna pojedyncza maszyna nie była wąskim gardłem ani jednym punktem awarii. Decyzje projektowe — jak rozmieszczać dane, jak je replikować, jak obsługiwać awarie węzłów, jak zachować spójność — odróżniają systemy takie jak Ceph (obiekt/blok/plik), GlusterFS (POSIX), HDFS (wsadowe big-data), MinIO (zgodny z S3) i systemy adresowane treścią jak IPFS i Filecoin. Każdy celuje w inne obciążenia, a kompromisy są realne. UODO i RODO nakładają przy tym wymogi dotyczące lokalizacji i rezydencji danych, które wpływają na wybór architektury storage dla polskich podmiotów. Poniżej konkretny przegląd, jak te systemy faktycznie działają.

Replikacja kontra kodowanie erasure

Dwie strategie chronią przed awarią węzła. Replikacja przechowuje wiele pełnych kopii: domyślnie Ceph stosuje replikację 3x, co oznacza, że obiekt 1 GB zajmuje 3 GB surowego storage. Prosta w rozumowaniu, szybka w odczycie, droga pod względem storage. Kodowanie erasure dzieli dane na k chunków danych plus m chunków parzystości używając kodów Reeda-Solomona, więc schemat (10,4) przechowuje 14 chunków i toleruje 4 awarie z zaledwie 40% narzutem zamiast 200%. MinIO domyślnie stosuje kodowanie erasure; Backblaze Vaults używa 17+3 Reed-Solomon. Odczyty z kodowania erasure są wolniejsze, bo rekonstrukcja może wymagać wielu chunków, więc gorące dane często używają replikacji, a zimne — kodowania erasure.

Spójne hashowanie i rozmieszczanie danych

Jak system decyduje, który węzeł przechowuje który obiekt? Spójne hashowanie, wprowadzone przez Kargera i in. (1997) i spopularyzowane przez DynamoDB i Cassandrę, hashuje klucze na pierścień i mapuje każdy zakres do węzła. Dodanie lub usunięcie węzła przetasowuje tylko ułamek kluczy, nie cały zestaw danych. Ceph używa CRUSH (Controlled Replication Under Scalable Hashing), deterministycznego algorytmu rozmieszczającego obiekty na podstawie mapy topologii (rack, rząd, centrum danych), by repliki trafiały do różnych domen awarii. Wirtualne węzły (vnode) na fizyczny węzeł wygładzają nierównomierność obciążenia.

Modele spójności: silna, ostateczna i przyczynowa

Twierdzenie CAP mówi, że nie możesz mieć spójności, dostępności i tolerancji partycji jednocześnie — wybierasz dwa. Silna spójność (linearyzowalnność) oznacza, że odczyty widzą najnowszy zapis; systemy jak Spanner i etcd zapewniają to przez protokoły konsensusu jak Paxos lub Raft. Ostateczna spójność (DynamoDB, Cassandra, S3 historycznie dla niektórych operacji) oznacza, że repliki convergują w czasie, z możliwymi przestarzałymi odczytami podczas propagacji. Spójność przyczynowa zachowuje porządek przyczyna-skutek bez pełnej linearyzowalnności. Systemy przechowywania plików często akceptują ostateczną spójność dla metadanych (listowanie, rozmiar) z silną spójnością dla odczytów po zapisie tego samego obiektu.

Architektura Ceph: OSD, Monitory, Managerowie i MDS

Ceph uruchamia cztery typy demonów. OSD (Object Storage Daemon) przechowują obiekty i replikują je; klaster zazwyczaj ma 10 do 1 000 OSD na dyskach obrotowych lub NVMe. Monitory (MON) utrzymują stan klastra przez Paxos; 3 lub 5 MON zapewnia kworum. Managerowie (MGR) eksponują metryki i hostują dashboardy. MDS (Metadata Server) obsługują warstwę systemu plików POSIX CephFS. Object storage przez RADOS Gateway (RGW) prezentuje API S3 i Swift. Block storage przez RBD wspiera woluminy OpenStack i dyski VM. Jedna codebase, trzy osobowości, dostrajana przez /etc/ceph/ceph.conf i edycje mapy CRUSH.

HDFS i dziedzictwo Hadoop

HDFS (Hadoop Distributed File System) celuje w duże sekwencyjne odczyty dla zadań MapReduce i Spark. Pliki podzielone na 128 MB lub 256 MB bloki; każdy blok domyślnie replikowany 3x w DataNodes. NameNode trzyma wszystkie metadane w pamięci, ograniczając skalę do około 500 milionów plików na NameNode. HDFS Federation i HDFS Router dodają obsługę wielu przestrzeni nazw. HDFS nie jest dobry dla małych plików (metadane dominują) ani kompatybilności POSIX, ale doskonały dla analityki na zbiorach danych o skali TB. Jest też wypierany przez object storage (S3, GCS) w miarę jak obliczenia oddzielają się od storage w erze chmury.

Content-Addressed Storage: IPFS i Filecoin

IPFS (InterPlanetary File System) identyfikuje treść przez jej hash (CID, Content IDentifier) zamiast lokalizacji. Każdy przechowujący plik o tej samej treści produkuje ten sam CID. Pobieranie używa DHT (Distributed Hash Table, opartego na Kademlia) do znalezienia węzłów trzymających treść. Filecoin dodaje ekonomiczne incentywy — górnicy udowadniają, że przechowują treść przez PoRep (Proof-of-Replication) i PoSt (Proof-of-Spacetime) i zdobywają tokeny FIL. IPFS pasuje do archiwizowania i zdecentralizowanego publikowania (metadane NFT, strony web3); jest wolny dla interaktywnych obciążeń z powodu opóźnienia wyszukiwania DHT (setki milisekund do sekund).

Object Storage: S3, R2, B2 i MinIO

Object storage prezentuje płaskie API klucz-wartość: PUT obiekt z kluczem, GET go z powrotem. Żadnych katalogów, żadnej semantyki POSIX. Ta prostota umożliwia masową skalę — AWS S3 przechowuje biliony obiektów z 11 dziewiątkami trwałości. Klony jak Cloudflare R2, Backblaze B2, Wasabi i DigitalOcean Spaces implementują API S3 na różnych backendach. MinIO działa lokalnie jako open source AGPL v3, często w Kubernetes jako StatefulSet, dostarczając storage zgodny z S3 na sprzęcie commodity. Object storage w dużej mierze wygrał rynek cloud storage, bo API jest proste, ceny przejrzyste i trwałość godna zaufania.

Kodowanie erasure w praktyce: jak działa rekonstrukcja

Gdy węzeł umiera w systemie z kodowaniem erasure, pozostałe węzły rekonstruują utracone chunki. Dla kodu Reed-Solomon (10,4), dowolne 10 z 14 chunków rekonstruuje oryginalne 10 chunków danych przez algebrę macierzową nad skończonym ciałem. Obciążenie rekonstrukcją spada na ocalałe węzły, więc utrata 1 węzła w klastrze 100 wyzwala odczyty z 10 innych węzłów na każdy utracony chunk. Pasmo podczas przebudowy to poważna troska operacyjna. Systemy jak Ceph ograniczają szybkość przebudowy, by nie wpływać na produkcyjne I/O. Nowsze kody jak Local Reconstruction Codes (LRC, używane przez Azure) i kody Hitchhiker redukują pasmo rekonstrukcji.

Opóźnienia ogona i hedged requests

Systemy rozproszone mają długie ogony. Żądanie trafiające na wolny dysk lub przeciążoną sieć może zająć 10 razy medianę. Artykuł Google „The Tail at Scale" (Dean & Barroso, 2013) sformalizował techniki: hedged requests wysyłają zduplikowane odczyty do dwóch węzłów, anulując tego, który przegrywa; tied requests koordynują, by tylko jeden faktycznie wykonał. Ceph, DynamoDB i Spanner wszystkie używają wariantów tych technik. Dla systemów transferu plików, czytanie obiektu przez wiele replik równolegle i pobieranie pierwszej odpowiedzi dramatycznie skraca opóźnienie p99 kosztem nieco większego pasma.

Praktyczne implikacje dla usług transferu plików

Usługa transferu plików zazwyczaj buduje się na object storage zamiast na systemie plików POSIX. Backendy zgodne z S3 (AWS S3, Cloudflare R2, MinIO) obsługują trwałość i skalę bez uruchamiania Ceph czy GlusterFS przez zespół. Usługa dodaje auth, presigned URL, metadane i funkcje widoczne dla użytkownika. HexaTransfer używa backendu zgodnego z S3 z szyfrowaniem AES-256-GCM po stronie klienta, więc rozproszona warstwa storage obsługuje trwałość, podczas gdy warstwa aplikacji zachowuje prywatność zawartości pliku od każdej warstwy — w tym od samego dostawcy storage.

Wypróbuj bezpłatnie na hexatransfer.com — bez konta, maksymalnie 10 GB.