vInfrastructure Blog

Nei post precedenti abbiamo visto l’archittettura di NexentaVSA for View e come installarlo e configurarlo. Come si sarà notato la parte di configurazione del NexentaStor VSA è in realtà apparentemente banale: si limita ad un OVF deploy, una verifica che la VM parta e poi la successiva conversione in template. La vera configurazione in realtà avverrà solo durante il deploy di un pool di desktop virtuali. Vediamo quindi come si utilizza e gestisce questo prodotto. Per maggiori informazioni consultare la User Guide e il video introduttivo.

Come scritto nel post precedente, l’interfaccia di management è raggiungibile da un browser all’indirizzo http://ManagementVM:3000 (ufficialmente sono supportati Mozilla Firefox v9 o successivi oppure Google Chrome v12x o successivi, nella pratica sembra funzionare anche con altri browser, incluso Microsoft Internet Explorer 9).

Gli elementi dell’interfaccia grafica che si presentano sono:

• NexentaVSA bar: è la prima barra in alto (nella pagina del browser) ed include i vari pulsanti dei wizard.
• Objects List: area a sinistra con i vari oggetti associati a NexentaVSA for View.
• Recent Activity panel: a sinistra in basso, visualizza le attività recenti (in modo simile all’are analoga nel vSphere Client).
• Working area: area di visualizzazione delle informazioni di un particolare oggetto.

Il deploy di un nuovo pool di virtual desktop può essere gestito da un wizard a partire dal pulsante “Deploy VDI” (come scritto in precedenza è necessario che nessun pool sia già presente nel cluster VMware). Notare che l’interfaccia di gestione di NexentaVSA for View rimpiazza quella di View Manager che diviene non più indispensabile per la gestione dei desktop virtuali.

Il provisioning dei pool può essere di tipo Full Cloned oppure Linked-Clones (in questo caso è necessario il VMware Composer). Inoltre i pool possono essere:

• Stateless (in View Manager sono indicati come Automated Floating pool): non hanno alcuno stato da salvare (a meno di usare delle share di rete), ma soprattutto, ad un utente  viene assegnato un desktop a caso. Con questo tipo di pool, NexentaVSA for View utilizza automaticamente il provisioning di tipo Linked-Clones.
• Persistent (in View Manager sono indicati come Persistent e Assigned): ogni utente ha il suo desktop virtuale e lo stato è salvato all’interno dello stesso (anche se in realtà potrebbe essere rediretto con Folder Redirection, Roaming Profiles o Persona Management). Per questo tipo di pool, NexentaVSA for View utilizza il provisioning Full Clones.

Chiaramente nei pool stateless, la perdita di un nodo porta alla ricomposizione di nuovi desktop e non vi sono “grossi” problemi anche con l’uso di storage locale. Nel caso invece di pool persistenti, l’approccio a storage locale rischia di divenire pericoloso.

Il wizard per il deploy dei pool è abbastanza simile a quello di View Manager (non saprei dire se meglio o peggio, forse è più funzionale), ma una grossa differenza è la parte relativa alla configurazione dello storage:  in questa fase è possibile scegliere se creare un nuovo NexentaStor VSA o usare uno storage NFS esistente (che può essere o un NexentaStor VSA o non, o una generica share NFS ). Il deploy e la configurazione di un nuovo NexentaStor VSA può essere completamente automatizzato.

La scelta di usare NFS, invece di iSCSI, è stata fatta per ragioni di scalabilità (per spostare il locking a livello di ZFS invece che a livello di VMFS). Immagino che vi siano anche altre ragioni, tra cui la possibile maggiore efficienza quando usato in una VSA.

Se la parte di provisioning dei pool è simile a quella di View Manager, non possiamo dire lo stesso della parte di monitoraggio delle risorse: realizzata in modo molto semplice ed intuitivo.

Inoltre sono disponibili alcune funzioni completamente uniche (rispetto al solo View Manager), come ad esempio la parte di Benchmark, che permette di testare e misurare diversi parametri (inclusi gli IOPS calcolati con diversi tool). Si può persino simulare e testare un completo processo di boot storm (per vedere come si comporta l’ambiente nella fase critica di avvio e/o login alle VM)!

Anche la funzione di Calibration è unica in questo tool e permette, a partire da delle misurazioni di benchmark, di ottimizzare il sistema.

Naturalmente NexentaVSA for View non si sostituisce a View Manager, né tanto meno permette di risparmiare licenze di VMware. E non elimina neppure la necessità dello storage condiviso: ipotizzando requisiti di alta disponibilità, il cluster di management dovrà comunque essere appoggiato ad uno storage condiviso. Come pure gli stati degli utenti (a meno di casi molto particolari dove veramente non c’è bisogno di alcun stato).

Rimane comunque un prodotto estremamente interessante in grado di arricchire VMware View con interessanti funzioni di gestione e monitoraggio, permettendo anche di sfruttare lo storage locale degli host in modo efficiente.

