In-Depth
Boxing, VVOLs And Replication
"Everyone has a plan until they get punched in the face." – Mike Tyson
Having a datacenter, rack, or even a single server go offline can be the IT equivalent of having Mike Tyson punch you in the face: it can send all your plans out the door. VMware has made business continuity one of its defining characteristics. They have developed many techniques and tools that allow businesses to continue to operate as usual after an outage. This may not seem like has any connection with Mike Tyson, but stay with me.
Let's talk about two useful business continuity tools: replication, which is the ability to make a copy of virtual machine (VM), and VMware's Site Recovery Manager (SRM), which has the ability to automatically restart replicated VMs on separate hardware in case of failure. Using these techniques, you can change the dynamics when a system goes down so that the effect is lessened from a punch in the face to a body blow-- painful but recoverable.
I recently held a BrightTALK (a roundtable webinar) about vSphere Virtual Volumes (VVOLs) with representatives from HP (Eric Siebert), Dell (David Glynn), NexGen (Ben Bolles) and NetApp (Joel Kaufman). The final question I asked each of them was "What one feature would you like to see in the next generation of VVOLs?"
They all agreed that they'd like to have it support array-based replication. VMware has made it very clear that array-based replication and Site Recovery Manager (SRM) are not interoperable with the current release of VVOLs. That said, vSphere replication is supported with VVOLs, and some arrays can replicate VVOLs outside of vSphere. This seems to be a contradiction, and has led to some confusion in the VMware community. Let's look at the various replication schemes and see how they work with VVOLs.
vSphere Replication
Let’s start by looking at vSphere replication. It was first introduced with SRM 5.0, and later included as a feature in vSphere 5.1. vSphere replication allows VMs to be replicated to another storage repository without the use of a Storage Replication Adapter (SRA).
vSphere replication is done at the VM level (SRAs replicate entire LUNs), and entirely within vSphere; it doesn't depend on any third-party hardware or software, but does have some limitations that SRAs don't have. SRM supports vSphere replication and VVOLs can use vSphere replication to make copies of VMs. VVOLs, however, is not interoperable with SRM, so any failover using vSphere replication would require manual run-book reconfiguration, since SRM and its orchestrated run-book automation feature is not supported with VVOLs.
Array-Side Replication
Next let’s look at array-side replication of VVOLs. As I mentioned earlier, SRAs aren't supported with the current release of VVOLs; however, this doesn't preclude array vendors from replicating VVOLs from one array to another using their own technology, and in fact many do. Rule-sets can surface capabilities that allow replication policies to be set on a per-VVOLs basis. This replication is handled and managed totally by the array; the rule is just describing a capability, nothing else.
As with vSphere replication, any VVOLs-based VMs that get replicated using array-side replication will need to be managed outside of vSphere and SRM for failover purposes.
The vendors I'm aware of that either currently or will shortly support array-side replication of VVOLss include NetApp, Nexenta, Nimble and SolidFire.
The net-net of this article is that at this time SRM and SRAs are not compatible with VVOLss, but you can replicate VVOLs-based VMs using vSphere replication and array-side replication techniques. You can use these replicated VMs for business continuity purposes, but all reconfiguration will need to be done manually.
Not a Knockout, But It Still Hurts
With VVOLs-based VMs you do have some business continuity protection, but at this time not as much as with traditional datastore-based VMs. Your datacenter will not be taking a debilitating Mike Tyson face punch that will send all your business continuity plans out the window, but it will still be taking a heavy and hard body shot.
About the Author
Tom Fenton has a wealth of hands-on IT experience gained over the past 30 years in a variety of technologies, with the past 20 years focusing on virtualization and storage. He previously worked as a Technical Marketing Manager for ControlUp. He also previously worked at VMware in Staff and Senior level positions. He has also worked as a Senior Validation Engineer with The Taneja Group, where he headed the Validation Service Lab and was instrumental in starting up its vSphere Virtual Volumes practice. He's on X @vDoppler.