Storage distribuito dei file: come funziona spiegato

Lo storage distribuito dei file distribuisce i dati su molti nodi in modo che nessuna singola macchina sia un collo di bottiglia o un singolo punto di fallimento. Il Garante per la protezione dei dati personali richiede che i dati personali memorizzati dai titolari del trattamento siano protetti contro perdita, distruzione o danneggiamento accidentale: la ridondanza è quindi non solo una questione tecnica ma un obbligo di conformità ai sensi del GDPR articolo 32. Le scelte di progettazione, come posizionare i dati, come replicarli, come gestire i fallimenti dei nodi, come mantenere la consistenza, distinguono sistemi come Ceph (oggetti/blocchi/file), GlusterFS (POSIX), HDFS (big-data batch), MinIO (compatibile S3) e sistemi content-addressed come IPFS e Filecoin.

Replicazione vs. Erasure Coding

Due strategie proteggono contro i fallimenti dei nodi. La replicazione memorizza più copie complete: la replica predefinita di Ceph è 3x, il che significa che un oggetto da 1 GB usa 3 GB di storage grezzo. Semplice da ragionare, veloce da leggere, costosa in storage. L'erasure coding divide i dati in k chunk di dati più m chunk di parità usando i codici Reed-Solomon, così uno schema (10,4) memorizza 14 chunk e tollera 4 fallimenti con solo il 40% di overhead invece del 200%. MinIO usa per default l'erasure coding; i Vault di Backblaze usano Reed-Solomon 17+3. Le letture di erasure coding sono più lente perché la ricostruzione potrebbe richiedere più chunk, quindi i dati caldi spesso usano la replicazione e i dati freddi usano l'erasure coding.

Hashing Consistente e Posizionamento dei Dati

Come decide un sistema quale nodo memorizza quale oggetto? L'hashing consistente, introdotto nel lavoro accademico di Karger et al. (1997) e reso popolare da DynamoDB e Cassandra, hasha le chiavi in un anello e mappa ogni intervallo a un nodo. L'aggiunta o la rimozione di un nodo mescola solo una frazione di chiavi, non l'intero dataset. Ceph usa CRUSH (Controlled Replication Under Scalable Hashing), un algoritmo deterministico che posiziona gli oggetti in base a una mappa topologica (rack, fila, datacenter) così le repliche finiscono su domini di fallimento diversi. I nodi virtuali (vnode) per nodo fisico ammorbidiscono lo squilibrio del carico.

Modelli di Consistenza: Forte, Eventuale e Causale

Il teorema CAP dice che non si può avere contemporaneamente consistenza, disponibilità e tolleranza alle partizioni: si sceglie due. La consistenza forte (linearizzabilità) significa che le letture vedono l'ultima scrittura; sistemi come Spanner ed etcd la forniscono tramite protocolli di consenso come Paxos o Raft. La consistenza eventuale (DynamoDB, Cassandra, S3 per alcune operazioni storicamente) significa che le repliche convergono dato tempo, con letture stale possibili durante la propagazione. La consistenza causale preserva l'ordine causa-effetto senza piena linearizzabilità. Lo storage dei file spesso accetta la consistenza eventuale per i metadati (listing, dimensione) con consistenza forte per le letture-dopo-scritture dello stesso oggetto.

Architettura Ceph: OSD, Monitor, Manager e MDS

Ceph gestisce quattro tipi di daemon. Gli OSD (Object Storage Daemon) memorizzano oggetti e li replicano; un cluster tipicamente ha 10-1.000 OSD su dischi rotanti o NVMe. I Monitor (MON) mantengono lo stato del cluster tramite Paxos; 3 o 5 MON forniscono quorum. I Manager (MGR) espongono metriche e ospitano dashboard. Gli MDS (Metadata Server) servono il layer del filesystem POSIX CephFS. Lo storage a oggetti tramite RADOS Gateway (RGW) presenta API S3 e Swift. Lo storage a blocchi tramite RBD supporta i volumi OpenStack e i dischi VM. Un codebase, tre personalità, tunate con /etc/ceph/ceph.conf e modifiche alle CRUSH map.

HDFS e il suo Retaggio Hadoop