Riguardo ai costi, è licenziato a macchina virtuale (circa 35$ per VM, con un gold level support) a partire da un pacchetto minimo di 100 VM (che comunque include anche la licenza di NexentaStor VSA).

Post precedenti:

• Introduzione
• Architettura
• Installazione e configurazione

Nel post precendente, abbiamo visto l’architettura di NexentaVSA for View e come ottenere il prodotto (ed anche cosa è incluso nel file ottenuto). La parte relativa al deployment, all’installazione ed alla configurazione è, a mio parere, non semplicissima ed intuitiva. Ma è spiegata abbastanza bene nella Installation Guide ed anche in un video.

Vi sono molti requisiti che devono essere soddisfatti prima di poter procedere, come ad esempio quelli che riguardano il vSphere datacenter uno per ogni VMware cluster (come riportato nel manuale “the NexentaVSA for View environment requires a separate datacenter for each ESXi cluster”), i VMware cluster (“the NexentaVSA for View environment requires at least one ESXi cluster that contains one or more ESXi hosts” e tra l’altro deve essere un cluster “vuoto” sicurante senza virtual desktop già presenti!), il virtual networking (bisogna predisporre una rete per NFS, meglio se dedicata), per i template di NexentaStor VSA e dei virtual desktop (sul master del virtual desktop bisogna ricordarsi di installare le VMware Tools, il View Agent ma anche il NexentaVSA for View Agent), …

Tutti questi requisiti sono descritti nella Installation Guide (che include anche, nelle pagine finali, un’utile pre-installation checklist), ma in realtà alcune parti sono descritte meglio del video introduttivo. Alla fine risulta meno complesso di quanto possa sembrare (molte cose sono poi gestite in automatico, come ad esempio la configurazione dei parametri del cluster, la configurazione del NexentaStor VSA, …). Ma altri vanno seguiti alla lettera, come ad esempio la configurazione nel virtual networking che va impostato a mano (a meno di un banale cluster mononodo, nel qual caso la configurazione sarebbe automatica).

Il passo successivo è l’installazione del virtual appliance NexentaVSA for View Management (che è basato su una distribuzione Linux Ubuntu con credenziali root/nexenta). Questo step però è relativamente semplice e parte dal deployment del file OVF.

La NexentaVSA for View Management Appliance andrebbe salvata su un ESXi host (o un cluster) dedicato al management e separato da quello dei desktop virtual (ma nella stessa rete di management). Da notare che NexentaVSA for View Management Appliance richiede un accesso con pieni privilegi amministrativi a tutte le componenti che dovranno poi essere gestite e controllate (vCenter Server e View Connection Server).

