HP Rx2620-2 - Integrity - 0 MB RAM Operator's manual

HP Integrity Servers with Microsoft Windows
Server 2003
Cluster Installation and Configuration Guide
HP Part Number: 5992-0936
Published: September 2007

©Copyright 2007 Hewlett-Packard Development Company, L.P.
Legal Notices
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP
shall not be liable for technical or editorial errors or omissions contained herein.
Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.
Intel and Itanium are registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Java is a U.S. trademark of Sun Microsystems, Inc.
UNIX is a registered trademark of The Open Group.

Table of Contents
About This Document.........................................................................................................9
Intended Audience.................................................................................................................................9
New and Changed Information in This Edition.....................................................................................9
Document Organization.........................................................................................................................9
Typographic Conventions......................................................................................................................9
Related Information..............................................................................................................................10
Publishing History................................................................................................................................10
HP Encourages Your Comments..........................................................................................................10
1 Introduction...................................................................................................................11
Clustering Overview.............................................................................................................................11
Server Cluster Versus Network Load Balancing..................................................................................12
Server Cluster..................................................................................................................................13
NLB..................................................................................................................................................13
Cluster Terminology.............................................................................................................................14
Nodes...............................................................................................................................................14
Cluster Service.................................................................................................................................14
Shared Disks....................................................................................................................................14
Resources.........................................................................................................................................14
Resource Dependencies...................................................................................................................15
Groups.............................................................................................................................................15
Quorums..........................................................................................................................................15
Single Quorum...........................................................................................................................16
Majority Node Set (MNS) Quorum............................................................................................17
Heartbeats........................................................................................................................................18
Virtual Servers.................................................................................................................................18
Failover............................................................................................................................................18
Failback............................................................................................................................................19
2 Administering the cluster.............................................................................................21
Verifying Minimum System Requirements..........................................................................................21
Gathering Required Installation Information.......................................................................................22
Creating and Configuring the Cluster..................................................................................................24
Configuring the Public and Private Networks................................................................................25
Private Network.........................................................................................................................25
Public Networks.........................................................................................................................26
NIC Teaming..............................................................................................................................27
Preparing Node 1 for Clustering.....................................................................................................27
Configuring the Shared Storage......................................................................................................27
Preparing Node 2+ for Clustering...................................................................................................28
Creating the Cluster.........................................................................................................................29
Joining Node 2+ to the Cluster........................................................................................................29
Configuring Private and Public Network Role and Priority Settings.............................................30
Validating Cluster Operation................................................................................................................31
Method 1: Simulate a Failover.........................................................................................................31
Method 2: Run the Cluster Diagnostics and Verification Tool........................................................31
Upgrading Individual Nodes...............................................................................................................31
Table of Contents 3

4

List of Figures
1-1 NLB Example.................................................................................................................................14
1-2 Single Quorum Example...............................................................................................................16
1-3 MNS Quorum Example.................................................................................................................17
2-1 Example cluster hardware cabling scheme...................................................................................22
5

6

List of Tables
1-1 Server Cluster and NLB Features..................................................................................................12
2-1 Installation and Configuration Input ...........................................................................................23
7

8

About This Document
This document describes how to install and configure clustered computing solutions using HP
Integrity servers running Microsoft® Windows® Server 2003.
The document printing date and part number indicate the document’s current edition. The
printing date changes when a new edition is printed. Minor changes may be made at reprint
without changing the printing date. The document part number changes when extensive changes
are made.
Document updates may be issued between editions to correct errors or document product changes.
To ensure that you receive the updated or new editions, you should subscribe to the appropriate
product support service. See your HP sales representative for details.
The latest version of this document can be found online at http://www.docs.hp.com.
Intended Audience
This document is intended for system administrators and HP support personnel responsible for
installing, configuring, and managing clustered computing solutions using HP Integrity servers.
This document is not a tutorial.
New and Changed Information in This Edition
This document includes the following changes since its last release:
• Added “About This Document” section
• Includes changes per ATCL editor
Document Organization
This document is organized as follows:
Chapter 1 “Introduction”. Describes cluster concepts and terminology.Chapter 1
Chapter 2 “Administering the cluster”. Describes how to set up and administer clusters.Chapter 2
Typographic Conventions
This document uses the following typographical conventions:
WARNING A warning calls attention to important information that if not understood
or followed will result in personal injury or nonrecoverable system
problems.
CAUTION A caution calls attention to important information that if not understood
or followed will result in data loss, data corruption, or damage to
hardware or software.
IMPORTANT This alert provides essential information to explain a concept or to
complete a task
NOTE A note contains additional information to emphasize or supplement
important points of the main text.
KeyCap The name of a keyboard key or graphical interface item (such as buttons,
tabs, and menu items). Note that Return and Enter both refer to the
same key.
Computer output Text displayed by the computer.
User input Commands and other text that you type.
Command A command name or qualified command phrase.
Intended Audience 9

