NAKIVO Blog > Hyper-V Administration and Backup > Hyper-V Replication and Failover Types: In-Depth Overview

Hyper-V Replication and Failover Types: In-Depth Overview

Hyper-V Replication is a feature that comes at no additional cost with Microsoft Hyper-V. This feature lets users implement a business continuity (BC) and disaster recovery (DR) plan built on replication to a remote host. Introduced with Microsoft Server 2012, Hyper-V Replication is popular with both SMBs and large enterprises.

When it comes to using Hyper-V Replica, there may be some misunderstandings about how best to use this feature and the purposes it serves. Replication can also be a source of confusion when trying to decide on other DR features like checkpoints and clustering. In this post, we cover:

• What is Hyper-V Replica?
• How does Hyper-V Replication work?
• When to use Hyper-V Replication
• What is Hyper-V Replica Failover?
• Types of Hyper-V Replica failover
• Alternative Hyper-V Replication solutions

What Is Hyper-V Replica?

Hyper-V replication is a disaster recovery feature available as part of Microsoft Hyper-V. The main role of Hyper-V replication is creating replicas of primary virtual machines to be stored on remote hosts for VM recovery when needed.

The primary host and the hosts with the replica VMs can reside on the same site or be located on different sites. An organization can set up and maintain its own replica site. Smaller organizations with limited budgets can choose to subscribe to disaster recovery as a service (DRaaS) from a managed service provider (MSP). In this case, disaster recovery using Hyper-V replication can also be another affordable option given the low requirements and ease of configuration.

How Does Hyper-V Replication Work?

To learn more about recovery metrics, download our white papers about RPO and RTO. You can also read the blog post about the difference between RPO and RTO.

Recovery points

By default, Hyper-V replication creates only one recovery point for a VM replica and updates the data of this recovery point at set time intervals. You can set multiple recovery points for a Hyper-V replica if needed. The minimum replication interval is not reduced in this case, but you can recover data for the needed recovery point. For example, you can set up to 24 recovery points for VM replicas with a 1-hour interval. The available Hyper-V replication time intervals are: every 30 seconds, 5 minutes, 10 minutes, 15 minutes or 1 hour.

Network

Replication data is transferred via the network from a host running the source VM to the host on which the VM replica is stored. For this reason, you must have high network bandwidth, which can be a challenge when using an internet connection between two geographically distributed sites. To avoid conflicts and split-brain situations, you should not run a source Hyper-V VM and a VM replica simultaneously.

VM replicas are usually connected to other networks and have IP addresses different from those used by the original VM.

Hyper-V replication process

• You can configure Hyper-V replication in Hyper-V Manager or System Center Virtual Machine Manager (SCVMM).
• When you enable Hyper-V replication for a VM, a VM replica is created on the secondary host, and a Hyper-V Replica Log (.HRL) file to track changes is created.
• When you replicate a VM for the first time, all VM data is copied from the source host to the target host.
• The next time the VM is replicated, only changed VHDX (or VHD) virtual disk data (increments) is copied to save replication time and amount of transferred data.
• A Hyper-V checkpoint (.AVDX) is created when replication starts (for subsequent replicas after the initial replication).
• When you create a new recovery point, and the oldest recovery point for a VM replica has expired, the oldest one is combined with the main virtual disk.

Recovery from a VM replica is performed manually when using native Hyper-V functionality.

When Is Hyper-V Replication Used?

Unlike Hyper-V clustering, where one running VM is located on shared storage and accessed by two Hyper-V hosts, Hyper-V replication uses two VM instances (a primary running VM and a VM replica that is in powered-off state during normal operation) located on the own storage of hosts (local storage, SAN, or NAS).

Download the ebook about Hyper-V clustering to learn how clustering works.

When not to use Hyper-V replication

You may not need to use a Hyper-V replica for VM failover if you run the following services on VMs:

• Active Directory Domain Controller. Choose native Active Directory replication options rather than using Hyper-V replication.
• MS SQL Server. You can use Hyper-V replicas for SQL Server protection. However, there is a native alternative solution to replicate SQL databases. Read the blog post about MS SQL Server Replication to learn more about the native replication feature. Selecting the right SQL replication method depends on your tasks and requirements.
• Microsoft Exchange. You may have problems if you use Hyper-V replication for VMs running Exchange. Choose the native Exchange replication technology.

