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

active Group Manager. For more details, see the “Group Manager Failover Considerations”
section.
Group Manager Failover Considerations
If the active Group Manager system becomes unavailable, the standby Group Manager can take
over GiCAP group operations from the Group Manager. If both the active Group Manager and
the standby Group Manager are unavailable, or if the active Group Manager fails and the
icapmanage -Q command was not issued to make the standby Group Manager the active Group
Manager, 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 and temporary capacity between complexes cannot occur.
An administrator can have a standby Group Manager take control at any time using the
icapmanage -Q command. While this can be done routinely, for example to allow shutting down
a functioning active Group Manager for maintenance, normally this command is issued either
when the active Group Manager has failed, or when a network outage has made it unable to
communicate with critical group members. When a standby manager is told to take control, it
attempts to update all members and the current active Group Manager so that group operations
can proceed smoothly.
However, in the case of a failure, it is possible that the icapmanage -Q command is unable to
contact the active Group Manager and some members of the groups that it now manages. When
this happens, the previously active Group Manager remains active, unaware of the change of
control. This is referred to as a “bifurcated” (or “split”) GiCAP group. Members that were reachable
by the standby Group Manager when it took control cannot accept commands from the old active
Group Manager; but unreachable members continue to consider it active. Control operations can
be carried out on both active Group Managers, each communicating with the members that it (and
only it) can reach. Groups and members can be added or removed on both (subject to the set of
members each can command), and sharing rights can be added on both. In some cases this can
be valuable; for example, when two data centers each remain functional but some intervening
network link has been broken. Each isolated set of systems can proceed with independent disaster
recovery operations within their group subset.
At some point, communication is restored and the split groups must be rejoined. This is accomplished
through issuing a new icapmanage -Q command. It can be executed on either active Group
Manager to confirm that Group Manager as the active Group Manager and demote the other to
standby status. Be aware that doing this loses all database changes made on the demoted Group
Manager during the time that the group was split. There is no method to merge the two databases,
and in particular any new sharing rights applied to the Group Manager designated now as standby
are lost.
Additional GiCAP Considerations
Systems that have no 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. The only constraints are
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.
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
123