Server virtualization is rapidly becoming a key part of many organizations' disaster recovery (DR) strategy. This is for good reason, as the properties that make server virtualization so compelling in a consolidation effort also play naturally into streamlining DR as well.
That said, the use of server virtualization for DR purposes is not a "slam dunk" by any means. While server virtualization can help, it also poses its own unique set of challenges. In this article, we'll examine some of the benefits as well as some of the drawbacks that come out of using server virtualization as part of a DR plan.
Virtual machines (VMs) intrinsically possess two qualities that are quite beneficial to DR:
- Hardware independence: Virtual machines are naturally isolated from the underlying physical hardware by the very operation of the server virtualization software, granting them hardware independence.
- Encapsulation: Virtual machines are encapsulated into discrete storage areas. Depending upon the virtualization solution, this encapsulation may be in the form of files or specific LUNs.
Similarly, the fact that VMs are neatly encapsulated into discrete storage units can simplify the manipulation of those VMs for DR purposes. Need to get the VMs to the DR site? SAN replication software can often accomplish that trick, and usually more easily for VMs than for traditional physical servers due to hardware independence and encapsulation. To do this in a physical world would require extensive use of boot from SAN, which introduces a level of complexity many organizations don't wish to support.
However, server virtualization is not the magic panacea to DR that many hope it will be. There are challenges that arise out of the use of server virtualization that may be unique to DR.
First, consider the encapsulation property we discussed earlier in this article. While storage encapsulation can, in some cases, simplify the manipulation of VMs for DR purposes, it can also introduce complexities of its own. Consider the need to carefully coordinate storage array operations with the virtualization software itself, as described in my article, Avoiding storage array snapshot pitfalls in a VMware environment. If the storage array uses snapshots to handle replication, then care must be taken to ensure that consistent snapshots are taken so that valid and usable data arrives at the DR site. Otherwise, the DR site will be useless as it will have unusable, inconsistent, nonfunctional VM images. Note that this specific concern is more applicable in server virtualization scenarios than with physical servers attached to the SAN because of the extra layer of abstraction--the server virtualization software itself--that is involved.
Some server virtualization solutions impose certain procedural requirements that affect DR. While users may be able to replicate VM data from the production site to the DR site, will the server virtualization automatically recognize the presence of those VMs? Or are manual steps required to tell the server virtualization software that the VM data is present, and in what locations it can be found? The answer is most likely the latter instead of the former, and this is something that must be considered when using virtualization as part of an overall disaster recovery strategy.
Finally, it's important to note that while server virtualization does abstract many things -- the operating system instances from the underlying hardware, for example, and individual VMs from one another -- there are other pieces that are not virtualized or abstracted. Organizations must still deal with such everyday issues like IP address assignment.
Techniques such as using DHCP reservations -- a trick commonly used to control the IP addresses that servers have between the production and DR data centers -- have a ripple effect on other areas of the virtualization solution. Using DHCP reservations requires the use of static MAC addresses, and some virtualization solutions use dynamic MAC addresses by default. And this doesn't even take into consideration the management of static MAC address assignment.
Fortunately, a new crop of products, both from the server virtualization vendors themselves as well as from third-party developers, is arriving to help with these issues. Here are some examples:
- VMware recently introduced Site Recovery Manager (SRM), which provides a workflow automation tool to help with using VMware Infrastructure for DR purposes.
- A new version of Double-Take Software's Double-Take was released back in June to help address the use of Microsoft Hyper-V for DR. This new version provided the data replication necessary to create geo-clusters for DR failover.
Undoubtedly more ISVs will release products designed to further simplify and extend virtualization specifically for DR purposes as the server virtualization market continues to mature.
The key takeaway from this discussion is to remember that while server virtualization does simplify and enable some aspects of DR, it is not, in and of itself, a DR solution. Server virtualization should be considered only a part, a component, of an overall DR strategy.
About the author: Scott Lowe is a senior engineer for ePlus Technology, Inc. He has a broad range of experience, specializing in enterprise technologies such as storage area networks, server virtualization, directory services, and interoperability. Previously he was President and CTO of Mercurion Systems, an IT consulting firm, and CTO of iO Systems.
Dig Deeper on Disaster recovery, failover and high availability for virtual servers
Is software-based replication better for your DR setup?
Virtualization makes DR in the cloud an attractive option, but caution is advised
Deep dive into cloud-based DR
Put cloud disaster recovery within reach with nested virtualization