Scality, Simply Scaling Storage. White Paper

Transcript

1 Scality, Simply Scaling Storage White Paper Versione in Italiano Giugno 2012

2 Sommario Introduzione Il nostro storage tra sfide e scommesse Cos'è l'object storage? Scality RING Organic Storage Filosofia Architettura e componentistica Prestazioni Protezione dei dati Modello di consistency Scalabilità Management e supporto Partners ed ecosistema Conclusione: Scality, una nuova visione dello storage Bibliografia Glossario Scality 1

3 Sommario Scality offre una soluzione affidabile ed economica che permette di gestire e archiviare dati non strutturati su scala petabyte. Scality RING si basa su una tecnologia brevettata di object storage che fornisce alta disponibilità, facilità operativa ed un controllo totale dei dati. Il RING è in grado di gestire miliardi di files evitando alcune complicazioni come limiti di volume o complesse procedure di backup. Il suo design organico crea un sistema scalabile dotato di un'intelligenza distribuita e praticamente priva di singoli punti di failure, il risultato è che RING Organic Storage è dotato di alta resilienza e si autorigenera, in tal modo gli upgrades tecnologici non richiedono alcuna migrazione di dati ne disservizi. Grazie alla sua struttura parallela Scality Ring offre le migliori performance nelle operazioni di lettura e scrittura. 1 Introduzione Scality elimina il bisogno di hardware specifico e richiede unicamente componenti facilmente reperibili sul mercato, offrendo dei meccanismi di protezione dati che non temono paragoni per affidabilità e qualità, e che garantiscono la più totale continuità di servizio alle piccole come alle più grandi imprese. Grazie ad un intelligente mix tecnologico di replication e di erasure coding è possible ottenere una disponibilità dei dati che supera i "dodici nove" ( %). RING Organic Storage usa un'architettura peer-to-peer dotata di ridondanza geografica distribuita e decentralizzata, dove i dati sono uniformemente diffusi tra tutti i server attivi che compongono l'archivio. Il sistema appare come un'aggregazione di più server indipendenti o parzialmente abbinati secondo un modello "shared nothing" unificato logicamente in un "anello" per offrire un'incomparabile mix di scalabilità lineare, efficenza di costi e protezione dei dati. Il Ring offre inoltre un'eccezionale tolleranza all'errore, proteggendo da tutte le interruzioni funzionali (dischi, servers, corruzione silente, network, rete elettrica), assicura alta disponibilità grazie ad un'allocazione intelligente su siti singoli e multipli. Questo risultato è ottenuto senza l'uso di un database centrale, il che sarebbe in conflitto con la filosofia Ring che mira ad eliminare tutti i singoli punti di failure. Essenza delle performance del Ring è una massiccia architettura parallela, che sa sfruttare pienamente i server più eterogenei facilizzando il transfer dei dati aggregati e fornendo alti livelli di operazioni IOPS. Il Ring è specialmente progettato per permettere la scalabilità lineare di migliaia di storage servers. Scality ha sviluppato un approccio unico per andare incontro alla crescita esponenziale della domanda di storage. Ring vi consente infatti di crescere in armonia con i bisogni del vostro business senza dovervi preoccupare di costosi e complessi cicli di hardware refresh. Paragonato ad altri sistemi di storage attualmente in commercio, il Ring taglia il costo totale di proprietà (TCO) del 50%. Ciò è reso possible grazie all'uso di commodity Scality 2

4 servers, all'enorme semplificazione delle operazioni e grazie alla flessibilità del suo modello di controllo dei costi. 2 Il nostro storage tra sfide e scommesse La crescita delle sfide legate alla gestione dei dati ha generato una priliferazione di risposte tecnologiche innovative, ma la natura di queste soluzioni ha carattere transitorio. In effetti questo fiorire di infrastrutture di storage di ogni tipo si presenta come un insieme molto vario di dispositivi array (SAN), file servers (NAS) e applicazioni di backup o archivio, ma l'emergere di questa complessità causa l'aumento dei costi dovuto ad un tasso di utilizzo relativamente basso, a integrazioni separate di management, SLA di difficile calcolo e all'inesistenza di validi percorsi di upgrade. Figura 1: Enterprise reality: isole di storage eterogenee per fornitori, modelli, tecnologie e versioni. La risposta naturale ai decision makers delle corporazioni è di ridurre la complessità gestionale concentrandosi unicamente su soluzioni standard o di comprovata efficacia e disponibilità. Tra queste soluzioni, optare per lo storage basato su SAN sembrava presentare la massima convenienza, specialmente quando si richiedono le più alte performance, ma la natura del SAN è storicamente legata ad una connettività su fibra ottica che è molto costosa, il che ha portato recentemente l'industria a cercare di rispondere con un'evoluzione interessante, ovvero presentando combinazioni di SAN e Ethernet con protocolli iscsi. Per alcuni decenni il sistema RAID è stato considerate come un semplice meccanismo per protezione dei dati su disco. Poi col proliferare dei gruppi di RAID si è rivelato necessario introdurre gruppi di dischi a doppia parità, come i RAID6 per evitare di esporsi alla perdita di dati. Nonostante questo livello di protezione offra un buon rapporto di salvaguardia del disco, una buona durata e basse probabilità di perdita di dati, se un guasto del disco si verifica il rischio di interruzione funzionale completa è troppo importante, specialmente per le configurazioni più estese. Scality 3