HDFS (Hadoop Distributed File System) mira alle grandi letture sequenziali per i job MapReduce e Spark. I file si dividono in blocchi da 128 MB o 256 MB; ogni blocco si replica 3x per impostazione predefinita tra i DataNode. Un NameNode mantiene tutti i metadati in memoria, limitando la scala a circa 500 milioni di file per NameNode. HDFS Federation e HDFS Router aggiungono supporto multi-namespace. HDFS non è adatto per i file piccoli (i metadati dominano) o la compatibilità POSIX, ma è eccellente per l'analytics su dataset di scala TB. Viene anche soppiantato dallo storage a oggetti (S3, GCS) man mano che il calcolo si separa dallo storage nell'era cloud.

Storage Content-Addressed: IPFS e Filecoin

IPFS (InterPlanetary File System) identifica il contenuto tramite il suo hash (CID, Content IDentifier) piuttosto che la posizione. Chiunque memorizzi un file con lo stesso contenuto produce lo stesso CID. Il recupero usa una DHT (Distributed Hash Table, basata su Kademlia) per trovare i nodi che detengono il contenuto. Filecoin aggiunge incentivi economici, i miner dimostrano di memorizzare il contenuto tramite PoRep (Proof-of-Replication) e PoSt (Proof-of-Spacetime) e guadagnano token FIL. IPFS si adatta all'archiviazione e alla pubblicazione decentralizzata (metadati NFT, siti web3); è lento per i workload interattivi a causa della latenza di ricerca DHT (centinaia di millisecondi a secondi).

Storage a Oggetti: S3, R2, B2 e MinIO

Lo storage a oggetti presenta una semplice API chiave-valore: PUT un oggetto con una chiave, GET indietro. Nessuna directory, nessuna semantica POSIX. Questa semplicità abilita una scala massiva: AWS S3 memorizza trilioni di oggetti con durabilità a 11 nove. I cloni come Cloudflare R2, Backblaze B2, Wasabi e DigitalOcean Spaces implementano l'API S3 su backend diversi. MinIO gira on-premises come open source AGPL v3, spesso in Kubernetes come StatefulSet, fornendo storage compatibile S3 su hardware commodity. Lo storage a oggetti ha ampiamente vinto il mercato dello storage cloud perché l'API è semplice, il pricing è chiaro e la durabilità è affidabile.

Erasure Coding in Pratica: Come Funziona la Ricostruzione

Quando un nodo muore in un sistema erasure-coded, i nodi rimanenti ricostruiscono i chunk persi. Per un codice Reed-Solomon (10,4), qualsiasi 10 dei 14 chunk ricostruisce i 10 chunk di dati originali tramite algebra matriciale su un campo finito. Il carico di ricostruzione cade sui nodi sopravvissuti, così perdere 1 nodo in un cluster di 100 innesca letture da altri 10 nodi per ogni chunk perso. La larghezza di banda durante la ricostruzione è una grande preoccupazione operativa. I sistemi come Ceph limitano il tasso di ricostruzione per evitare di impattare l'I/O di produzione.

Latenza di Coda e Richieste Hedged

I sistemi distribuiti hanno code lunghe. Una richiesta che colpisce un disco lento o una rete congestionata potrebbe richiedere 10x la mediana. Il paper di Google "The Tail at Scale" (Dean & Barroso, 2013) ha formalizzato le tecniche: le richieste hedged inviano letture duplicate a due nodi, cancellandone quella che perde. Ceph, DynamoDB e Spanner usano tutte varianti. Per i sistemi di trasferimento file, leggere un oggetto tramite più repliche in parallelo e prendere la prima risposta taglia drasticamente la latenza p99 al costo di un po' più di larghezza di banda.

Implicazioni Pratiche per i Servizi di Trasferimento File

Un servizio di trasferimento file tipicamente si costruisce sullo storage a oggetti piuttosto che su un filesystem POSIX. I backend compatibili S3 (AWS S3, Cloudflare R2, MinIO) gestiscono durabilità e scala senza che il team gestisca Ceph o GlusterFS. Il servizio aggiunge auth, URL presignati, metadati e funzionalità rivolte all'utente. HexaTransfer usa un backend compatibile S3 con crittografia AES-256-GCM lato client tramite crittografia end-to-end, così il layer di storage distribuito gestisce la durabilità mentre il layer app mantiene i contenuti dei file privati da ogni livello, rispettando pienamente i requisiti del GDPR e del Garante per la protezione dei dati personali.

Prova su https://hexatransfer.com — gratuito, senza account, massimo 10 GB.