Implement high-availability solutions with HP Instant Capacity - easily and effectively

13
you can use a GiCAP command to extract (seize) processor core usage rights from that server and transfer those usage
rights to the Group Manager. Then, using normal activation commands on the failover server, you can use those
transferred usage rights to activate additional processor cores on the failover servers to increase capacity.
The freedom that iCAP with GiCAP provides you (no partitions need to be running to seize rights from a member) is that it
enables you to recover from more serious outages. For example, consider a GiCAP group consisting of an active server in
one location and a failover server in another location. With the Group Manager in a third location, if either of the group
members becomes unavailable due to a disaster, you can seize core usage rights from the unavailable member and
make them available to the remaining member.
The seizure of core usage rights from a fully unavailable Integrity Superdome 2 member complex is temporary. After
30 days, the usage rights are automatically restored to the member complex from which they were seized. (In the event
a system cannot reconnect to the Group Manager within the 30-day period, you can extend the expiration of the seized
usage rights. This extension is applied to the Group Manager by a codeword obtained from HP support.)
Migrating vs. seizing usage rights
Here are some basic guidelines for determining when to seize usage rights or when to simply migrate those rights.
Planned downtime and load balancing: whenever possible, migrate usage rights by deactivating cores in one partition
and then activating cores in another partition. The involved partitions may or may not be part of the same member
server. For example, if maintenance is planned such that a target partition or server is going to be unavailable for a
period of time, deactivate all but one core per partition in that target and activate the same number of cores in other
partitions, before the target is taken down for maintenance.
Unplanned downtime: when either OA modules or the server complex goes down unexpectedly, seize the usage rights
to make them available to remaining GiCAP group members.
Unplanned downtime when only one or many of the partitions go down but the OA modules are up: In this case, with
iCAP 10.05 or later and OA with complex firmware bundle 2.51.102 or later, we do not need to seize the rights or bring
down the entire complex. The rights are released soon as the partition goes down and are free to be used in other
partitions/complexes within a group as needed. During a transfer-of-control scenario, when memory is being recorded
on disk, the usage rights are not automatically released. They are released only after the partition comes to “halt” or
“down” state. HP plans to fix this issue as part of the next firmware release.
Configuration guidelines
All partitions on the servers in the group must be running HP-UX 11i v3 September 2011 or later, with iCAP version
10.05 or later, and the OA must have the complex firmware bundle 2.51.102 or later. GiCAP grouping rules determine
which servers can be put in a group (hardware-related rules).
HP recommends using a separate HP-UX system as the GiCAP Group Manager, both for recoverability and ease
of use. That is, the system should be independent of the group, but it does not need to be dedicated only to the
Group Manager software. The Group Manager system (and all member systems) must have a machine-readable serial
number, as displayed by the “getconf CS_MACHINE_SERIAL” shell command and must run HP-UX 11i v1 or later and
iCAP 10.05 or later. A management server fitting these requirements, such as the Integrity Superdome Support
Management Station (SMS), could be used. The separate server used to provide quorum service for the Serviceguard
cluster, or a Service Cluster, could also potentially be used to host the Group Manager.
Configurations where the primary node and the failover node are part of the same complex are not recommended for
mission-critical applications, because of the possibility of a single point of failure. Also, iCAP does not support the
ability to seize usage rights that have already been seized from the same complex. This means that while failover and
failback do work in this configuration, the rotating standby model should not be used. After a failover involving a
seizure of usage rights, the failover node should not become the new primary node. As soon as the original failure is
corrected and the primary is back online, failback to the primary node is recommended.
You can designate a standby Group Manager to manage the group in case the active Group Manager has a failure. For
more details, see “Recovery from a failure involving the Group Manager” and “HP Serviceguard considerations
subsections. Independent software vendor (ISV) licensing policies must be verified with your vendors. HP
recommends talking with ISVs early in any deployment process.
In an HP Integrity Virtual Machines environment, iCAP operates in the virtual machine host.