Storage ridondato con OpenStack – Teoria

OpenStack è un progetto OpenSource sviluppato da una collaborazione di aziende tra cui Rackspace, NASA, Dell, Citrix, Cisco e Canonical (Ubuntu) attraverso cui è possibile generare un sistema Cloud simile a quello di Amazon utilizzando “Commodity Computer”, cioè dei computer standard senza particolari caratteristiche.

A chi può servire OpenStack Swift
Come già detto tutto non va bene per fare tutto, ogni cosa è concepita con uno scopo preciso e, se si usa per ambiti differenti da ciò per la quale è stata concepita, è facile rimanere insoddisfatti.

Openstack Swift è concepito per:
– archiviare file multimediali (foto, video, musica, ecc.)
– archiviare file di videosorveglianza
– archiviare intercettazioni telefoniche
– archiviare file di log
– archiviare backup
– salvare e caricare file di VM
– achiviare file piccoli (<50K)
– archiviare grosse quantità di file (miliardi)
– gestire storage esremamente grandi (Petabytes – milioni di Gigabyte) che possono crescere dinamicamente
– gestire storage geograficamente separati

Openstack non è concepito per:
– archiviare file di dimensioni > 5 GB: in questi casi è necessario splittare il file in più parti
– essere usato come un filesystem: per accedere ai file ci sono le REST API, le funzionalità POSIX di Linux non sono supportate
– situazioni in cui è necessario controllare le quantità di dati memorizzate dall’utente
– situazioni in cui serve la gerarchia delle directory
– situazioni in cui è necessario modificare il singolo byte all’interno di un file – on Swift sovrascrive il file ad ogni modifica e ne crea una nuova versione
– nessun supporto in append (vedi sopra)
– nessun uso di ACL e di File Locking
– situazioni in cui è necessaria la consistenza dei file – nel casi di contemporaneità, la versione memorizzata sarà quella ad essere modificata per ultima
– nessun supporto del criptaggio dei dati memorizzati ma solo del traffico
– incompatibile con i Web Browser
– nessun supporto di database per la ricerca di file
– situazioni in cui è necessario modificare spesso file di grosse dimensioni – i file sono immutabili, ad ogni modifica si crea una nuova versione
– tentare di usare Swift come FileSystem attraveso applicazioni come FUSE

Se queste limitazioni sono incompatibili con ciò che volete fare, probabilmente vi potrà andar meglio OCFS2, NFS, GFS2, ecc.

Concetti di base:
Swift mette a disposizione un ambiente di storage in cui un cliente (account) ha accesso ad un’area si storage dove può creare distinte partizioni (container) e caricare file (object) all’interno di queste. Ogni account può avere associate più username/password.

Tecnicamente il sistema si compone di 3 entità che possono sia risiedere sullo stesso server, sia essere separate: l’Auth server è dove risiedono i dati di autenticazione degli utenti; gli storage server sono i server dove fisicamente risiedono i dati e il il proxy server è il server che ha il compito di girare i dati di autenticazione all’auth server e, successivamente, interagire con gli storage server per rendere disponibili i dati.

Bisogna ora introdurre due altri concetti: le zone e le repliche. Qui la cosa è leggermente più difficile.
Le zone sono le entità fisiche che devono essere gestite e sono formate da una o più aree di disco fisiche; vediamole come l’entità minima che si può guastare. Con OpenStack si ha la massima libertà nel scegliere qual è l’elemento minimo del sistema e quindi la zona: può essere una partizione fisica all’interno di un disco, un disco, un server o un intero datacenter. Più piccola è l’entità zona, maggiore è l’efficenza del sistema, ma peggiore è la tolleranza ai guasti. Ad esempio, se abbiamo 2 server con 2 HD ciascuno e definiamo come zona il singolo disco (ciò che faremo nell’HowTo), tollereremo il guasto del singolo disco, ma non tollereremo il guasto di un intero server. Analogamente se definiamo come zona un server e abbiamo i server in due diversi datacenter, tollereremo il guasto di un Server, ma potremmo avere problemi nel caso in cui un intero datacenter muoia.

Le repliche sono invece il numero di copie che si vogliono avere per ogni dato memorizzato nel sistema: normalmente è 3; il numero di zone minimo presenti nel cluster è pari al numero di repliche, in questo caso abbiamo un sistema “mirror”. Il numero minimo consigliato di zone per un sistema in produzione è 5.
Da sottolineare che OpenStack non fa il mirror a livello di file, bensì suddivide il filesystem delle zone in partizioni più piccole (normalmente 10 GB/partizione) e si occupa di migrarle dinamicamente tra le zone per mantenere il sistema bilanciato.

Ultimo concetto da introdurre in OpenStack sono gli anelli (ring): un anello è un insieme di zone, quindi rappresenta la distribuzione dei nostri dati all’interno del cluster. Devono essere configurati tre anelli: uno per gli account, uno per i container e uno per gli object.

Come fare ad accedere ad OpenStack Swift
Openstack Swift include delle API per tutti i più importanti linguaggi di programmazione (php, .net, python ecc.). Inoltre esistono numerosi prodotti che già possono interagire con OpenStack Swift: a parte OpenStack Nova, mi sembra giusto citare CyberDuck che, oltre ad essere un ottimo client FTP, permette di collegarsi direttamente a storage di nuova concezione come Amazon S3 e, appunto, Openstack Swift.

Quando lo storage deve crescere
E’ semplice: si aggiunge un nuovo elemento “zona” aggiungendolo al proxy e ribilanciando il sistema e lo si annuncia agli altri storage copiando i file di configurazione. Operazione totalmente trasparente, il sistema continua ad essere operativo fintanto che l’update viene completato.