5 D'altra parte i vantaggi dell'impiego di un file system locale o basato in rete sono sensibili in termini di facilità di allocazione, creazione e classificazione di contenuti, ma presentano anche limiti concreti. Le caratteristiche del file system sono sensibili al peso dei files o alla dimensione massima del sistema, o ancora al numero di inode. Insomma, un vantaggio iniziale può trasformarsi in un problema; per esempio la ricerca di un oggetto o di una chiave d'accesso ad un file impone la navigazione della stessa directory. Questa navigazione sequenziale, sebbene rapida e sufficente per un numero limitato di oggetti, diventa presto "un laccio al collo" per i più grandi volumi di dati. Per ovviare a queste limitazioni ci si è serviti di clusters condivisi con due accessi concorrenti al sistema di file, ma questi metodi raggiungono rapidamente il loro limite perchè il modello di disco condiviso riesce a gestire solo qualche decina di nodi. Un approccio "shared nothing" con architettura distribuita e senza condivisione del disco, può invece spingere i limiti del degrado delle performance oltre la soglia imposta in precedenza, rendendo possibile aggregare migliaia fino a decine di migliaia di nodi. Considerando il mondo NAS, uno dei leader mondiali sul mercato offre una soluzione molto scalabile in termini di performance e ridondanza dei dati, con una capacità di diversi PB, ma i limiti del network le impongono di limitare l'offerta a circa 144 nodi. Scality 4

6 3 Cos'è l'object storage? I metodi di accesso tradizionali come il file sharing o i protocolli di blocchi hanno le loro specifiche proprietà, vantaggi e svantaggi. Ma oltre al SAN, NAS e NAS scalabile, una quarta soluzione fa il suo ingresso sulla scena industriale, l'object storage. Un oggetto è un'entità logica che raggruppa data e metadata, dove quest'ultima serve a catalogare e descrivere i dati stessi. Il punto chiave implica la creazione di protocolli di scambio per permettere l'interazione tra i clients e il server. L'industria ha già prodotto innumerevoli protocolli di questo genere, ma le migliori caratteristiche sono attualmente offerte dall'uso associato di keys e values ed è su questo sistema che Scality si basa. Questo approccio presenta numerosi vantaggi contemporaneamente: 1. Il protocollo è semplice da integrare e si rivela affidabile. 2. Le performances hanno una risposta lineare, spesso basata sul calcolo, e quindi prevedibile, senza l'obbligo di centralizzare i dati. 3. La scalabilità non è più limitata dai limiti fisici del sistema a file o a blocchi. 4. La garanzia dell'indipendenza del data location è l'integrazione della ridondanza di dati, grazie al meccanismo di copia multipla riesce a fornire una solidità ottimale. 5. A differenza di uno storage di tipo system file o a blocchi, incapace di gestire l'estensione geografica, l'object storage permette di adottare una topologia internet che favorisce le configurazioni più vaste. 6. La consistenza è semplificata e le restrizioni del block storage o del system file classico sono superate. Il concetto stesso dell'object storage risiede nel valore riconosciuto dall'esterno del sistema, come un percorso o il contenuto di un file del quale si calcola una singola chiave. La chiave conduce ai dati direttamente e senza la minima latenza che deriverebbe invece dalla moltiplicazione di inutili operazioni di accesso. Gli ultimo dieci anni hanno visto la nascita di uno storage system conosciuto come Content Adressable Storage (CAS), questi sistemi sono basati su valori key di oggetti archiviati che derivano direttamente dal loro contenuto (hashes). Gli algoritmi MD5 o SHA-1 sono scelti sia singolarmente che contemporaneamente per consentire l'identificazione unica di ogni oggetto. Intanto, da alcuni anni i CAS hanno fatto il loro ingresso nel mercato cambiando la natura dello storage di dati, e alcune offerte sono già evolute. Questi sistemi sono efficienti per un carico di lavoro moderato perchè ad oggetti uguali corrisponde una sola chiave, ma inevitabilmente tutti rivelano le loro debolezze appena gli si affida un file storing più globale. Più di recente è stato riconosciuto che l'implementazione di un object storage basato su key value, dove la chiave non sia generata dal sistema ma dall'applicazione, è molto più adatta al proliferare delle applicazioni. Amazon ha aperto la strada col servizio Amazon S3 nel Scality ha sviluppato la modernità di questo object storage su key-value e vi ha aggiunto spiccate qualità di performance, facendo del RING Organic storage la tecnologia ideale per un file storage scalabile adatto a qualsiasi uso. Scality 5

