Posey's Tips & Tricks
Is It Better To Use Replication or a Two-Node Cluster with Hyper-V?
Brien details the pros and cons of Hyper-V replication versus clustering, and what scenarios work best for each method.
For several years now, I have been using Hyper-V's replication feature to provide a degree of protection for my production virtual machines (VMs). So far, this setup has worked out really well for me. Recently, though, a friend asked why I was replicating VMs rather than building a two-node cluster out of my Hyper-V servers.
To be completely honest, the biggest reason I am using replication rather than building a two-node cluster is because two-node clusters weren't supported at the time that I adopted Hyper-V in my production environment. While it's true that my hardware is adequate for clustering, it would be really disruptive to take my production environment offline while I reconfigure the underlying infrastructure to act as a two-node cluster.
But what if I didn't already have a production infrastructure in place? Would I opt to create a two-node cluster or would I choose Hyper-V replication?
This is actually a difficult question to answer because replication and clustering each has its advantages and disadvantages.
The biggest advantage to building a cluster is that clustering allows Hyper-V VMs to failover automatically in the event that something happens to a host server. The Hyper-V replication feature doesn't allow VMs to failover automatically; failovers have to be initiated manually.
Another advantage to failover clustering is that failovers can occur without data loss. Both of the cluster's nodes share the same underlying storage. This means that if a failover occurs, the VM will be automatically live-migrated to a different host, but it will continue to use the same underlying storage.
In contrast, Hyper-V replication requires each replica host to have its own storage. VMs are replicated asynchronously. This means that if the Hyper-V host that a VM is running on were to fail, the administrator would be required to manually initiate the failover process. In doing so, however, any storage blocks that had not yet been replicated would be lost. Depending on the replication frequency (which the admin can configure) and the amount of time since the last successful replication cycle, you might lose anywhere from a few seconds to several minutes' worth of data.
So if failover clustering allows for an automatic failover and it does not have the potential for replication-related data loss, why do I prefer to use replication in my own environment as opposed to clustering?
Before I tell you my reasons, let me say upfront that even though Hyper-V replication is a good fit for my needs, it doesn't mean it is the best choice for everyone. Each organization needs to consider its own needs when determining how best to protect its VMs.
With that said, there are three main reasons I prefer to use Hyper-V replication in my own environment rather than build a cluster.
The first is because each replica host has its own storage. This means you never have to worry about a cluster-shared volume becoming a single point of failure. If a VM fails due to a storage problem, you can simply failover to a replica of the VM. Since the replica resides on a different host and on different hardware than the failed VM, there shouldn't be anything preventing the replica VM from starting.
Admittedly, there are solutions for making cluster-shared volumes resilient to failure. Even so, I like that the Hyper-V replica feature stores each replica on its own separate storage device.
Another reason I like the Hyper-V replica feature is that it makes it easy to create an offsite (or cloud-based) replica. Hyper-V supports three-way replication. If you are trying to protect an on-premises VM, then you can replicate the VM to an on-premises replica server, and use the replica server to create a secondary offsite replica of the VM.
Finally, replication makes it less likely for a failure to go unnoticed. Yes, I know that corporate IT departments use monitoring software to alert technicians to problems. However, I work out of my home and do not use any sort of monitoring software (other than a few PowerShell scripts). If I ran my Hyper-V VMs on a two-node cluster and a failure occurred, there is no telling when I would notice.
I have to confess that I'm not in the habit of checking my infrastructure health on a daily basis. Being that Hyper-V replicas require a manual failover, however, I would almost certainly notice problems with my host server right away.
Once again, the Hyper-V replica feature is a really good fit for my own organization, but it isn't the best fit for every organization. If an organization needs to prevent downtime at all costs, then it's best to use failover clustering instead of replication.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.