HP Instant Capacity Version 10.x User Guide (5900-2170, January 2012)

extra capacity is needed before you purchase either an RTU codeword, a temporary capacity
codeword, or setup a GiCAPgroup.
TiCAP can be added to the complex by applying a temporary capacity codeword (available from
the HP Utility Pricing Solutions portal) using the icapmodify command. Information about the
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.
Instant Capacity cell board
Instant Capacity Cell Board offers a way to have additional (inactive) cell board capacity for your
system. These Instant Capacity cell boards, which contain memory and cores, can be activated
after a cell RTU codeword is obtained from the HP Utility Pricing Solutions portal and is applied
to the complex using the icapmodify command. To activate a cell, you must have usage rights
for all memory attached to the cell and at least one core.
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 provides 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
133