Ho letto questo articolo di Chris Mellor che si chiede quanto la crescita di SSD può penalizzare i produttori di dischi tradizionali (leggi Seagate).

Oggi gli SSD di classe enterprise vengono prodotti, (praticamente) in esclusiva, dalla STEC e sono i famosissimi ZeusIOPS. Questa azienda, fino a poco tempo fa quasi sconosciuta, sta vivendo un momento d’oro grazie ad un prodotto veramente eccellente e al ritardo dei competitor tradizionali che si sono trovati decisamente impreparati alla frenesia con il quale cresce la domanda.

L’attuale fortuna della STEC è però la sfortuna di tutti gli altri! (utenti compresi)

Il singolo vendor non aiuta il mercato e accresce i rischi!

Il fatto che i dischi SSD adottati da tutti i vendor sono forniti da un singolo produttore non permetterà di abbattere i costi nel breve periodo per la mancata concorrenza. Ne beneficeranno solo quegli utenti che hanno grande capacità di spesa. Aggiungo anche che STEC potrebbe essere avida e tralasciare la ricerca per fare più cassa possibile limitando così il lancio di nuovi prodotti più efficienti e meno costosi!

Un secondo fatto che, a prima vista, può sembrare banale è dato dal fatto che la STEC potrebbe avere un problema (disastro? problemi politici negli stati dove produce? altro?) che impedisca o rallenti la fornitura di questi dischi per un periodo anche lungo. Io non so quanti stabilimenti e in quali parti del mondo è presente STEC ma è vero che se ci fosse un problema nessuno avrebbe una alternativa seria per sostituire gli STEC con altro dentro gli array!

Terzo, siamo sicuri che STEC sia in grado di gestire una crescita così esplosiva? e se avessero un problema serio di produzione legato alla qualità o a bug sui nuovi modelli? (in questo caso ritorniamo al secondo punto).

SSD non è la panacea di tutti i mali!

SSD è veloce,costa molto ma è relativamente economico se serve veramente. Prove fatte nel mondo reale su applicazioni reali danno circa un rapporto 15:1/20:1 su un workload tipo DB con blocchi da 8K/16K, (per la natura dell’oggetto stesso non c’è più la differenziazione randomico/sequenziale). Più è piccolo il blocco più il rapporto aumenta! Con il costo di 3 SSD (raid1 + spare) si può risparmiare l’acquisto di 3 cassetti interi di dichi FC da 15K rpm e, almeno a listino, il TCA è leggermente più basso ma è il TCO a fare la differenza (solo per dirne una un cassetto consuma 800/1000 W mentre un disco SSD pochi watt).

Il problema sorge subito dopo… risolto il problema delle iops devo risolvere quello dello spazio e, ancora di più, di come organizzarlo!!! con Compellent è facile c’è la Data Progression ma per tutti gli altri è necessario preparare l’ambiente con accuratezza: fare il re-layout delle LUN, migrare i dati, gestire diversamente da quanto fatto finora lo storage! (costi, costi, costi).

A quanto sopra devo anche aggiungere, per esempio, la difficoltà di gestire le features aggiuntive che hanno i sistemi più evoluti di storage: come si gestiscono le snapshot e le repliche remote? sei hai una LUN su SSD le snapshot le puoi fare su FC? e ancora, se puoi fare le snapshot su FC c’è una sufficiente esperienza per garantire la qualità delle perfomance sulle LUN SSD coinvolte da quato meccanismo??? stesso discorso per la replica remota: puoi permetterti di gestire repliche sincrone da SSD a non-SSD?? se si è necessario capire quanto tutto questo impatta sulle performance reali e quanto limita i vantaggi dell’SSD!

La crescita dell’SSD non si fermerà ma ci vuole più esperienza.

Quindi, tanto per dare una risposta a Chris: E’ probabile che dopo questo primo momento inizieranno le prime riflessioni su come far convivere SSD-FC-SATA, quando avremo l’esperienza pratica sul campo capiremo le migliori pratiche di adozione e quindi anche come/quando acquisire questa tecnologia a discapito delle altre disponibili.

La cosa più importante ora, per chi acquista uno storage, è quello di non avere limitazioni sulla tecnologia dei dischi sul backend!!! come per Compellent per esempio 😉

ES

PS: poi magari già fra una settimana le cose cambiano… (leggi qui)