Highly Available SCVMM - Proposed Setup B - Hyper-V Replica

The key ingredient here is Hyper-V Replica. This technology allows us to replicate a VM in a Hyper-V server to another Hyper-V server. We create everything as VMs and replicate. (It is simple, until we talk about failover later.)

The storage will not be as flexible as "Setup A" because this is using local disk space on the Hyper-V server itself.

Hyper-V Replica is designed for replicating VMs over slow links. Thus, it sometimes replicates in "bursts", which results in the replicated VMs "lagging behind" in the original VMs. But if there are not many changes in the original VMs, and the connection remains stable, the replicated VMs will "catch up" with the original VMs eventually.

The proposed setup...

Hyper-V Replica all the way...

About the failover, there is no automatic failover. Replicated VMs remained off, and need to be manually turned on. It is possible to script the turning on, but there are no inbuilt tools in Hyper-V Replica to decide whether the replicated VMs should be turned on or remained off.

To automate the failover, we need to code something that can detect/decide that the main server/site is down and then power up the replicated VMs. It is very easy to fall into split-brain scenarios if this is not done properly. Thus, I propose using Microsoft's Failover Cluster technology to maintain the quorum properly. Here is the proposed idea of maintain the quorums: 1 for single site, another for multi-site.

One way of maintaining quorum if using Hyper-V Replica

The idea is to run VMs for maintaining quorums, then write a script to periodically check where the quorum is. If the quorum is at the second node/site, script to turn on the replicate VMs gets executed.

Another challenge is that Hyper-V Replica exists outside of SCVMM. If a new VM is deployed via SCVMM, we cannot tell SCVMM to replicate it. We need to write our own code to detect a newly created VM and replicate it.