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

20
HP TiCAP and rights seizure
In the previous examples, no TiCAP 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. iCAP 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 on OA (on other members in the group) could 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 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 stop consuming TiCAP cores by deactivating iCAP 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 is used. If usage rights become available, by
the completion of the seizure operation, cores activated using temporary capacity 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 10.05 or later, (iCAP) 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 Group Manager be able to establish Secure Sockets
Layer (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 works even if some group member hosts
are inaccessible. Inaccessible hosts are listed in the command output, and you should reissue the command when
those systems are online again. This establishes communication between the standby Group Manager and the
remaining hosts.
After 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.