Configure core group bridge communication between cells that contain multiple core groups

We might need to configure core group bridge communication between cells that contain multiple core groups if one of the cells contains processes that need access to the high availability manager state information of processes running in a different cell. For example, a WebSphere proxy server or an On Demand Router might need to route requests to cluster members in a different cell and that other cell contains multiple core groups.

Verify that the following conditions exist:

• The cells between which we are configuring core group bridge communication have unique names. We cannot set up a core group bridge between two cells that have the same name.

• At least one of the cells contains multiple core groups, and core group bridge communication must already exist between the core groups that reside in that cell. The access point group used to establish this communication continues to handle communication between the core groups within the same cell even after communication is established between the two cells.

To enable core group bridge communication between cells that contain multiple core groups, create an inter-cell access point group to handle communication between one of the core groups in each of the cells. This inter-cell access point group, working in conjunction with the existing access point group, allows state information from within one of the cell to be propagated to the other cell.

The following figure illustrates this topology where DefaultAccessPointGroup is the access point group that enables communication between the three core groups in cell_1, and the inter-cell access point group enables communication between the core groups in cell_1 and the core group in cell_2.

Use core group bridge custom properties to set up advanced configurations for a core group bridge.

Requirements:

• Whenever a change is made in core group bridge configuration, including the addition of a new bridge, or the removal of an existing bridge, fully shutdown, and then restart all core group bridges in the affected access point groups.

• There must be at least one running core group bridge in each core group. If we configure two bridges in each core group, a single server failure does not disrupt the bridge functionality. Also, configuring two bridges enables us to periodically cycle out one of the bridges. If all the core group bridges in a core group are shutdown, the core group state from all foreign core groups is lost.

Recommended:

• Core group bridges be configured in their own dedicated server process, and that these processes have their monitoring policy set for automatic restart.

• For each of our core groups, we set the IBM_CS_WIRE_FORMAT_VERSION core group custom property to the highest value supported on the environment.

• To conserve resources, do not create more than two core group bridge interfaces when defining a core group access point. We can use one interface for workload purposes and another interface for high availability. Ensure that these interfaces are on different nodes for high availability purposes. See frequently asked question information on core group bridges.

• We should typically specify ONLY two bridge interfaces per core group. Having at least two bridge interfaces is necessary for high availability. Having more than two bridge interfaces adds unnecessary overhead in memory and CPU.

bprac

Configure core group bridge communication between cells that contain multiple core groups

1. To specify the remote end points in the cell to which we want to establish communication from the multi-core group cell, create a peer access point, and peer ports. Within each peer access point, configure a peer port that corresponds to each bridge interface in the other cell (cell_2 in the preceding figure). Before adding a peer access point, determine the following information about the other cell:
   • Cell name
   • Core group name
   • Core group access point name
   • Host and port information corresponding to the bridge interfaces configured in the other cell. Specify a peer port for each bridge interface in the other cell.

   1. In the administrative console, click...
      Servers > Core Groups > Core group bridge settings > Access point groups > access_point_group > Peer access points > New

      access_point_group is the name of the access point group that already exists in the multi-core group cell.

   2. Configure the peer access point.

      In addition to specifying a name...

      • Specify the other cell where the peer access point resides.
      • Specify the name of the core group in the other cell to which the peer access point belongs.
      • Select Use peer ports.
      • Select the default level of access (full access) that we want this other cell to have to the multi-core group cell.

   3. Click Next, and then Finish.

   4. Save the configuration changes.

2. Create an inter-cell access point group in the multi-core group cell.

   1. In the administrative console, click...
      Servers > Core Groups > Core group bridge settings > Access point groups > New

   2. Click Next

   3. Select a core group from the Available core group access points list. Select the arrow to add the selected core group to the access point group.

      The selected core group should be the one to use to exchange proxy state information between the core groups in the two cells. Remember that a peer access point can only represent one core group in another cell. Therefore, make sure we only add one core group from the multi-core group cell to the inter-cell access point group.

   4. Click Next

   5. Select the appropriate peer access point from the Available peer access points list. Select the arrow to add the selected peer access point to the access point group.

      The selected peer access point must be the one we previously created to communicate with the other cell.

   6. Click Next> Finish.

   7. Save the configuration changes.

