VMware Products Not Supported with SQL Server AlwaysOn Availability Groups
Recently I posted some updates to the supportability of Windows Server 2012 Clustering and SQL Server in particular in my articles titled Windows Server 2012 Failover Clustering Now Supported By VMware With Some Caveats and The Status of Microsoft Failover Clustering Support on VMware vSphere 5.1. VMware KB 1037959 Microsoft Clustering on VMware vSphere: Guidelines for Supported Configurations explains the configurations that are supported and provides guidelines. The reason for this article is because some people might think because these configurations are now supported on top of vSphere that somehow the configurations are also supported with vCenter and other VMware Products. Unfortunately this is not the case. In this article I’ll cover some background and where things are today.
In October 2012 I published an article titled Clustering Support on vCloud Director and vCenter Databases, which explains which products supported clustering of their databases. I didn’t cover every product, just a selection of the popular products, it also didn’t cover SQL Server Replication, Mirroring or AlwaysOn. For things like vCenter, VMware supports vCenter Server Heartbeat as the means of protecting both the vCenter Server itself and the vCenter Server Database (as well as a selection of related components). But you can’t use vCenter Server Heartbeat to protect the vCloud Director database for example, see Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!.
Clustering of the Database has not been tested or validated by VMware to date. VMware will attempt to help customers with their configurations even if it includes a clustered database, unless the clustering technology is believed to be at fault. If the clustering technology is believed to the cause of the fault you would need to contact the vendor of said clustering technology for further assistance.
So where does SQL Server 2012 AlwaysOn Availability Groups come into this picture? SQL Server 2012 AlwaysOn Availability Groups is basically a database availability technique using database replication with automated failover between the members of the availability group (depending on how you configure it). This doesn’t require shared disk clustering, which is why it got added as supported recently on top of Windows Server 2012 and on vSphere 5.1 platform. But in terms of using this for the databases that support your VMware products you’ll be in the same boat as mentioned above with clustering of the databases. VMware has not tested and validated the use of SQL Server 2012 AlwaysOn Availability Groups with their products. It may well work fine, like clustering does for many databases, but it could well break things as well. VMware will likely provide best efforts support up to the point that they believe that AlwaysOn Availability Groups might be causing an issue, at which point it’ll be time to log a call with Microsoft.
So we are all clear. SQL Server 2012 AlwaysOn Availability Groups is not currently tested, validated or supported by VMware for use with VMware’s products. This situation may or may not change in the future. If you wish to use this type of availability technique to protect your VMware products, such as vCenter DB, I would strongly recommend extremely thorough testing and that you weigh up the support risks. It would likely be a lot cheaper and easier to use vCenter Server Heartbeat, which would be my recommended solution for availability of the vCenter Server Database at least, and the other DB’s that vCenter Server Heartbeat supports. SQL Server 2012 AlwaysOn Availability Groups is supported to run on top of the vSphere 5.1 platform to provide database services to any application that supports this method of availability. As always feedback is appreciated.
This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.