Storage per la Virtual Desktop Infrastructure (VDI)
Il vantaggio è che i desktop virtuali sono indipendenti dall’hardware e quindi accessibili da qualunque sistema operativo (OS). È anche molto più facile implementarli, assicurando agli utenti la libertà che desiderano. E grazie al single-user OS, la compatibilità applicativa non è un problema.
Tuttavia, quando si implementa un’infrastruttura VDI è necessario indirizzare alcuni elementi. Innanzitutto, il calcolo TCO/ROI potrebbe non essere semplice come alcuni sostengono. Inoltre, l’impatto delle performance sulle applicazioni, in particolare quelle multimediali e 3D, deve essere analizzato. Infine, non dimentichiamoci degli aspetti legati al licensing, che possono rappresentare un fattore determinante in ambito VDI.
Mentre il desktop computing centralizzato offre importanti vantaggi, tutte le risorse si riuniscono nel data center. E questo significa che CPU, memoria, networking e dischi devono essere gestiti da un unico punto – l’infrastruttura virtuale. Il beneficio è che, se dimensionata correttamente, quest’ultima è più flessibile in termini di consumo di risorse rispetto al computing decentralizzato. È anche maggiormente in grado di gestire i picchi di lavoro dato che avvengono saltuariamente su un numero limitato di sistemi nel data center. Ma cosa succede se i picchi sono costanti e le medie sono così elevate che il costo di facilitarle è sproporzionato rispetto a quello di un sistema decentralizzato?
Apparentemente c’è un’insidia che si nasconde nel VDI, si chiama “IOPS”.
IL CLIENT
Un client fisico con Windows dispone di un disco locale che di solito è SATA e gira a 5.400 o 7.200 RPM, fornendo da 40 a 50 IOPS. Quando si avvia, il client carica sia l’OS sia diversi servizi, molti dei quali forniscono funzionalità che potrebbero essere richieste dal sistema fisico, semplificando la vita all’utente. Ma quando il client è virtuale, molti di questi servizi sono superflui o addirittura controproducenti. L’indicizzazione, i servizi hardware (wireless LAN), prefetching e altri producono molti IOPS nel tentativo di ottimizzare la velocità di caricamento, attività utile sui client fisici ma totalmente inutile in ambiente virtuale.
L’elemento più sorprendente è che la maggior parte di questi IOPS sono WRITE, dove il rapporto read/write si ritiene sia, percentualmente, di circa 90/10. Ma in realtà gli utenti utilizzano dozzine o addirittura centinaia di diverse applicazioni, virtuali o installate. In pratica, il rapporto read/write risulta al massimo pari a 50/50! Attestandosi in generale intorno a 30/70, o anche 20/80 e a volte 10/90. Ma perché è importante?
BOOT E LOGON
Quando si adotta un’infrastruttura VDI, essa deve essere ottimizzata per IOPS. Ha quindi senso accendere in anticipo e in maniera sequenziale le machine che verranno impiegate un determinato giorno prima che gli utenti inizino a utilizzarle. D’altra parte, il 90-95% degli IOPS in fase di boot sono read. Se si dispone di una cache sufficientemente ampia o dedicata a catturare le operazioni di lettura del sistema operativo, lo stress sullo storage è minimo. Se progettato correttamente, l’impatto dei boot storm sull’infrastruttura Virtual Desktop può essere drasticamente ridotto o addirittura azzerato nelle ore di produzione.
I logon storm sono tutt’altra cosa. L’impatto sugli IOPS quando un utente effettua il logon dipende molto dal modo in cui profili e policy sono configurati e come le applicazioni vengono fornite. La soluzione sta nell’ottimizzare l’immagine della Virtual Machine (VM) ma anche la gestione dello user environment. Tuttavia, se tutti gli utenti iniziano a lavorare contemporaneamente, è necessario un numero sostanzialmente più elevato di IOPS (e storage) per accomodarli rispetto a quando i logon sono distribuiti su diverse ore. L’unico modo per farlo a dovere è sapere quando gli utenti effettuano il login.
Oltre al login, c’è un terzo elemento di cui tenere conto: il primo avvio di un’applicazione. I primi minuti dopo il logon, le applicazioni si avviano per la prima volta. In questa fase il rapporto read/write è di circa 50/50, dopodiché le operazioni di lettura scendono, mentre i write restano uguali. Questo significa che pochi minuti dopo il login, il rapporto read/write passa da 50/50 a 20/80, che è quello che si verifica in produzione. I primi scendono e i secondi no, ma sono le operazioni di scrittura a creare problemi.
CACHE
Vi sono molte soluzioni che promettono di velocizzare in modo significativo lo storage.
Mentre il modo in cui la cache viene utilizzata è diverso in base a vendor e soluzione. La maggior parte ha una percentuale fissa di cache dedicata alle scritture, e questa write cache è generalmente più piccola rispetto a quella dedicata alle operazioni di scrittura.
Il punto è che quando il numero di write rimane sotto a un determinato livello, la maggior parte di esse è gestita dalla cache. Ed è veloce. Molto più veloce che per le read. Questa cache è, tuttavia, solo una soluzione temporanea per gestire i write I/O occasionali. Dato che, con la VDI, la maggior parte degli I/O sono write, non possiamo assumere che la cache si occupi di risolvere i problemi di scrittura in input o output, e avremo bisogno del giusto numero di dischi per gestirli.
SSD
I dischi a stato solido (SSD) sono in realtà solo più grandi dei memory stick (in alcuni casi poco di più) piuttosto che veri e propri dischi. Il vantaggio è che sono in grado di gestire un’enorme quantità di IOPS; a volte addirittura 50.000 o 100.000. Non hanno parti mobili, di conseguenza l’accesso richiede pochi microsecondi, invece che millisecondi. Inoltre, i consumi equivalgono a una frazione di un disco meccanico a rotazione. Un array di dischi SSD utilizza solo poche centinaia di Watt, mentre quelli tradizionali possono arrivare a diverse migliaia.
Vi sono due tipologie di memorie flash: NOR e NAND. Nelle prime, ogni bit è indirizzabile separatamente ma le write sono molto lente. Le memorie NAND sono molto più veloci e, poiché richiedono meno spazio per cella di memoria, offrono una densità superiore alle memorie NOR. Sono anche molto più economiche. L’aspetto negativo è che si possono indirizzare solo blocchi di celle, ma per i dispositivi basati su blocchi, come i dischi SSD, vanno benissimo.
Attualmente i dischi SSD sono molto più costosi di quelli fiber channel e la maggior parte dei vendor non ne garantisce una durata di molteplici anni con un profilo I/O come quello della VDI. Ma i miglioramenti nelle celle SSD sono costanti. Con un rapporto read/write più equilibrato, una durata più lunga, dischi più capienti e un costo più contenuto, riteniamo che i dischi SSD diverranno sempre più comuni nelle Storage Area Network (SAN).
CONCLUSIONI
È ormai ovvio che calcolare la quantità di storage necessario per ospitare una VDI in maniera corretta non deve essere sottovalutato. L’ostacolo principale al momento sono gli IOPS. Il rapporto read/write che si vede nella pratica mostra valori percentuali quali 40/60, a volte addirittura 10/90, e tutti registrano più scritture che letture. E poiché le write sono più costosi delle read – su qualunque sistema storage – il numero di dischi necessari aumenta di conseguenza, in base all’uso degli utenti e all’applicazione.
Infine, è fondamentale effettuare un progetto pilota. Utilizzare applicazioni reali con utenti effettivi in produzione, per sapere in anticipo: come si comportano e il rapporto read/write generato. Altrimenti tutti si lamenteranno, e il progetto VDI fallirà.