7 4 Scality RING Organic Storage 4.1 Filosofia Scality ha creato la soluzione RING Organic storage per adattare le sfide di business e l'it commerce alla crescita esponenziale dei dati; è oggi l'unica soluzione a offrire un tale comfort nel gestire la più grande mole di transazioni e nel conservare volumi di dati su scala petabyte e oltre. La filosofia Scality è basata su principi che fanno da solide fondamenta ad un'architettura ultra scalabile e dalle alte prestazioni, assemblabile con i componenti più convenienti sul mercato. La filosofia è quella di moltiplicare gli spazi logici di storage all'infinito grazie all'uso di commodity servers e dischi non specifici. Figura 2: scalabilità multidimensionale: solo capacità, solo performance o entrambe Scality punta a due insiemi di obbiettivi: 1. Efficienza IT a. Per offrire le migliori prestazioni, disponibilità e scalabilità proponiamo un approccio davvero innovativo. b. Capacità di fornire prestazioni con capacità indipendenti senza il minimo compromesso di disponibilità. 2. Un TCO ridotto (per raggiungere un ROI immediato). Scality 6

8 La figura 3 illustra l'analogia perfetta tra un array tradizionale con elementi comuni (controllers e unità di storage) ed i componenti di Scality RING come connettori e storage servers. Figura 3: L'architettura ad alti livelli di Scality RING Organic Storage confrontata allo storage tradizionale. Ecco come Scality soddisfa gli obbiettivi prefissati: Il load sharing è gestito da numerose unità elementary funzionanti in parallelo. (principio del Divide and Conquer ), Un approccio indipendente e decentralizzato guidato dalla rete peer-to-peer (principio del Divide and Deliver ) La distribuzione degli oggetti scritti su nodi multipli (principio del "Divide and Store"). A differenza dell'uso tipico della distribuzione statica dei dati, Scality non richiede alcun data sharding preliminare da parte dell'user o dell'amministratore dell'applicazione. Tutte le divisioni sono implicite, trasparenti e integrate nella nostra soluzione, senza alcun impatto sull'utente dell'applicazione. Scality 7

9 Figura 4: Esempio di deployment di Scality RING con 2 Tiers di storage, un sito DR e connettori multipli che fungono da layer d'accesso diretti dal Supervisor. 4.2 Architettura e componentistica Fin dal principio Scality ha basato il suo sviluppo sull'implementazione della ricerca universitaria fondata sulla distribuzione e sulla persistenza degli oggetti in una rete di sistemi elementari. La capacità di accedere rapidamente ad ogni oggetto distribuito è quindi un requisito primario. Il Chord protocol, un invenzione del MIT, è un sistema peer-to-peer di seconda generazione su cui fa leva Scality per collocare gli oggetti archiviati in uno spazio virtuale. Contrariamente ai sistemi P2P non strutturati di prima generazione, come Gnutella (dove le richieste sono distribuite a più produttori di storage) questo sistema P2P strutturato integra un vero routing della richiesta al nodo che possiede i dati richiesti. In seguito Scality ha pensato di sviluppare ed estendere chord oltre la distribuzione dei dati, aggiungendo componenti funzionali che raggiungono prestazioni enterprise-level con una migliore affidabilità, riducendo i tempi di accesso e garantendo la persistenza degli oggetti ed una migliore efficacia del self healing. Grazie a questi nuovi componenti siamo riusciti a sostituire un sistema di server keys con una rete di storage nodes meno Scality 8

