Managing HP Serviceguard A.11.20.10 for Linux, December 2012

Figure 1 Typical Cluster Configuration
In the figure, node 1 (one of two SPU's) is running package A, and node 2 is running package B.
Each package has a separate group of disks associated with it, containing data needed by the
package's applications, and a copy of the data. Note that both nodes are physically connected
to disk arrays. However, only one node at a time may access the data for a given group of disks.
In the figure, node 1 is shown with exclusive access to the top two disks (solid line), and node 2
is shown as connected without access to the top disks (dotted line). Similarly, node 2 is shown with
exclusive access to the bottom two disks (solid line), and node 1 is shown as connected without
access to the bottom disks (dotted line).
Disk arrays provide redundancy in case of disk failures. In addition, a total of four data buses are
shown for the disks that are connected to node 1 and node 2. This configuration provides the
maximum redundancy and also gives optimal I/O performance, since each package is using
different buses.
Note that the network hardware is cabled to provide redundant LAN interfaces on each node.
Serviceguard uses TCP/IP network services for reliable communication among nodes in the cluster,
including the transmission of heartbeat messages, signals from each functioning node which are
central to the operation of the cluster. TCP/IP services also are used for other types of inter-node
communication. (See, “Understanding Serviceguard Software Components” (page 31) for more
information about heartbeat.)
1.1.1 Failover
Under normal conditions, a fully operating Serviceguard cluster simply monitors the health of the
cluster's components while the packages are running on individual nodes. Any host system running
in the Serviceguard cluster is called an active node. When you create the package, you specify
a primary node and one or more adoptive nodes.When a node or its network communications
fails, Serviceguard can transfer control of the package to the next available adoptive node. This
situation is shown in Figure 2 (page 21).
20 Serviceguard for Linux at a Glance