VMware vCenter Site Recovery Manager Broadens DR Duties

 
 
By Cameron Sturdevant  |  Posted 2012-06-14
 
 
 

VMware vCenter Site Recovery Manager Broadens DR Duties


VMware vCenter Site Recovery Manager 5.0 throws the virtual infrastructure leader into the fray to provide disaster recovery capabilities for lower-value second-tier applications while making user interface changes that cause the complex tool to be somewhat easier to use.

IT managers who already use Site Recovery Manager 4.x (SRM) will likely be impressed with the new automated failback and planned migration features while also finding that the improved user interface is easier to navigate.

 

To see more about how VMware SRM works, click here.

 

But make no mistake: Moving complex collections of virtual machines, data stores and networks from one location to another is tricky work, no matter what the breathy €œone-click€ marketers say. So, while eWEEK Labs tests showed that significant improvements have been made in the latest version of SRM, the product still requires extensive planning, testing and ongoing maintenance to ensure that when the €œone-click€ gets activated, the virtual infrastructure reliably migrates to and then actually works at the secondary site. And while the UI has been improved, SRM requires expert IT operators to implement, test and operate the product.

SRM 5.0 was released in September 2011 and updated in March 2012 to support a feature called €œforced failover€ along with a host of minor product improvements. SRM 5.0 Standard€”the lowest-priced option available from the VMware online store€”costs $5,899 and includes a 25-VM pack and one year of basic support. SRM is licensed per protected virtual machine (VM).

SRM 5.0 isn€™t the only tool in town when it comes to DR and business continuity. IT managers should be aware that all the competitors I talked to are also VMware partners. I can advise IT managers to be ready to hear a lot of diplomatic patter when it comes to understanding when one product would be better than another. Veeam€™s backup and replication tool works with both VMware and Microsoft Hyper-V environments and is licensed per CPU socket. VirtualSharp€™s ReliableDR focuses on certifying that applications will meet business recovery point objectives (RPO) after a failover.

Test Run

While SRM 5.0 can be evaluated in a small-scale environment in which two clusters substitute for actual sites, I went on-site to VMware€™s world headquarters in Palo Alto, Calif., to see the product in action. I also installed a small-scale test in the eWEEK Labs test bed in Foster City, Calif.

New in SRM 5.0 is vSphere Replication (VR). Whereas SRM before solely used storage array-based replication that requires relatively costly, mirrored storage hardware at both the protected and recovery site, the product can now use VR, which operates independent of the underlying storage system.

The VR feature is positioned as disaster recovery for lower-value VMs or for organizations that do not use storage array-based replication. I set up VR to use direct-attached storage in the eWEEK test lab. The lab and the VMware on-site test environment was set up using only vSphere 5.0 ESXi hosts. VR can only be used with vSphere 4. I deployed all the VR components, which includes a small number of special-purpose servers that I instantiated as virtual machines in the test environment.

SRM generally uses the concept of a €œprotection group€€”a collection of virtual machines and templates and a €œrecovery plan€ that specifies how the virtual machines in a protection group will be recovered. I set up protection groups specifically for my VR-protected virtual machines and followed procedures not too different from those already used by SRM to set up and run my recovery plans.

There are a number of moving parts in any DR product, and how these moving parts work together depends as much on technology as business rules, timing and operator ability. In the case of VR, IT managers should expect to spend nearly as much time crafting recovery plans as they would when using the previously available array-based replication tools. This is not due to a shortcoming in VR, but rather because effective recovery plans require expert planning and configuration, and that means a fair amount of human brain power needs to be applied to the problem.

VR is less complex, less capable and also less expensive than the array-based replication embodied in SRM. The new automated failback and planned migration capabilities along with the ability to cover linked clones don€™t exist in VR. Overall, however, the feature is a nice addition to the overall SRM 5.0 product and is unavailable, except as part of an SRM implementation.

SRM 5.0 Array-Based Replication Is the Flagship of VMware DR


Array-Based Replication

SRM 5.0 array-based replication is the flagship of VMware DR and now provides automated failback, planned migration and an improved boot-sequence controller along with other enhancements that reduce VM configuration time.

Using the VMware-provided test environment, I saw the entire SRM 5.0 setup process and observed live implementation of all aspects of SRM 5.0. Among the new features that I observed was the new automated failback function, also called €œreprotection.€ Reprotection is only available when using array-based replication, not the new VR feature.

After running a test failover with SRM in the operating in the context of an executed recovery plan, I was able to €œfailback€ to the original protected site. During tests of the fairly small and purpose-built test environment, this operation proceeded without problems.

Similarly, the €œplanned migration€ or slow-and-careful execution of a recovery plan proceeded without problems. Planned migration could be useful after acquiring a company or when a known event, such as an approaching hurricane, makes it possible to deliberately move from one site to another. The biggest advantage of using the planned migration mode was that if errors were encountered, such as inconsistent network configurations, the migration stopped to allow for a correction. When the recovery plan was re-executed, it started at the error stop point.

SRM 5.0 has been improved compared with SRM 4.x by now supporting up to four VM boot-sequence priority levels. Boot-sequence priority is a fairly blunt way to govern how VMs are restarted at the recovery site, thus making products like VirtualSharp€™s ReliableDR appealing for ensuring that business-critical applications come up in good working order. In tests, it was clear that IT managers who had been using SRM 4.x would benefit from the increased boot-order flexibility.

Click here to view a related slide show.

Rocket Fuel