High availability group policy selection process

Every high availability group has a unique group name that consists of a set of name-value pairs. Every policy definition contains an attribute called match criteria that is also a set of name-value pairs. To determine the policy for a high availability group, the group name is compared to the match criteria of all the associated core group polices. The policy with the strongest match to the group name is assigned to the high availability group:

This topic references one or more of the application server log files. As a recommended alternative, we can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

When selecting a policy for a high availability group, the high availability manager:

1. Finds the set of policies that are eligible to govern a high availability group. For a policy to be eligible, all name-value pairs in the match criteria of an eligible policy must be contained in the name of the high availability group.

2. Selects the policy that has the most name-value pair matches from the list of eligible policies, and uses that policy to govern the high availability group.

Any component can create a high availability group for that component to use. However, the component code must specify the name-value pairs used for the high availability group name. The product administrator can control the name-value pairs that make up a policy match criteria, and thereby control which policy governs a particular high availability group.

The product includes a couple of predefined policies. The following examples demonstrate the matching mechanism used for these policies.

Clustered TM Policy

The transaction manager component uses the policy Clustered TM Policy when the component is configured for high availability. The following description illustrates why, under these conditions, this policy is selected for the transaction manager high availability group:

• A cluster member process, such as ServerA, is started.

• The transaction manager component code joins a high availability manager to the high availability group named:
  GN_PS=testCell\testNode\ServerA,IBM_hc=MyCluster,type=WAS_TRANSACTIONS

• ServerA is defined as a member of the DefaultCoreGroup core group for which the following policies are defined:

  • Clustered TM Policy, which has the match criteria type=WAS_TRANSACTIONS.

  • Default SIBus Policy, which has the match criteria type=WSAF_SIB.

• The high availability manager compares the group name to the match criteria for the two available policies. The high availability manager eliminates the Default SIBus Policy because the match criteria is not a proper subset of the high availability group name. The high availability manager determines that Clustered TM Policy is the closest match because:

  1. The match criteria for that policy includes the name-value pair type=WAS_TRANSACTIONS, which is also specified in the high availability group name. Therefore, the match criteria is a proper subset of the high availability group name.

  2. The match criteria for that policy more matches (one) than the match criteria for Default SIBus Policy, which is eliminated because it does not have any matches.

Administrator TM Policy

This example builds on the previous example and demonstrates how an administrator can define a new policy to govern the transaction manager high availability group. In this example the same high availability group name and default policies described in the previous example are used. However, in this example, the administrator creates a new policy in the DefaultCoreGroup configuration called the Administrator TM Policy. For the high availability manager to select this new policy, the policy must be eligible and contain more matches than any other policy.

The following description illustrates why, under these conditions, the policy Administrator TM Policy is selected for the transaction manager high availability group:

• The cluster member process ServerA is started.

• The transaction manager component code joins a high availability manager to the high availability group named:
  GN_PS=testCell\testNode\ServerA,IBM_hc=MyCluster,type=WAS_TRANSACTIONS

• ServerA is defined as a member of the DefaultCoreGroup core group, for which the following policies are defined:

  • Clustered TM Policy, which has the match criteria type=WAS_TRANSACTIONS.

  • Default SIBus Policy, which has the match criteria type=WSAF_SIB.

  • Administrator TM Policy, which has the match criteria IBM_hc=MyCluster,type=WAS_TRANSACTIONS.

• The high availability manager compares the group name to the match criteria for the available policies. The high availability manager eliminates the Default SIBus Policy because the match criteria is not a proper subset of the high availability group name. It determines that Clustered TM Policy and Administrator TM Policy are both eligible policies, because their match criteria are proper subsets of the high availability group name:

  • Clustered TM Policy contains the name-value pair type=WAS_TRANSACTIONS, which is also specified in the high availability group name.

  • Administrator TM Policy contains the name-value pairs IBM_hc=MyCluster and type=WAS_TRANSACTIONS, which are both specified in the high availability group name.

  Because Administrator TM Policy has two matching pairs, IBM_hc=MyCluster and type=WAS_TRANSACTIONS, and Clustered TM Policy has only one matching pair, type=WAS_TRANSACTIONS, the high availability manager associates Administrator TM Policy with the transaction manager high availability group.

Ambiguous Matches

Do not configure identical match criteria for multiple policies in the same core group. Configuring identical match criteria causes an ambiguous match to the associated high availability group. Because a high availability group can only be associated with one policy, if the previously described matching mechanism does not result in a single policy match, the high availability manager puts the high availability group in error state, and does not make any of the group members active. Depending on the nature of the problem, the high availability manager might write one of the following error messages to the SystemOut.log file:

HMGR0301W: No policy was located for the group named {0}
HMGR0302W: Multiple policies match the group named {0}, Matching Policies are {1}

We can use the console to view the policies associated with a high availability group and the current state of members of that group.

Related concepts

High availability groups