Implement high-availability solutions with HP Instant Capacity - easily and effectively
27
Figure 15. Initial HP Serviceguard configuration with standby Group Manager
For this scenario, imagine that the Group Manager ap1 fails, followed by a server 1 complex or OA failure. As in the
previous examples, customized scripts are used to provide the necessary shift of resources on the startup and shutdown
of each of the Serviceguard packages.
For the Group Manager failover, the startup script associated with the standby Group Manager needs only to issue the
icapmanage -Q -n command to take control. Use of the -n option is recommended within scripts because it prohibits the
prompting for passwords that might occur if the standby manager had not previously contacted all member host
systems.
Note: This is why it is important to pre-establish SSL communication with all member hosts before any failures, because use of this option also means that
any such systems remain out of contact with the group as a result.
The member failover can be accomplished in a manner similar to that described previously in the “Failover involving
unplanned downtime: When both OA modules or the server complex go down unexpectedly” section, but with one
change; as the member does not know which Group Manager might be active, the script to do rights seizure must either
try each Group Manager in turn, or use a relocatable IP address associated with the Group Manager package to identify
the Group Manager that is running. Figure 16 shows the state after failover of both packages.
Serviceguard
cluster
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: Active 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
ap2: Standby Group Manager