High availability groups
High availability groups are dynamically created components of a core group. They cannot be configured directly but are directly affected by static data, such as policy configurations, which are specified at the core group level.
A high availability group cannot extend beyond the boundaries of a core group. However, members of a high availability group can also be members of other high availability groups as long as all of these high availability groups are defined within the same core group.
Any WAS component, such as the transaction manager, can create a high availability group for that component to use. The component code must specify the attributes that are used to create the name of the high availability group for that component. For example, to establish a high availability group for the transaction manager:
- Code included in the transaction manager component code specifies the attribute type=WAS_TRANSACTIONS as part of the name of the high availability group associated with this component.
- The high availability manager function includes the default policy Clustered TM Policy that includes type=WAS_TRANSACTIONS as part of its match criteria.
Whenever transaction manager code creates a high availability group, the high availability manager matches the match criteria of the Clustered TM Policy to the high availability group member name. In this example, the string type=WAS_TRANSACTIONS included in the high availability group name is matched to the same string in the policy match criteria for the Clustered TM Policy. This match associates the Clustered TM Policy with the high availability group the transaction manager component creates.
After a policy is established for a high availability group, one can change some of the policy attributes, such as quorum, fail back, and preferred servers. However, you can not change the policy type. If you need to change the policy type, create a new policy and then use the match criteria to associate it with the appropriate group.
If you want to use the same match criteria, delete the old policy before defining the new policy. You cannot use the same match criteria for two different policies.
Important: If the old policy is one of the default policies that IBM provides, it is recommended that you do not delete the old policy. Instead, you should use a different match criteria for your new policy. This new match criteria should include more matches with the attributes contained in high availability group's name than the default policy uses for its match criterion. The policy with the greatest number of matches is the one that is used. Not deleting the IBM provided policy enables you to revert back to that policy if a problem occurs when you use your newly created policy.
Before changing the policy type for a high availability group fully understand how the application server processes that are contained in that high availability group are configured and how they will be affected by the policy change. You must also verify that the component that uses that particular high availability group supports the new policy type. For example, if the high availability group for the service integration bus uses a One of N policy, because it only wants one server to be active at any given point in time, and you change the policy associated with that group to All Active, the service integration bus high availability support no longer functions properly and data corruption might occur.
Creating a policy for a high availability group
Changing the policy of a high availability group
Changing the configuration of a high availability group
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.