Hyper-V Replica Overview
Published: May 31, 2012
Updated: March 10, 2015
Applies To: Windows Server 2012, Windows Server 2012 R2
This topic describes how to deploy Hyper-V Replica, a new feature of Hyper-V that replicates all changes on a virtual machine to a counterpart virtual machine hosted by a different server. It covers basic planning decisions and includes steps for preparing a virtualized environment for Replica, configuring and enabling replication, testing the deployment, performing planned failovers, and responding to unplanned failovers.
Hyper-V Replica provides asynchronous replication of Hyper-V virtual machines between two hosting servers. It is simple to configure and does not require either shared storage or any particular storage hardware. Any server workload that can be virtualized in Hyper-V can be replicated. Replication works over any ordinary IP-based network, and the replicated data can be encrypted during transmission. Hyper-V Replica works with standalone servers, failover clusters, or a mixture of both. The servers can be physically co-located or widely separated geographically. The physical servers do not need to be in the same domain, or even joined to any domain at all.
In this scenario, we define two “sites”: the “primary site,” which is the location where the virtualized environment normally operates; and the “Replica site,” which is the location of the server that will receive the replicated data. At the primary site, the primary server is the physical server that hosts one or more primary virtual machines. At the Replica site, the Replica server similarly hosts the Replica virtual machines.
Once replication is configured and enabled, an initial copy of data from the primary virtual machines must be sent to the Replica virtual machines. We call this “initial replication” and you can choose to accomplish it directly over the network or by copying the data to a physical device and transporting that to the Replica site.
When replication is underway, changes in the primary virtual machines are transmitted over the network periodically to the Replica virtual machines. The exact frequency varies depending on how long a replication cycle takes to finish (depending in turn on the network throughput, among other things), but generally, replication data is sent to the Replica server every 5 minutes in Windows Server 2012. In Windows Server 2012 R2, you can configure the replication frequency, so that the changes are sent every 30 seconds, every 5 minutes, or every 15 minutes.
You can choose to move operations on any primary virtual machine to its corresponding Replica virtual machine at any time, an action we call “planned failover.” In a planned failover, any un-replicated changes are first copied over to the Replica virtual machine and the primary virtual machine is shut down, so no loss of data occurs. After the planned failover, the Replica virtual machine takes over the workload; to provide similar protection for the virtual machine that is now servicing the workload, you configure “reverse replication” to send changes back to the primary virtual machine (once that comes back online).
If the primary server should fail unexpectedly, perhaps as a result of a major hardware failure or a natural disaster, you can bring up the Replica virtual machines to take over the workload—this is “unplanned failover.” In unplanned failover, there is the possibility of data loss, since there was no opportunity to copy over changes that might not have been replicated yet.
Starting in Windows Server 2012 R2, the frequency of replication, which previously was a fixed value, is configurable. You can set this value in the Configure Replication Frequency page of the Enable Replication wizard or in the Replication section for the virtual machine in Hyper-V Manager. You can configure the replication frequency so that the changes are sent every 30 seconds, every 5 minutes, or every 15 minutes.
You can also access recovery points up to 24 hours old (previously, recovery points up to 15 hours old were available).
You can configure extended replication. In extended replication, your Replica server forwards changes that occur on the primary virtual machines to a third server (the extended Replica server). After a planned or unplanned failover from the primary server to the Replica server, the extended Replica server provides further business continuity protection. As with ordinary replication, you configure extended replication by using Hyper-V Manager, Windows PowerShell (using the –Extended option), or WMI.
In practice, you configure the extended Replica server with a subset of the usual protection parameters. The extended Replica server offers most of the same features as the Replica server, though it does not support application-consistent replication and must use the same VHDs that the Replica server is using. You can fail over to the extended Replica server if both the primary and Replica servers go down; you can also perform a test failover to either the Replica or extended Replica server without disrupting workloads. You can move the target of replication from the extended Replica server to a different extended Replica server.
Because Hyper-V Replica is so simple and flexible, it can be used in a wide variety of potential scenarios of varying complexity. Some examples include:
Head office and branch office
In this scenario, there are two sites: a main head office and one or more branch offices in different physical locations. Taking advantages of virtualized workloads, Hyper-V Replica can be used to provide disaster recovery support for the branch offices. The servers at any of the sites can be clustered or standalone.
For this situation, day-to-day operations would run on the virtual machines running on primary servers at the various branch offices. Each branch office would have a Replica server standing by at the head office to take over the workload in the event that the primary server must go offline for any reason.
In Windows Server 2012 R2, you can extend this scenario further using extended replication. Each branch office would have its Replica server located nearby, which then uses extended replication to send changes to an extended Replica server back at the head office.
This scenario can be scaled up to involve large datacenters with many servers without requiring any different management activities with respect to Hyper-V Replica.
Cloud service provider
In this scenario, the hosting provider sets up a Replica server at their datacenter which receives replication data from a number of primary servers running virtualized workloads on the premises of their various customers. The hosting provider’s Replica server thereby provides disaster recovery capability for the customers who subscribe to it.
To assure security for the customers, this scenario would involve certificate-based authentication using certificates probably serviced by a separate certificate server owned by the hosting provider. In addition, the Trusted Group feature of Replica allows the hosting provider to segregate the replicated data from each customer, using separate storage locations and tagging to prevent data from various customers from being mixed.
You can set up replication of Hyper-V virtual machines as long as you have any two physical Windows Server 2012 or Windows Server 2012 R2 servers which support the Hyper-V role. The two (or three, in the case of extended replication) servers can be physically co-located or in completely separate geographical locations. Either (or both of) the primary and Replica servers can be part of a failover cluster and mixed standalone and clustered environments are supported.
No special software, other than Windows Server 2012 or Windows Server 2012 R2, is required. If you plan to use certificate-based authentication (required for the replicated data to be encrypted during transmission), you will need an appropriate certificate, which can either be local and self-signed, or supplied by a certificate server in your deployment.
This table contains links to related resources that explore other aspects of this feature, including blogs and forums where you can find the most up-to-date information.
Tools and settings