You are on page 1of 8


Installing vCenter Server
Heartbeat and Configuring
Protection for vCenter Server
The previous chapter was in introduction to vCSHB. It’s useful to understand how
something works before the knob turning starts. Chapter 1 should be that foundation for
us to get started with the installation, configuration, and tweaking of vCSHB. So let’s
start at the beginning with installing vCSHB and making post-installation changes to
completely protect vCenter Server with a locally installed instance of SQL Server. The
topics in this chapter will flow as follows:
 Preparing the environment
 Installing vCSHB on the Primary vCenter Server
 Installing vCSHB on the Secondary vCenter Server
 Configuring vCSHB to protect vCenter and associated services
 Installing the View Composer plugin
There a few important items that need to be addressed before the installation can begin.
First, let’s get a feel for the environment which this book uses. Throughout the book, the
Virtual-to-Virtual deployment model is used, with each vCenter Server or component
running as a virtual machine. The table below describes the various components.


Operating System

Windows Server 2012 Datacenter Edition

vCenter Server

5.5.0 Update 1 build 1750787


5.5.0 Update 1 build 1623387

SQL Server

2012 SP1

Virtual Hardware

version 10

VMware Tools

version 9349

vCenter and SQL Server on the same host Virtual Hardware

2 vCPUs, 12 GB RAM

Distributed Virtual Hardware

vCenter Server - 2 vCPUs, 8 GB RAM
SQL Server – 2 vCPUs, 4 GB RAM

Sharp eyes may notice the current VMware documentation on vCSHB 6.6 only lists
support up to vCenter Server 5.5, not Update 1 which is the version this book uses. As
always, checking the online product interoperability matrixes at shows that, indeed, Update 1 is now supported.

VMware has espoused the benefits of virtualizing vCenter Server for many years. Today,
VMware even recommends a virtual vCenter as a best practice in order to take advantage
of HA, DRS, and other general benefits of virtualization.
As a quick note on best practices: know when to deviate from them. Understand
why a best practice is considered such, under which circumstances it is and is


not, and when your situation does not fit as a best practice. Then feel free to
deviate but be sure you can defend your decision.
This book will only use virtual machines for examples and screenshots but will notate
when certain settings or configurations are specific to physical servers.
For specifics on which operating system and vCenter version are supported, be sure to
read the latest vCSHB documentation available at While for the most
part, Windows Server 2008 and 2012 and SQL 2008 and 2012 are supported (see the
documentation), there are definitely a few unsupported configurations of which you
should be aware. Most environments will have nothing to worry about here, but I should
at least mention them. vCSHB cannot be installed on a Domain Controller or a DNS
server. It also not supported on an Itanium IA-64 processor.

Preparing the environment
Before we install vCSBH, the systems with which we’re working must be configured in
particular ways. The focus of this chapter considers vCenter Server and all its
components as installed on a single machine. This includes SQL Server and is likely the
most often deployed architecture, also called V2V. Think of this as walking into a data
center where the vCenter Server has been up and running for some time. Here is a
diagram of the setup after the environment is prepared for vCSHB.


We’ll use this diagram to explain key concepts. The VM running on the left ESXi host
will be the Primary server and the VM running on the right ESXi host using a dashed line
will be the Secondary server.
There are two ESXi hosts because that’s the extent to which my lab has hardware. The
important part to note regarding the hosts you have is that you never want to run both the
Primary and Secondary server on the same host. This would undermine the purpose of
vCSHB which is to keep vCenter and its services highly available. Remember that
vCenter components can also be placed on several different VMs and still be protected by
vCSHB. In this case, you would want to make sure each Secondary server is never
placed on the same host as its Primary server. You can make sure of this by using DRS
“must” rules, also known as VM-VM Anti-affinity rules, which state that certain VMs
must never run on the same host.
Another item to note in the diagram is the networking. The vCSHB documentation will
state, and often confuse users, that when using multiple vNICs, the Public vNIC and the
VMware Channel vNIC should be placed on separate vSwitches. The point this
statement is trying to make is that the networking used by vCSHB should not be a single
point of failure. It is perfectly acceptable and supported to use only one vSwitch,
whether it’s a standard vSwitch or distributed vSwitch. In the best case, any failure on
one network, Public or VMware Channel, should not affect the other. It’s not always
possible to completely separate the network, though. For instance, in a WAN


deployment, if you only have a single ISP or WAN link between data centers, the Public
and Channel network might share the link and then the WAN becomes a single point of
As the diagram shows, a distributed virtual switch (vDS) is used in this deployment and
each ESXi host has two uplinks. The uplinks are spread across a multi-chassis Ethernet
switch deployment using virtual port channels (vPCs) and Cisco Nexus 5500-series
switches. So even though each vCSHB-protected VM will use a single vDS, the
networking is redundant and does not present a single point of failure. Similarly, if
standard virtual switches (vSS) are used, make sure multiple physical uplinks are used
and the upstream switches are redundant. If possible, separate ESXi uplinks across
physical NICs as well. An example configuration using standard virtual switches is
shown below.

With an understanding of the vSphere and networking configurations, let’s get the
systems set up for vCSHB installation. The following items need to be checked and

The vCenter Server is already a member of the domain. While domain
membership is not strictly required, some functionality is lost without it. For
the shops likely to use vCSHB, vCenter is likely to be already joined to the
domain. Let’s assume the vCenter Server hostname is VCENTER01. This
hostname will change. The idea is that the identity of the vCenter Server that


