VMware recently announced vSphere 6.5 and it includes the next big version of Virtual Volumes (VVols) which is based on the updated VASA 3.0 specification. The initial release of VVols was part of vSphere 6.0 which went GA in March 2015 and was based on VASA 2.0. VVols has been out now for over 18 months and with vSphere 6.5 expect to see maturity, improvements and of course a big capability that was missing in the initial release, support for array based replication.
Before I go into what’s new with VVols 2.0, lets first re-visit what I’m currently seeing around customer adoption of VVols. I’ve spoken to dozens of customers and surveyed hundreds of people in my sessions at Discover, VMUGs and VMworld. When I ask who is using VVols today I see very few hands go up. That’s really about what I expected at this point, most companies avoid 1.0 products, the same held true with VSAN, there are additional reasons as well such as lack of replication support, not on vSphere 6.x yet and not understanding what VVols is and the benefits it brings.
I expect that to start to change though, I have also spoke to plenty of customers, some very large that are in the planning phase for migrating to VVols. The release of vSphere 6.5 should help drive adoption as VVols unofficially becomes a 2.0 product and is more complete with support for replication. As far as the understanding aspect goes I think VMware hasn’t overall done all that great a job of helping customers with that. My feeling on that is mainly based on my own observations and interactions with VMware. I do know for a fact that the VMware VVols product management team has done a good job promoting VVols but they are a relatively small part of a big company.
If you watched the VMworld EMEA keynotes were vSphere 6.5 was introduced, you didn’t here a single mention of VVols. Other features like VSAN, NSX, encryption, vRealize, cloud, VM scale, vCenter, new Web UI, etc. all were mentioned. There was a brief callout in the vSphere 6.5 press release but not many people read those. The same was true with the early access blogger briefings that VMware does so the bloggers get the early scoop so they can write about it at launch, VVols was strangely absent. With the initial release of VVols they put a lot more effort into VVols marketing and awareness but this time around it has been relatively quiet. I’d really like VMware to step it up and see people like Pat Gelsinger, Ray O’Farrell and Yanbing Li talking about VVols as well. I know I’m doing my best to evangelize VVols and educate the community and I know other partners are doing so as well but it would be good to see VMware try and do more at all levels of their organization.
So let’s now cover what’s new in VVols 2.0 and really the focus here is all on Replication as there is not much else new. Under the covers I expect there are a lot of improvements but VASA is really a development specification or an enabler for storage vendors to develop their own implementations of array based capabilities to integrate with Storage Policy Based Management (SPBM). As a result every vendor implementation of VVols will be slightly different as it’s up to each vendor to dictate how they can scale, how they implement the VASA provider, what capabilities they will present to SPBM, etc.
With vSphere 6.5 storage array vendors can now implement replication of VVol-based VM’s through the creation of Replication Components and attaching them to vSphere Storage Policies. Previously, a storage policy was a single set of rules built from the list of capabilities offered by the array. With vSphere 6.5 those rules have been broken up into different capability types, known as Components that allows you to define a capability once and re-use it in multiple storage policies. There are different Component class types which include Replication, Performance and Encryption. The below figure show how the Component section in the VM Storage Policy management interface in the vSphere client.
Once you create a Component, you tie it to a vCenter Server, name it and then select the Provider type, in the below figure you can see the multiple types of Providers available in vSphere 6.5 including Replication.
Next you define the properties for the Replication Component, this can include the target Storage Container and disk groups, how frequent replication will occur and desired RPO levels as shown below.
Once you have your component defined you can add it to a VM Storage Policy as shown below, note a Storage Policy can have multiple Components added to it.
Now that your Components are created and assigned to Storage Policies when you go to create a VM on VVol storage when you get to the Storage selection screen and choose an existing Storage Policy to assign to that VM you will also see the option to select a Replication Group for that VM based on what is defined in the policy. as shown below. You can choose from an existing Replication Group or a new one will be automatically created for you. Only existing groups that match the replication constraints defined in the policy will be displayed. A replication group is the minimum level of failover and will contain one or more VVol objects (multiple VMs). Any Replication Group that is automatically created will also be automatically removed once their are no more VMs assigned to it.
Some other things to note about replication, all of a VM’s VVol objects will be replicated to the target to ensure VM integrity, this includes and snapshots attached to the VM. Replication may be array based but it is solely designed to be implemented and managed by vSphere via SPBM and other vSphere interfaces. You must configure Storage Containers on both the source and target arrays before creating replication profiles. While it is possible to replicate only certain disks of a VM to a target site, a VM must have all of it’s VVols that it is replicating in teh same Replication Group.
So while it is great that we now have array based replication with VVols, how do you actually make use of it in a real world DR scenario? In this release there is no automation component like SRM to orchestrate replication, failover, testing, failback, etc. Eventually vRealize Orchestrator will be able to do much of this but for now all operations must be scripted using the VVol APIs that exist. There are 3 main operations that you can do in this release, a test failover, an actual failover (planned or unplanned) and a reverse failover (recovery). All of these operations are strictly performed within the vSphere environment, your storage admin is not involved in any of this.
Under normal operations VVols at the secondary site are hidden from vSphere and can not be bound to. When you perform a test failover it is not a true failover operation, just a simulated one. What happens is the VVols at both the primary and secondary sites remain in their current state and copies of each replica VVol are made at the secondary site so they may be presented to the vSphere environment and are now capable of being bound to at the secondary site for testing. These copies are in a consistent state and vSphere will automatically fix-up the copies so they can be utilized for testing purposes. Once testing is complete all of the VVols at the secondary site will cleaned up and removed.
If you perform an actual failover it is initiated from the secondary site, a final sync operation is performed (planned failover) and replication is halted between the sites. If the failover is forced or unplanned the secondary site is not allowed to contact the primary site. After the failover call is made to the VASA Provider at the secondary site, the VVols at that site become visible and are able to be bound to hosts. After a failover, the only operation allowed is is to recover the group (failback). As the primary site can no longer be the replication source, vSphere will issue a reverse operation. A reverse operation essentially just sets up replication back to the primary site where you can failback at some point when needed. As part of a planned failover you initiate both the failover and reverse replication at the same time.
As far as the orchestration of all this I’m still trying to come up to speed on that so as I learn more I’ll provide more detail on that. For a planned failover you will have to manually script (i.e. PowerCLI) out the workflows as you don’t have a tool like SRM to build them for you. At some point vRealize Orchestrator and Automation will be capable of doing all this but until then you will have to build this on your own. I suspect VMware will have all the tools, docs, sample scripts, etc to help you with this. I’m actually just kicking off a tech paper that will cover how to do this for 3PAR, however most of the workflows/scripts should be generic as they are calling the standard tasks outlined in the VASA 3.0 specification.
You can also read more about the capabilities in VVols 2.0 on the VMware Virtual Blocks blog.
