I’ve been doing a lot of work with vCenter Heartbeat recently, which is a product I really like and my customers appreciate and see a lot of value from. I was very fortunate to get an opportunity to speak to the product manager about the product in quite a lot of depth. While I can’t tell you anything that is covered by NDA, I can tell you some interesting and important information that has come out of these conversations. This is extremely relevant to vCloud Directory environments where SQL is being used as the database, and also Enterprise environments using vCenter Heartbeat that have other VMware Management Tools such as Site Recovery Manager.

VMware Best Practices and common sense both suggest it’s a good idea to build in availability for the databases that are the Achilles Heel of your virtual infrastructure, such as the databases for vCenter, vCloud Director, Site Recovery Manager, vCenter Configuration Manager, vCenter Chargeback etc. However in some cases for some of these products traditional DB high availability solutions such as SQL Mirroring or Failover Clustering are not supported by VMware.  So you might choose to just protect the database server with VMware HA, and that might be fine in most cases, even though the operating system instance then becomes a single point of failure and has to go down when some OS patches are applied. If your database can get by with only 1 vCPU you could also consider VMware FT.

One option that some customers may think might be viable is using vCenter Heartbeat to not only protect the vCenter Database, but also the database of the other VMware Management Tools and components (like vCloud Director, Chargeback or Site Recovery Manager). This would eliminate costly complex solutions and the outages that can sometimes be associated with them. This also has the advantage of minimizing SQL licenses, and also using a common protection mechanism for the vCenter System and also it’s database and the related database of the other management tools. I know of a number of customers that have done just this and used vCenter Heartbeat to protect their vCenter, vCloud, Chargeback, and other VMware Product DB’s. You might think this sounds like a good idea, but you would be wrong!

So I am clear: This is not a supported configuration and this is explicitly against the VMware vCenter Server Heartbeat EULA. vCenter Heartbeat can only be used to protect the remote SQL Databases of vCenter, Update Manager, and View Composer and only if running on the same shared database instance and server.

So can you still run a single shared Database server for all the VMware SQL DB’s? Yes you can, but you must have two or more SQL instances installed on the shared SQL server. One instance for the Heartbeat Supported DB’s that can be protected by vCenter Heartbeat, and another SQL instance (or more) for the DB’s of the products that can’t be protected by vCenter Heartbeat. This might not be an optimal or feasible design choice, but it is supported. The only other alternative is completely separate DB servers for the vCenter Server Heartbeat supported SQL Database schemas (vCenter, Update Manager, View Composer), and one or more for everything else.

All of the supported plug-ins and components that can be protected are listed in the vCenter Heartbeat Installation Guide. You will not see the DB’s for Site Recovery Manager, Chargeback, vCloud Director, Configuration Manager or VMware Service Manager listed as supported, because they are not. You will also not see the View Events Database listed as supported either.

Perhaps the product marketing blurb on the VMware web site could be made more clear, I have quoted below and was current as at 30/03/2012 (03/30/2012):

“Ensure Availability and Disaster Recovery

VMware vCenter Server Heartbeat delivers high availability and disaster recovery for VMware vCenter Server and all of its components across the LAN or WAN, including the database and plug-ins like VMware vSphere Update Manager, eliminating costly, complex outages. VMware vCenter Server Heartbeat protects and recovers the VMware vCenter Server database instance, even if it’s installed on a separate server.”

It’s the “plug-ins like VMware vSphere Update Manager” statement that could be a little bit misleading. Just be aware this doesn’t mean you can use it for protecting the database of things like vCloud Director.

Another important thing to note about vCenter Heartbeat is that it only supports protecting SQL 2008 R2, not SQL 2008 R2 SP1, although it does support Windows 2008 R2 SP1. Some of the VMware Management tools also don’t yet support SQL 2008 R2 SP1. You should always check the Product Interoperability Matrix when designing solutions. Not every solution is listed and there have been times where it is not up to date (such as currently there are no supported DB’s listed for Chargeback 2.0.1), but this is fairly rare. If you think something doesn’t look right on there contact VMware and they are normally able to quickly resolve the problems.

SQL 2008 R2 (no SP) is the lowest common denominator currently supported by most of the VMware product range that supports SQL. Unless you want to get into a complex situation of supporting multiple variants of Database for different VMware products I would recommend you you stick with this for now.

Now on the topic of protecting the Database of vCloud Director specifically, which is an important database if you are a public cloud provider, what HA options are available? Well if you’re using MS SQL Server as your Database then the only currently supported option is VMware HA or FT to protect the DB VM. With the FT option your DB needs to be configured with only a single vCPU, which will likely only be viable in very small environments. MSCS Failover Clustering and SQL DB Mirroring are not supported in the current 1.5.1 release of vCloud Director. If you’re running Oracle then you have the option of an active/passive configuration of RAC where the service is only active on one node at a time, or VMware HA if you choose. This situation will likely be addressed in upcoming releases.

If you need to know if a particular form of DB high availability is supported you should check the product documentation or log a Service Request with VMware Support, if you can’t find it explicitly supported. Without an explicit statement of support in the product documentation it is likely unsupported.

—

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.

In a previous post, The Trouble with CA SSL Certificates and vCenter 5, I reported that there isn’t a supported way to change out the self-signed SSL certificates that vCenter Heartbeat uses to communicate between nodes. This is quite important in secure enterprise and government environments, and in public/private clouds that are trying to meet regulatory standards. I have some good news to report.

After raising this with VMware I was informed they were working on a supported solution and they have now developed a KB article that explains how to change the vCenter Heartbeat SSL Certs for CA signed SSL certs. For information on how to change out the SSL certs for vCenter Heartbeat refer to KB 2013041. I have not yet tested this procedure but when I do I will update this post and if necessary create a new post to explain the process further and give you a tested and verified process.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

—

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.