Ctrl+x A key sequence. A sequence such as Ctrl+x indicates that you must hold
down the key labeled Ctrl while you press another key or mouse button.
[] The contents are optional in command line syntax. If the contents are a
list separated by |, you must choose one of the items.
{} The contents are required in command line syntax. If the contents are a
list separated by |, you must choose one of the items.
... The preceding element can be repeated an arbitrary number of times.
 Indicates the continuation of a code example.
| Separates items in a list of choices.
Related Information
You can find more information about HP Integrity servers, server management, and software
in the following locations:
• For more information about cluster configuration and supported storage systems:
http://h18004.www1.hp.com/solutions/enterprise/highavailability/answercenter/
configuration-all-list.html#03ei
• For more information about troubleshooting and maintaining clusters:
http://technet2.microsoft.com/windowsserver/en/library/
549145e4-4f5d-4545-a9b5-53ebd86d75911033.mspx?mfr=true
• For more information about network load balancing (NLB):
http://technet2.microsoft.com/WindowsServer/en/library/
98d46a24-96d8-412c-87d8-28ace62323d21033.mspx?mfr=true
Publishing History
The publishing history below identifies the edition dates of this manual. Updates are made to
this publication on an unscheduled, as needed, basis. The updates will consist of a complete
replacement manual and pertinent online or CD documentation.
Publication DateSupported Products
(Servers)
Supported SmartSetup
Version
Supported Operating
Systems
Manufacturing Part
Number
December, 2007BL860c, BL870c,
rx1620, rx2620,
rx2660, rx3600,
rx4640, rx6600,
rx7620, rx7640,
rx8620, rx8640,
Superdome,
Superdome/sx2000
Version 5.5Microsoft Windows
Server 2003 for
Itanium-based
Systems, 64-bit
5992-0936
HP Encourages Your Comments
HP encourages your comments concerning this document. We are committed to providing
documentation that meets your needs. Send any errors found, suggestions for improvement, or
compliments to:
[email protected]
Please include the document title, manufacturing part number, and any comment, error found,
or suggestion for improvement you have concerning this document.
10

1 Introduction
This document describes how to install and configure clustered computing solutions using HP
Integrity servers running Microsoft® Windows® Server 2003.
The clustering improvements for Microsoft Windows Server 2003, 64-bit Edition (over Microsoft
Windows 2000) include the following:
Larger cluster sizes 64-bit Enterprise and Datacenter Editions now support up
to eight nodes.
Enhanced cluster installation wizard Built-in validation and verification function helps ensure
base components are ready to be clustered.
Installation Clustering software is automatically copied during
operating system installation.
Multi-node addition Multiple nodes can now be added in a single operation
instead of one by one.
Active Directory integration Tighter integration including a virtual computer object,
Kerberos authentication, and a default location for services
to publish service control points. Users can access the
virtual server just like any other Windows server.
Clustering Overview
A cluster is a group of individual servers, or nodes, configured to appear as a single, virtual
server to both users and applications. The nodes making up the cluster run a common set of
applications. They are physically connected by cables and programmatically connected by the
clustering software.
Clusters provide the following advantages over standalone servers:
High availability Clusters avoid single points of failure. Applications can be distributed
over more than one node, creating a high degree of parallelism and
failure recovery.
Manageability Clusters appear as a single system to end users, applications, and the
network, while providing a single point of control for administrators
both locally and remotely.
Scalability You can increase the cluster's computing power by adding more
processors or computers. Applications can also be scaled according
to need as your organization grows.
Because of the inherent redundancy of hardware and software, clusters protect businesses from
system downtime due to single points of failure, power outages, natural disasters, and even
during routine system maintenance or upgrades. In addition, clusters help businesses eliminate
penalties and other costs associated with not being able to meet Service Level Agreements.
A cluster is similar to a general distributed system, except that it provides the following additional
capabilities:
• Every node has full connectivity and communication with the other nodes in the cluster
through the following methods:
Hard disks on a shared bus One or more shared buses are used for storage. Each
shared bus attaches one or more disks that hold data
used to manage the cluster. Cluster service provides
a dual-access storage model whereby multiple systems
in the cluster can access the same storage.
Private network One or more private networks, or interconnects, carry
internal cluster communication only (heartbeats). At
least one private network is required.
Clustering Overview 11

