Virtualized Disaster Recovery: Obvious Benefits, Hidden Obstacles
Virtualized Disaster Recovery: Obvious Benefits, Hidden Obstacles
By Don Norbeck
published: Monday, November 30 2009


Virtualized Disaster Recovery: Obvious Benefits, Hidden Obstacles

 

Introduction

Virtualization has been widely used to speed application deployment, improve IT utilization rates, and reduce costs.  Today’s “doing more with less” virtualized data centers require a closer management eye since problems on dense consolidated infrastructure impact more people – employees, partners and customers – then in more distributed, less utilized, and less stressed systems.

 

Just like their non-virtualized counterparts, virtualized infrastructures require a plan for when a business disruption or disaster strikes. Also like their non-virtualized counterparts, local redundancy while enhanced due to virtualization-enabled high availability and pooling of resources, only goes so far. It can never be a substitute for a second geographically segregated disaster recovery site. While the same disaster recovery tenets apply, the relative newness and consolidated nature of virtualized machines make individual components more critical and thus mandate a more deliberate and comprehensive approach using unique technology components to ensure a successful outcome.

 

The following is an executive level overview of Virtual Disaster Recovery (VDR) benefits and planning considerations  

 

Virtual Disaster Recovery – Benefits

 

The benefits of VDR are very apparent for those who have virtualized their production environments. Besides reaping the same cost and flexibility attributes that virtualization brought to the production environment, a second remote DR location tuned for virtualization can greatly benefit from the enhanced reliability and speed with which virtualized applications can be recovered on separate hardware platforms in a different location. This is critically important when time is of the essence - when a production data center becomes unavailable.

 

Going a little deeper, one of the core capabilities of virtualization is physical hardware abstraction.  This enables utilizing different hardware, brands or versions, so long as the x86/x64 chip set is consistent i.e., Dell to HP not AMD to Intel or HPUX to AIX. Virtualization greatly mitigates problems stemming from recovering a physical server on two disparate hardware brands, such as a Dell 2950 on an HP DL380 or even an HP DL380 to a DL580. Virtualization allows companies to mix and match their production and DR assets. Besides eliminating the need to buy two of everything and having to rigorously maintain all the system levels in lock step, organizations now can opportunistically provision their DR locations, even as “hand me downs,” from production or development. Further cost savings can be realized through provisioning with less robust equipment still capable of maintaining production in a limited capacity or for limited time until reinforcements can arrive.

 

Even further cost savings are possible if the DR site and strategy are architected where many resources are mapped to fewer. This “many to one” ratio, as it is sometimes called, allows companies to get the most out of a lesser number of servers compared to the production site.  This may be a reasonable approach for organizations that are unlikely to lose their entire production capability; or if they do, can operate in a degraded performance mode until the production site is available again.

 

Virtual Disaster Recovery – Organizational Planning Considerations

It is expected that organizations running virtualized production should recover in a like manner - virtual to virtual. But what about organizations that have a mix of both virtualized and traditionally hosted applications? As in most areas, complexity compounds as more methods of recovery are deployed.

 

The truth of the matter is that most organizations have important applications deployed both virtually and in native physical operating environments, some of which may never be virtualized. A disaster recovery plan must address both operating environments and establish recover point objectives (RPO) and recover time objectives (RTO) for the applications as well as interdependencies and recovery order. For example, an individual email server may have a low RTO and RPO for a particular business unit, but that server may play a vital part in a higher priority business process (such as order management).

 

An application’s RPO and RTO primarily drive the DR solution plan. While the DR solution components and method are influenced if production is hosted on a virtual machine (VM) or in a native operating environment, at the end of the day, the solution must account for these hosting factors and deliver the required RPO and RTO.

 

Ideally, a disaster recovery plan should leverage a single DR solution to recover an organization’s virtual machines and native hosted applications. In some cases this might be possible, but in most cases, the differences in operating environments, information criticality and information availability needs may make a tiered solution approach more practical.

 

That being said, however, it makes sense to leverage common DR solutions whenever possible. Look for common operational system environments, similar RPOs and RTOs, compatible application hosting capacity, and performance levels. An example would be leveraging one off-site back up and recovery solution that uses the same backup sets for physical and virtual protection versus a best-of-breed back up just for virtual. In a recovery, more steps differing process for restoration create more opportunities for human error or system/process failure.

 

Taking the example a step further, if one can find a common solution that can protect both virtualized and native applications having the above parameters, all the better. This solution could be described as hybrid solution offering both V to V, P to P or P to V recovery.

 

We touched on the high level DR planning aspect that an organization with virtualized applications should consider. It can be paraphrased as this: be sure to build a virtualized DR solution that integrates with your organization’s overall DR plan and leverages common solutions whenever possible.