Hyper-V replication flexibility

Hyper-V replication is flexible in terms of the multiple deployment variations it supports. It can be deployed between:

• Two standalone hosts
• A standalone host and a Hyper-V failover cluster
• Two Hyper-V failover clusters

Hyper-V replication is also flexible in terms of hardware requirements. The primary and secondary hosts do not require matching hardware components. Besides, extended replication is supported. This means that a secondary host can be the source of another replication to a third host, thus forming a daisy chain.

Hyper-V replication provides flexible granular protection. You can select specific VMs to be replicated and even select specific VM’s VHDX virtual disks.

What Is Hyper-V Replica Failover?

Hyper-V Replica Failover Types

• Test failovers
• Planned failovers
• Unplanned failovers

Each failover type is intended to meet specific needs.

Type 1: Test failovers

A test failover is used to validate replica VMs and test a disaster recovery plan. It should be carried out regularly. With test failovers, neither the running primary VM operation nor the replication process for the replica VM is impacted. Test failovers don’t interrupt production workloads and ongoing replication. A test VM is created to be examined in an isolated environment, including an isolated network. Once the IT admin stops the test failover for a replica VM, the created test VM is cleaned up.

Test failovers use the internal VM Export/Import feature of Hyper-V to create a new VM copy and then rename this VM. The test Hyper-V failover includes the following operations:

1. A VM replica including the VHDX, XML and other files is exported to a temporary location.
2. The XML file of the exported VM is modified to use a unique GUID.
3. The host registers the newly created VM with Hyper-V with the VMSS.exe process.
4. The VM is renamed.
5. The VM is imported to the same Hyper-V host.

The test VM remains in the powered-off state after the test failover, and you need to start the test VM manually.

Type 2: Planned failovers

Planned failovers are used to prepare for service availability during a disaster such as a hurricane or planned power outage, or to smoothly fail over from primary VMs to replicas during maintenance or datacenter migrations. Another possible reason to use a planned failover is related to compliance requirements.

During a planned failover, the primary VM is shut down, and the replica VM is forced to boot on the secondary host. The traffic is directed towards the secondary host, and VM workloads are moved to that host. There is no data loss when you use planned failover. Planned failover has zero RPO and RTO and requires only the time to replicate data and boot the VM after that.

A planned Hyper-V failover consists of the following actions:

1. A system administrator or user initiates failover.
2. The VMSS.exe Hyper-V process is notified about this action.
3. VMSS.exe requests Hyper-V VSS Writer to create a snapshot of the primary VM.
4. The VSS Writer creates a standard Hyper-V replica VM.
5. The Hyper-V Replica server is notified about this event.
6. The standard replica VM is copied to the Hyper-V replica server via the network.
7. The replica server registers the received VM replica and starts this VM replica.

Type 3: Unplanned failovers

An unplanned failover is started on the secondary server or site when an unexpected disaster brings down VMs on your primary server or site (power loss, hardware failure, ransomware attack, etc.). This Hyper-V replica failover type is also used to fail over a single failed VM to a secondary host. As in the case of a planned failover, the RTO is the time it takes to boot the VMs. However, when it comes to the RPO, the data since the last replication is lost. The maximum RPO is the configured replication interval, ranging from 30 seconds to 15 minutes.

After switching to a Hyper-V replica using failover, you have the option of running a failback operation when the primary server is back working. Failback starts reverse replication to copy the latest data from the replica server to the original server and move workloads back to the original server.

Alternative Hyper-V Replication Solutions

NAKIVO Backup & Replication is a universal data protection solution that supports Hyper-V, VMware vSphere, Nutanix AHV virtual environments, as well as Amazon EC2 and Linux/Windows physical machines. You can use the NAKIVO solution to manage replication of Hyper-V VMs, automatic failover, and disaster recovery orchestration using Site Recovery. Advanced features allow you to improve replication speed, reduce replication time and automate data protection operations.

Download the white paper about disaster recovery and automation by using VM replicas.

Conclusion

Disaster recovery by using VM replication and failover is affordable compared to clustering, allows you to recover VMs faster than from backup, but doesn’t provide high availability with zero downtime as when using a Hyper-V failover cluster.