VVOLs have been available for a few months now. I’m not going to cover the basics in this post but if you are new to VVOLs check out my over view of VVOLs. Based on a wholly unscientific survey on Twitter I asked how many people had adopted VVOLs and the response was limited. From what I have seen on blogs, I have seen plenty written on the technology but little about people actually implementing it. I wanted to look today at what’s hot about VVOLs (Ladders) and what could potentially be holding people back (Snakes). Finally we will look at a balanced way of moving forwards.
This Ladder’s section covers what’s hot about VVOLs. One of the most obvious is per VM and indeed per disk management since a separate VVOL is created for each part of the files that make up a VM. This means the broad approach that had to be used with LUN’s containing vast numbers of VMs could be a thing of the past. The Granularity of VVOLs allows performance changes to be dynamically applied to a single VM, rather than having to apply to all the VM’s on a traditional LUN. Additionally protection of VM’s is also simpler as individual snapshots can be applied at the VM level utilising the storage system to perform the operation.
This leads directly onto the next benefit, policy driven storage. Because each VM is constructed in such a granular manner it allows different storage requirements to be applied easily on a per VM basis. This is enabled through VM policies which enable specific requirements to be defined and allows a more focused app centric approach. The capabilities of the storage array are fed back via the VASA provider and then can be served up in policies of your choosing. You could keep it simple having a gold, silver and bronze policy or define other attributes such as the VM must have snapshot or replication features available.
As storage is now policy driven storage provisioning can now be done automatically as part of the VM creation process in vSphere. Previously the storage admin would have to get all the storage lined up before the VM admin even thought about creating a VM. Now everything is done on the fly, assuming your storage admin has completed the one time step of enabling the system for VVOLs. The VM can be created and the necessary VVOLS are automatically created on the storage. Essentially the process of provisioning a VM has less admin overhead and is much faster.
VVOLs allow the storage system to be able to do what it does best, so storage operations such as cloning or taking snapshots can be offloaded to the storage system delivering a performance boost. Also VVOLs remove the previous limitation of 256 LUN’s per host.
No really after you
English people love to queue, and with VVOLs it seem to be a case of “no really after you”. Most organisations virtual environments are running business critical systems and there could be some fear moving onto what is effectively a 1.0 product release.
A handful of systems including 3PAR were VVOL ready at launch but other systems such as EMC’s VNX will not be ready till quarter 2 2016 and XtermeIO till quarter 4 2016.
Not all vendors are equal
No specific features were part of the certification process. So the availability of features such as snapshots, clones, thin provisioning etc. are vendor specific. So check you’re getting what you want from your implementation.
Whilst VVOLs are a new technology, one of the keys to success with any new technology is putting in the correct people and processes around it. Firstly and perhaps most obviously VVOLs are a new technology and so there will be no readymade experts out there.
VVOLs also provide a new way of working, effectively excluding the storage guy from the process of provisioning storage for VM’s. This could create potential internal political conflict with the storage resource feeling like they are losing control and visibility of what’s going on.
I’ll take it all please
When people started with virtualisation they acted like a kid in a candy shop requesting crazy amounts of RAM because it was there. I can see this being the same with people requesting that their VM is cut from the highest performance policy and in turn expensive backend storage.
Not only will you need to be running vSphere 6 and hence all your equipment will need to be supported to version 6. But also you will need to check other components such as HBA’s in servers are compatible. Not all features are supported, for example (FT) and Microsoft Failover Clustering (MSCS) for example are not supported.
No one knows yet if VVOLs will completely replace VMFS. But how many vendors would want to maintain the code and support for 2 products delivering such similar use cases. I am not suggesting that VMFS is about to disappear any time soon but it would seem sensible that at some time VVOLs will become the successor to VMFS. So how do we move forward to start to use and familiarise ourselves with VVOLs:
If your storage vendor doesn’t support VVOLs, yet there obviously isn’t much you can do just hang in there or switch vendors. If your vendor does support it, the next step is to start looking at compatibility with the rest of your infrastructure and required features
Don’t just assume things are going to work together and will be available in this initial release. You can use the vSphere Virtual Volumes (VVols) Interoperability Matrix to check which features are compatible with VVOLs. Check for any vendor specific requirements including your full SAN infrastructure such as HBA’s. Also don’t forget good ol’ testing covered in the next section.
Remember the brave old days of virtualisation when you strode boldly around the office clutching VMware capacity planner reports shouting “it’s all going to be virtual I tell you.” Today the brave attitude has been replaced by caution with the reality that a lot of critical systems sit on top of virtual infrastructures. If you’re not ready to put VVOLs into your commercial test environment yet check out this guide by Luca Dell’Oca describing how you can use a simulator from EMC to test VVOLs in your home lab.
Again thinking back to the early days of virtualisation the sensible and often- taken approach when moving to a virtualised environment was a phased one. With the initial phases being to virtualise test /dev, then IT system, business apps and critical apps. This again seems like a sensible path for migration to VVOLs. VVOLs and VMFS can co-exist on the same storage system. So why not start small and get 1 or 2 test systems using VVOLs.
As things progress and confidence grows it is even possible to migrate a VM from a VMFS volume to a VVOL.
Do your planning
As outlined above do not under-estimate how different working with VVOLs will be, you need to make sure you have clearly thought through how this will change your processes. Make sure everyone in the IT department is on-board and understand their new responsibilities, plus consider questions like how will capacity be managed and monitored when it’s the VM admin doing the provisioning. How does this affect change control? On what basis will the required storage policy be decided? This and other questions relevant to your business, need planning to get the maximum return from this new technology and to ensure you are not held back by processes or politics.