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

26
Next, the script activates the additional cores on Db2, and the packages start up on Db2 with all cores active. Figure 14
shows this failover state.
Figure 14. HP GiCAP and Serviceguard failover completed
The package can be configured to fail back automatically to Db1 when it is available, or the cmhaltpkg/cmrunpkg
commands can be used to provide the failback manually. The customized scripts should be written generically to work
properly with these operations. Sample scripts for this example are shown in the “Scripts for implementing failover
with Serviceguard” subsection. The scripts provide the failover capability but assume that failback is done manually
using the cmhaltpkg/cmrunpkg commands as needed. They also assume that the failing partition is powered down
manually as needed. For related considerations, especially with respect to vPars, see the “Additional HP Serviceguard
scripting considerations” subsection.
Note that in this GiCAP high-availability scenario, there might be no need to do failback because the systems are
symmetrical. This is unlike the TiCAP HA scenario, where failback is more compelling to avoid continued depletion of the
TiCAP balance. However, if Db1 is going to be offline for more than twelve hours, the iCAP software on Db3 assumes that
all cores might become active on Db1 (it might be running another OS without iCAP software). For more detail, see the
“Recovery from a failure involving virtual partitions” subsection.
Automated (Serviceguard) complete outage member failover and group
manager failover
This configuration is similar to the previous example (figure 14), except that the entire complex fails and for the addition
of a standby Group Manager and the additional Serviceguard cluster and package that includes the active and standby
Group Managers. Note that this example shows two separate clusters, but the group manager could be contained in the
same cluster and managed by another package.
Server 1
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
Server 2
Db4: 2 blades, 8
active and 8 iCAP
cores
ap1: Group Manager
A A
A A
A A
A A
Serviceguard
cluster
Db1: 2 blades,
0 active core
Db2: 2 blades,
16 active cores
A A
A
A
A
A
A A
A A
A A
A A
A A