In caso di problemi, i dati archiviati in un servizio di block storage in cloud possono essere persi per sempre se non ne viene eseguito correttamente il backup. Questo articolo spiega come l’object storage funzioni in modo molto diverso rispetto al block storage e come offra migliori protezioni integrate.

Che cos’è l’object storage

Ogni fornitore di servizi cloud offre un servizio di object storage come nel caso del Simple Storage Service (S3) di Amazon, del Blob Store di Microsoft Azure e del Cloud Storage di Google.

I sistemi di object storage sono come un file system senza struttura gerarchica di directory e sottodirectory. Laddove un file system utilizza una combinazione di struttura di directory e nome file per identificare e individuare un file, ogni oggetto archiviato in un sistema di object storage ottiene un identificatore univoco (UID) basato sul suo contenuto.

L’UID viene quindi utilizzato sia come mezzo per identificare un oggetto, sia come mezzo per recuperarlo. L’UID viene creato eseguendo il contenuto del file attraverso un algoritmo crittografico come SHA-1. Per avere un’idea di come funzioni SHA-1, potete creare il vostro hash SHA-1 qui inserendo qualsiasi quantità casuale di testo. Ogni elemento, come un file, un blocco, un gruppo di file o blocchi o una porzione di un blocco o file, può essere archiviato come oggetto.

Un’enorme differenza tra l’object storage e il block storage è che ogni oggetto archiviato nel primo modo viene automaticamente replicato in almeno tre zone di disponibilità. Ciò significa che una catastrofe naturale o di altro tipo di evento negativo potrebbe eliminare due zone di disponibilità ma che, nonostante ciò, tutti i dati rimarranno comunque memorizzati nel sistema di object storage. Un sistema di block storage invece viene replicato solo all’interno di una singola zona di disponibilità e quindi una singola interruzione di particolare gravità può distruggere tutti i dati.

Anche il funzionamento della replica è molto diverso tra i due sistemi. La replica degli oggetti viene eseguita a livello di oggetto rispetto alla replica a livello di blocco del block storage in cloud e dei sistemi RAID. Gli oggetti inoltre non vengono mai modificati. Se un oggetto deve essere modificato, viene semplicemente archiviato come nuovo oggetto. Se il controllo delle versioni è abilitato, la versione precedente dell’oggetto viene salvata per scopi “storici”. In caso contrario, la versione precedente viene semplicemente eliminata. Questo è molto diverso dal block storage, in cui le versioni precedenti non vengono mai salvate a meno che non si utilizzi un tipo di sistema di protezione aggiuntivo.

I sistemi di object storage prima citati possono essere configurati per resistere anche a un disastro regionale che eliminerebbe tutte le zone di disponibilità. Amazon lo fa utilizzando la replica inter-regione che deve essere configurata dal cliente. L’archiviazione con ridondanza geografica di Microsoft include la replica tra regioni e Google offre l’archiviazione su due aree e su più aree. In combinazione con le funzionalità di versioning integrate in tutti i sistemi di object storage, ciò rende i dati archiviati in tali sistemi molto più resistenti dei dati memorizzati nei sistemi di archiviazione a blocchi offerti da questi fornitori.

Mentre i volumi di blocco e i filesystem sono stati progettati per le prestazioni, l’object storage è stato progettato con l’integrità dei dati come obiettivo principale. Ad esempio, l’identificatore univoco può essere utilizzato in qualsiasi momento per garantire che una determinata copia di un oggetto non sia stata danneggiata.

Tutto ciò che il sistema deve fare è rieseguire l’oggetto attraverso il processo che ha creato l’identificatore univoco. Se l’UID è sempre lo stesso, il contenuto dell’oggetto non è cambiato. Se il contenuto dell’oggetto è invece cambiato, il sistema lo rileverà automaticamente perché l’UID cambierà. Può quindi riparare automaticamente l’oggetto recuperando una buona copia da un’altra regione. Nessun sistema di block storage ha incorporato questo livello di integrità dei dati.

data center

L’object storage si è attirato contro più di una critica a causa del cosiddetto problema open-bucket, in cui i dati importanti e sensibili sono archiviati in un bucket le cui autorizzazioni non sono state gestite. Database di clienti di grandi dimensioni sono stati esposti a questo problema, principalmente perché i clienti non capivano come funzionasse l’object storage. È certamente possibile creare un bucket aperto, poiché consente di distribuire facilmente i file a molte persone semplicemente fornendo loro il collegamento diretto a quell’oggetto. Ciò però significa anche che è relativamente facile creare un bucket aperto e svelare accidentalmente i vostri segreti commerciali a tutto il mondo.

Seguire le pratiche migliori

Una semplice ricerca su Google sulle best practice per il vostro fornitore preferito di object storage vi darà le risorse necessarie per comportarsi al meglio. Ad esempio, Amazon ha questa pagina web che offre una serie di suggerimenti di buon senso, come la disabilitazione dell’accesso pubblico e le autorizzazioni di riscrittura per tutti. Anche Microsoft ha una pagina simile, così come Google. Dovreste anche essere in grado di trovare un numero di articoli di terze parti che vi guideranno lungo il percorso.

Un suggerimento comune è quello di identificare solo quale accesso è richiesto per una determinata applicazione e di garantire quel livello di accesso e non di più. Potrebbe essere molto più semplice garantire a tutte le applicazioni l’accesso completo ai bucket di object storage, ma si tratta di un disastro di sicurezza quasi garantito. Prendete anche in considerazione l’utilizzo dell’amministrazione basata sui ruoli, con la quale è possibile concedere e revocare facilmente l’accesso in base alle esigenze.

È necessario eseguire il backup con un sistema di object storage?

Decidere se eseguire il backup di un sistema di object storage non è semplice come lo è per uno di block storage. A differenza infatti dei volumi a blocchi, l’object storage include automaticamente molti livelli di protezione che difendono la vostra azienda da pericoli che potrebbero danneggiarla seriamente, inclusa la protezione opzionale WORM (write-once-read-many). Se si seguono tutte le migliori pratiche disponibili, inclusa la replica tra regioni, si potrebbe facilmente sostenere che non esiste uno scenario in cui tutti i dati potrebbero scomparire e che dobbiate quindi accedere al backup.

Detto questo, è difficile dare torto a chi afferma che i servizi di object storage sono scritti da essere umani che possono commettere errori. Dopotutto se i dati che risiedono in un sistema di object storage sono di importanza critica, è necessario eseguirne il backup. È importante ricordare che esistono diversi modi per farlo.

Ad esempio, è possibile utilizzare un livello di servizio completamente diverso per il backup (AWS Glazier Deep Archive, Azure Archive Storage o Google Coldline) per conservare una copia dei dati degli oggetti “per ogni evenienza”. Se i vostri dati sono così importanti, allora dovreste prendere in considerazione questo tipo di backup, oltre a assicurarvi che si trovi in un account e una regione diversi, proprio come con il block storage.

Siate però consapevoli di ciò che usate. È necessario infatti eseguire il backup dei volumi di blocco e le immagini di archiviazione a blocchi devono inoltre essere replicate in un’altra area e un altro account. L’object storage invece offre un livello di resilienza molto più elevato, poiché viene automaticamente replicato in più zone di disponibilità. Ma tenete presente che nulla è infallibile e quindi agiste di conseguenza.