10 fisici e più flessibili. I nostri server logici sono costituiti di oggetti attraverso un processo UNIX indipendente, responsabile di parti fisiche nell'address space del dispositivo. Con queste innovazioni Scality aggiunge un ingrediente essenziale che facilita enormemente la crescita dell'infrastruttura, e automatizza la redistribuzione delle object keys da un qualsiasi server che venga meno verso altri servers e nodi. Ogni nodo di storage possiede una chiave assegnatagli automaticamente dal sistema e agisce come un semplice archivio per le key/value. Scality crea una generazione di keys e un meccanismo di allocazione flessibile ed efficiente che equilibra le possibilità di errore con il numero di copie richieste e la topologia del Ring (racks, singolo o multisite). Le server keys attuano anche il concetto del class of storage per stare al passo con i bisogni delle applicazioni. Gli algoritmi di Scality, capaci di equilibrare il carico sanno distribuire uniformemente il keyspace nel gruppo di nodi disponibili. Questi algoritmi prevengono la collisione di dati replicati in condizioni operative ma proteggono anche da possibili disk failure dei server. Non meno importante è la loro capacità di associare la configurazione di più server, in modo da permettere l'aggiunta di nuove macchine con capacità particolari o di diverse caratteristiche di performance alle macchine già presenti all'origine. Scality ha integrato una tecnologia dispersa che garantisce la collocazione di ogni replica degli oggetti in un diverso processo nodale e in un diverso server fisico di storage, potenzialmente in diversi datacenters; questa garanzia non decade neanche in caso di disk o server failure. L'indipendenza dei nodi, dei server e delle chiavi è ciò che permette al sistema scality Ring di garantire una disponibilità di %, che gli da una statura Carrier Grade, e lo rende adatto ai contesti più esigenti. Scality ha concepito una filosofia completamente object-oriented per superare i limiti tradizionali e far fronte ad un data storage dell'ordine di petabytes e oltre. La rivoluzione introdotta da Scality richiede solo l'uso di computer economici, di tipo standard x86 come storage server di base, e questo va ben più lontano degli approcci tradizionali che si affidano su indici centralizzati, cataloghi o DBs di piccola entità quali inodes o blocchi di dati. Il cambio paradigmatico sta proprio qui: nell'offerta di uno storage di livello aziendale con server standard a differenza del metodo tradizionale ma con dischi che restano ultra scalabili. L'aggregazione di macchine standard e la loro unione logica a formare un anello coerente con la filosofia peer-to-peer rende possibile soddisfare la promessa di un sistema sempre in linea, sempre attivo e dalla scalabilità illimitata. Così costituito, questo sistema è davvero capace di crescere alla stessa velocità delle esigenze applicative legate ad internet. Il nucleo della soluzione Scality risiede nella sua esclusiva architettura distribuita e in un software dalle capacità di self-healing. Non essendoci centralizzazione delle richieste, nè catalogo di dati nè gerarchia di sistemi, la nozione di "master and slave" è definitivamente superata, l'approccio è in questo caso puramente simmetrico, perchè tutti i nodi hanno lo stesso ruolo è girano con lo stesso codice. Scality RING integra due sistemi supplementari: il supervisor, dal quale l'infrastruttura è di fatto gestita e i connectors che collegano il Ring agli utenti (spesso rappresentati dalle Scality 9

11 applicazioni o dai terminali dell'utente). Si parlerà più diffusamente del supervisor nel capitolo 4.7. I connettori assumono il ruolo della traslazione dei dati tra l'interfaccia standard e i modelli di oggetto che caratterizza il Ring. L'interfaccia può essere aperta e vastamente diffusa o altamente specializzata per usi business o bisogni verticali. Esistono diversi tipi di connettore: ad esempio distribuiti per ottenere il massimo della ridondanza e un layer d'accesso performante o abbinati all'applicazione stessa. L'infrastruttura storage di Scality Ring offre un'architettura dotata di scale-out da un connettore o da una postazione di storage. Figura 5: I diversi elementi che compongono l'infrastruttura Scality Ring All'interno del software sono presenti due livelli: lo Scality Core Framework che permette agli sviluppatori di prevedere modelli di scambio "event-based" asincroni, e lo Scality RING Core, uno strato superiore che esegue la logica distribuita e gestisce i keyspace, il processo di self-healing e una gerarchia di tutti gli spazi di storage. Figura 6: I due livelli funzionali dell'user mode in Scality RING Scality 10