Public network One or more public networks can be used as a backup
for the private network and can be used both for
internal cluster communication and to host client
applications. Network adapters, known to the cluster
as network interfaces, attach nodes to networks.
• Each node tracks cluster configuration. Every node in the cluster is aware when another
node joins or leaves the cluster.
• Every node in the cluster is aware of the resources that are running locally and the resources
that are running on the other nodes.
You can create clusters using nodes that have different numbers of CPUs, CPUs with different
clock speeds, or even from nodes running different Integrity platforms. Diverse configurations
are tested, qualified, and certified frequently by HP. The only limitations are that each node must
be an HP Integrity system, and each node must have the same Host Bus Adaptors (HBAs), HBA
drivers, and HBA firmware.
Server Cluster Versus Network Load Balancing
Windows Server 2003 provides two types of clustering services:
Server Cluster Available only in Windows Server 2003 Enterprise Edition
or Datacenter Edition, this service provides high
availability and scalability for mission-critical applications
such as databases, messaging systems, and file and print
services. The nodes in the cluster remain in constant
communication. If one of the nodes becomes unavailable
because of failure or maintenance, another node
immediately begins providing service, a process known
as failover. Users accessing the service continue to access
it, unaware that it is now being provided from a different
node. Both Windows Server 2003 Enterprise Edition and
Datacenter Edition support server cluster configurations
of up to eight nodes.
Network Load Balancing (NLB) Available in all editions of Windows Server 2003, this
service load balances incoming IP traffic across clusters.
NLB enhances both the availability and scalability of
Internet server-based programs such as web servers,
streaming media servers, and Terminal Services. By acting
as the load balancing infrastructure and providing control
information to management applications built on top of
Windows Management Instrumentation (WMI), NLB can
integrate into existing web server farm infrastructures.
NLB clusters can scale to 32 nodes.
Table 1-1 summarizes some of the differences between these two technologies.
Table 1-1 Server Cluster and NLB Features
NLBServer Cluster
Used for web servers, firewalls, and web servicesUsed for databases, email services, line of business
(LOB) applications, and custom applications
Included with all versions of Windows Server 2003Included with Windows Server 2003 Enterprise
Edition and Datacenter Edition
Provides high availability and scalabilityProvides high availability and server consolidation
Generally deployed on a single network, but can span
multiple networks if properly configured
Can be deployed on a single network or a
geographically distributed network
12 Introduction

