Admins have plenty of ways to protect their virtual environment, but when disaster strikes the entire data center, vCenter Site Recovery Manager (SRM) from VMware is one offering that can get multiple virtual machines back into production with minimal downtime.
Of course, it's one thing to have a disaster recovery (DR) product in place, but it's entirely another prospect to make sure it is configured properly and will work as prescribed when the time comes.
Luke Huckaba blogs about SRM and other virtualization topics, and works as a virtualization architect for Rackspace. SearchVMware asked him about the different types of backup products and what skills an administrator would need to implement and manage SRM.
What are some ways to optimize SRM to deliver better recovery times?
Some of the best ways to bring your recovery time down is to do less with the virtual machines (VMs). VCenter SRM has a ton of features regarding changing IPs, running scripts from the SRM server or within the guest OS, but all of this adds time overhead.
Also, if the group of VMs you're recovering can all be spun up at the same time, you're better off leaving them in the default priority group of three. If you separate them into the five different groups, group one powers on first and won't move on to group two until group one is 100% successful.
I've tested array-based replication with NetApp's SnapMirror and EMC arrays with RecoverPoint and found they both behave about the same when running a recovery, as they both have to add the volume/data store to the host during the restore before importing the VMs.
If you use vSphere Replication, the storage piece is taken out of the equation. It actually runs pretty quick -- definitely faster than array-based replication -- but your recovery-time objective may suffer, and it's not designed for large enterprise environments.
Which products compete with vCenter SRM?
The first one [that] comes to mind is Zerto, and they offer a great product; you can even leverage in your SRM environment. I've pointed to SRM as an orchestration tool in the past as it doesn't really do any of the heavy lifting -- storage replication. It talks to different systems and tells everyone else what to do, while Zerto is pretty much a one-man show. It handles replication with the ability to choose point-in-time (PIT) recoveries.
EMC's RecoverPoint offers this, too, but it doesn't really work with SRM. If you have completely dissimilar environments between your production and DR locations, it may be worthwhile to look at Zerto instead of possibly spending tons of money to make your storage systems play together. Of course, you could use vSphere Replication with dissimilar storages, but your recovery-point objective (RPO) may be higher with it versus Zerto, and again, vSphere Replication isn't recommended for large environments.
Does SRM work with VMware VDP/VDPA for backup and recovery?
They're two different products aimed at two different scenarios. Think of SRM as full data center disaster recovery; it basically forklifts all your servers to a different [data center] and powers them up. It can recover a ton of VMs in minutes. I've seen 40 VMs recover in less than five minutes.
VDPA, on the other hand, can't recover a single VM that fast, much less all 40. However, if you need to pull some data out of the VM that was accidentally deleted, without having to restore all VMs in the protection group, VDPA can help.
SRM doesn't have a [point-in-time] recovery option, despite this being offered through vSphere Replication -- as well as other array-based replication options -- but VDP does. You can also have it hang on to those restore points for a while, just in case.
They can be great products to use together, but know [that] SRM is still the DR winner here, and VDPA is a backup solution.
Is vCenter SRM missing anything in either the configuration or the execution of a site recovery?
The number one complaint I have about SRM is the fact that you have to set your mappings on each site independently. For instance, when logged into your protected (source/production) site, you can map clusters, hosts, folders and port groups at the recovery (target/DR) site. That's awesome, right? Yes, you know exactly where all your production workloads will land; however, you have to log into the recovery site and set the mappings in a mirrored fashion. This is required for your failback -- reprotect and subsequent failover -- and will likely cause your reprotect to fail because it won't be able to create the placeholder VMs. That being said, I have a feeling that will be addressed in the next release of SRM.
Another complaint is its inability to export the configuration. If you want to migrate to a new server, your only option is to do a fresh install and point to the existing database. From a service provider's perspective, this is difficult if you want [to] move one customer to a different SRM pair. And by difficult, I mean rip and replace. If it's in your data center for you only, it's not that big of a deal.
As a scripter, I also wish there were PowerCLI cmdlets. They do allow you to connect to an SRM server via PowerCLI, but all the commands are more API driven.
Is vCenter SRM suited for recovery in multiple-hypervisor environments?
Not really. SRM is purely for VMware environments and cannot play with anything else. That's not to say you couldn't use some array-based replication to replicate the storage, but the orchestration will be owned by you. As long as you plan on using SRM for your VMware environment, you'll be fine.