Configure core group bridge communication between cells containing multiple core groups

Configure core group bridge communication between cells containing multiple core groups

We might need to configure core group bridge communication between cells containing multiple core groups if one of the cells contains processes that need access to the high availability manager state information of processes that are running in a different cell. For example, a WAS 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 containing 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.

We can use core group bridge custom properties to set up advanced configurations for a core group bridge.
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, you must fully shut down, 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 you to periodically cycle out one of the bridges. If all the core group bridges in a core group are shut down, the core group state from all foreign core groups is lost.
gotcha
Best practice: It is also recommended that:

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 the core groups, set the IBM_CS_WIRE_FORMAT_VERSION core group custom property to the highest value that is supported on the environment.

To conserve resources, do not create more than two core group bridge interfaces when you define 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. For more information, see the frequently asked question information on core group bridges.

You 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
Complete the following procedure to configure core group bridge communication between cells containing multiple core groups.

Create a peer access point, and peer ports to specify the remote end points in the cell to which to establish communication from the multi-core group cell.
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 we add 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. The host and port correspond to the bridge interfaces configured in the other cell. Specify a peer port for each bridge interface that is in the other cell.

In the 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.

Configure the peer access point.
In addition to specifying a name for the peer access point, you must complete the following actions:

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) we want this other cell to have to the multi-core group cell.

Click Next, and then Finish.

Save the configuration changes.

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

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

Click Next

Select a core group from the Available core group access points list, and then click 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 you only add one core group from the multi-core group cell to the inter-cell access point group.

Click Next

Select the appropriate peer access point from theAvailable peer access points list, and then click the arrow to add the selected peer access point to the access point group.
The selected peer access point must be the one you previously created to communicate with the other cell.

Click Next, and then click Finish.

Save the configuration changes.

Create a peer access point, and peer ports to specify the remote end points in the multi-core group cell to which 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. The host and port correspond to the bridge interfaces configured in the other cell. Specify a peer port for each bridge interface that is in the other cell.

In the 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.

Configure the peer access point.
In addition to specifying a name for the peer access point, you must complete the following actions:

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) we want the multi-core group cell to have to this other cell.

Click Next, and then Finish.

Save the configuration changes.

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

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

Click Next

Select a core group from the Available core group access points list, and then click 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 you only add one core group from the other cell to the inter-cell access point group.

Click Next

Select the appropriate peer access point from theAvailable peer access points list, and then click the arrow to add the selected peer access point to the access point group.
The selected peer access point must be the one you previously created to communicate with the other cell.

Click Next, and then click Finish.

Save the configuration changes.

Configure bridge interfaces for the 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 you 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, you must fully shut down, 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 you to periodically cycle out one of the bridges. If all the core group bridges in a core group are shut down, the core group state from all foreign core groups is lost.
gotcha

In the console, click Servers > Core Groups > Core group bridge settings > Access point groups >access_point_group > Core group access points

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

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

Click Apply.

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 the bridges highly available. When you define 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.

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 WebSphere Application Server 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 WebSphere Application Server proxy servers might report 503 errors, and JNDI look-ups for objects in remote core groups might fail.
If we are running on Version 7.0.0.1 or later, we can avoid such outages, if you 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 the core groups.

Shut down all core group bridges in all of the core groups.

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

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

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

Save the changes.

Synchronize the changes across the topology.

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.

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 concepts

Core group communications using the core group bridge service
Core groups (high availability domains)

Related tasks

Set up a high availability environment
Create backup clusters

Core group bridge settings
Core group bridge custom properties