Microsoft has developed a sort of hidden gem of a feature that allows for a Hyper-V virtual machine to be replicated between sites and requires no tools other than Failover Cluster Manager to initiate both failover and failback in a reliable way.
Limitations;
- This is a host-based feature and as such the hosts will be required to write to the primary site as well as process the replicated traffic to the secondary site. The generates more host load that using the array to process these changes. This is most pronounced during the initial sync as the entire VHD contents must be replicated.
- The Primary Site and the Secondary sites Hyper-V Hosts need to have Virtual Network Switches with the same names. This enables the VMs to failover and automatically connect to the correct network.
- This replica is an asynchronies mirror which can be either 30 seconds, 5 minutes, or 15-minute intervals behind the primary copy.
Advantages;
- The same tool commonly used to setup, monitor, and manage a Hyper-V Cluster is the tool used to control Hyper-V Replica, namely the ‘Failover Cluster Manager’.
- Hyper-V Replica is fully integrated with Hyper-V and copies not only the VHDs from site to site but also the full configuration which means that you do not need to run the time-consuming Import-VM process on the remote site.
- Since the VMs can be replicated at a granularity level, you can pick and choose which VMs to protect and which VMs not to protect. You can use different Replication timeframes for each VM as well. With array level replication the common granularity is a complete volume which may house many VMs.
Now lets start our discussion of how to setup Hyper-V Replica in the most simple way. Once we have this set up, I will dig deeper into how to optimize the settings to take advantages of Nimble Storage strengths to remove the sting from the listed limitations;
Basic Hyper-V Replica Setup
The most common Hyper-V environment you will encounter is a Widows Failover Cluster (between 2 and x Nodes) on Site A and another Windows Failover Cluster (between 2 and x Nodes) on Site B.
The other assumption is that you will be using a number of Cluster Shared Volumes (CSV)s to host the VMs.
The first step is to setup the Hyper-V Replica Broker Service on both Sites so that even when the VM moves from node to node in the cluster, it does not stop replicating.
To start the Hyper-V Replica Broker, from within the Failover Cluster Manager, open your Cluster, and right click Roles, and choose Configure Role.
You will need to supply the Hyper-V Replica Broker with a Name and IP Address.
Once the service is running, you will want to locate the Hyper-V Replica Broker from the roles list in Failover Cluster Manager, and right click and select ‘Replication Settings’
This HVR broker setup should be completed on both Site A and Site B. In my case, my Site A is called Seattle, while Site B is called Tacoma.
Once you have setup Hyper-V Replica, you can start using it. To enable replication on a specific VM, right click that VM in Failover Cluster manager, and choose ‘Replication’ and ‘Enable Replication’.
When asked for the destination of the HVR, you will put in the name previously used for the secondary site replica broker.
Once this has been selected, choose the replication method, (either Kerberose or Signed Certificate).
You will now be presented with the VHDs that are assigned to the VM and given the option to mirror only some of the VMs or all the VMs. In this basic setup we would choose all. We would also get to select the frequency of the replications.
We can now select if we want Hyper-V replica to maintain recovery points. This goes to the question of your needs for the Hyper-V replica. I would recommend not using the Microsoft recovery points, to get an idea of the base performance on the secondary site so that if you wish to enable it, you can determine if the performance hit of using these is worth it.
Now we can launch the initial replication either immediately or on a time delay. Once we select the time to start, we can hit finish and refresh Failover Manager and monitor the replication status.
You can also see that the VM is now available on the secondary site, but is offline while the replication is running.
You can now see what options are available for that particular VM. Note that the options that are available from Site A are different from those available from Site B. i.e. From Site A, you can initiate a planned failover, or pause the replication, etc..but from site B you can force a failover, as well as test a failover. See attached options. The below option list is from Site A
If we choose to failover our VM from Site A to Site B, the following options are presented from Site B
I should note that for the failover process to work, you will need to either do a VM shutdown or VM Turn Off before the failover or you will get an error. Note that the secondary site will restart and reboot the VM. Additional Note that a VM in Saved State is not good enough…. but hey, Maybe Microsoft will read this blog and add the ability to SAVE the VM and do a failover….(please guys).
Now lets choose to do a planned failover, and reverse the direction of the replica.
Ok, I will need to split this in to a multi-part series. This post completely covers the basic operation of Hyper-V replica, while the next post will address how to integrate all of this directly with Nimble Storage. We can use Nimble Storage to do the initial mirror of the VHDS from Site to site, as well as offer a very granular control of snapshots while also offering 1000 snapshots of each VM without affecting performance.
Part 2 of this Blog series is posted here; https://community.hpe.com/t5/Operating-System-Microsoft/Hyper-V-Replica-and-Nimble-Storage-Advanced-Features/td-p/7002101