HP Instant Capacity User's Guide for Versions 8.x

Global Instant Capacity and Temporary Capacity
Temporary capacity can be shared across servers for better efficiency and ease of use. Temporary
capacity within a GiCAP group is always available to all members of a group without the need
to purchase temporary capacity for each server. You can exercise some control over how “willing”
each GiCAP member system is to share temporary capacity by setting its “temporary capacity
warning period”. No member's temporary capacity balance will be decreased below the member's
warning period until all members of the group are within their warning period.
Example 7-8 Activation Using Pooled Temporary Capacity
In the following scenario, member1 of mygroup has two active cores and needs to activate six
more cores, but only five usage rights are available in the group. There is no temporary capacity
available on member1. Other members of mygroup have a sufficient amount of temporary
capacity, so we can activate the cores using temporary capacity:
member1> icapmodify -a 6 -t
8 cores are intended to be active and are currently active.
Number of cores using temporary capacity: 1
Projected temporary capacity expiration: Less than 30 minutes
Notice that five additional cores are permanently activated with the available usage rights, and
only the last core is activated with TiCAP. Initially only 30 minutes of TiCAP are transferred to
member1, since 30 minutes of TiCAP are transferred per core activated with TiCAP. Every 30
minutes the daemon checks if TiCAP is depleted and will acquire more from the group as needed.
Temporary Capacity and Freed Usage Rights
When a complex is consuming temporary capacity, the iCAP daemon periodically decrements
a complex’s temporary capacity balance. Before doing so it will contact the Group Manager to
determine if there are available core usage rights on other group members. If no such usage
rights are available, temporary capacity will continue to be consumed. If usage rights are available
anywhere in the group, they will be transferred to the complex using temporary capacity in order
to stop temporary capacity consumption on that complex.
Between the time the core usage rights are made available and the iCAP daemon checks for
temporary capacity consumption, icapstatus will report that temporary capacity is being
consumed when it is not. When the transfer of usage rights is completed, the icapstatus output
will be updated on both systems to reflect the transfer. Due to the delay, the changes may appear
to be unrelated to a user-initiated operation, but they are due to the previously initiated
deactivation that freed up core usage rights.
Temporary Capacity and Status Reporting
The temporary capacity balance reported by icapstatus on a group member reflects only the
temporary capacity that has been applied to, or transferred to that system via the Group Manager.
You may still receive temporary capacity expiration warning messages even though more
temporary capacity is available in the group.
Temporary capacity is transferred to group members in 30-minute blocks. Once a block of
temporary capacity has been consumed, the Group Manager will continue to transfer group
temporary capacity to the system every 30 minutes as long as it is available. However, the local
icapstatus on the system may report temporary capacity as expired even though it is still
being used to activate cores, as shown in the icapstatus listing of “Number of cores using
temporary capacity”.
110 Global Instant Capacity