How Hyper-V Replica Actually Works

The series of posts on Hyper-V Replica:

• Part 1: Overview and benefits of using Hyper-V Replica
• Part 2: Requirements and facts of Hyper-V Replica
• Part 3: Enabling and configuring Hyper-V Replica
• Part 4: Virtual Machine Backup Vs Hyper-V Replica
• Part 5: Hyper-V Replica Failover Types

The Hypervisor or VMMS.exe is modular in design e.g. any component which understands VMMS API functions can work effectively. The Hypervisor code of the Hyper-V running on Windows Server 2012 has been modified to include replica components. The module “Replication Engine” has been included which comprises of four components. There are a number of other components operate in the “Replication Engine” module but the four important components of Hyper-V Replica, which play an important role when communicating with the Replica Server, replicating the changes to the Replica Server, and optimizing the network traffic, are “Replication Manager”, “Replication Tracker”, “Network Module” and “Change Tracking” as shown in the below screenshot.

Replication Manager (RM)

The “Replication Manager” is responsible for executing the replication related tasks against the virtual machines and making sure it handles failovers efficiently for the virtual machines. The “Replication Manager” implements the necessary functions for actions to be executed for the Primary Virtual Machines.

There are a number of actions executed internally. To handle each action, “Replication Manager” implements the necessary handlers as mentioned below:

• Initial Replication Handler
• Delta Replication Handler
• Failover Handler
• Failback Handler
• Test Failover Handler

It is important to understand that these handlers execute in a separate thread, but part of VMMS.EXE process, which allows them to accept incoming messages for specific actions. For example:

• “Failover Handler” is able to accept incoming messages for the failover for multiple virtual machines.
• “Initial Replication Handler” is used when you are enabling a virtual machine for replication and when virtual machine data is sent to the Replica Server initially.
• The “Delta Replication Handler” becomes active when initial replication is over. The task of this sub-component is to make sure replica copies are created.

In addition to above, Replication Manager provides the following functionality:

• Monitors the state of the Virtual Machines enabled for replication
• Retrieves metadata for each virtual machine which includes Standard-Replicas, Application-Consistent replicas, encryption, compression and source to destination storage mappings.
• Keeps a list of all the Primary Virtual Machines running on Primary Server and the list of VHD files which have been selected for replication for all Primary Virtual Machines.
• Keeps last successful replication information for each Primary Virtual Machine.
• Exposes APIs to handlers for vendors to implement any specific function.

Change Tracking

The “Change Tracking” component is responsible for tracking the changes to the virtual machine VHD files which have been enabled for the replication. The changes can be tracked for the multiple virtual machines concurrently. Once the changes have been tracked, they are forwarded to the “Replication Manager” which, in turn, activates “Delta Replication Handler” to create either Standard-Replica copies or Application-Consistent copies. The changes are tracked at the Virtual Machine level e.g. any changes (write operations) to the virtual machine are tracked and stored in the Hyper-V Replication Log files. This is sometimes referred as HRL. The HRL files are kept in the same directory where Virtual Machine VHD files reside. Each VHD file, which has been selected for the replication, has an associated HRL file.

Once the replicas/HRL files are ready, “Replication Manager” notifies “Replication Tracker” (RT) to send the copies to the Replica Server. The changes are tracked on the Primary Server and Change Tracking component has no function on the Replica Server!

Replication Tracker (RT)

Using the “Replication Tracker” component, replica copies (Standard and Application-Snapshots) are sent to the Replica Server. By default, replication happens every 5 minutes and this interval is not configurable. The only responsibility of this component is to send the HRL files generated by the “Change Tracking” module as explained above.

Network Module

Network Module looks after the networking between the Primary and Replica Servers providing the following services:

• Data compression
• Network communication between Primary and Replica Server either using HTTP or HTTPS
• Data encryption
• Providing necessary support for Hyper-V Replica Broker component

To provide the network communications between Primary and Replica Servers, “Network Module” implements HTTP client on Primary Server and HTTP Listener on “Replica Server” as shown in the above screenshot. The HTTP Listener running on the Replica Server listens for IR (Initial Replication) and DR (Delta Replication) messages. Both HTTP Listener and HTTP Client can work either using HTTP or HTTPS protocols.

Before the HRL files can be replicated from Primary to Replica Server, the Hyper-V Replica Server must authenticate successfully with the Primary Server using either over HTTP or HTTPS protocols. Once the Replica Server has authenticated successfully to the Primary Server, the authorization logic is used to check if the Replica Server is actually allowed to replicate from the Primary Server or not. The authorization logic is actually performed when you are enabling a virtual machine for Hyper-V replication and continue to use the same logic for subsequent replications.

Once the Hyper-V Replica and Primary Server establish a connection with each other, the “Change Tracking” component at Primary Server tracks the changes to the Primary Virtual Machine. If the Primary Server sees any changes to the VHD files of Primary Virtual Machine, those changes are sent to the Replica Server.

On arrival of the replica copy or HRL file from Primary Server, Replica Server receives the HRL files from the Primary Server. On the Replica Server, the changes occur in the asynchronous order meaning the processing of the HRL file happens in the reverse order allowing Replica Server to apply only the latest writes.

Replica Server must send an acknowledgement (ACK) back to the Primary Server stating that it has received the HRL file. You find warning event messages logged in the Event Viewer at Primary Server, if acknowledgment (ACK) for an HRL file is not received from the Replica Server.

The Primary Server continues to track the changes to VHD files of Primary Virtual Machines and maintaining the HRL log file for any other changes while the Replica Server is busy in receiving the previous HRL log file. The number of HRL log files maintained by the Primary Server for Primary Virtual Machine depends on what you select when configuring the “Recovery History” configuration page. If you have selected “Store only the latest recovery point” then only 1 HRL file is maintained and changes to the Primary Virtual Machine VHD file are merged into the VHD file at Replica Server.

The Volume Shadow Copy Service running on the Replica Server makes sure to take point in time snapshots for the Replica Virtual Machine to maintain the recovery history as you specify during the “Configure Recovery History” configuration page.

Conclusion

This article primarily focused on components of Hyper-V Replica which are included in the Hypervisor. We learned how Hyper-V Replica components operate. Change tracking mechanism is implemented as part of the “Change Tracking” component and how “Replication Manager” uses its handlers to implement the required functionality. We also learned about the “Replication Tracker” component which helps in replicating the changes to the Replica Servers.