Global Instant Capacity and Temporary Capacity
» Table of Contents |  | | » Index | | |
| | |
| ||
| ||
Temporary capacity can be shared across servers for better efficiency and ease of use. By pooling temporary capacity, it is immediately available to all members of a group without the need to purchase temporary capacity for each server.
Example 7-6 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
|
|
|
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.
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.
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”.
Since temporary capacity is pooled for the group, adjustments to the temporary capacity balance can be made even when it is not being consumed. For performance reasons, the Group Manager anticipates potential future use of temporary capacity and may prefetch an amount of temporary capacity from one or more member systems. Although temporary capacity will not be used on a member system unless the “-t” option was specified with the icapmodify command, an icapmodify command without the “-t” option may still result in an adjustment of the temporary capacity balance for members of the group. When this happens, the overall temporary capacity balance for the group does not change, but there may be differences in the allocation to individual member systems.