In-Depth

Hyper-V Replica for Disaster Recovery

The replication feature Microsoft introduced in Windows Server 2012 provides business continuity. Though no substitute for failover clustering, it's an affordable option.

• By Brien Posey
• 12/09/2014

Although many small and midsize businesses run their workloads on virtualized servers, they haven't been able to take advantage of the fault tolerant capabilities of virtualization such as failover clustering. The licensing and hardware costs and technical complexity involved in building a clustered Hyper-V deployment tend to put failover clustering out of reach for smaller organizations. Fortunately, Hyper-V offers a replica feature that's well suited for helping smaller organizations improve their disaster readiness.

Appropriately called Hyper-V Replica, Microsoft introduced it with Windows Server 2012 R2 and upgraded it in the subsequent release. While it provides replication designed to ensure business continuity, Hyper-V Replica is not a substitute for failover clustering. If your organization has the budget to build a clustered Hyper-V deployment, you should definitely do so. Although there are similarities between replication and failover clustering, failover clustering is the preferred method for protecting your virtual machines (VMs).

Of course, that isn't to say the Hyper-V Replica feature is inadequate -- quite the contrary. I use Hyper-V Replica to protect my own VMs. I recommend the use of failover clustering whenever possible because a failover cluster's job is to make sure critical workloads never go offline. Replication won't guarantee that your VMs stay running in the event of a disaster, but it will give you at least one "spare copy" of your VMs, which you can launch at a moment's notice.

The Hyper-V Replica feature is based on the idea of asynchronously replicating a virtual disk from a primary site to a replica site. Although Microsoft refers to the source and target in terms of sites, it's important not to confuse the concept with Active Directory sites or geographic sites. In my own organization, for instance, my primary and replica "sites" exist within the same rack and on the same network segment.

The replication process occurs at the virtual hard disk level on an asynchronous basis. Once the initial copy process has been completed, replication occurs on a scheduled basis. In the version of Hyper-V Replica delivered with Windows Server 2012 R2, it's now possible for administrators to adjust the replication frequency. Replication can be scheduled to occur at 30-second, five-minute or 15-minute intervals. Intervals of 30 seconds do the best job of keeping the replica up-to-date, but aren't always appropriate. If the primary server is heavily utilized or if there's a slow link between the primary and the replica servers, then a longer duration replication frequency might work better.

Another improvement is the addition of Hyper-V Extended Replication. Extended Replication allows for the creation of a secondary replica. The most common use for this feature involves placing one replica within the local datacenter (so that it's easily accessible) and placing the secondary replica in a remote location (so that it's protected against datacenter-level disasters).

Planning Considerations
First, the server that will store your replica doesn't need to be 100 percent identical to your source server, but it needs to be capable of hosting your VMs if necessary. As such, you'll need to make sure the replica server has adequate hardware resources to ensure a good UX in the event that it ever has to be put into use.

Another important consideration is the authentication type that's used by the replication process. By default the replication process is based around the use of Kerberos and the HTTP protocol. If you require encryption, however, you might be better off using certificate-based authentication, which is based on HTTPS.

You'll also need to consider the initial synchronization process. Normally, you should be able to perform the initial synchronization process across the network. In the case of excessively large VMs, you're often better off using removable media to create the initial replica.

In addition, you'll need to consider other aspects of the replication process, such as the most appropriate frequency and whether you'll require extended replication.

Enabling Hyper-V Replication
The process of enabling Hyper-V replication involves performing various tasks on both the source server (the primary site) and the destination server (the replica site). Incidentally, the focus here is on Hyper-V replication in terms of a source server and a destination server, but you can replicate a VM to or from a cluster, or even between clusters so long as the Replication Broker is installed.

The destination server must be configured first. Open the Hyper-V Manager, select the listing for the destination host server and then click on the Hyper-V Settings link, found in the Actions pane. When the Host Server Settings dialog box opens, select the Replica Configuration container (see Figure 1).

Next, select the Enable this Computer as a Replica Server checkbox. You'll also need to select the type of authentication you want to use: allowing replication from any authorized server or specifying a list of Hyper-V servers from which you want to allow replication. Finally, click the Browse button and specify the location where you want to store the VMs. Click OK to complete the process. You might receive a warning message saying you need to configure your firewall to allow replication traffic.

