HP Serviceguard Cluster Configuration for HP-UX 11i or Linux Partitioned Systems, April 2009

4
Figure 2. Sample of combined nPartitions and vPars configurations
Serviceguard design assumptions
To best understand issues related to using partitioning within the cluster, it is helpful to start with a
review of the Serviceguard design philosophy and assumption, including hardware redundancy,
cluster membership protocol, and quorum arbitrations.
Hardware redundancy
Serviceguard, like all other high-availability (HA) clustering products, uses hardware redundancy to
maintain application availability. For example, the Serviceguard configuration guidelines require
redundant networking paths between the nodes in the cluster. This requirement protects against total
loss of communication to a node if a networking interface card fails. If a card should fail, there is a
redundant card that can take over for it.
As can be readily seen, this strategy of hardware redundancy relies on an important underlying
assumption: the failure of one component is independent of the failure of other components. If the two
networking cards were somehow related, a single failure event could disable them both. This
represents a SPOF and effectively defeats the purpose of having redundant cards. It is for this reason
that the Serviceguard configuration rules do not allow both heartbeat networks on a node to travel
through multiple ports on the same multi-ported networking interface. A single networking interface
card failure would disable both heartbeat networks.
Cluster membership protocol
This same philosophy of hardware redundancy is reflected in the clustering concept. If a node in the
cluster fails, another node is available to take over applications that were active on the failed node.
Determining with certainty which nodes in the cluster are currently operational is accomplished
through a cluster membership protocol whereby the nodes exchange heartbeat messages and
maintain a cluster quorum.