Business continuity strategy with Hyper-V

Any discussion of disaster recovery -- especially in the context of Microsoft's Hyper-V –- should note that there are few disaster recovery tools on the market. In terms of virtual platforms, VMware has the longest history and the greatest capability in the realm of automated disaster recovery. But many other virtual platform players leave disaster recovery to third-parties.

Microsoft's recent debut means that its ecosystem of third-party technologies is still developing. Despite the hypervisor's infancy, however, there are disaster recovery options for Hyper-V. This tip explains why Hyper-V is an excellent platform for business continuity, which components native to Hyper-V help implement a disaster recovery strategy and which additional tools you'll need to make a Hyper-V DR strategy run efficiently.

Basic disaster recovery concepts in virtual environments
In the context of virtualization, disaster recovery is essentially made up of three steps:

1. The regularly scheduled block-level backups of virtual servers.
2. The relocation of these backups to an alternate location.
3. The powering on of those virtual machines (VMs) after a disaster.

A successful disaster recovery plan closely monitors the scheduling and management of these steps as well as the maintenance of the virtual platform at an alternate site. If your organization has considered virtualization because of its disaster recovery potential, or if you want to add disaster recovery capabilities to your existing environment, you aren't alone.

Disaster recovery planning in Hyper-V
Microsoft's Hyper-V natively includes solid backup features that make it a capable platform for disaster recovery. Depending on your budget and the infrastructure at your alternate site, you have options for implementing a DR plan. With this in mind, let's outline what you need in place to add disaster recovery to Hyper-V virtualisation. Depending on your needs, you may find that there are fewer requirements than you think:

• A backup site. You must have a location to which you can divert processing after a disaster. Your backup site can be continuously connected to your data center via a network or fully isolated until needed. The stronger the connection, the faster you can return to operations after a disaster.
• Alternate servers and a virtual platform. The disaster recovery site must have the servers and virtual platform software necessary to host virtual machines after a disaster occurs. Once you construct your disaster recovery plan, this software and hardware can be either up and operational (at a higher cost) or contracted for quick delivery (and at a much lower cost).
• Virtual backup software. This is where Hyper-V shines. Its built-in Volume Shadow Copy Service (VSS) integrations ensure that backed-up virtual machines can successfully restore. VSS ensures a quick restoration of the virtual machine's operating system and applications like SQL and Exchange that reside on top of a VM.
• Replication software. Accomplishing the second step in the disaster recovery process means that virtual server backups must somehow make their way to your alternate site. For a low cost, it can be done through the manual transfer of tapes (or large hard drives). But for a higher price, you can leverage the automatic replication of backups over the network for a quicker return to operations.

Building a failover cluster with Hyper-V
Most disaster recovery plans involve a lot of manual or scripted activities to transfer the backed-up VMs and, later, to use the backup site. But Hyper-V's native technologies can automate the process further. Hyper-V's reliance on Windows Server Failover Clustering (WSFC) for load balancing and failover of its virtual machines is also a mechanism for disaster recovery -- if you have the needs, budget and skill to implement it.

In Windows Server 2008, WSFC can create a stretch cluster, or a GeoCluster. These clusters extend the boundaries of traditional clusters -- namely, the length of cable between cluster nodes and their shared storage -- to any location on a network. GeoClustering effectively means that cluster nodes can be located anywhere on a network, as long as the cluster's shared storage is replicated between locations. Splitting a cluster's nodes between sites means that a massive failure at your primary site will prompt an automatic restart of your secondary site's VMs.

Accomplishing the replication component of this type of clustering is no simple task -- and not one that Microsoft attempts to resolve itself. But Microsoft does recognize some third-party vendors that have created software that works from Double-Take Software, Neverfail and SteelEye Technology. Be aware that while this type of clustering provides a near-immediate return to operations after a disaster, it is also complex and requires special skill in terms of implementation and management.

So while install-and-go products that enable easy installation of disaster recovery for Hyper-V are still rare, there are inexpensive, homegrown solutions. Hyper-V is still in its first version release, which is why Microsoft's third-party ecosystem remains small. But with Hyper-V's growing adoption rate, you can expect that in 2009 many Microsoft partner software vendors will make substantial movement toward solving this problem.