HP Instant Capacity Version 10.x User Guide (762794-001, March 2014)

critical group members. When a standby manager takes 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 V (or split) GiCAP group. Reachable members start accepting
commands from the standby Group manager while unreachable members continue to consider
the previous Group manager active. Control operations can be carried out on both active Group
Managers, each communicating with the members that 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 is 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 are 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.09 or higher must be installed on the Group Manager and on all member
systems to use GiCAP. The CIM Server configuration property sslClientVerificationMode must be
set to a value of “optional” and enableHttpsConnection must be set to “true” 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.
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
if there is a sufficient positive balance of temporary capacity. A negative balance always indicates
a system which is out of compliance.
A GiCAP group is in a compliant state if 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 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.
150