Premessa.Questo documento vuole descrivere approfonditamente le analisi e i criteri di

valutazione di alcuni prodotti di storage sul mercato, esaminati allo scopo di acquistarneuno nuovo per migrare le VM dell'infrastruttura di virtualizzazione del servizio informatico.L'avvio del procedimento di acquisto è da imputare ad alcune gravi criticità nello storage inuso (acquistato appena due anni prima) che pregiudicavano la continuità di servizio delleattività informatiche istituzionali e ritenendo incerto e non risolutivo il metodo dello scale-updel sistema. Durante il periodo di indagine e nella scelta finale sono stati coinvolti ilresponsabile dell' U.O.C. Servizio Informatico dell' Ulss 5 Ing. Giorgio Roncolato e ilcollega Ing. Nicola Povoleri. Un ringraziamento particolare va al Dott. Matteo Durighetto,Data Scientist in Miriade, per il contributo indispensabile all' indagine.

Il mio ruolo in azienda è quello di coordinatore della attività che riguardano leinfrastrutture informatiche hardware e software: networking wired e wi-fi, storage,computing, server e software virtualization, security (client, server, perimetrale) e softwaredi infrastruttura (routing,dhcp, dns, ntp, autenticazione, posta). In tutti gli ambiti hoacquisito un livello di conoscenza adeguato per la conduzione e lo sviluppo dei sistemi insinergia con i colleghi e i consulenti. Molte delle note segnalate hanno un contenutomatematico scientifico di tipo accademico, ma con frammenti, a volte comprensibili inparticolare nelle conclusioni che bel complesso aiutano ad orientarsi.

A distanza poco più di due anni dall'ultima indagine il mercato dello storage èprofondamente trasformato, affollato di vendor vecchi e nuovi con prodotti, nomi eacronimi talora sconosciuti. Nella precedente relazione ho esposto una sintesi degliavvenimenti che, a mio parere, hanno cambiato un settore da anni considerato stabile ematuro e che in questo documento proverò ad approfondire ricordando il ruolofondamentale del software in licenza GPL.

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

U.O.C. Servizio Informatico

Analisi del prodotti di archiviazione dei dati sul mercato e selezione della migliore soluzione per l'infrastruttura di virtualizzazione del datacenter del sistema informatico: note tecniche.

Parte prima: evoluzione storica dello storage.

La diffusione capillare di tecnologiedi virtualizzazione dei server, ed inparticolare l'evoluzione tecnologica virtuosadi ESXi di Vmware, ha incoraggiato iresponsabili IT a migrare i dati gestiti daDBMS, CMS, DMS, ecc, anche noto comeTier 1 Storage, dalle LUN SAN/iSCSI/NFSdirettamente all'interno dei vmdk ottenendouna prima astrazione, de facto, dellostorage.

Nel 2012 Google annuncia di avercompletato la transizione della propriainfrastruttura di rete in termini di “SoftwareDefined Network” (SDN)1 innescando ladiffusione del concetto “Software Defined”in altri settori come quelli del DataCenter(SDDC) e dello Storage (SDS). Poiché l'SDN non ha avuto la diffusione sperata neinostri datacenter, reti locali e campus, vienea mancare quel minimo comundenominatore di esperienza maturata dall'uso nel tempo. Al contrario si sa bene, purtroppo, come implementare una rete configurando vlan L2, uplink trunk, lacp, SpanningTree, rip, ospf, acl L3/L4, dhcp snooping, ecc.,ecc. La promessa attesa era la trasformazione di ciò che conosciamo in termini nuovi secondo quanto ONF2 propone come concetto di SDN: un framework per gestire l'infrastruttura di rete che consenta di essere programmabile, configurabile, agile, amministrabile centralmente, basato su

standard e neutrale rispetto ai produttori di apparati. Cosa rappresenta l'SDS in concreto parlando di storage?

1 http://www.nextplatform.com/2015/06/19/inside-a-decade-of-google-homegrown-datacenter-networks/ 2 ONF https://www.opennetworking.org/sdn-resources/sdn-definition

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Illustrazione 2 Fonte: Intel

Illustrazione 1 Fonte: WMware

Se nel mercato enterprise il cliente medio è indeciso cosa scegliere tra storage SANo NAS, aziende come Google, Amazon, Facebook e Microsoft competono in sfide maiaffrontate prima, gestire PetaByte di dati in modoveloce, affidabile, sicuro e, soprattutto, economico.Nessuno di loro si affida ai big vendor sul mercatopreferendo la via dell'innovazione tramite soluzionihardware e software custom. Google con ilprogetto Google File System (GFS) ha avuto ilruolo di pioniere in questo scenario creando nuovearchitetture e coniando concetti come web-scale,hyper-scale, hyper-converged.

Parallelamente a tutti questi processi apartire dal 2009 arrivano sul mercato i primi dischiSSD in tecnologia flash con interfaccia SATA/SAS(prima erano solo in PCIe) che permettono laprogettazione di storage “classici” ad alteprestazioni. Per rendere accessibili questi nuoviprodotti alcuni produttori creano una nuovacategoria di storage Hybrid-Array con mix di dischimagnetici e flash. Gli storage All Flash Arrayintroducono il termine di “frullatore”, ossia storagecon alcuni ordini di grandezza di performancesuperiori agli storage tradizionali, che “macinano”migliaia di IOPs qualunque cosa venga inserita.Con l'introduzione di nuove tecnologie SSD i prezziper GB diventano sempre più convenienti eprobabilmente Amazon diventa il più grandevendor di flash storage.

L'offerta di storage con dischi/schede flashsoddisfa pienamente alcuni settori IT /ad esempiofinanza) dove alti valori di IOPs e bassissimalatenza sono condizioni necessarie per ottenere benefici immediati. Spesso però vengonovenduti in architetture tradizionali mutuate da quelle consolidate con sistemi di protezionein RAID5 e architetture di crescita di tipo scale-up. Quando ex collaboratori di Google,Amazon o Facebook fondano proprie start-up, iniziano ad apparire soluzioni di storageche portano nel mercato enterprise aziendale tecnologie fin'ora appannaggio esclusivo deidatacenter Cloud: web-scale, hyper-converged, hyper-scale. Quando gli storage nonsono embedded in hardware esterni dedicati, ma negli host standard e virtualizzati inhypervisor si conia il termine di Virtual SAN.

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Illustrazione 3 Fonte: Amazon

Riepilogando, ecco alcuni termini e per i sistemi storage in circolazione:- tradizionale: un host con un OS (o un firmware ), un filesystem e software dicomplemento che rende disponibile ad host e client uno spazio di archiviazione.Normalmente utilizza dischi magnetici con interfaccia SAS o SATA aggregati tra loro viamoduli software o estensioni del filesystem.- All Flash Array: i dischi sono tutti in tecnologia flash memory con interfacce di accessoUlltra Dimm, NVMe, PCIe, SSD SAS o SATA di tipo SLC. MLC, eMLC, TCL, 3D TCL.- Hybrid Array: i dischi sono un mix di SSD e magnetici con tecnologie di gestione dellivello in base a diversi criteri come performance, hot/cold, long term, ecc.,ecc.- Virtual SAN: un sistema di storage virtualizzato, in grado di accedere ai dischi locali edesporre all' hypervisor un datastore. Può avere caratteristiche scale-out.- Scale-up: possibilità di scalare verticalmente la capacità dello spazio di archiviazione, adesempio aggiungendo cassetti di dischi.- Scale-out: possibilità generica di scalare orizzontalmente la capacità dello spazio diarchiviazione, ad esempio aggiungendo un nodo in rete.- Hyper-scale: possibilità di scalare orizzontalmente di diversi ordini di grandezza unostorage, ad esempio 10.000 nodi - Hyper-converged: un sistema di storage Virtual SAN specializzato nel massimizzare leprestazioni cercando di mantenere assieme nell' host di esecuzione i dati nei vmdk di ognisingola VM.- Web-scale: un sistema progettato per avere caratteristiche hyper-scale e hyper-converged, ma con proprietà di sicurezza del dato nell'ordine di PetaByte e checonsentano una gestione del guasto di un disco o di un nodo autonoma- Big Data: sistemi per la gestione di estese quantità di dati da analizzare con tecniche emetodologie specifiche. Non adatti a gestire ambienti di virtualizzazione.- Cloud: un sistema storage esterno all'azienda con tutte le tecnologie più avanzate pergestire moli di dati immense, con ridondanza geografica a livello mondiale. Si accede inmolti modi diversi, ma di preferenza tramite un canale sicuro su rete pubblica Internet.- Software Defined Storage: un sistema che declina i concetti esposti per il softwaredefined Network. Si può ipotizzare come un framework centralizzato per la gestione“contro l plane” per storage eterogenei delegati a meri “data plane” dei dati (EMC ViPER).- Data Aware: un sistema caratterizzato da moduli integrati di software di analisi e auditdei dati.

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Il lato oscuro dello storage: silent data corruption.L'informatica richiede un processo continuo di apprendimento, ma a volte l'esperienzatende a cristallizzarsi su alcune opinioni soggettive resistenti al cambiamento. A talproposito cito il paradosso del compleanno. Soggettivamente si tende a ritenereimprobabile che in un piccolo gruppo di persone ce ne siano due che compiono gli anni lostesso giorno, ma la matematica ci dice che la probabilità che vi sia una coppia nata lostesso giorno sia del 51% (!) con appena 23 elementi:

Allo stesso modo è comune ritenere che i dischi FC o SAS “enterprise” siano

affidabili in termini di guasti, più affidabili dei dischi SATA, che l'eccessivo calore sia unproblema rilevante, che un array RAID 5 sia sicuro, ecc., ecc.

La prima preoccupazione, quando si deve scegliere un sistema di storage, è che idati siano protetti integri, a maggior ragione oggi che si gestiscono TByte di volumi, perchéun restore da un backup è una procedura razionale e teoricamente tollerata, ma che nellapratica può richiedere tempi estremamente lunghi e con esiti incerti3. I dischi magnetici(compresi gli SSD!) oltre al guasto totale possono essere soggetti ad una molteplicetipologia di errori:

