HP Instant Capacity (iCAP) manual Global Instant Capacity and Temporary Capacity

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