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

However, if Server 1 reconnects to the GiCAP group sometime before the end of the 10-day period,
the rights seizure can be committed on Server 1 just as if the rights seizure had been a deactivation of
the cores. During the reboot of Server 1, the Instant Capacity software adjusts the usage rights on
Server 1 to show that usage rights have been migrated from those partitions. Server 1 will boot with
the minimum number of cores, equal to the sum of active cells assigned to all partitions. In the
example, db1 would boot with two active cores and db3 would boot with two active cores after
Server 1 reconnected to the group.
As before, failback to Server 1 can be accomplished simply by deactivating cores on Server 2 and
activating cores on Server 1 (the normal method of usage rights migration within a GiCAP group):
db2> icapmodify -d 6
db1> icapmodify -a 6
db4> icapmodify -d 2
db3> icapmodify -a 4
To return db3 to its original state, we activated four cores, even though only two cores were activated
on the failover partition db4. We assumed the two seized usage rights that were not deployed to the
failover partition db4 remained unused in the group; otherwise, the last activation might fail. (Or
additional deactivations would be necessary.)
Alternatively, you can deactivate cores on Server 2 and then use the restore command
(icapmanage -z) on the Group Manager system, before rebooting Server 1:
db2> icapmodify -d 6
db4> icapmodify -d 2
ap1> icapmanage -z db1
ap1> icapmanage -z db3
In this case, no activations are necessary on db1 or db3 because the restore ensures that the Intended
Active is restored to its previous value and the boot process will activate cores based on the Intended
Active value. The restore will automatically restore all seized usage rights. In this example, the restore
will return all four seized usage rights to db3. Again, this is only possible if the extra two usage rights
had either remained unused, or were otherwise deactivated before the restore.
Use the restore method if you want to restore usage rights before rebooting the failed partitions, or
when you do not want to specify the number of seized rights to restore. (The restore command is
rejected if there are not enough usage rights available for the restore.)
Recovery from a failure involving virtual partitions
While rights seizure operations can be performed in a virtual partition environment, the rights seizure
always operates on, and affects, the entire nPartition. This means:
• Rights seizure can only be performed if all the virtual partitions for an nPartition are down.
• For a given nPartition, you can specify any of the virtual partition host names as the target of a
rights seizure operation or as the target of a usage rights restore operation.
• Because rights seizure leaves only a minimum of core usage rights with the nPartition, it is likely that
the remaining number of core usage rights is not sufficient to satisfy the number of cores assigned to
each virtual partition in the nPartition. This means that the virtual partitions likely cannot be booted
(due to noncompliance) once the original failure is corrected. To avoid this problem, usage rights
must be restored before rebooting the failed virtual partitions.
23