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

24
Figure 12. Initial configuration with HP GiCAP and Serviceguard
Imagine that Db has a serious failure and the partitions on it are no longer running. The packages are defined with the
AUTO_RUN option, so Serviceguard automatically fails them over to Db2 on server 2. Scripts are defined to provide
customized processing on the startup and shutdown of the package. Before the package is started on Db2 Db4 has none
of relationship with the package used between Db1 and Db2. So we should remove to mention about Db4. The startup
script contacts the OA1 to release the available core usage rights from Db1 and activate the 12 additional processor
cores on Db2.
Figures 13 and 14 shows the scripting process in two separate steps. Figure 13 shows the state after the script has
deactivate all the core usage rights from Db1. These usage rights are available for migration by the Group Manager when
a member of the GiCAP group needs a core activated.
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 5 iCAP
cores
ap1: Group Manager
A A
A A
A A
A A
Serviceguard cluster
Db1: 2 blades,
16 active cores
A A
A A
A A
A A
A A
A A
A A
A A
Db2: 2 blades,
4 active and 12 iCAP
cores
A A
A
A