Global Instant Capacity Resource Sharing
» Table of Contents |  | | » Index | | |
| | |
| ||
| ||
Once a group has been established, Instant Capacity resources (core, cell board, memory usage rights, and temporary capacity) may be shared among all the members of the group. The sharing can occur in several ways:
During creation of the group, some members may have unused usage rights so that by simply joining the group, additional usage rights are available for use by any member of the group.
Even if there are no unused usage rights across the group, a member of the group may deactivate resources (cores, cells or memory) to make additional usage rights available for activation by any other member in the group.
Temporary capacity from all members of the group is available for use by any member of the group.
Usage rights are shared by deactivating resources on one group member, and then activating resources on another member of the group. In effect, the system on which the resources were deactivated is loaning usage rights to the activating (or borrowing) system. The activation and deactivation commands are done using the usual icapmodify commands on the individual member systems to effect this “loan” operation (also sometimes referred to as a transfer of usage rights).
Any temporary capacity available to individual members of the group is combined into a larger pool of temporary capacity that is available for consumption by any and all members of the group, as needed. Initiating usage of shared temporary capacity is the same as with individually purchased TiCAP: group members use the icapmodify -a -t command to activate shared temporary capacity. Note that this differs from the sharing of usage rights in that temporary capacity is never a “loan” to be returned; it is always depleted through its usage over time.
Example 7-4 Core Rights Sharing
In the following scenario, no member of the group mygroup has core usage rights immediately available. Group member member1 has an immediate need for more processing power. However, group member member2 can loan a core usage right by deactivating one core.
First, member2, currently with 8 active cores, will deactivate one core:
member2> icapmodify -d 1
7 cores are intended to be active and are currently active
The core usage right from member2 is now available for any member of the group, and can be used to activate an additional core on member1:
member1> icapmodify -a 1
8 cores are intended to be active and are currently active.
The output of the icapstatus command on the loaning system member2 will show that the Number of Intended Active Cores and Number of active cores have decreased by one, and the Number of inactive cores and Number of cores without usage rights have increased by one. On the borrowing system member1, the Number of Intended Active Cores and Number of active cores have increased by one, and the Number of inactive cores and Number of cores without usage rights have decreased by one.
The output of icapmanage -s on the Group Manager system will show that the total number of cores without usage rights for the group has not changed.
In systems where usage rights and temporary capacity are available, Instant Capacity tends to use usage rights before temporary capacity. In a situation where temporary capacity is being used on at least one member system, a component on another member is deactivated, and a component on a third member system needs to be activated, the usage rights made available by the deactivated component may be taken by the system using temporary capacity. In this case it may be necessary to use the “-t” option to icapmodify to activate the component using temporary capacity.
Usage rights and temporary capacity can sometimes be temporarily assigned to the Group Manager, which can cause some unexpected results. The total temporary capacity reported for the group by icapmanage -s may not equal the sum of temporary capacity reported by each member system. This is because the Group Manager will prefetch an amount of temporary capacity in anticipation of needing it for a future operation, so the temporary capacity may not be immediately assigned to a member system.
The values reported by icapstatus for borrowed and loaned usage rights are not adjusted when usage rights remain unassigned. This usually happens when usage rights are released by one member system and are not immediately used by another member system. In this case, the released usage rights remain assigned to the Group Manager. The borrowed and loaned values for the group members may not reflect the total usage rights for the group.
Example 7-5 Cell/Memory Sharing
In the following scenario, member1 of the group mygroup has an inactive cell it wants to activate, but no usage rights are available on the system. However, member2 of the group has available usage rights.
First, we can see from the output of icapstatus on member1 that no cell or memory usage rights are available:
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 1
Number of inactive cells: 1
Amount of memory without usage rights: 16.0 GB
Amount of inactive memory: 16.0 GB
Number of cores without usage rights: 8
Number of inactive cores: 8
The output of icapstatus on member2 shows that memory and cell usage rights are available:
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 1
Number of inactive cells: 2
Amount of memory without usage rights: 16.0 GB
Amount of inactive memory: 32.0 GB
Number of cores without usage rights: 8
Number of inactive cores: 8
In this situation, it is not necessary to deactivate components on member2 since the system is under-utilized and usage rights are available. The usage rights from member2 are available to member1, and the cell can be activated:
member1> parmodify -p 0 -m 2::y:
After a reboot, all of the components on member1 will be active.