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

Additional GiCAP Considerations

Systems which do not have any Instant Capacity components can be part of a GiCAP group.

Deactivating resources on these systems allows them to loan usage rights to other members in

the group.

Members of a GiCAP group do not have to be located near each other. IP connectivity between

the members and the Group Manager, sufficient GiCAP Sharing Rights, and adherence to the

GiCAP grouping rules are the only constraints.

The GiCAP software uses the HP-UX Secure Shell product to provide secure communication

between the Group Manager and the group members. If SSH is installed after Instant Capacity,

a provided script (/etc/opt/iCAP/GiCAP_keygen) must be invoked in order to configure

secure communication.

It is recommended that the IP address of the Group Manager not be a dynamic address. The

member systems of a GiCAP group store the IP address of the Group Manager and therefore

will lose communication with the Group Manager if the IP address changes.

If the GiCAP Group Manager system becomes unavailable, usage rights and temporary capacity

remain as per allocated to each group member. Within a server complex, the usage rights can be

deployed to other partitions, but movement of usage rights between complexes is unavailable

when the Group Manager is unavailable.

Compliance

In general, a complex is in a compliant state when the number of active components of a given

type does not exceed the number of usage rights associated with the type of component. The one

exception is that the number of active cores is allowed to exceed the number of core usage rights

as long as there is a sufficient positive balance of temporary capacity. Also, even if temporary

capacity has never been purchased for the system, the temporary capacity balance is used to

track any such non-compliance since the balance continues to be decremented while the system

is out of compliance. If TiCAP has never been purchased for a system, the temporary capacity

balance starts out as 0 and is decremented whenever the system goes out of compliance.

A GiCAP group is in a compliant state as long as all the members are in a compliant state, all

the members of the group continue to have compatible hardware as determined by the hardware

grouping rules, and as long as the number of Sharing Rights installed on the GiCAP manager is

equal or greater than the total number of cores without usage rights on complexes managed by

the Group Manager.