I'm taking a couple weeks off before the busiest part of Microsoft's 2012 kicks into full gear. But never fear: The Microsoft watching will go on while I'm gone. I've asked a few illustrious members of the worldwide Microsoft community to share their insights via guest posts on a variety of topics -- from Windows Phone, to Hyper-V. Today's entry is all about Hyper-V Replica and is authored by Aidan Finn.
Think back to disasters such as the hurricane in New Orleans and the floods in Eastern Australia, where there were business and technology impacts of those disasters. Large datacenters probably had made significant investments to protect against such emergencies. But what about the small/medium enterprise (SME) or the corporate branch office that couldn’t afford these expensive solutions? Did they have somewhere to go? Did those businesses survive? What was the long term cost to their owners and shareholders?
The list of new features in Windows Server 2012 Hyper-V is staggering but the new one that stands out to me is Hyper-V Replica (HVR). HVR is built into Hyper-V at no extra cost and is designed specifically for those branch offices and small/mid-size enterprises that cannot afford an expensive SAN-based or host-based replication solution with their required expensive bandwidth. In fact, HVR has been designed to work on commercial broadband with no special hardware.
HVR can be configured via PowerShell (there are a lot of native PowerShell cmdlets for Hyper-V in Windows Server 2012) or in the GUI. Users configure each virtual machine (VM) that they want to replicate. VMs are usually just a few files and that makes them easy to replicate. No, you will not be able to use HVR with Passthrough disks, and this is another reason to be excited about 64 TB VHDX files with near physical disk performance.
Once enabled, HVR will do light weight logging of changes to the VM’s virtual hard disks. Every five minutes, Hyper-V Replica will attempt to replay that log file, containing the changes only, with compression enabled from the source host to the destination host to reduce bandwidth utilization. If the network connection is not available then HVR will reattempt to replicate for up to 30 minutes before it goes into a state that requires attention. This asynchronous method assumes that the Internet connection to the DR site is unreliable, as commercial broadband usually is. The combination of compression and change only replication is perfect for low cost connections that are the norm for branch offices and SMEs.
Microsoft remembered that users might have possibly terabytes of data to replicate during the initial synchronization and gave them a few options. If they have a small amount of data, they can do the first synchronization over the wire, with an additional option to schedule this for out-of-business hours. They can export the data to removable storage, preferably with BitLocker encryption to protect the data during transit. And they can restore the VMs from backup in the DR site, and fix up the differences over the wire.
Customers have some additional options when you configure HVR. They can choose to keep multiple snapshots of a VM on the replica host, allowing them to choose a past version of a VM when they start it up in the DR site. (This would be useful if a VM is corrupted and that was the reason for invoking the business continuity plan.)
Users can also choose to configure an isolated network for testing the DR replicas. With this enabled, they can start up test copies of the replica VMs in the DR site, and verify that their plans will work during an emergency without impacting on systems on the production network.
HVR does not have a heartbeat and does not start up DR VMs automatically. This makes sense because it is designed to replicate across unreliable links and users don’t want accidental invocation of the DR site because the ISP has one of those all-too-frequent brief outages. VMs are manually started, a process which can be sped up by using PowerShell or a System Center 2012 Orchestrator runbook.
HVR allows replication of VMs from standalone host to standalone host, from Hyper-V cluster to Hyper-V cluster, and from standalone host to Hyper-V cluster and vice versa. This opens up a lot of options. SMEs are more likely to have standalone virtualization hosts. Many hosting companies choose this option, too, because it allows them to offer very low cost hosting plans.
There are a few scenarios where HVR will be used. The SME will find HVR very appealing because it is free and can avail of low cost bandwidth. Those SMEs with two offices might choose to configure each one as the DR site for the other. Managed services partners or public cloud companies can choose to offer hosted DR services, availing of the optional HTTPS authentication and policy mechanisms in HVR, and building on additional add-ons such as remote access and remote backup. Corporations can also look at HVR as a way to provide economic DR replication either to a local DR site or to a central data center.
HVR is asynchronous replication. Therefore it won’t be suitable for those organizations that need zero data loss. HVR is also not intended for replicating from massive environments such as a public cloud. In this case, users can expect to find high end storage with built-in replication and plentiful low latency bandwidth that can replicate at the hardware level, which is more suitable for large amounts of data and constant VM change.
Hyper-V Replica is a built-in, free, asynchronous virtual machine replication mechanism that can offer something to SMEs, managed service partners, hosting companies, and corporations with branch offices. I think it is a killer feature because it is designed to work well in these environments and can solve problems for SMEs and complex environments, while offering service opportunities for Microsoft partners.aidanfinn.com, tweets as @joe_elway, and has written or contributed to books such as Mastering Hyper-V Deployment (Sybex, 2010) and Microsoft Private Cloud Computing (Sybex, 2012).