Implement high-availability solutions with HP Instant Capacity - easily and effectively

34
Scripts for Group Manager failover
These scripts pertain to the Group Manager failover portion of theRecovery from a failure involving the
Group Manager” subsection. For Group Manager failover from an active Group Manager ap1 to a standby Group Manager
ap2, the package definition specifies “yes” for AUTO_RUN and “manual” or “automatic” for failback_policy. It also
indicates that the package should always start on ap1 before ap2, if possible. For package startup, a subroutine to
handle failover might look like the following:
gm_start {
#! /usr/bin/sh
PATH=$PATH:/usr/sbin
HOSTNAME=`/usr/bin/hostname`
# Take control of the group when started
echo Taking control of the GiCAP Group on $HOSTNAME >&2
/usr/sbin/icapmanage -Q -n
return 0
}
For package shutdown, the following subroutine 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.
gm_stop{
#! /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 theRecovery from a failure involving the Group Manager
subsection. 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, as 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 startup and shutdown scripts. The
startup 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 vPars 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.