This post is also available in: Inglese

Una delle più grandi novità del nuovo VMware vSphere 6.0 riguarda i Virtual Volume, tassello importante alla base della vision SDS di VMware.

I VMware vSphere Virtual Volumes (o VVols) sono un nuovo standard di mercato per il Software-Defined Storage, che permettono a storage array esterni di diventare virtual machine-aware. VMware vSphere Virtual Volumes è un set di API storage che consente una più granulare integrazione fra lo storage e VMware vSphere a livello di singola macchina virtuale.

Gli storage array compatibili con VMware vSphere Virtual Volumes possono essere gestiti attraverso un sistema di controllo centralizzato (VMware vCenter), estendendo così a storage eterogenei la visione di VMware per il Software-Defined Storage incentrata sulle applicazioni e basata su policy.

VMware vSphere Virtual Volumes ha ricevuto un forte supporto dall’ecosistema VMware per lo storage. Inizialmente VMware ha lavorato a stretto contatto con 5 partner (Dell, EMC, HP, IBM and NetApp) per definire questa tecnologia. Ma ad oggi vi sono già numerosi storage partner (una trentina) inclusi Atlantis Computing, Fujitsu, Hitachi Data Systems, NexGen Storage, Pure Storage, Tintri, Nimble Storage e SolidFire.

Secondo me, questa tecnologia è forse la più innovativa della nuova release (sicuramente più del nuovo FT, ma anche della nuova VSAN visto che in entrambi i casi si è trattato più di una evoluzione). Paradossalmente è stata anche la novità più annunciata e “spoilerata” nei vari VMworld (si pensi che la prima tech preview risale al 2012!). Il punto è che rappresenta un modo completamente nuovo di intendere lo storage e cambierà sicuramente il modo con in quale viene utilizzato, ma anche come viene pianificato e progettato.

E per una volta tanto è un vantaggio più per l’ecosistema, dato che i vari storage vendor hanno l’opportunità di implementare qualcosa di totalmente nuovo e differenziarsi tra di loro, ma anche tra le diverse funzionalità native che potranno essere implementate! Ovviamente queste funzionalità differenzianti vanno poi mediate e ponderate, non tutti gli storage implementano le stesse funzionalità nello stesso modo e quindi paragoni beceri possono nascondere il vero valore delle soluzioni (a tale propositivo vedere questo post in inglese).

In realtà questa scelta può rivelarsi un buon affare sia per VMware che per gli storage vendor. Sicuramente è una dimostrazione di come VMware non renda tutti gli storage uguali tra di loro o “stupidi”: magari nella gestione che diventa incentrata su vCenter e sulle policy e sicuramente semplice, ma non nelle funzionalità che i vari storage vendor possono esprimere e che rimarranno distintivi di ogni soluzione (anche è ragionevole aspettarsi un set di funzioni comuni).

Come cambierà lo storage

Utilizzando i VVols sarà prima di tutto possible semplificare gli storage a blocchi (ma i VVols vanno bene comunque anche per storage a file): niente più LUN, necessità di stabilire la dimensione, farne il provisioning, masking o mapping, …Ogni virtual disk delle varie VM può essere ospitato nativamente sullo storage con la massima flessibilità e senza introdurre nuovi protocolli (rimangono supportati i soliti FC, iSCSI, NFS).

In questo modo, tramite i VVols lo storage può “vedere” i singoli oggetti che compongono le VM e su di questi eseguire operazioni granulari. Ma vale anche il viceversa: tramite vSphere Storage Policy-Based è possibile richiedere specifiche funzioni allo storage in modo da avere una configurazione completamente VM-centrica e policy driven.

Semplifica anche la classica separazione dei ruoli tra virtualization e storage admin che ora possono almeno vedere gli stessi oggetti:

Ma si può anche arrivare a delegare completamente tutta la parte di storage provisioning (dopo che il tutto è stato opportunamente configurato) ai virtualization admin.

