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

The restore operation (icapmanage -z) automatically returns the seized usage rights to the nPartition
containing the specified host. In this example, the restore operation can designate either vp1 or vp2.
Temporary capacity and rights seizure
In the previous examples, no temporary capacity was being used. If TiCAP is in use during a failover
sequence, the activation step on the failover node may need to specify the use of TiCAP. The Instant
Capacity code is designed to stop using temporary capacity and instead take advantage of usage
rights if any become available. After the rights have been seized and before the activation on the
failover node, there is a window of time where the iCAP daemons (on other partitions in the group)
could wake up and start using the seized usage rights in order to stop using TiCAP. If that happens,
the seized usage rights are no longer “available” for the failover activation.
By specifying the use of TiCAP on failover activation, you guarantee that the core activations needed
for failover will occur. The total TiCAP consumption across the group remains the same, even though
the TiCAP may be consumed on the failover server instead of the original TiCAP-consuming server.
If for some management reason it is important to keep the TiCAP usage to a particular server, the
administrator could choose to deactivate TiCAP-consuming cores manually before doing the failover
activations, and then reactivate the TiCAP usage after the failover activations.
For similar reasons, it may be important to make sure other activations are not occurring
simultaneously during a failover sequence.
Note that specifying the use of TiCAP also allows activation of the cores before the seizure operation
has completed and it does not necessarily imply that additional temporary capacity will be used. If
usage rights become available, by the completion of the seizure operation, cores activated using
temporary capacity will use the newly available usage rights instead.
Recovery from a failure involving the Group Manager
The ability to shift resources within a group depends on the ability to access the Group Manager.
What if the Group Manager fails or is temporarily inaccessible (perhaps due to planned
maintenance)? None of the GiCAP examples previously presented would work if the Group Manager
was down.
Creating a standby Group Manager
Starting with version 9.0, Instant Capacity includes the ability to create a standby Group Manager to
be available for use as an active Group Manager when the currently active Group Manager is
unavailable. The system requirements for a standby Group Manager are exactly the same as
described previously for the active Group Manager.
To be effective, the standby Group Manager must be defined before any failure or planned downtime
on the active Group Manager. To create a standby Group Manager on a host named ap2 in this
example, log in to the active Group Manager (named ap1) and run the following command:
ap1>icapmanage -a -S ap2
While not required, it is recommended that this command be issued when all host systems of all
members of all managed groups are accessible. It is important that the standby Manager be able to
establish SSL communication with each of the member hosts before any failure requiring the standby
Group Manager to take control of the group. However, defining a standby Group Manager will work
even if some group member hosts are inaccessible. Inaccessible hosts will be listed in the command
output and you should reissue the command when those systems are online again. This will establish
communication between the standby Group Manager and the remaining hosts.
28