Questo è il secondo articolo di una serie informativa dedicata all'object storage (qui il primo).

Come funziona

Per spiegare al meglio i meccanismi che regolano il funzionamento di un object storage penso possa essere utile confrontarlo con uno storage a file. Per certi aspetti l’object storage può essere considerato come un file storage più sofisticato.
La prima cosa da definire quando sia parla di object storage è il concetto di oggetto e come questo differisce dal classico concetto di file. Un oggetto è la somma di un file (il contenitore dei dati) più una serie di metadati che ne descrivono il contenuto e le caratteristiche. I Metadati sono il valore aggiunto, possono contenere svariati tipi di informazione e sono utilizzabili per la ricerca dei file, funzionalità indispensabile in caso di ricerche complesse e su archivi di grandi dimensione.

In un sistema tradizionale lo spazio è organizzato in file e directory. Quando un dato viene scritto all'interno dello storage non ci si preoccupa del suo contenuto ma della sua posizione. L'unico modo per accedere nuovamente al dato è di sapere dove si trova (path). Non è possibile assegnare due file diversi alla stessa locazione e non è previsto che lo stesso file sia referenziato da percorsi diversi.
Al contrario, in un object storage, non esiste un sistema di localizzazione dei dati determinato dal loro posizionamento ma dal loro contenuto.
Ogni volta che un oggetto viene immesso in un object storage il sistema utilizza una funzione di hashing (MD5 o SHA-1 sono gli algoritmi più diffusi) per generare una chiave univoca derivata da quelle informazioni. Ogni minuscola modifica al file originario crea automaticamente una nuova chiave che, proprio per natura dell’algoritmo usato, è totalmente differente dalla precedente.
Le hash formano quindi una hash table: un indice (catalogo) di tutti gli oggetti che fanno parte del sistema. Questo meccanismo previene la possibilità di avere due oggetti identici ma anche la sicurezza che, avendo la chiave giusta, si ottenga l’oggetto effettivamente richiesto.
Il problema dell’utilizzo di algoritmi di hash come quelli descritti è il numero limitato di combinazioni possibili, grande ma limitato, e il conseguente rischio di collisioni (la collisione si verifica quando vengono generate due chiavi identica partendo da due oggetti diversi). Questa possibilità è remota in piccoli sistemi ma diviene un rischio concreto quando si devono memorizzare centinaia di milioni di file. Molti vendor, grazie anche al frutto di esperienze passate hanno iniziato a produrre hash table a doppia chiave, in alcuni casi semplicemente sommando i risultati di due funzioni diverse.
Una volta che l’oggetto è stato accolto all’interno di un object storage viene duplicato N volte in funzione di regole che, in molti casi, possono essere definite dall’utente in funzione del livello di affidabilità o anche solo della facilità di reperire l’oggetto nel nodo più vicino possibile per una questione di performance.
Molti sistemi prevedono funzionalità di versioning (la gestione automatica della versione di un oggetto), WORM (write once ready many) e crittografia dei dati, compressione dei dati. Tutte funzionalità che rendono lo strumento particolarmente adatto per operazioni di archiving con valenza legale e per altre applicazioni dove la sicurezza è una caratteristica fondamentale.
I sistemi di object storage, proprio per loro natura e architettura, non necessitano di sistemi di backup tradizionali o di replica dei dati. I sistemi più moderni hanno tutte queste caratteristiche già presenti nel prodotto e quindi, se adeguatamente configurati, possono essere implementati su reti geografiche per offrire il massimo di affidabilità, qualità del servizio e resilienza.
L’inserimento e la lettura degli oggetti, nella maggior parte dei casi, vengono eseguiti attraverso l’uso di API. Ogni produttore ha sviluppato delle API proprietarie ma, grazie a servizi cloud come Amazon S3, che utilizzano un set di API aperte, molti vendor si stanno adeguando a questo nuovo standard de facto. Le API di cui ho appena accennato sono basate sul protocollo HTTP e sono di tipo RESTful (un’architettura client/server molto semplice e largamente usata per costruire applicazioni web). Alcuni produttori si sono spinti oltre permettendo l’uso anche di protocolli file (NFS, CIFS) o HTTP. Questo approccio è dovuto essenzialmente al tentativo semplificare al massimo la migrazione da ambienti storage tradizionali a quelli basati su oggetti (ovviamente in questi casi i metadati non possono essere utilizzati se non attraverso attività successive).

Quando usarlo

L’object storage ha delle caratteristiche tali da poter essere preso in considerazioni in diversi ambiti ma non è sicuramente una soluzione ad alte prestazioni in termini di throughput. Partendo dal concetto che ho appena espresso è facile capire che non è paragonabile ad un File server o ad NAS, o quantomeno non nella forma classica con cui siamo abituati a considerare questi oggetti.
Esistono delle sovrapposizioni fra File e Object storage ma, nella pratica, queste avvengono principalmente quando uno dei due viene utilizzato erroneamente per fare le funzioni dell’altro. All’inizio di questo documento avevo riportato proprio l’esempio più calzante: uno dei motivi per cui si utilizza l’object storage può essere il raggiungimento dei limiti di una architettura a file tradizionale, ma anche questo è riduttivo.
In linea generale, se il numero di oggetti/file da gestire è piccolo e non esistono particolari necessità legate all’archiviazione (retention lunghe o di valenza legale) l’uso di object storage è sconsigliabile: il costo iniziale di una soluzione di questo tipo e il lavoro necessario per l’integrazione con il resto dell’infrastruttura è superiore al vantaggio.
Dal lato diametralmente opposto, proprio grazie alle caratteristiche di questi sistemi, se le esigenze legate all’archiviazione sono preponderanti e il numero di file/oggetti da gestire è molto elevato, la soluzione ideale rimane l’object storage.
Tutte le applicazioni che sono fra quelle descritte nei due paragrafi precedenti dovrebbero essere analizzate in dettaglio da uno specialista. E’ comunque importante precisare che l’object storage ha una valenza sempre più elevata con l’aumentare dei file da gestire e in funzione della necessità che questi oggetti presentano in termini di sicurezza e disponibilità nel lungo termine.
Ultimamente stanno anche nascendo nuove opportunità per l’object storage, rese possibili dalla sua declinazione cloud e dai relativi servizi associati, che ne hanno permesso di allargare tantissimo le applicazioni pratiche come ad esempio: backup, repository per foto/video/streaming, Big data, ecc.

Disclaimer: L’azienda Scality ha sponsorizzato la realizzazione di un report sul object storage e cloud storage. Il documento è diviso in due parti, nella prima viene presentata la problematica nei suoi aspetti più generali: introduzione, storia, funzionalità, vantaggi e svantaggi. La seconda parte di questa pubblicazione è dedicata alla presentazione di Scality e del suo prodotto RING. Il report sarà presto scaricabile dal sito dell’azienda e dall’area dei download del sito di Juku consulting srl. In questo blog abbiamo deciso di pubblicare una serie di articoli che ripropongono la sezione indipendente del documento.