VMware vCenter Server Heartbeat - 5.5 Reference Guide
Reference Guide
VMware vCenter Server Heartbeat 5.5 Update 2
This document supports the version of each product listed and
supports all subsequent versions until the document is replaced
by a new edition. To check for more recent editions of this
document, see http://www.vmware.com/support/pubs.
EN-000206-01
Reference Guide
You can find the most up-to-date technical documentation on the VMware Web site at:
http://www.vmware.com/support/
The VMware Web site also provides the latest product updates.
If you have comments about this documentation, submit your feedback to:
docfeedback@vmware.com
Copyright © 2009 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and
intellectual property laws. VMware products are covered by one or more patents listed at
http://www.vmware.com/go/patents.
VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks
and names mentioned herein may be trademarks of their respective companies.
VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com
2 VMware, Inc.
Contents
About This Book 7
Getting Started
1 Introduction 11
vCenter Server Heartbeat Concepts 11
Server Protection 12
Network Protection 12
Application Protection 12
Performance Protection 13
Data Protection 14
Communications 14
Switchover Process 15
Auto Switchovers 16
Failover Process 17
Recovery from a Failover 17
Installation
2 vCenter Server Heartbeat Implementation 21
Overview 21
Environmental Prerequisites 21
Common Requirements 22
Server Architecture Options 22
Virtual to Virtual (V2V) 22
Physical to Virtual (P2V) 23
Physical to Physical (P2P) 23
Cloning Technology Options 24
Supported Pre-Clone Technologies 24
Supported Install Clone Technologies 24
Application Component Options 25
vCenter Server with SQL Server on the Same Host 25
vCenter Server with SQL Server on a Separate Host 25
vCenter Server Only 25
Network Options 25
LAN 26
WAN 26
Antivirus Recommendations 27
Deployment Options Summary 28
Installation Options Checklist 28
3 vCenter Server Heartbeat Installation on Windows Server 2003 31
Overview 31
Installation Process 31
Primary Server 32
VMware, Inc. 3
Reference Guide
Secondary Server 53
Post Installation Configuration 68
Add the VMware License 68
When Deployed in a WAN Environment 68
vCenter Server 2.5 68
vCenter Server 4.0 69
4 vCenter Server Heartbeat Installation on Windows Server 2008 71
Overview 71
Installation Process 71
Primary Server 72
Secondary Server 92
Post Installation Configuration 109
Add the VMware License 109
When Deployed in a WAN Environment 109
vCenter Server 2.5 109
vCenter Server 4.0 110
5 Configuring vCenter Server Heartbeat 113
Server Configuration Wizard 114
Configuring the Machine Identity 115
Configuring the Server Role 115
Configuring the Client Connection Port 115
Configuring Channel IP Routing 115
Configuring the Default Channel Port 116
Configuring Low Bandwidth Module 116
Configuring Public IP Addressing 116
Enabling Network Monitoring 117
Configuring Split-Brain Avoidance 118
Managing vCenter Server Heartbeat License Keys 119
Configuring Message Queue Logs 119
Configuring the Maximum Disk Usage 120
System Administration and Management
6 Server Protection 123
Server Protection Overview 123
Checking the Server Pair Status 124
Configuring Heartbeat Settings 125
Configuring vCenter Server Heartbeat Shutdown Options 126
Starting, Stopping, and Shutting Down vCenter Server Heartbeat 126
Forcing a Switchover 127
Recovering From a Failover 128
Configuring Split-Brain Avoidance 129
7 Network Protection 131
Communication Status 131
Reviewing the VMware Channel Status 131
Configuring Public Network Connection Checks 132
Setting Max Server Time Difference 133
4 VMware, Inc.
8 Application Protection 135
Application Protection Overview 135
Applications Tab 135
Editing Individual Applications 136
Configuring Applications 137
Reviewing the Status of an Application 138
Reviewing the Application Log 138
Filtering Application Log Entries 139
Resetting the Application Health Status 140
Removing an Application 140
Services Tab 141
Adding a Service 142
Editing a Service 143
Checking the Status of Services 144
Unprotecting Services and Stopping Monitoring 144
Removing a Service 145
Tasks Tab 146
Adding a Task 146
Editing a Task 147
Removing a Task 148
Starting a Task Manually 148
Plugins Tab 149
Installing a Plug-In 150
Editing a Plug-in 151
Uninstalling a Plug-in 152
Contents
9 Status and Control 153
vCenter Server Heartbeat Console 153
Logging into vCenter Server Heartbeat 153
Connecting to a Pair of Servers 155
Reviewing the Status of a Server Pair 155
Configuring the Look and Feel of the vCenter Server Heartbeat Console 156
Changing vCenter Server Heartbeat Console Pages 157
Logging Out of the vCenter Server Heartbeat Console 157
10 Performance Protection 159
Rules Tab 159
Editing a Rule 160
Rules Installed by vCenter Server Heartbeat Plug-Ins 160
Checking a Rule Condition 162
11 Data Protection 163
Data Protection Overview 164
Automatic Filter Discovery 164
Adding a User-Defined Inclusion Filter 165
Adding a User-Defined Exclusion Filter 166
Removing User-Defined Inclusion or Exclusion Filters 167
Configuring Max Disk Usage 167
Reviewing Status of Protected Files 168
Determining Effective Filters 168
Initiating File Synchronization Manually 169
Initiating Verify and Synchronize Manually 170
Initiating a Full System Check 170
Reviewing the Registry Synchronization Status 171
VMware, Inc. 5
Reference Guide
Initiating a Full Registry Check 172
12 Other Administrative Tasks 173
Configuring Alerts 173
Configuring Alert Reporting 174
Test Alert Reporting 176
Configuring Event Log Files 177
Configuring Log File Email Recipients 177
Reviewing Event Logs 178
13 Troubleshooting 181
Troubleshooting Unexpected Behaviors 181
Two Active Servers 181
Symptoms 181
Causes 182
Resolution 182
Two Passive Servers 183
Symptom 183
Causes 183
Resolution 183
Synchronization Failures 184
Services Running on the Passive Server 184
VMware Channel Incorrectly Configured 184
Incorrect or Mismatched Disk Configuration 185
Passive Server Has Less Available Space than Active Server 185
Registry Status is Out of Sync 186
Resource Issues 186
Registry Security Issues 186
Channel Drops 186
Performance Issues 186
Passive Server Does Not Meet Minimum Hardware Requirements 187
Hardware or Driver Issues on VMware Channel NICs 187
Firewall Connection 188
Incorrect VMware Channel Configuration 188
VMware vCenter Server Heartbeat Packet Filter Is Enabled on the Channel NIC(s) 189
Subnet or Routing Issues 190
LAN Deployment 190
WAN Deployment 190
MaxDiskUsage Errors 190
Active Server (Unsafe) Queue 191
Passive Server (Safe) Queue 191
MaxDiskUsage Error Messages 191
[L9]Exceeded the Maximum Disk Usage (VCChannelExceededMaxDiskUsageException) 191
[L9]Exceeded the Maximum Disk Usage on the ACTIVE Server 191
[L9]Exceeded the Maximum Disk Usage on the PASSIVE Server 192
[L20]Out of Disk Space (VCChannelOutOfDiskSpaceException) 193
Application Slowdown 193
Poor Application Performance 193
Both Servers Can Accommodate the Initial Load but the Load Has Increased 194
One Server Can Provide Adequate Resource Support, but the Other Cannot 194
Scheduled Resource Intensive Tasks 195
Appendix – Setup Error Messages 197
Glossary 199
6 VMware, Inc.
About This Book
The Reference Guide provides information about installing and configuring VMware vCenter Server Heartbeat,
including implementation in a Local Area Network (LAN) or Wide Area Network (WAN), configuring
network protection, application protection, data protection, Split-brain Avoidance, and more. To help you
protect your VMware vCenter Server, the book provides an overview of protection offered by vCenter Server
Heartbeat and the actions that vCenter Server Heartbeat can take in the event of a network, hardware, or
application failure.
Intended Audience
This guide assumes a working knowledge of networks including configuration of TCP/IP suite of protocols
and sound knowledge of domain administration on the Windows 2003 platform, notably in Active Directory
and DNS.
Document Feedback
VMware welcomes your suggestions for improving our documentation. If you have comments, send your
feedback to docfeedback@vmware.com.
Abbreviations Used in Figures
The figures in this book use the abbreviations listed in Tab le 1.
Table 1. Abbreviations
Abbreviation Description
Channel VMware Channel
NIC Network interface card
P2P Physical to physical
P2V Physical to virtual
V2V Virtual to virtual
SAN Storage area network type datastore
Technical Support and Education Resources
The following sections describe the technical support resources available to you. To access the current version
of this book and other books, go to www.vmware.com/support/pubs.
Online and Telephone Support
To use online support to submit technical support requests, view your product and contract information, and
register your products, go to www.vmware.com/support.
VMware, Inc. 7
Reference Guide
Customers with appropriate support contracts should use telephone support for the fastest response on
priority 1 issues. Go to www.vmware.com/support/phone_support.
Support Offerings
To find out how VMware support offerings can help meet your business needs, go to
www.vmware.com/support/services.
VMware Professional Services
VMware Education Services courses offer extensive hands on labs, case study examples, and course materials
designed for use as on the job reference tools. Courses are available onsite, in the classroom, and live online.
For onsite pilot programs and implementation best practices, VMware Consulting Services provides offerings
to help you assess, plan, build, and manage your virtual environment. To access information about education
classes, certification programs, and consulting services, go to www.vmware.com/services.
8 VMware, Inc.
Getting Started
VMware, Inc. 9
Reference Guide
10 VMware, Inc.
1
Introduction
This chapter includes the following topics:
“vCenter Server Heartbeat Concepts” on page 11
“Switchover Process” on page 15
“Failover Process” on page 17
vCenter Server Heartbeat Concepts
vCenter Server Heartbeat is a Windows based service specifically designed to provide high availability
protection for vCenter Server configurations without requiring any specialized hardware.
vCenter Server Heartbeat provides the following protection levels:
Server Protection – vCenter Server Heartbeat provides continuous availability to end users through a
hardware failure scenario or operating system crash. Additionally, vCenter Server Heartbeat protects the
network identity of the production server, ensuring users are provided with a replica server including
server name and IP address shares on the failure of the production server.
Network Protection – vCenter Server Heartbeat proactively monitors the network by polling up to three
nodes to ensure that the active server is visible on the network.
1
Application Protection – vCenter Server Heartbeat maintains the application environment ensuring that
applications and services stay alive on the network.
Performance Protection – vCenter Server Heartbeat proactively monitors system performance attributes
to ensure that the system administrator is notified of problems and can take pre-emptive action to prevent
an outage.
Data Protection – vCenter Server Heartbeat intercepts all data written by users and applications, and
maintains a copy of this data on the passive server that can be used in the event of a failure.
vCenter Server Heartbeat provides all five protection levels continuously, ensuring all facets of the user
environment are maintained at all times, and that the network (Principal (Public) network) continues to
operate through as many failure scenarios as possible.
vCenter Server Heartbeat software is installed on a Primary server and a Secondary server. These names refer
to the physical hardware (identity) of the servers.
The Secondary server has the same domain name, same file and data structure, same network address, and
can run all the same applications and services as the Primary server.
vCenter Server Heartbeat uses two servers with identical names and IP addresses. One is an active server that
is visible on the Principal (Public) network and the other is a passive server that is hidden from the network
but remains as a ready standby server. Only one server name and IP address can be visible on the Principal
(Public) network at any given time.
VMware, Inc. 11
Reference Guide
The vCenter Server Heartbeat software is symmetrical in almost all respects, and either the Primary Server or
the Secondary server can take the active role and provide the protected application to the user.
Server Protection
vCenter Server Heartbeat maintains availability through operating system and hardware failure events. Two
instances of vCenter Server Heartbeat monitor each other by sending “I’m alive” messages and reciprocating
with acknowledgments over a network connection termed the VMware Channel. If the passive server detects
that this process or heartbeat has failed, a failover is initiated as illustrated in Figure 1-1.
Figure 1-1. Failover
A failover is similar to a switchover but is used in more drastic situations. A failover happens when the passive
server detects that the active server is no longer responding. This can occur when the active server hardware
crashes or loses its network connections. Rather than the active server gracefully closing, the passive server
determines that the active server has failed and requires no further operations. During failover, the passive
server immediately takes on the active server role. The mechanics of failovers are discussed later in this guide.
Network Protection
vCenter Server Heartbeat proactively monitors the capability of the active server to communicate with the rest
of the network by polling defined nodes around the network, including by default the default gateway, the
primary DNS server, and the Global Catalog server at regular intervals. If all three nodes fail to respond, for
example, due to a network card failure or a local switch failure, vCenter Server Heartbeat can initiate a
switchover, allowing the Secondary server to assume an identical network identity as the Primary server.
Application Protection
vCenter Server Heartbeat running locally on the active server monitors the protected applications and services
through the use of plug-ins. vCenter Server Heartbeat protects the following components:
VirtualCenter Server Versions 2.5
VMware VirtualCenter Server
VMware Capacity Planner
VMware Converter Enterprise
VMware Update Manager
VMware License Server
vCenter Server Version 4.0
VMware vCenter Server
VMware Guided Consolidation Service
12 VMware, Inc.
Chapter 1 Introduction
VMware License Sever
VMware ADAM
VMware vCenter Management Web Server
VMware Update Manager
VMware Converter Enterprise
Guided Consolidation Service
VMware Orchestrator
VMware vSphere Host Update Utility
If a protected application fails, vCenter Server Heartbeat first tries to restart the application on the active server
(1) in Figure 1-2.
If the application does not successfully restart, vCenter Server Heartbeat initiates a switchover (2) in
Figure 1-2. Refer to “Switchover Process” on page 15 and “Failover Process” on page 17 for further
information about the switchover process.
Figure 1-2. Switchover
A switchover gracefully closes any protected applications that are running on the active server and restarts
them on the passive server, including the application or service that caused the failure. In the example where
the Primary server is active and the Secondary server is passive, the Primary server is demoted to a passive
role and is hidden from the network when the Secondary server is promoted to an active role and is made
visible to the network. The mechanics of switchovers are discussed in more detail later in this guide.
Performance Protection
Ensuring that your protected applications are operational and providing service at a level of performance
adequate for users to remain productive is important. The vCenter Server Heartbeat plug-in provides these
monitoring and pre-emptive repair capabilities.
vCenter Server Heartbeat monitors application services and specific application attributes to ensure that
protected applications are operational and not in an unresponsive or stopped state. This level of monitoring is
fundamental in ensuring that applications are available to end users.
In addition to monitoring application services, vCenter Server Heartbeat can also monitor specific application
attributes to ensure that they remain within normal operating ranges. Similar to application monitoring,
various rules can trigger specific corrective actions whenever these attributes fall outside of their respective
ranges.
Furthermore, vCenter Server Heartbeat provides the same level of flexibility to define and perform multiple
corrective actions in the event of problems on a service by service or even attribute by attribute basis.
VMware, Inc. 13
Reference Guide
Data Protection
You can configure vCenter Server Heartbeat to protect the application environment. All data files that users or
the applications require in the application environment are made available should a failure occur. After
installation, vCenter Server Heartbeat configures itself to protect files, folders, and registry settings for
vCenter Server on the active server by mirroring them in real time to the passive server. This means that if a
failover occurs, all the files that were protected on the failed server are available to users after the failover,
hosted on the Secondary server.
vCenter Server Heartbeat intercepts all file system I/O operations on the active server. If the intercepted write
and update operations are within the protected set, these are placed in a queue on the active server referred to
as the active server (unsafe) queue, pending transmission to the passive server. Each request is numbered to
maintain its order in the queue.
With the request in the active server (unsafe) queue, vCenter Server Heartbeat allows the disk I/O to continue
with the requested disk operation.
If the channel is connected, the active server (unsafe) queue is transferred to the passive server, which places
all the requests in the passive server (safe) queue. The passive server confirms the changes were logged by
sending the active server an acknowledgement. The active server clears the data from its queue.
Figure 1-3. Apply Process
The apply process running on the passive server (safe) queue applies all updates in strict sequence, duplicating
an identical set of file operations on the passive server as illustrated in Figure 1-3.
Communications
The VMware Channel is a crucial component of the setup and can be configured in a number of ways.
Both the Primary and Secondary servers must have two or more network interface connections (NICs).
The Principal (Public) network requires one NIC. The VMware Channel uses a separate NIC for the private
connection between the servers used for control and data transfer between the pair of servers.
A second pair of NICs can be used to provide a degree of redundancy for the VMware Channel. In this
configuration, the VMware Channel has a dual channel if more than one dedicated NIC is provided for the
VMware Channel on each server. To provide added resilience, the communications for the second channel
must be completely independent from the first channel. They must not share any switches, virtual switches,
routers or the same WAN connection.
14 VMware, Inc.
Chapter 1 Introduction
Figure 1-4. Communication Between Primary and Secondary Servers
The IP address used by a client to connect to the active server (the Principal (Public) IP address) must be
configured to use a static IP address that is not DHCP (Dynamic Host Configuration Protocol) enabled. In the
example in Figure 1-4, the IP address is configured as 192.168.1.127.
N
OTE Obtain the IP address: type ipconfig at the prompt in a DOS shell. For additional information about
the IP configuration, type /All.
The Principal (Public) NICs on the passive server are configured to use the same IP address as that of the active
server but are prevented from communicating with the live network through an IP packet filtering system
installed with vCenter Server Heartbeat. This packet filter prevents traffic using the Principal (Public) address
from being committed to the wire. It also prevents NetBIOS traffic utilizing other IP addresses on the NIC from
being sent to prevent NetBIOS name resolution conflicts.
The NICs on the active and passive servers used for the VMware Channel must be configured so that they have
IP addresses outside of the Principal (Public) networks subnet range. These addresses are termed the VMware
Channel addresses.
During installation, setup will switch off NetBIOS for the VMware Channel(s) on the active and passive
servers as this connection remains live and both the passive and active machines have the same NetBIOS name.
After restore and after the vCenter Server Heartbeat installation is complete (runtime), NetBIOS is disabled
across the channel(s).
The NICs that allow the connectivity across the VMware Channel can be standard 100BaseT Ethernet cards
providing a throughput of 100 Mbits per second across standard Cat-5 cabling. In its most basic form, a
dedicated channel requires no hubs or routers, but the direct connection requires crossover cabling.
When configured for a WAN deployment, configure the VMware Channel to use static routes over switches
and routers to maintain continuous communications independent from corporate or public traffic.
Switchover Process
You can trigger a switchover manually from vCenter Server Heartbeat Console Status & Control window by
clicking Switchover. vCenter Server Heartbeat can initiate a switchover when a protected application fails or
suffers performance degradation, or a network failure prevents the active server from being visible to the
network.
When a switchover is triggered, the running of protected applications is transferred from the active machine
to the passive machine in the server pair. The server roles are switched.
VMware, Inc. 15
Reference Guide
Figure 1-5. Switchover
The automatic procedure executed during a switchover operation involves the following steps:
1 Stop the protected applications on the active server. After the protected applications stop, no more disk
2 Send all updates that are still queued on the active server to the passive server. After this step, all updates
updates are generated.
are available on the passive server.
3 Change the status of the active server to switching to passive. The server is now no longer visible from the
network.
4 Apply all queued updates on the passive server.
5 Change the status of the passive server to active. The new active server starts intercepting disk I/Os and
queues them for the new passive server. The new active server is now visible on the network with the
same identity as the old active server.
6 Change the status of the old active server from switching to passive to passive. The new passive server
now accepts updates from the active server.
7 Start the same protected applications on the new active server. The protected applications now start and
are accessible to users, generating disk updates.
The switchover is complete.
Auto Switchovers
An auto switchover is triggered when a protected application or other system monitored component such as
networking fails.
An auto switchover is different than a manual switchover. Although the server roles are changed, replication
stops so the administrator can investigate and rectify the cause of the auto switchover.
Auto switchover is similar to failover but caused by a failed monitored application or system component. After
you determine the cause for the auto switchover, restore the server with the failed application or other system
monitored component to the active role as follows:
1 Correct the incident that caused the failover.
2 Verify the integrity of the disk data on the failed server.
3 Restart the failed server.
4 Start vCenter Server Heartbeat on the failed server.
5 Wait until vCenter Server Heartbeat is fully synchronized.
6 Perform a manual switchover.
16 VMware, Inc.
Failover Process
Figure 1-6. Failover
When the passive server detects the active server is no longer running properly, it assumes the active server
role by taking the following steps.
1 The server applies any intercepted updates that are currently saved in the passive server (safe) update
queue, that is, the log of update records saved on the passive server but not yet applied to the replicated
files.
Chapter 1 Introduction
The length of the passive server (safe) queue affects the time the failover process takes to complete. If the
passive server queue is long, the system must wait for application of all passive server updates before the
rest of the process can take place.
When no more update records can be applied, any update records that the server was unable to apply are
discarded. An update record can only be applied if all earlier update records were applied and the
completion status for the update is in the passive server (safe) update queue.
2 The server switches its role from passive to active.
The server enables the public identity of the server. The active and passive servers both have the same
system name and same Principal (Public) IP address. This Principal (Public) IP address can be enabled on
only one of the two systems at a time. When the public identity is enabled, any clients connected to the
server before the failover can now reconnect.
3 The server starts intercepting updates to the protected data. Updates to the protected data are saved in
the active server (unsafe) update queue.
4 The server starts all the protected applications. The applications use the replicated application data to
recover before allowing clients to reconnect. Any updates that the applications make to the protected data
are intercepted and logged.
At this stage, the originally active server is offline, and the originally passive server has taken over the active
server role and is running the protected applications. Because the originally active server stopped abruptly,
the protected applications possibly lost some data, but the no synchronization mode update that completed
before the failover is lost. The application clients can reconnect to the application and continue running as
before.
During a failover, the data in the active server (unsafe) queue is lost.
Recovery from a Failover
Assuming that the active server before the failover was the Primary server, and the Secondary server has
assumed the active role following a failover, you can reinstate the Primary server to an active role after
rectifying the problem that initiated the failover.
VMware, Inc. 17
Reference Guide
When vCenter Server Heartbeat starts on the failed Primary server, it detects that it did not stop cleanly the
previous time. It disables the public identity by deploying the IP packet filter at startup, and halts vCenter
Server Heartbeat so that the issues that caused the failure can be resolved. The following steps restore the
previously failed server to the active role:
1 Correct the incident that caused the failover.
2 Verify the integrity of the disk data on the failed server.
3 Restart the failed server.
4 Start vCenter Server Heartbeat on the failed server.
5 Wait until vCenter Server Heartbeat is fully synchronized.
6 Perform a manual switchover.
After resolving these issues, you can start vCenter Server Heartbeat on the failed, now passive, server. At this
stage, the vCenter Server Heartbeat software running on the pair of servers connects and starts to synchronize
the data on the Primary server. When the resynchronization is complete, you can continue operating with this
configuration (for example, the Secondary server is the active server and the Primary server is the passive
server), or perform a switchover to reverse the roles of the two servers in the vCenter Server Heartbeat pair
(for example, assigning the Primary and Secondary the same roles that they had before the failover).
18 VMware, Inc.
Installation
VMware, Inc. 19
Reference Guide
20 VMware, Inc.
2
vCenter Server Heartbeat Implementation
This chapter includes the following topics:
“Overview” on page 21
“Environmental Prerequisites” on page 21
“Common Requirements” on page 22
“Server Architecture Options” on page 22
“Cloning Technology Options” on page 24
“Application Component Options” on page 25
“Network Options” on page 25
“Antivirus Recommendations” on page 27
“Deployment Options Summary” on page 28
Overview
vCenter Server Heartbeat is a versatile solution that provides you with complete protection of vCenter Server
and SQL Server. It can be deployed in a LAN for high availability or across a WAN to provide disaster recovery.
vCenter Server Heartbeat can protect vCenter Server and SQL Server installed on the same server, or protect
vCenter Server and SQL Server on separate servers. This flexibility enables vCenter Server Heartbeat to protect
vCenter Server when using remote databases other than SQL Server.
2
This chapter discusses the deployment options and prerequisites necessary to successfully implement vCenter
Server Heartbeat and provides a step by step process to assist in selecting options required for installation. The
deployment scenario table provides a visual reference to configuration options supported by vCenter Server
Heartbeat.
During the installation process, vCenter Server Heartbeat performs a variety of checks to ensure the server
meets the minimum requirements for a successful installation. A critical stop or warning message appears if
the server fails a check. Refer to the Appendix – Setup Error Messages in this guide for a list of the checks and
an explanation of the message. You must resolve critical stops before you can proceed with setup.
Prior to installing vCenter Server Heartbeat, select the deployment options you intend to use. The installation
process prompts you to select options throughout the procedure to create the configuration you want.
Environmental Prerequisites
vCenter Server Heartbeat cannot protect a server configured with the following roles: domain controller,
global catalog, or DNS. Please note, because vCenter Server Heartbeat only protects the vCenter Server and
SQL Server applications, no other critical business applications should be installed on the server.
VMware, Inc. 21
Reference Guide
Common Requirements
The following requirements are in addition to those required for vCenter Server and SQL Server.
Supported vCenter Server Versions
VirtualCenter Server 2.5
VirtualCenter Server 2.5 Update 1
VirtualCenter Server 2.5 Update 2
VirtualCenter Server 2.5 Update 3
VirtualCenter Server 2.5 Update 4
VirtualCenter Server 2.5 Update 5
vCenter Server 4.0
vCenter Server 4.0 Update 1
Operating System
Windows Server 2003 x86 SP1 or SP2
Windows Server 2003 x64 SP2
Windows Server 2008 x86 SP1 or SP2
Windows Server 2008 x64 SP1 or SP2
Prior to installing vCenter Server Heartbeat, verify that vCenter Guided Consolidation, vCenter Update
Manager, and vCenter Converter are configured using Fully Qualified Domain Names (FQDN) rather
than IP addresses.
During the setup process, vCenter Server Heartbeat verifies that a minimum of 1GB RAM is available. To
ensure proper operation, vCenter Server Heartbeat requires a minimum of 1GB RAM (2GB is
recommended) in addition to any other memory requirement for the Operating System or vCenter Server.
Verify that 2GB of disk space is available on the installation drive for vCenter Server Heartbeat.
Obtain and use local administrator rights to perform vCenter Server Heartbeat installation.
Apply the latest Microsoft security updates.
All applications that will be protected by vCenter Server Heartbeat must be installed and configured on
the Primary server prior to installing vCenter Server Heartbeat.
Verify that both Primary and Secondary servers have identical system date, time, and time Zone settings.
Once configured, do not change the time zone.
Verify that the Principal (Public) network adapter is listed as the first network adapter in the Network
Connections Bind Order. (Network Connections > Advanced > Advanced Settings).
Verify that the Managed IP setting in the Virtual Infrastructure Client is the same IP address used for the
vCenter Server Heartbeat Principal (Public) IP address.
Server Architecture Options
The selected server architecture affects the requirements for hardware and the technique used to clone the
Primary server.
Virtual to Virtual (V2V)
V2V is the supported architecture if vCenter Server is already installed on the production (Primary) server
running on a virtual machine. Benefits to this architecture include reduced hardware cost, shorter installation
time, and use of the Pre-Clone technique for installation.
22 VMware, Inc.
Chapter 2 vCenter Server Heartbeat Implementation
The Secondary virtual machine must meet the minimum requirements.
The specifications of the Secondary virtual machine must match the specifications of the Primary virtual
machine as follows:
Similar CPU (including resource management settings)
Memory configuration (including resource management settings)
Appropriate resource pool priorities
Each virtual machine used in the V2V pair must be on a separate ESX host to guard against failure at the
host level.
Each virtual NIC must use a separate virtual switch.
Physical to Virtual (P2V)
P2V architecture is used when the environment requires a mix of physical and virtual machines, such as when
vCenter Server is installed on a physical server in an environment where available hardware is limited. This
architecture is appropriate if you must avoid adding more physical servers or if you plan to migrate to virtual
technologies over a period of time. With P2V architecture, you can test vCenter Server running in a virtual
environment or migrate from Physical to Virtual without any downtime. The Secondary virtual machine must
meet the minimum requirements.
The specifications of the Secondary virtual machine must match the Primary physical server as follows:
Similar CPU
Identical Memory
The Secondary virtual machine must have sufficient priority in resource management settings so that
other virtual machines do not impact its performance.
Each virtual NIC must use a separate virtual switch.
Physical to Physical (P2P)
P2P architecture is used in environments where both the Primary and Secondary servers are physical servers.
Use of P2P limits installation options as it requires use of the Install Clone technique. This architecture requires
attention to detail when preparing for installation as both hardware and software must meet specific
prerequisites.
Primary Server
The Primary server must meet the following requirements:
Hardware as specified in “Common Requirements” on page 22.
Software as specified in “Common Requirements” on page 22.
VMware, Inc. 23
Reference Guide
Secondary Server
The Secondary server operates as a near clone of the Primary server and must meet the following
requirements.
Hardware
Hardware should be equivalent to the Primary server to ensure adequate performance when the server is in
the active role:
Similar CPU.
Similar memory.
Identical number of NICs to the Primary server.
Drive letters must match the Primary server.
Available disk space must be greater than or equal to the Primary server.
Advanced Configuration and Power Interface (ACPI) compliance must match the Primary server. The
Software
Software on the Secondary server must meet the following requirements.
vCenter Server Heartbeat Standard implementation process assumes identical ACPI compliance on both
machines. If not, contact VMware Support at www.vmware.com/support for further information.
OS version and Service Pack version must match the Primary server.
OS must be installed to the same driver letter and directory as on the Primary server.
Machine name must be different from the Primary server prior to installing vCenter Server Heartbeat.
Set up in a workgroup prior to installing vCenter Server Heartbeat.
System date, time, and time zone settings must be consistent with the Primary server.
Cloning Technology Options
Cloning the Primary server to create a nearly identical Secondary server involves different techniques
depending on the selected server architecture.
Supported Pre-Clone Technologies
The following cloning technologies are supported for creating Pre-Cloned images for use as a Secondary
server:
VMware Converter for “Physical to Virtual (P2V)” on page 23.
VMware vCenter virtual machine cloning for “Virtual to Virtual (V2V)” on page 22.
Supported Install Clone Technologies
Installation of vCenter Server Heartbeat provides support for NTBackup on Windows 2003 and Wbadmin on
Windows Server 2008 for automated Install Cloning. This process is automated but requires meeting all
prerequisites for the Secondary server specified in “Physical to Physical (P2P)” on page 23.
24 VMware, Inc.
Application Component Options
vCenter Server Heartbeat can accommodate any of the supported vCenter Server configurations and protects
the following components:
VirtualCenter Server Version 2.5
VMware VirtualCenter Server
VMware Capacity Planner
VMware Converter Enterprise
VMware Update Manager
VMware License Server
vCenter Server Version 4.0
VMware vCenter Server
VMware Guided Consolidation Service
VMware License Sever
VMware ADAM
VMware vCenter Management Web Server
VMware Update Manager
VMware Converter Enterprise
Guided Consolidation Service
VMware Orchestrator
VMware vSphere Host Update Utility
Chapter 2 vCenter Server Heartbeat Implementation
N
OTE Ensure that all VMware components are bound to the Principal (Public) IP address on the Principal
(Public) network adapter and that the Principal (Public) network adapter is listed first in the bind order of the
Network Connections > Advanced > Advanced Settings window.
vCenter Server with SQL Server on the Same Host
To ensure adequate performance in 20+ host or 200+ virtual machine environments, VMware recommends that
SQL Server and vCenter Server be installed on separate physical disk drives. VMDKs must be on separate
datastores to avoid potential disk bottlenecks.
vCenter Server with SQL Server on a Separate Host
When installing vCenter Server Heartbeat in an environment where SQL Server is on a separate host from
vCenter Server, repeat the installation process for the Primary and Secondary server specifically for the SQL
Server.
To ensure proper failover, increase the default Heartbeat interval for the vCenter Server from 20 to 30 seconds.
vCenter Server Only
The vCenter Server Only option requires a single iteration of the installation process because the database is
not protected.
Network Options
Networking requirements are contingent on how vCenter Server Heartbeat is deployed. To deploy as a High
Availability (HA) solution, a LAN configuration is required. To deploy vCenter Server Heartbeat for Disaster
Recovery (DR), a WAN configuration is required. Each network configuration has specific configuration
requirements to ensure proper operation.
VMware, Inc. 25
Reference Guide
LAN
When deployed in a LAN environment, vCenter Server Heartbeat requires that both servers use the same
Principal (Public) IP address. Each server also requires a separate VMware Channel IP address on a separate
dedicated subnet.
N
OTE When installing vCenter Server Heartbeat in a LAN environment, do not enable the Low Bandwidth
Module as this is designed for WAN deployments.
Primary Server
Three NICs (1 x Public and 2 x Channel) are recommended for redundancy in the event one channel fails. A
minimum of two NICs (one for the Channel, and one for the Public) are required in this configuration.
Split-brain Avoidance should be configured.
Principal (Public) network connection configured with the following:
Static IP address
Correct network mask
Correct Gateway address
Correct preferred and secondary (if applicable) DNS server address
NetBIOS enabled
Channel Network connection(s) configured with the following:
Static IP address in a different subnet than the Principal (Public) network with a different IP address
than the Secondary server channel NIC
Correct network mask
No Gateway IP address
No DNS server address
NetBIOS enabled (setup will disable this during the installation process)
Secondary Server
Networking components on the Secondary server must be configured as follows:
Same number of NICs as the Primary server
Principal (Public) network connection configured with temporary network settings
Channel network connection(s) configured with the following:
Static IP address in a different subnet than the Principal (Public) network with a different IP address
than the Primary server channel NIC
Correct network mask
No Gateway IP address
No DNS IP address
NetBIOS enabled (setup will disable this during the installation process
File and print sharing enabled
WAN
Deploying vCenter Server Heartbeat in a WAN environment requires additional considerations. Each server
within the vCenter Server Heartbeat pair requires its own separate Principal (Public) IP address and a VMware
Channel IP address in a separate dedicated subnet.
26 VMware, Inc.
Chapter 2 vCenter Server Heartbeat Implementation
WAN Requirements
WAN deployments require the following:
Persistent static routing configured for the channel connection(s) where routing is required
Two NICs (1 x Public and 1 x Channel) are recommended
At least one Domain Controller at the Disaster Recovery (DR) site
If the Primary and DR site use the same subnet:
During install, follow the steps for a LAN or VLAN on the same subnet
Both servers in the vCenter Server Heartbeat pair use the same Public IP address
If the Primary and DR site use different subnets:
During install, follow the steps for a WAN
Both servers in the vCenter Server Heartbeat pair require a separate Principal (Public) IP address and
a VMware Channel IP address in a separate dedicated subnet
Provide a user account with rights to update DNS using the DNSUpdate utility provided as a
component of vCenter Server Heartbeat through vCenter Server Heartbeat Console Application >
Ta sk > User Accounts
VMware recommends integrating Microsoft DNS into AD so that DNSUpdate can identify all DNS
Servers that require updating
At least one Domain Controller at the DR site
Refer to the following articles in the VMware Knowledge Base:
KB 1008571 – Configuring DNS in a WAN Environment
KB 1008605 – Configuring vCenter Server Heartbeat to Update BIND9 DNS Servers Deployed in a
WA N
Bandwidth
Determine the available bandwidth and estimate the required volume of data throughput to determine
acceptable latency for the throughput. Additionally, the bandwidth can affect the required queue size to
accommodate the estimated volume of data. VMware recommends making a minimum of 1Mbit of spare
bandwidth available to vCenter Server Heartbeat.
vCenter Server Heartbeat includes a Low Bandwidth Module for use in WAN environments. When enabled,
the VMware Channel compresses the data, optimizing the traffic for low bandwidth connections causing some
additional CPU load on the active server.
Latency
Latency has a direct effect on data throughput. Latency on the link should not fall below the standard defined
for a T1 connection.
Heartbeat Diagnostics can assist in determining the available bandwidth, required bandwidth, and server
workload. For more information about Heartbeat Diagnostics, contact VMware Professional Services.
Antivirus Recommendations
Consult with and implement the advice of your antivirus (AV) provider, as VMware guidelines often follow
these recommendations. Consult the VMware knowledge base for up to date information on specific AV
products.
Do not use file level AV to protect application server databases, such as MS SQL Server databases. The nature
of database contents can cause false positives in virus detection, leading to failed database applications, data
integrity errors, and performance degradation.
VMware, Inc. 27
Reference Guide
VMware recommends that when implementing vCenter Server Heartbeat, you do not replicate file level AV
temp files using vCenter Server Heartbeat.
The file level AV software running on the Primary server must be the same as the software that runs on the
Secondary server. In addition, the same file level AV must run during both active and passive roles.
Configure file level AV to use the management IP address on the passive server for virus definition updates.
If this is not possible, manually update virus definitions on the passive server.
Exclude the following VMware directories from file level AV scans (C:\Program Files\VMware\VMware
vCenter Server Heartbeat\ is the default installation directory):
C:\Program Files\VMware\VMware vCenter Server Heartbeat\r2\logs
C:\Program Files\VMware\VMware vCenter Server Heartbeat\r2\log
Any configuration changes made to a file level AV product on one server (such as exclusions) must be made
on the other server as well. vCenter Server Heartbeat does not replicate this information.
Deployment Options Summary
Tab le 2 -1 provides all possible deployment options described in this section.
Table 2-1. Installation Options
Network Clone Technique Component
vCenter Server w/SQL
LAN WAN Pre-Clone InstallClone
V2V X X X - X X X
P2V X X X X X X X
P2P X X - X X X X
Local
vCenter Server w/SQL
Remote vCenter Server Only
Installation Options Checklist
Verify the prerequisites:
Server architecture:
___ P2P
___ P2V
___ V2V
Cloning technology option:
___ Pre-Clone Install
___ Install Clone
Application components to protect:
___ vCenter Server with SQL Server on same host
___ vCenter Server with SQL Server on separate host
___ vCenter Server only
Network environment type:
___ LAN
___ WAN
28 VMware, Inc.
Chapter 2 vCenter Server Heartbeat Implementation
Is the subnet the same at the Secondary site?
If Yes, an IP address is required for this subnet
Active Directory Integrated DNS?
If Yes, a Domain Account with rights to update DNS is required.
If No, refer to the knowledge base articles in “Network Options” on page 25.
VMware, Inc. 29
Reference Guide
30 VMware, Inc.
Loading...