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

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.
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 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
146