Implement high-availability solutions with HP Instant Capacity - easily and effectively
14
Failover involving unplanned downtime: The OA modules and the complex
are up; however, one or more of the partitions have failed
Recovery from a server where the OA is still running, is the simplest and most straightforward case. In this situation,
the (iCAP) software uses normal migration of usage rights, because the software can contact the still-running OA to
commit the changes for the server. A partition that goes down releases all its committed rights to the OA. For this
partition to be brought up again, it needs a minimum of one core in the partition. For instance, manual failover from a
partial outage of nPars.
Consider the configuration shown in figure 7. The GiCAP group consists of an active Group Manager (ap1), and two
servers, each with two partitions. The primary application runs on nPartition Db1 and requires 16 active processor cores,
so Db1 is configured with usage rights for 16 cores. nPartition Db2 has been configured with 12 inactive cores. No
temporary capacity is being used in this group. Db3 on Server 1 has 12 active and 4 iCAP cores, whereas Db4 on server 2
has 8 active cores and 8 iCAP cores.
There are 24 inactive/iCAP cores (cores without usage rights) in this configuration. 24 GiCAP sharing rights are required
to create this group.
Figure 7. Initial HP GiCAP configuration (partial outage example)
Imagine that partition Db1, which runs on server 1 with 16 active cores has crashed, and the system administrator
knows it will be hours or days until the problem can be fixed. The application running in partition Db1 is critical to the
business and must continue running on server 2.
With iCAP version 10.05 or later and firmware version 2.51.102 or later, iCAP automatically releases the rights
committed to the partition Db1. These cores are no longer committed to the failed partition. So, they can be used on the
standby partition to activate the remaining cores.
Note: Though iCAP gives up all the rights from the partition, it is best practice to leave one core per partition active to ensure basic availability in case of
failback.
Db1: 2 blades,16
active cores
Server 1
A A
A A
A A
A A
A A
A A
A A
A A
A
Active core
Inactive (iCAP) core
Db3: 2 blades,
12 active and 4 iCAP
cores
A A
A A
A A
A A
A A
A A
Db2: 2 blades,
4 active and 12 iCAP
cores
Server 2
A A
A A
Db4: 2 blades,
8 active and 8 iCAP
cores
ap1: Group Manager
A A
A A
A A
A A