Table 1-1 Server Cluster and NLB Features (continued)
NLBServer Cluster
Supports clusters up to 32 nodesSupports clusters up to eight nodes
Doesn't require any special hardware or softwareRequires the use of shared or replicated storage
Server Cluster
Use a server cluster to provide high availability for mission critical applications through failover.
It uses a shared-nothing architecture, which means that a resource can be active on only one
node in the cluster at any given time. Because of this, it is well suited to applications that maintain
some sort of fixed state (for example, a database). In addition to database applications, enterprise
resource planning (ERP), customer relationship management (CRM), online transaction processing
(OLTP), file and print, email, and custom application services are typically clustered using server
cluster.
When you deploy a server cluster, first configure the two to eight servers that will act as nodes
in the cluster. Then configure the cluster resources that are required by the application you are
clustering. These resources can include network names, IP addresses, applications, services, and
disk drives. Finally, bring the cluster online so that it can begin processing client requests.
Most clustered applications and their associated resources are assigned to one cluster node at a
time. If a server cluster detects the failure of the primary node for a clustered application, or if
that node is taken offline for maintenance, the clustered application is started on a backup cluster
node. Client requests are immediately redirected to the backup cluster node to minimize the
impact of the failure.
NOTE: Though most clustered services run on only one node at a time, a cluster can run many
services simultaneously to optimize hardware utilization. Some clustered applications can run
on multiple Server Cluster nodes simultaneously, including Microsoft SQL Server.
NLB
Use NLB to provide high availability for applications that scale out horizontally and do not
maintain a fixed state, such as web servers, proxy servers, and other services that need client
requests distributed across nodes in a cluster. NLB uses a load balancing architecture, which
means that a resource can be active on all nodes in the cluster at any given time.
NLB clusters do not use a quorum, and so they don't impose storage or network requirements
on the cluster nodes. If a node in the cluster fails, NLB automatically redirects incoming requests
to the remaining nodes. If you take a node in the cluster offline for maintenance, you can use
NLB to allow existing client sessions to finish before taking the node offline. This eliminates any
end-user impact during planned downtime. NLB can also weigh requests, which enables you to
mix high-powered servers with legacy servers and ensure all hardware is efficiently used.
Most often, NLB is used to build redundancy and scalability for firewalls, proxy servers, or web
servers, as illustrated in Figure 1-1. Other applications commonly clustered with NLB include
virtual VPN endpoints, streaming media servers, and Terminal Services.
For more information about the key features of this technology and its internal architecture and
performance characteristics, go to:
http://technet2.microsoft.com/WindowsServer/en/library/
98d46a24-96d8-412c-87d8-28ace62323d21033.mspx?mfr=true
Server Cluster Versus Network Load Balancing 13

Figure 1-1 NLB Example
Cluster Terminology
A working knowledge of clustering begins with the definition of some common terms. The
following terms are used throughout this document.
Nodes
Individual servers or members of a cluster are referred to as nodes or systems (the terms are
used interchangeably). A node can be an active or inactive member of a cluster, depending on
whether or not it is currently online and in communication with the other cluster nodes. An
active node can act as host to one or more cluster groups.
Cluster Service
Cluster service refers to the collection of clustering software on each node that manages all
cluster-specific activity.
Shared Disks
Shared disks are devices (normally hard disk drives) that the cluster nodes are attached to by a
shared bus. Applications, file shares, and other resources to be managed by the cluster are stored
on the shared disks.
Resources
Resources are physical or logical entities (such as file shares) managed by the cluster software.
Resources can provide a service to clients or be an integral part of the cluster. Examples of
resources are physical hardware devices such as disk drives, or logical items such as IP addresses,
network names, applications, and services. Resources are the basic unit of management by the
cluster service. A resource can only run on a single node in a cluster at a time, and is online on
a node when it is providing its service on that node.
At any given time, a resource can exhibit only one of the following states:
• Offline
• Offline pending
• Online
• Online pending
• Failed
When a resource is offline, it is unavailable for use by a client or another resource. When a
resource is online, it is available for use. The initial state of any resource is offline. When a resource
is in one of the pending states, it is in the process of either being brought online or taken offline.
14 Introduction

