EMC ed il settore dell’Oil & Gas

Nuova strategia e rinnovato focus

di Eugenio Manini

In qualità di Account Systems Engineer che opera da diversi anni su una primaria azienda italiana del Settore Oil & Gas / Energy, desidero in questo breve articolo dare un aggiornamento sulla posizione di EMC in ambito Oil & Gas, frutto di una recente conferenza world wide tenutasi a Londra a fine Febbraio 2014.

Il Vertical Oil & Gas per EMC sta diventando sempre più strategico e si affianca ai più maturi e consolidati Telco, Banking, Automotive, Retail, Healthcare, giusto per citare i più importanti.

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.

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.

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.

L'Universo Digitale: opportunità e sfide per le aziende in un'infografica

Di quanto crescerà l'Universo Digitale nei prossimi anni, e dove ? Quanto (poco) sono protetti i dati? Un'infografica può aiutare a scoprirlo:



Il report completo è disponibile in questa pagina, con numerosi approfondimenti sull'Universo Digitale.
Decisamente consigliata la versione interattiva del report, che permette di navigare in modo molto agile tra le varie sezioni.

RISOLVERE LE PROBLEMATICHE DI UN MONDO BASATO SUI DATI

La Business Intelligence alla velocità richiesta dal mondo di oggi: i risultati di un Proof Of Concept.

L’aumento vertiginoso dei dati disponibili (Big Data)permette di ottenere una visione più completa di come un mercato si muove, delle opportunità che offre e della economicità o anti-economicità di possibili scelte aziendali.
Conoscere approfonditamente la realtà che circonda la propria azienda permette di avere più prontezza nel prendere decisioni che possono influire sia sull’aumento del fatturato o profitto, sulla razionalizzazione e ottimizzazione dei costi e sulla percezione che ha il mercato e, quindi, sull’evoluzione della proposta di prodotti e servizi.

Alcuni esempi riguardano:

• Dal punto di vista del Business, e cioè del Top Management delle aziende, è sempre più importante poter prendere decisioni su come muoversi sul mercato, quali prodotti o soluzioni hanno la maggior probabilità di prendere piede (e quindi generare utile) o, viceversa, quali mostrano trend negativi e, quindi, come approntare per tempo piani alternativi.

• Anche per quanto riguarda l’efficienza interna (in ottica di riduzione dei costi) riuscire a ottimizzare i cicli di produzione, lo stoccaggio delle merci, l’approvvigionamento delle componenti, la conoscenza della mortalità della componentistica e la conseguente efficienza dei magazzini ricambi permettono di aumentare il rapporto costo/guadagno e, soprattutto, aumentare l’immagine verso i propri Clienti/Utenti.

• La conoscenza dei commenti della comunità dei Clienti, inoltre, è diventata possibile grazie ai Social Network e alla possibilità di analizzare i commenti che vengono fatti (Sentiment Analisys); questo permette di avere una percezione (soprattutto su nuovi prodotti o soluzioni) in tempo reale di quali sono considerati i Plus o Minus e, anche, di conoscere quali sono le caratteristiche che accendono l’immaginario dei Clienti; da queste analisi discendono varie possibilità: da campagne di marketing mirate sui Plus, a dare le giuste priorità alle modifiche e o novità da apportare (Minus) e, anche, ad avere nuove idee su come far evolvere la propria offerta.

Tecniche di scale-out

Elaborazione parallela: Tecniche di Scale-Out

Una delle maggiori sfide nell'ambito dei Big Data è come gestire le grandi quantità di dati in modo efficiente e scalabile. Il tema della scalabilità è particolarmente delicato nel mondo Big Data in quanto, come noto, i dati spesso crescono in modo molto veloce, e quindi occorre predisporre una soluzione architetturale in grado di rispondere a questa crescita in modo flessibile.

Per affrontare queste sfide l’approccio più diffuso è quello dell’elaborazione parallela del carico di lavoro: l’idea di fondo è quella di suddividere il carico tra le diverse componenti del sistema in modo che ciascuna possa operare in autonomia, parallelizzando quindi un lavoro che altrimenti dovrebbe essere eseguito procedendo serialmente,un passo alla volta.

