ATTENZIONE!!!! se sei utente EMC evita di leggere quanto segue, ci potresti rimanere male. 🙁

La scorsa settimana  Ã¨ stata lunga, appena tornato dagli USA mi sono precipitato da un cliente per affrontare una presentazione per Compellent contro EMC CX-4.

La cosa che mi ha colpito di più di tutta la giornata è stato il prezzo che EMC ha fatto al cliente…. basso, molto basso, non potete immaginare quanto basso! perchè? perchè le funzionalità che EMC spaccia di avere non sono utilizzabili e quindi abbassa il prezzo ad un valore “accettabile” per il cliente! Comunque la trattativa non l’abbiamo persa, non ancora almeno 😀 :il cliente, grande acquirente di EMC, si sta dimenando fra lasciare il N.1 dello storage mondiale ( 🙂 )che non gli da quello che gli serve ma glielo da a poco e Compellent che sicuramente costa di più ma fà quello che serve, lo fà bene e con un TCO decisamente molto più basso nell’arco degli anni a venire. (non potete immaginare quanto sia dura parlare di TCO con chi non ci vuol sentire!)

Oggi non voglio tediare nessuno con tutti gli altri 1000 motivi tecnici che stanno portando questo cliente ad una riflessione ma mi voglio concentrare sul Thin Provisioning.

Cosa è il Thin Provisioning?

il TP è una funzionalità dello storage che permette di far credere ai server di aver allocato una certa quantità di spazio ma, in realtà, viene usato solo quello veramente consumato. Questo meccanismo permette quindi di non avere una allocazione dello spazio rigida come nei sistemi obsoleti “tradizionali” ma di godere di una flessibilità, impensabile in precedenza, che si traduce in risparmi notevoli nel tempo.

Un esempio?

L’esempio più semplice può essere questo: se oggi dovessi pianificare lo spazio per un nuovo DB sarei costretto a capire quanto sarà grosso da qui a tre anni e, comunque, aggiungere dell’altro spazio per un eventuale crescita inattesa… quindi, per fare bene, se oggi dovessi pensare ad un DB di una certa dimensione (magari da 1TB) dovrei allocare il mio TB più un 20/30% per gli imprevisti: totale 1,3TB!!!

E quanto ne userei di quei 1,3TB? all’inizio nulla! poi pian piano il DB crescerà ma non so se poco, molto o troppo! e allora l’allocazione rigida dello spazio mi ha portato a:

  • comprare più spazio di quello che mi serve oggi
  • allocare più spazio di quanto mai mi servirà (già l’amministratore del DB aveva sovradimensionato il TB!!!!)
  • rischio di dover riallocare comunque lo spazio per la troppa crescita
  • dover combattere con le altre risorse del mio storage che hanno più necessità di spazio di questa, almeno nell’immediato!
  • ecc
  • ecc

Con il TP alloco la LUN tanto grande quanto serve e anche di più e il sistema si occuperà di allargarla quando e come servirà!

  • evito di dover pianificare la crescita (purtroppo non ho una sfera di cristallo)
  • evito di dover comprare oggi lo storage che forse mi servirà fra tre anni
  • evito molte altre attività di managment dello storage
  • ecc
  • ecc

Insomma il TP sta diventando una funzionalità essenziale per risparmiare dei soldi… e nei momenti di crisi ogni risparmio è benvenuto!!!

E’ l’implementazione che conta!

Il problema di ogni funzionalità dello storage è la sua implementazione! Il TP è una di quelle funzionalità che devi avere nel DNA, in questo caso il componente fondamentale è il wide striping (di cui ho già postato qui): senza un meccanismo di wide striping ogni implementazione di TP sarà zoppa in partenza e con delle limitazioni che si ripercuoteranno nella sua utilizzabilità.

Compellent ha un meccanismo di wide striping nel suo DNA (dynamic block architecture) che rende il TP una cosa sola con il resto della macchina… EMC ha appiccicato una pezza alla sua implementazione RAID per poter dire di avere il TP! (Attenzione io parlo di Compellent perchè lo conosco bene ma anche altri hanno un ottimo DNA 😉 , es.: 3PAR).

Ogni operazione su Compellent è thin provisioned, non ci sono limiti per le copie locali o remote, non c’è limite al numero di LUN, al numero di server, o altro. Su EMC invece è tutto un limite: il numero di LUN, il numero di volumi, il numero di server, il numero di dischi utilizzabili, il prezzo della funzionalità, l’impossibilità di usarla con MirrorView (replica remota dei volumi), e tante altre!

Ah, dimenticavo… su Compellent è possibile anche recuperare lo spazio non più utilizzato dai server… su EMC no!

C’è da dire una cosa in favore di EMC, il nome lo hanno centrato in pieno: Virtual Provisioning! nel senso che è così inutilizzabile che praticamente è virtuale. 8-D

Insomma, alla fine la gara è dura:

Da una parte un sistema di storage moderno, flessibile, integrato, totalmente virtualizzato, facile da usare e gestire, che però ha un costo d’acquisto più alto!

Dall’altro una scatola di dischi con un controller raid, rigido, poco integrato, senza funzionalità che ti costringerà a molte più ore (giorni) per il management, poco efficiente anche dal punto di vista energetico e di spazio; però costa meno da acquistare!

A voi la scelta: certo la crisi è dura ma se il progetto ha una visibilità più lunga di qualche settimana siamo sicuri che non sia meglio spendere un pò di più oggi per ottenere grandi risparmi domani? Basta fare i conti sul costo di uno Storage administrator in meno all’anno, risparmio energetico e di spazio nel datacenter (solo per citarne alcuni) ed ecco che mi ripago abbondantemente, e con gli interessi, quanto speso in anticipo!

Questo post mi è stato utile anche per rispondere a StorageBod sul suo post di qualche tempo fà “Just another feature”: è l’implementazione che conta, non il fatto di avere una nuova funzionalità. Lo stesso problema che poi si è riproposto nei giorni scorsi su un articolo di GestaltIT “EMC Symmetrix V-Max: When Does It Get FAST and Virtual?”: sta diventando controproducente, per i fornitori stessi, creare aspettative che vengono puntualmente disattese!

ES