La scorsa settimana si è parlato molto di wide striping e thin provisioning ma, a mio onesto parere, il discorso è partito su basi sbagliate!
Il primo è stato Hu Yoshida sul suo blog: ha iniziato spiegando come sia possibile ottenere un wide striping partendo dal thin provisionig. Poi c’è stato un post di Storagebod che ha chiesto di più ai vendor e la relativa risposta di EMC. Alla fine un commento di Storage Architect sulla faccenda… e per finire un altro post di Hu sul fatto che il TP di HDS consuma poche risorse…c’erano dubbi? deve usare poche risorse se no siamo sempre a cancellare vantaggi con svantaggi!
ma nessuno ha sollevato la vera questione!
il problema non è chi è nato prima fra l’uovo (thin provisioning) e la gallina (wide striping), ma la questione è tutta sull’architettura su cui si basano queste funzionalità!
Ok, adesso sia HDS che EMC ti “regalano” il thin provisioning ma è un falso regalo perchè, almeno per HDS, aumentano i costi di manutenzione!!! Se ti guardi intorno capisci che il thin provisioning deve essere gratuito: NetApp, 3Par e Compellent, solo per citarne alcune, lo fanno da sempre!
L’implementazione del TP che hanno scelto HDS e EMC è stata appiccicata a quanto già esistente, questo gli ha permesso di mantenere una compatibilità con il passato ma ha anche limitato fortemente questa tecnologia. Nel caso di HDS si è scelto di implementare il TP creando uno Pool fatto di raid groups, questi poi vengono affettati in chunks da 42 MB che vengono dati alle LUN… quindi, come risultato successivo si ottiene il Wide Striping…. ma con tante limitazioni.
La prima è proprio quella che suggerisce Chris M Evans nel suo post: “In addition, wide striping has more impact if a failure occurs. One benefit of having LUNs created from a single RAID group is that the impact of that RAID group failing is limited to only those LUNs. Imagine a 300GB 3+1 RAID group divided into 18x 50GB LUNs. Failure of that RAID group impacts only the 18 LUNs. So, wide stripe across 10 RAID groups – now the impact of any RAID group failure is 180 LUNs. Remember that’s any RAID group failure, which is much more likely as we have more RAID groups on which every LUN is dependent.”
Chris ha completamente ragione… un fail di un Raid group mina tutte le LUN coinvolte nel pool!!! Ma questo succede perchè esiste ancora il concetto di raid group, che è in netto contrasto con il concetto di Wide Striping. Per Compellent le cose sono radicalmente diverse e, manco a dirlo, molto più furbe. Compellent ha introdotto il DBA (Dynamic Block Architecture) e ogni blocco porta con se dei metadati utili a capire come quel blocco sia utilizzato all’interno del sistema. Grazie al DBA è possibile non fare più un raid group ma il raid è fatto a livello di singolo blocco! questo approccio di nuova generazione garantisce una affidabilità migliore, performance migliori e il wide striping vero implementato a basso livello: quindi si eliminano dall’inizio eventuali limitazioni software che si è costretti a vedere sui sistemi tradizionali. 
Anche 3Par ha una tecnologia molto sofisticata da questo punto di vista ma, non avendo qualche cosa tipo il DBA, ha delle forti limitazioni sulla possibilità di avere un pool unico che contenga dischi di diverso tipo (SSD, FC e SATA contemporaneamente)…. probabilmente è per questo che 3Par, ancora oggi, non ha gli SSD! Per 3Par sarà un grosso problema da gestire perchè gli SSD sono il futuro e la loro architettura non li ha previsti, come non può prevedere, al momento, l’automated tiered storage!
ES
[...] Lo Storage Center può spostare i blocchi e cambiargli il livello di RAID (leggi qui) all’interno di uno stesso disco ma può anche cambiare la posizione del blocco e mettere [...]