Managing HP Serviceguard A.11.20.20 for Linux, May 2013

You should not use the wildcard (*) for node_name in the package configuration file, as this
could allow the package to fail over across subnets when a node on the same subnet is eligible;
failing over across subnets can take longer than failing over on the same subnet. List the nodes
in order of preference instead of using the wildcard.
You should configure IP monitoring for each subnet; see “Monitoring LAN Interfaces and
Detecting Failure: IP Level” (page 66).
2.2.3.2 Restrictions
The following restrictions apply:
All nodes in the cluster must belong to the same network domain (that is, the domain portion
of the fully-qualified domain name must be the same.)
The nodes must be fully connected at the IP level.
A minimum of two heartbeat paths must be configured for each cluster node.
There must be less than 200 milliseconds of latency in the heartbeat network.
Each heartbeat subnet on each node must be physically routed separately to the heartbeat
subnet on another node; that is, each heartbeat path must be physically separate:
The heartbeats must be statically routed; static route entries must be configured on each
node to route the heartbeats through different paths.
Failure of a single router must not affect both heartbeats at the same time.
IPv6 heartbeat subnets are not supported in a cross-subnet configuration.
IPv6–only and mixed modes are not supported in a cross-subnet configuration. For more
information about these modes, see About Hostname Address Families: IPv4-Only, IPv6-Only,
and Mixed Mode” (page 88).
Deploying applications in this environment requires careful consideration; see “Implications
for Application Deployment” (page 131).
cmrunnode will fail if the “hostname LAN” is down on the node in question. (“Hostname
LAN” refers to the public LAN on which the IP address that the node’s hostname resolves to
is configured.)
If a monitored_subnet is configured for PARTIAL monitored_subnet_access in a
package’s configuration file, it must be configured on at least one of the nodes on the
node_name list for that package. Conversely, if all of the subnets that are being monitored
for this package are configured for PARTIAL access, each node on the node_name list must
have at least one of these subnets configured.
As in other configurations, a package will not start on a node unless the subnets configured
on that node, and specified in the package configuration file as monitored subnets, are
up.
NOTE: See also the Rules and Restrictions (page 26) that apply to all cluster networking
configurations.
2.2.3.3 For More Information
For more information on the details of configuring the cluster and packages in a cross-subnet
context, see About Cross-Subnet Failover” (page 130), “Obtaining Cross-Subnet Information
(page 156), and (for legacy packages only) “Configuring Cross-Subnet Failover” (page 239).
See also the white paper Technical Considerations for Creating a Serviceguard Cluster that Spans
Multiple IP Subnets, which you can find at the address below. This paper discusses and illustrates
supported configurations, and also potential mis-configurations.
28 Understanding Hardware Configurations for Serviceguard for Linux