• errore latente di settore (LSE): occorre quando, durante una lettura, undato letto viene esplicitamente e definitamente identificato come illeggibile (i50 byte di ECC aggiuntivi per settore da 512 byte coprono solo alcuni errori!)

• corruzione: il dato è fisicamente leggibile, ma diverso da quellointenzionalmente scritto (usura, deterioramento, raggi cosmici)

• scritture parziali: durante la scrittura il disco subisce un inattesospegnimento

• scritture fantasma: firmware o driver segnalano un avvenuta scrittura chenella realtà non viene effettuata

• scritture traslate: avviene in caso di scrittura erronea su un settore diversoda quello scelto con conseguente mancata scrittura sul settore target ecorruzione del dato sull'altro

3 http://blog.ontrackdatarecovery.it/recupero-di-230-milioni-di-file-persi-da-commvault/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Illustrazione 4: Fonte: https://it.wikipedia.org/wiki/Paradosso_del_compleanno

Alcuni di questi errori possono essere corretti a diversi livelli (ad es. filesystem) altrimentisi ottiene la segnalazione di un errore o, nel peggiore dei casi, un dato corrotto/alterato.Per molti anni le uniche informazioni sulla qualità, l'affidabilità e la vita utile dei dischimagnetici e degli storage tradizionali sono state quelle rese pubbliche dai produttori stessi.Tra i parametri utilizzati più spesso, ormai entrati nel linguaggio comune, ci sono i valori dimttf, mtbf, distribuzione a “vasca da bagno” della mortalità degli hard disk, nonché lasuddivisione in classi di affidabilità/qualità tra enterprise (dischi FC e SAS) e consumer(SATA).A partire dal 2007 vengono resi pubblicidocumenti tecnici di analisi di sistemistorage che mettono in discussione alcuneasserzioni popolari ed evidenziano temimeno noti, ma di grande importanza. Neglianni successivi si susseguono studiscientif ici di approfondimento che,indirettamente, aiutano anche a capiremeglio la forbice tecnologica tra i sistemistorage enterprise e quelli cloud4. Tral'enorme mole di informazioni alcunielementi di maggior criticità accreditati aisistemi storage sono i seguenti:

• l' MTBF, parametro calcolato dai vendor per indicare un livello di affidabilità deidischi magnetici, è largamente sovrastimato e ormai considerato inattendibile

• alcuni parametri ottenuti dai sistemi embedded S.M.A.R.T. sono utili per prevenirealcuni problemi, ma hanno un alto livello di inefficienza (36%) nell' identificare ifault (scan errors, reallocation count, offline reallocation, probational count)

• l'incidenza dei guasti dei dischi FC/SAS enterprise è quasi equivalente a quelladei dischi SATA consumer

• l'andamento dei guasti dei dischi non segue il grafico a “vasca da bagno”, ilcalore ambientale influisce minimamente come causa dei guasti mentre l'usura (manon intesa come workload) e l'età sono fattori rilevanti

• il guasto di un disco (ma anche di un settore di una traccia) può implicare un rischiopiù alto di un altro guasto, una soglia di 10 ore è da considerare critica

• l 'Unrecoverable Rate Error o URE (al netto degli algoritmi di ECC) di un discoFC/SAS è di un 1 bit ogni 1016 (1,25TB), quello di un disco SATA 1x1014 (12,5TB),ma quello reale può essere sensibilmente più basso (1x107, Cern 2007) a causa deilivelli di stratificazione: Os, memoria ram, filesystem, driver, controller, cavi, rete

• il fenomeno del latent sector error è alimentato da diversi fattori, la dimensione(crescente) in TB dei dischi (con fattore URE rimasto stabile da anni ), l'età, il livellodi qualità produttiva dei produttori e il verificarsi stesso di un errore.

• sistemi di verifica degli errori mal progettati possono propagare ulteriormente lacorruzione dei dati invece di correggerla5

4 http://storagemojo.com/2007/02/19/googles-disk-failure-experience/, http://storagemojo.com/2007/02/20/everything-you-know-about-disks-is-wrong/ , http://storagemojo.com/2007/09/19/cerns-data-corruption-research/ , http://storagemojo.com/2008/02/26/netapps-research-offensive/ , http://storagemojo.com/2008/02/18/latent-sector-errors-in-disk-drives/ , http://storagemojo.com/2010/03/05/storagemojos-best-paper-of-fast-10/ .

5 https://www.usenix.org/legacy/events/fast08/tech/krioukov.html

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Illustrazione 5: Fonte: Wikipedia

• il malfunzionamento di un sistema storage non è da imputare esclusivamente aglierrori dei dischi6, ma a tutte la catena dei componenti hardware e software

• metodi di single-erasure-code come RAID57 sono considerati estremamenterischiosi e si suggerisce di utilizzare come minimo sistemi a tripla parità.

6 https://www.usenix.org/legacy/events/fast08/tech/jiang.html 7 https://en.wikipedia.org/wiki/RAID#Correlated_failures

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

RAID: da “Redundant Array of Inexpensive Disks” a “Redundant Arrayof Independent (expensive?) Disks”.

Chi si occupa di sicurezza informatica si è abituato a considerare normale utilizzare metodidi risk management per implementare un moderno sistema di protezione aziendale.L'incessante cronaca di attacchi a siti internet e la possibilità di accedere facilmente a fontidi sapere aperte e attendibili (ad es. i sistemi a codice free o open source) hannoconsolidato la consapevolezza che nessun sistema di sicurezza è inviolabile. In ambitostorage è ancora comune considerare i sistemi come infallibili poiché altamente resilienti.Probabilmente il ritardo di offerta di storage con software a codice aperto per il mercatoaziendale ha limitato la diffusione di notizie e quindi la conoscenza di casi critici, conqualche eccezione8 (notare che spesso la causa è imputata ad un errore “umano”).

Per arrivare a considerare normale9 che i dati in uno storage in RAID 5/6 abbiano unelevato rischio di corruzione o fault totale è necessario chiarire il contesto dei requistim i n i m i r i c o r d a n d o c h e i ldocumento10 del 1988 in cui vieneconiato per la prima volta il termineRAID conclude con una serie ditemi su cui investigare e tra questi:“Ho do defective sectors affectRAID?”

Facciamo l'ipotesi di uno storage inraid 5 “hardware” costituito da unarray di dischi in cui il controlleraggrega n dischi che espone alsistema operativo come un singolovolume su cui creare unfilesystem. In caso eliminazione(erasure) di un singolo disco ilcontroller entra in modalità “InterimData Recovery Mode”, ossiaricostruisce al volo il dato mancante in modo che il sistema operativo possa operare senzainterruzione di servizio. Appena l'unità guasta viene sostituita con una nuova, parte un processo di ricostruzione per tornare allo stato precedente. Ci sono tre puntualizzazioni importantissime da fare a questo punto:- un sistema RAID5 effettua la ricostruzione del dato mancante solo in Interim o inRebuild data recovery mode,- il rebuild (re-silver) di un array RAID5 comporta la lettura sequenziale di TUTTI i bit(non è un filesystem) di tutti i dischi rimanenti e, in caso di errore di lettura anche di unsolo bit, si interrompe con segnalazione di errore,- in nessun caso lo standard RAID5 effettua il checksum dei dati...

8 http://www.availabilitydigest.com/public_articles/0510/virginia.pdf , https://www.computable.nl/artikel/achtergrond/infrastructuur/4389649/2379248/raadsels-rond-computerstoring-groningen.html

9 http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/ 10 http://www.cs.cmu.edu/~garth/RAIDpaper/Patterson88.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Il motivo per cui i sistemi RAID5/6 non effettuano verifiche di integrità (alcuni si basano suquery S.M.A.R.T per verificare lo stato dei dischi!) ad ogni lettura è opinabile in termini diintegrità dei dati enterprise (ma ben argomentato in questo post11 e parzialmenteconfermato da questo paper12 ) mentre il fatto che il rebuild si interrompa in caso di errore,per quanto impressionante, deriva dal fatto che un array RAID (hardware o software senon integrato nel filesystem) è ad un livello inferiore e disgiunto dal filesystem dell' Os equindi non ha nessun mapping/conoscenza di come siano strutturati i dati.E' interessante osservare che il vero scopo di sistemi RAID6/Double Parity non sia quellodi ricostruire un array in caso di rottura contemporanea di due dischi (evento che in sériconduce alle stesse criticità di un Raid5), ma di tollerare la ricostruzione di un disco ela perdita di un bit!Abbiamo stabilito che lo standard Raid5, originariamente progettato per ottenereperformance con un “accettabile” livello di affidabilità, non effettua mai il checksum deidati in lettura e scrittura, delegando tale attività ai controlli ECC integrati nell'elettronica deidischi o del controller. Oggi sul mercato sono già disponibili dischi magnetici SATAconsumer da 8TB13 (al costo di 200€) con frequenze dichiarate dai produttori diunrecoverable error rate di un bit ogni 1014: Lo scenario che andremo a descriveresarà quello di un RAID5 con array didischi ad altissima capacità e URE dicategoria consumer 1x1014 .Prima di proseguire è necessarioricordare che l'indicazione di un URE con frequenza di 1x1014 non significa che si abbia lacertezza che l'evento accada e vale l'occasione per ricordare alcuni elementi del calcolodelle probabilità.La distribuzione binomiale di probabilità è una distribuzione discreta che descrive ilnumero di successi in un processo di Bernoulli.Un tipico processo di Bernoulli è il lancio di una moneta dove il risultato può essere testa ocroce oppure la lettura di un bit da un hard disk che può avere valore 0 o 114, con lacaratteristica che:- p è la probabilità che un evento abbia successo- q è la probabilità che un evento non abbia successo- p = 1 -q

La distribuzione binomiale consente di valutare le probabilità che una modalità di unevento con probabilità individuabile a priori (p) si verifichi un determinato numero di volte(k) entro un numero totale (n) di eventi.

Ad esempio se lancio tre volte15 un dado il numero massimo di combinazioni semplici conripetizioni16 è 56 (n=6, k=3):

