Failback? Absolutely! Absolutely!

Since VMware released vCenter Site Recovery Manager (SRM) in June 2008, the product has gained tremendous momentum in customer adoption. Customers are impressed with the SRM capabilities that turn their manual disaster recovery (DR) runbook into automated recovery plans. They execute the recovery plans in test mode as frequently as they desire in order to eliminate any glitches in the plans. When a disaster happens, they are confident that SRM can be entrusted to seamlessly perform disaster recovery for them. (See below for the DR and SRM terminology used in this blog.)

With SRM failover capabilities, customers can successfully recover their workloads on Site B.  If you are one of those customers, do you wonder how to failback to Site A? I bet you do!

Do SRM customers need failback capabilities?  Absolutely!

Many SRM customers have told us at VMware that failback is important to them for reasons such as:

·         They do not rely on their recovery site for an extended period of time. When the Site A is recovered, customers prefer to have the workloads running on that site instead.  Site A (the primary site) is typically allocated more computing resources than Site B (the recovery site) and it is geographically closer to the business units.  From performance considerations, it makes sense to failback to Site A in many cases.

·         They may need to failover to Site B (in recovery mode) as part of their scheduled disaster recovery testing or maintenance.  Afterwards, they need to failback to Site A.

Does SRM v1.0 make failback easier? Absolutely!

From the customer feedback we gathered, we understand how important failback it is to our customers. Before then customers still have many options to streamline and expedite their failback process using SRM. Using SRM to perform failback provides tremendous values:

·         Automated recovery plan(s)

·         Automated testing before recovery

·         Built-in audit trail

Now you probably wonder what is involved in using SRM for failback. In a nutshell, SRM-assisted failback involves two directional reversals of protection: from Site B to Site A and then back to from Site A to Site B. In order to perform the directional reversal of protection to be from Site B to Site A, the following steps are involved:

1.       Reverse the replication direction in the storage layer to be from Site B to Site A

2.       Clean up the shadow virtual machines and protection groups on Site A

3.       Clean up the Recovery Plans configured on Site B

4.       Configure the protection group(s) on Site B

5.       Configure the Recovery Plans on Site A

6.       Test recovery from Site B to Site A

7.       Perform the recovery from Site B to Site A

Afterwards, you will need to perform steps 1 – 7 for the directional reversal of protection from Site A to Site B before you can call the failback done.  You can find more details on failback in the resources listed below:

·         Chapter 6 of SRM Evaluator’s Guide: http://www.vmware.com/pdf/srm_10_eval_guide.pdf

·         The storage vendors that implement SRA (Storage Replication Adaptor) for SRM also have individually produced documents that describe how to reverse the replication direction in the storage layer and how to leverage SRM to perform failback. Mike Laverick, author of the book “Administering VMware’s Site Recovery Manager”, has started a thread on the VMware SRM community forum to track a list of documents published by Storage Vendors on SRM: http://communities.vmware.com/message/1037176#1037176. The list includes some documents that describe how to perform failback using SRM on specific storage platforms.

You may think that the SRM-assisted failback steps illustrated above are not trivial to implement. Once you compare the man-time spent on SRM-assisted failback with the man-time on manual failback, you will appreciate the benefits of SRM-assisted failback. The table below lists the man-time estimates of the failback operations with and without SRM, assuming a protected environment of 100 virtual machines:

To perform all the steps listed in the table above in a protected environment of 100 virtual machines, the time estimates for SRM assisted operations and manual operations are 355 minutes and 1915 minutes respectively. The ratio is around 1 to 5. In other words, you can expect to spend 5 times as much time to perform failback if you opt for the manual operations instead of the SRM-assisted operations. This is a significant time saving, on top of the time saved on fixing human errors and the audit trails that you get with SRM.