Living in Texas at the bowling pin end of Tornado Alley, I’ve always been conscious of what would happen to my data should a disaster drop down from the sky. Before cloud-based backups, I did my own offsite backups by copying my Windows Home Server data to a large USB drive that I toted to my karate dojo and stored in a locked cabinet. Real businesses have more strict objectives, however. In the months of reconstruction taking place on the East Coast in the wake of Hurricane Sandy, IT departments up and down the coast are thinking about disaster recovery. How can they provide some degree of business continuity the next time wind and water invades their company? If you’re using Hyper-V for server virtualization, Windows Server 2012 has a feature you should immediately have a good look at: Hyper-V Replica.
Hyper-V Replica provides the ability to take a virtual machine (VM) on one Windows Server 2012 Hyper-V host and create a loosely coupled replica on another Windows Server 2012 Hyper-V host. “Loosely coupled” means the replica is not tightly in sync with the source; the latency is approximately five minutes or so when the replication channel is working correctly. With this replica in place, if the source VM fails with no warning, you can bring the replica online and have a very slightly older version available to customers almost immediately. If you have time to gracefully shut down the source VM and replicate its delta to the offsite replica, the failed-over VM will be identical to the source.
This approach sounds like a great idea, but the feature won’t be of much use if it has stringent infrastructure requirements. One of the major benefits of Hyper-V Replica is that it doesn’t have any dependencies on storage or network infrastructure. One end can have SAN storage with 10 gigabit Ethernet, the other a standalone Hyper-V host with direct attached storage on a 100 Mb network. What does the solution require? Two Windows Server 2012 Hyper-V hosts and network connectivity between them. That’s pretty much it. Hyper-V Replica is specifically designed to work over high-latency, restricted bandwidth networks such as WAN circuits to branch offices so you can easily configure replication across the data center, campus, or country.
You’re probably already thinking of ways you could use Hyper-V Replica. Offsite replication of a VM to another location is certainly the primary scenario Microsoft designed the feature for; this location could be another site within the company, or at a hosting provider, or even an IaaS cloud. A good small business example would have a business’s VMs replicated to their IT provider’s own network or data center, so in case of a disaster (or if the small business owner accidently breaks his own VM) a replica will keep the business running. You can also use Hyper-V Replica for planned failover if you’re doing host maintenance and don’t have a requirement for continuous availability during the maintenance window.
Hyper-V Replica works by first taking a shadow copy of the VM image and transferring it to the replica host. After this setup, the VM is kept up-to-date by copying a Hyper-V replica log file containing the VM’s writes to the replica’s host, which applies it to the VM (which is in a shutdown state). As nifty as Hyper-V Replica is, it can’t subvert the laws of physics, so it’ll obviously take longer for the initial transfer. There’s an option to perform the initial transfer using external media (e.g., a USB drive) so you can sidestep bandwidth limitations entirely and, for example, hand-carry the image to your Las Vegas replica location. (A useful maxim to remember in IT work is a quote by Andrew S. Tanenbaum, influential professor and author of the classic book Computer Networks: “Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.”) Aidan Finn has a nice description of the Hyper-V Replica feature in his blog.
Hyper-V Replica also works with the free Hyper-V Server 2012 product. Assuming you’ve taken care of the licensing that Hyper-V Server 2012 doesn’t provide for, it’s a feature-complete version of the hypervisor. You can have virtualizated disaster recovery at essentially no cost.
Hyper-V Replica isn’t designed to replace clustering or Live Migration. It’s specifically for disaster recovery situations. There’s latency between the source and replica VMs of at least five minutes (you can see the actual latency by right-clicking the replica VM, choosing Replication, and selecting View Replication Health.). Failover is a manual procedure, though I suppose you could script it. It’s also not really intended to handle large numbers of VMs.
Microsoft’s SMB organization recently published a blog post where Hyper-V Replica did in fact keep two small businesses available during Hurricane Sandy. These customers had recently upgraded to Windows Server 2012, and when they realized the full extent of what was about to hit them in lower Manhattan, they activated Hyper-V Replica and executed a planned failover to their IT service provider’s Brooklyn data center. Their actions kept their IT infrastructure up, and employees were able to access the network and work from home the entire time.
I think that Hyper-V Replica provides a strong benefit for small and medium businesses that need disaster recovery capabilities (and don’t we all?) but can’t afford to spend deeply on infrastructure and software for highly sophisticated solutions. It’s yet another tool in the Windows Server 2012 tool chest that makes it such a compelling product for companies of all sizes.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
