Solidfire: uno storage “di qualità”

3 Flares Twitter 0 Facebook 0 Google+ 1 LinkedIn 2 Email -- 3 Flares ×

Da quando è uscita dallo stealth mode nel 2009 ho sempre osservato con interesse Solidfire, perchè hanno un prodotto storage veramente particolare, differente da tutti gli altri produttori, e di sicuro interesse per chi come me lavora nell’ambito dei service providers. Alcune settimane fa ho avuto una piacevole chiaccherata con alcuni loro rappresentanti, ed ho potuto finalmente approfondire la mia conoscenza sul loro prodotto.

Nato per i Service Providers

La storia di Solidfire ruota intorno alla figura di Dave Wright, fondatore anni fa di Jungle Disk; un servizio di sync & Share che ho oltretutto utilizzato per diversi anni, e che fu acquistato da Rackspace nell’Ottobre 2008. Potendo lavorare a stretto contatto con un grande provider come Rackspace, ha potuto osservare cosa veniva utilizzato a livello storage, e soprattutto cosa mancava a uno storage per Service Providers.

Solidfire è nato con questo specifico focus: è uno storage di tipo scale-out, nato espressamente per i Service Providers.

SolidFire Scale Out Architecture

La base di partenza è un Block Storage,anche se dal modo in cui si comporta sembrerebbe un Object Storage. Ogni oggetto è salvato 2 volte in parti differenti dello storage, utilizzando un algoritmo di protezione chiamato Double Helix, e vi è una completa separazione tra i dati e i metadati che li referenziano. Partendo da un cluster minimo di 5 nodi, l’architettura è in grado di scalare linearmente per raggiungere valori di spazio disponibile e IOPS veramente elevati, si parla di 3.4 PB e 7,5 milioni di IOPS per il loro modello maggiore, SF9010, in una configurazione a 100 nodi. Ogni nodo è completamente indipendente dagli altri, secondo un altro concetto caro agli Object Storage, ovvero il “Share Nothing”.

I vari nodi sono semplici server 1U su base Dell, dotati ognuno di 10 dischi SSD e due connessioni 10G. La scelta di Dell permette a Solidfire di non doversi preoccupare dell’assistenza hardware, e potersi quindi concentrare sul cuore della soluzione, che come spesso accade è il loro software. Sui server è infatti installato un loro sistema operativo, chiamato Element OS, dove viene eseguito tutto il software sviluppato internamente. Il sistema infine espone verso i server differenti LUN tramite il protocollo iSCSI.

Esistono attualmente tre modelli, denominati SF3010, SF6010 e SF9010. Sono sostanzialmente identici, ma ognuno possiede dischi SSD di dimensioni differenti, rispettivamente 300, 600 o 960 GB ciascuno; il 9010 inoltre ha prestazioni computazionali maggiori. Ad oggi non è possibile mixare differenti modelli nello stesso cluster, ma è una possibilità che sarà introdotta quest’anno. Sicuramente un’aggiunta interessante, per preservare l’investimento di quei clienti che hanno iniziato col modello più piccolo e vorrebbero adesso aggiungere i modelli maggiori.

Questione di OPEX…

E’ indubbio che un Service Provider, nell’offrire servizi ai propri clienti, deve anche essere molto attento all’ottimizzazione dei propri costi. Solidfire è nato come dicevamo specificatamente per questi clienti, e quindi molte delle ottimizzazioni che permette sono rivolte proprio a questa tipologia di clienti. I valori di OPEX (Operational Expenses) indicati da Solidfire vanno tutti in questa direzione.

Innanzitutto, l’enorme capacità di I/O offerta dai dischi SSD non viene unicamente utilizzata per garantire prestazioni stratosferiche. Ogni singolo nodo non offre valori di IOPS esagerati, si parla di un valore compreso tra 50 e 75 mila IOPS. Avendo a disposizione 10 dischi SSD, potrebbero addirittura sembrare pochi. Piuttosto, le prestazioni degli SSD sono la base per garantire gli IOPS e soprattutto la latenza in qualsiasi condizione di esercizio, anche in seguito alla rottura di diversi componenti, dal singolo disco fino a un intero nodo.

