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

6
• Through a quorum service, for Serviceguard clusters of any size or type. Quorum services are
provided by a quorum server process running on a machine outside of the cluster. The quorum
server listens to connection requests from the Serviceguard nodes on a known port. The server
maintains a special area in memory for each cluster, and when a node obtains the cluster lock, this
area is marked so that other nodes will recognize the lock as “taken.” A single quorum server
running on either HP-UX or Linux can manage multiple HP-UX and Linux Serviceguard clusters.
Partition interactions
With this background in mind, we next need to examine to what extent the partitioning schemes
either meet or violate the independent failure assumption.
The partitioning provided by nPartitions is done at a hardware level, and each partition is isolated
from both hardware and software failures of other partitions. This provides isolation between the OS
instances running within the partitions. In this sense, nPartitions meets the assumption that the failure of
one node (partition) will not affect other nodes. However, within the Superdome infrastructure and
other servers supporting nPartitions, there exists a very small possibility of a failure that can affect all
partitions within the cabinet. So, to the extent that this infrastructure failure exists, nPartitions violates
the independent failure assumption. However, depending on the specific configuration, nPartitions
can be used within a Serviceguard cluster.
The vPars form of partitioning is implemented at a software level. While this provides greater
flexibility in dividing hardware resources between partitions, it does not provide any isolation of
hardware failures between the virtual partitions. The failure of a hardware component being used by
one vPar can bring down other vPars within the same hardware platform.
In addition to the failure case interactions, vPars exhibit a behavior that should also be considered
when including a vPars as a node in a Serviceguard cluster. Due to the nature of the
hardware/firmware sharing between vPars, it is possible for one vPars partition to induce latency in
other vPars partitions within the same nPartition or node. For example, during bootup, when the
booting partition requests the system firmware to initialize the boot disk, it is possible for other
partitions running in the same machine to become blocked until the initialization operation completes.
The effect of this type of latency is discussed in the section “Latency Considerations.”
Integrity VM is a soft partitioning and virtualization technology that allows you to run multiple virtual
machines (or “guests”) on a single physical HP Integrity server or nPartition. Like vPars, Integrity VM
provides operating system isolation with shared hardware. Multiple virtual machines hosted in a
single partition are vulnerable to a single hardware failure. To protect virtual machines from this
SPOF, run Integrity VM on multiple cluster nodes and create virtual machine packages that can fail
over from one cluster node to another. For the cluster to survive, distribute active virtual machines
across VM Hosts so at least half of them remain running after a hardware failure.
Alternatively, Serviceguard can be used to protect the applications running on guests. In this
configuration, install Serviceguard on the guest and create application packages that can fail over to
another virtual machine or to a physical server (or nPar) that is not running Integrity VM. Each
configuration provides different levels of protection:
1. Cluster in a box consists of two or more virtual machines running on the same VM Host system,
each of which is an HP-UX guest running Serviceguard. Applications are packaged on the guest
and the cluster members are virtual machines. This configuration is useful for testing but provides
no protection against SPOF.
2. Cluster across host consists of two or more VM Host systems (HP Integrity servers or nPars).
Serviceguard cluster members are guests on two or more VM Host systems. Application packages
can fail over to a guest running on a different VM Host system. This provides protection against
hardware failure. One example is to run active applications on guests on separate VM Host