Implement high-availability solutions with HP Instant Capacity - easily and effectively
12
Figure 6. HP GiCAP group
Note that migration of cores in this situation is exactly analogous to the previously described capability where iCAP
resources are migrated from one partition to another. The migration is achieved through a deactivation/activation
sequence. With GiCAP, the migration scope is extended from the partition to the group. For example, by deactivating
cores in the test partition on server 1, usage rights are freed and available to any other partition of any member in the
group for potential activation of cores and blades. After the group is created, the normal iCAP commands for activation
and deactivation are used to migrate usage rights from one group member to another.
Using HP GiCAP to recover from failures (seizing core usage rights)
With GiCAP, you have another tool for providing cost-effective, high-availability solutions: The ability to “seize” usage
rights from a complex that is down.
In the simplest high-availability solution, you create a group of servers that includes two types of members: 1) servers
to run your primary processing tasks, and 2) servers that provide failover processing (active/standby model). Both types
of servers can contain iCAP components for the most economical solution. When a failure occurs on the active servers,
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
Test2: 2 blades, 8
active and 8 iCAP
cores
A A
A A
A A
A A
Db2: 2 blades, 4
active and 12 iCAP
cores
Server 2
A A
A A
Reports: 1 blade, 4
active and 4 iCAP
cores
A A
A A
Inactive (iCAP) blade
ap1: Group Manager