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

Once the standby is defined, the active Group Manager transfers the Group Manager database to
the standby Group Manager whenever group database changes occur, and also on a regular timed
basis (using a cron job). This enables the standby Group Manager to be ready to take control of the
group in case of a Group Manager failure. For a Group Manager in standby status, only limited
icapmanage commands are allowed, such as showing status of the group. Active management of
the group is allowed only by a Group Manager with active status.
Failover to a standby Group Manager
When you need to have a standby Group Manager take control of group management, log in to the
standby system and run this “take control” command:
ap2>icapmanage -Q
This command establishes ap2 as the active Group Manager for all managed groups and group
members, limited only to the extent that ap2 can contact the member systems and the previously
active Group Manager. That is, the new Group Manager (ap2) attempts to contact the previously
active Group Manager (ap1) to put it in standby status. In the case of planned downtime, this should
be no problem as long as the “take control” command is issued before taking an active Group
Manager off line. In the case of a sudden failure of an active Group Manager, the new active Group
Manager likely cannot contact the previously active Group Manager. This has some implications for
failback, as discussed in the “Split groups and failback
” sub-section.
The new active Group Manager also attempts to contact all group members, informing them that this
system is the active Group Manager. Standard group operations can then be continued on the new
active Group Manager for all the members that are contactable. As long as the new active Group
Manager can contact one host on a group member, the new active Group Manager will become the
active manager for that member.
Failback from a standby Group Manager
In the case where a standby Group Manager took control as part of planned maintenance, control is
restored to the formerly active Group Manager through the following two commands:
ap2> icapmanage -t
ap1> icapmanage -Q
The icapmanage -t command transfers the GiCAP database from ap2 to ap1 ensuring that ap1 has
all the changes made to the GiCAP database while ap1 was not available. The icapmanage -Q
command on ap1 restores ap1 as the active Group Manager and ap2 as the standby Group Manager,
as long as both Group Managers are accessible and able to exchange information.
Inaccessible members during Group Manager status changes
If a newly active Group Manager cannot contact a group member during a failover or failback
transition, that group member will continue to believe itself managed by its current manager (the
previously active Group Manager). This may result in the member not being able to loan or borrow
usage rights or it may result in a split group, if the previously active Group Manager also could not
be contacted at the time the standby Group Manager took control of the group. For more details, see
the “Split groups and failback
” sub-section.
In the case where the previously active Group Manager successfully manages the transition to
standby status, but a member was inaccessible during this failover or failback transition, that member
will be unable to loan or borrow usage rights in the group. To recover from this situation, you
reestablish communication between the member and the newly active Group Manager by issuing the
icapmanage -Q command on the newly active Group Manager once the member is back online.
29