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:
- Your hardware must support the Hyper-V role in Server 2012.
- Your primary and replica servers must have sufficient storage and physical memory to host the VMs.
- You must have network connectivity between the locations hosting the primary and replica servers.
- Properly configured firewall rules must permit replication between the primary and replica sites.
- You must have an X.509v3 certificate to support mutual authentication with certificates (if desired or needed).
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.
- On the primary Hyper-V server, right-click the VM and select Enable Replication from the drop-down list to start the Enable Replication wizard for the VM.
- On the Specify Replica Server screen, enter either the NetBIOS name or the Fully Qualified Domain Name (FQDN) for the replica server in the Replica server box, and click Next.
- On the Specify Connection Parameters screen, input the port to use and the authentication type. As long as Remote WMI is enabled, these settings will be filled out for you. Ensure that you double-check them, because if they’re inaccurate, you’ll receive an error and the replica won’t work.
- The Choose Replication VHDs screen will list all of the .VHD files that the virtual machine has. You can select the disk or disks that you want to replicate for the VM, then click Next. Keep in mind that if you need to bring the replica up, any .VHDs that you didn’t select previously won’t appear. If the disk contains data that is important for the VM, it won’t be available.
- Replication changes are sent to a replica server every five minutes. On the Configure Recovery History screen, which Figure 3 shows, make selections for the number and types of recovery points to be sent to the replica server. If you choose Only the latest recovery point, only the parent VHD will be sent during initial replication and all changes will be merged into that VHD. If you choose Additional recovery points, you’ll need to set the number of additional recovery points (standard replicas) that will be saved on the replica server.
- On the Choose Initial Replication Method screen, which Figure 4 shows, several methods are available for performing an initial replication of the VM to the replica server. The default selection is Send initial copy over the network. This option starts replication immediately over the network to the replica server. If you don’t want to perform immediate replication, you can schedule it to occur at a specific time on a specific date. If you wish to not have the initial copy sent over the network, you can choose Send initial copy using external media. This option lets you copy the VM data to an external drive, DVD, USB stick, or other media and move it to the replica server.
- Click Finish. If the firewall port hasn’t been enabled, you’ll receive an error message.
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.- Prerequisite check:
- Check that the VM is turned off.
- Check configuration for allowing reverse replication.
- Actions:
- Send data that has not been replicated to replica server.
- Fail over to replica server.
- Reverse the replication direction.
- Start the replica VM.
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:- Replication State
- Replication Type
- Current Primary Server
- Current Replica Server
- Replication Health
- Statistics
- From Time
- To Time
- Average Size
- Maximum Size
- Average Latency
- Error Encountered
- Successful Replication Cycles
- Pending Replication
- Size of Data Yet To Be Replicated
- Last Synchronized At
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.