If the resource cannot be brought online or taken offline after a specified amount of time, and
the resource is set to the failed state, you can specify the amount of time that cluster service waits
before failing the resource by setting its pending timeout value in Cluster Administrator.
Resource state changes can occur either manually (when you use Cluster Administrator to make
a state transition) or automatically (during the failover process). When a group fails over, the
states of each resource are altered according to their dependencies on the other resources in the
group.
Resource Dependencies
A dependency is a reliance between two resources that makes it necessary for both resources to
run on the same node (for example, a Network Name resource depending on an IP address).
The only dependency relationships that cluster service recognizes are relationships between
resources. Cluster service cannot be told, for example, that a resource depends on a Windows
2003 service; the resource can only be dependent on a resource representing that service.
Groups
Groups are a collection of resources to be managed as a single unit for configuration and recovery
purposes. Operations performed on a group, such as taking it offline or moving it to another
node, affect all resources contained within that group. Usually a group contains all the elements
needed to run a specific application, and for client systems to connect to the service provided by
the application.
If a resource depends on another resource, both resources must be a member of the same group.
For example, in a file share resource, the group containing the file share must also contain the
disk resource and network resources (such as the IP address and NetBIOS name) to which clients
connect to access the share. All resources within a group must be online on the same node in the
cluster.
NOTE: During failover, entire groups are moved from one node to another node in the cluster.
A single resource cannot fail from one node to another.
Quorums
Each cluster has a special resource called the quorum. The quorum provides a means for
arbitration leading to node membership and cluster state decisions. Only one node at a time can
own the quorum. That node is designated as the primary node. When a primary node fails over
to a backup node, the backup node takes ownership of the quorum.
The quorum resource also provides physical storage to maintain the configuration information
for the cluster. This information is kept in the quorum log, which is a configuration database for
the cluster. The log holds cluster configuration information, such as which servers are part of
the cluster, what resources are installed in the cluster, and what state those resources are in. By
default the quorum log is located at \MSCS\quolog.log.
NOTE: Quorums are only used in the server cluster, not in NLB. References to quorums
throughout the remainder of this document apply to server clusters only.
The quorum resource is important in a cluster for the following reasons:
Consistency Because a cluster is multiple physical servers acting as a single virtual server,
it is critical that each physical server have a consistent view of how the cluster
is configured. The quorum acts as the definitive repository for all configuration
information relating to the cluster. In the event that the cluster service is unable
to read the quorum log, it cannot start because it is unable to guarantee that
the cluster is in a consistent state.
Cluster Terminology 15

Arbitration The quorum is used as the tie-breaker to avoid split-brain scenarios. A
split-brain scenario occurs when all network communication links between
two or more cluster nodes fail. In these cases, the cluster can split into two or
more partitions that cannot communicate with each other. The quorum then
guarantees that any cluster resource is brought online on one node only. It
does this by allowing the partition that owns the quorum to continue, while
the other partitions are evicted from the cluster.
There are two types quorums: the single quorum and the Majority Node Set (MNS) quorum.
Single quorum clusters behave differently than MNS quorum clusters, so take care when choosing
a model for your cluster.
For example, if you have only two nodes in your cluster, the MNS model is not recommended
because failure of one node leads to failure of the entire cluster (a majority of nodes is impossible).
After the cluster is created, you cannot change the quorum from one type to another.
Single Quorum
A single quorum uses a quorum log file located on a single disk hosted on a shared storage
interconnect that is accessible by all nodes in the cluster. Single quorums are available in Windows
Server 2003 Enterprise Edition and Datacenter Edition.
IMPORTANT: The quorum must use a physical disk resource, as opposed to a disk partition,
because the entire physical disk resource is moved during failover.
NOTE: You can configure clusters to use the local hard disk on one node to store the quorum,
but this is only supported for testing and development purposes. Do not use this configuration
in a production environment. Each node connects to the shared storage through some type of
interconnect, with the storage consisting of either external hard disks (usually configured as
RAID disks), or a storage area network (SAN), where logical slices of the SAN are presented as
physical disks.
The following figure shows a single quorum in a four-node cluster.
Figure 1-2 Single Quorum Example
Single quorums are sufficient for most clusters. The following are typical single quorum situations:
Highly available data in a single
location
Most customers that require their data to be highly
available need this on a per-site basis only. If they have
multiple sites, each site has its own cluster. Typical
applications that use this type of cluster include Microsoft
SQL Server, file shares, printer queues, and network
services (for example, DHCP and WINS).
16 Introduction

