Sono stato invitato a partecipare in qualità di delegato allo Storage Field Day, nella sua quarta edizione in quel di San Josè, California. Il primo produttore che abbiamo incontrato è stato CloudByte.
Chi è CloudByte
CloudByte è una società mista indiana e americana, con uffici a Bangalore e a Cupertino (California). Il loro prodotto principale è ElastiStor: è una soluzione completamente software che trasforma uno normale server dotato di storage locale (o collegato a uno storage remoto) in uno storage array. Differenti macchine con ElastiStor installato vengono combinate tra loro per creare uno storage distribuito, di tipo scale-out.
L’idea di creare uno storage distribuito basandosi su hardware commodity che viene aggregato con una soluzione completamente software non è nuova, ma CloudByte ha aggiunto alcune soluzioni nel loro prodotto pensate specificatamente per i Service Providers. Soprattutto, il concetto di QoS (Quality of Service) per i vari workload che vengono caricati ed eseguiti su uno storage.
Il concetto di “predictable performance” è il terrore di ogni Service Provider: a differenza di un’infrastruttura aziendale, dove un amministratore ha (più o meno) il controllo dei vari workload, un Service Provider non sa cosa i propri clienti eseguiranno sulle virtual machines che hanno comprato. Gestire quindi uno storage distribuito e assicurare ad ogni cliente le prestazioni che richiede, è una sfida difficile da affrontare. Solitamente, la soluzione più facile è fare over-provisioning: nel dubbio di avere in futuro problemi di prestazioni, si disegna uno storage con prestazioni maggiori di quelle necessarie, per evitare picchi di richieste che potrebbero mettere in crisi il sistema. Ma questo ovviamente è economicamente inefficiente per un Service Provider.
A morte i “vicini rumorosi”!
Il concetto di “noisy neighbours” è ben noto agli amministratori di storage in ambiente virtualizzati. Un singolo workload che richiede un numero elevato di IOPS può mettere in crisi tutti gli altri workload ospitati sullo stesso storage. E ne parlo per esperienza, può anche essere un semplice cliente di un service provider che per scoprire le performance dello storage su cui è ospitato esegue programmi di test come IOmeter…
CloudByte si basa su TSM, acronimo che ricorda molto IBM, ma che in questo caso sta per Tenant Storage Machine. Si tratta di un container logico al cui interno vengono definiti i parametri da assegnare a un cliente, sia in termini di capacità (ma questo lo si fa già con altri storage) ma soprattutto di performance. TSM prende per prima cosa una parte dello storage sottostante, che è composto da tutti i dischi e le memorie Flash presenti nei vari ElastiStor che formano i cluster o pool. Lo storage viene gestito tramite il filesystem ZFS, e infatti il sistema operativo su cui è basato ElastiStor è FreeBSD.
Ogni TSM può gestire differenti volumi, e questi vengono esposti al singolo tenant tramite uno dei multipli protocolli disponibili: NFS, iSCSI, SMB o FC. Ogni TSM può essere dinamicamente riallocato in differenti parti dello storage, e si può anche muovere completamente un TSM tra differenti HA-groups (questo assomiglia molto a una Storage vMotion di VMware…).
Infine, vengono applicate le regole QoS che sono state definite: si tratta sostanzialmente di impostare un limite in termini di IOPS per ogni singolo volume che viene creato. Il sistema poi provvede a misurare in tempo reale valori di throughput, IOPS, latency e molti altri. Se uno di questi valori raggiungere i limiti impostati, le prestazioni vengono limitate applicando un vero e proprio filtro. Si può anche impostare una latenza, ma questo è più che altro un valore desiderato. In caso si voglia in seguito modificare questo valore, potrebbe capitare che il TSM venga “migrato” su un altro pool che possa offrire le prestazioni desiderate. Questa attività ovviamente ha un costo in termini di IOPS stessi, quindi ci si potrebbe ritrovare in un dato momento a peggiorare le prestazioni del volume mentre questo viene mosso su un pool più performante.
Sono stato molto interessato a un approfondimento sul QoS: ad oggi, prevede unicamente un limite superiore al valore di IOPS che si può definire. E’ sicuramente una funzione differenziante rispetto a molti altri storage, ma penso (e ho fatto presente) che si può fare di più.
Mi metto nei panni di un Service Provider: un limite superiore è sicuramente utile per limitare l’accesso contemporaneo allo storage, ma non è una funzione “vendibile” ai clienti. Questi sono molto più interessati a un valore minimo garantito, che non venga violato quale che sia il carico complessivo sullo storage. Pertanto, va benissimo avere un limite superiore di IOPS, ma ben vengano in futuro anche impostazioni di IOPS minimi garantiti, e visto che si parla sempre di differenti workload in esecuzione sullo stesso storage, anche la possibilità di prioritizzare alcuni workload rispetto ad altri.
Aggiungo poi una mia idea personale: dato che uno dei casi d’uso per questa tecnologia sono i Service Providers, si potrebbe delegare la gestione di un TSM al singolo cliente cui è assegnato. Ad esempio, parlando di IOPS, un cliente potrebbe richiedere 5000 IOPS complessivi sui propri volumi; il Provider provvederebbe a configurare in questo modo il TSM del cliente. Quest’ultimo in seguito potrebbe ulteriormente segmentare il proprio TSM in differenti volumi, ognuno dei quali potrebbe avere differenti parametri di QoS. Basterebbe garantire che il valore complessivo di IOPS dei vari volumi non sia superiore al valore complessivo assegnato (e venduto!) al cliente. Stesso discorso per gli IOPS minimi garantiti e la prioritizzazione.
Un altro aspetto interessante, ma che penso vada migliorato, è come vengono misurati gli IOPS. Fondamentamente, non vi è un vero e proprio test per campionare dei valori, ma il sistema vedendo la tipologia di dischi presenti, le configurazioni di memoria e molti altri parametri, definisce un valore iniziale. Un amministratore può in seguito variare questo valore. L’approccio nel definire questi valori è giustamente conservativo, ma anche qui in futuro mi aspetto un vero sistema di testing delle prestazioni, da eseguire magari in background, oppure una sorta di “burn-in” test prima che un nuovo nodo venga aggiunto a un cluster. Questo è un pò il limite delle soluzioni unicamente software, ovvero non avere il controllo dell’hardware sottostante che il cliente decide di utilizzare.
Note Finali
Ci sono senz’altro alcune buone idee nel prodotto di CloudByte.
Le principali funzioni che potrebbero ulteriormente distinguerlo tuttavia penso debbano essere ulteriormente sviluppate. Ad esempio, si parla di un sistema scale-out che tuttavia ad oggi è limitato a solo 4 nodi, ragion per cui la definizione stessa di scale-out è un pò forzata: è vero che non vi è una cache condivisa e ogni nodo è indipendente, ma esistono anche storage “classici” che possono scalare ben oltre questi numeri.
Inoltre, da un sistema QoS mi aspetto anche la possibilità di definire soglie minime e non solo massime, e di poter gestire la priorità tra i vari workload. Vedremo nelle prossime versioni se verranno superati questi limiti e il prodotto introdurrà ulteriori funzioni.