In a HA DPF environment with the roving HA feature enabled, it
is possible that the roving HA feature does not function as
expected. Take for example, a three host environment with two
Db2 partitions, where partition 0 is active on hostA and
partition 1 is active on hostB and where hostC is the standby
location for both partitions. In this case, the resource model
for partitions 0 and 1 would looks as follows in the lssam
output:
Online IBM.ResourceGroup:db2_db2inst1_0-rg Nominal=Online
|- Online IBM.Application:db2_db2inst1_0-rs
|- Online
IBM.Application:db2_db2inst1_0-rs:hostA
'- Offline
IBM.Application:db2_db2inst1_0-rs:hostC
Online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
|- Online IBM.Application:db2_db2inst1_1-rs
|- Online
IBM.Application:db2_db2inst1_1-rs:hostB
'- Offline
IBM.Application:db2_db2inst1_1-rs:hostC
If the roving HA feature is enabled in this environment, then it
is expected that the resource model is dynamically updated to
look as follows after hostB encounters a failure causing
partition 1 to failover to hostC:
Online IBM.ResourceGroup:db2_db2inst1_0-rg Nominal=Online
|- Online IBM.Application:db2_db2inst1_0-rs
|- Online
IBM.Application:db2_db2inst1_0-rs:hostA
'- Offline
IBM.Application:db2_db2inst1_0-rs:hostB
Online IBM.ResourceGroup:db2_db2inst1_1-rg Nominal=Online
|- Online IBM.Application:db2_db2inst1_1-rs
|- Offline
IBM.Application:db2_db2inst1_1-rs:hostB
'- Online
IBM.Application:db2_db2inst1_1-rs:hostC
As you can see in the above lssam output, partition 0 is still
running on hostA, but hostB is now its designated standby,
whereas partition 1 is now running on hostC (its new active
node) and hostB is now its standby location.
The roving HA feature makes it so that there is always a single
standby location for all active partitions in the cluster. If
the roving HA feature enabled, and this dynamic updating of the
resource model is not occurring, it may be due to this APAR. |
