- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
- Cannot delete a file or folder - Wed, Feb 22 2023
- Analyze Windows memory usage with RAMMap - Fri, Feb 3 2023
A DR strategy is an important part of your IT environment. Regardless of the size of your company, if your day-to-day business relies on IT infrastructure, for example, a cash desk application to sell your products and give the customer a ticket, you need to have a DR plan. DR plans consist of multiple steps, such as application, connectivity or hardware failure. In this post, we will take a closer look at how Hyper-V Replica can help mitigate hardware failures.
Requirements
Hyper-V Replica is an integral part of the Hyper-V role and is available at no extra cost. If you are running free Hyper-V Server Core to virtualize your environment, you can cover part of your DR strategy with Hyper-V Replica completely free, which is great, isn’t it? There are no special requirements, and all you need are two simple things:
- Solid connection between the servers
- Storage with decent IOPS
There are two factors that influence how fast your connection is and how many IOPS you need:
- Number of VMs you are about to replicate
- How often you need to synchronize the data. There are three options: 30 seconds, 5 or 15 minutes
For one of my clients with just two production VMs, we used an old DELL server with standard SATA disks with 7200rpm, configured in RAID10, and a 1Gbps network connection between the servers. Everything worked well, and we were able to reuse the old server, with free Hyper-V Server Core.
Configuring Replica server
Configuring Replica servers is a very easy task. In Hyper-V Manager, right-click your Hyper-V server and select Hyper-V Settings. In Replication Configuration, check Enable this computer as a Replica server. You can choose two authentication methods for incoming traffic, Kerberos or HTTPS. In my case, as I have both Hyper-V servers joined to a domain, I use Kerberos. In case you require encrypted traffic or your servers are not domain members, you should opt for HTTPS authentication. A valid certificate is required for HTTPS, either self-signed or issued by CA.
Replication configuration
Next, you need to select whether the server allows replication from any authenticated server, or only specific ones, and a folder where the Replica files should be stored.
Configure firewall
There are two firewall rules created by default:
- Hyper-V Replica HTTPS Listener (TCP-In) for Kerberos traffic
- Hyper-V Replica HTTPS Listener (TCP-In) for HTTPS traffic
If you left default ports in the Replication Configuration, simply enable the rule you need. Otherwise, you need to update the port in the rule.
Enabling VM replication
At this point, we are all set to start replicating. Connect Hyper-V Manager to your primary Hyper-V Server, right-click the VM you want to replicate and click Enable Replication… A configuration wizard appears that will guide you through the process. First, specify the name of the Replica server. In my case, it is HV2.EXIT.local.
Specify Replica Server
In Specify Connection Parameters, you can only decide whether you want to compress the traffic or not. The Authentication Type is based on what we configured in the Replication Configuration.
Specify connection parameters
Next, you can select virtual disks to replicate. Normally, you would want to replicate all disks.
Choose replication VHDs
In the next step, select how often you want to replicate the data. As previously mentioned, you have three options.
Configure replication frequency
In the first step, Configure Additional Recovery Points, you can choose whether to create additional recovery points and whether you want to create VSS snapshots. VSS snapshots are useful for consistent application recovery points (if the application supports VSS). By default, replication only maintains operating system consistency.
Configure additional recovery points
The last step is to configure the creation of the initial replica VM. In case you replicate over a WAN connection, you may export your VM to an external media rather than transferring all the data over to WAN. Additionally, you can schedule when to start the initial replication, for example, after office hours.
Choose initial replication method
Once the initial replication is finished, you may get the following message.
Replication enabled successfully
It says that network adapters are not connected to any network. This is because the Replica server does not have a virtual switch with the same name. If you create a virtual switch with the same name that the VM uses on the primary server, it will be automatically connected to the Replica server.
Performing failover
Once the replication is enabled and the initial transfer is complete, we can perform the failover operation. There are two options:
- Test Failover – used to verify that the replica VM can successfully start. This option creates a duplicate of the replica VM and is deleted once the test is complete.
- Failover – used in case issues occur with the primary Hyper-V server.
To perform the failover simply right click the replica VM and select Failover… or Test Failover…
Perform failover
A confirmation message will appear and warn you not to perform the failover unless the primary VM has failed. If you configured the replication to have more recovery points, you can select to failover to any of them. Click Fail Over to complete the process.
Failover
After performing the failover, the VM will start automatically. The VM now has a checkpoint created, and its failover status is complete. Once you verified that everything works, you can remove the checkpoint by right-clicking the VM and selecting Replication -> Remove recovery points…
At this point, the production is now running on the replica VM. Once you fix the issue with your primary server, you can reverse the replication back to your primary hardware. Note that you need to configure the server as a Replica server, the wizard will warn you again, and offer to perform the configuration.
Reverse replication
Once the reverse replication is finished, the current server will become your primary server. If you need to get the VM back to the original server, you need to perform another failover.
Subscribe to 4sysops newsletter!
Conclusion
Hyper-V Replica is a great, free DR feature and is easy to configure and use. In case you wish to have the replica VM in a third server, this is also possible with the Extended replication feature. For more information about Hyper-V Replica, you can refer to Microsoft docs website. There you will find an article written for Windows Server 2016, but this can also be applied to Windows Server 2019.
In my organization, we have found that enabling replication drastically reduces VM write performance.
I would be interested in knowing if you have had the same experience.
https://docs.microsoft.com/en-us/answers/questions/151871/enabling-replication-reduces-vm-write-speeds.html
Hello Eric,
I have used it on servers with standard SATA disks 7200RPM, RAID1, 1 Gbit network. Repliacation was set to every 15 minutes and we had no issues at all.
Normally, there should be no direct impact on write performace. Replication is not real time. Of course, if you configure the interval to be 1 minute and you have high IO demands, that might not be the ideal use case.
What interval do you use and how much data does the server write during that time? What is your network speed between the servers?
I agree. There shouldn't any difference when writing to the .hrl instead of the .vhdx.
I've tested this on several different hosts; with SSDs and 10k HDD, direct attached and SANs with high speed networks. Disk i/o will vary, but as soon as replication is enabled, write speeds suffer greatly. Then they recover when it is disabled.
I've tested this with 5 & 15 minute intervals. Resynchronization will of course take longer if I'm running a test at the time.
I did come across a post where someone else experienced the same issue, but the thread did not include a resolution and came to an end in 2016.
Note: On the hosts, the VHD folder structure has been excluded from virus/malware scanning.