The next thing you need to do is to open the Hyper-V Manager on the source server. Next, right click on the VM you want to replicate and select the Enable Replication command from the shortcut menu. You can replicate multiple VMs, but you'll need to enable replication separately for each VM.

At this point, Windows will launch the Enable Replication Wizard. Click Next to bypass the wizard's Welcome screen and you'll see a screen prompting you to enter the name of the replica server. Enter your destination server's name and click Next. When prompted to enter an authentication type, make sure to specify the same authentication method you used on the destination server and click Next.

You'll be asked if you want to compress the data sent across the network. Compression reduces bandwidth consumption, but slightly increases CPU utilization. It's usually a good idea to use compression. Make your selection and click Next.

The next screen you'll see asks you to specify the virtual hard disks you want to replicate. Remember, replication works on a per-virtual hard disk (not a per-VM) basis. Click Next and you'll be asked to specify your replication frequency. After doing so, click Next.

The following screen asks you to choose the number of recovery points you want to store for the VM. Creating recovery points allows you to revert the replica to an earlier point in time. Windows Server 2012 R2 allows up to 24 hours' worth of recovery points to be maintained (the previous limit was 15 hours). It's worth noting that the replica's storage requirements increase as you add recovery points.

Click Next and you'll be prompted to select the method you want to use for the initial synchronization process. After doing so, click Next. Assuming you're synchronizing across the network, you'll be asked when you'd like the replication process to begin. Make your selection and click Next. You should now see a summary screen displaying the replication options you've chosen. Take a moment to make sure everything is correct and click Finish. When you do, the VM Status should change to Initial Replication.

Replica Failover
As previously noted, replicas exist for disaster recovery purposes. As such, you can perform a planned failover or an unplanned failover. You can also perform a test failover.

A planned failover is useful in situations in which you need to take the primary host offline for maintenance. To do a planned failover, however, you need to first power down the VMs being replicated.

To perform a planned failover, right-click on the VM and select the Replication | Planned Failover commands from the shortcut menu. You'll see the dialog box in Figure 2 . You can complete the failover by simply clicking on the Fail Over button. However, it's usually a good idea to select the Reverse the Replication Direction After Failover checkbox first. This checkbox causes the source VM to become the replica and the replica to become the primary.

You can safely perform a planned failover at any time. An unplanned failover should only be performed in the event that your primary VM has suffered a catastrophic failure. The reason for this is that an unplanned failover does not perform a synchronization as part of the failover process. Consequently, any data not already synchronized will be lost. The amount of data lost depends on the length of your replication cycle and the volume of data that was added to the primary VM since the last successful replication cycle.

To perform an unplanned failover, open the Hyper-V Manager on the server that contains your VM replica. Right-click on the replica and select the Replication | Failover commands from the shortcut menu (see Figure 3). Next, choose the recovery point that you want to use for the failover and then click the Failover button.

It's a good idea to perform a test failover. A test failover doesn't actually result in a failover. Instead, the process creates a brand-new test VM. This test VM lacks network connectivity, so it can be safely powered on and tested. There's a VM named Mirage-Test (see Figure 4), which is a test VM.

You can perform a test failover by going to the replica server, right-clicking on the VM, and selecting the Replication | Test Failover commands from the shortcut menu. Upon doing so, you'll be asked to select the recovery point you want to test. Make your selection and click the Test Failover button.

When you're done with your tests, right-click on the destination VM (not the test VM) and select the Replication | Stop Test Failover commands from the shortcut menu. This will cause the test VM to be deleted and everything will be put back to normal.

Replica Resynchronization
If you're going to use the replication feature, I strongly recommend enabling the automatic resynchronization of replicas. Replicas occasionally fall out of sync, and the resynchronization feature can fix the problem whenever necessary. You can access this feature by right-clicking on your VM and selecting the Settings command from the shortcut menu. When the Settings dialog box appears, expand the Replication container to reveal the Resynchronization container. You can choose to manually resynchronize, automatically resynchronize or automatically resynchronize during a scheduled time.

The Hyper-V replica feature is relatively easy to use, but there are loads of features not covered here, which you should explore.