Our VVol implementation has been out for well over a year now and we’ve had our share of customers wanting to take the technology for a spin. When VMware first introduced support in vSphere 6 – what is known as VVol 1.0 and VASA 2.0 – they did not offer replication capabilities for array vendors. It can be confusing since you might think the vendors have control over VVol replication, but really we need VMware and VASA to help us there. For most of our customers the lack of a DR solution was a real deal-breaker (frankly as it should be) and has hindered VVol adoption ever since. Our customers who use VVols do so almost exclusively in a test environment.
Fast forward to this past fall when VMware released vSphere 6.5 along with VVol 2.0 and VASA 3.0. This release does have support for replication (though not Site Recovery Manager to the chagrin of many customers) which means vendors can enable their own array technology with VVols. Unfortunately, however, VMAX has yet to do this for SRDF. You can of course use our VVol implementation with vSphere 6.5, but it will be based on VVol 1.0 and VASA 2.0 with no replication. As our customers were hoping the latest VMware release would bring replication support on the VMAX, we wanted to be able to offer a solution that would allow them to proceed further in their VVol implementation if they so desired. Enter RecoverPoint for VMs (RP4VMs). RP4VMs is a software which replicates data at the VM level (unlike SRDF which is device level) using an ESXi write-splitter. It supports both local and remote copies in asynchronous or synchronous modes over the IP network. It also has a plug-in to the vSphere Web Client to manage the replication. It is most analogous to vSphere Replication. There is a nice whitepaper that will give you an overview of RP4VM here. (You’ll note that there are two different types of write-splitters – for my environment I’ve only used the vSCSI.)
As I have not found any specific documentation around VMAX VVols and RP4VMs, I wanted to at least provide a quick walkthrough for any customers who wish to try RP4VM with VVols. I’ll start with an explanation of my particular setup and then there is a demo you can view which shows how to protect a VVol VM between two VMAX All Flash arrays.
My setup is very simple since it was in a lab and I didn’t conform to all the best practices for RP4VM (which you should do of course). I have 2 vCenters, each with 2 ESXi hosts and each attached to a different VMAX All Flash. I am using a single NIC for both vSphere management and RP4VM. I deployed 2 vRPAs at each vCenter, representing SiteA and SiteB. Once deployed, I connected the sites which allows me to use both local and remote replication. Here is how RP4VM sees my environment:
I use 3 datastores at each vCenter: 2 VMFS (shared across both vCenters) and 1 unique VVol. Each vCenter is configured with its own VASA 2.0 Provider associated with a VMAX array. In order to use RP4VM with VVols you will need a VVol datastore at each site. Theoretically you could use the same VASA Provider in both vCenters and thus the same array, but that defeats the purpose of having a distinct DR site. The VMFS datastores are required because RP4VMs with the vSCSI write-splitter does not support putting the journals on VVol datastores. In the demo I point this out but here is the ESSM which notes it.
One final thing about using RP4VM with VVols and that is you cannot select a Storage Policy for your VM copy (remote or local) in the wizard. On the VMAX All Flash this really isn’t a concern but if you have a VMAX3 and use many different SLOs and thus Storage Policies, you could not, say, have your production VM be a Diamond SLO and the remote copy be a Bronze SLO. I did try some testing where I modified the shadow copy VM (the remote receiving the changes), but the changes never took. I was forced to conclude that you would have to change the policy after activating the remote VM.
So here is my walkthrough where I protect a VVol VM on SiteA to SiteB. In the demo you’ll occasionally see warnings or errors in the RP4VM plug-in – these are due to my lack of adherence to best practices. I’m afraid I don’t have a timeline for SRDF support of VVols. Certainly many customer will wish to wait for that, but this option is available in the meantime.
Dell PowerFlex and PowerMax with VMware 
Leave a Reply