Lo scorso lunedì ho avuto un brief con un paio di executive di Virsto e vi riporto qualche pensiero su quello che ho appreso durante quell’incontro.
Virsto è una piccola (28 dipendenti) startup americana, ben finanziata, fondata 5 anni fa nella Silicon Valley. Questa azienda sviluppa una soluzione che ha l’obiettivo di virtualizzare l’accesso ai dischi fisici di una infrastruttura virtualizzata permettendo un importante aumento di prestazioni
Al momento, come tanti altri, anche Virsto sta usando un messaggio marketing per cui si definiscono l’azienda che ha inventato “lo storage hypervisor” ma, a parte il marketing, penso che questi signori qualche cosa da dire ce l’abbiamo.
Il problema
I server (decisamente potenti) dell’ultima generazione hanno incrementato sensibilmente il rapporto di consolidamento fra server fisici e server virtuali ospitati al loro interno. Questo ha creato un problema sullo storage: i differenti workload generati dalle diverse VM vengono tutti mischiati fra di loro sui canali fisici dello storage creando un effetto che viene chiamato “I/O Blender” (letteralmente: “frullatore di I/O”).
In pratica L’I/O Blender è un problema molto grave perché si è costretti ad operare con un workload 100% random con blocchi di dimensione variabile (il peggiore possibile), situazione che può impattare pesantemente sulla infrastruttura sottostante. La cache si “avvelena” e diventa quasi inutile, le latenze crescono e, di conseguenza, anche le CPU dei server ne soffrono per via dell’I/O wait che si genera. Quando si verificano questo tipi di problemi l’unica soluzione, con un array tradizionale, è quella di acquistare altri dischi meccanici (per aumentare le IOPS). L’altra faccia della medaglia è che diminuisce l’efficienza del sistema in termini di utilizzo delle risorse ma anche un aumento del TCO in generale.
La soluzione Virsto
Il prodotto di Virsto si presenta come un VSA (Virtual Storage Appliance) su ogni host ESXi o Hyper-V che pubblica dei volumi chinati vDisk. I vDisk, accoppiati ad un meccanismo di logging, lavorano come dei collettori di IO. In pratica il loro lavoro è quello di collezionare le IO e riorganizzarle in grandi scritture sequenziali ottenendo il massimo throughput (con il minimo sforzo) dall’array fisico! L’idea è ottima e l’implementazione sembra sufficientemente trasparente da non impattare troppo sul lavoro quotidiano di chi gestisce l’infrastruttura. Ovviamente, Virsto, porta con se altre funzionalità come il thin provisioning, le snapshot di tipo pointer-based, una forma di automated tiereing (tutte funzionalità che in realtà si trovano anche su storage dell’ultima generazione). In termini di utilizzo di risorse e di performance il vantaggio può essere considerevole (loro parlano di miglioramenti fino a 10x), specialmente in ambiente particolarmente densi come potrebbero essere quelli di tipo VDI (infatti, se ricordo bene, la prima versione del prodotto era particolarmente orientata a questa problematica).
Nota finale
Questo prodotto, in alcune infrastrutture, può essere una degna risposta al problema che ho descritto ma ho anche dei dubbi: il primo riguarda sicuramente il fatto che si parla di un altro strato di software da aggiungere fra storage e hypervisor, e come tale va gestito e mantenuto (ad esempio: solo la prossima versione, in uscita fra 6 mesi, sarà compatibile con vSphere 5). Il secondo dubbio riguarda il fatto che questo prodotto aggiunge un sacco di buone funzionalità alla piattaforma di storage che c’è in essere ma è vero anche che ciò renderà impossibile usare quelle già presenti. Inoltre, se deciderò di comprare un nuovo storage di prossima generazione (magari con dei dischi SSD integrati come cache o tier 0), alcuni dei vantaggi di questo prodotto potrebbero sparire velocemente.
Vorrei verificare l’esistenza di prodotti simili anche per altri hypervisor, tra cui KVM
Gianluca,
purtroppo il mercato degli HV (nel senso dove ci sono le aziende che spendono soldi) è fatto da Microsoft e VMware, sarà dura vedere soluzioni di questo tipo per ambienti tipo Xen (ormai uno zombie) e KVM (in ascesa ma principalmente dagli ISP).
E’ più probabile che il problema, per KVM ad esempio, lo devi risolvere con storage più sofisticati (e quindi più costosi) di quelli tradizionali. Però rimane un cane che si morde la coda visto che chi adotta KVM lo fa anche (solo?) per risparmiare sul costo delle licenze e del supporto. 😉
ciao,
E
Vorrei verificare l’esistenza di prodotti simili anche per altri hypervisor, tra cui KVM
Gianluca,
purtroppo il mercato degli HV (nel senso dove ci sono le aziende che spendono soldi) è fatto da Microsoft e VMware, sarà dura vedere soluzioni di questo tipo per ambienti tipo Xen (ormai uno zombie) e KVM (in ascesa ma principalmente dagli ISP).
E’ più probabile che il problema, per KVM ad esempio, lo devi risolvere con storage più sofisticati (e quindi più costosi) di quelli tradizionali. Però rimane un cane che si morde la coda visto che chi adotta KVM lo fa anche (solo?) per risparmiare sul costo delle licenze e del supporto. 😉
ciao,
E