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.
I have read the entire Heatdbeat EULA (http://www.vmware.com/download/eula/heartbeat_eula.html) and I wasn't able to find anything that confirms the text in bold above.
Hi Krasi, I'll take your feedback to the Product Manager for Heartbeat and get a response. But having just re-read the EULA myself I'm pretty sure it's covered by section 9 sub-part (a). I'm not a lawyer so it would be best to get independent legal advice on this. But the way I read the EULA having anything else protected by heartbeat other than what is specifically granted in the license agreement, and spelled out in that section, would be in breach of the license agreement. The EULA specifically says that the license is granted to protect the vCenter Server and it's database. It does not mention any other products. If the EULA is read subject to the product guide and documentation it covers all the components that can be protected by vCenter Server Heartbeat.
Hi Michael, no need for any action. I have simply missed that part of the EULA.
You are absolutly right.
No problem. I'm hoping to get more awareness of this and for the product managers to make it easier to understand and also easier for customers to implement heartbeat as well. I've talked to the product manager today and hopefully an FAQ will be produced that will help. Heartbeat is a great tool and very important in enterprise and service provider environments. Used in the right way it can provide fantastic availability and protection benefits to vCenter, which is the heart of your virtual infrastructure. vCenter is especially critical when it's managing business critical infrastructure, cloud environments, and virtual desktop infrastructure. If you choose to implement heartbeat I'd love to hear how you get on. I'm going to write another article shortly on a recent installation and upgrade experience that will help other customers who are implementing vCenter Server Heartbeat.
Hi Micheal,
This KB 1014266 : "Using vCenter Heartbeat With SRM", is very confused with vCenterHB EULA as it doesn't explain that we are not allowed to secure the SRM database on the same DB server of the vCenter
Hi Remi, I agree that KB article is confusing. I think what it's trying to say is that you can use SRM to protect VM's that are being managed by a vCenter Server that is using vCenter Server Heartbeat. You definitely can't put SRM Database on the same SQL system that is being used for vCenter if that SQL system is being protected by vCenter Server Heartbeat. I've asked my contacts at VMware to review that KB and make it more clear. It's totally unclear to me what they're trying to say in that KB at the moment. What is crystal clear is the EULA and the restriction of what can and can't be protected by vCenter Server Heartbeat.
[…] 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 […]
[…] of you may also remember the article I wrote titled Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!. vCenter Server Heartbeat is only licensed and supported to provide HA and protect certain […]