Ma l’aspetto più importante è che può virtualizzare storage esterni di tipo SAN o NAS trasformandoli in “object storage” (dove gli oggetti sono i vari elementi delle VM) e che è incluso in vSphere 6.0 (a partire dall’edizione Standard!). Gli storage possono diventare VM centrici ed integrarsi meglio con l’infrastruttura di virtualizzazione (a dire il vero alcuni vendor avevano già realizzato approci VM centrici, ma in questo caso parliamo di un vero e proprio standard).

Come funziona?

I concetti principali di questa tecnologia sono:

• Nessun file system: VVols non richiedono più l’uso di VMFS (almeno per lo storage a blocchi)
• Gli host ESXi e vCenter Server possono comunicare con lo storage tramite le VASA (vSphere APIs for Storage Awareness) API che sono una componente fondamentale di questa soluzione (ovviamente VASA 2.0 è diventato disponibile dall’edizione Standard in poi)
• Gli storage possono essere partizionati in modo logici in “container” chiamati Storage Containers
• I dischi delle VM diventano Virtual Volumes, salvata come “oggetti” nativi all’interno dei Storage Containers
• Le operazione di storage I/O da parte degli host ESXi passano attraverso un punto di accesso chiamato Protocol Endpoint
• Il tutto è gestibile tramite il framework di storage policy-based management

Per comprendere meglio il funzionamento bisogna chiarire alcuni termini e punti chiave di questa tecnologia. Vediamoli uno per uno…

Vendor Provider (VP)

La parte chiamata Vendor Provider di fatto è una componente software o plug-in sviluppata e fornita dallo storage vendor. Serve ad implementare delle API comuni fi out-of-band management e non solo. Di fatto un’evoluzione delle Storage API già esistenti in vSphere 5.x chiamate VASA e ora arrivate alla versione 2.0.

Alla pari delle API VASA 1.0, possono essere implementate direttamente nello storage array (a livello di firmware o interfaccia di gestione), oppure traminte una componente esterna (ad esempio per Compellent è l’Enterprise Manager, per EqualLogic è una VA).

Aggiungere un nuovo Vendor Provider è praticamente come aggiungere un VASA 1.0 provider ed un solo Provider può gestire più array.

Protocol Endpoints (PE)

Un Protocol Endpoint è il meccanismo di trasporto o il punto di accesso tra l’host ESXi e lo storage array. Un po’ come se fosse il target iSCSI o FC di uno storage tradizionale. Deve essere creato dallo storage admin.

I Protocol Endpoint sono compatibili ovviamente con i normali protocolli di front-end degli storage SAN o NAS:

• iSCSI
• NFS
• FC
• FCoE

E possono gestire diversi percorsi o policy di accesso:

• Multi-path policies
• NFS topologies

Vi sono diverse differenze tra i Protocol Endpoint e i VMware datastore:

• I PE non memorizzano dati, sono solo punti di accesso
• I PE normalmente sono uno solo (per storage array)

Storage Container (SC)

Gli Storage Container sono abbastanza simili ai datastore di VMware dato che raggruppano parti di storage in un costrutto logico sul quale applicare, ad esempio, differenti SLA e requisiti funzionali, tramite le VASA API.

Alla pari dei Protocol Endpoint, anche gli Storage Container devono esser creati dagli storage admin. Uno stesso Storage Container può essere acceduto simultaneamente da più Protocol Endpoint.

Come detto vi sono delle similitudini tra Storage Container e VMware datastore:

• Capacity is based on physical storage capacity
• Logically partition or isolate VMs with diverse storage needs and requirement
• Minimum one storage container per array
• Maximum depends on the array

Virtual Volumes (VVols)

I Virtual Volume sono memorizzati negli Storage Container e mappati con i vari oggetti che compongono una VM. Esistono 5 diversi tipi di Virtual Volume a seconda del diverso tipo di oggetto:

• Data: sono i vari VMDK
• Config: File che normalmente sono nella cartella delle VM, come il file di configurazione, i file di log, …
• Memory: Le snapshot
• Swap: Il file di memory swap per ogni VM
• Other: Altri tipi di file

Il provisioning dei VVols sarà consistente sia lato vSphere che lato storage:

• Lato vSphere: le operazioni vengono convertite in VASA API per eseguire i comandi sullo storage
• Lato Storage: le operazioni saranno eseguite in virtù delle VM Storage Policy selezionate

Questa granularità dove ogni oggetto di una VM è un Virtual Volume (e quindi un oggetto dello storage) permetterà agli storage vendor di implementare funzioni molto interessanti in virtù della maggior visibilità acquisita.

Ad esempio potrebbero implementare uno Storage QoS a livello di VM, permettere una miglior replica orientata alle VM e non più ai datastore, persino un miglior provisionig, soprattutto nel caso di vmdk thin (con potenzialmente la possibilità di eseguire un guest reclaim dello spazio liberato), e tanto altro ancora…

Ma anche le VM snapshot possono cambiare!

Snapshot

Le snapshot sono delle immagini copy on write e point in time utilizzati per diversi scopi, in primis poter avere una copia quiescente di una VM per poter eseguire il backup con la stessa in funzione. Ma potrebbero esserci anche altri sceari di utilizzo come ad esempio necessità di test e rollback.

Con i Virtual Volume vi saranno due diversi tipi di snapshots:

• Managed snapshot: gestite da vSphere (come fossero le normali VM snapshot) con il limite di massimo 32 snapshot per VM
• Unmanaged snapshot: gestite dallo storage array con un massimo che dipende dalle funzionalità e capacità dello storage stesso

Chiaramente la seconda soluzione diventa quella potenzialmente più interessante visto che può complemente superare gli attuali limiti delle snapshot di VMware (in particolare su vSphere) e potrebbe diventare anche molto utile per i backup vendor (a quel punto, potenzialmente, qualunque storage compatibile con i Virtual Volume e questo tipo di snapshot potrebbe essere usato per eseguire un backup in modalità offload, presentando la snapshot direttamente alla macchina di backup).

Storage Policy Based Management (SPBM)

Come oramai diventato normale nelle soluzioni di VMware (come, ad esempio, nella Virtual SAN) tutto è gestibile da policy, volendo anche a livello di singole VM.

Nel caso dei Virtual Volume (ma anche di VSAN) le policy usate sono quelle del vSphere Storage Policy-based management framework (SPBM) e normalmente sono una serie di requisiti funzionali che vengono poi adattati alle funzionalità presenti a livello di storage. Ad esempio è possibile richiedere che un oggetto di una VM deve essere replicato o deve essere su uno storage ad alte prestazioni.

Le storage capability sono in modo con il quale specificare queste richieste e possono essere definite in due modi:

• Vendor defined: lo storage annuncia automaticamente queste funzionalità tramite le VASA API e il Vendor Provider
• End User defined: l’utente definisce a mano questi attributi

VAAI vs VVol

Dato che lo storage vede già i singoli oggetti le operazioni possono già essere native grazie a VASA e quindi l’offload essere del tutto implicito. In realtà le VAAI esistono ancora e per maggiori informazioni, consiglio questo post (in inglese) che dimostra vari scenari di utilizzo delle stesse quando si clona una VM: Virtual Volumes (VVols) vSphere APIs & Cloning Operation Scenarios. Oppure questo post (sempre in inglese e sempre dello stesso autore): vSphere Virtual Volumes Interoperability: VAAI APIs vs VVOLs.

Maggiori informazioni

Vedere anche queste risorse (in inglese):

• Virtual Volumes official page
• HOL-SDC-1429
• vSphere Virtual Volumes
• vSphere 6.0 Storage Features Part 5: Virtual Volumes
• Virtual Volumes and queueing
• Migrations and Virtual Volumes – Deep Dive

Andrea Mauro

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.