Configuring Hyper-V Replica in Windows Server 2012

This month, I want to talk about a new feature in Windows Server 2012 called Hyper-V Replica. This feature provides asynchronous replication over a network of virtual machines (VMs) for the purposes of disaster recovery. If a disaster occurs at a primary site, productivity can be quickly restored by bringing up the replicated VM at the “replica” site, as you see in Figure 1.

Figure 1: Hyper-V Replica At Work

One of the first points I want to bring up is that Hyper-V Replica is a disaster recovery solution and not a high availability solution. If the primary site goes down, manual intervention is needed to get the offsite VM replicas up. In a highly available solution (using multisite failover clustering), if the primary site goes down, the offsite VMs automatically come up without manual intervention. This is a question that we get quite a bit, so we wanted to clear up any misconceptions that you might have about what Hyper-V Replica offers.

Hyper-V Replica will track write operations on the primary VM and replicate these changes to the replica server every 5 minutes. The network connection between the two servers uses the HTTP or HTTPS protocol and supports both integrated and certificate-based authentication. So, at any point in time, the “replica” should be no more than 5 minutes behind.

Prerequisites

Hyper-V Replica is affordable and doesn’t require any complicated configurations. As long as both sites are running Server 2012 Hyper-V and have network connectivity between the two sites, it’s certainly a disaster recovery solution worth considering. Hyper-V Replica is available only in Server 2012 and not in the client (Windows 8) Hyper-V.To take advantage of Hyper-V Replica, you must meet the following prerequisites:

Set Up Hyper-V Replica

To set up Hyper-V Replica, you’ll need to go into the Hyper-V settings in Hyper-V Manager. In the right-hand pane of the dialog box that Figure 2 shows, you’ll see the Replication Configuration settings once it is enabled. By default, this configuration isn’t enabled.

Figure 2: Replication Configuration 

You’ll need to enable replication on both servers, and the settings will need to match. The first option to consider is Authentication and ports. You have the option of using Kerberos (HTTP) over port 80 or certificate-based authentication (HTTPS) over port 443. These are the default ports, but you can change them if desired. If you change the ports, you’ll also need to change the port numbers in the firewall rule (discussed later).

The other option is Authorization and storage. This setting determines which servers will be participating in the Hyper-V Replica. It also specifies the local folder where the replica files will reside. You can choose to use any authenticated server or specific servers. If you choose any server, you can specify a folder location here. If you choose specific servers, the Add button will let you specify a server and folder.

After you set everything up and click OK, a warning box states Inbound traffic needs to be allowed in the Firewall. There are two inbound firewall rules that are on a replica server: Hyper-V Replica HTTP Listener (TCP-In) and Hyper-V Replica HTTPS Listener (TCP-In). Depending on the Authentication and ports selection you make, the proper rule to enable will appear in the dialog box. These rules aren’t automatically enabled. If you don’t enable the rule, the primary server won’t be able to make the connection to the replica server. If you can’t make your connection as a replica, the firewall rule and the replica settings should be what you check first. The proper rule must be enabled, and the port it is using must also be configured. So, if you’re using a firewall that comes with another product, you need to ensure that the port is open. The same will need to be set for any routers or gateways between the servers.

Configure VMs for Replication

Once you’ve configured the Replication Configuration settings, you need to configure the VMs for replication. Hyper-V Replica is on a per-VM selection. You can have all VMs or a subset of VMs, but each must be configured separately.

Figure 3: The Configure Recovery History Screen

Figure 4: The Choose Initial Replication Method Screen

Once the wizard finishes, in the Hyper-V Manager console, you’ll see the name of the VM on both the primary and replica servers. You can change this nomenclature. Hyper-V Replica will track the VM by its Virtual Machine ID. So, on the primary server, you can have the name Windows8 and on the replica server, you can call it Windows8-Replica. On the replica server, you’ll see the VM and it will be turned off. The replica machines will be prevented from being turned on. If you attempt to turn on the VM, you’ll see the error message that Figure 5 shows.

Figure 5: Hyper-V Manager Error

Another popular question is whether you can set up multiple replicas. The answer is no: You can have only one primary replica server that the VM runs on, and one replica server that holds the copy of the VM. However, you can have multiple Hyper-V servers participating in a replica. For example, suppose I have a Hyper-V server called HyperV1 that is running two VMs (Acct-File-Server and HR-File-Server). I can also have two other Hyper-V servers called HyperV2 and HyperV3.

To set this up, I would need to go into the Hyper-V Settings on all the physical machines. Considering the example in Figure 2 above, if you’re configured for Allow replication from any authenticated server, you’re good. If you selected Allow replication from the specified servers, you’ll need to ensure that both of the other machines are in the list. When going through the Enable Replication for Acct-File-Server wizard, the Specify Replica Server page will show the HyperV2 server. When going through the Enable Replication for HR-File-Server wizard, the Specify Replica Server page would show the HyperV3 server. Figure 6 illustrates this scenario.

Figure 6: Multiple Replicas 

Now that everything is configured, what’s next? When you right-click a VM, you’ll see Replication in the drop-down list, along with several options depending on whether you’re on the primary server or the replica server. If you’re on the primary server, you’ll see the Planned Failover, Pause Replication, View Replication Health, and Remove Replication options. If you’re on the replica server, you’ll see the Failover, Test Failover, Pause Replication, View Replication Health, and Remove Replication options.

