SCALE - OUT NAS: ISILON porta lo storage nel futuro (parte 2)

Nella prima parte, abbiamo illustrato i principi su cui è fondato il sistema EMC ISILON. Il paradigma dello Scale-Out, realizzato attraverso l’adozione di un’architettura cluster (invece del tradizionale approccio controller-array) e l’implementazione di un sistema operativo in grado di virtualizzare tutte le risorse hardware,  non sarebbe completamente realizzato senza una modalità innovativa ed efficiente di protezione dei dati.  OneFS aggrega le funzionalità di RAID Management, Volume Management e File System in un unico livello software che svincola definitivamente le esigenze di protezione dei dati dal livello fisico e consente agli storage manager di gestire i dati, non l'infrastruttura.

N+M: PROTEZIONE DEI DATI OLTRE I CONFINI DEL RAID

Big Data non significa soltanto grandi quantità di dati, ma anche dati che sono continuamente modificati,  che si espandono continuamente e un tasso di obsolescenza molto più accelerato del normale: il RAID è un meccanismo troppo statico e oneroso dal punto di vista dell’overhead per essere considerato ottimale. 

Il livello tradizionale di protezione dei file (mirroring e FEC) è sempre stato definito a livello fisico, mediante la creazione dei gruppi RAID, indipendentemente dal ciclo di vita dei dati. E’ possibile però che uno stesso dataset abbia una criticità maggiore in una certa fase della sua vita rispetto a un’altra o che nuove policy aziendali richiedano una modifica non prevista al livello di protezione dei dati. In un array basato sul RAID, questo significherebbe onerose e rischiose operazioni di migrazione dei dati e ricostruzione dei gruppi RAID, oppure acquisto di nuovo spazio disco.

EMC ISILON implementa invece un meccanismo proprietario estremamente flessibile, in cui l’elemento atomico del gruppo di protezione non è più il singolo disco, ma il nodo, e che consente di riconfigurare il livello di protezione online a seconda delle esigenze e senza più necessità di migrazione dati. 

Tale meccanismo è chiamato N+M. I vantaggi del N+M sono immediatamente comprensibili, se paragonato al RAID:

Feature	N+M	RAID
Fault Tolerance	Fino a 4 failure (N+4)	Fino a 2 failure (RAID 6)
Flessibilità	Livello modificabile a caldo (SW level)	Non modificabile a caldo   (HW level)
Granularità	File Level (SW)	Raid Group Level (HW)
Efficienza vs Scalabilità	Variabile (a parità di protezione, l’efficienza aumenta con la dimensione del cluster)	Fissa (a parità di protezione, aumentando la capacità bisogna creare nuovi gruppi RAID )

Sebbene N+M sia in qualche modo paragonabile al RAID, è importante ricordare che mentre il failure, nel RAID, è riferito ad uno o due dischi all'interno di un RAID Group, per ISILON, un failure è riferito a un NODO, quindi fino a 36 dischi di uno stesso nodo che possono contemporaneamente essere offline senza alcun impatto sulla disponibilità dei dati. L’implementazione della protezione N+M è molto semplice.

•                    Ogni volta che un client scrive un file in un cluster ISILON, questo è suddiviso in blocchi da 128 KB

•                    Per ogni N di questi blocchi, il sistema calcola M blocchi di parità, sempre da 128 KB

•                    Gli N+M blocchi risultanti costituiscono una stripe (o protection group)

•                    La stripe viene scritta sui dischi, un blocco per nodo ( * )

•                    Il procedimento viene ripetuto fino all’esaurimento della dimensione complessiva del file

( * )  La massima estensione di una stripe è 20 blocchi, di cui al massimo 16 di dati e i restanti di parità. Ogni blocco di una stessa stripe viene scritto su un nodo diverso, perciò per cluster inferiori ai 20 nodi N+M è uguale al numero dei nodi del cluster, mentre per cluster più grandi, la stripe sarà scritta al massimo su venti dei nodi che compongono il cluster.

Nell'immagine seguente, è riportato l'esempio di un file che viene scritto con una doppia protezione in un cluster composto da 6 nodi (N=4, M=2) . Nella pratica, il nodo che ha in carico la sessione di file sharing si occupa di dividere il file, calcolare la parità ed inviare infine i blocchi agli altri nodi.

