|
Page 1 of 2 Virtualized Disaster Recovery: Obvious Benefits, Hidden Obstacles By Don Norbeck published: Monday, November 30 2009
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.
|