La tecnica di Scale-Out è una delle soluzioni architetturali che sta dimostrando di essere particolarmente efficiente in questo ambito: si tratta di una architettura a scalabilità orizzontale che prevede l’aggiunta progressiva di “nodi”, ciascuno in grado di fornire al sistema nuove risorse di calcolo e di memorizzazione delle informazioni.

In questo tipo di architetture il carico di lavoro viene suddiviso tra i vari nodi in modo da permettere un’elaborazione parallela: ciascun nodo elabora i dati localmente e ritorna al sistema il proprio risultato parziale; i risultati parziali sono poi riaggregati ottenendo il risultato finale.

Si parla in questo caso di Massive Parallel Processing (MPP): se tutti i nodi sono equivalenti ci troviamo di fronte ad un MPP simmetrico, mentre se alcuni nodi ricoprono un ruolo differente si parla di MPP asimmetrico.  La distinzione non è puramente accademica: in un sistema asimmetrico infatti è possibile che alcuni nodi arrivino alla saturazione mentre altri nodi risultino invece scarichi; un classico caso è dato dai sistemi nei quali i nodi sono distinti tra front-end e back-end: in queste architetture è abbastanza comune che si arrivi alla saturazione del sistema quando una delle due componenti giunge al 100% di utilizzo (spesso è il front-end), anche se le restanti componenti avrebbero, almeno in teoria, ancora diversa capacità di poter erogare. Il fatto di aver “specializzato” i nodi non permette di poter (ri)utilizzare la capacità residua. Alcune soluzioni asimmetriche permettono di inserire nuovi nodi in modo indipendente (alimentando ad esempio il front-end o il back-end), mentre in altri casi occorre far crescere tutto sistema anche se la saturazione riguardava solo una delle sue parti.

Un sistema simmetrico garantisce la distribuzione del lavoro fra tutte le componenti, rendendo possibile una scalabilità quasi lineare. In questo caso la saturazione viene raggiunta quando tutte le componenti raggiungono  il 100% di utilizzo: l’aggiunta di nuovi nodi permette qui di crescere in modo controllato e progressivo, senza il “problema” di avere nodi sottoutilizzati.

La presenza di nodi sottoutilizzati, frequente nel mondo asimmetrico, è un problema non solo tecnico, in quanto causa una saturazione “prematura” del sistema, ma anche economico: il cliente infatti ha acquistato nodi che non riescono ad operare al 100%, e allo stesso tempo consumano corrente elettrica e soprattutto licenze software.  

La scelta della corretta architettura è ovviamente un aspetto critico di ogni soluzione Big Data: non esiste un'unica ricetta per tutte le necessità quindi il consiglio è di non fidarsi delle proposte “one size fits all”  ma valutare invece quali soluzioni il mercato metta a disposizione.

Un esempio di MPP simmetrico in casa EMC: Geenplum Database.

L’architettura MPP simmetrica è alla base di Greenplum Database, una soluzione disegnata per la Business Intelligence e l’analisi dei Big Data. Il principio centrale del Greenplum Database è quello di spostare le capacità di elaborazione il più vicino possibile ai dati: l’architettura MPP permette di eseguire le operazioni in modo pienamente parallelo, utilizzando contemporaneamente tutte le connessioni verso lo storage. Il parallelismo viene usato non solo in fase di “lettura” dei dati, ma anche nella fase di caricamento dei dati stessi, che in tutte le altre soluzioni presenti nel mercato risulta invece necessariamente seriale. Nel sistema Greenplum i dati fluiscono dai sistemi sorgente verso tutti i nodi del database, senza richiedere la presenza di un singolo punto di accesso (che diventa ovviamente un collo di bottiglia). In questo modo Greenplum Database è in grado di raggiungere velocità di caricamento di più di 10TB/ora per rack (e una velocità di scansione dei dati di 24GB/sec).

La scalabilità del sistema Greenplum è ottenuta in modo lineare aggiungendo nuovi nodi: ogni nodo porta con sé le risorse di elaborazione e di memorizzazione dei dati. Partendo da un minimo di quattro nodi è così possibile analizzare universi dati di alcune centinaia di gigabytes, per raggiungere progressivamente dimensioni che possono arrivare all’ordine di multi-petabytes.

GZ

Per maggiori su Greenplum Database potete visitare la pagina descrittiva della soluzione nelsito Pivotal.