Cost-Effective High-Availability Solutions with HP Instant Capacity on HP-UX

For package shutdown, the following script works well for automatic failback. In this case it will be
run on the failover node before the package starts on the original primary node; it will ensure that
interim database changes are transferred from the failover node to the failback node.
# cat gm_stop.sh
#! /usr/bin/sh
PATH=$PATH:/usr/sbin
HOSTNAME=`/usr/bin/hostname`
# Ensure that any standby/failback database is updated before exiting
# precautionary for most shutdowns but necessary for failback
echo Taking group control on $HOSTNAME and updating database >&2
/usr/sbin/icapmanage -Q -n
return 0
Scripts for member failover when there is a standby Group Manger
These scripts pertain to the Member Failover portion of the “Example: Automated (Serviceguard) Partial
outage member failover and Group Manager failover
” sub-section. The scripts show additional
techniques to consider, but most importantly, they accommodate the possibility of Group Manager
failover as well. Package definitions and script placement are similar to the previous examples.
The technique used to accommodate Group Manager failover is the use of a relocatable IP address for
the Group Manager and standby Group Manager. In this case, gmpkg02.xxx.hp.com is the
relocatable IP address defined as part of the package associated with the Group Manager and
provides failover between ap1 and ap2. Using this relocatable address means that the scripts do not
have to know which Group Manager is active. However, note that during a simultaneous Group
Manager failover, the relocatable address might not be available for a period of time, and to
accommodate this the script should include some error checking or retry logic in the case of an error on
the remote command (the remsh command in this example). Or, the script can simply try each Group
Manager successively, since only the active Group Manager will allow a rights seizure operation.
The scripts define both simple host names and fully qualified host names, to show what needs to be
done in a case where the hostnames are not in the same domain.
These scripts exhibit an additional technique of using icapmodify -s in both the start-up and
shutdown scripts. The start-up script sets a value for the number of cores needed for the package to
run, and the shutdown script sets a (lower) value when the package is not running. This method is a
better choice for virtual partitions or whenever manual activations may be interspersed with the script
operation. The -s option sets a known value and does not depend on a particular starting value.
#cat gicap_start.sh
PATH=$PATH:/usr/sbin
HOSTNAME=`/usr/bin/hostname`
GM=gmpkg02.xxx.hp.com;
# The number of cores needed to run the package
NUM=8
case $HOSTNAME in
db1) OTHER_HOST=db2.bbb.hp.com;
OTHER=db2;;
db2) OTHER_HOST=db1.aaa.hp.com;
OTHER=db1;;
esac
43