Managing Serviceguard A.11.20, March 2013

• Deploying applications in this environment requires careful consideration; see “Implications
for Application Deployment” (page 161).
• If a monitored_subnet (page 245) 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 cluster 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.
Implications for Application Deployment
Because the relocatable IP address will change when a package fails over to a node on another
subnet, you need to make sure of the following:
• The hostname used by the package is correctly remapped to the new relocatable IP address.
• The application that the package runs must be configured so that the clients can reconnect to
the package’s new relocatable IP address.
In the worst case (when the server where the application was running is down), the client may
continue to retry the old IP address until TCP’s tcp_timeout is reached (typically about ten
minutes), at which point it will detect the failure and reset the connection.
For more information, see the white paper Technical Considerations for Creating a Serviceguard
Cluster that Spans Multiple IP Subnets, at http://www.hp.com/go/hpux-serviceguard-docs.
Configuring a Package to Fail Over across Subnets: Example
To configure a package to fail over across subnets, you need to make some additional edits to the
package configuration file.
NOTE: This section provides an example for a modular package; for legacy packages, see
“Configuring Cross-Subnet Failover” (page 314).
Suppose that you want to configure a package, pkg1, so that it can fail over among all the nodes
in a cluster comprising NodeA, NodeB, NodeC, and NodeD.
NodeA and NodeB use subnet 15.244.65.0, which is not used by NodeC and NodeD; and
NodeC and NodeD use subnet 15.244.56.0, which is not used by NodeA and NodeB. (See
“Obtaining Cross-Subnet Information” (page 195) for sample cmquerycl output).
Configuring node_name
First you need to make sure that pkg1 will fail over to a node on another subnet only if it has to.
For example, if it is running on NodeA and needs to fail over, you want it to try NodeB, on the
same subnet, before incurring the cross-subnet overhead of failing over to NodeC or NodeD.
Assuming nodeA is pkg1’s primary node (where it normally starts), create node_name entries in
the package configuration file as follows:
node_name nodeA
node_name nodeB
node_name nodeC
node_name nodeD
Package Configuration Planning 161