12 Nel linguaggio introdotto da Scality il termine "nodo" è diverso da un sistema o un server fisico, diversi nodi possono infatti operare su un singolo server. Una delle configurazioni più raccomandate unisce 6 nodi in un server e la loro coesistenza è puramente logica, essendo fatta di semplici processi (nel senso Unix/Linux) che sono indipendenti l'uno dall'altro anche se operano nello stesso server. Questi elementi nodali di storage controllano la loro porzione del keyspace globale per localizzare i dati e soddisfare la richiesta di oggetti. I nodi operano nei server e si occupano di una porzione dell'anello globale di storage, dove ogni nodo gestisce una parte uguale del keyspace globale. La figura 7 illustra l'esempio di un anello di 12 nodi creato da quattro servers di storage, ognuno dei quali aziona a sua volta 3 nodi di storage. Si nota che ogni server è quindi responsabile di ¼ del keyspace. Il massimo della configurazione supportata è quindi di 6 nodi di storage per ogni storage server. Figura 7: Dai server fisici agli storage nodes organizzati in un anello logico (A0 D2 sono usati per illustrare che 2 nodi consecutivi non appartengono allo stesso server fisico) Chiavi dal peso di 20 bytes sono generate dai connettori, che le assegnano a diversi nodi, questi formano quindi un anello con un ruolo ben bilanciato grazie al fattore di dispersione presente nella stessa chiave. Figura 8: Formato di una chiave Scality a 160 bits, di cui 24 bits sono riservati al key di dispersione. Scality 11

13 Ogni nodo funziona come un semplice key/value store. La chiave non contiene informazioni di location ma l'algoritmo Chord si occupa costantemente di localizzare la chiave al suo nodo specifico. Inoltre la logica interna di ogni nodo determina la posizione appropriata dei dati object sul disco. I prefissi contenuti nelle keys sono sempre hashed o generati in random, portando ad una equilibrata distribuzione dei dati tra i nodi basata su solidi principi di hashing. Un altro punto essenziale della soluzione Scality è la nozione di decentralizzazione e di indipendenza dei nodi perchè essi non rimandano ad un'intelligenza centrale. Trattandosi di un'architettura peer-to-peer, ogni nodo può ricevere una richiesta per una chiave. Il percorso verso il giusto nodo segue l'equazione ½ log2(n), dove n sta per il numero di nodi nel Ring, e quando la topologia cambia una chiave è assegnata ad un nodo che si occupa di archiviare gli oggetti le cui chiavi sono immediatamente inferiori alla propria e superiori alle chiavi del nodo precedente. Al cuore dello stesso sistema, gli In/Out daemons, conosciuti come iod, sono responsabili della persistenza dei dati nel mezzo fisico. Il loro ruolo è quindi di scrivere i dati passati ai nodi sulla stessa macchina, monitorare lo storage ed assicurare la longevità. Ogni iod è locale in un dispositivo, gestendo lo spazio storage locale e comunicando solo con i nodi presenti nella stessa macchina. Non c'è quindi alcuno scambio tra il nodo di una macchina e lo iod di un'altra macchina. Diversi iod possono coesistere operando nella stessa macchina fisica. Una configurazione tipica porta uno iod per ogni disco, dove gli iod costituiscono il solo legame tra la residenza fisica di un data entry e lo strato di servizi rappresentato dai nodi e dai connettori. Il numero massimo di iods in un server è di 255, abbastanza da supportare un grosso carico locale. Lo storage fisico locale di un server consiste in partizioni regolari dal formato standard di sistema ext3. Ogni iod controlla il suo file system e i contenitori di dati che si trovano sopra di esso. Questi file containers sono, in concreto, unità elementari di storage del Ring che ricevono oggetti scritti diretti da iod a partire da richieste verso nodo generate da ogni connettore. Essi archiviano tre tipi di informazione: l'idex per reperire gli uggetti sul media, l'object metadata e gli stessi dati degli oggetti. La speciale architettura connector-ring-iod offre un abstraction layer totale per l'hardware e per il network, con i connettori che al di sopra agiscono come un entry gate verso il Ring. I nodi del Ring agiscono come server di storage e iod daemons producendo storage e occupandosi delle operazioni fisiche di I/O. Scality 12

