HP Instant Capacity Version 10.x User Guide (762794-001, March 2014)

nPartition of a group member to make assumptions that all cores might be active on another
nPartition of the member.
GiCAP
GiCAP provides HP customers the flexibility to move usage rights for Instant Capacity components
within a group of servers. It also provides pooled temporary capacity across the group. This has
several potential benefits: cost-effective high availability, more adaptable load balancing, and
more efficient and easier use of temporary capacity.
For example, in case of planned or unplanned down time, a customer can transfer usage rights
from a failed partition on one server to one or more servers in the group that provide backup
availability. This allows additional activations of iCAP components on the backup servers. Without
GiCAP, the only way to provide this failover scenario is to provision each server with an adequate
amount of temporary capacity.
A similar scenario exists for load balancing. Rather than using temporary capacity whenever a
server is overloaded (peak profiles for all workloads on a server), usage rights can be transferred
from other servers in the GiCAP group that have extra capacity. These borrowed usage rights
enable new component activations on the overloaded system.
Pooled temporary capacity for a group of servers is more efficient because all temporary capacity
is available to all servers in the GiCAP group. It is also easier to manage if temporary capacity
needs to be applied to only one member of the group and monitored across the group instead of
monitoring TiCAP for each member complex.
GiCAP groups
GiCAP is built on the concept of a server group, or GiCAP group. The group consists of a list of
server complexes that are allowed to share Instant Capacity usage rights (for cores, cell boards,
and memory) and temporary capacity. There are no constraints on the number of servers allowed
in a group, but the HP defined grouping rules specify the types of servers allowed to group together.
GiCAP Group Manager
For each group, an HP-UX system must be designated as an active GiCAP Group Manager. It is
this system that maintains information about the group, group resources, and grouping rules. The
icapmanage commands are intended to be used only on a Group Manager system to manage
one or more GiCAP groups.
The active Group Manager must be an HP-UX system running the Instant Capacity software version
9.0 or later. The system running the Group Manager does not need to have any Instant Capacity
components, nor does it need to be a partitionable system. The system must have a
machine-readable serial number, as displayed by the shell command getconf
CS_MACHINE_SERIAL. HP recommends that the Group Manager must not be on a partition that
is a member of any GiCAP group, and that it manages a single group. If run on a partitionable
system, changing the configuration of the partitions may result in the GiCAP Manager becoming
inoperative.
Standby GiCAP Group Manager
The active GiCAP Group Manager can designate a standby Group Manager. This standby Group
Manager can take control of GiCAP group management from the active Group Manager using
the command icapmanage -Q. This allows GiCAP group operations to continue if the GiCAP
Group Manager is unable to function.
Note that the requirements and recommendations defined for the Group Manager also apply to
the standby Group Manager; it is a Group Manager with standby status. The Group Manager in
charge of the group has active status. If the standby Group Manager takes control, the intention
is that its status becomes active and the former Group Manager's status becomes standby. For
more information, see “Group manager failover considerations”.
196