Uno storage totalmente ideato sui dischi SSD, con un’architettura scale-out e funzionalità software dell’ultima generazione pensato esclusivamente per i Cloud Service Provider: più radicale di così non si può!
Un approccio così radicale (e affascinante) che però nasconde qualche rischio.

Chi è Solidfire

Solidfire è una startup che sta sviluppando un sottosistema SSD particolarmente indicato per il mercato dei service provider. L’obiettivo della compagnia, che fra i suoi fondatori può contare persone che vengono da esperienze proprio in questo settore, è quello di fornire una piattaforma di nuova generazione per rispondere alle problematiche che stanno affrontando i cloud provider. L’azienda è finanziata molto bene da alcuni VC americani e sta concludendo il beta testing della piattaforma che sarà presto disponibile sul mercato.

Prestazioni e scalabilità radicali

Ovviamente un array basato tutto su dischi SSD (di tipo MLC in questo caso) non può che avere prestazioni strabilianti. Infatti, già per la configurazione minima si parla di 50.000 IOps (in teoria, una configurazione a 100 nodi può raggiungere i 5 milioni di IOps). Non parlo quindi, come spesso capita di vedere, di un array tradizionale riempito di dischi SSD (limitato sia nella capacità di calcolo che nel backend) ma di un oggetto capace di sprigionare numeri da capogiro.

Infatti, l’architettura di Solidfire è di tipo Scale-out (praticamente è un cluster di nodi indipendenti, interconnessi ad alta velocità, che agiscono all’unisono). Ogni nodo ha potenza di calcolo (CPU x86), 12 HD SSD da 2,5″, 2 porte 10GBe e 2 da 1GBe. La configurazione più piccola è a tre nodi, poi si può crescere un nodo alla volta praticamente senza limiti.
Il sistema propone un solo tipo di protocollo verso gli host: iSCSI, ovviamente scelto sia per la semplicità di utilizzo ma anche per l’ambiente in cui viene principalmente proposto (CSP/ISP). Vista la natura dell’hardware usato, server x86 standard, non sarà difficile aggiungere diversi tipi di connessione in futuro se sarà necessario.
In pratica non esistono limitazioni pratiche come numero di volumi gestiti (LUN), quantità di dischi supportati, numero di porte di frontend e backend, ecc.: il tutto si riduce a quanti nodi sono necessari per supportare le richieste del Frontend e, purtroppo, al budget che si ha disposizione.

Efficienza radicale

La grande potenza di calcolo messa a disposizione dalle CPU x86 e l’uso dei dischi SSD ha permesso a Solidfire di sviluppare una serie di funzionalità decisamente interessanti che rendono questo sosttosistema di storage particolarmente efficiente e sicuramente più conveniente di quanto ci si potrebbe immaginare.
Gli SSD hanno un costo che, ancora oggi, è proibitivo. Infatti, la maggior parte delle implementazioni tradizionali prevede un piccolo numero di dischi (di solito SLC) che vengono usati come cache o per gestire i dati più frequentemente acceduti (automated tiered storage). Solidfire, invece, ha deciso di implementare tutte le tecnologie possibili per aumentare al massimo efficienza e utilizzazione delle risorse: wide striping, thin provisioning particolarmente granulare (in blocchi da 4KB), compressione, deduplication on-line e snapshot di tipo redirect-on-write. Quanto sopra ha permesso l’utilizzo di una tecnologia SSD più economica (MLC).
Le slide che sono state mostrate durante la demo sono sicuramente interessanti e mostrano che i risparmi pratici in quantità di risorse disco posso essere molto sensibili.
La combinazione delle tecnologie software e di un hardware comodity ha permesso a Solidfire di creare un sistema molto performante e relativamente accattivante dal punto di vista del prezzo: i rappresentanti di solidfire sono convinti di poter dimostrare che il costo per GB del loro array è paragonabile, nella peggiore delle ipotesi, con quello degli storage tradizionali ma che è decisamente migliore quando si parla di grandi installazioni.

SLA radicale

Quando parliamo di storage per service provider la prestazione è solo uno degli argomenti, l’altro è il multitenant. In particolare, nel caso di Solidfire, la granularità e il controllo delle prestazioni da erogare è molto elevata. Si può persino controllare la qualità dell’accesso al singolo volume e regolarla per gestire anche eventuali picchi momentanei. Questa granularità diventa indispensabile quando si parla di sistemi che devono gestire migliaia o decine di migliaia di VM.
Lo SLA non è misurabile sono in uptime ma anche in qualità della risposta, soprattutto in ambienti cloud (e ancora di più quando ci si rivolge alle imprese) questo diventa fondamentale.

Management radicale

Solidfire è radicale anche qui, non esiste una interfaccia di gestione “umana”: non è assolutamente prevista una GUI e neanche una CLI, l’accesso al sistema è consentito solo via APIs!
Per quanto quello che ho appena scritto può sembrare assurdo, è la realtà e la spiegazione è tanto semplice quanto disarmante. In un ambiente in cui, potenzialmente, sono ospitate decine di migliaia di Virtual Machine, più le relative snapshot, regole di QoS, ecc., ecc. non si può pensare ad management tradizionale: tutto deve essere integrato con la piattaforma che sovrintende alle operazioni!
In pratica Nimble, oltre a pubblicare tutte le API, supporta direttamente le diverse piattaforme cloud più importanti (Vmware, Openstack, Eucalyptus, Cloud.com). 
Nel costo di implementazione di questo array è necessario includere anche l’attività di integrazione con la piattaforma cloud che si andrà ad utilizzare, non proprio un approccio plug-and-play.

Nota finale

Devo dirlo, il prodotto mi ha colpito! Purtroppo però devo anche aggiungere che, per quanto possa avermi impressionato ha dei lati oscuri da non sottovalutare.
Prima di tutto, è orientato ad un mercato limitato, dai grandi numeri, ma limitato: questo significa che se il prodotto (e l’azienda) non incontrerà il favore dei grandi CSP/ISP è destinato ad una vita breve.
Secondo, ma non meno importante, è relativamente immaturo: mancano funzionalità di replica (previste per Q3-2012) e i rischi di dover accedere solo via API può innescare diverse criticità dovute al fatto della necessità di sviluppare e mantenere del software e le relative integrazioni con altri prodotti!

Alcuni aspetti di questa architettura sono affascinati e spero che l’azienda, in futuro, spenda qualche risorsa per attaccare anche il mercato enterprise.

Disclaimer: Sono stato invitato a questo meeting da Condor Consulting Group e loro hanno pagato per il viaggio e l’alloggio. Non sono stato ricompensato in alcun modo per il mio tempo e non sono in obbligo di scrivere articoli. In ogni caso, i contenuti di questi articoli non sono concordati, rivisti o approvati dalle aziende menzionate o da altri al di fuori del team di juku.