Sono stato invitato a partecipare in qualità di delegato allo Storage Field Day, nella sua quarta edizione in quel di San Josè, California. Ho potuto incontrare Coho Data presso i loro uffici a Sunnyvale. Questo articolo è una recensione molto dettagliata, e come vedrete molto appassionata, di quello che ho potuto vedere. Ammetto che sia piuttosto lungo, anche per i miei standard. Ma ho pensato che togliere delle parti sarebbe stato un delitto alla qualità dell’incontro che ho avuto.
Chi è Coho Data
Coho Data (precedente chiamata Convergent.IO) è stata fondata nel 2011 tra gli altri da Andy Warfield, che per chi non lo sapesse è tra gli ideatori dell’hypervisor Xen. Dopo avere assistito alla sua presentazione, mi risulta impossibile parlare della loro soluzione senza parlare un pò di Andy.
Capita frequentemente oramai durante i vari Tech Field Day che sia il CTO o un qualche fondatore della società a tenere la presentazione. Capita molto più raramente che questa persona sia anche un professore universitario, e che la presentazione diventi in modo assolutamente naturale una lezione. Questo è quello che è successo con Andy, che ci ha letteralmente “educato” sullo storage scale-out, sull’uso delle memorie Flash negli storage, nonchè mi ha dato una delle migliori spiegazioni che abbia mai sentito su SDN (curioso che arrivi durante una presentazione di storage e non di networking).
Uno storage “studiato”
La presentazione di Andy è stata supportata da tutta una serie di numeri e valori, derivati da numerosi test che lui e il suo team hanno condotto, per effettuare poi le decisioni finali mentre il prodotto veniva realizzato. Non voglio dire che altre soluzioni sono il frutto di idee infondate, ma apprendere i vari risultati e sentire poi come questi hanno influenzato le scelte architetturali mi ha dato l’impressione di avere davanti un prodotto che poteva effettivamente nascere solo in un ambiente dallo spirito universitario.
Il passato costituito dai lavori su Xen ha fatto si che una delle idee principali fosse portare gli stessi benefici che la virtualizzazione ha portato per i server anche verso lo storage. Questo ha significato disegnare un sistema che fosse scalabile, e che “disaccoppiasse” la gestione dell’hardware sottostante dai dati che contiene, sostanzialmente “virtualizzandolo”. Il tutto sfruttando i tre pilastri tecnologici che si sono affermati nei moderni datacenter: commodity hardware, connettività ethernet, e le memorie Flash.
L’obiettivo finale era creare uno storage che fosse fruibile come una utility (pensiamo all’energia elettrica) e che potesse fornire un sistema utilizzabile dalle società e dai service provider che non hanno le stesse capacità di giganti come Google, Facebook o Amazon per realizzarlo internamente.
Una grande enfasi è stata posta sull’uso di commodity hardware. Il vantaggio risiede nella possibilità di acquistare oggi la versione 1.0 del prodotto (sarà disponibile a fine Novembre), ma in futuro poterlo integrare con i nuovi modelli che si renderanno disponibili, dato che il “collante” tra i vari modelli hardware è il software che viene eseguito sui server. Ad oggi l’hardware vero e proprio, denominato DataStream 1000, è fondamentalmente un SuperMicro 2U Twin: uno chassis 2U al cui interno sono contenuti due server indipendenti. Ogni server, denominato invece MicroArray, presenta al suo interno due schede Intel 910 SSD Flash PCIe, due CPU Intel Xeon di ultima generazione, 6 dischi meccanici da 3 TB e due connessioni ethernet 10G.
Armonizzare il flusso di dati
Andy ci ha mostrato (supportato da grafici e numeri) come una singola scheda Flash sia in grado di saturare completamente un canale 10G ethernet, e possa anche mandare in crisi i processori più veloci. Inoltre, con i vari algoritmi di caching ad oggi disponibili, ci ha spiegato come una dimensione eccessiva di cache in proporzione allo storage che accelera è inutile, perchè oltre una certa percentuale le prestazioni non subiscono più incrementi sensibili che giustifichino il costo di memorie Flash di grandi dimensioni. Un’altra scoperta interessante è stata che le memorie Flash vengono gestite meglio dalle CPU all’aumentare della frequenza di clock piuttosto che dal numero di core che la CPU possiede.
Tutte queste analisi hanno portato Coho Data a disegnare il loro singolo server, il MicroArray, in modo che ogni componente fosse armonizzato con gli altri. Troviamo infatti 2 schede Flash PCIe, 2 processori Intel Xeon e 2 schede di rete 10G. Visto con un’altra angolatura, CoHo ha creato due flussi (appunto Stream) in ogni server, fatti così:
Il flusso dei dati quindi (il Data Stream) utilizza i vari elementi senza che nessuno di essi diventi un collo di bottiglia e metta in crisi gli altri.
Se si gunge a queste considerazioni, diventa ovvio che lo storage debba essere di tipo scale-out: modificare un singolo Stream in un qualsiasi suo componente (ad esempio per mettere una memoria Flash di dimensioni maggiori) significa compromettere l’equilibrio; meglio allora creare tanti Stream paralleli, e fare in modo che collaborino insieme.
Storage e Network, finalmente alleati!
Un fanatico delle buzzword di marketing avrebbe detto che Coho è la prima soluzione SDS + SDN: Software Defined Storage e Software Defined Network. Io che queste cose le odio, la descrivo in un altro modo.
Riprendiamo il discorso di prima: lo Stream è completamente armonizzato fino all’uscita dalle schede ethernet di ogni MicroArray. Uno storage però non vive di vita propria, ma nasce con lo scopo di gestire i dati dei client che vi accedono. Bisogna quindi poter garantire un flusso dei dati ottimale fino ai client! Da questa semplice osservazione nasce un’altra delle numerose idee veramente innovative che ci sono in questa soluzione: l’introduzione di uno switch ethernet, pilotato dallo storage, che gestisce in modo dinamico tutti i flussi di dati, da e verso i client, e tra i vari MicroArray.
In questo modo, lo storage non è più “in balia” della rete, sulla quale non ha controllo, ma anzi può sfruttare la rete a suo vantaggio. Tramite uno switch OpenFlow (ad oggi usano Arista, ma il dettaglio è veramente ininfluente) a 10G, Coho Data espone verso i client (pensate agli Hypervisor ESXi, dato che inizialmente il target è questo) una singola connessione NFS, che però è gestita in contemporanea da tutti i MicroArray.
Questo è possibile soltanto sfruttando la programmazione dello switch tramite OpenFlow. Le connessioni NFS per loro natura non possono essere multipath; un singolo server ESXi e uno storage NFS stabiliscono 1 connessione da indirizzo IP a indirizzo IP. In uno storage come Coho Data quindi, dove vi possono essere un numero elevato di MicroArray, un server ESXi si collegherebbe unicamente a uno di essi, di fatto vanificando le funzioni scale-out dello storage. Ma ecco che qui interviene OpenFlow: pur presentando un’unico indirizzo IP per tutto il cluster, Coho Data può programmare dinamicamente lo switch per distribuire le connessioni in arrivo dai vari server ESXi verso i vari MicroArray, in base a parametri come l’Array meno utilizzato, la connessione più scarica, e via dicendo. I server ESXi vedono un unico indirizzo IP, mentre dietro lo switch vi sono tantissimi MicroArray. La soluzione dimostra un uso pratico veramente geniale di SDN.
Uno storage proiettato al futuro
I vari MicroArray parlano tra di loro, si coordinano, scambiano dati e connessioni verso i client, allo scopo finale di presentare all’esterno un unico storage. Ma come avviene ciò?
Fondamentalmente, ci troviamo in presenza di un object storage, dove ogni dato di qualsiasi dimensione viene scorporato in “pezzi” di dimensioni variabili, gli oggetti appunto, marcato con un metadato che ne identifica la posizione nello storage e altre informazioni, e salvato in più MicroArray per ridondanza. Non vi è un file system sui dischi o sulla memoria Flash, Coho Data gestisce direttamente la scrittura dei dati sui media fisici, memorizzando poi le posizioni dei dati nei metadati. Ciò rende lo storage particolarmente veloce, dato che il livello di astrazione creato dal file system non è più presente. Inoltre, il namespace è univoco per tutto lo storage, tutti i MicroArray vedono gli stessi dati anche se le diverse copie degli oggetti vengono salvate solo in alcuni di essi.
Il sistema è resistente a numerosi failover, e in ogni momento ribilancia i dati tra i vari array per renderli sempre disponibili. Non è presente nessun sistema RAID, ma la ridondanza viene ottenuta distribuendo in modo intelligente le copie di un oggetto su differenti MicroArray. Ad esempio vi è un sistema di HeartBeat tra i due array di uno stesso chassis, per cui i due server sanno di essere “vicini” ed evitano di salvare le due copie di un oggetto su di essi (tranne quando si parte con soli due MicroArray ovviamente). In questo modo un problema agli alimentatori condivisi di uno chassis non comporta la perdita di dati.
La presenza di duplici copie di ogni oggetto non ha come scopo unico la ridondanza, ma anche le prestazioni. Ad ogni aggiunta di ulteriori MicroArray, gli oggetti presenti vengono pian piano ridistribuiti sui “nuovi arrivati”; il risultato finale è uno storage che possiede una potenza di calcolo complessiva notevole, e le cui prestazioni incrementano in modo lineare all’aggiunta di nodi.
E nonostante ciò, la parte più interessante è questa:
NFS è stato scelto come protocollo unicamente per permettere a questo storage futuristico di parlare con un sistema “legacy” come l’NFS di VMware. Fa senso parlare di VMware come sistema legacy, vero? E tuttavia è vero, dato che usa NFS v3, un protocollo sviluppato oramai 12 anni fa. Se fosse possibile, Coho potrebbe utilizzare meno astrazione, e dialogare con qualsiasi client utilizzando protocolli di più basso livello, magari nativi del singolo applicativo (gli esempi di Mongo e Hadoop della scheda) fino ad ipotizzare come obiettivo ultimo applicazioni capaci di parlare nativamente il linguaggio dell’object storage (“Direct Integration”). Questo non soffrirebbe dei problemi di altri sistemi object (penso ad esempio a Ceph) dove il gateway che traduce il protocollo del client nel linguaggio dell’object store è un’entità separata e unica, e quindi un potenziale collo di bottiglia. Qui ogni MicroArray funge anche da gateway, e tramite SDN tutti sono contemporaneamente attivi; il risultato finale è che i gateway scalano orizzontalmente insieme ai MicroArray.
L’aver disaccoppiato l’object store dai protocolli con cui questo viene esposto all’esterno permette queste cose. E stiamo solo vedendo l’inizio…
Storage Analytics!
Da un gruppo di ricercatori che si è inventato uno storage simile, vi potreste aspettare che tutte le risorse siano state impiegate per realizzare l’architettura, e che la gestione avvenga tramite una complicata riga di comando in puro stile Open Source. E invece no! Coho Data possiede anche un’interfaccia completamente HTML5, semplice da usare, che volutamente espone solo le informazioni che richiedono un intervento dell’utente (un disco rotto, una connessione non funzionante…) lasciando allo storage l’esecuzione di tutti quei task in cui l’utente non è coinvolto. Vi è persino la possibilità di applicare dei TAG alle varie virtual machines ospitate, e esporre i dati di consumo delle risorse suddividendole per tags. Il sistema vi mostrerà un completo sistema di “showback”, utilissimo per fare reportistica ai vari uffici o clienti.
Vorrei però focalizzarmi su una funzione che non ci sarà nella versione 1.0, ma su cui stanno già lavorando e di cui ci è stata mostrata una preview: un completo sistema di analisi dei dati!
Una traccia di un I/O occupa solo 4 bytes, oltretutto comprimibile a 2. Dato che la memoria Flash è molto grande, e non vi è praticamente nessun overhead nel collezionare i trace dell’I/O, Coho Data registra il trace di ogni I/O che va oltre la soglia di allerta (come una telecamera di sorveglianza che registra solo quando vi è movimento), e quando raggiunge la quantità di log corrispondenti alla dimensione di una cella NAND, provvede a salvare in essa questi dati. In seguito, quando il carico sul sistema è meno elevato, provvede automaticamente a effettuare delle analisi su questi dati: da un lato permette di analizzare lo storico dell’I/O, identificando quali specifiche VM avevano rallentamenti, e di che entità. Inoltre, effettua una simulazione “what if” mostrando come l’aggiunta di uno o due ulteriori blocchi varierebbero i risultati.
Si tratta di un vero e proprio sistema di Modeling, che permette di capire PRIMA di comprare un sistema addizionale se questo porterà o meno dei benefici, e di quale entità. E’ la prima volta che vedo in uno storage una funzione simile, e anche durante l’incontro ha lasciato tutti a bocca aperta.
Conclusioni
Devo ammetterlo, mi sono letteralmente innamorato di questa soluzione. L’eleganza nel disegno architetturale e lo studio alla base di ogni scelta fatta non possono non far ammirare questo progetto.
Ovviamente Coho Data è nella sua infanzia, tanto che il prodotto sarà disponibile solo alla fine di Novembre 2013 e sarà un prodotto in versione 1.0, quindi con un set di funzioni “enterprise” limitate (non c’è ad esempio la replica tra cluster o la deduplica) ma con già ad esempio il pieno supporto per le librerie VAAI-NAS di VMware. Molti sviluppi futuri sono stati già definiti, come appunto replica e deduplica; tra questi molto interessante è la possibilità di prioritizzare differenti dati, introducendo quindi una funzione di QoS nel sistema, o di reagire a workload periodici precaricando i dati nelle aree calde dello storage, “anticipando” le mosse dei client tramite gli analytics.
Spero vivamente che i ragazzi di Coho Data abbiano successo, perchè sarebbe un delitto vedere sprecate queste splendide idee. In bocca al lupo!