Some 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 components. This article will outline what components are supported with the new vSphere 5.1 release and some important design and deployment considerations.

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 MS SQL Server databases relevant to the components below (if any) are supported for protection by vCenter Server Heartbeat.

Supported Components

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.

Key Design Considerations

vCenter Server Heartbeat can be configured to protect the supported components either when they are on the same system as vCenter Server (one exception below to note) or if they are on separate systems. In the case of separate systems you will configure each system as a Heartbeat Protected pair. It is important to note that this is still considered a single vCenter Server Heartbeat License. vCenter Server Heartbeat can also be configured to protect the MS SQL Server database system that hosts all of the database schemas for the supported components. But it must not be used to host any other database schemas for components that are not explicitly supported. Doing so would be a serious breach of your license agreement.

You should strongly consider changing the SSL Certificates that vCenter Server Heartbeat uses for secure communications to ensure that you are not vulnerable to a Man in the Middle (MiTM) attack and also to stop those annoying warning messages that you get when you log into the classic vSphere client. You can refer to my article titled Changing vCenter Heartbeat to CA SSL Certificates for the process.

If you are running a multi-site SSO deployment or HA SSO deployment you should consider if you need to also use vCenter Server Heartbeat at all. I would recommend you review the following Documentation and KB’s before considering your options with SSO. Overall given the complexity of SSO using vCenter Server Heartbeat may well be a far simpler solution to meeting the goal of a highly available SSO infrastructure for your vSphere environments.

KB2034074 – Installing vCenter Single Sign On in a Multi-Site Deployment

KB2034918 – vCenter Single Sign On FAQ

Install and Configure vCenter Single Sign On for a High Availability Deployment

You may choose to protect SSO with vCenter Server Heartbeat for local site availability at each of the sites in your multi-site deployment. This would avoid having to separately configure the load balancing and may avoid modifying the Lookup Service URL as described in the documentation. This is because the principal public IP / host name of the Heartbeat Pair in a Local LAN configuration won’t change when it fails over to the secondary node.

In a multi-site scenario or when you are protecting SSO for local site HA you should separate SSO off from the vCenter Server system and run it on a separate server. The main reason for this is that you will likely have multiple vCenters using the same SSO and it makes sense not to have it tied to any particular vCenter Server system. The second reason is that failover between primary and secondary nodes of a vCenter Server system protected by vCenter Servar Heartbeat will fail if you are running SSO on the same system as vCenter. This second situation will be addressed in a vCenter 5.1 Update 1 and vCenter Server Heartbeat 6.5 Update 1.

Final Word

Using vCenter Server Heartbeat can greatly simplify the High Availability configuration and protection of the vCenter Single Sign On systems when considering a multi-site deployment or a local site High Availability Deployment. When you are licensed for vCenter Server Heartbeat the same license can be used to protect all the key components that make up a vCenter Server System, including the MS SQL Server databases of those key components. If you management infrastructure is important to you, and having access to all these core management components is important to you I would strongly recommend you consider making vCenter Server Heartbeat part of your solution architecture. I have implemented it now for many clients in either private or public cloud and also normal vSphere environments and it has saved them countless hours of restoration activity and saved them from a lot of downtime including planned maintenance. When Virtualizing Business Critical Applications it would be very unwise not to have vCenter Server Heartbeat as part of the strategy for protecting the core vCenter management systems considering it is only a rounding error for the licenses in the greater scheme of things.

—

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.