Compartilhar via


Hyper-V Replica

 

Applies To: Windows Server 2012 R2, Windows Server 2012

Hyper-V Replica is an integral part of the Hyper-V role. It asynchronously replicates Hyper-V virtual machines in a primary site to replica virtual machines in a secondary site

Requirements

  • Servers—You’ll need two servers running Windows Server 2012 or Windows Server 2012 R2 with the Hyper-V role.

  • Location—servers can be physically co-located or in completely separate geographical locations.

  • Topology—Primary, secondary, and extended Replica servers can be standalone or nodes in a failover cluster. A mix of standalone and clustered environments is supported.

  • Certificate—. If you plan to use certificate-based authentication (required for the replicated data to be encrypted during transmission), you’ll need a certificate which can be local and self-signed, or supplied by an internal CA.

Replication

. After you enable Hyper-V Replica for a specific virtual machine on the primary Hyper-V host server, initial replication begins to create an identical virtual machine in the secondary site. After the initial replication Hyper-V Replica maintains a log file for the virtual machine VHDs. The log file is replayed in reverse order to the replica VHD in accordance with the replication frequency. This log and reverse order means that the latest changes are stored and replicated asynchronously. If replication doesn’t occur in line with the expected frequency an alert is issued.

You can set up resynchronization settings for a virtual machine. This can be manual, automatic, or automatic within a specific schedule. Setting up automatic resynchronization is useful to fix ongoing synchronization issues.

Extended replication

Windows Server 2012 R2 introduced extended replication which allows multiple copies of data to protect from different outage scenarios. For example you might keep a second virtual machine replica in a close geographical location and a third copy more remotely.

In extended replication changes that occur on the primary virtual machines to the secondary site and to the the extended Replica server. If an outage occurs you can retrieve data from the extended replica as well as from the secondary, providing an additional layer of protection.

Note that:

  • The extended server doesn’t 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 run a test failover to the extended server just as you would to the secondary, without disrupting workloads.

  • You configure extended replication with Hyper-V Manager, Windows PowerShell (using the –Extended option), or WMI:

    • In the Hyper-V Manager console you extend replication for a specific virtual machine. You can set a replication frequency of 5 or 15 minutes. If you have a cluster you select the option for the virtual machine in the Failover Cluster Manager console.

    • In PowerShell you use the same cmdlet you used to configure replication (with a 5 or 15 minutes frequency):

      Enable-VMReplication –VMName <vmname> -ReplicaServerName <extended_server_name> -ReplicaServerPort <Auth_port> -AuthenticationType <Certificate/Kerberos> -ReplicationFrequencySec <300/900> [--other optional parameters if needed—]
      
  • You can monitor extended replication on the Replication tab in the Replica Site Hyper-V console. You can check status in the Hyper-V console -> Replication -> View Replication Health -> Extended Replication.

  • If you want to see the extended replication chain use this PowerShell cmdlet:

    Measure-VMReplication –VMName <name> -ReplicationRelationshipType Extended | select *
    

Failover

Failover isn’t automatic. You can manually different types of replication for a virtual machine:

  1. Test failover—Use to verify that a replica virtual machine can start successfully in the secondary site. It creates a duplicate test virtual machine during failover, and doesn’t impact regular production replication. After failover, if you select Failover on the replica test virtual machine it will be deleted.

  2. Planned failover—Use to fail over virtual machines during planned downtime or expected outages. You’ll need to turn off the primary machine before you run a planned failover. After the machine fails over Hyper-V Replica starts replicating the changes back to the primary server. The last set of tracked changes are sent to ensure zero data loss. At the end of the planned failover reverses replication begins so that the primary virtual machine becomes the secondary and vice versa, ensuring they’re synchronized.

  3. Unplanned failover—Use when unexpected outages occur. Unplanned failover is initiated on the replica virtual machine. It should only be used if the primary machine fails. A check verifies whether the primary machine is running. If recovery history is enabled you can recover to a previous point in time. During failover you should check that the recovery point is valid, and then complete the failover to ensure that recovery points are merged.

Test

Planned

Unplanned

When should it run?

To check that replica machines start as required.

To train your team.

To test failover and recovery processes.

According to organization or compliance requirements.

For planned outages

For impending disaster events

For host server maintenance.

When unexpected events occurs

Where is operation initiated?

Replica virtual machine

Initiated on primary and completed on secondary

Replica virtual machine

Is a duplicate machine created?

es

No

No

How long does it take?

Once a month

How often is recommended?

Once a month

Once every six months

Only in case of disaster

Does the primary machine continue to replicate?

Yes

Yes – with reverse replication back to the primary site after failover.

No

Is any data lost?

None

None

There can be depending on the event

Is there any downtime?

None

Planned downtime

Unplanned downtime

Recovery

When you configure replication for a virtual machine you specify the number of recovery points you want to store for it. Recovery points represent points in time from which you can recover data from a replicated machine. Recovering from early recovery points in effect reverts a replica. In Windows Server 2012 you can access recovery points up to 15 hours old. In Windows Server 2012 R2 this is extended to 24 hours.

Other useful resources

Content type

References

Product evaluation

Windows Server 2012 R2 and Windows Server 2012| Understand and Troubleshoot Hyper-V Replica

Planning

Prepare to Deploy Hyper-V Replica | Hyper-V Replica Feature Overview | Poster

Deployment

Deploy Hyper-V Replica

Troubleshooting

Hyper-V Replica Troubleshooting Guide

Tools and settings

Hyper-V Module for Windows PowerShell

Community resources

Ben Armstrong’s Virtual PC Guy's WebLog|

Virtualization Blog