This post is also available in: Inglese

Reading Time: 5 minutes

Nella via intervista a Sakthi Chandra (NexentaVSA for View Director), durante l’ultimo Open Storage Summit EMEA, abbiamo avuto modo di discutere della soluzione di Nexenta per l’ambiente VDI (al momento pensata solo per VMware View) e soprattutto del tipo di approccio allo storage. Il loro prodotto è stato sviluppato da una collaborazione con VMware e in effetti alcuni spunti possono sembrare familiari: ad esempio come sono gestite la varie VSA (in modo del tutto analogo alla soluzione VMware VSA, salvo che non sussiste il limite di scalabilità oltre i 3 nodi). Ma del prodotto specifico vorrei parlare in un altro post (quando avrò modo di provare il prodotto e verificarlo). Quello che vorrei invece discutere è del tipo di approccio: usare storage locale anziché quello condiviso.

A dire il vero Nexenta VSA for View, in realtà, supporta entrambi gli approcci: o storage locale (alla sinistra) o quello condiviso (alla destra).

      

Se l’approccio a storage condiviso e centralizzato suona sicuramente familiare (del resto la virtualizzazione dei server è tipicamente basata su quel modello di storage), l’approccio con lo storage locale potrebbe sembrare curioso o quanto meno strano.

Ma alcuni ovvi vantaggi dovrebbero essere evidenti: in primis potrebbe essere una soluzione più economica (uso comunque il condizionale, perché le variabili sono tante).

Più interessante è invece l’aspetto della “località” dei dati, vicino ai processori e memoria dell’host, in questo modo potremmo ridurre qualunque “collo di bottiglia”, ma anche usare soluzioni specifiche lato host per accelerare gli I/O dello storage (ad esempio con schede FusionIO).

La soluzione poi può risultare maggiormente scalabile (in realtà anche qua non è detto, può dipendere dal tipo di storage condiviso), ma sicuramente rappresenta un buon modello di approccio scale-out (in contrasto con quello enterprise dello storage condiviso): ogni singolo host diventa un “building block” (o “mattoncino”) per comporre una soluzione VDI. Ogni blocco include potenza di calcolo (CPU), memoria primaria (RAM), memoria secondaria (storage locale) e porte di rete. Usando più blocchi aumento la potenza di tutti questi elementi.

Considerando poi i nuovi server che possono, in appena 2 U, avere molti core (ad esempio 4 CPU a 8 core l’una), tanta memoria (anche più un 1 TB), buona espandibilità di rete e persino tanti dischi locali (in alcuni casi anche una ventina), diventa chiaro che con pochi “blocchi” si possono realizzare soluzioni interessanti.

Ma naturalmente c’è il rovescio della medaglia: il primo, molto evidente da quanto detto prima, è che succede se un “blocco” fallisce? Tanti virtual desktop vengono impattati e andranno rifatti. Del resto in un approccio scale-out è il livello applicativo che deve poter fallire e gestire il fallimento nel modo più corretto possibile.

Nell’ambito VDI chiaramente bisogna ragionare su come lavorano i virtual desktop, come vengono istanziati e ovviamente come possono essere progettati al meglio per minimizzare l’impatto di un fallimento di un “blocco”. Considerando come esempio la soluzione VMware View (ma ragionamenti simili possono essere estesi anche ad altri prodotti) abbiamo due tipi di desktop pool automatici (e che quindi possono istanziare nuovi desktop all’occorrenza):

  • Floating (non persistent) pool: ogni desktop può essere condiviso (ma ovviamente non nello stesso tempo) tra più utenti diversi.
  • Dedicated (persistent) pool: ogni desktop è assegnato ad un solo utente.

Diventa quindi ovvio che i pool floating possono “fallire” (con impatti relativamente ridotti): se un virtual desktop non è più disponibile (ad esempio per il fallimento dell’host) l’utente dovrà solo ricollegarsi ed ottenere un nuovo desktop sul quale lavorare. Chiaro che deve rincominciare una nuova sessione, questo in alcuni casi può non essere un problema, ma in molti altri casi è un potenziale problema.

Ma poi bisogna considerare l’intero stato dell’utente, ad esempio il suo profilo! Usando folder redirection o Persona Management è possibile mantenere lato server (in questo caso ovviamente su uno storage condiviso) buona parte del profilo. E per le applicazioni? Qua dipende dalle applicazioni… alcune sono in grado di accorgersi dell’interruzione e quando si riaprono sono in grato di ripristinare parte dello stato precedente (ad esempio Firefox riapre i vari tab, Office recupera gli ultimi documenti aperti, …). Vi sono anche strumenti che tentano di riaprire i vari programmi (a volte anche nell’esatta posizione).

Altri ragionamenti si possono leggere anche su un post (in inglese): Another battle royale: SAN vs. local storage for VDI. Ma le considerazioni e le conclusioni sono simili: la scelta dell’approccio dipende dalla tipologia di utente e dai casi d’uso.

Notare che considerazioni simili si potrebbero anche fare sul “dilemma” relativo a dove eseguire le VM: localmente (client-side) o su ambiente centralizzato (datacenter-side). Se consideriamo sempre View, abbiamo la modalità Local Mode e ci si potrebbe chiedere cosa è meglio: usare il Local Mode o il virtual desktop nel datacenter? Chiaramente per utenti mobili, il Local Mode può essere la soluzione, ma quando l’utente è nella rete aziendale? Continua ad usare il Local Mode o usa la VM nel datacenter? Verrebbe da pensare alla seconda opzione, ma la prima ha un vantaggio interessante: sposta il carico di lavoro dal datacenter al client dell’utente (ovviamente sempre che non sia un thin o zero client).

Sarà anche da vedere cosa succederà a seguito della recente acquisizione da parte di VMware (VMware’s Wanova acquisition extends VDI to physical desktops): il prodotto Mirage potrebbe introdurre interessanti novità e nuove possibilità.

Share

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.