Vedi il blog post originale
Lo scorso settembre ho scritto un articolo per descrivere una soluzione che avrei voluto vedere, ma che in realtà non esisteva: la possibilità di avere una VDI con lo storage locale "virtuale". In pratica avevo sottolineato il perché non mi piacessero le SAN per le VDI e avevo scritto quanto sarebbe stato bello avere una specie di software in grado di virtualizzare l'accesso ai dischi fissi locali all'interno di un server host VDI. Stavo pensando a una soluzione che fosse in grado di mettere insieme il meglio dei due mondi: uno storage veloce e flessibile senza gli spaventosi costi di una SAN.
La nuova funzione "IntelliCache" presente in XenServer 5.6 SP1 va in questa direzione, anche se per ora funziona solo con le immagini disco condivise (mentre la maggior parte delle attuali soluzioni VDI utilizza dischi persistenti).
In un nuovo white paper realizzato da DataCore (collegamento diretto al PDF), la società dichiara che la sua soluzione software SANmelody che gira su un host VDI soddisfa le mie fantasie sullo storage. E dichiara inoltre di farlo con una completa ridondanza multi-server al costo di meno di 70 dollari per utente (ovvero 70 dollari per tutto quello che serve: l'host delle VM, il software SANmelody, i dischi necessari per lo storage… tutto!).
I lettori abituali sanno che di solito non ripubblico documenti realizzati da aziende produttrici. In questo caso, però, il documento di DataCore (scritto da Ziya Aral & Jonathan Ely) è davvero molto, molto valido. Gli autori parlano dello storage VDI senza preconcetti e validano la loro architettura usando strumenti standard come il benchmark VSI di Login Consultants.
Dal documento: Precedenti pubblicazioni avevano indicato configurazioni che, per abbattere i costi di questi controller, utilizzavano migliaia di VD. Leggendo tra le righe, è evidente come i costi hardware per ogni VD crescano rapidamente mano a mano che la configurazione viene scalata verso il basso. Ed è ovvio che le configurazioni VDI più piccole sono anche quelle più importanti dalla maggior parte dei punti di vista pratici. D'altro canto, la configurazione di cui si parla in questo report può comunque essere scalata verso l'alto, in modo lineare, fino a migliaia di Virtual Desktop, eliminando quindi configurazioni molto ingombranti create per cercare quei "punti perfetti" artificiali in cui i costi risultano ottimizzati.
Poi continuano:
Il problema nell'adozione del Virtual Desktop è che le SAN vengono spesso implementate utilizzando enormi e costosi controller per lo storage abbinati a complesse reti esterne per l'archiviazione. Anche se questi strumenti offrono il vantaggio di una ragionevole scalabilità, introducono però una forte barriera di costo nell'adozione della VDI. Per superare questo ostacolo, i fornitori di hardware pubblicano dati riferiti a implementazioni che includono da mille a diverse migliaia di VD.
Molte aziende, comprendendo i benefici potenziali di questa tecnologia, stanno implementando programmi pilota o stanno cercando di integrare un'iniziale adozione di Virtual Desktop nelle strutture esistenti. Se la granularità di queste implementazioni fosse nell'ordine delle migliaia, gli utenti verrebbero obbligati a consumare non solamente una "pagnotta", ma un intero panificio in un unico pasto… senza nemmeno avere il tempo di capire se il pane è buono. L'alternativa è altrettanto poco appetibile. L'utente "stringe i denti" e accetta di affrontare la barriera formata da costi e complessità di un'intera SAN dedicata pur utilizzando un numero non ottimale di Virtual Desktop. In questo modo, il costo per desktop dell'implementazione diventa molto più elevato rispetto a quello che si sarebbe registrato mantenendo il "vecchio schema" dei singoli desktop. E in pratica si ottiene l'effetto opposto di quello cercato con l'introduzione di una nuova tecnologia per il 'risparmio dei costi', come ha notato un crescente numero di blogger dallo spirito concreto.
Gli autori offrono una panoramica del loro scenario di test, partito con due server identici ognuno dei quali configurato per ospitare 110 desktop virtuali. Ogni server aveva cinque drive: uno di avvio e due coppie di pool a due dischi controllate da DataCore, una delle quali utilizzata come storage del server e la seconda usata come mirror di backup dell'altro pool. Per avere una base di partenza più semplice possibile sono stati usati dei comuni drive SATA:
Siamo restii a utilizzare componenti che non siano prodotti SATA standard facilmente configurabili. SAS, Fibre Channel, periferiche veloci, dischi ibridi e SSD hanno un loro ruolo specifico e sono ideali per offrire prestazioni superiori a quelle di SATA. L'inserimento di questi dispositivi in una configurazione di riferimento, però, avrebbe lo stesso effetto di realizzare un'architettura VDI intorno a uno specifico tipo di batteria di storage. Un'ottimizzazione di questo genere creerebbe solo confusione: non solo si renderebbe difficile la comparazione, ma questo porterebbe a una sorta di intrusione da parte di una specifica architettura hardware in ambiti nei quali le protagoniste dovrebbero essere le caratteristiche proprie della VDI.
L'hardware che hanno utilizzato è costato 3.848 dollari per server (circa 35 dollari per utente), con un prezzo complessivo che arriva a circa 67 dollari per utente tenendo conto anche del software DataCore. Gli autori hanno spiegato:
La principale innovazione nei risultati di questo benchmark è l'utilizzo del sistema di virtualizzazione dello storage di DataCore sulle stesse piattaforme hardware utilizzate per ospitare i Virtual Desktop. Mentre il comune buon senso suggerisce che il software DataCore potrebbe trasformarsi in un concorrente a caccia delle stesse scarse risorse della piattaforma hardware, come la memoria e la CPU, numerosi esperimenti hanno dimostrato esattamente l'opposto. In ogni caso, configurazioni come quella utilizzata hanno facilmente offerto prestazioni superiori rispetto a quelle dotate di storage esterno.
Retrospettivamente, i motivi sono semplici da individuare. L'applicazione Virtual Desktop non fa un uso particolarmente intenso dell'I/O e dimostra di essere facilmente supportata da DataCore a prezzo di un numero molto limitato di cicli della CPU. L'eliminazione della maggior parte del traffico di canale esterno contribuisce a ridurre ulteriormente questa attività. In cambio, i tempi di latenza del blocco di cache in pratica spariscono, così come i sovraccarichi di canale e i tempi di latenza dell'I/O. SANmelody residente si "ripaga" da solo, senza perdere nulla sul fronte delle funzionalità o della portabilità.
Anche se la piattaforma di test è stata limitata a due server, è possibile scalare verso l'alto adottando una topologia "a stella". L'idea è che si continuino a utilizzare dischi locali degli host VDI (ognuno dei quali dotato di software DataCore) come storage primario, e che l'hub centrale nella topologia a stella contenga una replica sincronizzata continuamente di ogni host VDI, garantendo così che nessun dato venga perso nel caso in cui si verifichi un problema a uno degli host (e se c'è bisogno di elevata disponibilità estrema basta tenere a portata di mano un host VDI di riserva che può temporaneamente avviare le VM dal pool di storage dell'hub centrale). Gli autori hanno anche sottolineato un altro vantaggio dell'utilizzo dello storage locale, dicendo che "questi tipi di configurazione … sono intrinsecamente "auto-regolanti". Ogni volta che viene aggiunto un gruppo di Virtual Desktop, lo stesso avviene con l'infrastruttura di storage necessaria a supportarli."
Gli autori DataCore sono consci di quanto sia differente questo approccio rispetto alle tipiche architetture di storage per le VDI:
Complessivamente, l'architettura sottoposta a test è differente rispetto alla maggior parte di quelle utilizzate a questo scopo da altri fornitori di storage. Invece di realizzare una configurazione VDI intorno a un controller per lo storage o a un'architettura SAN pre-esistente, prevede che la SAN sia realizzata intorno agli stessi server della VDI.
Infine, hanno preso in giro la combriccola degli "smanettoni" (per altro includendosi nel gruppo), sostenendo che non esiste "trucchetto" che sia in grado di migliorare il rapporto prezzo/prestazioni di un tipico ambiente VDI quanto la loro soluzione per lo storage virtuale:
Migliore sfruttamento della memoria, hardware più avanzato e vari "trucchi" per l'ottimizzazione offrono i risultati desiderati. L'incremento di costi e complessità, però, porta a un sistema che è solo leggermente migliore in termini di rapporto prezzo/prestazioni rispetto a quello testato qui. Noi "vecchi smanettoni" dobbiamo purtroppo prendere atto del fatto che la configurazione testata è sufficientemente ottimizzata per superare la barriera che porta a una VDI pratica da gestire e che piccole ottimizzazioni di basso livello possono portare solamente a piccoli miglioramenti.
Devo proprio ammettere che questo è uno dei migliori documenti aziendali che io abbia letto da molto tempo a questa parte. Voi che cosa ne pensate? Ci sfugge qualcosa?
