HP Instant Capacity Version 10.x User Guide (5900-1581, March 2011)

Group Manager, the standby Group Manager functions as a standby for all the groups managed
by that Group Manager.
A server complex can be a member of only one GiCAP group at a time. To participate in a different
group, it must be removed from one group before being added to the other group.
Sharing rights can never be transferred between two active Group Manager systems. As you create
new groups or add new members to existing groups, you might need to purchase and apply
additional sharing rights to the relevant active Group Manager systems. This is necessary even if
the member has been moved from another Group Manager that now has excess sharing rights.
Sharing rights can never be applied to a Group Manager with standby status. If a standby Group
Manager is requested to take control, the sharing rights of the former active Group Manager move
to it. If additional sharing rights need to be applied before failing back to the original Group
Manager, they must be purchased specifically for the new active Group Manager system (formerly
the standby Group Manager) and acquired from the portal. Once applied, the new total of sharing
rights moves to the originally active Group Manager if it is requested to retake control, although
only if the new active Group Manager is able to propagate its GiCAP database to the originally
active Group Manager.
Additional Considerations
Systems that 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, the Group Manager, and the standby Group Manager (if any), sufficient GiCAP
sharing rights, and adherence to the GiCAP grouping rules are the only constraints.
For systems with multiple network cards, you can specify the additional network paths as additional
hosts when defining member systems in a group, for enhanced connectivity. However, there might
be a significant performance penalty because the Instant Capacity software occasionally must
access all the multiple hosts in that case. You cannot specify the Group Manager and the standby
Group Manager such that they are different network paths to the same system. An OS instance
can host one and only one GiCAP database, regardless of the number of hostnames by which
that OS instance might be reachable.
WBEM version A.02.05 or higher must be installed on the Group Manager and on all member
systems in order to use Global Instant Capacity. The CIM Server configuration property
sslClientVerificationMode must be set to a value of “optional” on all GiCAP Group Managers and
on all OS instances of all member systems. (The CIM Server may need to be restarted if the property
was not previously set to this value.) For details, see cimconfig(1M). Note that communication
between the managers and members of groups is established using SSL certificates that are supplied
by the GiCAP software.
If the GiCAP Group Manager system becomes unavailable, the standby GiCAP Group Manager
can take over GiCAP group operations from the Group Manager. If both the Group Manager and
the standby Group Manager are unavailable, usage rights and temporary capacity remain as
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 cannot occur.
On a system with full usage rights, the icapd daemon does not constantly verify the system
configuration. It can take up to 12 hours for each partition of a system converted from non-iCAP
to iCAP to discover that it is now an iCAP system. During this time, icapmanage -s shows
asterisks for the new member, and the icapstatus command issued on that system shows “Runs
iCAP” as “N”. To force a faster conversion, kill the icapd daemon and wait for it to restart.
88 Global Instant Capacity