vvol1 – Page 2 – d8taDude

I have done several posts recently which have touched on VMware Virtual Volumes (VVOLs). Now that the dust has settled, I wanted to do a more detailed post to put all the pieces together and answer all the questions you may have about VVOLs and its function with 3PAR.

vSphere Storage Today

Today we take a LUN centric approach to storing VM’s in vSphere. On a 3PAR system you would create a virtual volume, then export this to your ESX hosts as a VLUN, this VLUN would then be formatted within vSphere with a VMFS file system to form a datastore. The diagram below represents the present situation, with a single LUN formatted as an VMFS datastore containing multiple VM’s.

The Need for Change

This is the way we have been working for years so what’s the challenges with this LUN centric approach.

Physical limitations – vSphere can only recognise up to 256 LUN’s per host
Disconnect between storage and VM admin. Storage guy talks LUN’s while the VM admin talks datastores
Lengthy provisioning cycles – First the LUN must be designed to meet needs of all VM’s, be provisioned in 3PAR, finally the VM admin needs to configure in VMware
Lack of granularity – LUN’s and datastore characteristics have to be designed to meet a broad range of requirements to suit all VM’s
Overprovisoning – As lots of VM’s are in the same container you have to over specify the space requirement for safety
Storage operations not offloaded – so operations such as snapshots and clones are performed by vSphere at the VM level. This approach does not optimise performance

In summary today we are bound by physical limitations, management complexity and a broad approach that’s defined by the storage characteristics

vSphere6

So what we need is something more granular, that workers closer with the storage to expose its capabilities and allows the VM’s to define their storage requirements in a policy driven manner. Well, with the launch of vSphere 6 and VVOLs, that’s exactly what we have got.

VVOL Architecture

As this is a completely new way of working with storage, let’s first understand the architecture and terminology of VVOLs. In vSphere 6 when provisioning a VM there is no need to first present the backend storage from 3PAR, just create the VM in vSphere which will then communicate utilising the VASA provider to create the necessary storage on 3PAR. VASA stands for vStorage APIs for Storage Awareness and allows the capabilities of the storage to be exposed to vSphere. When there is a storage request VASA acts as a broker between the storage and vSphere, for example when a VM says ”I want a snapshot”, the storage replies “hey take the weight off your feet good sir, allow me.”

The VVOLs created on the 3PAR have a one to one relationship with the disks created in the VM, so for example if you create a VM with 2 VMDK disks, two VVOLs will be created on the 3PAR to represent these. These VMDK VVOL’s are called data VVOLs. On top of this you also have Config, MEM, Other, and SWAP VVOL types to represent the other files that make up a VM. The diagram below shows the one to one mapping between VVOLs and VM’s.

This one to one relationship between VVOLs and backend storage does away with the need for a VMFS system, with the VMDK effectively sitting directly on the storage. The building block within which all VVOLs must sit is called a storage container. A storage container is a logical construct on the storage system in which VVOLs with similar characteristics are placed. A minimum of one storage container is required and as initially the 3PAR only supports one storage container there are no great decisions to be made here.

Protocol end points are the logical access points that enable data path communication between the storage system and vSphere. All communications to VVOLs will not be direct to the VVOLs themselves but via the protocol end point.

Summary

To summarise a separate container is created for each file type that makes up the VM direct on the storage as a VVOL, the VVOLs are grouped together in a storage container, communications to the VVOL is via the storage end point and the capabilities of the array are exposed via VASA.

VVOL Advantages

More granular approach – since each VMDK exists on its own virtual volume, availability and performance requirements can be very granular. Also reduces the need to over provision storage
No LUN limitations – The 256 limit imposed by LUN’s is banished
Quick provisioning cycle Can all be handled by a single person from within the vSphere console
Offloading to storage – VVOLs let the storage do what its best at, so snapshots clones etc. are performed by the storage on behalf of vSphere
Common language – the VM admin can talk direct to the storage admin about VVOLs without having to translate datastores to LUNs
Policy driven – When creating the VM administrators can choose the class of service they require from the storage for each disk. For example a VM disk housing a database could be set to use flash disk that supported replication and snapshots whilst a disk from the same VM only used for backups could sit on NL disk with no additional features.

All of these features allow us to overcome the challenges we identified earlier to allow a more granular, policy driven approach with the grunt work offloaded to the storage

VVOL and 3PAR

The good news for 3PAR owners is that HP have been working with VMware on VVOLs since day 1, the 3PAR was actually the reference device for Fibre Channel and VVOLs, so has undergone extensive testing. Whilst some vendors will require additional installs to accommodate VVOLs 3PAR has it baked into the code and will be available to all those running the 7000 and 10,000 systems with 3PAR OS 3.2.1 MU2. VVOLs are included with vSphere 6 which is expected in quarter one of 2015. To read more about how 3PAR and VVOLs will work together check this post and also this post which deals with requirements for VVOls.

The only thing I think HP will have to review is their naming convention for LUN’s. I think they are going to have to admit defeat with both themselves and now VMware using the term virtual volumes.

To stay in touch with more 3PAR news and tips connect with me on LinkedIn and Twitter.