More information on VVOLs is being released every week and it is only now that we are getting a chance to play with the full release code that we are able to dig into the detail of how it works. Let’s start off by exploring the benefits of VVOLs that are likely to make it game changing technology:
Granular Control of VMs
- Enable VM granular storage operations on individual virtual disks for the first time including control of the following capabilities:
- Auto Grow
- Compression
- De-duplication
- Disk Types: SATA, FCAL, SAS, SSD
- Flash Accelerated
- High Availability
- Maximum Throughput: IOPS & MBs
- Replication
- Protocol: NFS, iSCSI, FC,FCoE
Enhanced Efficiency and Performance
- Off-load VM snapshots, clones and moves to the array
- Automatically optimise I/O paths for all protocols
- No VMFS, therefore
- Virtual disks natively stored on the array
- Datastore space management is not required
- Size limits are dictated by the guest and array
- Zeroing, either on disk creation or use, is not required
- vSphere UNMAP, when a VM is deleted, is not required
- Guest UNMAP commands are passed directly to the VVOL
- Thin-provisioning is managed by the array
- Minimise LUN and path consumption, NFS mount usage, and LIF count and IP address consumption
Automated Policy Based Management
- Create a library of reusable storage profiles
- Match the profiles to storage capabilities
- Provision VMs using storage profiles
- Alert when a VM no longer conforms to the profile
To get VVOLs up and running you need cDOT 8.2.3 or above, Virtual Storage Console 6.0 and VASA Provider 6.0 – for more background information see A deeper look into NetApp’s support for VMware Virtual Volumes.
The On-Demand engine
One of the best kept secrets of cDOT 8.3 was the inclusion of the On-Demand engine which consists of the following new commands:
- Single-File Move on Demand (SFMoD)
- Single-File Copy/Clone on Demand (SFCoD)
- Single-File Restore on Demand (SFRoD)
When a command is triggered, data access at the destination begins immediately, while in the background the data is copied or moved from source to destination. The commands cannot be directly invoked, rather other operations take advantage of them (i.e. VVOLs and LUN moves). So when the policy of a VVol is changed that results in it needing to be moved from one volume to another (even across controllers) the On-Demand engine non-disruptively moves data access from the source to the destination instantly. All writes go to the new destination and, while the data is being copied from the source, reads are redirected back to the original volume as required. If a VVOL is migrated elsewhere in the cluster, a rebind operation automatically changes the I/O path to the new closest PE, maintaining optimum performance and reducing complexity and latency.
Not all VVOLs implementations will be equal
The interesting thing about VVOLs is that not all implementations will be equal, as it puts more responsibility on the array by moving many storage operations to it that were previously handled by vSphere – you therefore need an array that provides efficient:
- Thin-provisioning
- Snapshots
- Clones
- Non-disruptive VM mobility
The current snapshot technology in VMFS is to say the least very poor – best practice is to have no more than 2-3 snapshots in a chain (even though the maximum is 32) and to use no single snapshot for more than 24-72 hours – the reason is simple, storage performance will suffer if you create a snapshot on a VM. So if an array supports VVOLs and we can off-load snapshot and clone creation to the array then we have surely solved the problem and we can then keep 100s of snapshots. As always it is not so simple – if the array uses inefficient CoW snapshots then you will not gain much over the standard vSphere snapshots. Thin-provisioning is another area whereby some arrays do it very efficiently, but many suffer a significant performance drop unless thick LUNs are used.
The nice thing about FAS is that it has excelled at the first three points above for many years and the last point has been introduced with the On-Demand engine in cDOT 8.3 – there are plenty of arrays on the market that will be enabled for VVOLs, but they will not be able to claim efficient support for these features without massive re-engineering work.
Other points of note
It is essential to backup the VASA provider VM, this can be achieved using the in-built backup capabilities of the array using one of the following options:
- The backup and recovery features of VSC
- The built-in scheduled FlexVol snapshot copies
NetApp All-Flash FAS has emerged as the first storage array to successfully complete validation testing with Horizon View 6 with VVols.
The VADP APIs backup vendors use are fully supported on VVOLs therefore backup software using VADP should be unaffected.
For a detailed breakdown of vSphere product and feature interoperability with VVOLs click here
Get hands on with VVOLs on FAS
If you would like to gain a detailed understanding of how the technology works we have created, in conjunction with VMware and NetApp, a series of demo café events – to find-out more click here.
VVOLs is certainly interesting technology and I am sure what we have today is only the beginning of the journey and it is going to be interesting to see how it develops over the coming years – we know for sure that NetApp will be making improvements to cDOT to enable things like replication to be set at a VVOL level.
What do you think – is VVOLs as game changing as VMware thinks?
Disclosure: My company has a business relationship with this vendor other than being a customer: We are Partners with NetApp.
Saluting Mark:>)
Henry