Cost-Effective High-Availability Solutions with HP Instant Capacity on HP-UX

Migrating versus 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 cell in that target and activate the
same number of cores in other partitions, before the target is taken down for maintenance.
• Unplanned downtime: When an nPartition or server goes down unexpectedly, seize the usage
rights to make them available to remaining GiCAP group members.
Configuration guidelines
• All partitions on the servers in the group must be running HP-UX 11i v1 or later, with iCAP 8.01.01
or later. The partitions must have iCAP 8.02.01 or later installed if you want to seize usage rights
from members with no partitions accessible. 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 8.01.01 or later. (Use iCAP 8.02.01 or later to seize usage rights from members with no
partitions accessible.) A management server fitting these requirements, such as the 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, Instant Capacity 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.
• For iCAP versions earlier than V9, the Group Manager cannot be managed as part of its own
Serviceguard node cluster. The sharing rights are associated with that system and cannot be
transferred to another system if the Group Manager has a failure. Any usage rights or temporary
capacity that has already been transferred between members of the group before a Group
Manager has a failure are not affected.
• For iCAP versions V9 and later, 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” sub-sections.
• 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 VM Host.
15