I haven’t tested it, I’ll find out. But for SQL Server we would recommend FCI local site (clustering) with Availability Groups (replication) between sites. This will be application consistent, as anything we do at the storage level would only be crash consistent.
Thanks @vcdxnz001 would love to know.
So here lies the problem with using AAGs for DR form a business PoV…….. it’s up against current SAN technologies like HP 3Par Cluster Extensions. This gives you multi-site synchronous stretched cluster capabilities under a SQL Standard license model. That deals with HA and DR. So, when we look at our current SQL project the SAN looks very appealing because it could make the difference between our SQL project costing £150k in SQL licenses or £600k. If Nutanix requires an Enterprise SQL license to achieve the same HA/DR capabilities via AAG, then the reduced TCO of any move from SAN to Nutanix could be negated by a need to go Enterprise, assuming of course there's no other driver to go Enterprise.
The biggest problem with stretched cluster is the miantenance of the cluster itself. Unless you have two of them you can't guarantee non-disruptive operations for production and they are very complex to implement and maintain. So whatever you save up front you end up paying for over time in increased opex. Nutanix offers Metro availability that can be implemented with a few clicks and removes a lot of the problems with a traditional SAN based stretched cluster. However this doesn't work with SQL Clusters at this time, which require in-guest iSCSI access from Volume Groups.
With the release of our v4.5 OS today we now support Windows Failover Cluster with in-guest iSCSI access with MPIO. This will help with your project and for other customers that need to support traditional failover clustering instead of or in addition to Always On Availability Groups.