14 Figura 9: I diversi elementi di un storage server La filosofia Scality è tutta centrata sul lancio di un'infrastruttura che non vuole compromessi tra le tre principali dimensioni dello storage: performance, disponibilità e scalabilità, e sa seguirne l'evoluzione in modo armonioso, accompagnando la crescita delle esigenze degli utenti come del service provider. 4.3 Prestazioni Le performance sono misurate sulla base di tre criteri: la latenza, la capacità di elaborazione e il numero di operazioni al secondo. La latenza è il tempo che intercoccorre tra la richiesta READ ed il primo byte di dati che si ottiene in risposta, è una funzione che determina la velocità del network, dello storage media e dei protocolli di storage distribuiti dal Ring. IOPS invece è il numero di operazioni prodotte al secondo, e può essere misurato come object IOPS (ovvero READ, WRITE e DELETE di oggetti interi) o del media fisico IOPS (blocchi del disco al secondo). A questo si associa il flusso di dati elaborati (throughput) della trasmissione in Gbit al secondo, comunemente chiamato bandwidth. La piattaforma di storage Scality Ring è concepita per adattarsi a diversi carichi di lavoro, spesso molto variabili, che possono includere piccole o grandi operazioni (svariati KB) con un alto tasso di transazioni al secondo, oppure grosse operazioni con un numero di transazioni relativamente basso. L'alto grado di parallelismo tra tutti i nodi, tra i servers e i connettori costituisce un forte differenziatore di performance della nostra piattaforma, così abbiamo applicato la filosofia "Divide and Conquer" attraverso una larga diffusione dei dati tra i vari storage nodes che operano su molteplici storage servers garantendo l'uso completo di ogni risorsa disponibile. Per trovare un file ovunque si trovi i sistemi di legacy storage devono esplorare i cataloghi centralizzati. Al contrario il Ring usa un algoritmo efficientemente distribuito basato su object keys, e confrontato all'aumento del carico di richiesta presenta una risposta sempre molto lineare. La latenza è perfettamente prevedibile, e il tempo di ricerca dei dati resta basso, anche con un un crescente numero di server o oggetti. Scality 13

15 La seconda generazione del protocollo Chord peer-to-peer non impone a tutti i nodi di conoscere la lista completa degli altri nodi (i peers della configurazione), le sue qualità principali consistono nella sua efficienza di routing. Nel Chord originale sviluppato dal MIT, ogni nodo ha bisogno di conoscere solo il suo successivo o precedente integrato nel Ring. In tal modo gli updates dei dati non esigono la sincronizzazione di una lista completa di tavole su ogni nodo e le informazioni restano comunque protette da ogni alterazione. Figura 10: Il metodo di lookup del connettore basato su un algoritmo Chord ad alta efficienza Servendosi dell'intelligenza del protocollo Chord il Ring offre una copertura completa delle ripartizioni di keyspace. Una richiesta iniziale viene indirizzata all'interno dell'anello Chord fino alla localizzazione del giusto nodo, il che provoca una serie di salti, ma le due informazioni chiave predecessore e successore- riducono la latenza con cui il protocollo localizza il giusto nodo. Appena il nodo voluto è reperito, il nodo che riceve la richiesta originale fornisce questa informazione direttamente in risposta al connettore. La figura 10 illustra una semplice richiesta di lookup fatta dal connettore, dove questo sollecita la chiave #33 ed il dispositivo conosce solo le chiavi 10 e 30. Il connettore raccoglie quindi la prima informazione e si connette a quel nodo, ovvero il 10. Successivamente vengono contattati i nodi 15, 25, 45 e 85; il protocollo determina che il nodo 25 collegato al nodo 35 rispondono alla richiesta della chiave 33, il nodo 25 rinvia quindi l'informazione al nodo 10 e successivamente al connettore. L'implementazione che Scality Ring fa del Chord ha modificato l'algoritmo originale nel modo seguente: Ogni nodo conosce il suo successore immediato e questa capacità dimezza esponenzialmente l'occorrenza di hops nello scambio di informazioni. Scality 14