Stateful applications Applications or Windows NT services that require only a
single instance at any time and require state information
to be stored typically use single quorums, because they
already have shared state information storage.
Connecting all nodes to a single storage device simplifies transferring control of the data to a
backup node. Another advantage is that only one node must remain active for the cluster to
function.
However, this architecture has several weaknesses. If the storage device fails, the entire cluster
fails. If the storage area network (SAN) fails, the entire cluster fails. And while the storage device
and SAN can be designed with complete redundancy to eliminate those possibilities, there is
one component in this architecture that can never be truly redundant — the facility itself.
Floods, fires, earthquakes, extended power failures, and other serious problems cause the entire
cluster to fail. If your business requires that work continue even if the facility is taken offline, a
single quorum cluster solution will not meet your needs.
Majority Node Set (MNS) Quorum
A Majority Node Set (MNS) quorum appears to the server cluster as a single quorum resource.
However, the data is stored on the system disk of each node of the cluster by default. The
clustering software ensures that the configuration data stored on the MNS is kept consistent
across the different disks. MNS quorums are available in Windows Server 2003 Enterprise Edition
and Datacenter Edition.
As Figure 1-3 shows, MNS clusters require only that the cluster nodes be connected by a network.
That network does not need to be a LAN. It can be a wide area network (WAN) or a virtual
private network (VPN) connecting cluster nodes in different buildings or even cities. This enables
the cluster to overcome geographic restrictions imposed by its storage connections.
Figure 1-3 shows an MNS quorum in a four-node cluster.
Figure 1-3 MNS Quorum Example
Although the disks that make up the MNS can be disks on a shared storage fabric, the MNS
implementation provided as part of Windows Server 2003 uses a directory on each node's local
system disk to store the quorum data. If the configuration of the cluster changes, that change is
reflected across the different disks. The change is committed, or made persistent, only if that
change is made to the following:
(<Number of nodes configured in the cluster>/2) + 1
This ensures that a majority of the nodes have an up-to-date copy of the data. The cluster service
itself only starts up and brings resources online if a majority of the nodes configured as part of
the cluster are up and running the cluster service. If there are fewer nodes, the cluster does not
have a quorum and the cluster service waits until more nodes join. Only when a quorum of nodes
are available can the cluster service start up and bring the resources online. This ensures that the
cluster always starts up with the most up-to-date configuration.
Cluster Terminology 17

In the case of a failure or split-brain, all partitions that do not contain an MNS quorum are
terminated. This ensures that if there is a partition running that contains a majority of the nodes,
it can safely start up any resources that are not running on that partition. Thus, it can be the only
partition in the cluster that is running resources.
MNS quorums have strict requirements to ensure they work correctly. Be sure that you fully
understand the issues involved in using MNS-based clusters before implementing this solution.
Use MNS quorums only in the following situations:
Geographically dispersed clusters A single MSCS cluster has members in multiple geographic
sites. Though geographic clusters can use a standard
quorum, presenting the quorum as a single, logical shared
drive among all sites can be challenging. MNS quorums
solve these challenges by enabling the quorum to be stored
on the local hard disk.
NOTE: HP supports geographically dispersed clusters
with shared quorums using Cluster Extension XP (CLX)
and Continuous Access (CA) technology on XP storage
products.
Clusters with no shared disks Some specialized configurations need tightly consistent
cluster features without having sharing disks. For example:
• Clusters that host applications that can failover, but
where another, application-specific method can keep
data consistent between nodes (for example, database
log shipping for keeping the database state up-to-date,
or file replication for static data).
• Clusters that host applications that have no persistent
data but must cooperate in a tightly coupled way to
provide a consistent volatile state.
• Independent Software Vendors (ISVs): By abstracting
storage from the cluster service, an MNS quorum
provides ISVs with greater flexibility to design
sophisticated cluster scenarios.
Heartbeats
Heartbeats are network packets periodically broadcast by each node over the private cluster
network. Heartbeats inform other nodes of a single system's health, configuration, and network
connection status. When heartbeat messages are not received among the other nodes as expected,
the cluster service interprets this as node failure, and a failover begins.
Virtual Servers
Groups that contain an IP address resource and a network name resource (along with other
resources) are published to clients on the network under a unique server name. Because these
groups appear as individual servers to clients, they are called virtual servers. Users access
applications or services on a virtual server the same way they access applications or services on
a physical server. They do not need to know that they are connecting to a cluster and have no
knowledge of which node they are connected to.
Failover
Failover is the process of moving a group of resources from one node to another in the case of a
failure. For example, in a cluster where Microsoft Internet Information Server (IIS) is running on
node A and node A fails, IIS fails over to node B of the cluster.
18 Introduction

Failback
Failback is the process of returning a resource or group of resources to the node on which it was
running before it failed over. For example, when node A comes back online, IIS can fail back
from node B to node A.
Cluster Terminology 19

20