clients access, for instance, by using the vSphere Web Client, must not be
tied to a particular machine. This client facing identity is known as the
Public identity. Rather, that identity will move between machines protected
by vCSHB while a true identity stays with a particular machine for day-today access. So while VCENTER01 is the name of the vCenter Server that
clients access before installation, during the installation of vCSHB, the name
will change and the machine will rejoin the domain under the new name.
Here, you’ll need to document the following hostnames. I’ve listed the
names used in this book as examples.
o Public identity: VCENTER01
o Primary server: VCENTER01-A
o Secondary server: VCENTER01-B
If you’re installing a greenfield vCenter Server (a fresh install of vCenter
Server) that will be protected by vCSHB, you can name this Primary vCenter
Server straight away when you first build the machine. Then the installation
of vCSHB won’t have to change the name and rejoin the domain.
Verify that User Account Control (UAC) is turned off. This eases the
installation of vCSHB and can be turned back on afterwards. During the
installation of vCSHB on the Secondary server, there’s an automatic
configuration through a file share that occurs that UAC can disrupt so it’s
best to turn it off to avoid problems.
Per the licensing agreement, vCSHB can only protect certain services.
Beyond these services, there is no support and licensing would be in
question. vCSHB supports protecting vCenter Server and its associated
services like SSO, Inventory Service, Web Client, and Update Manager
(among others) and three specific SQL Server databases: vCenter, Update
Manager, and View Composer. Ensure no other business critical services are
running on the vCenter Server. For example, if Site Recovery Manager is
used in the environment, install it on its own server and point it to the Public
identity DNS name of the vCenter Server, in this case, VCENTER01.

For an FAQ on SRM with vCSHB, see VMware KB article 1014266

Often, databases associated with VMware are stored on shared SQL Servers.
The question then arises, “How do I protect the databases supported by
vCSHB when they’re on a shared SQL Server?” The answer is that it’s not
always pretty. When protecting SQL Server, vCSHB will only protect a
single SQL instance. Therefore, if you want to use a shared SQL Server,


place your vCSHB-protected databases on their own instance and place all
other databases on a separate instance.
Ensure all services are using DNS resolution instead of IP addresses when
connecting to vCenter Server. This includes Update Manager, vCenter
Converter, ESXi Dump Collector, ESXi Syslog Collector, Auto Deploy, and
others. This is especially important in WAN deployments because the Public
IP address will change between vCSHB nodes after a fail over.
Ensure enough resources have been provisioned for the Primary and
Secondary servers. A minimum of 1 GB of RAM is required and 2 GB is
recommended to run vCSHB in addition to any other requirements. 2 GB of
free disk space is required for installation. If the virtual environment has
been oversubscribed in memory or CPU, consider using resource
reservations to ensure vCenter Server will always have enough. While
reservations are generally unnecessary because they can complicate the
infrastructure, if vCenter is a candidate for high availability using vCSHB,
then it might also be a candidate for resource reservations to ensure it doesn’t
suffer from resource contention. If reservations are used, be sure to use the
same reservations for both nodes.
vCSHB installation is performed using local administrator credentials so
obtain them and document them.
To ensure vCSHB runs as seamlessly as possible, the Primary and Secondary
servers must be nearly identical in size and configuration as possible. In all
deployment scenarios, a cloning process occurs to begin with identical
software. From there, further updates like Microsoft patches need to take
place in an identical fashion. Before installing vCSHB, make sure Microsoft
patches are up to date.
For ease of installation, have all software to be protected installed on the
Primary serer before starting the vCHSB installation. Applications can be
added and removed later, but to reduce complexity and risk, try to have all
software installed before vCSHB.
Because vCSHB is a type of clustering solution that depends on
synchronization, ensure dates, times, and time zones are correct before
installing vCSHB. Obviously, in a LAN deployment, these settings will
match. Over a WAN, though, it’s possible they’re different. Verify these are
correct before proceeding.
If installing vCSHB in a P2P deployment, install the Windows Server
Backup Feature and Command Line Tools. These are used to create a
system state backup of the Primary server and restore it to the Secondary



server. Remember an underlying concept that keeps vCSHB running
smoothly is that both member servers are nearly identical in most ways.
If any changes have been made to the startup type for protected services,
ensure it is set back to Automatic before installing vCSHB. During the
installation, protected services will be set to Manual in order for vCSHB to
manage the starting and stopping of the services.
As already mentioned, vCSHB supports one, two, or more NICs. Anything
more than the second NIC will be additional VMware Channel NICs for
added redundancy. Redundant NICs should also uplink to redundant
switching gear. In this example, each VM will have two vNICs. Add two
vNICs to the Primary server. Label one vNIC something like “Primary” and
the second something like “Channel.” These labels, of course, aren’t
functional, but they help with identification and troubleshooting. Identify the
following IP addresses. The Public IP addresses should be consecutive. I’ve
included IP addresses below used in the examples.
o Primary Management IP address:
o Secondary Management IP address:
o Public IP address:
o Primary VMware Channel IP address:
o Secondary VMware Channel IP address:
Configure Management and Public IP addresses on the Public vNIC.
Configure the VMware Channel IP addresses on the Channel vNIC.
Finally, if you have firewalls in between your Primary and Secondary
servers, open the following ports across the firewall to each server
o Client Connection port: 52267
o Default Channel port: 57348