High Available (HA) is not a solution for Disaster Recovery (DR) and cannot replace DR. Actually HA is a component of a DR plan, which consists of processes, policies, procedures, backup and recovery plan, documentation, tests, best practices, and so on. The objective of a Disaster Recovery Plan is simply to have business continuity in case of any disaster.

In Windows Server 2012 and beyond, Microsoft addressed this challenge by offering an amazing solution into the platform called Hyper-V Replica making DR replication possible and affordable for all sized companies.

Hyper-V Replica introduces the ability to replicate a virtual machine asynchronously to a secondary Hyper-V host, such as a remote disaster recovery site, using a single network connection.

Hyper-V Replica is also applicable to a failover cluster. With a failover cluster of Hyper-V hosts in place, we need first to configure a Hyper-V Replica Broker role using Failover Cluster Manager.
Ordinarily, Hyper-V Replica can be enabled in the Hyper-V Settings of a Hyper-V Host. However, in a failover cluster, the Hyper-V Replica is grayed out in an individual Hyper-V host’s Hyper-V Settings. Instead, all Hyper-V Replica settings are to be managed through the Hyper-V Replica Broker.

Hyper-V Replica (Broker) isolated network for Hyper-V is not listed as requirement by Microsoft. However, you can throttle Hyper-V Replica Traffic by using the New-NetQosPolicy cmdlet, but I strongly recommend to isolate the replica traffic from the host Management OS to a dedicated network, and by leveraging the converged network in Hyper-V were combining multiple physical NICs with NIC teaming and QoS we can isolate each network traffic while maintaining resiliency.

In this blog post, we’ll look at how to isolate Hyper-V Replica in a cluster over a dedicated network.

Hyper-V Replica Cluster

To configure Hyper-V Replica Broker over a dedicated and isolated replication network, there are a few things you want to take into consideration.

1. Ensure you have adequate teamed network or converged fabric with vNIC dedicated to Hyper-V Replica network on each Hyper-V node. In this instance, I have a dedicated vNIC for Hyper-V Replica Network.

2. Before you install the Hyper-V Replica Broker Role. The Network in the cluster that will be used for Hyper-V Replica must be configured to ‘Allow clients to connect through this network’ in Failover Cluster Manager, Networks, as shown in the following screenshot:

3. In the Failover Cluster Manager, in the left pane, and while the cluster name is highlighted, click Configure Role in the Actions pane. The High Availability wizard opens. In the Select Role screen, select Hyper-V Replica Broker as shown in the following screenshot:

4. Complete the wizard, providing a NetBIOS name to be used as the connection point to the cluster (called a “client access point”), and the IP address that will be used for the Replica network.

5. Verify that the Hyper-V Replica Broker role comes online successfully and can fail over between all nodes of the cluster. To do this, right-click the role, point to Move, and then click Select Node. Then, select a node, and then click OK.

6. Configure your Hosts file to include the FQDN and NetBIOS names of each Hyper-V host that needs to be replicated “to and from”. In this scenario, you can have a standalone host and a cluster working as primary or replica server, or a cluster for each.
Hyper-V Replica (Broker) will still use DNS to resolve the names of each Hyper-V host and as a result will still resolve the Parent Management OS IP Address.

Do you want to influence and let Microsoft change the Hyper-V replication from DNS to IP based? if so, please vote at the Windows Server user voice page here, and let your voice shape the product development. Your vote is very important.

At the time of writing, the only option is to update the C:\windows\system32\drivers\etc\hosts file to include the replica network IP address on EVERY SINGLE HYPER-V Host. This will need to be configured identically on the corresponding Replica Site as well.

7. Open Failover Cluster Manager, right click on the Hyper-V Replica Broker, and select the Replication Settings action.

Enable replication on HTTP and/or HTTPS, depending on the trust level of the replication network based in your environment.

In the Authorization and storage section, as shown in the following screenshot, use the radio buttons to specify whether to allow any authenticated (primary) server to send replication data to this Replica server or to limit acceptance to data from specific primary servers. If you specify individual primary servers, you can designate a separate storage location for Replica data for each one, as well grouping them with the Trust Group tag.

8. Ensure the inbound TCP exception for port ‘80’ or ‘443’ is enabled in the firewall on every host that will be used as a member of the Hyper-V Replica. If you are using Windows Firewall, enable “Hyper-V Replica HTTPS Listener (TCP-In)” and “Hyper-V Replica HTTPS Listener (TCP-In)” rules.

9. If you need to route the replica traffic to another site, you will need to configure a persistent route to ensure Hyper-V Replica traffic will route correctly. You need to use the route command (route add) to configure a static route on all Hyper-V hosts. Open command prompt and type the following (update according to your environment).

route add 10.8.1.0 mask 255.255.255.0 172.16.20.1

If you want to remove a static route, you would type (route delete). To list all the routes, you would type (route print).

10. Once the Hyper-V Replica Cluster is configured on a dedicated network, you can enable replication for each virtual machine that you want to be replicated. The details of replication are configured on a per-virtual-machine basis, so each one can have slightly different settings.

11. Last but not least, check Task Manager Network performance to ensure that the Initial Replication is copying across the dedicated Hyper-V Replica Cluster Network.

Conclusion
By keeping the Hyper-V Replica traffic off your production network allows you to segregate and utilize more bandwidth without sharing it with the management OS network, but this does not mean that you will not see potential performance issues as the servers are replicating, but the impact will be much less especially when you isolate the replica traffic and throttle the network bandwidth of your Hyper-V hosts as described in this post.

As always, these tips and tricks are meant for guidance and process, actual results will vary based on your hardware and circuit types.

Charbel Nemnom is a Microsoft Cloud Consultant and Technical Evangelist, totally fan of the latest's IT platform solutions, accomplished hands-on technical professional with over 15 years of broad IT Infrastructure experience serving on and guiding technical teams to optimize performance of mission-critical enterprise systems. Excellent communicator adept at identifying business needs and bridging the gap between functional groups and technology to foster targeted and innovative IT project development. Well respected by peers through demonstrating passion for technology and performance improvement. Extensive practical knowledge of complex systems builds, network design and virtualization.