This message was deleted.

I have run that a few times. It is a viable solution for DR. Some monitoring info may be lost if needing to swap to it though. You would need a 3rd site for the quorum share

We run that currently and it's fine so long as you are prepared for the manual failover to the secondary site for DR purposes. Just know what to do, it's not difficult at all. There are some oddities when doing failovers on the remote sites occasionally and need to keep an eye on the replications, but nothing show stopping. What I mean basically is that we have 2 - 2 node clusters. 1 cluster in each site. When failing over the DBs in the secondary site, the DBs on the remote secondary often (nearly always) forget to get replication from the remote primary. I have scripts that I run to get them all going again after a failover event, like after patching. Also, discovered that you want the cluster Host Server to be the same as the primary SQL server in the site. I found this because there was an issue with the cluster and the cluster decided that the SQL services needed to run on the same node as the Host Services, even though they were still running perfectly fine on the other node. As for the quorum, we are using Azure Cloud Witness and with 4 clusters we spend less than $1/month for all of the quorum witnesses. It happened to be that the cluster lost access to the Cloud Witness in the event mentioned above, which is why it decided to fail over SQL.

@Hal Lange @Dennis Parker thank you for the insight. I will let you know how it goes.