Clustering Support on vCloud Director and vCenter Databases

It was good to read recently on Duncan Epping’s blog Yellow Bricks that database clustering support for vCloud Director is added in version 5.1. vCloud Director now supports both Oracle RAC and also Microsoft Cluster Services or Microsoft Failover Clustering for MS SQL Server for it’s database. This was previously not supported in vCloud Director 1.0 and 1.5. But what is the support situation for all of the other components when it comes to database clustering, including vCenter Server?

The announcement regarding clustering support for vCloud Director 5.1 databases can be found in kb 2037802. It is really great that VMware has made it clear what the support situation is with no ambiguity.

Here is my understanding of the current state of play with regard to clustered database support (RAC and MSCS/MSFC) based on publicly available information (or lack thereof), this is for the main components of the VMware Cloud Suite that would generally be deployed in most environments:

Single Sign-On (SSO) – Not Supported, vCenter Server Heartbeat is the supported and recommended solution for database high availability

vCenter Server – Not Supported, vCenter Server Heartbeat is the supported and recommended solution for database high availability.

vCenter Server Virtual Appliance – Not Supported, No Database HA currently Supported

vCenter Update Manager – Not Supported, vCenter Server Heartbeat is the supported and recommended solution for database high availability

vCloud Director – Supported from version 5.1 both Oracle RAC and MSCS/MSFC

vCenter Chargeback – Oracle RAC Only from v1.6.2 (refer release notes)

vCenter Orchestrator – Oracle RAC 11g (refer kb 1022828), or vCenter Server Heartbeat

So what do I mean when I say Not Supported? I mean there is no explicit support statement from VMware that they have tested and verified the configuration with clustered databases at the time of writing this article. VMware will provide best efforts support and still help customers troubleshoot their environments. But like most vendors if they suspect a problem caused by the clustered database or clustering technology will refer the customer back to the vendor of that technology. I know many customers that are running vCenter with Oracle RAC databases at the back end successfully and have never had any problems, provided they set it up correctly and tested it, including failover scenarios (should be active/passive configuration). Likewise with a clustered MS SQL database customers have run that successfully as well with vCenter. In many cases the clustering of the database is completely transparent to the application. But that is not always the case depending on how the components connect to and communicate with their database.

When it comes to components that don’t use traditional ODBC connectivity to the database, such as SSO and the vCenter Virtual Appliance, support for clustered MS SQL databases is a bit more difficult. This seem to be primarily why in my opinion SSO is not currently supported with a MS SQL clustered database. For vCenter Server Virtual Appliance it doesn’t support MS SQL at all, but does support Oracle. Oracle RAC Support for the vCenter Server Virtual Appliance is currently going through validation from what I’ve heard and will in the future be supported.

Remember when it comes to support and VMware if something is not included in public documentation, including the product documentation and KB articles, and is not in the product interoperability matrix, then it is not supported. If the support statement isn’t explicit then you can assume that VMware will do everything they can to help (based on my experience and reading relevant kb’s), but it’s on a best efforts basis only.

I’ve mentioned vCenter Server Heartbeat a couple of times above. Some of you may also remember the article I wrote titled Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!. To ensure you’re aware of what components are supported for protection with vCenter Server Heartbeat I have included them below. This is directly from the vCenter Server Heartbeat Product Documentation. The case remains that if the component isn’t listed below it is not supported and only the databases relevant to the components below (if any) are supported for protection by vCenter Server Heartbeat.

vCenter Server Versions 5.1

■ VMware vCenter Inventory Service

■ VMware ADAM

■ VMware USB Arbitration Service

■ VMware vCenter Server

■ VMware vSphere Client

■ VMware vSphere Web Client

■ VMware vCenter Update Manager

■ VMware vSphere Update Manager Download Service

■ VMware vCenter Orchestrator Configuration

■ VMware vCenter Orchestrator Server

■ VMware vSphere ESXi Dump Collector

■ VMware Syslog Collector

■ VMware vSphere Auto Deploy

■ VMware vSphere Authentication Proxy

■ VMware vCenter Host Agent Pre-Upgrade Checker

■ VMware vCenter Single Sign On

■ VMware vSphere Profile-Driven Storage Service

■ RSA SSPI Service

■ View Composer 1.1, 2.0, 2.7, and 3.0

Note Remote deployment of View Composer is supported starting with View Composer 3.0

■ VMware View Composer

■ VMware Universal File Access

■ vCenter Converter Enterprise

When considering vCenter Server Heartbeat for your environment I would recommend you get VMware involved in the design and deployment, or at least someone (Partner / Consultant) that is experienced with it’s implementation (blatant plug: like my company). It provides great features and excellent availability but does introduce additional complexity. VMware or your preferred partner can help you navigate the complexity and ensure a robust handover to operations to ensure you get what you expect.

Final Word

Depending on the component there are different solutions to provide database high availability. There is no standard across the board between the different VMware components that make up the new vSphere 5.1 Cloud Suite. I expect as the suite develops we will start to see a lot more standardisation in this respect and to see more availability options. Careful consideration needs to be given to providing high availability when deploying the suite within current constraints. As and when the availability options change I will update this post.

Given that this has been based on the easily accessible and publicly available information it’s possible I’ve got something wrong. If so I’d be happy to correct it, so please let me know.

Note: Anyone who is wondering what MSFC is it’s the new term Microsoft use to name their clustering technology. In the past (Windows 2003 and previous) it was called Microsoft Cluster Services, and now it’s called Microsoft Failover Clustering. Many people use the term MSCS to describe both, but MSFC is vastly improved over the previous MSCS.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster. All rights reserved. Not to be reproduced for commercial purposes without written permission.