11 http://serverfault.com/questions/100301/how-does-raid-detect-a-faulty-hd 12 http://pages.cs.wisc.edu/~bpkroth/cs736/md-checksums/md-checksums-paper.pdf 13 http://www.seagate.com/files/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-

dS1834-3-1411us.pdf 14 https://mycourses.aalto.fi/pluginfile.php/42813/course/section/45281/Solution7.pdf 15 http://www.irccsdebellis.it/html/dipuninf/statistica/cap6.pdf 16 https://it.wikipedia.org/wiki/Coefficiente_binomiale

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Ad ogni lancio la probabilità che esca un certo valore (ad esempio 6) è 1/6, ma qual è laprobabilità che esca 6 almeno una volta dopo tre lanci?

La formula generale B(n,p) ci dice che la somma di tutte le probabilità è uguale a 1:Tra tutte le otto (23) possibili combinazioni dei tre lanci (n=3) vogliamo calcolare quelladove la probabilità che un evento p pari a 1/6 non si verifichi mai ossia k=0, la formulaP(n,k,p) diventa il caso specifico P(3,0,p)

sapendo che il coefficiente si esprime come (nk)= n!k!(n−k )!

p=1/6q= 1-pn (numero di lanci) = 3k (casi di successo) = 0

[ 3!0!⋅(3−0)! ]⋅( 16 )

0

⋅(1−16 )(3−0)

=1⋅1⋅(1− 16 )(3−0)

=(1− 16 )3

=0,579

ossia che nel 57.9% dei casi su tre lanci l'evento p non uscirà mai. A questo puntosapendo che p=1-q possiamo dedurre che tutti i casi rimanenti in cui l'evento p escaalmeno una volta ha una probabilità del 1-0,579= 42,1%.

Dalla letteratura17 sappiamo che durante il rebuild di un array da 100GB in raid5 di dischicon ure 1x10^14 l'eventualità di incorrere in un errore di lettura di bit è assimilabile ad unprocesso di Bernoulli (0,1) possiamo utilizzare la distribuzione binomiale per calcolare laprobabilità di leggere con successo tutti i dati:

p (probabilità di leggere 1 bit errato) = 1/10^14q (probabilità di non leggere 1 bit errato) = 1-p = 1-1/10^14n (numero di letture di bit indipendenti) = 100GB = 8*10^11 bitk (casi di successo) = 0

(8∗1011

0 )[ p0][q(8∗1011−0 )]=1∗1∗[1− 11014 ]

8∗1011

=0,992

che significa che la probabilità di incorrere in almeno un unrecoverable error è dello 0,8%. Il numero di errori attesi si ricava dalla formula

ossia (8*10^11)*(1/(10^14))= 0,008.

17 https://web.eecs.umich.edu/~pmchen/papers/chen94_1.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Vediamo ora uno scenario di 6 dischi da 6TB SATA consumer in RAID5 nell'ipotesi direbuild causato dalla rottura di un disco, il processo di lettura dovrà ricostruire i dati viaXOR dai 5 dischi rimanenti:

p (probabilità di leggere 1 bit errato) = 1/10^14q (probabilità di non leggere 1 bit errato) = 1-p = 1-1/10^14n (numero di letture di bit indipendenti) = 5*6TB=30TB = 2,4*10^14 bitk (casi di successo) = 0

C( 2,4*10^14;0)*p^0*q^ 2,4*10^14 = 1*1*(1-1/(10^14))^(2,4*10^14) = 0,090