L’efficienza economica viene garantita poi da tutta una serie di ottimizzazioni sullo spazio disco. E’ noto che gli SSD hanno un costo per Gb molto più elevato dei dischi meccanici, e inoltre per preservarne la durata è necessario ottimizzarne quanto più possibile le scritture. Innanzitutto, tramite attività di deduplica, ogni volta che un blocco è presente più volte in differenti virtual machines, viene semplicemente registrato il numero di occorrenze del blocco nei metadati e da quali VM è utilizzato, ma su disco vi è solo una copia (più la sua replica). Dopo la deduplica, interviene anche un processo di compressione, e infine tutte le LUN vengono create in formato thin.

Solidfire dichiara a titolo conservativo un guadagno di 2:1 per ognuna di queste ottimizzazioni. Considerando la duplice copia di ogni blocco, lo spazio utile su disco è quindi mediamente 4:1 rispetto a quanto è disponibile, anche se vi sono situazioni in cui questo valore è decisamente migliore, come ad esempio ambienti vCloud in cui vi sia un uso molto spinto dei template e del fast provisioning.

Un successivo risparmio viene da un footprint inferiore all’interno del datacenter: un nodo SF3010 offre 3 TB di spazio, che ottimizzati diventano 12, mentre un modello SF9010 arriva fino a 38. Ciò vuol dire che un intero rack Solidfire da 42U (sempre ammesso che la dispersione termica e soprattutto l’alimentazione elettrica disponibile consentano una tale densità, ma SolidFire mi ha indicato che un cluster di 40 nodi consuma 12KW per i modelli 3010 e 6010, e 18 KW per il 9010) offre tra i 500 TB e 1600 TB di spazio disco. Valori che praticamente nessuno storage basato su dischi meccanici può raggiungere nello spazio spazio rack. Inoltre, la presenza di soli dischi SSD rende lo storage molto efficiente da un punto di vista termico, e quindi porta ulteriori risparmi sui costi di raffreddamento.

Ho un unico dubbio relativamente ai costi di connettività: due connessioni 10G per ogni nodo da 1U sono molte, e il costo delle porte 10G sugli switch non è basso attualmente. Sicuramente la scelta di avere un fault domain così piccolo è utile per ottenere prestazioni scale-out così elevate, ma sicuramente il costo della connettività ethernet è da considerare. Probabilmente, nonostante un costo di acquisto maggiore, la scelta più sensata è puntare oggi da subito sul modello 9010, che permette una densità dati maggiore a pari numero di rack unit e porte ethernet consumate.

Come vedete, sono tutte considerazioni che non si fanno spesso in presenza di storage “classici”, ma che all’interno di un datacenter hanno una notevole importanza.

Un veloce discorso sui costi. Non esiste un listino pubblico, ma un’indicazione generale di “meno di 3 USD per GB”. Basandomi su questi numeri ho provato a fare una simulazione che è stata confermata da Solidfire. Il più piccolo cluster con cui è possibile iniziare è composto da 5 nodi SF3010. Con 10 dischi da 300 GB per nodo, lo spazio totale raw è 15 TB. Applicando il rapporto di 4:1 indicato prima, lo spazio disponibile effettivo è 60TB. A 3 USD per GB, il costo di acquisto del cluster è quindi circa 180.000 USD. I costi reali sono diversi, e calano se si scelgono i due modelli superiori.

In termini di OPEX, questo vuol dire un costo per GB per mese, su tre anni di vita del prodotto, di 8,33 USD. In confronto, Amazon AWS offre i  dischi “Provisioned IOPS” a 12,5, oltretutto con un limite massimo di 4000 IOPS e nessuna chiara indicazione di QoS che garantisca anche valori minimi.

QoS: un’architettura, non una funzione

Solidfire QoS configuration

Sicuramente, la caratteristica più peculiare alla base del progetto Solidfire è il loro sistema di QoS (Quality of Service): a differenza di altri storage, che possiedono alcune funzioni di questo tipo, questo storage è nato con l’idea di offrire queste caratteristiche, dopo aver constatato che uno dei limiti nell’adozione del “cloud computing” anche per applicativi enterprise era proprio la garanzia di prestazioni elevate ma soprattutto predicibili dello storage.

