Site Recovery Manager 5 and disaster recovery

Find out how VMware Site Recovery Manager Version 5 can help with disaster recovery and learn about the other key features SRM gained in vSphere Version 5.

Among VMware storage features, vCenter Site Recovery Manager (SRM) is ideally suited to disaster recovery (DR) use cases. SRM provides failover and fail back of virtual machine volumes, and it offers testing capabilities that won’t disrupt the working day.

Other VMware storage features introduced with vSphere 5 that are available to SRM users include array vendor-neutral replication with virtual machine-level granularity.

In this interview, Bureau Chief Antony Adshead speaks with Mike Laverick, an author, blogger, podcaster and public speaker who recently published a book on administering Site Recovery Manager 5, about VMware storage features in SRM that can help with disaster recovery and replication.

Play now:
Download for later:

Listen to the podcast on Site Recovery Manager 5

  • Internet Explorer: Right Click > Save Target As
  • Firefox: Right Click > Save Link As How can vCenter Site Recovery Manager help with disaster recovery?

Laverick: One of the early promises of virtualisation was to reduce the number of servers you would need at the disaster recovery location, and I think it’s fair to say VMware’s SRM has delivered on that promise.

The way it works is that it integrates with whoever your storage vendor is, whether it’s Dell, EMC or NetApp, to control the failing over and failing back of the volumes that actually contain your virtual machines. Major features include things like nondisruptive tests so you can carry out testing during product hours, where previously you would have to carve out a maintenance window to do this sort of work.

Introduced in Version 5 is a fail-back process that makes it very easy to move VMs from the production location to the recovery site and back again.

SRM has always supported a scripting feature so alongside the basics of the recovery plan which controls which VMs come up, what order they come up in, how long they wait before the next virtual machine starts, you can include things like VBS and PowerShell scripting inside the recovery plan for anything that’s particularly specific to your environment.

It’s also worth saying that SRM isn’t just about DR. Increasingly, customers are using it to move VMs from one data centre to another using the SRM tool for orchestration.

I can imagine that [in the future] SRM might lose its recovery element and become more of a site management tool facilitating the move of large numbers of VMs to a public cloud vendor or even being able to outsource your DR requirements to a cloud provider so when you do your recovery you’re recovering VMs not to a site in your own network but to an external provider. What new capabilities does Site Recovery Manager 5 have?

Laverick: The biggest change that affects storage people is that VMware has introduced replication into its vSphere platform, so customers that adopt SRM now have the choice of using array-based replication from EMC, Dell, NetApp and others or instead actually use replication that’s sitting in the virtualisation layer.

It’s an interesting move by VMware because it allows for more granularity than we’ve previously enjoyed. So, previously, when we did replication, it was the entirety of a volume or LUN that contained VMs, and the problem with that is you might not own the LUN or data store or volume. So, it’s more granular in that respect as it’s just the VM you’re protecting rather than all the VMs in a particular LUN.

Other advantages include that it is storage vendor-neutral, so you may have a few sites between which you want to replicate, and previously that might have been a bit tricky because they may not be using the same vendor storage at both sites, and even if they are they may not be using the same firmware, and that could have introduced complexities into getting SRM rolled out.

So, vSphere replication only sees the data store; it doesn’t care whether it’s NFS, iSCSI, Fibre Channel, whether it’s EMC or Dell or others providing that LUN, and it might make it easier for different business units within the organisation to replicate to each other as well.

Looking back to the earlier statement I made about the cloud, it’s going to be tricky to do replication from a private business to a public vendor and guarantee they’ll have the same storage and firmware. So, if they can agree to use a kind of replication that’s agnostic when it comes to the storage vendor, that might make it easier to work with a third party on your virtual infrastructure than is currently possible.

The last thing I’d say about vSphere replication is that it does have a sneakernet method of getting the virtual disks that make up a virtual machine to the DR location. You can take the virtual disks and put them on removable storage, ship that to the DR location and when DR replication is triggered, all it has to do is the deltas since that last copy.

So, there are some advanced features in there that you wouldn’t have with conventional storage vendors because VMware gives you access to the virtual disk.

Read more on Disaster recovery