HP Instant Capacity Version 10.x User Guide (5900-2063, December 2011)

amount of temporary capacity time remaining on a complex can be obtained by executing the
icapstatus command. A warning is also sent via email when the temporary capacity balance
is expected to be depleted within a certain period of time.
The icapmodify command allows you to activate a core using temporary capacity only if at least
30 minutes of temporary capacity is available for each core that is being activated.
Whenever temporary capacity is applied to a system (or if the complex is part of a GiCAP group),
extra care must be taken to avoid situations that can cause the Instant Capacity software on one
nPartition of a group member to make assumptions that all cores might be active on another
nPartition of the member. For example, when the nPartition is making boot-related configuration
changes (at EFI or BCH). If this state continues for more than 12 hours, unexpected temporary
capacity might be consumed on the complex.
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 cpt 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.
182