3. Create a peer access point, and peer ports to specify the remote end points in the multi-core group cell to which we want to establish communication from the other cell.

   Within each peer access point, configure a peer port that corresponds to each bridge interface in the multi-core group cell (cell_1 in the preceding figure). Before we add a peer access point, determine the following information about the multi-core group cell:

   • Cell name
   • Core group name
   • Core group access point name
   • Host and port information corresponding to the bridge interfaces configured in the other cell. Specify a peer port for each bridge interface in the other cell. cell.

   1. In the administrative console, click...
      Servers > Core Groups > Core group bridge settings > Access point groups > access_point_group > Peer access points > New

      access_point_group is the name of the access point group that already exists in the other cell.

   2. Configure the peer access point.

      In addition to specifying a name...

      • Specify the other cell where the peer access point resides.

      • Specify the name of the core group in the other cell to which the peer access point belongs.

      • Select Use peer ports.

      • Select the default level of access (full access) that we want the multi-core group cell to have to this other cell.

   3. Click Next, and then Finish.

   4. Save the configuration changes.

4. Create an inter-cell access point group in the other cell.

   1. In the administrative console, click...
      Servers > Core Groups > Core group bridge settings > Access point groups > New

   2. Click Next

   3. Select a core group from the Available core group access points list. Select the arrow to add the selected core group to the access point group.

      The selected core group should be the one to use to exchange proxy state information between the core groups in the two cells. Remember that a peer access point can only represent one core group in another cell. Therefore, make sure we only add one core group from the other cell to the inter-cell access point group.

   4. Click Next

   5. Select the appropriate peer access point from the Available peer access points list. Select the arrow to add the selected peer access point to the access point group.

      The selected peer access point must be the one we previously created to communicate with the other cell.

   6. Click Next> Finish.

   7. Save the configuration changes.

5. Configure bridge interfaces for our core group access point.

   Create bridge interfaces for the core group in the other cell if it is the only core group in that cell, which is the topology illustrated in the preceding figure. If there are multiple core groups in both cells, select any of the core groups in the other cell to use for inter-cell communication. If the core group we select already has bridge interfaces defined, skip this step.

   When configuring core group bridges, remember the following requirements:

   • Whenever a change is made in core group bridge configuration, including the addition of a new bridge, or the removal of an existing bridge, fully shutdown, and then restart all core group bridges in the affected access point groups.

   • There must be at least one running core group bridge in each core group. If we configure two bridges in each core group, a single server failure does not disrupt the bridge functionality. Also, configuring two bridges enables us to periodically cycle out one of the bridges. If all the core group bridges in a core group are shutdown, the core group state from all foreign core groups is lost.
   1. 
      In the administrative console, click...
      Servers > Core Groups > Core group bridge settings > Access point groups > access_point_group > Core group access points

   2. Select one of the listed core group access points. Then click Show detail > Bridge interfaces > New.

   3. Select a node, server, and transport chain for our bridge interface.

   4. Click Apply.

   5. Repeat this set of steps to add more bridge interfaces to the core group access point.

      Define two bridge interfaces for each core group access point to make your bridges highly available. When defining two core group bridge servers, if one of these two servers fails, the other server handles any pending communication, thereby preventing an interruption in the communication between the core groups. It is also recommended for the bridge interfaces of a core group to be on different nodes.

6. Optional: Configure the high availability manager protocol to establish transparent bridge failover support.

   When a core group bridge server restarts, state information, such as WLM data, and ODR or WAS proxy server routing data, is lost until the state information is recovered by a bridge in the same core group. The length of time the data is lost varies depending on the number of core groups and the amount of state data, but the length of time can be a minute or longer. During this time, ODRs and WAS proxy servers might report 503 errors, and JNDI look-ups for objects in remote core groups might fail.

   If we are running on v7.0.0.1 or later, we can avoid such outages, if we enable the transparent bridge failover protocol by setting the IBM_CS_HAM_PROTOCOL_VERSION custom property to 6.0.2.31 in each core group. When this custom property is set to 6.0.2.31, the remaining bridges recover the high availability state of the failed bridge without the data being unavailable in the local core group.

   Complete the following actions to set the IBM_CS_HAM_PROTOCOL_VERSION core group custom property to 6.0.2.31 for all of our core groups.

   1. Shut down all core group bridges in all of our core groups.

   2. Repeat the following actions for each core group in each of our cells:

      1. In the administrative console, click...
         Servers > Core Groups > Core group settings > core_group_name > Custom properties

      2. Specify IBM_CS_HAM_PROTOCOL_VERSION in the Name field, and 6.0.2.31 in the Value field.

      3. Save changes.

   3. Synchronize our changes across the topology.

   4. Restart all of the bridges in the topology.

   All of the core groups within this topology are using the 6.0.2.31 high availability manager protocol.

7. Save and synchronize changes, and restart all of the core group bridge servers in both cells to apply the changes.

What to do next

Continue configuring the high availability environment.

Related:

Core group communications using the core group bridge service

Core groups (high availability domains)

Set up a high availability environment

Create backup clusters

Core group bridge settings

Core group bridge custom properties