Sto leggendo ultimamente una enorme mole di informazioni riguardanti lo storage Flash. Articoli, blog, whitepaper prodotti da analisti, blogger e dalle stesse aziende che producono una qualsiasi soluzione basata sulle memorie NAND. Ognuno possiede una propria soluzione; tutte sono state concepite per risolvere gli annosi problemi di lentezza dello storage basato su dischi meccanici, ma allo stesso tempo la modalità in cui si offrono di risolvere questo problema è molto differente una dall’altra.
Alla persona quindi che mi chiede “Credo mi possa servire uno storage flash, ma quale?” cosa posso rispondere?
Cosa dovete sostituire nel vostro datacenter?
La possibilità di progettare da zero una nuova infrastruttura (il cosiddetto “greenfield”) senza doversi preoccupare di integrare il nuovo con elementi già esistenti è la situazione in cui ogni progettista si trova più a suo agio. Aggiungere un componente a un’infrastruttura che già funziona è sicuramente una sfida stimolante, ma anche piena di potenziali insidie; figuriamoci quando l’elemento da aggiungere è un componente così fondamentale come lo storage.
Purtroppo però le situazioni cosiddette “brownfield” sono le più comuni. Esistono sicuramente molti fattori quando si deve valutare l’introduzione di una nuova tecnologia, e in una situazione già consolidata l’invasività di una soluzione è un fattore importante. Quindi, quando sto valutando con un cliente quali nuove opzioni abbiamo a disposizione, una delle domande che faccio solitamente è proprio questa:
“cosa dovete sostituire nel vostro datacenter?”
In occasione infatti di sostituzioni di componenti hardware che sono arrivati alla fine della loro vita utile, è sicuramente più facile introdurre una nuova tecnologia. Badate bene! Sto valutando queste differenti soluzioni unicamente in base alla facilità e ridotta “invasività” con la quale si possono introdurre in una infrastruttura esistente. Esistono ovviamente molti altri fattori da considerare per la scelta finale, che però non considero in questo articolo.
Questo semplice grafico descrive le varie situazioni. La freccia indica il livello di sostituzione dei componenti che la tecnologia scelta comporta. Il grafico vuole essere un brevissimo riassunto dei principali casi d’uso, ovviamente si possono utilizzare le varie tecnologie anche in altre situazioni.
Server Side Caching
Questa soluzione è la meno intrusiva, e quella che permette con poca spesa e in poco tempo di migliorare le prestazioni di un sistema storage esistente. Al minimo, sono necessari un disco SSD per singolo server ESXi e le licenze del software di caching prescelto (Pernix Data, FlashSoft, Proximal Data, o anche VMware vFRC).
E’ la soluzione ideale se non si ha in previsione nessun rinnovo tecnologico dell’infrastruttura in nessuno dei suoi componenti, e se lo specifico problema da risolvere è il livello prestazionale dello storage esistente. E’ una soluzione molto mirata: se ad esempio lo storage che si possiede ha ancora sufficiente spazio disco libero, aggiungere dischi per incrementare le sua prestazioni sarebbe una soluzione molto inefficiente. Tramite invece il Server Side Caching è possible demandare allo storage centralizzato la gestione della capacità, e affidare invece al sistema di caching la gestione delle prestazioni.
Ognuno dei vari prodotti disponibili presenta peculiarità e differenze: accelerazione delle letture o anche delle scritture, supporto per i datastore VMFS o NFS o entrambi, supporto specifico per il solo VMware vSphere oppure anche per altri Hypervisors… Quello che hanno tutti in comune è la poca invasività: oramai nessuna soluzione moderna prevede più l’installazione di agenti o driver all’interno delle virtual machines, ma tutti lavorano direttamente a livello dell’hypervisor. Questo rende molto semplice l’installazione, e non comporta nessuna modifica alle virtual machine.
Se dovete unicamente incrementare le prestazioni di un’infrastruttura storage esistente, questa è la vostra soluzione.
Flash Storage Array
Esistono oramai numerosi storage sul mercato specificatamente progettati per sfruttare le memorie NAND al loro interno. Possono essere di due tipi fondamentalmente: Hybrid (con un mix di memoria Flash e di dischi meccanici) oppure i cosiddetti AFA (All Flash Array, composti quindi unicamente da memorie NAND).
La scelta tra le due tipologie principali dipende da fattori come il costo per GB oppure il costo per IO che necessitate o che siete disposti a spendere; i sistemi hybrid sicuramente sono più economici da questo punto di vista, mentre tendenzialmente i sistemi All Flash saranno più performanti. Non è scopo di questo articolo valutare pregi e difetti delle due tipologie.
Piuttosto, è interessante osservare come questi sistemi possano essere integrati in un ambiente esistente. Anche se internamente le loro caratteristiche tecniche sono più o meno differenti, uno dei vantaggi di questi storage è che si presentano ai client come un qualsiasi storage array “classico”: sia che venga utilizzato come protocollo di connessione FC, iSCSI, FCoE, oppure NFS, questi sistemi possono essere collegati ai vari server ESXi esattamente come lo storage che state utilizzando oggi. Inoltre, molti di questi storage offrono il supporto per le librerie accelerate VAAI, e alcuni (non tutti) presentano funzioni enterprise come Snapshots e Repliche.
La loro maggiore intrusività rispetto ai sistemi server-side caching è dovuta non tanto alla loro introduzione nell’ambiente esistente, ma alla necessità di dover spostare le virtual machine su di essi per poterli usare. Da quando VMware ha posizionato le licenze di Storage vMotion anche nelle versioni inferiori di vSphere, la disponibilità di questa funzione è impedita unicamente ai clienti con licenze Essentials. Ma anche per gli altri clienti, si pone il problema di movimentare la virtual machines dal vecchio storage a uno di questi sistemi. Ciò comporta una creazione di I/O sullo storage sorgente, che oltretutto sarà uno degli storage “lenti” che si vuole sostituire. Bisogna sicuramente pianificare con attenzione queste operazioni.
Converged Infrastructure
Con questo termine si indicano diverse soluzioni, e ho notato ultimamente che anche diversi vendor primari lo stanno utilizzando.
I
o sinceramente mi riferisco unicamente ai prodotti di due aziende, Nutanix e SimpliVity. Tutte le varie soluzioni come Vblock, FlexPod e simili, a me paiono piuttosto come un bundle di prodotti già esistenti e assemblati in modo curato dal produttore, e offerti come un unico prodotto insieme ad un software di gestione. Nutanix e SimpliVity invece nascono da zero per essere un sistema integrato che al proprio interno offre sia l’hypervisor che lo storage distribuito.
Il singolo server porta con sè un determinato quantitativo di storage, e il cluster viene espanso aggiungendo un numero a piacere di server. In questo modo, si aumenta sia la potenza di calcolo che lo storage, oltretutto in entrambe le sue caratteristiche di capienza e prestazioni.
Questi sistemi sono un’incredibile soluzione per costruire nuove infrastrutture: offrono tempi di installazione e messa in servizio molto ridotti, e soprattutto permettono di scalare nel tempo, evitando inutili spese iniziali. In questo risiede il loro maggior vantaggio, da un punto di vista economico.
A livello di integrazione in ambienti esistenti tuttavia, questi ambienti risultano “auto contenenti”. Sono perfetti fino a quando tutto è eseguito al loro interno, ma non sono pensati per essere utilizzati come storage esterno di altri server ESXi. Questo seplice elemento limita il loro impiego all’interno di ambienti già funzionanti; esistono casi d’uso ben specifici dove possono essere implementati con successo, ma volerli imporre come “LA” soluzione per ogni sistema è impensabile. Se invece pensiamo ad esempio a nuovi progetti in realtà consolidate come se fossero nuovi “micro ambienti”, ecco che tornano prepotentemente nella lista delle soluzioni papabili.
Flash nel mio vecchio array? No grazie.
Vi sarete accorti che da questa panoramica manca un’opzione che invece ad oggi si ritrova in numerose soluzioni: l’installazione di alcuni dischi Flash all’interno di storage già esistenti. Se lo storage non è stato progettato per utilizzare dischi Flash tuttavia, il guadagno che si ha nell’aggiungere questi dischi è praticamente nullo. Si avranno certo prestazioni migliori, ma i dischi Flash appariranno unicamente come dei normali dischi, solo più veloci.
La velocità delle memorie Flash porta due problemi fondamentali che solo uno storage pensato appositamente può gestire: l’I/O di uno di questi oggetti è sufficiente a saturare i più diffusi bus di comunicazione, siano essi SATA o anche SAS. Inoltre, una memoria Flash impegna la CPU molto più di un disco meccanico, proprio per la quantità di dati che è in grado di movimentare. Se un controller di un array non è stato opportunamente dimensionato per le memorie Flash, e il suo software non è nato con l’idea di gestire questi supporti, la loro aggiunta potrebbe creare problemi di prestazioni al controller, ovvero il risultato opposto a quello sperato.
Cosa succederà nel lungo periodo?
Se estendiamo i discorsi fatti fin qui a periodi di tempo più lunghi, alcuni ragionamenti potrebbero essere differenti. Ad esempio, il server-side caching è da considerarsi una comoda soluzione per l’immediato, oppure un nuovo modo di disegnare gli storage? Nel lungo periodo utilizzeremo tutti sistemi di tipo converged, specie se VMware renderà questi concetti diffusi e accettati grazie a VSAN?
I tempi di rinnovo tecnologico si sono ultimamente dilatati, e non è difficile incontrare realtà dove permangono sistemi con 4-5 anni di età, e non più di 2-3 come accadeva solo qualche anno fa. Ciò vuol dire che, nell’introdurre un sistema basato su Flash, qualunque esso sia, il fattore economico deve essere rapportato a questo lasso temporale.
L’importante è iniziare in ogni caso a valutare gli storage Flash fin da oggi se già non l’avete fatto, e non continuare a comprare capacità (sotto forma di dischi meccanici) per risolvere problemi di prestazioni. I dischi non vi aiuteranno. Le memorie NAND sì.