Per file più piccoli di 128 KB, il risultato della procedura N+M è un mirroring, quindi, di fatto, i file di piccole dimensioni vengono mirrorati (OneFS supporta nativamente anche il mirroring da 2x a 8x). Ovviamente, OneFS gestisce e ottimizza file la cui dimensione non sia multiplo di 128 KB, ma la spiegazione di come siano trattati i casi particolari di striping(incluse le configurazioni N+M:b) esula dallo scopo di questo post. Il grande vantaggio dell’algoritmo N+M è che N e M sono numeri configurabili a seconda delle esigenze, con l’unico vincolo che N sia maggiore M, quindi, per esempio, la doppia parità è applicabile solo a cluster con un numero di nodi uguale o superiore a 5 e così via. Il valore di M (cioè del numero di fault tollerati) varia da 1 a 4 . M = 1 corrisponde a una protezione a singola parità (protezione equivalente a quella del RAID 5) mentre M = 2 corrisponde a una protezione a doppia parità (protezione equivalente a quella del RAID 6).Il livello di protezione può essere definito su base file o cartella e può essere modificato a caldo, svincolandosi pertanto definitivamente dalla quantità e dalla configurazione dei dischi sottostanti.

Vale la pena sottolineare il fatto che M = 3 e M = 4 sono livelli di protezione non raggiungibili con i tradizionali RAID e pertanto da nessun altro sistema.

Ultime due considerazioni: la distribuzione dei blocchi in cui il file è suddiviso su un numero ampio di nodi ha due conseguenze dirette molto importanti: innanzitutto, un nodo non è mai un Single Point of Failure per la disponibilità e l'integrità dei dati, perchè un file in nessun caso può risiedere interamente su un unico nodo; in secondo luogo, l'utilizzo bilanciato di tutti i nodi evita la creazione di hot spot e consente al sistema di lavorare in maniera efficiente, sia dal punto di vista delle prestazioni che da quello dell'utilizzo della capacità.

Alcuni esempi pratici:

CLUSTER di 3 NODI, protezione a singola parità: N+M diventa 2+1 (ovvero il file viene suddiviso in stripe composte da 3 blocchi di 128 KB, di cui due di dati e una di parità). L’efficienza dello storage è 67%.

CLUSTER di 8 NODI, protezione a singola parità: N+M diventa 7+1 (ovvero il file viene suddiviso in stripe composte da 8 blocchi di 128 KB, di cui sette di dati e una di parità). L’efficienza dello storage è 87%.

CLUSTER di 8 NODI, protezione a doppia parità: N+M diventa 6+2 (ovvero il file viene suddiviso in stripe composte da 8 blocchi di 128 KB, di cui sei di dati e due di parità). L’efficienza dello storage è 75%.

Cluster di 18 NODI, protezione a singola parità: N+M diventa 16+1 (ovvero il file viene suddiviso in stripe composte da 17 blocchi di 128 KB, di cui sedici di dati e una di parità). In questo caso, ogni file sarà suddiviso su un diverso sottoinsieme di nodi, in modo che l’occupazione complessiva dei nodi sia sempre bilanciata. L’efficienza dello storage è 88%.

Cluster di 20 NODI, protezione a quadrupla parità: N+M diventa 16+4 (ovvero il file viene suddiviso in stripe composte da 20 chunk di 128 KB, di cui sedici di dati e quattro di parità). L’efficienza dello storage è 80%

Nota Bene: Gli esempi riportano casi molto semplici in cui un solo algoritmo di protezione è stato definito per tutto il cluster, per cui è molto semplice calcolare l’efficienza. Vale la pena ricordare che si può applicare una diversa protezione a diversi sottoinsiemi di dati nello stesso filesystem, pertanto l’efficienza, seppure sempre crescente al crescere del numero dei nodi, non risulta più immediatamente calcolabile a priori.

XtremIO: Garbage Collection? No, Grazie!

Il minimo da sapere.

Durante il  lancio il 14 novembre, per XtremIO, è stato affermato che non dispone di eventuali processi di Garbage Collection (da qui in avanti detto G.C.) a livello di sistema.   Questo però è stato interpretato  da alcune persone come se XtremIO fosse in qualche modo impermeabile alla necessità di G.C. Ovviamente non è possibile, tutti i dischi flash richiedono la procedura di G.C.  Ciò che conta è dove e come la G.C. è effettuata.  Con XtremIO, dovendo garantire prestazioni sempre coerenti e prevedibili, il processo di G.C.
viene gestito in maniera nuova e unica.

Quindi come mai XtremIO non richiede G.C. a livello di sistema, mantenendo prestazioni costanti e prevedibili?

... prima dobbiamo essere d'accordo sulla definizione di cosa è e cosa fà la G.C. 