Quando la VM è pronta (notare che le richieste sono relativamente limitate: 1 vCPU, 2 GB di vRAM e 20GB di storage) bisogna entrare in console e completare la configurazione della rete (di default è in DHCP) e della timezone (if needed. Peccato che sono siano usate le funzioni previste per gli OVF, in modo da chiedere queste informazioni già all’inizio.

A questo punto è possibile usare il Configuration Wizard. Sarà necessario un browser (anche Chrome 12 o successivo è supportato) da far puntare all’URL http://IP:3000 (come riportato anche nella console della VM).

I tre step previsti dal wizard sono la registration del prodotto, la configurazione della connessione al View Connection Server e di quella al vCenter Server.

Notare che per collegarsi al View Connection Server è necessario:

• Attivare la View Power CLI (aprendo la View Power CLI come Administrator e digitando il comando”Set-ExecutionPolicy RemoteSigned”).
• Installare il NexentaVSA for View Server Agent.

Solo in questo modo sarà possibile collegarsi al View Connection Server (altrimenti sarà visualizzato un generico messaggio di tipo connection refused error).

Per registrare il prodotto servirà un Product key valido, anche per la versione trial!

Per ottenere il product key è necessario recuperare la “Virtual Appliance Signature” (visualizzata nella pagina di registrazione dell’appliance) ed inserirlo nel campo “Machine Signature” della registrazione online. In realtà richiesta del Product key può essere fatta anche dall’appliance (se è in grado di collegarsi via SMTP ad un server di posta).

Come si nota alcuni parti potrebbero essere decisamente migliorate in release future del prodotto, ma in realtà basta seguire la documentazione passo-passo.

Nel post precedente abbiamo visto le principali caratteristiche e i concetti base di NexentaVSA for View. Ora forniamo ulteriori dettagli sulla parte architetturale di questo prodotto. Maggiori dettagli sono disponibili nella guida NexentaVSA VMware View HW Reference (che include anche interessanti scenari e criteri di dimensionamento).

In una soluzione a storage locale per parti principali sono:

• NexentaVSA for View Management Appliance: la parte di gestione di tutto l’ambiente e viene fornito sotto forma di un VA eseguibile su qualunque host ESXi.
• NexentaStor VSA: è un virtual storage appliance (VSA) che fornisce la parte di storage ed è basata sulla stessa componente di storage di Nexenta. In realtà l’interazione con questa componente avviene sempre e solo attraverso i wizard. Per ogni host ESXi con il suo storage locale sarà necessario un NexentaStor VSA che convertirà lo storage locale in storage NFS (ma, come già spiegato, non fornisce funzioni di alta disponibilità e/o replica tra altri VSA). Per certi versi, lato host, è del tutto simile al VMware VSA (salvo che non dispone dell’alta disponibilità e che la sua scalabilità non è limita a 3 nodi).
• NexentaVSA for View Server Agent: gestisce le comunicazioni tra handles all communication between NexentaVSA for View e le componenti di VMware. Viene installatto sul View Connection Server ed è obbligatorio (è curioso come non si sia riusciti ad usare le API standard al suo posto).
• NexentaVSA for View Desktop Agent: gestisce le comunicazioni tra NexentaVSA for View e i virtual desktop. Viene installato nel desktop template (nella macchina di riferimento per il pool). Da notare che non sostiuisce il View Agent e/o le VMware Tools: la sua funzione è integrarli per fornire funzioni altrimenti non possibili (come ad esempio l’analisi dettagliata sulle prestazioni e il funzionamento dei desktop virtuali).

Naturalmente saranno necessarie anche le parti relative a View e vSphere, per completare l’architettura.

Il NexentaVSA for View Management Appliance include diverse compomenti che servono per “dialogare” con View, vCenter Server e la parte di storage, oltre che ovviamente un’interfaccia web di gestione con diversi wizard per semplicare il compito dell’amministratore ed ottimizzare i diversi workload VDI.

Per la parte storage, come già scritto, viene utilizzato il NexentaStor VSA (nella soluzione a storage locale). La scelta è per diverse ragioni, alcune tecniche (come ad esempio sfruttare al meglio il ZFS filesystem), altre di marketing (ovviamente per spingere il prodotto di storage dello stesso vendor).

Nel caso di una soluzione a storage condiviso, viene utilizzata una soluzione basata su NexentaStor Server, su sistemi dedicati, e (per ragioni di alta disponibilità) in configurazione cluster.

Per la parte storage, l’utilizzo di un Hybrid Storage Pool è consigliato per migliorare ed ottimizzare le prestazioni. Gli elementi che lo compongono sono:

• Adaptive Replacement Cache (ARC): the main ZFS cache stored in RAM.
• Level Two Adaptive Replacement Cache (L2ARC): provides a larger, second-level cache to accelerate read operations. SSDs can be deployed here to cache read operations. Sizing RAM is important in calculating the size of the L2ARC (For example, it would make sense to store database pointers in RAM to enable quick access to records in the L2ARC, and to size RAM and the
  L2ARC accordingly).
• ZFS Intent Log (ZIL): a separate intent log allows synchronous writes to be written quickly and acknowledged in the transactional model that ZFS uses. For VDI workloads, adding SSDs as a ZIL to cache writes significantly enhances performance.

Tutte le componenti software sono incluse in un unico grosso file (in formato tar.gz) disponibile nella pagina del download.

Il file contiene le seguenti cartelle:

• Agents: include gli agenti per la parte server e desktop.
• Docs: include le guide all’installazione e all’uso del prodotto.
• NexentaStor_Template: la parte di storage sotto forma di VSA in formato OVF.
• NexentaVSAforView: la parte di management sotto forma di VA in formato OVF.

Nel prossimo post vedremo come usare tutti questi file.

NexentaVSA for View (NV4V) è una soluzione sviluppata da Nexenta, in collaborazione con VMware, con l’obiettivo di realizzare un sistema integrato di virtual storage per VMware View deployments e che integri anche funzioni di gestione.

Questo prodotto cerca di risolvere alcuni dei principali problemi e/o ostacoli all’adozione di soluzioni di VDI:

• Prestazioni: in ambienti di VDI tradizionali si utilizza storage condiviso che diviene potenziale collo di bottiglia. In questa soluzione, è possibile utilizzare lo storage locale e scalare le prestazioni semplicemente aggiungendo nuovi host (allo stesso modo con cui si scalerebbe per aumentare la potenza di elaborazione).
• Costo: nelle soluzioni tradizioni lo storage diviene una compotente significativa nel costi della soluzione (anche perché spesso sono richieste funzioni di un certo livello). Qua è possibile adottare storage locale.
• Complessità: tipicamente ci sono da gestire diverse parti (View, vSphere, storage, …). Con questo prodotto tutto può essere gestito da una singola console.
• Monitoraggio: l’aspetto difficile in ambienti VDI è il controllo di come il sistema sta funzionando e come gli utenti stanno lavorando. Con questo strumento è possibile controllare e verificare alcuni importanti indici.

continue reading…