This post is also available in: Inglese

I VMware Virtual Volumes (o VVols) sono una delle nuove feature più importanti di vSphere 6.0 dato che possono realmente cambiare la gestione dello storage e trasformare uno storage esterno in uno storage VM-aware secondo la vision SDS di VMware.

Benché i vantaggi maggiori si possono avere con storage a blocchi, questa funzionalità si può applicare anche agli storage a file (con datastore NFS) fornendo a tutti funzionalità di controllo e visibilità per-VM, policy based management e integrazione (e visibilità) con specifiche funzionalità a livello di storage:

E per la prima volta una novità significativa e rivoluzionaria non è stata relagata a prodotto a se’ stante o funzionalità solo dell’edizione Enterprise Plus, ma è disponibile dall’edizione Standard in su (con tanto di “downgrade” alla versione Standard anche delle funzionalità di VASA e VAAI!).

E i vari storage vendor si stanno organizzando a rilasciare nuovi firmware che supportino questa funzionalità, anche su storage già esistenti da qualche anno. Quindi molti potrebbero essere interessati ai VVols.

Ma bisogna notare come ogni storage vendor possa implementare i VVols in modo diverso: ogni oggetto di tipo VVol può essere gestito in modo diverso e avere proprietà e/o funzionalità diverse. As esempio: molti storage vendor trattano gli oggetti di tipo VVols in modo separato dagli oggetti nativi (come ad esempio le LUN o i Volumi a seconda di come sono chiamati dallo storage vendor), ma può succedere che sugli oggetti di tipo VVols non sono applicabili tutti e proprietà e funzionalità tipiche dello storage vendor (ad esempio la replica).

Ogni storage vendor che abbia sposato i VVols ha una sua implementazione, ma molti iniziano a fornire maggiori informazioni sulla propria implementazione e come e perché si differenziano rispetto ad altri storage vendor.

Tintri ha anche pubblicato un piccolo report (a mio parare un po’ troppo sintetico, ma con commenti validi ed utili) sui principali miti che riguardano i VVols.

Ovviamente è incluso (anche se non è il primo della lista) il fatto che non tutte le implementazioni siano uguali e che quindi i VVols non rendono tutti gli storage uguali!

C’è anche da considerare che non tutti i VASA provider (VASA 2.0 è una componente cruciale dei VVols) sono implementati nello stesso modo: in alcuni storage questa funzione è inclusa nello storage array stesso e quindi possiede già un discreto livello di servizi, ma in altri storage è implementato come servizio o virtual appliance esterno con quindi la necessità di considerare almeno gli aspetti che riguardano la disponibilità di questo servizio (VMware HA basta? Magari serve VMware FT? Oppure lo storage vendor prevede una specifica configurazione in alta disponibilità?), ma anche dal punto di vista delle dipendenze ed evitare che risieda in un oggetto da lui gestito (andrebbe quindi messo in una VM in un management cluster senza VVols o almeno su un datastore tradizione o un VVol gestito da un altro VASA provider).

In linea di massima uno storage può fornire sia VVols che normali datastore, ma questo dipende più dall’implementazione dello storage vendor, dato che lato VMware è possibile usare configurazioni “ibride”.

Vi è poi da considerare il limiti massimi che vanno sottovalutati: se da un lato è vero che non bisogna più curarsi di quante VM sono contenute in un datastore (valore critico soprattutto per storage a blocchi), dall’altra parte bisogna considerare che ogni singola VM corrisponderà a più VVols (un oggetto per la configurazione, uno per ogni virtual disk, uno per lo swap e poi altri nel caso di VM snapshot). Quindi è possibile raggiungere numeri di VVols anche alti che andranno confrontati con il numero massimo di VVols gestibili dal proprio storage.

Per chi è interessato su quali siano i numeri massimi dei VVols (con tanto di distinguo tra i massimi teorici e i massimi che poi i vari vendor vanno ad implementare) esiste un buon post (in inglese): “Comparing Virtual Volume (VVol) limits to VMFS/NFS limits“.

Vedere anche (in inglese):

• Virtual Volumes Links
• The 7 Big Myths About VVol
• Not all VVols are Created Equal : Hitachi Storage for VMware vSphere Virtual Volumes
• VMware Virtual Volumes – The Next Level of Storage Integration
• Why you don’t need Vvols in Coho Data

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.