SQL2012 – Hyper-V Replica

May 26th, 2012 by Stephen Jones Leave a reply »

Hyper-V Replica is a built-in, free, asynchronous virtual machine replication mechanism – a killer feature.

( This blog is an a bridged version of a ZDNET article by Aidan Finn a Microsoft Valuable Professional (MVP) with an expertise in Virtual Machine – http://www.zdnet.com/blog/microsoft/one-of-windows-server-2012s-secret-weapons-hyper-v-replica/12707)

The list of new features in Windows Server 2012 Hyper-V is staggering -one that stands out is Hyper-V Replica (HVR). HVR is built into Hyper-V at no extra cost and is designed specifically for  branch offices and small/mid-size enterprises that cannot afford an expensive SAN-based or host-based replication solution with their required expensive bandwidth.  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)  to replicate. VMs are usually just a few files and that makes these easy to replicate.

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.

Users might have  terabytes of data to replicate during the initial synchronization . If they have a small amount of data,then  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. They can alsorestore the VMs from backup in the DR site, and fix up the differences over the wire.

Customers can choose to keep multiple snapshots of a VM on the replica host, to choose a past version of a VM when they start it up in the DR site. (This would be useful when a VM is corrupted and that was the reason for invoking the business continuity plan.)

Users can choose to configure an isolated network for testing the DR replicas. 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. It is designed to replicate across unreliable links and users don’t want accidental invocation of the DR site because 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.

Advertisement

Comments are closed.