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 prior to vCenter 5.5. 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.
[Updated 24/12/2013] As of vSphere 5.5 and vCenter 5.5 VMware has tested and now supported the use of SQL Server Database for vCenter on a traditional Microsoft Failover Cluster solution. This does not however include the use of Always on Availability Groups. Support for Always on Availability Groups may be included in a future release. Two KB articles cover this topic area. KB 1024051 Supported vCenter Server high availability options (Always On Availability Groups would only be covered by third party support as per other cluster configurations), and KB 2059560 Enabling Microsoft SQL Clustering Service in VMware vCenter Server 5.5.
Final Word
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.
Heartbeat is probably one of the worst VMware products out there. I would prefer a proven solution like SQL cluster anyway above heartbeat.
What is your justification for Heartbeat being one of the worst products? It's supported, more reliable and simpler to install and maintain than a Microsoft Failover Cluster and can easily work across geographic distances. So I'd much rather use it than a failover cluster to protect the DB for vCenter and the other relevant products now if I had a customer requirement that justified it.
vCloud is not the only cloud environment which doesn't support SQL 2012 AlwaysOn– Amazon RDS doesn't support it either.
But like it or not, cloud environments will need to support AlwaysOn, or supply equivalent functionality. Going forward, that will be the only method supplied by Microsoft, as database mirroring will be deprecated. (See http://msdn.microsoft.com/en-us/library/ms190202….
Since AlwaysOn is conceptually similar to MySQL readonly replicas, I suspect support by non-MS clouds is technically feasible, and may be forthcoming in the near future.
As covered in the article, SQL 2012 AlwaysOn is supported on top of the VMware Platform and can be used on top of vCloud Director no problem. It just can't be used as the database for vCloud Director or vCenter, or the other VMware products. There is no limitation such as the one with Amazon RDS.
Hi !
One another question. How is the Heartbeat cheaper ? Do you need 2 separate SQL Licences for AlwaysOn while you don't need it using Heartbeat ? I'm I right ?
Correct, as only one instance of SQL Server is running at any time. This is my understanding and you would need to check with your commercial team or license EULA on the specific terms and conditions. vCenter Server Heartbeat is also operationally cheaper and more flexible. I.e. easier, cheaper to maintain, in addition to being supported.