User's Manual

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 is decreased below the member's
warning period until all members of the group are within their warning period.
Example: Activation Using Pooled Temporary Capacity
In this scenario, member1 of mygroup has 2 active cores and needs to activate 6 more cores, but
only 5 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 you
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 5 additional cores are permanently activated with the available usage rights, and
only the last core is activated with TiCAP. Initially, only 30 minutes of temporary capacity are
transferred to member1, since 30 minutes of temporary capacity are transferred per core activated
with temporary capacity. Every 30 minutes the daemon determines whether temporary capacity
is depleted and acquires more from the group as needed.
Temporary Capacity and Freed Usage Rights
When a complex consumes temporary capacity, the Instant Capacity daemon periodically
decrements a complex’s temporary capacity balance. Before doing so it contacts the Group
Manager to determine whether there are core usage rights available on other group members.
If not, temporary capacity continues to be consumed. If usage rights are available anywhere in
the group, they are 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 Instant Capacity daemon
monitors temporary capacity consumption, the icapstatus command reports that temporary
capacity is being consumed when it is not. When the transfer of usage rights is completed, the
icapstatus output is updated on both systems to reflect the transfer. Because of the delay, the
changes might 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 or transferred to that system via the Group Manager.
You might 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. When a block of
temporary capacity has been consumed, the Group Manager continues to transfer group temporary
capacity to the system every 30 minutes as long as it is available. However, the icapstatus
command on the local system might 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”.
Global Instant Capacity and Temporary Capacity 115