SQL AlwaysOn Availability Group support in VMDKs on NFS Datastores

Recently I had a customer contact me about doing SQL Always-On Availability Groups on Nutanix and they were wondering if it was supported due to the fact Nutanix recommend and run by default NFS datastores.

The customer did the right thing and investigated and came across the following VMware KB:

Microsoft Clustering on VMware vSphere: Guidelines for supported configurations (1037959)

The KB has the following table and the relevant section to MS SQL AAGs is highlighted.

SQLsupportnfs

As you can see the table indicates (incorrectly I might add) that SQL Always On Availability Groups are not supported on NFS when in fact the storage protocol is not relevant to non shared disk deployments.

The article goes onto provide further details about the supported clustering and vSphere versions as shown below with no further (obvious) mention of storage protocols.

pix1

However down the bottom of the article it states (as per the below screenshot):

3. In-Guest clustering solutions that do not use a shared-disk configuration, such as SQL Mirroring, SQL Server Always On Availability Group (Non-shared disk), and Exchange Database Availability Group (DAG), do not require explicit support statements from VMware.

pix2

As a result, SQL Always-On Availability Group non shared disk deployments are supported by VMware when deployed in VMDKs on NFS datastores (as are Exchange DAG deployments).

To ensure there is no further confusion, Michael Webster and I are currently working with VMware to have the KB updated so it is no longer confusing to customers with NFS storage.

For those of you wanting to learn more about Virtualizing SQL Server with vSphere, checkout my friend and colleague Michael Webster (VCDX#66) VMware Press book below.

virtualizing-sql-server-cover-small (1)

7 thoughts on “SQL AlwaysOn Availability Group support in VMDKs on NFS Datastores

  1. Hi Josh,

    The question is not if VMWare supports it. The main problem here is that Microsoft doesn’t support SQL / Exchange databases on datastores running NFS. Technically it all works well but Microsoft explicitly has the statement in their support..

  2. Pingback: Nutanix Platform Link-O-Rama | vcdx133.com

  3. Good afternoon Josh.
    Great article on a very confusing subject. I am currently looking into both SQL Always on and Exchange 2010 DAG’s setup within a virtual machine using non-shared disks.
    I think i understand the perspective from VMware’s point and as you have quite rightly stated above, VMware will support this.

    However Microsoft seem to suggest that they WILL NOT support Exchange 2010/2013 installed inside a virtual machine, severed from NFS storage. To me this seems very short sighted as the storage presentation to the hypervisor has very little consequence to the virtual machines.

    Have you covered this from a Microsoft perspective at all and i would be extremely interested to know once VMware publish their simplified KB article if Microsoft will endorse it.

    Many Thanks.
    Lee

  4. Hi Josh,

    In a recent version of the same article the position is updated.
    However, a note is added stating:
    “SQL Server AlwaysOn Availability Group on vSphere are supported only for non-shared Disk configurations, except when the system disk’s VMDK is located on a NFS datastore. Deployments with Shared Disk and SQL as FCI with AlwaysOn is not supported on vSphere.”
    Apparently it doesn’t matter where the SQL Server database files are, but the VMDK with the system can’t be carved out of NFS storage.
    I have no idea why and would appreciate any light you can shed on this.

    • Its safe to say that KB is poorly written article at best and VMDK on NFS for AAGs is perfectly fine and supported for 2012 onwards. For Old style clustering, Worst case, you would use In-guest iSCSI software initiators and you would be fully supported. The following is what the KB states:

      === START ===
      VMware fully supports a configuration of MSCS using in-guest iSCSI initiators, provided that all other configuration meets the documented and supported MSCS configuration. Using this configuration in VMware virtual machines is relatively similar to using it in physical environments. vMotion has not been tested by VMware with this configuration.
      === END ===

      Hope that helps.