16 Ne consegue che spesso un hop è necessario per trovare i dati; nel caso di un cambiamento della topologia il numero di hops segue l'equazione 1/2log2(n), dove n sta per il numero di nodi nel Ring. Questo porta ad un massimo di 4 hops per un anello di 100 nodi, e a non oltre 5 hops per un anello di 1000 nodi. Nel caso di un cambiamento come ad esempio un nuovo inserto o il failure di un nodo, un meccanismo proxy viene attivato per ristabilire l'equilibrio e garantire al Ring una topologia ottimale. Generalmente è raro quindi che la tavola di routing cambi anche dopo un inserimento, l'infrastruttura infatti non ha bisogno di interrompere, fermare o congelare il sistema quando vengono aggiunti nuovi storage servers. All'occorere di un failure il sistema lo tratta come la perdita di un cache, ed il processo di lookup ripristina la linea cache dopo averne determinato un nuovo route verso i dati. Scality permette un'impareggiabile topologia che favorisce l'inserimento e la rimozione di nodi nell'infrastruttura. Il Ring riesce quindi a soddisfare le queries anche quando il sistema cambia continuamente, e durante lo svolgersi delle normali operazioni la localizzazione del circuito connector-key-node è diretto, le performance sono ottimali. Scality RING si appoggia su numerose innovazioni tecnologiche, per esempio la capacità di integrare uno storage basato su Flash o le unità SSD nei server e i connettori che aiutano ad accrescere ulteriormente le prestazioni *. In modo simile, l'integrazione di carte network di 10 GbE ed oltre, o la configurazione di port multipli e CPU multicore ad alta frequenza possono procurare ulteriori e significativi miglioramenti. L'integrazione di questi nuovi elementi è possibile senza provocare disturbi o disequilibri al sistema, e sicuramente senza interruzioni di servizio. L'assenza di centralizzazione rimuove ogni potenziale "collo di bottiglia" in uno o più servers (come può invece verificarsi con un server che monopolizza l'accesso alle informazioni). Pertanto il sistema Scality evita i singoli punti di failure (SPOF) che potrebbero invece sconvolgere l'intero sistema. Le performance possono quindi estendersi oltre la definizione usuale abbinando la potenza del throughput ad una grande disponibilità del servizio., perchè Scality considera la più rapida capacità di recovery da un errore o un guasto come uno dei punti chiave del concetto di performance. * Consultare lo Scality Lab Report della ESG sulle performance di Scality RING con l'uso di storage SSD. Scality 15

17 Server Nodes Software Nodes 4kB get Objects/sec 4kB put Objects/sec ,573 26, ,882 33, ,410 39, , ,000 Figura 11: risultati di performance dove l'unità di misura è di oggetti al secondo Source ESG Auto-Tiering Scality include la propria tecnologia di storage tiering, incorporata nel Ring, detta Auto- Tiering. Il metodo garantisce il corretto allineamento tra il valore dei dati ed il costo dello storage in cui risiedono i dati, operando a livello di oggetti è quindi indipendente dalla struttura dati utilizzata dall'applicazione e può quindi essere applicato a molti diversi ambienti IT. Il Ring riceve criteri diversi che applica nel gestire lo spostamento dei dati e il motore di policy esegue autonomamente e automaticamente la migrazione degli oggetti all'interno di un singolo anello o tra gli anelli. L'object key continua a rimandare alla stessa posizione assicurando una perfetta fluidità per l'utente e per l'applicazione. È così possibile immaginare varie configurazioni, come ad esempio un consolidamento di storage attraverso un modello N-1, dove N è il numero dell' anello primario. Questi anelli N fanno migrare i dati verso un solo anello secondario e condividono la sua enorme capacità potenziale. Questa funzione fondamentale per i data center odierni consente di configurare, ad esempio, un primo Ring su SSD. Questo anello fornisce un rapido accesso ai dati e memorizza solo dal 10 al 20% dell'intero volume di dati. Ad esso è collegato un secondo anello, esposto a meno accessi, e con più capacità derivante dai dischi SATA, presentando un tempo di risposta più alto, ma ben adeguato alla funzionalità del sistema. La figura 4 illustra questa funzione di Auto-Tiering tra i 2 anelli all'interno dello stesso data center. Questa funzione opzionale raggiunge pienamente gli obiettivi di riduzione dei costi delle infrastrutture di storage e migliora sensibilmente il servizio di storage. 4.4 Protezione dei dati Scality RING fornisce diversi meccanismi per la protezione dei dati e dell'infrastruttura su cui si opera: replication e ARC, la nuova modalità per una configurazione dalla resilienza avanzata. Replication Scality offre un built-in in modalità di replica all'interno dell'anello capace di fornire un accesso ai dati senza eguali anche in caso di guasti. I dati vengono copiati in formato nativo senza alcuna trasformazione, questo procedimento offre un reale guadagno di prestazioni. Scality Replication crea copie multiple degli oggetti (chiamate repliche) tra i diversi nodi di storage, con la garanzia che ogni replica risiede su un server di Scality 16

18 archiviazione diverso grazie al fattore di dispersione espresso nella sua chiave (i primi 24 bit di ogni chiave). Il meccanismo sviluppato da Scality comporta garanzie di proiezione che determinano nodi di destinazione indipendenti per ulteriori copie di dati. Il numero massimo di repliche è 6, sebbene valori tipici siano 3 o 4. Inoltre, esiste un'opzione per abilitare la replica tra anelli multipli, sui siti stessi o su siti remoti con la flessibilità nella scelta della modalità: unidirezionale o multi-direzionale. Figura 12: Replication con 2 repliche Configurazione di resilienza avanzata Oltre alla replica, Scality ha sviluppato una configurazione avanzata di resilienza nota come ARC, la sua tecnologia di cancellazione dei codici basata su IDA (Information Dispersal Algorithm ) ben noti e sperimentati a lungo nelle telecomunicazioni. Il suo meccanismo di ricostruzione si basa sulla teoria di correzione degli errori Reed- Solomon3. ARC è una nuova funzionalità opzionale che opera all'interno dell'anello per proteggere i dati in modo intelligente contro i guasti di dischi, server o rack. Questa nuova modalità di configurazione riduce il numero di copie e evita doppie o triple informazioni simili. Pertanto questo meccanismo riduce notevolmente il CapEx di hardware nonché il relativo OpEx. Come breve descrizione di Scality ARC, proviamo a pensare ad n oggetti che devono essere memorizzati e protetti. Per semplificare la dimostrazione, si presume che essi siano tutti di dimensione 1MB. Diciamo che il fine è proteggersi contro dei failure che chiameremo k (scriviamo quindi ARC (n, k)). Scality ARC memorizzerà ciascuno degli n pezzi di contenuto individualmente, e in aggiunta conserverà k nuovi oggetti che chiamiamo checksum. Questi checksum sono combinazioni matematiche degli n oggetti originali, in tal modo che si possa ricostruire tutti gli n oggetti, nonostante la perdita di elementi k, siano essi oggetti o checksum. Con Scality ARC, ciascuno dei checksum k sarebbe di dimensione 1 MB, offrendo una protezione contro la perdita di k dischi o server, con un solo un extra k MB di memoria richiesta. Per illustrare i benefici e il meccanismo che sta dietro a questa teoria useremo il seguente esempio: Scality 17

19 Figura 13: La Configurazione di Resilienza Avanzata con il modello 16,4 Qui, con solo 4 MB di storage addizionale abbiamo protetto 16 MB contro la perdita di 4 dischi o server, ottenendo una spesa di 4/16=25%, sensibilmente più bassa del costo di replication che è del 200%, e per una protezione molto più efficace di quella offerta da un RAID 6. Da notare che il codice di erasure protegge contro la perdita di server oltre che di dischi, il che non è possibile con RAID. Applicare la tecnologia tradizionale di erasure code allo storage presenta un "penalty on read" il che significa che il lettore deve leggere numerosi elementi e poi estrarre i dati per ricevere l'informazione originale. Questo è lo svantaggio di un approccio di storage disperso, perchè introduce da 200 a 300 ms di latenza nel servire i dati. Per evitare questo eccesso di IOPS, Scality sceglie di archiviare i frammenti originali di dati con i frammenti checksum in modo indipendente. Scality implementa un modello (16,4), che fa riferimento ad ARC (16,4) e questo significa che la ridondanza copre un ulteriore 25% dello spazio dati. Se confrontiamo replication e ARC in termini di ottimizzazione dei costi per lo stesso livello di ridondanza, replication con 3 copie richiede 2 spazi supplementari di storage e ARC (16,4) ha bisogno solo del 25% in più di spazio, che rappresenta 8 volte meno storage o solo il 12.5% del caso di replicazione per lo storage dedicato alla protezione. Globalmente per lo spazio di protezione dei dati, l'integrazione di ARC rappresenta 2,4 volte meno storage della configurazione totale con la replicazione. Questo è ciò che Scality ha implementato e che raccomanda per le configurazioni su larga scala. Così ora è possibile ottenere un'affidabilità migliorata di volte che con RAID 6, senza più overhead del disco e niente più colli di bottiglia che limitino le performance. In confronto con una memoria dispersa, l'approccio Scality evita le limitazioni di lettura e continua ad offrire il miglior tempo di risposta con un'operazione di lettura diretta sui dati. Scality 18

20 Figura 14: Esempio di Scality RING ARC a confronto dei metodi di Replication dispersi Nella tavola seguente riassumeremo alcuni risultati con una configurazione di 1PB di storage usando RAID5, RAID6, il processo di Replication and lo Scality ARC. RAID 5 con 5 dischi di dati ed un disco parity mostra un ottimo overhead di storage ma una configurazione debole in quanto a longevità dei dati. Invece RAID 6 con 6 dischi dati e 2 dischi parity presenta altri vantaggi con un'interessante longevità ma una tolleranza assai limitata al disk failure. Questi limiti dimostrano che RAID 6 non è la scielta migliore per grandi configurazioni, specialmente per quelle che superano 1PB. Replication è una soluzione buona e affidabile ma il costo rappresentato dallo storage overhead può costituire uno svantaggio per certi account o certe configurazioni. Infine Scality ARC, con configurazione 16,4 aggiunge solo un 20% di storage overhead, con un rischio di perdita dati eccezionalmente basso ed un'alta longevità associata alla capacità di tollerare svariati failure nei nodi di storage. Figura 15: Confronto di Scality ARC le configurazioni RAID e Replication Scality 19