che significa che la probabilità di incorrere in almeno un unrecoverable error è dello91%!. Il numero di errori attesi si ricava dalla formula: (2,4*10^14)*(1/(10^14)= 2,4 .

Il grafico successivo indica la probabilità di un errore in array di dischi SATA con ure1x1014:

Sono dati che fanno riflettere e che fanno capire come mai ad un certo punto la i diInexpensive sia diventata Indipendent, infatti ora sappiamo che l'unica vera differenza traun disco consumer ed uno enterprise è l' URE, ad esempio con un disco da 10TB“consumer enterprise” HGST HelioSeal18 con URE 1x1015 la probabilità che l' array inrebuild ottenga l'errore scende:1-((1-(1/10^15))^(2,4*10^14))19 = 0,21 , ma il 21% di probabilità di ottenere un blocco nellaricostruzione del raid è ancora un valore inaccettabile. Una possibile soluzione potrebbe essere quella di usare unità con URE 1x1016 :1-((1-1/(10^16))^(2,4*10^14)) = 0,02, ma un tale livello di qualità è presente solo nei dischimagnetici SAS20 (o SSD enterprise) che però vengono venduti a 3.000€ l'uno e concapacità massima di 900GB.

18 https://www.hgst.com/products/hard-drives/ultrastar-archive-ha10 19 La formula equivalente 1-(((10^15-1)/10^15)^(2,4*10^14)) 20 http://www.enterprisestorageforum.com/storage-technology/sas-vs.-sata-1.html

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

I valori di soglia critici in relazione ai parametri ure sono i seguenti:URE 1x1014 12,5 TB.URE 1x1015 125 TB.URE 1x1016 1,25 PB.

La possibilità di un bit URE durante il re-silver di un array RAID5 non è l'unico problema,esiste infatti un elevata correlazione di un secondo fault successivo alla rottura di un discoe quindi è estremamente importante non solo che l'unità difettosa sia sostituitaimmediatamente tramite dischi di spare, ma che il processo di ricostruzione sia minore di10 ore21: “For example, the probability of seeing two drives in the cluster fail within one hour isfour times larger under the real data, compared to the exponential distribution. Theprobability of seeing two drives in the cluster fail within the same 10 hours is twotimes larger under the real data, compared to the exponential distribution. “

Ipotizzando di leggere un intero disco da 10TB ad una velocità ottimistica di 100MB/s(durante un rebuild RAID5 è operativo e quindi esegue le attività di lettura ad una velocitàdel 60-80% del massimo possibile) abbiamo 10TB/100MB/s= 27 ore.

Non è un caso quindi che i produttori di sistemi storage enterprise offranoprevalentemente dischi SAS con URE 1x1016 e di capacità ridotta, molto al di sotto dellamassima capacità disponibile sul mercato, con conseguente esplosione dei costi diacquisto, supporto e manutenzione. Ed è probabilmente per gli stessi motivi che la I diRAID si è trasformata da Inexpensive in Indipendent... Per completare il quadro d'insieme ricordiamo che la letteratura scientifica, sulla base dimisurazioni empiriche, ha ridiscusso la definizione di parametri o concetti noti(MTBF,MTTL,latent sector error, silend data corruption, ecc., ecc), ma anche formule ealgoritmi di analisi e previsione dei guasti22 .

21 https://www.usenix.org/legacy/events/fast07/tech/schroeder/schroeder_html/index.html 22 http://www.cs.cmu.edu/~bianca/fast08.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Illustrazione 6: Distribution of time between disk replacements across all nodes in HPC1 for only year 3 of operation.

Nel 2006 Netapp pubblica un articolo “NETAPP RAID-DP™: DUAL-PARITY RAID 6PROTECTION WITHOUT COMPROMISE “ che annuncia che con il proprio RAID-DoubleParity il rischio di perdita di dati in caso di rebuild di un array è 3800 volte piùbasso di un RAID5 (la versione del 2006 WP-7005-1006 è reperibile in altri siti). Nel 2009 Adam Leventhal23, sulla base dei trend di crescita della capacità dello storage,prevede che nel 2019 anche RAID6 non potrà più essere affidabile e suggerisce di iniziarea considerare la strada del RAID Triple Parity. Nel 2013 Netapp, con rara e ammirabileonestà intellettuale, pubblica un documento24 che prende atto dei progressi tecnologici edelle analisi scientifiche e propone una nuova formulazione del calcolo dell'affidabilità deglistorage RAID6 che ricalcola il minor rischio dai 3800x del 2006 ad un valore attorno a300x25 nei confronti di RAID5 (ma anche RAID1+0) e mettendo a disposizione uncalcolatore26. Compariamo quest'ultimo documento27 Netapp con uno Dell28 del 2002 chesostiene che “Mirroring (RAID10 ndr) provides the most reliable RAID system” (tesitutt'ora sostenuta da alcuni produttori):

Poiché sappiamo che la complessità degli argomenti trattati coinvolge anche la scelta deimetodi matematici di analisi è evidente la necessità che i modelli/algoritmi utilizzati dachiunque per calcolare l'affidabilità dei sistemi storage siano resi pubblici o,auspicabilmente, ricollocati nell'ambito del sempre attuale metodo scientifico in modo dafacilitare la discussione e la verifica dalla più amplia platea possibile di soggetti. In casocontrario ogni affermazione è riconducibile a semplice opinione se non ad un meromessaggio pubblicitario.

23 http://queue.acm.org/detail.cfm?id=1670144 24 https://www.usenix.org/system/files/fastpw13-final25.pdf 25 http://www.netapp.com/us/media/wp-7005.pdf 26 http://raideqn.netapp.com/ 27 http://www.netapp.com/us/media/wp-7005.pdf 28 http://www.dell.com/content/topics/global.aspx/power/en/ps1q02_long?c=us&l=en&cs=04

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Rimedi e filesystem avanzati.Dato per assodato che RAID5da molto tempo non è piùconsiderato un l ivello diprotezione affidabile e che iNAS con dischi consumersono fortemente a rischio difailure citiamo ora alcunimetodi utilizzati per mitigaregli effetti dei latent sectorerror, degli unrecoverablee r ro r e de l s i l en t da tacorruption. Per arginare la temuta “SilentData Corruption” i produttori distorage hanno proposto unaserie di miglioramenti, inparticolare per i controlli ECCnativi nei dischi da anni silavora per il nuovo formato a settore da 4k29 . Nel 200330 il comitato T10 propone unmodello “end to end” lineare tramite l'implementazione di un meccanismo di data integrityinserendo un'estensione di 8 byte (DIF) nel flusso dei dati successivamente denominatacome T10 Protection Information31. Il T10 PI si propone come un'estensione del protocolloiSCSI lasciando scoperta la pila di strati fino a livello applicativo, ma nel 200832 Oracle

propone un'estensione alkernel di Linux e alproprio DBMS Oracle.Quando su l mercatoescono i primi apparatihardware che supportanoil T10 PI si completal'architettura “end to end”,nell'esempio di OracleDatabase si nota l'effettodella somma T10 + DIX33.

29 https://en.wikipedia.org/wiki/Advanced_Format 30 End-to-End Data Protection Justification

http://www.t10.org/ftp/t10/document.03/03-224r0.pdf 31 Snia

http://www.snia.org/sites/default/files/Data_Integrity_Architectural_Model_v1.0.pdf 32 Linux Data Integrity Extensions Martin K. Petersen

https://oss.oracle.com/~mkp/docs/ols2008-petersen.pdf , https://oss.oracle.com/projects/data-integrity/dist/documentation/dix.pdf

33 Oracle DIXhttps://oss.oracle.com/~mkp/docs/data-integrity-webcast.pdf , https://oss.oracle.com/projects/data-integrity/dist/documentation/ppdc.pdf , http://www.oracle.com/us/technologies/linux/data-integrity-solution-1852762.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

In termini di silent data corruption rate i risultati sembrano estremamente incoraggianti:

ma rimane la criticità per la parte T10 PI poiché l'implementazione è vincolata allacompatibilità dell'hardware (ad oggi solo Oracle DBMS e Lustre utilizzano l'estensioneDIX)

Nell'ambito degli storage tradizionali uno dei metodi più noti per mitigare l' SDC è quellodello scrubbing, ma non è l'unico come descrive questo articolo34 (finanziato da Netapp)del 2008 che fa il punto della situazione:

Table 1: Protections in Real Systems. This table shows the known protections used in real-world systems. Some systems have other protections: Pilot uses a scavenger routine torecover metadata, and Powervault uses a 1-bit ``write stamp'' and a timestamp value to detect data-parity mismatches. Systems may use further protections (details not madepublic).

System RAID ScrubbingSector

checksumsBlock

checksumsParent

checksumsWriteVerify

PhysicalIdentity

LogicalIdentity

VersionMirroring

Other

Hardware RAID card

x

(say, Adaptec 2200 S)

Linux softwareRAID

x x

Pilot X x

Tandem NonStop

X X x

Dell Powervault

X X x x

Hitachi Thunder 9500

x x x

NetApp Data ONTAP

x x x X X x

ZFS with RAID-4

X X X

è interessante osservare (tabella 3) che per raggiungere una probabilità dello 0% diperdita o corruzione del dato è necessario applicare i metodi di raid+scrub+blockchecksum+ physical e Logical ID+version mirroring. Questo passaggio porta a ritenereesaurito il ciclo di storage basati su controller hardware a favore di implementazioni dimetodi di protezione dei dati fortemente integrati con il filesystem espresso in modoefficace in un'intervista del 200735: “one of the design principles we set for ZFS was:

34 Parity Lost and Parity Regainedhttp://usenix.org/legacy/event/fast08/tech/full_papers/krioukov/krioukov_html/main.html

35 A Conversation with Jeff Bonwick and Bill Moorehttp://queue.acm.org/detail.cfm?id=1317400

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

“never, ever trust the underlying hardware”. Nel 2005 l'introduzione nel mercato diZFS36 in licenza CDDL rappresenta un elemento di novità in un settore dominato daNetapp con il proprio filesystem proprietario WAFL . Essendo un filesystem progettatoprincipalmente per garantire l'integrità dei dati (Bill Moore: “We had several design goals,which we’ll break down by category. The first one that we focused on quite heavily is dataintegrity.") l'implementazione dei livelli di RAID-Z è leggermente diversa da quellastandard. Ad esempio l'equivalente di RAID5 ha in ZFS il livello RAID-Z1 che però utilizzaun metodo simile a RAID3 per lo striping a livello di byte dei dati e non di blocco. Per questo motivo il livello RAID-Z37 ha dei limiti38 architetturaliche potenzialmente possono penalizzarlo nell'effettuareread/write random in termini di IOPs. Al contempo ZFS hadelle peculiarità infrastrutturali (L1ARC, L2ARZ, write-aheadlog via Zil) che gli consentono di scalare le performanceutilizzando storage pool ibrido di dischi SSD, HDD (oqualunque altro supporto39), ma soprattutto DRAM40 (l'opzionedi optare per un livello RAID 1041 pone dei dubbisull'affidabilità dei quali abbiamo già argomentato inprecedenza). ZFS rappresenta un notevole passo avantitecnologico che tende ad una piena implementazione delmodello di “end to end”42 data integrity con prospettive di

ulteriorimiglioramenti43

. La licenzaCDDL hafavorito l'aggregazione di una community attiva di sviluppatori anche dopo l'acquisto di Sun da parte di Oracle e, di conseguenza, il proliferare di sistemi storage. A differenza di un sistema RAID hardware su controller, ZFS durante il resilver di un disco ricostruisce solo i dati memorizzati e non tutto il disco indiscriminatamente, inoltre è in grado di recuperare/ricostruire un dato in caso di

36 THE LAST WORD IN FILE SYSTEMShttp://www.cs.utexas.edu/users/dahlin/Classes/GradOS/papers/zfs_lc_preso.pdf

37 RAID-Zhttps://blogs.oracle.com/bonwick/entry/raid_z

38 WHEN TO (AND NOT TO) USE RAID-Zhttps://blogs.oracle.com/roch/entry/when_to_and_not_to

39 ZIL Acceleratorhttp://www.ddrdrive.com/zil_accelerator.pdf

40 Storage I/O from DRAM is 1000x Faster Than Flash”. Well, sort of…https://blogs.oracle.com/ZFS-Storage-for-Cloud/entry/storage_i_o_from_dram

41 ZFS RAIDZ stripe width, or: How I Learned to Stop Worrying and Love RAIDZhttp://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/

42 End to end ZFShttp://storageconference.us/2013/Presentations/ZhangYupu.pdf , http://research.cs.wisc.edu/wind/Publications/flex-e2e-msst13.pdf

43 ZFS and RAID-Z recoverability and performancehttp://www.quetek.com/zfsandraidz.htm

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

URE. Rimane irrisolto il problema dei tempi di rebuild per dischi ad altissima capacità e, in generale, il caso di un filesystem avanzato, ma in un ambito che concepisce il guasto come un evento eccezionale da scongiurare e rimediare in tempi estremamente rapidi, ridondando tutti i componenti con hardware di qualità e lasciando margini anche per un errore umano.

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Erasure coded storage e serendipity.Nel tentativo di rendere più chiaro il quadro generale della rivoluzione tecnologica in attosarà necessario indicare, a puro scopo informativo, dei riferimenti teorici di informatica ematematica. Ricordiamo che il termine forwarding error correction (FEC) indica un metodo per larilevazione e la correzione degli errori in una trasmissione dati. Tra i vari codici che possoessere utilizzati ne esiste uno noto come erasure code44 (EC) che ha la caratteristica diessere definito come la trasformazione (encoding) tramite un codec di un messaggio di ksimboli in n simboli dove n>k e che consenta di ricostruire (decoding) il messaggio da unsottoinsieme di n. E' possibile anche affermare che il risultato finale n sia la somma di k +m dove m è un oggetto detto partita:

Un metodo di EC che consenta di tollerare la perdita di qualunque blocco dell'insieme dik+m fino ad un massimo di failure ≤ m può essere definito un EC di tipo maximumdistance separable45 (MDS), tra questi uno dei più utilizzati è noto come Reed-Solomon46:

44 Erasure Codehttps://en.wikipedia.org/wiki/Erasure_code J.S.Plankhttp://web.eecs.utk.edu/~plank/plank/papers/FAST-2005.pdf http://web.eecs.utk.edu/~plank/plank/papers/2013-02-11-FAST-Tutorial.pdf

45 http://smahesh.com/blog/2012/07/01/dummies-guide-to-erasure-coding/ 46 Red-Solom coding

https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction , https://www.usenix.org/legacy/event/fast09/tech/full_papers/plank/plank_html/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Illustrazione 7: A typical storage system with erasure coding

Illustrazione 8: Reed-Solomon coding for k=4 and m=2.

Illustrazione 9: Erasure Code generico di tipo MDS

In questi termini è possibile riclassificare i sistemi come “erasure coded storage”47,includendo anche metodi come la replica,definendo come prima generazione quellatradizionale basata su array di dischi locali. Nel caso di RAID4/5 il codec utilizzato è lafunzione XOR applicata a k blocchi chepermette di ottenere 1 blocco di parità (m).Ragionando in termini di dischi, un array di n= 5 è costituito di 4 dischi di dati e uno dipartita (m) che consentono di ripristinare l'array in caso di cancellazione/guasto(erasure) al massimo di un (qualunque) disco.La scelta di XOR è determinate per avere unmeccanismo di coding a basso utilizzo diCPU.Considerando che n=m+k, m indica sia ilnumero di blocchi di parità che il numero difault tollerati, il ratio r (storage efficiency) chesi ottiene tra k e (m+k) ci aiutano a capire cheEC con m=1 possono avere r molto diversicome ad esempio tra RAID1 e RAID5.Poiché il livello RAID6 con m=2 non puòutilizzare XOR48 per il calcolo della paritàorizzontale pena l'impossibilità di ricostruire idati mancanti, deve ricorrere ad altri49 sistemi dicoding più complessi come le funzioni di Reed-Solomon50. In passato questo tipo di coding haavuto una d i f fus ione limitata a causadall'eccessivo carico computazionale richiesto. Per ovviare al problema e continuare adutilizzare le funzioni XOR esistono due metodi di erasure coding non MDS, EVENODD51 eRDP52, , ma entrambi sono brevettati.La spiegazione del funzionamento di RAID-DP di Netapp ci ricorda che un metodo EC peressere ottimale deve essere efficiente sia in encoding (minor uso possibile di cicli di cpu)che in decoding53 (la ricostruzione deve impiegare meno tempo possibile), sprecare pocospazio ed essere performante. Inoltre non va dimenticato che l'applicazione di EC, perquanto nuovi, non risolvono in sé il tema della data integrity54

47 Next Generation Erasure Coding Techniqueshttp://www.snia.org/sites/default/files/Wesley_Leggette-Next_Gen-Erasurev4_EDIT.pdf

48 RAID6 and Solomon codeshttp://www.raid-recovery-guide.com/raid5-parity.aspx

49 The RAID-6 Liberation Codeshttp://usenix.org/legacy/event/fast08/tech/full_papers/plank/plank_html/index.html

50 La matematica di RAID6https://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf

51 EMC http://www.emc.com/collateral/hardware/white-papers/h2891-clariion-raid-6.pdf

52 Netapphttp://community.netapp.com/t5/Tech-OnTap-Articles/Back-to-Basics-RAID-DP/ta-p/86123

53 MDR Codes: A New Class of RAID-6 Codes with Optimal Rebuilding and Encodinghttp://arxiv.org/pdf/1310.2381.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Quando per il mercato aziendale enterprise appaiono i primi prodotti di erasure codedstorage (II generazione) distribuiti in rete vieneconiato il termine RAIN55. La complessità di questisistemi è duplice, da un lato necessitano di metodidi EC che vadano oltre RAID per adattarsial l ' infrastruttura di rete, dall 'altro devonoconfrontarsi con i limiti imposti dalla congettura diBrewer nota come C.A.P56. Quest'ultima nella suaformulazione iniziale si riferisce ad un genericosistema di dati distribuiti in rete e negli anni vieneripresa e modellata in molti ambiti, in particolare peri database NoSQL, innescando una discussione57

che porterà l'autore ad una riformulazione piùarticolata58. In merito all'estensione della congettura CAP (o PACELC) ai sistemi distorage distribuiti è da notare come, al di là delle diatribe, i progettisti abbiano tenuto contoin fase di progettazione delle possibili criticità teoriche. I primi sistemi RAIN denotano una

limitata scalabilità e poiché per garantire bassalatenza, performance, economicità, consistenza, altaaffidabilità e tolleranza alle interruzioni di rete devonoimplementare dei metodi altamente complessi59 sidovranno evolvere ulteriormente verso storage di IIIgenerazione.L'idea di distribuire i dati in rete impone un cambio diarchitettura che richiede l'utilizzo di una terminologianuova. I sistemi di I generazione si suddividevano inSAN e NAS. Nel primo caso gli array di dischi localivenivano suddivisi in volumi accessibile via rete

tramite un protocollo di tipo block-level, come ad esempio iSCSI, ai client. A quest'ultimiveniva delegato il compito di creare e gestire il filesystem ed eventualmente l'accessoesclusivo della risorsa. Nel caso del NAS la gestione del filesystem è in carico allostorage che espone in rete i volumi con un protocollo di tipo file access concorrente, adesempio NFS.

54 Erasing Misconceptions Around RAID & Erasure Codeshttp://community.netapp.com/t5/Technology/Erasing-Misconceptions-Around-RAID-amp-Erasure-Codes/ba-p/83689

55 RAINhttps://storagemojo.com/2009/11/08/redundant-array-of-inexpensive-servers/ http://wikibon.org/wiki/v/Erasure_Coding_and_Cloud_Storage_Eternity ,

56 Teorema CAPhttps://en.wikipedia.org/wiki/CAP_theorem , http://www.mokabyte.it/2013/07/BrewerCAP-1/#ref

57 http://blog.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/ 58 CAP Twelve Years Later:How the “Rules” Have Changed

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed , http://dbmsmusings.blogspot.it/2010/04/problems-with-cap-and-yahoos-little.html , http://markburgess.org/blog_cap.html , http://www.diag.uniroma1.it/~querzoni/corsi_assets/1213/GreatIdeasInComputerScienceAndEngineering/GIiCSaE-cap_01.pdf

59 Leonardo Querzoni http://www.diag.uniroma1.it/~querzoni/corsi_assets/1213/GreatIdeasInComputerScienceAndEngineering/GIiCSaE-cap_02.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

In aggiunta al tipo di erasure code utilizzato i distributed storage in rete si possonoriclassificare in moltissimi altri modi, in base al tipo di hardware utilizzato, ai protocollousati o al tipo di filesystem utilizzato:- shared-disk file system60 che analogamente alle SAN utilizza protocollo simili a iSCSI ditipo block-level, ma l'accesso ai volumi è possibile in modo concorrente a più clients,- distributed filesystem61 (DFS) che analogamente ai NAS utilizza protocolli come NFS perl'accesso file-level- distributed data store62 che differisce da un DFS per il fatto che l'accesso ai dati avvienetramite API e metodi (come ad esempio i database)

Tipo di filesystem Distributed Filesystem Shared-disk file system Distributed Data StoreBeeGFS (Fraunhofer)Ceph (Inktank, Red Hat, SUSE)GFS (Google Inc.)GlusterFS (Red Hat)HDFS (Apache Software Foundation)OneFS (EMC Isilon)OrangeFS (Clemson University, OmnibondSystems), formerly Parallel Virtual FileSystemMooseFS (Core Technology / Gemius)ObjectiveFSPanfs (Panasas)Parallel Virtual File System (ClemsonUniversity, Argonne National Laboratory,Ohio Supercomputer Center)Windows Distributed File System (DFS)(Microsoft)XtreemFS

Silicon Graphics (SGI) clustered filesystem (CXFS)Veritas Cluster File SystemDataPlow Nasan File SystemIBM General Parallel File System (GPFS)LustreMicrosoft Cluster Shared Volumes (CSV)Oracle Cluster File System (OCFS)PolyServe storage solutionsQuantum StorNext File System (SNFS), exADIC, ex CentraVision File System (CVFS)Blue Whale Clustered file system (BWFS)Red Hat Global File System (GFS)Sun QFSTerraScale Technologies TerraFSVersity VSMVMware VMFSXsan

AerospikeApache Cassandra, former data store ofFacebookBigTable, the data store of GoogleCrateIODruid (open-source data store), used byNetflix, Yahoo and othersDynamo of AmazonHBase, current data store of Facebook'sMessaging PlatformCouchbase, data store used by LinkedIn,Paypal, Ebay and others.MongoDBRiakHypertable, from BaiduVoldemort, data store used by LinkedIn

La genesi del primo clustered/cloud filesystem Google File System, i problemi e le sfideche i fondatori di Google hanno affrontato e risolto sono ben sintetizzati in questoarticolo63. Uno degli aspetti più notevoli è che il team di sviluppo abbia optato per unerasure code MDS semplice a tripla64 copia del dato (Replication Factor 3) su nodi inrete, utilizzando hardware commodity, stravolgendo tutte le certezze e le migliori praticheproposte dai vendor “big iron” (Yahoo!65 fino al 2010). La scelta sembra avere una giustificazione scientifico matematica solida, supponiamoinfatti di avere un meccanismo di semplice replica con fattore 1 (simile a raid1) tale per cuiparlando in termini di erasure code si ottiene RF(2,1) n=2, k=1, m=1 che traduciamo comeun meccanismo applicato ad un file M del tipo:M------split--- X1------coding----A1,A2A1=X1A2=X1ossia A1 e A2 sono ciascuno la semplice copia esatta dell'unico frammento X1 e quindir=1/2 con una storage efficiency del 50%.

60 https://en.wikipedia.org/wiki/Clustered_file_system#Shared-disk_file_system 61 https://en.wikipedia.org/wiki/Clustered_file_system#Distributed_file_systems 62 https://en.wikipedia.org/wiki/Distributed_data_store 63 Google File System Eval: Part I

http://storagemojo.com/google-file-system-eval-part-i/ 64 The Google File System: “By default, we store three replicas, though users can designate different replication levels

for different regions of the file namespace.”http://research.google.com/archive/gfs-sosp2003.pdf

65 http://storagemojo.com/killing-with-kindness-death-by-big-iron/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Nell'ipotesi di avere un milione di nodi di cui un 10% guasto applicando la formula di cuia pag. 366 si ottiene che la probabilità che un blocco sia disponibile è del 99%. Mantenendo r=1/2, e quindi a parità di spazio fisico totale utilizzato per la registrazione delfile M, ma utilizzando un RF(32/16) che effettui lo split iniziale di M in 16 frammenti siottiene:M------split--- X1,,X16------coding----A1,A2,..A32A1=X1A2=X1A3=X2A4=X2 ….applicando la stessa formula di ottiene una percentuale di affidabilità del 99,9999998!L'utilizzo di un metodo di erasure code basato su un semplice fattore di replicazione seapplicato su un numero elevato di nodi in rete garantisce livelli di affidabilità elevatissimi67.Più avanti riprenderemo l'analisi degli effetti collaterali relativi alla latenza e ai tempi diripristino in caso di “erasure” di un dato conseguenti l'uso di metodi di EC.

Tra le innumerevoli novità tecnologiche che Google sviluppa per la propria infrastruttura viè quella che verrà chiamata architettura web/hyper/self-healing(scale) come si evince inquesta intervista68 ad uno dei partecipanti al progetto GFS (e co-fondatore di Nutanix):”When I worked at Google I saw a different view of the world. I saw a world where thesmallest systems comprised 5,000 to 10,000 server nodes back when Google had millionsrather than gazillions like now. When you’re talking about that scale you cannotbabysit these systems. When something goes down it will probably stay down foran extended period of time and there is no hope that an admin will come along andhave time to fix it. One of the ways in which the Google File System was different interms of interruptions is that it said hey, if any component fails and stays down for anextended period of time, you can design around that so that the system can heal, almostlike if an organ of the body is going to die and you work around it, not waiting for the doctorto come and implant a second organ.”Purtroppo GFS (Colossus nella sua seconda versione) non è in vendita poiché costituisceper Google un vantaggio tecnologico nei confronti dei concorrenti e non è possibileottenere il codice sorgente poiché, secondo la licenza GPL, i servizi erogati in rete nonobbligano in alcun modo lo sviluppatore (per questo è stata formulata l'“Affero GPL”AGPL). Nel 2005 Apache foundation rilascia il codice del framework Hadoop, il cui componenteHadoop Distributed File System HDFS ( RF=3 per default) si ispira68 a GFS, e trovadiffusione69 in numerose aziende in tutto il mondo, in particolare in Facebook70 e…Microsoft71. In conseguenza dell'incremento esponenziale dei TByte occupati si avverte

66 Erasure Coding vs. Replication: A Quantitative Comparisonhttp://oceanstore.cs.berkeley.edu/publications/papers/pdf/erasure_iptps.pdf tratto da “Erasure Coding and Cloud Storage Eternity”http://wikibon.org/wiki/v/Erasure_Coding_and_Cloud_Storage_Eternity Eternity Service (1996!) http://www.cl.cam.ac.uk/~rja14/Papers/eternity.pdf

67 David Floyerhttp://wikibon.org/wiki/v/Reducing_the_Cost_of_Secure_Cloud_Archive_Storage_by_an_Order_of_Magnitude http://wikibon.org/wiki/v/Erasure_Coding_Revolutionizes_Cloud_Storage

68 Intervista ad Mohit Aron http://www.networkworld.com/article/2936660/network-storage/google-infused-storage-startup-cohesity-reveals-itself.html

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

la necessità di implementare metodi di EC con una storage efficiency migliore69 a parità diaffidabilità70 al punto che Google stessa aggiorna il proprio GFS71 e a partire dal 2010introduce EC di tipo RS(6,3). I concorrenti non rimangono al palo, Facebook introduceHDFS-RAID72 per lo storage “primario” e una nuova architettura73 in RS(28,20) per laconservazione dei dati meno utilizzati: “Instead of trying to utilize an existing solution —like massive tape libraries — to fit our use case, we challenged ourselves to revisit theentire stack top to bottom.” La migrazione da un sistema di EC di tipo RF ad uno RS permette di un significativorisparmio di spazio occupato e un incremento dell'affidabilità. Purtroppo il rovescio dellamedaglia dei RS code sono l'elevato costo intermini di tempo e bandwidth in caso diricostruzione di un dato. A tal proposito èinteressante analizzare il caso di Microsoft che,per il proprio Azure cloud storage, implementa unnuovo tipo di erasure code, detto LocallyRepairable Code (LRC), per ottenere un migliorequilibrio tra storage overhead e riduzione deitempi di ricostruzione dei dati e traffico di rete incaso di failure74.

Quando in gioco ci sono PByte di dati ogni minimo vantaggio ottenuto si trasforma in unelemento chiave per essere più competitivi sul mercato. La community Hadoopovviamente è alla ricerca di erasure code avanzati per HDFS, tra questi75 uno dei progetti

69 Rethinking Erasure Codes for Cloud File Systems: Minimizing I/O for Recovery and Degraded Readshttp://www.cs.jhu.edu/~okhan/fast12.pdf

70 Erasure Coding vs. Replication: A Quantitative Comparisonhttp://oceanstore.cs.berkeley.edu/publications/papers/pdf/erasure_iptps.pdf

71 Google GFS IIhttp://www.theregister.co.uk/2009/08/12/google_file_system_part_deux/ , http://static.googleusercontent.com/media/research.google.com/it//university/relations/facultysummit2010/storage_architecture_and_challenges.pdf

72 Facebook HDFShttps://code.facebook.com/posts/536638663113101/saving-capacity-with-hdfs-raid/

73 Facebook cold storagehttps://code.facebook.com/posts/1433093613662262/-under-the-hood-facebook-s-cold-storage-system-/

74 A Better Way to Store Data http://research.microsoft.com/en-us/news/features/erasurecoding-090512.aspx , http://research.microsoft.com/en-us/um/people/chengh/slides/erasure_coding_tutorial_part2_FAST_2013.pdf , https://www.usenix.org/sites/default/files/conference/protected-files/huang_atc12_slides_0.pdf

75 Hadoop Adaptively-Coded Distributed File System (HACFS)https://www.usenix.org/system/files/conference/fast15/fast15-paper-xia.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

LRC più avanzati è Xorbas76 . Per quanto riguarda Amazon poco si sa degli riferimentitecnici dei vari Cloud Storage S3, EBS,EFS. Purtroppo, a differenza di Google eFacebook, Amazon ha una politica molto rigida per quanto riguarda le informazioni sulsoftware sviluppato internamente ed è solita non rilasciare77 codice alla comunità se nonper obblighi di legge.

Arrivati a questo punto ritengo che sia evidente la complessità sottostante i sistemi distorage moderni e la difficoltà a trovare un metodo univoco di classificazione. Unaproposta interessante, perennemente work in progress, è quella proposta nel proprio blognon ufficiale da Chad Sakac (presidente di Emc VCE) che categorizza gli storage in baseall'architettura78:Persistence ArchitectureClassification

T y p e 1Clustered Scale Up

Type2Tighly Coupled Scale Out

Type3Looseley Coupled ScaleOut

Type4Distributed Share Nothing

Type5Raid 3d79 ?

E m c V N X ,NetApp FAS, Pure,Tintri,Nimble, Nexenta

E M C S y m m e t r i x ,ExtremeIO, IBM DS, HDSUSP

EMC I s i l o n , Sca l e I O ,GlusterFS, Vmware Vsan,Nutanix, Simplivity

EMC Vipr, Ceph, GoogleG F S , H a d o o p H D F S ,Microsoft Azure,

DSSD?

semplicità, performance,ricchezza di feature

elevate performance, bassal a t e n za , ma g g i o recapacità, limitata scalabilità

performance, capacità,scalabilità

modello non transazionale,hyper scale, affidabilità ecapacità “illimitate”

Spero che la mia soggettiva cronaca dello stato dell'arte dei sistemi di storage sia utile perorientarsi nella moltitudine di prodotti sul mercato. Al termine di un articolato percorso diapprendimento ritengo di aver accumulato un bagaglio di conoscenza minimo perapprezzare appieno quella che considero una risorsa incredibilmente poco sfruttata inambito aziendale: Hadoop e HDFS. Esistono infinite possibilità per il mercato aziendale(basti pensare a come Facebook gestisce milioni di messaggi80 via Hbase/HDFSspingendosi fino a gestire l'intero ciclo di vita di un documento) e la possibilità di utilizzare

76 HDFS Xorbas e oltrehttps://storagemojo.com/2013/06/21/facebooks-advanced-erasure-codes/ , http://blog.cloudera.com/blog/2015/09/introduction-to-hdfs-erasure-coding-in-apache-hadoop/

77 Amazon code release irrelevant, Kindle is still closedhttp://arstechnica.com/information-technology/2009/06/amazon-code-release-irrelevant-kindle-is-still-closed/

78 Chad Sakac http://virtualgeek.typepad.com/virtual_geek/2014/01/understanding-storage-architectures.html 79 DssD http://www.google.nl/patents/US8554997 80 The Underlying Technology of Messages

https://www.facebook.com/notes/facebook-engineering/the-underlying-technology-of-messages/454991608919/ http://hortonworks.com/big-data-insights/how-facebook-uses-hadoop-and-hive/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

nodi di rete con hardware commodity, compresa la possibilità di riusare server obsoleti,permetterebbe di generare economie di scala impensabili con storage tradizionali. Si proviad immaginare il vantaggio di un' unico volume in tecnologia HDFS che può spandersigradualmente , in cui riversare posta elettronica, documenti, CMS, immagini Dicom81,referti82, fatture, ecc., ecc., con valori di un'affidabilità che aumentano al crescere dei nodi.

81 http://www.syntelinc.com/sites/default/files/medical_image_store_flyer.pdf 82 http://hortonworks.com/blog/modern-healthcare-architectures-built-with-hadoop/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Parte seconda: la pre-selezione dei candidati.L'elenco di alcuni dei produttori/prodotti che attualmente competono sul mercato deglistorage enterprise è il seguente:

Distribuito inItalia

VirtualFiler/Ca

che

AFA HybridFlash

Scaleout

Hyperscale

Hyperconverg

ed

Cloudstorage

DataAnalitic

BigData

VirtualSAN

WebScale

SDS DataAware

DataIntegrity

Amazon Y Y RF/EC

Google Y Y RF/EC

3PAR (HP) Y Y Y Raid

Atlantis USX Y Y Y RF

Ceph Y Y EC

Cohesity N Y EC

Coho Data N Y Y Y Y EC

DataGravity Y

GlusterFS Y Y Y

Hadoop Y Y EC

Hedvig N Y Y EC

HDS Y Y Y Raid

Infinidat N Y Y

Infinite IO N Y(?)

Isilon (Emc) Y Y

Kaminario N Y Y EC

Maxta N Y Y Y

Nimble N Y Raid

Nimbus N Y

Nutanix Y Y Y Y Y RF/EC

Oracle zs Y Y Raid

Pernix Data Y Y

Pivot3 N Y Y

Primary Data N Y

Pure Storage Y Y

Qumulo N Y Y Y EC

Rozo Y EC

S c a l e I O(Emc)

Y Y Y RF2

Simplivity Y Y Y Y

Solid Fire Y Y Y RF

Syneto Y Y Raid

Springpath N Y Y

Tegile N Y Raid

Tintri N Y Raid

ViolinMemory

N Y

Vsan(Vmware)

Y Y Y RF

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

La prima scrematura è stata applica a tutti quei clustered system che per vari motivi nonhanno (Type4 per ora) i requisiti di uno storage Tier 183 per infrastrutture divirtualizzazione: Hadoop84, Ceph, GlusterFS, ecc., ecc. Successivamente si è scelto di scartare tutti i sistemi general purpose o Type1 non scale-out perché non in grado di garantire una scalabilità progressiva di capacità e performancenel lungo periodo. Premesso che molte aziendesono ancora allo stadio di startup, numerosisistemi utilizzano efficacemente ZFS filesystempotenziandolo di funzioni come deduplica,compressione o caching ottenendo risultatieccellenti (Syneto). In alcuni casi sono statibrevettati nuovi filesystem, come CASL85, conl'obiettivo di migliorare alcune criticità di ZFS.Quasi sempre l'interfaccia grafica di gestione ediagnosi è anni luce migliore di quanto si fosseabituati in passato. Come anticipato alcunivendor sono stati scartati perché non distribuiti inItalia, tra questi alcuni presentano dellecaratteristiche tecnologiche innovative. Adesempio SolidFire (acquisita a dicembre daNetapp) e ancor più Kaminario propongonoprodotti scale-out di tipo AFA utilizzando dischi SSD cMLC o tMLC con costi per GB moltocompetitivi. Coho Data implementa un'infrastruttura di rete nativamente in SDN per lagestione dello scale-out e la possibilità di ospitare microservice Docker per l'analisi deidati. Prima di affrontare la pattuglia dei sistemi hyper-converged colgo l'occasione permenzionare alcuni prodotti particolarmente originali. Pernixdata propone per VmwareEsxi una soluzione di caching, anche in write back, tramite l'utilizzo di software layer chesfrutta la ram o dischi SSD in locale agli host allo scopo di ottimizzare lo storage NAS inuso. Analogamente Atlantis USX propone una soluzione software per implementaremetodi di deduplica e compressione direttamente sui volumi NAS esistenti. Lo statodell'arte di questa classe di sistemi è rappresenta da Infinite IO che si propone comesistema di accelerazione/caching con tiering dei dati cold su cloud. Altri sistemi di storagemolto promettenti sono Qumulo e Data Gravity che aprono la strada a una nuovacategoria di storage NAS con sistemi di gestione, analisi dei dati e qos che sono il sognodi qualunque storage admin.Una elemento di criticità comune a molti vendor, ad eccezione di quelli che utilizzano ZFSfilesystem, è la diffusa consuetudine ad omettere informazioni sulla Data Integrity, che ècome proporre un investimento finanziario omettendo di indicare l'indice di rischiosità… Unesempio su tutti è rappresentato da Emc ScaleIO che utilizza un medoto RF(2,1), ma chenon indica come vengano preservati i dati per la SDC. Nascondersi dietro una fantomaticapolicy di riservatezza per non divulgare ai concorrenti preziose informazioni è un lusso chepuò permettersi, per ora, solo Amazon con una capitalizzazione in borsa di quasi 300miliardi di dollari.

83 Defining Tier-1 Storage in the Modern Data Centerhttp://h18006.www1.hp.com/storage/pdfs/4AA3-6569ENW.pdf

84 https://storagemojo.com/2015/06/01/make-hadoop-the-worlds-largest-iscsi-target/ 85 Casl vs Zfs http://www.nimblestorage.com/blog/technology/a-comparison-of-filesystem-architectures/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Il segmento Type3 è quello più affollato con il trend emergente dei sistemi hyper-converged86 trainati da Vmware Vsan che da tempo conduce una campagna di marketingmolto pervasiva (sito, blogger, annunci) per i clienti vSphere. Per una sintesi dellecaratteristiche dei principali sistemi disponibili sul mercato suggerisco di leggere ilcontributo di Trevor Pott in questo post87 . Alcune nuove startup non sono state prese inconsiderazione poiché i loro prodotti non sono ancora in commercializzazione ufficiale, mavale la pena dare un'occhiata ad alcune di esse, come Hedvig o Rozo, per intuire la vitalitàdi questo mercato.Per chi ha già un'infrastruttura di virtualizzazione l'inclinazione ad avviare un POC conVmware Vsan è piuttosto naturale, ma dopo un'analisi più approfondita sono emersialmeno due elementi tecnici macroscopicamente controversi: l'uso di metodi ditrasmissione IP multicast e scarsa documentazione sulla gestione della Data Integrity.Per il primo punto è bene ricordare che IP multicast è stato definito per la prima volta nel1986 (!) e quindi non è propriamente lo stato dell'arte dei sistemi di trasmissione. Lagestione dei flussi e delle sottoscrizioni è demandata a funzioni L2-L7 esclusive delfirmware dello switch, con la conseguenza che un anomalia di funzionamento (bugsoftware) non è identificabile dai livelli L7 applicativi. Per casi di L2 IP multicast in cui gli

hosts risiedano su switch indipendenti connessi via trunk ènecessario implementare funzionalità di querier mentre lacomplessità aumenta notevolmente quando sia necessarioconfigurare protocolli di Multicast Routing88. A conferma deidubbi è piuttosto interessante la lettura di questo articolo89 dicritica a Vmware e che a mio parere accomuna Vsan,Microsoft90 e Atlantis USX nell'anacronistica (incauta) scelta diusare IP Multicast a 30 anni dalla sua definizione. Per quantoconcerne la Data Integrity non sono stato in grado di trovaredocumentazione ufficiale disponibile, poiché qualche caso dicorruzione dei dati sembra essersi verificato91 l'opzione diavviare un test di Vmware Vsan è stata rinviata.

Il processo di pre-selezione si è concluso quindi selezionando Nutanix in considerazionesia del fatto che è la prima startup presente sul mercato e sia per scelta filosofica e dimarketing di rendere pubblica parte della propria documentazione92 tecnica, non molto,ma abbastanza per avviare un' approfondimento ragionato . Nutanix si propone come un sistema “loosely coupled scale out” Type3 con una serie difunzionalità:- convergenza: in condizioni normali una VM accede allo storage interno al server vialocalhost networking,- software defined: inteso nella sua accezione più semplice come preminenza del softwareindipendente da vincoli hardware,

86 http://www.theregister.co.uk/2015/07/21/hyperconverged_market_hotness/ 87 https://community.spiceworks.com/topic/591454-simplivity-nutanix-or-scale?page=2 88 Multicast https://www.juniper.net/documentation/en_US/junos13.2/topics/concept/multicast-ip-overview.html ,

https://www.extremenetworks.com/wp-content/uploads/2014/04/Multicast.pdf 89 Unreliable Multicast means Unreliable VMware VSAN

http://etherealmind.com/unreliable-multicast-means-unreliable-vmware-vsan/ 90 Microsft network load balancing

http://demo.ipspace.net/bin/watch?id=8050da3e-5655-11e1-96be-005056880254 91 http://www.ontrackdatarecovery.it/azienda/comunicati-stampa/63383/kroll-ontrack-recupera-i-dati-da-vmware-

virtu/ , http://hansdeleenheer.com/vsan-the-performance-impact-of-extra-nodes-versus-failure/ 92 http://nutanixbible.com/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

- storage ibrido: utilizza dischi flash o magnetici in modo ottimale,- virtualizzazione ibrida: supporta più hypervisor mantenendo la stessa architettura- web-scale: scale out graduale con garanzia di consistenza e integrità del dato,rilevamento dei guasti automatico e auto-riparazione in caso di fault.

Una caratteristica tipica di un sistema Nutanixè l'insistenza sull'aspetto della convergenza inconsiderazione del fatto che il proprio“Nutanix Distributed Filesystem“ è accessibilevia rete IP. Dato che un comune desktop conuna scheda di rete hardware da 1Gb/s puòraggiungere picchi di 80/90 Gb/s quandoutilizza la TCP localhost interface (iperf) èevidente che l'accesso allo storage pool illocalhost consente di raggiungere picchi diperformance elevatissimi. L'utilizzo di metodicombinati di replica RF ed EC e l'utilizzo dicicli di scrubbing dai dati danno l'idea di unsistema maturo e con tutte le carte in regola per essere sottoposto ad un POC.

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Parte terza: test di performance e Proof of concept.Da alcuni mesi Vmware e Nutanix hanno ingaggiato una reciproca campagna dimarkenting volta a dimostrare l'eccellenza dei propri prodotti che ha evidenziato ladifficoltà nel riconoscere uno standard per il benchmark dei prodotti hyper-converged.Personalmente ritengo che in ambito sanitario la prevalenza della continuità di servizio siaprioritaria anche a scapito di valori bassi di latenza. La necessità di simulare ilcomportamento in situazioni di stress di carico di lavoro e di confronto con altri player hacondotto alla scelta di utilizzare un progetto di Vmware gratuito e facilmente utilizzabile invSphere: HCIbench93. Tutti i test sono stati effettuati in base alle linee guida e con gli stessiworkload profile utilizzati dalla rivista Storagereview nell' articolo “Vmware Virtual SANReview: HCIbench Syntethic Performance”94. Effettuare dei benchmark è un'attività cherichiede impegno e occupa molto tempo, trovare quindi dei reports indipendenti è digrande aiuto all'attività di indagine. Nel caso in esame alcuni risultati evidenziano soglie dicriticità notevoli: come mai nel terzo round di test la latenza misurata è quasi 15 voltemaggiore del primo con footprint da 1,6TB?

Il terzo test con footprint da 16 TB è pensato per rendere ininfluente il contributo diaccelerazione dei dischi SSD con conseguente utilizzo dei soli dischi magnetici. Un indiziosulle cause dell'anomalia potrebbe essere trovato in una nota sulla classe Type3 di ChadSakac nel suo già citato articolo95 di classificazione degli storage di cui ripropongo unestratto:“if you use a lower amount of distribution (even if the nodes in the cluster is higher), latencies can belower – but the flip side is true – you don’t get the same degree of potential parallelism on reading data.That is the design center of VSAN as an example. …. Conversely, people using VSAN can see forthemselves what increasing the object copy policy to large numbers does to latency and system-wide IOps – hint, more copies = higher and higher load on the system as a whole (and it’s non-linear, asyou would expect from that type of design). ...”

Per il POC è stato consegnato un Nutanix NX-1065-G4 con tre nodi ciascuno dotato di256Gb di ram, un disco da 400GB SSD e due dischi da 2TB SATA (SeagateST2000NM0033 con URE 1x101 5) . Essendo i sistemi hardware diversi in capacità e

93 http://cormachogan.com/2015/09/24/getting-started-with-hcibench-the-benchmark-for-hyper-converged-infrastructure/ , http://blogs.vmware.com/virtualblocks/2015/08/12/introducing-hcibench-a-free-storage-performance-testing-tool-for-hyperconverged/

94 http://www.storagereview.com/vmware_virtual_san_review_hcibench_synthetic_performance 95 Chad Sakac http://virtualgeek.typepad.com/virtual_geek/2014/01/understanding-storage-architectures.html

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

potenza si è cercato di personalizzare alcuni parametri al fine di effettuare dei test chefossero confrontabili proporzionando il numero di VM e i footprint:- fully in-cache,- partially outside of cache,- spilling outside of cache.Nel cluster di prova è stata installa la VM via ova ed effettuato il download di vdbenchcome da istruzioni e dopo qualche giro di prova è stato eseguito più volte il workloadp r o f i l e " H c i B e n c h 8 K R a n d o m 7 0 % r e a d / 3 0 % w r i t e " .Le clausole contrattuali di Nutanix96 non consentono di pubblicare i risultati ottenuti da testdi performance senza autorizzazione, scelta che non condivido e ritengo svantaggiosa peri clienti. In questo è in buona compagnia con Vmware che proibisce97 di pubblicareliberamente report di per Vmware vSphere, il che non ci ha impedito di triplicare leperformance di Oracle DBMS migrando le VM su hypervisor Xen (Oracle VM). Per questi motivi si preferisce presentare un graficodei risultati senza valori allo scopo di analizzare itrends. Al contrario dei risultati dei test di VmwareVsan i valori migliorano al crescere del footprint senzaperò raggiungere picchi di performance. Nel casodella latenza nel test “Partially ouside” i valoriaumentano leggermente per poi migl ioraresensibilmente nell'ultimo round. L'idea che se nericava è di un sistema che mantiene un profiloprestazionale mediamente contenuto, ma costanteanche quando viene a mancare il contributo del disco SSD. Per capire come sia possibileraggiungere questo risultato è necessario ricordare che Nutanix, in modo simile a quantofa il modulo (ex) Virsto98 embedded in Vsan 6 (e Zil di ZFS?), utilizza un componenteOplog per le scritture hot: “The OpLog is similar to a filesystem journal and is built as astaging area to handle bursts of randomwrites, coalesce them, and thensequentially drain the data to the extentstore.”Nelle situazioni in cui il disco SSDr a g g i u n g e l a s o g l i a c r i t i c a d ioccupazione del 75% tutte le scritturerandom vanno direttamente negli HDD.Per evitare di superare questo limite, apartire da NOS 4.5, è stata introdottaun'opzione detta “Intelligent LifecycleManagement” (ILM) che agisce suidischi SSD99 al fine di ridurre l'impattodella replica RF., ma quando insituazioni particolari (footprint spillingoutside of cache) si supera la soglia del 75%, i dati vanno direttamente nei dischi SATA e

96 e. disclose the results of testing, benchmarking or other performance or evaluation information related to the Software or the product to any third party without the prior written consent of Nutanix;http://www.nutanix.com/eula/

97 2.4 Benchmarking https://www.vmware.com/download/eula/esxi50_eula 98 http://cormachogan.com/2012/08/22/virsto-software-for-vsphere-overview/ 99 NOS 4.5 ILM per SSD http://www.joshodgers.com/2015/08/04/nos-4-5-delivers-increased-effective-ssd-tier-

capacity/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

sono richieste letture random di dati cold si attiva un'ulteriore100 opzione ILM cheparallelizza le lettura dai dischi SATA degli altri nodi:

Memori dell'ammonimento che “... more copies = higher and higher load on the system..” Nutanixafferma che in condizioni normali “Data Locality is being maintained for the hot data which residesin SSD tier because reads from SSD are faster and have lower overheads on CPU/Network etc when readlocally due to the speed of SSDs.” Ma quando l'accesso random ad un disco SATA a sua volta diventa un collo di bottigliaILM distribuisce le lettura dai nodi in rete migliorando le performance e riducendo lalatenza.ILM è un modulo software incluso tra i tanti miglioramento delle versione 4.5 di NOS edimostra come la libertà di programmare svincolati da componenti hardware siavantaggiosa. Fin dalle sue prime versioni NUTANIX ha protetto di dati utilizzando metodidi erasure code di tipo Replication Factor, RF2 con un ratio del 50% di spazio disponibileo RF3 con il 33%, decisamente dei valori molto bassi che però permettono di sostenere ilguasto di nodi o blocchi a seconda delle configurazioni.La necessità di competere sul mercato aziendale ha spinto gli sviluppatori, similmente aquanto fatto da Google, Facebook e Microsoft, ad introdurre meccanismi di erasure codeper ottenere ratio di storge efficiency migliori; dalla versione 4.5 è disponibile un algoritmoproprietario chiamato EC-X101 per i cold data.

Con queste premesse il modulo “Intelligent Lifecycle Management” effettua il workflow per gli I/O di scrittura dei dati che è ben più articolato di un semplice tiering ssd/hdd. Nello scenario previsto, con due blocchi per un totale di 6 nodi, lo stato dell'arte ciconsentirà di implementare un'architettura RF3+EC-X tale per cui si potrà avere latolleranza al guasto di 2 nodi contemporaneamente con una storage efficiency di circa il50%, di gran lunga superiore rispetto ad uno scenario RF3 “puro” con solo il 33% di spazioutilizzabile:

A parziale conclusione (poiché quando si parla di integrità non si giunge mai ad unaconclusione) della disamina dei vantaggi in termini di Data Integrity/Availability di un

100 NOS 4.5 ILM per SATA http://www.joshodgers.com/2015/08/04/nos-4-5-delivers-increased-read-performance-from-sata/

101 Nutanix EC-X http://www.nutanix.com/2015/06/17/erasure-coding-x-ec-x-predictably-increase-usable-storage-capacity/ , http://www.joshodgers.com/2015/10/07/sizing-assumptions-for-solutions-with-erasure-coding-ec-x/

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

distributed storage rispetto ad un Type1 tradizionale suggerisco la lettura di “FailureAnalisys”102 di Nutanix che riassume gran parte degli argomenti trattati fin'ora.

Il POC è proseguito con il trasferimento a novembre 2015 di 80 VM dal NAS Type1(arraySAS) al Cluster Nutanix per un periodo di oltre due mesi ottenendo subito unmiglioramento della latenza media ma, soprattutto, un appiattimento delle oscillazioni checausavano timeout applicativi. Nelle immagini seguenti si possono vedere le rilevazioni diun server Linux campione monitorato con Munin:

dai grafici è evidente la stabilizzazione attorno ad un range più stretto della latenza e lascalabilità degli IOPs in conseguenza di un maggior carico di lavoro.Come sempre ci sono delle limitazioni e dei vincoli che vanno considerate e forse daquesto punto di vista può essere utile rifarsi ai concetti del teorema CAP rivisitato inPACELC103.

Ipotizziamo cheNutanix sia un caso PAEC ossia che in caso di partitioning venga sacrificata l' Availabilityin favore della Consistency. Nell'ipotesi di avere un cluster a 2 blocchi con 6 nodi in RF3 ilsistema è in grado funzionare anche con due nodi guasti, ma superata tale soglia unulteriore fault

102 Nutanix http://go.nutanix.com/rs/nutanix/images/nutanix-failure-analysis.pdf 103 http://www3.nd.edu/~dthain/courses/cse40822/fall2014/slides/cse40822-CAP.pptx

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Simultaneous Failure ToleranceNumber of Blocks Awareness Type Cluster FT1 Cluster FT2<3 NODE SINGLE NODE DUAL NODE

3-5 NODE+BLOCKSINGLE BLOCK(up to 4 nodes)

SINGLE BLOCK(up to 4 nodes)

5+ NODE+BLOCKSINGLE BLOCK(up to 4 nodes)

DUAL BLOCK(up to 8 nodes)

andrebbe a inficiare la consistenza dello storage venendo a mancare il numero minimo diframmenti per la ricostruzione di quello mancanti per mezzo degli algoritmi di erasurecode. Un ulteriore elemento critico è la soglia globale di spazio occupato, analogamente aquanto avviene in un filesystem ZFS il superamento dell'80% di spazio utilizzato puòmettere l'NDFS fuori linea per mantenere la consistenza dei dati. Quando il sistemafunziona in condizioni ottimali ritengo che l'infrastruttura NDFS sia orientata allaConsistency come farebbe supporre il workflow del modulo ILM:

All'opposto vi è la scelta di limitare a RF2 il fattore di replica nel distributed filesystemScaleIO da parte degli sviluppatori proprio per ottenere latenze estremamente basse: “Youcan have low write latency AND high scaling AND high parallelism on reading – but only ifyou finely sub-stratify the the data, BUT only write a small number of copies. That’s theScaleIO design point.” (Chad Sakac).In Nutanix ci sono molti altri altri elementi tecnici, come ad esempio la possibilità diimplementare sistemi nativi di replica sincrona o asincrona del cluster o l'interfaccia digestione e diagnosi eccellente, che meritano di essere presi in considerazione.

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240

Conclusioni.Nutanix è un sistema integrato hyper-converged con un distributed filesystem attento allaconsistenza e integrità dei dati con una caratterizzazione delle performance orientata adun carico di lavoro costante e gradualmente scalabile, che è la tipologia di prodotto chemeglio si adatta alle nostre esigenze per migrare l'infrastruttura di virtualizzazione.E' plausibile che nell'immediato futuro i sistemi storage di file sharing documentale (adesempio CIFS server) vengano virtualizzati e inglobati nei sistemi hyper-converged e, amio parere, ritengo che Hadoop sia una soluzione matura con un frameworkincredibilmente avanzato che per una diffusione capillare nel mondo aziendale manchisolo di una killer application: posta elettronica, Pacs, DMS, ecc., ecc. Gli storage Type1possono ancora avere qualcosa da dire quando sono richieste performance elevate.All'orizzonte sono attese nuove tecnologie come i dischi 3D Point di Intel/Micron, iMemristor di HP/Sandisk e i Dssd di EMC ma, memori che non sempre è tutt'oro quel cheluccica104, la prudenza è sempre consigliabile.

104https://www.usenix.org/system/files/conference/fast15/fast15-paper-kim-jaeho.pdf

U.O.A. Servizio Informatico Via Trento, 4 - 36071 Arzignano (VI)Resp. del Procedimento: dott. Giorgio Roncolato Tel: 0444/479663 Fax: 0444/479654 Resp. Istruttoria: Alessandro Fascina e-mail: uoc.servizio.informatico@ulss5.itRevisione 1.0 del 5 febbraio 2016 C.F.e P.I. 00913220240