Le configurazioni di QoS di Solidfire vengono applicate per ogni singola LUN che viene configurata: oltre al classico spazio disco, si può definire una policy che comprende:

– IOPS minimi garantiti

– IOPS massimi concessi

– IOPS in burst

L’ultima voce è molto interessante: se un cliente compra come nell’esempio a fianco uno spazio disco con un massimo di 11000 IOPS, ma ne usa per diverso tempo molti meno, accumula IOPS “a credito” che può poi “spendere” per estendere la durata del burst.

Per la mia esperienza, questo è l’unico storage esistente che permette questo tipo di configurazioni. Molti altri prevedono un limite massimo, e una qualche forma di priorità relativa tra le varie LUN, ma nessuno ha un livello di configurazione simile. Per un service provider, questo permette non solo di proteggere i vari clienti dai cosiddetti “noisy neighbors” tramite i Max IOPS, ma soprattutto di poter “vendere” differenti livelli di storage in base ai Min IOPS. Pensando a un sistema basato su VMware vCloud, si possono creare differenti storage profiles, configurati con differenti valori di Min IOPS, e vendere ai clienti questi storage a costi mensili man mano crescenti. Il tutto senza dover implementare e gestire differenti “silos” di storage, ma al contrario incrementando le economie di scala date dall’uso di un unico grande storage.

Solidfire vs Noisy Neighbors

Ad oggi, la granularità del QoS è limitata alla singola LUN, quindi vi è comunque il problema del Noisy Neighbor tra differenti VM presenti nella stessa LUN. Se state utilizzando VMware vCloud con contratti VSPP, quasi sicuramente la licenza vSphere in uso è la Enterprise Plus, e quindi potete implementare SIOC (Storage IO Control) e farlo lavorare in modo congiunto con il QoS di Solidfire.

Per quanto riguarda infine l’ulteriore integrazione con VMware, lo storage supporta alcune primitive VAAI, ma non possiede ad oggi un SATP (Storage Array Type Plugin) proprietario, ma si affida unicamente al Round Robin nativo di ESXi.

Per quanto riguarda SRM invece, ad oggi non è supportato. E’ prevista l’introduzione della replica asincrona, base necessaria per supportare in seguito SRM.

La gestione? API!

Tutto il sistema è gestibile tramite API, sia in modo nativo, sia tramite alcune interfacce che si relazionano poi con le API stesse. Anche questa è una scelta che può sembrare strana, e lo era sicuramente ancora di più quando questo prodotto è stato introdotto alcuni anni fa. Ma ancora, il focus sui service provider fa si che certe scelte architetturali risultino corrette: in ambienti dove tutto è quanto più automatizzato e la quantità di oggetti da gestire può essere molto elevata, è impensabile perdere ore e ore sull’interfaccia grafica, è molto meglio utilizzare le API presenti per automatizzare quanto più possibile.E’ disponibile comunque un plugin per vCenter, così come un’interfaccia nativa via web. Entrambe in realtà non sono altro che interfacce che si collegano all’unico “vero” metodo di gestione di questo storage, ovvero le sue RESTful API.

Note finali

Solidfire è uno storage estremamente interessante, molto focalizzato sui service provider, ai quali ai quali permette di garantire ai clienti livelli di servizio certi e misurabili. Possiede numerosi clienti, alcuni indicati pubblicamente sul loro sito web, e anche alcuni clienti enterprise.

Per il futuro, alcuni limiti come ad esempio il QoS applicato alla singola LUN potranno essere rimossi, e permettere una granularità del QoS ancora maggiore. Questo grazie soprattutto all’introduzione da parte di VMware dei vVols. Con essi, anche su storage di tipo block si potrà ragionare a livello di singola VM piuttosto che di intera LUN come già è possibile con NFS. Solidfire ha realizzato questo interessantissimo video che ne mostra il funzionamento con il loro storage. Avete notato ESXi 6.0? 🙂

3 Flares Twitter 0 Facebook 0 Google+ 1 LinkedIn 2 Email -- 3 Flares ×