Planned Failover. A planned failover is a controlled action you take when you know that the primary Hyper-V server or site is going to be down. A planned failover will make the replica server the primary server, and vice versa. This action is only available on the primary replica server. There's a series of checks you need to make before a planned failover, as well as some actions that the process will take.

Failover. Failover is an action that occurs in the event of an unplanned outage. If the primary site goes down, you must select Failover from the secondary replica server on the VM so that it now becomes the primary site and will start. Once the primary site comes back up, you would select Planned Failover to reverse it back. This selection is available only on the replica server. An additional check will ensure that this is the proper action to take. Before it does this, it will try to contact the primary server. If it can’t contact the primary server, it will continue. If it can contact the primary server, it will determine whether the VM is on. If it’s on, it won’t continue. If Failover is chosen accidentally, you can choose Cancel Failover on the secondary replica server from the Replication drop-down list. Cancelling failover will result in the loss of any changes that occurred in the replica VM after the failover operation started.

Test Failover. This is a controlled action to take where you simply want to test that the replica VM on the replica site will come up. When you choose this action, it will create a new VM on the replica server and tag it with a -Test name so that it can be easily identified. This process might take a while because it copies the entire primary VM. Doing so allows the normal replication of changes to occur between the primary server and the original replica server. When you’re satisfied that it functions, you can simply power off the -Test VM and delete it from Hyper-V.

Pause Replication. This is a controlled action to take when you know that the replica server will be going down. Once the replica server is up, you can select Resume Replication. You can take this action on either the primary or replica server.

View Replication Health. This is an action you take to ensure that replication is working and that all the changes are getting across. These statistics can be reset, refreshed, or saved as a .CSV file. You can select this option from both the primary and replica server. You’ll see the following items in a popup dialog box:

Remove Replication. This is an action you would take if you no longer want to have a replica of the VM. You can perform this action on either the primary or replica server. When you’ve removed the replication, you’ll need to manually delete the VM from Hyper-V Manager.

Hyper-V Replica on a Failover Cluster

You can also use Hyper-V Replica on a Server 2012 failover cluster. To add a failover cluster, you must create the Replica Broker Role in Failover Management. Doing so will create a group in the cluster, to which you provide a Client Access Point (CAP) that includes the name you would connect to. This capability gives you the extra benefit of high availability for the replica or the primary site.

When running Hyper-V Replica on a failover cluster, you won’t be able to make any changes in the Hyper-V Manager console. When you go into Hyper-V Manager, Hyper-V Settings, and Enable Replication, everything will be grayed out. At the bottom of the window will be the message This server is part of a failover cluster. Use the Failover Cluster Manager to change replication settings. When running on a failover cluster, any Replica Configuration settings is only needed on only one of the cluster nodes. Because it’s a clustered resource, it will have all the changes replicated to the other nodes.

IP Addressing

The last thing I wanted to bring up deals with the network that the VMs reside on. You need to consider the IP address scheme on the networks of the primary and replica sites/servers. For example, suppose your primary Replica Server has an IP address scheme of 1.x and your secondary replica server has the IP address scheme of 192.168.x. If you use DHCP on the networks and the VM uses DHCP, it will get an address from the DHCP server when it comes up. This is the recommended setting for when Hyper-V Replica servers reside on different networks. If you use static IP addresses, you should set up multiple IP addresses for the VM (one for each network it will be a part of). If you bring up the properties of the VM, there is a new option under Network Adapter called Failover TCP/IP, as Figure 7 shows.

Figure 7: Failover TCP/IP 

This is necessary for the VM to communicate with the network it will be on. In the example above, if you have a VM with the IP address of 1.1.1.1 (running on the primary replica server) and it’s going to run the secondary replica server that uses 192.168.1.1, it won’t communicate properly on the network. It will have a different gateway, DNS server, and so on, that it might not be able to communicate with. This can also prevent clients from being able to communicate with the VM.

These VM Failover TCP/IP settings are the settings you would want to set for the replica server/site. The same Integration Services need to be running on both the primary and replica server in order to have the Failover TCP/IP settings give the proper IP Address to the virtual machine based on the server it is currently running on. When the VM is on the primary site, it will have the normal IP address you’ve set. If it moves to the replica site and starts, it will use the address information that is set under Failover TCP/IP.

Cost-Effective Option

There are a few key points to remember. Hyper-V Replica is a cost-effective option for disaster recovery of VMs. It isn’t an automatic failover to get the replica up; rather, it’s all about manual, administrative-controlled actions. You’ll need to ensure that you have enough disk space and memory, and you’ll need to consider the network scheme on the replica server to accommodate the VM if it needs to start. Hyper-V Replica is available only on Server 2012 and is not available with Windows 8 Hyper-V. You can go from a standalone Hyper-V Server to another standalone server. You can go between a failover cluster running Hyper-V to another failover cluster running Hyper-V. Or, you can mix the standalone Hyper-V server with the failover cluster running Hyper-V. Finally, remember that there’s only a primary and replica server. You can’t have multiple replicas for an individual VM.