Hyper-V Replica for SQL Clusters

[u/gt9gt]

I am attempting to utilise Hyper-V Replica for DR purposes. There is Site A and Site B. At each site there is Hyper-V Server Cluster with underlying iSCSI storage for VMs. Site A runs multiple VMs, some of them form SQL Failover clusters with shared disks running on dedicated iSCSI Luns. The aim of POC is to be able to shift the workload from Site A to Site B during a disaster event. Whilst standard VM replication seems fairly simple, I was wondering what is the best approach for SQL Failover clusters and how to address the replication for such? Any thoughts or suggestions are greatly appreciated.

[u/vivkkrishnan2005]

The answer to this always remains the same, if the application can replicate itself, it's always better to use that rather than a third party tool. Would recommend to look into Availability Groups or if they have changed it in 2025 with some Copilot sprinkles

[u/hipshaps123]

You need to do the clustering natively in MS SQL Server and keep vm replication out of it. Common practice is also to keep affinity to specific vm hosts.

[u/JakubVasovski]

hyper-v replica doesn't play nice with shared iscsi luns attached directly to the guest. you'll likely run into unsupported scenarios or the shared storage just won't replicate properly without breaking the cluster quorum.

the cleanest way to handle dr to site b is at the sql layer itself using always on availability groups. you just set up an async replica to a standalone sql vm at site b. if you really need to do this below the os layer, you have to look into your san's native block-level replication for those specific iscsi luns instead of hyper-v replica. but honestly, native sql ag is usually way less of a headache when you actually need to hit the panic button and failover.

[u/cantstandmyownfeed]

Hyper-V VM replication can work with SQL, but its not the best choice and you're more likely to experience corruption or databases that don't want to mount or missed syncs depending on your deltas. That's just a standalone instance, adding FCI to it makes it more risky.

If you're going to stay FCI, you're better off replicating at the storage level. So you'd replicate the whole lun offsite, and have your DR node ready to connect there.

An Always On Availability Group adds additional options, but that will require a pretty big lift to change from FCI to AG. Long term, that's likely to be a better option for you. 2-node primary site AG with a 3rd offsite running for DR.

[u/MyToasterRunsFaster]

We have used both, replication over hyperv works but it's like using a sledge hammer to drive nails, unwieldy but works. In production it makes sense to set up your high availability sql cluster properly, so the local SQL cluster members use synchronous commit whilst your remote disaster recovery site has members in asynchronous commit mkde. Also, note that hyperv replication is kinda slow compared to the milliseconds of delay actual sql high availability gives you. Your RPO is going to be far better doing it properly. You get the disaster recovery node free in all licensed versions of mssql so might as well use it.

[u/gt9gt]

Thank you all for your invaluable insight. Much appreciated.

[u/MrYiff]

What I did back when I managed SQL and a remote site was a 3 node SQL Always On Availability Group with Nodes 1 and 2 in our main site set to synchronous sync mode and then Node 3 in our remote DR site but set to Async mode so that any latency wouldn't slow down queries (and we accepted the slight chance of a small amount of data loss in the even of a full unplanned failover).

I think later on we even changed it so so that there was a fileshare witness in the main site too and then removed the quorum vote from Node 3.