Con un disco tradizionale i nuovi dati possono essere scritti proprio sopra quelli esistenti, nel senso che la testina cerca solo la posizione da sovrascrivere e ri-magnetizza con il nuovo contenuto. Con i dischi flash, i dati esistenti devono prima essere cancellati (un'operazione molto lenta) e quindi i nuovi dati possono essere "riprogrammati" in quelle celle. A peggiorare le cose c'è che non si può semplicemente cancellare esattamente ciò che si desidera. Immaginate di avere un "erase block" di 256 KB, per modificare solo 8K dell'intero blocco, si dovranno leggere tutti i 256KB, poi bufferizzarli, poi cancellare o modificare gli 8K, poi i 256KB aggiornati possono essere scritti sulla cella.

Questo viene anche detto "write amplification" (wikipedia > Write_amplification) e poiché i dischi flash hanno comunque un numero finito di cicli di Write , questo non và troppo bene, no?

... e per capire perché, dobbiamo tornare un pò indietro nella storia. 

XtremIO & Database: Sfruttare nuovi modi per risparmiare sui costi dei database

Uno dei casi di utilizzo più interessanti di XtremIO è quello relativo al cost saving nel mondo dei DB.
Analizziamo brevemente la situazione attuale: in molti degli ambienti IT di oggi, con storage “tradizionali”, i database non possono operare in piena efficienza e offrire il rapporto costi/prestazioni che i clienti richiedono. I requisiti di cui i DB oggi hanno bisogno sono: una bassa latenza, elevate performance e throughput adeguato. Avere un ambiente a bassa latenza diventa estremamente vantaggioso quando è combinato con altre importanti funzionalità evolute.

In questo breve documento, verranno analizzati degli aspetti quali cloning, facilità di utilizzo e licencing e il loro significato per il cost saving nel modo dei DB.

Prima di iniziare vogliamo introdurre alcuni concetti utili per capire meglio alcuni ragionamenti presenti nel documento; “service time” & “wall-clock-time”.

“Service time”: quando un processo (DB) deve aspettare per interagire con lo storage, il “wall-clock-time” viene sprecato, ciò significa perdita di denaro e di tempo che non può essere recuperato.

Il “wall-clock-time” fa riferimento al tempo effettivo necessario ad un host per completare un determinato compito. È la somma di tre termini, tempo di CPU, tempo diI/O più il ritardo di comunicazione sul canale (ad esempio, se i dati sono sparsi su più macchine). A differenza del tempo di CPU, che misura solo il tempo durante il quale il processore sta lavorando attivamente su un certo compito, il “wall-clock-time” misura il tempo totale per il completamento del processo. 
La differenza tra i due consiste nel tempo trascorso a causa di ritardi programmati o in attesa di risorse che devono diventare disponibili, nel nostro caso, la componente storage.

SCALE - OUT NAS: ISILON porta lo storage nel futuro (parte 1)

Scale-Out non è solo un termine di marketing, sebbene sia usato spesso impropriamente. La “scalabilità orizzontale” indica la capacità di un sistema storage di far crescere in maniera lineare e organica tutte le proprie componenti: la capacità, le risorse computazionali, i collegamenti di front-end, senza far aumentare contestualmente gli OPEX e la complessità dell’architettura (ad esempio con componenti non nativi del sistema), migliorando la gestione, l’efficienza e la resilienza al crescere delle dimensioni del sistema. Solo un sistema progettato e ingegnerizzato sin dal principio in tal senso può realizzare il paradigma Scale-Out senza compromessi.

Gli storage legacy hanno dei limiti architetturali che li rendono estremamente inefficienti nel mondo dei Big Data. Innanzitutto, non sono in grado di scalare agilmente e velocemente: l’architettura a doppio controller, definita retroattivamente “Scale-UP”, crea implicitamente delle “isole” di storage che faticano a interfacciarsi tra loro e richiedono una costante manutenzione (migrazioni, bilanciamenti delle connessioni di front-end…). Sul fronte della protezione, la tecnologia RAID presenta un conto troppo salato da pagare sul piatto del rapporto usable / raw quando le quantità di dati in gioco sono nell’ordine dei PETAbyte (e oltre…) . L’architettura gerarchica controller + array di dischi costringe infine a pianificare gli acquisti con largo anticipo e impedisce un utilizzo intelligente e adattivo delle risorse computazionali.

EMC ISILON vanta un’esperienza decennale nel campo dei Big Data: sebbene faccia parte della famiglia EMC solo da pochi anni, è adottato con successo da oltre un decennio in tutti i Vertical che per primi hanno affrontato la tematica dei Big  Data (si pensi al Vertical dei M&E, con l’esplosione del video in alta risoluzione e del 3D o alla quantità di dati elaborata ed immagazzinata quotidianamente da un qualunque social network).

In questo articolo, introdurremo l’architettura di ISILON evidenziandone in sintesi le caratteristiche principali e le componenti che lo rendono unico nel panorama degli Scale-Out NAS.

Content Delivery : Whatever – Whenever – Wherever - On any device

Siamo entrati nella nuova era del “WWW” che sta per “Whatever – Whenever – Wherever” che ci permette di controllare cosa consumiamo, dove,  quando e su ogni dispositivo.

E come ogni cambiamento d'era, provoca grandi cambiamenti. Uno dei settori più pesantemente impattato è il M&E.

Il  numero di contenuti video sempre maggiore, dei divers formati adatti ai diversi device, di nuovi workflow così come i Could Digital Recorders ed i file con risoluzioni sempre maggiori  (HD, 4K , 8 K) hanno portato questo settore a forti cambiamenti.  Volete un esempio pratico? La Sony ha annunciato che trasmetterà i mondiali  di calcio in Brasile in 4K (ultra HD, dopo il full HD la risoluzione viene espressa per numero di pixel in orrizzontale e non più in verticale) e entro 2016 lancerà i televisori a 8K.

Per chi non è avvezzo con queste sigle qui di seguito l’evoluzione dei vari formati:

Tutte questi contenuti devono essere memorizzati e distribuiti  per permette a tutti noi di poterne usufruirne.  Questo porta ad una trasformazioni in tutti gli ambiti dei worklfows nel Media & Entertainment

Hadoop: di cosa si tratta ?

Cos'è Hadoop ?

La crescita impressionante dei dati osservata negli ultimi anni, e destinata a proseguire nel futuro, ha fatto nascere molti progetti indirizzati a trovare delle soluzioni il più possibile semplici ed economiche per:

1. Archiviare le informazioni
2. Eseguire delle elaborazioni su moli di dati fino a poco tempo fa impensabili (decine di Petabytes e più). 

Poiché la gran parte delle informazioni oggi generate è di tipo non strutturato (files), è in questa direzione che molti dei progetti si sono mossi e tra questi anche Hadoop.

Hadoop nasce come progetto per l'analisi distribuita di grandi insiemi di dati attraverso un semplice modello di programmazione.  L'architettura, realizzata in Java, permette di poter scalare da pochi server fino a migliaia di sistemi: ogni server contribuisce con le proprie risorse di calcolo e la propria capacità di memorizzare i dati, e quindi aggiungendo server, chiamati anche "nodi", è possibile far crescere un sistema Hadoop in modo quasi lineare. Benché non vi siano restrizioni specifiche per i nodi, di norma vengono utilizzati dei sistemi x86 standard, il che permette di poter tenere sotto controllo i costi complessivi della soluzione e allo stesso tempo di beneficiare della crescita in termini computazionali di queste architetture.

L'alta affidabilità, e dunque la protezione dei dati, viene realizzata non basandosi sulle caratteristiche hardware dei server, ma bensì a livello software: sono le librerie di Hadoop che si occupano di identificare se e quali componenti presentano un malfunzionamento, ed intervenendo per ripristinare le operazioni (ad esempio creando una nuova copia dei dati contenuti in un server). E' evidente che nella scala dei Petabytes le soluzioni di backup tradizionali non sono utilizzabili, e quindi è proprio la distribuzione dei dati su nodi differenti la chiave per salvaguardare le informazioni anche di fronte ad un guasto di uno dei nodi (Hadoop adotta come standard la scrittura dello stesso dato in tre locazioni differenti).

Le due componenti fondamentali di Hadoop sono quindi

• Il sistema di gestione distribuita dei dati: l'Hadoop Distributed File System (HDFS)
• Il sistema di elaborazione parallela dei dati: MapReduce

A fianco a queste componenti fondamentali si trovano altri moduli che aggiungono ulteriori funzionalità alla piattaforma: citiamo a titolo di esempio HBase,  un database distribuito per la gestione strutturata di dati sotto forma di tabelle di grandi dimensioni, e Hive, un modulo pensato per il datawarehousing che rende possibile interagire con i dati di Hadoop con un interfaccia SQL-like. I moduli addizionali si collocano "sopra" HDFS e MapReduce, che sono sempre presenti come fondamenta dell'architettura: ecco quindi che i dati strutturati di HBase sono memorizzati come files in HDFS e le query SQL di Hive sono eseguite da MapReduce.