Hyper V Replica (What it is and What it Can Do)
As Director of Technology at Kelley Connect, is part of my job to evaluate new technologies and determine how they can help our clients and our business. One of the technologies in Windows 2012 I am most excited about is Hyper V Replica.
In this article, I’ll talk a little bit about what Hyper V Replica is and why you might want to use it. Then, we’ll walk through a basic Hyper-V Replication configuration and failover.
What is Hyper V Replica?
Back in 2012 Windows Server introduced a free feature called Hyper-V Replication.
This tool is a built-in replication mechanism at the virtual machine (VM) level. Also, it can asynchronously replicate a selected VM running at a primary site to a designated replica site across LAN/WAN (see figure below).
Here, both the Primary Site and Replica Site are Windows Server 2012 Hyper-V hosts. The Primary Site runs production VMs while the Replica Site is standing by with replicated VMs powered off and ready to be brought online should the primary site experience an outage.
Hyper-V Replica does not require shared storage, specific storage hardware, or shared domain membership, and can even replicate over most WAN links. Once an initial copy is replicated to a replica site and replication is ongoing, it will replicate only the changes of a configured primary VM asynchronously.
What Does Hyper V do?
“Hyper-V Replica is an integral part of the Hyper-V role. It contributes to your disaster recovery strategy by replicating virtual machines from one Hyper-V host server to another to keep your workloads available. Hyper-V Replica creates a copy of a live virtual machine to a replica offline virtual machine.”
About Asynchronous Replication
Asynchronous replication is the key reason why Hyper-V Replica is such a robust solution.
The replication process creates an identical VM in the Hyper-V Manager of the replica server. Subsequently the Hyper-V Replica change tracking module tracks and replicates the write-operations in the source VM every a few minutes after the last successful replication, regardless of whether the associated vhd files are hosted in SMB shares, Cluster Shared Volumes (CSVs), SANs, or with directly attached storage devices.
The slight delay in the replication process between replications allows for network latency and other minor network disruptions that can make synchronous replication impossible.
Why Use Hyper-V Replica?
Hyper-V Replica can help many businesses achieve their Business Continuity (BC) and Disaster Recovery (DR) goals.
In a BC scenario with a planned failover event of a primary VM, Hyper-V Replica will first copy any un-replicated changes to the replica VM in a way that produces no loss of data. Once the planned failover is completed, the replica VM will then become the primary VM and carry the workload.
From there, a reverse replication is automatically set. In a data backup and recovery services scenario with an unplanned outage of a primary VM, an operator will need to manually bring up the replicated VM.
In this situation there is likely to be a few seconds to a few minutes data loss, since changes to the primary VM not yet replicated to the replica VM may have been lost during the outage.
How to set up Hyper-V Replica
Setup is surprisingly simple. We’ll walk through the process below, assuming two Windows 2012 servers with Hyper-V role installed.
- Select a Windows Server 2012 Hyper-V host as the replica site and enable Hyper-V Replica in the Hyper-V settings on the host in Hyper-V Manager. The following are the sample settings of a replica site named “Development”.
- Using the Hyper-V Manager at the primary site, right-click a VM and choose Enable Replication, then walking through the wizard to to enable Hyper-V Replica and establish a replication relationship. The image below shows how to enable A-Selected-VM at the primary site, named “VDI”.
- Perform the initial replication of a target workload. If an initial copy is to be sent out over the network, this will happen in real-time or according to a schedule at the end of step 2.
- Conduct a Test Failover from the replica site by right-clicking the replicated VM and selecting the option to confirm readiness and process traffic.
- Conduct a Planned Failover event from the primary site after shutting down an intended source VM as shown below.
In the event that the source VM experiences an unexpected outage at a primary site, it is necessary to manually start the replicated VM at the replica site. In this scenario a reverse replication relationship will not be automatically established so any un-replicated changes will not be lost.
- Conduct another Planned Failover event to confirm that the reverse replication works. In the presented scenario, the planned failover will be from Development back to VDI. When the failover completes the resulting reversed replication relationship will return to the original configuration of VDI as a primary site with Development as the replica site.
If you want to learn more, here are some links to additional information.
Written by Tony Robison, Director of Technology for Kelley Connect