Lo storage è il punto in cui la maggior parte dei progetti private cloud riesce o fallisce in silenzio. Il compute è facile da ragionare e facile da sostituire. Il networking è ben compreso. Lo storage è il livello che custodisce il vostro stato, che porta con sé i vostri obblighi di conformità ed è la cosa più difficile da migrare una volta riempito. Se state costruendo un cloud sovrano o privato, lo storage è la fondazione e di solito la parte più profonda della costruzione.
Questa è una panoramica vendor-neutral di cosa significhi davvero storage sovrano, dei livelli da progettare e di una mappa onesta delle opzioni open source. Costruiamo questi sistemi per mestiere e non vendiamo un prodotto di storage, quindi l’obiettivo qui è aiutarvi a scegliere bene, non spingervi verso uno stack.
Perché lo storage è la parte difficile
Tre cose rendono lo storage l’angolo più ostico di un private cloud.
Primo, è stateful. Potete svuotare e ricostruire un nodo di compute in pochi minuti. Non potete farlo con l’unica copia dei vostri dati. Ogni decisione di progettazione su replica, erasure coding e backup è una decisione su quanta perdita di dati e quanto downtime potete tollerare.
Secondo, è il punto in cui la sovranità diventa concreta. Un workload in esecuzione in un data center UE perde comunque sovranità se il livello di storage è gestito da un’entità soggetta a leggi straniere sulla divulgazione. Residenza dei dati e sovranità dei dati non sono la stessa cosa. La residenza è dove i byte si trovano fisicamente. La sovranità è chi ha il controllo legale e tecnico su di essi. I dati conservati in una region di Francoforte di un hyperscaler gestito da un’azienda statunitense possono comunque ricadere sotto il CLOUD Act statunitense, che può obbligare un’azienda USA a fornire i dati indipendentemente da dove siano archiviati. L’EDPB ha chiarito esplicitamente che una crittografia robusta con chiavi detenute esclusivamente sotto controllo SEE è la misura supplementare che affronta questa esposizione. Lo storage è esattamente il punto in cui implementate quel controllo.
Terzo, è impietoso dal punto di vista operativo. I sistemi di storage distribuito hanno modalità di guasto che emergono solo su larga scala o sotto carico: split-brain, ricostruzioni lente, write amplification, condizioni di cluster pieno. Farlo bene richiede una progettazione deliberata, non i valori predefiniti.
I tre livelli: block, file, object
Un private cloud completo di solito ha bisogno di tutti e tre i tipi di storage. Non sono intercambiabili.
Block storage presenta a un host volumi grezzi, come un disco virtuale. È ciò che vogliono le macchine virtuali e i database: bassa latenza, lettura e scrittura casuale, semantica single-writer. Il block è la spina dorsale per i workload su hypervisor e per i pod Kubernetes stateful.
File storage presenta un filesystem POSIX condiviso che molti client possono montare contemporaneamente. Si adatta a dati applicativi condivisi, home directory, pipeline multimediali e software legacy che si aspetta un percorso su disco. Il trade-off è che la semantica POSIX distribuita è genuinamente difficile, quindi i file system tendono a essere il tier più complesso da gestire bene.
Object storage presenta i dati come oggetti in bucket piatti, accessibili via HTTP con un’API in stile S3. Non c’è sovrascrittura in-place né gerarchia di filesystem. In cambio ottenete una scalabilità orizzontale di fatto illimitata, metadati integrati e un adattamento pulito per backup, data lake, log, corpora di addestramento AI e asset applicativi. L’object storage è la casa naturale per il grosso dei dati non strutturati, ed è per questo che si colloca al centro della maggior parte delle architetture di storage sovrano.
Software-defined storage, in breve
Il software-defined storage (SDS) disaccoppia la logica di storage dall’hardware. Invece di un’appliance proprietaria, eseguite software aperto su server commodity e lasciate che gestisca placement, replica e healing. È questo che rende realizzabile lo storage sovrano: l’intelligenza è aperta, verificabile e vostra, e l’hardware è intercambiabile. Il costo è che vi assumete la complessità operativa, con un team vostro o tramite un partner di servizi gestiti.
Due strategie di protezione dei dati attraversano tutto ciò che segue:
- Replica mantiene N copie complete di ogni porzione di dati. Semplice, veloce da ripristinare, ma avida di spazio: una replica 3x significa 3 TB di disco grezzo per ogni 1 TB di dati utilizzabili.
- Erasure coding suddivide i dati in frammenti più parità, così sopravvivete ai guasti usando molta meno capacità grezza. Un profilo di erasure tipico offre una resilienza simile alla replica 3x richiedendo circa 1,5x di capacità grezza. Il trade-off è più CPU, scritture piccole più lente e ricostruzioni più lunghe.
Una mappa ampia delle opzioni open source
Non esiste un unico strumento giusto. La scelta corretta dipende dalla scala, dai protocolli che vi servono, dalla competenza del vostro team e da dove vive il workload. Ecco un panorama onesto.
Ceph è la piattaforma SDS unificata di riferimento. Un singolo cluster serve tutti e tre i livelli: RBD per il block, CephFS per il file e il RADOS Gateway (RGW) per l’object storage compatibile con S3 e Swift. Scala fino ai petabyte, supporta replica ed erasure coding e si auto-ripara. Il costo è una complessità operativa reale: è il sistema più impegnativo qui da gestire in sicurezza, ed è avido di RAM e CPU. Rook è l’operator che esegue Ceph nativamente dentro Kubernetes e rimuove gran parte della fatica del day-two. Ceph è la risposta predefinita quando volete un’unica piattaforma per tutto su larga scala.
LINSTOR con DRBD prende una strada diversa: replica a livello block nel kernel, in sostanza un RAID-1 sincrono tra server, orchestrato da LINSTOR. Offre prestazioni del disco quasi native con un overhead molto basso, il che lo rende forte per database e VM sensibili alla latenza. È solo per il block, e il setup coinvolge moduli del kernel e LVM, quindi è meno plug-and-play. Piraeus porta LINSTOR su Kubernetes.
Per l’object storage compatibile con S3 nello specifico, il panorama è cambiato di recente ed è utile saperlo:
- MinIO è stato per anni il server S3 leggero predefinito. La sua community edition è ormai di fatto a fine vita: la console di amministrazione è stata rimossa, la distribuzione dei binari è stata interrotta e il repository GitHub è stato archiviato a febbraio 2026. La licenza AGPL adottata significa che il codice può essere (ed è stato) forkato, ma la community edition upstream non è più mantenuta. Trattate le installazioni esistenti come bisognose di un piano di migrazione.
- Garage è un object store leggero e distribuito, progettato per deployment geo-ridondanti tra siti separati. Nessun nodo master, tutti peer, placement delle repliche consapevole delle zone, gira su hardware modesto e su ARM. Eccellente per la sovranità multi-sito ed edge. AGPL-3.0.
- SeaweedFS è maturo, veloce e particolarmente valido con un numero molto elevato di oggetti piccoli. Offre S3, FUSE e WebDAV, ha una solida integrazione con Kubernetes ed è rilasciato sotto licenza Apache-2.0. Una scelta general-purpose robusta su larga scala.
Per i volumi persistenti nativi di Kubernetes:
- Longhorn è il block storage distribuito più semplice per Kubernetes: facile da gestire, buona UI, snapshot e backup integrati. Il migliore per edge e cluster da piccoli a medi; la latenza può impennarsi sotto carico pesante.
- OpenEBS è modulare; il suo motore Mayastor offre IOPS elevati con un costo CPU inferiore a Ceph, focalizzato sul block, senza funzionalità object.
Per il substrato di storage in sé:
- ZFS è il filesystem locale gold standard: checksumming, snapshot, compressione, crittografia nativa. Sta alla base di molti dei sistemi sopra elencati come livello per-nodo.
- GlusterFS è un filesystem di rete scale-out ancora presente in produzione, anche se lo slancio si è chiaramente spostato verso Ceph e architetture object-first per le nuove costruzioni.
Storage compatibile con S3 come alternativa sovrana ad AWS S3
L’API S3 è diventata lo standard di fatto per l’object storage, il che è una buona notizia per la sovranità. Poiché così tanto software parla S3, potete eseguire uno store compatibile con S3 sulla vostra infrastruttura (Ceph RGW, Garage, SeaweedFS) e mantenere lo stesso codice applicativo, gli stessi strumenti di backup, gli stessi motori di data lake, mentre i vostri dati restano nella vostra giurisdizione sotto le vostre chiavi. Ottenete l’ergonomia per gli sviluppatori di S3 senza l’esposizione legale di un cloud gestito da operatori stranieri. Questa è la singola mossa con la massima leva nella maggior parte delle architetture di storage sovrano.
Crittografia, controllo delle chiavi e residenza
La sovranità si applica al confine delle chiavi, non al muro del data center.
- La crittografia at-rest dovrebbe essere attiva su ogni livello che la supporta, da ZFS fino al gateway object.
- Il controllo delle chiavi è il punto centrale. Se una terza parte può decrittare i vostri dati, non siete sovrani indipendentemente da dove si trovino i dischi. Tenete le chiavi in un KMS o HSM controllato in UE, separato dall’operatore dello storage, così che nessuna entità straniera possa imporre la divulgazione di dati utilizzabili.
- La residenza conta comunque: vincolate il placement alle region UE e dimostratelo. Ma la residenza senza controllo delle chiavi è teatro.
Backup e disaster recovery
La replica non è un backup. Copia fedelmente i vostri errori. Una vera architettura di storage sovrano ha backup indipendenti (idealmente immutabili, in stile object-lock) e un piano di DR testato: replica cross-site per i dati object, ripristino basato su snapshot per block e file e regolari prove di restore. Il guasto che non avete provato è quello che farà male.
Gestione autonoma o gestita
L’SDS open source rimuove il lock-in di licenza, non il carico operativo. La divisione onesta:
- Gestione autonoma quando avete un team di piattaforma capace sullo storage e volete il pieno controllo. Mettete a budget un vero on-call e una competenza profonda; Ceph in particolare punisce gli organici sottodimensionati.
- Gestito quando volete uno storage sovrano e open source ma non un pager alle 3 di notte per un cluster degradato. Un partner vendor-neutral può progettare, costruire e gestire lo stack sulla vostra infrastruttura, nella vostra giurisdizione, con le vostre chiavi, e restituirvelo quando lo desiderate.
FAQ
L’object storage basta da solo? Raramente. L’object copre il grosso dei dati non strutturati, ma VM e database hanno bisogno del block, e i dati applicativi condivisi spesso hanno bisogno del file. La maggior parte dei private cloud usa tutti e tre.
Ceph o qualcosa di più leggero? Ceph se volete un’unica piattaforma per block, file e object su larga scala e potete dotarla di personale. Strumenti più leggeri e monouso (Garage o SeaweedFS per l’object, Longhorn o LINSTOR per il block) sono più facili da gestire quando non vi serve una piattaforma unificata.
Compatibile con S3 significa esattamente come AWS S3? L’API di base è ampiamente compatibile, ed è per questo che le migrazioni di solito sono fluide. Le funzionalità di contorno e le garanzie di consistenza variano, quindi convalidate le operazioni specifiche da cui dipendono le vostre applicazioni.
E la situazione di MinIO? La community edition non è più mantenuta dall’inizio del 2026. Gli utenti esistenti dovrebbero pianificare una migrazione verso un’alternativa mantenuta o un fork supportato.
Dove si colloca Rapid Solutions
Siamo una società di consulenza ingegneristica vendor-neutral e un partner di servizi gestiti, non un cloud provider. Progettiamo e gestiamo storage sovrano, open-source-first su infrastruttura sotto il vostro controllo, con residenza dei dati in UE e chiavi che restano nelle vostre mani. Ci adattiamo al vostro stack invece di vendervi il nostro.
Se state pianificando un private cloud o ripensando dove vivono i vostri dati, parlate con noi.