VMware vCenter Server Heartbeat - 6.4 Installation Manual
Installation Guide
VMware vCenter Server Heartbeat 6.4 Update 1
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-000727-00
Installation 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-2012 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 5
Getting Started
1 Introduction 9
Overview 9
vCenter Server Heartbeat Concepts 9
Architecture 9
Protection Levels 9
Communications 12
vCenter Server Heartbeat Switchover and Failover Processes 13
Installation
2 vCenter Server Heartbeat Implementation 19
Overview 19
Environmental Prerequisites 19
Common Requirements 20
Server Architecture Options 21
Virtual to Virtual 21
Physical to Virtual 21
Physical to Physical 21
Cloning Technology Options 22
Cloning Prior to Installation 22
Cloning During Installation 22
vCenter Server with SQL Server on the Same Host 24
vCenter Server with SQL Server on a Separate Host 24
vCenter Server Only 24
Network Options 24
LAN 24
WAN 25
Antivirus Recommendations 26
Deployment Options Summary 27
Installation Options Checklist 28
3 Installing vCenter Server Heartbeat 29
Overview 29
Installation Process 29
Primary Server 29
Secondary Server 37
Renaming the Servers 44
VMware vCenter Server Heartbeat Console 45
Navigate vCenter Server Heartbeat Console 46
Add a vCenter Server Group 46
Add a New Connection 46
VMware, Inc. 3
Installation Guide
Post Installation Configuration 47
Configuring SQL Server Plug-in to run with the Correct Credentials 48
Installing the View Composer Plug-in Post Installation 48
Configure the Application Timeout Exception 49
Installation of Client Tools 49
Uninstall vCenter Server Heartbeat 50
4 Unattended Installation of vCenter Server Heartbeat 53
Overview 53
Installation Process 53
Unattended Installation Command Line Usage 53
Parameter File Elements 54
Unattended Setup of the Primary Server 56
Unattended Setup of a Virtual Secondary Server 57
Unattended Setup of a Physical Secondary Server 59
Renaming the Servers 60
Post Installation Configuration 61
Configuring VirtualCenter Plug-in with the Correct Credentials 62
Configuring SQL Server Plug-in to run with the Correct Credentials 62
Installing the View Composer Plug-in Post Installation 63
Unattended Installation of Client Tools 63
Unattended Uninstall of vCenter Server Heartbeat 64
Appendix – Setup Error Messages 65
Glossary 67
4 VMware, Inc.
About This Book
The Installation Guide provides information about installing VMware vCenter Server Heartbeat, including
implementation in a Local Area Network (LAN) or Wide Area Network (WAN). 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 the reader has working knowledge of networks including the configuration of TCP/IP
protocols and domain administration on the Windows™ 2003 and 2008 platforms, notably in Active Directory
and DNS.
VMware Technical Publications Glossary
VMware Technical Publications provides a glossary of terms that might be unfamiliar to you. For definitions
of terms as they are used in VMware technical documentation go to http://www.vmware.com/support/pubs.
Overview of Content
This guide is designed to give guidance on the installation vCenter Server Heartbeat, and is organized into the
following sections:
Preface — About This Book (this chapter) provides an overview of this guide and the conventions used
throughout.
Chapter 1 — Introduction presents an overview of vCenter Server Heartbeat concepts including the
Switchover and Failover processes.
Chapter 2 — vCenter Server Heartbeat Implementation discusses environmental prerequisites and common
requirements for installation, options for server architecture, cloning technology, application components,
and network configurations. It also gives guidance on antivirus solutions, and provides a convenient
summary and checklist to follow as you perform the installation.
Chapter 3— Installing vCenter Server Heartbeat describes the installation process, guides you through
installation on the Primary and Secondary servers, and through post-installation configuration.
Appendix A— Setup Error Messages lists error messages that may appear during setup and tests that will
help you resolve the errors.
Document Feedback
VMware welcomes your suggestions for improving our documentation and invites you to send your feedback
to docfeedback@vmware.com.
VMware, Inc. 5
Installation Guide
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
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
Go to www.vmware.com/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/phone_support.html to find out how to use telephone support for the
fastest response on priority 1 issues (applies to customers with appropriate support contracts).
Support Offerings
Go to www.vmware.com/support/services to find out how VMware support offerings can help meet your
business needs.
VMware Professional Services
Go to www.vmware.com/services to access information about education classes, certification programs, and
consulting 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.
6 VMware, Inc.
Getting Started
VMware, Inc. 7
Installation Guide
8 VMware, Inc.
1
Introduction
This chapter includes the following topics:
“vCenter Server Heartbeat Concepts” on page 9
“vCenter Server Heartbeat Switchover and Failover Processes” on page 13
Overview
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 Concepts
Architecture
vCenter Server Heartbeat software is installed on a Primary (production) server and a Secondary
(ready-standby) server. These names refer to the physical hardware (identity) of the servers.
Depending on the network environment, vCenter Server Heartbeat can be deployed in a Local Area Network
(LAN) for High Availability or Wide Area Network (WAN) for Disaster Recovery, providing the flexibility
necessary to address most network environments. Depending on the network environment and architecture
selected, vCenter Server Heartbeat can be configured where the Primary and Secondary server have the same
Principal (Public) IP address or where the Primary and Secondary servers share the Principal (Public) IP
address.
1
When deployed, one of the servers performs the role of the active server that is visible on the Public network
while the other is passive and hidden from the Public network but remains as a ready-standby server. The
Secondary server has a different Fully Qualified Domain Name (FQDN) than the Primary server but uses the
same file and data structure, same Principal (Public) network address, and can run all the same applications
and services as the Primary server. Only one server can display the Principal (Public) IP address and be visible
on the Public network at any given time. 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 protected
applications to the user.
vCenter Server Heartbeat provides continuous access to the passive server simultaneously while the active
server continues to service clients allowing the passive server to be easily accessed for maintenance purposes,
updating anti-virus definition files, receiving operating system hot-fixes, updates and patches from
third-party management software, and allows use of third-party monitoring tools.
Protection Levels
vCenter Server Heartbeat provides the following protection levels:
VMware, Inc. 9
Installation Guide
Server Protection – vCenter Server Heartbeat provides continuous availability to end users through a
Network Protection – vCenter Server Heartbeat proactively monitors the network by polling up to three
Application Protection – vCenter Server Heartbeat maintains the application environment ensuring that
Performance Protection – vCenter Server Heartbeat proactively monitors system performance attributes
Data Protection – vCenter Server Heartbeat intercepts all data written by users and applications, and
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.
Server Protection
vCenter Server Heartbeat provides continuous availability to end users through a hardware failure scenario
or operating system crash. Additionally, vCenter Server Heartbeat ensures users are provided with a replica
server on the failure of the production server.
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 on the failure
of the production server.
nodes to ensure that the active server is visible on the network.
applications and services stay alive on the network.
to ensure that the system administrator is notified of problems and can take pre-emptive action to prevent
an outage.
maintains a copy of this data on the passive server that can be used in the event of a failure.
Two instances of vCenter Server Heartbeat regularly send “I’m alive” messages and message
acknowledgments to one another over a network connection referred to as the VMware Channel to detect
interruptions in responsiveness. If the passive server detects that this monitoring process (referred to as the
heartbeat) has failed, it initiates a failover as illustrated in Figure 1-1.
Figure 1-1. Failover
A failover is similar to a switchover but is used in more urgent situations, such as when the passive server
detects that the active server is no longer responding. This can occur when the active server hardware fails,
loses its network connections, or otherwise becomes unavailable. Rather than the active server gracefully
closing, the passive server determines that the active server has failed and requires no further operations. In a
failover, the passive server immediately assumes the active server role. The failover process is discussed later
in this guide.
10 VMware, Inc.
Chapter 1 Introduction
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. vCenter Server Heartbeat polls defined nodes around the network,
including the default gateway, the primary DNS server, and the global catalog server at regular intervals. If
all three nodes fail to respond, for example, in the case of a network card failure or a local switch failure,
vCenter Server Heartbeat can initiate a switchover, allowing the Secondary server to assume an the same role
as the Primary server.
Application Protection
vCenter Server Heartbeat running on the active server locally monitors the applications and services it has
been configured to protect (through the use of plug-ins) to verify that protected applications are operational
and not in an unresponsive or stopped state. This level of monitoring is fundamental in ensuring that
applications remain available to users.
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 “vCenter Server Heartbeat Switchover and Failover Processes” on page 13 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.
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 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.
In addition to monitoring application services, vCenter Server Heartbeat can monitor specific application
attributes to ensure that they remain within normal operating ranges. Similar to application monitoring,
various rules can be configured to trigger specific corrective actions whenever these attributes fall outside of
their respective ranges.
VMware, Inc. 11
Installation Guide
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.
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 near-real time to the passive server. If a failover
occurs, all files protected on the failed server are available to users after the failover, hosted on the Secondary
server.
Figure 1-3. Apply Process
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.
12 VMware, Inc.
Chapter 1 Introduction
Figure 1-4. Communication Between Primary and Secondary Servers
The IP address a client uses to connect to the active server (the Principal (Public) IP address) must be
configured as a static IP address, that is, not DHCP (Dynamic Host Configuration Protocol) enabled. In the
figure above, 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, add the switch /All to the ipconfig command.
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.
The NICs on the active and passive servers used for the VMware Channel are configured so that their IP
addresses are outside of the subnet range of the Principal (Public) network. These addresses are referred to as
VMware Channel addresses.
During installation, setup will switch off NetBIOS for the VMware Channel(s) on the active and passive
servers. Following restore and after the vCenter Server Heartbeat installation completes (runtime), NetBIOS is
disabled across the channel(s).
The NICs that support 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.
vCenter Server Heartbeat Switchover and Failover Processes
vCenter Server Heartbeat uses four different procedures — managed switchover, automatic switchover,
automatic failover, and managed failover — to change the role of the active and passive servers depending on
the status of the active server.
Managed Switchover
You can click Make Active on the vCenter Server Heartbeat Console Server: Summary page to manually
initiate a managed switchover. When a managed 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 reversed.
VMware, Inc. 13
Installation Guide
Figure 1-5. Switchover
A managed switchover performs 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 Re-designate the Secondary server as the new active server. After this step, vCenter Server Heartbeat:
Hides the previously active server from the network.
Makes the newly active server visible on the network. The newly active server begins to intercept and
queue disk I/O operations for the newly passive server.
4 vCenter Server Heartbeat causes the newly passive server to begin accepting updates from the active
server.
5 vCenter Server Heartbeat starts the same protected applications on the new active server. The protected
applications become accessible to users. The managed switchover is complete.
Automatic Switchover
Automatic switchover (auto-switchover) is similar to failover (discussed in the next section) but is triggered
automatically when system monitoring detects failure of a protected application.
Like managed switchover, auto-switchover changes the server roles but then stops vCenter Server Heartbeat
on the previously active server to allow the administrator to investigate the cause of the auto-switchover and
verify the integrity of the data.
After the cause for the auto-switchover is determined and corrected, the administrator can use vCenter Server
Heartbeat Console to return the server roles to their original state.
Automatic Failover
Automatic failover is similar to automatic switchover (discussed above) but is triggered when the passive
server detects that the active server is no longer running properly and assumes the role of the active server.
14 VMware, Inc.
Chapter 1 Introduction
Figure 1-6. Failover
During the automatic failover, the passive server performs the following steps:
1 Apply any intercepted updates currently in the passive server’s receive queue as identified by the log of
update records that are saved on the passive server but not yet applied to the replicated files.
The amount of data in the passive server’s receive queue affects the time required to complete the failover
process. If the passive server’s receive queue is long, the system must wait for all updates to the passive
server to complete before the rest of the process can take place. An update record can be applied only if
all earlier update records are applied, and the completion status for the update is in the passive server’s
receive queue. When no more update records can be applied, any update records that cannot be applied
are discarded.
2 Switch mode of operation from passive to active.
This enables the public identity of the server. The active and passive servers both use the same Principal
(Public) IP address. This Principal (Public) IP address can be enabled only on one system at anytime.
When the public identity is enabled, any clients previously connected to the server before the automatic
failover are able to reconnect.
3 Start intercepting updates to protected data. Any updates to the protected data are saved in the send
queue on the local server.
4 Start all protected applications. The applications use the replicated application data to recover, and then
accept re-connections from any clients. Any updates that the applications make to the protected data are
intercepted and logged.
At this point, the originally active server is offline and the originally passive server is filling the active role
and is running the protected applications. Any updates that completed before the failover are retained.
Application clients can reconnect to the application and continue running as before.
Managed Failover
Managed failover is similar to automatic failover in that the passive server automatically determines that the
active server has failed and can warn the system administrator about the failure; but no failover actually occurs
until the system administrator manually triggers this operation.
Automatic Switchover and Failover in a WAN Environment
Automatic switchover and failover in a WAN environment differ from a automatic switchover and failover in
a LAN environment due to the nature of the WAN connection. In a WAN environment, automatic switchover
and failover are disabled by default in the event that the WAN connection is lost.
Should a condition arise that would normally trigger an automatic switchover or failover, the administrator
will receive vCenter Server Heartbeat alerts. The administrator must manually click the Make Active button
on the Server: Summary page of the vCenter Server Heartbeat Console to allow the roles of the servers to
switch over the WAN.
VMware, Inc. 15
Installation Guide
To enable Automatic Switchover in a WAN
1 In the vCenter Server Heartbeat Console, click the Network tab to display the Network Monitoring page.
2Click Configure Auto-switchover.
3 Select the Auto-switchover if client network connectivity lost for check box.
4 Configure the number of pings to wait before performing the auto-switchover.
5Click OK.
16 VMware, Inc.
Installation
VMware, Inc. 17
Installation Guide
18 VMware, Inc.
2
vCenter Server Heartbeat Implementation
This chapter includes the following topics:
“Overview” on page 19
“Environmental Prerequisites” on page 19
“Common Requirements” on page 20
“Server Architecture Options” on page 21
“Cloning Technology Options” on page 22
“Application Component Options” on page 22
“Network Options” on page 24
“Antivirus Recommendations” on page 26
“Deployment Options Summary” on page 27
Overview
vCenter Server Heartbeat is a versatile solution that provides 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 its Database 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 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.
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. 19
Installation Guide
Common Requirements
The following requirements are in addition to those required for vCenter Server and SQL Server.
Supported vCenter Server Versions
vCenter Server 4.0 Update 1
vCenter Server 4.0 Update 2
vCenter Server 4.0 Update 3
vCenter Server 4.1
vCenter Server 4.1 Update 1
vCenter Server 5.0
vCenter Server 5.0 Update 1
Operating Systems
Windows Server 2003 x86 Standard/Enterprise/Datacenter SP1 and SP2
Windows Server 2003 x64 Standard/Enterprise/Datacenter SP2
Windows Server 2003 R2 x64 Standard/Enterprise/Datacenter SP2
Windows Server 2008 x86 Standard/Enterprise/Datacenter SP1 and SP2
Windows Server 2008 x64 Standard/Enterprise/Datacenter SP1 and SP2
Windows Server 2008 R2 Standard/Enterprise/Datacenter SP1
N
OTE vCenter Server Heartbeat supports protection of both standalone instances of vCenter Server 4.0.x
and also when in Linked Mode groups.
Prior to installing vCenter Server Heartbeat, verify that the Primary server is a member of the domain.
The Domain for the Primary server will not change throughout the installation process although the
Primary and Secondary server names will be changed as part of the installation procedure.
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.
20 VMware, Inc.
When installing into a Windows Server 2008 or 2008 R2 environment, verify that Windows Server Backup
Feature and Command Line Tools have been installed on the Primary and Secondary servers prior to
installing vCenter Server Heartbeat. Installation of Windows Server Backup Feature and Command Line
Tools will also install Windows PowerShell.
Server Architecture Options
The selected server architecture affects the requirements for hardware and the technique used to clone the
Primary server.
Virtual to Virtual
Virtual to Virtual 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.
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)
Chapter 2 vCenter Server Heartbeat Implementation
Appropriate resource pool priorities
Each virtual machine used in the Virtual to Virtual 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
The Physical to Virtual 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 Physical to Virtual 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
The Physical to Physical architecture is used in environments where both the Primary and Secondary servers
are physical servers. Use of Physical to Physical limits installation options as it requires cloning using vCenter
Server Heartbeats native cloning during the installation process. 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 20.
VMware, Inc. 21
Installation Guide
Software as specified in “Common Requirements” on page 20.
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
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.
Software on the Secondary server must meet the following requirements.
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 technologies
depending on the selected server architecture.
Cloning Prior to Installation
The following cloning technologies are supported for creating cloned images for use as a Secondary server
before you begin installing vCenter Server Heartbeat:
VMware vCenter Converter for “Physical to Virtual” on page 21.
VMware vCenter virtual machine cloning for “Virtual to Virtual” on page 21.
Cloning During Installation
Installation of vCenter Server Heartbeat provides support for NTBackup on Windows 2003 and Wbadmin on
Windows Server 2008 for automated cloning during the installation process. The process is automated but
requires meeting all prerequisites for the Secondary server specified in “Physical to Physical” on page 21.
Application Component Options
vCenter Server Heartbeat can accommodate any of the supported vCenter Server configurations and protects
the following components:
vCenter Server Version 4.0
22 VMware, Inc.
Loading...