Anyone who has participated in a disaster recovery exercise is familiar with the pains of rebuilding an infrastructure...
from scratch. The little nuances of reinstalling and restoring application servers, bringing supporting services live and the possibility of bad or missing data can all cause an exercise to fail.
Virtualization removes the guesswork from standing up new production systems since you can use the systems you already have – the ones running in production and in good working order.
While VMware's disaster recovery tools work fairly well, what if you are a Hyper-V shop and want to use Microsoft's virtual machines (VMs) in your disaster recovery planning?
That's possible too – if you take the appropriate steps to implement a plan of action.
Understanding your approach to disaster recovery
The first step in disaster recovery planning is figuring out you environment's requirements. Is your organization dependant on a near immediate Recovery Point Objective (RPO) -- the point your data is restored to --or is your RPO around the mark of your last backup?
In addition, your Recovery Time Objective (RTO) -- the time it takes to come back online -- will impact your requirements for infrastructure and specialized software. Most likely, you have "tiered" your applications into categories of recovery -- from mission-critical servers at a Tier 1 to nice-to-haves at a Tier 3 or Tier 4, for example.
Hyper-V can be supported in all of these scenarios, but each of these implementations – and their cost -- are very different.
Non-critical servers and cold sites
Let's start with the easiest of the servers -- those that are considered non-critical or have a long RPO/RTO. This also includes a plan based in a cold site scenario, where you would have to rebuild your servers and network from scratch and rely on backups at the cold site recovery location.
The Hyper-V server can recover via a host server backup and a VM backup. The VM backup restoration is like a normal machine recovery, except that when a host is restored, all of the virtual hard disks (VHDs) and VM settings are restored as they were when you backed up. All the VMs must use Integration Services in order to access the Volume Shadow Copy Service (VSS) and have the VHDs come back in a consistent state. Certain applications, such as Microsoft Exchange, don't support this kind of backup because of the risk of inconsistent databases. These applications may require your tried-and-true restoration methods. (Note that you need to reconfigure your network, even when restoring the host, so good documentation is necessary.)
A set of quality scripts that transfer backed-up hosts or VMs are good targets for your disaster recovery planning. It's important to determine how the restore will get done and where those hosts land before you initiate it. Picking and choosing after you get there will only lead to confusion and a failed recovery.
Critical servers and aggressive recovery objectives
For applications that must be up -- and stay up -- turn to clustering or failover load balancing from one geographic location to another. This is an option for storage that's being replicated across locations. SAN-based replication is done to off-site storage, which may or may not be going to a full remote data center. The storage is attached to the host when a disaster is declared.
With Hyper-V virtual machines – unlike with standard physical servers -- VHDs can live on the replicated SAN . This allows for failover; simply bring the replicated SAN online and attach those VHDs to the host configurations with little data loss. Again, care must be taken because some applications will be in an unstable state and may require a true restore or another method of recovery.
In Hyper-V R2, you can use Cluster Shared Volumes (CSVs) with GeoClusters. This allows you to set up a Hyper-V cluster and span it across locations. While the benefit of this is automated failover, the downside is that it's complex and requires certain hardware. In other words, you need to have a warm site for failover with server and SAN equipment to match. The key to this technology is that the storage is replicated across sites. Once again though, there isn't a Microsoft solution for this storage problem. Fortunately, products from SteelEye Technology, EMC and other vendors address this issue.
The future cloud option
Another option on the horizon involves using Microsoft's Windows Azure, which may be headed toward supporting a form of disaster recovery without a site.
While a VHD can currently be moved into the Azure cloud, other issues -- such as private networking and time of recovery -- are still being worked on. In the future, although you may not be able to replicate your entire infrastructure, Windows Azure could prove to be valuable for certain components of the datacenter like websites and SQL Server databases.
Overall, while it's true that the disaster recovery solutions for Microsoft Hyper-V haven't yet reached the level of VMware, remember there is also quite a bit of scripting involved in a VMware restoration solution. Disaster recovery -- even a low cost plan -- can be developed with a little testing and a good understanding of your requirements. Become familiar with your options, as knowing how you manage your existing Hyper-V environment and planning the right strategy based on RTO and RPO objectives are crucial to success.
|Eric Beehler has been working in the IT industry since the mid-90's, and has been playing with computer technology well before that. His experience includes over nine years with Hewlett-Packard's Managed Services division, working with Fortune 500 companies to deliver network and server solutions and, most recently, I.T. experience in the insurance industry working on highly-available solutions and disaster recovery. He currently provides consulting and training through his co-ownership in Consortio Services, LLC.|