Important Considerations Before Deploying Hyper-V Replication

0
Replication can be onsite or remote to support global availability.

Hyper-V Replication Feature allows companies to build their virtual machines highly available without the costs and complexities of physical replication. You may work in a multi-site company that needs to channel large amounts of data. Or your business can’t afford latency that can disrupt the end-user experience. In these cases, you would benefit from a Hyper-V Replica Server.

Virtualized Replica Servers allow you to create a digital copy of production servers and host them anywhere in the world and on the cloud. You can do this without worrying about hardware configurations exactly matching the original system, which is a tedious task. The administrator creates a copy and sends it to discrete data packets created by the virtual machine (VM) or physically ships it to a encrypted and password protected hard drive.

In this article, I will discuss Hyper-V replication and how it works. To understand the replication feature of Hyper-V, you must first understand what a replication server is!

What is a Replica Server?

A replica server replicates data from a master server. Scheduled updates or ad hoc requests push or pull the delta of data to each server. The data is checked against the main database for changes and then copied to the server that lacks it.

The data is often scheduled for after-hours replication to reduce disruption to operations. That said, if an end user is missing data, the server that needs it creates an “ad hoc” request. Depending on your needs, you can also create daisy chain replica servers to enhance this process.

To use a virtualized replica server, you will need to change the IP address, fully qualified domain name (FQDN), and a few other settings for your specific application solutions to make each server unique. You can then periodically push or pull the data to replicas to update it. If local users are assigned to access a replica server and not directly the master server, they can retrieve new data via a request from the replica.

Even though setting up Hyper-V replication is normally a simple process, you will need to make several important decisions before deploying it. let’s discuss 5 major considerations associated with the Hyper-V replication configuration.

1. How many replicas do you need?

The first decision you will need to make regarding Hyper-V replication is how many replicas you want to create. The more replicas you have, the less latency you will have, depending on the location of the replicas. You’ll also increase the number of users you can cater to without “system crashes” occurring.

If you decide to create a replica, it is extremely important to make sure you have enough bandwidth. This is to confirm that you can Track the change rate of data being replicated.

2. How much data can you afford to lose?

You can also use replicas to function as backup. To do this effectively, you need to consider how much data you can lose.

Replication aims to provide high availability for Hyper-V virtual machines. That said, some data loss is possible in certain situations.

When you create a Hyper-V Replica, you create a duplicate Hyper-V virtual machine that is synchronized with the primary copy that your company is actively using. If something happens to your primary Hyper-V host or virtual machine, you’ll be able to switch to the replica environment, avoiding a major outage, known as a failover.

You can experience 2 types of tipping.

1. Planned

It represents a graceful transition to virtual machine replica. If, for example, you needed to install patches on your primary VM host, you can perform a planned VM failover before doing so. This way you could reboot the host without disrupting your production workload. A planned failover does not cause any data loss.

2. Unplanned

This happens when a catastrophic situation takes your primary VM copy offline. You can quickly switch to the replicated VM in this situation. However, you will lose any data that has not yet been replicated.

That’s why you need to consider how much data you can afford to lose. When configuring Hyper-V replication, you must choose the replication frequency. Higher frequencies impose a heavier load on a Hyper-V environment, but result in less potential data loss during an unplanned failover.

Screenshot of Configure Replication Frequency options in Mirage.
Replication frequency determines how much data you could potentially lose during an unplanned failover.

3. Do you need point-in-time recovery capabilities?

Another consideration is whether you need point-in-time recovery capabilities. This recovery refers to your ability to restore a virtual machine to an earlier point in time. Normally your backup software handles point-in-time recovery, which is usually the best.

However, you can configure your VM replicas to create hourly recovery points that last 24 hours. You would use these replicas to restore a virtual machine to a previous state. This makes it easier to recover from a ransomware attack. You can also create app-aware recovery points every 4 hours.

Screenshot of Configure additional recovery points in Mirage
You can configure Hyper-V to provide limited point-in-time recovery capabilities.

4. Where will you store the replicas?

It is also important to determine where you will store your Hyper-V replicas.

By default, Hyper-V will attempt to store replicas on the host’s C: drive. You will need to choose a location with the required storage capacity. It must also provide a sufficient level of storage IOPS (input/output operations per second).

5. How will you create the initial replica?

Another major consideration is how you will create the initial replica of the virtual machine. By default, Hyper-V create the replica of the virtual machine by copying the contents of the original virtual machine over the network. This may be inconvenient if you are in a low bandwidth environment or if the virtual machine is very large.

Hyper-V allows you to compress data sent over the network if network bandwidth is an issue. You can also schedule the initial replication to occur during off-peak hours.

If you are not comfortable sending the initial replica over the network, you can create it using external media (like a backup tape). Another option is to use a existing virtual machine on the replica server as an initial copy.

Screenshot of Choose initial replication method options in Mirage.
Most organizations send the initial replica over the network.

Final Thoughts

Hyper-V replication is easy to configure. It can provide some failover capabilities businesses that may not have the budget or technical expertise typically required when building a failover cluster. Even so, you will need to do some planning before attempting to configure the replication process.

You need to consider how many replicas you want to create. Generally, the more you create, the less latency you will have. You should also consider how often you need to update your replica. If you choose to update it less often, you will increase your risk of data loss in the event of an unplanned failover. You also need to decide if you want to implement ad hoc features. Your final consideration is where you will store your replicas.

If you have more questions about Hyper-V replication, read our FAQ and Resources Sections to learn more.

FAQs

Will I lose data if I perform an unplanned failover?

You may experience data loss due to a unplanned failover. If you perform an unplanned failover, you lose any data that you haven’t replicated.

When should I use unplanned failover?

You should use unplanned failover when the primary replica is damaged or compromised and you need to reconnect quickly. This may result in the loss of a small amount of data. But it’s almost always faster to perform an unplanned failover than to restore a backup.

How do replica servers authenticate with each other?

When you configure Hyper-V replication, you must choose an authentication type. You can choose between Kerberos (HTTP) and CredSSP (certificate-based authentication). Kerberos is best if you manage your servers remotely (via RDP). However, if you decide to use Kerberos, it is important from a security perspective to implement constrained delegation.

What prevents me from using replication with large virtual machines?

Microsoft supports the use of Hyper-V replication with multi-terabyte virtual machines. However, keep in mind that larger VMs take longer to create the initial replica.

Which virtual machines should I not replicate?

A virtual machine with a high data change rate may not be suitable for use with Hyper-V’s replication feature. The replication engine may have trouble keeping up with all the changes. When this happens, the replication process stops. At best, you’ll have to resume the replication process manually. Depending on the amount of accumulated data, you may need to resynchronize the replica, which can be a lengthy process.

Resources

TechGenix: Article on Checking Hyper-V Integrity with PowerShell

Learn how to use PowerShell to maintain the integrity of Hyper-V replication.

TechGenix: Azure Backup and Hyper-V Replication article

Learn about the role of Azure Backup and Hyper-V Replication.

TechGenix: Article on Replication in Other Microsoft Products

Learn about replication options in other Microsoft products.

Microsoft: Hyper-V Replication Deployment Prerequisites article

Learn more about the Prerequisites for deploying Hyper-V replication.

Microsoft: article on using replicas for unplanned failover

Find out what it means use a replica for unplanned failover.

Share.

Comments are closed.