Managing Serviceguard Sixteenth Edition, March 2009

to try NodeB, on the same subnet, before incurring the cross-subnet overhead of failing
over to NodeC or NodeD.
NOTE: If you are using a site-aware disaster-tolerant cluster, which requires
additional software, you can use the SITE to accomplish this. See the description of
that parameter under “Cluster Configuration Parameters ” (page 138).
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
Configuring monitored_subnet_access
In order to monitor subnet 15.244.65.0 or 15.244.56.0, you would configure
monitored_subnet and monitored_subnet_access in pkg1’s package configuration file as
follows:
monitored_subnet 15.244.65.0
monitored_subnet_access PARTIAL
monitored_subnet 15.244.56.0
monitored_subnet_access PARTIAL
NOTE: Configuring monitored_subnet_access as FULL (or not configuring
monitored_subnet_access) for either of these subnets will cause the package configuration
to fail, because neither subnet is available on all the nodes.
Creating Subnet-Specific Package Control Scripts
Now you need to create control scripts to run the package on the four nodes.
IMPORTANT: In a cross-subnet configuration, you cannot share a single package
control script among nodes on different subnets if you are using relocatable IP addresses.
In this case you will need to create a separate control script to be used by the nodes on
each subnet.
In our example, you would create two copies of pkg1’s package control script, add
entries to customize it for subnet 15.244.65.0 or 15.244.56.0, and copy one of
the resulting scripts to each node, as follows.
348 Cluster and Package Maintenance