vCenter Heartbeat is the only supported and validated solution for providing high availability to vCenter Server, and can also protect the core components that go with it (such as SSO, VUM, Inventory Service etc). I strongly recommend vCenter Server Heartbeat be considered for environments where the management infrastructure availability is critical. I’ve used vCenter Server Heartbeat in a number of implementations. But it hasn’t always been easy to implement. The good news is that now thanks to the team at VMware and VMware KBTV we have a video that takes you through the installation and validation of vCenter Server Heartbeat in a vSphere 5.1 environment. In this article I’ll give you some insight into when you might want to deploy vCenter Server Heartbeat, and you can learn how by viewing the video.
As your environment grows and becomes more critical, as you start to virtualize business critical applications, deploy private or hybrid cloud, or virtual desktops, your management infrastructure such as vCenter also increases in criticality. Loss of access to vCenter can mean loss of major functionality, not just for support and troubleshooting but also provisioning, operations, and monitoring. In a 24/7 environment where availability is paramount this can have a major impact on your organization. This is where vCenter Server Heartbeat comes in. It will protect your vCenter system, and can also protect all the core components like SSO, VUM, Inventory Service, and even the vCenter MS SQL Database, by making it highly available. All of these components can be protected by a single heartbeat license even if they are deployed on separate servers or VM’s. It can be used in two different deployment modes that either provide local-site HA on the LAN or inter-site disaster recovery across the WAN. A list of all the components that vCenter Server Heartbeat can protect were listed in my article titled vSphere 5.1 and vCenter Server Heartbeat 6.5 Deployment Considerations, which also goes into some key design considerations for 5.1 environments.
This video is a first installment of a series answering the most common questions asked by the VMware user community when deploying vCenter Server Heartbeat. Whether deploying in High Availability or Disaster Recovery deployment modes, this video will offer key points, tips and considerations for a successful deployment. The video is originally published on the VMware Support Insider Blog – vCenter Heartbeat Installation and Validation. I hope you get a lot out of this video and watch out for more videos in the series.
vCenter Server Heartbeat is the best way to protect and provide high availability to vCenter and many of the core components. As I’ve previously written Cluster of the vCenter Server Database is not supported by VMware as a means of providing high availability, and neither is Database Mirroring. But Heartbeat does so much more than just protect the database, it provides intelligent application level high availability that includes monitoring performance metrics, so it knows when to switch over to the stand by or when to restart a service. With the proper design and implementation vCenter Server Heartbeat can provide worry free high availability protection for your core VMware management components. I recommend you consider vCenter Server Heartbeat for your environment and wish you luck with your implementation if you go down that road.
Two additional articles I’d recommend you read that cover vCenter Server Heartbeat are below:
Clustering Support on vCloud Director and vCenter Databases
Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!
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.
Having just spoken to the vmware engineer (heartbeat specialist) SSO is currently not supported running from the same server vCenter is running on in a heartbeat environment. As such VCHB is not a valid method of protecting SSO and it must be run on its own. There is a fix expected in U1 due in Q2/3.
Hi Scott, while there are problems that have to be worked around when running SSO on the same host as vCenter and protecting it with Heartbeat this doesn't change the fact that is a supported solution and is documented as such in the VMware product documentation. However, this configuration would not be recommended in the current state due to the problems and defects. The recommended configuration would be to have SSO configured on it's own server, separate from vCenter and then protect that server with vCenter Heartbeat. This would use the same vCenter Heartbeat license. The video included in this article is validated and supported by VMware and supported by VMware Global Support Services. There are other methods of protecting SSO that are documented in VMware KB's.
Is this lack of support for SSO on the same server as vCenter and protected by VCHB detailed in any VMware KB's anywhere?
What do you mean lack of support? It's supported to be on the same server as vCenter and protected by VCHB. But there is a workaround that needs to be applied to get it to work properly (I don't have the KB off hand). It's just that in the scenario where you have multiple vCenters in play it makes sense to have SSO on it's own VM and not tied to any particular vCenter.
The support comment was in reference to Scott's comment from the VMware engineer re SSO, vCenter and VCHB on the same server. I didn't see anything about this in the VCHB release notes to be honest.
So the issue is really with protecting SSO when multiple vCenters are deployed(linked or not), and how VCHB can be used to protect the SSO service.
If you could find the KB that would be great.
This article helps explain some options for protecting SSO – http://blogs.vmware.com/vsphere/2013/03/vcenter-s….
[…] vCenter Server Heartbeat Installation and Validation […]