You 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 that are running in a different cell.
For example, a WebSphere Application Server 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.
About this task
To enable core group bridge communication between cells
that contain multiple core groups, you must 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.
You can use core
group bridge custom properties to set up advanced configurations for
a core group bridge.
Avoid trouble: 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 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 you 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 shutdown, 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 your core groups, you set the IBM_CS_WIRE_FORMAT_VERSION
core group custom property to the highest value that is supported
on your environment.
- To conserve resources, do not create more than two core group
bridge interfaces when you define a core group access point. You 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 that contain multiple core groups.
- Create a peer access point, and peer ports to specify the
remote end points in the cell to which you want 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 you 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 that are configured in the other cell. You must
specify a peer port for each bridge interface that is in the other
cell.
- In the administrative console, click access_point_group.
access_point_group is the name of the
access point group that already exists in the multi-core group cell.
- Configure your 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)
that you want this other cell to have to the multi-core group cell.
- Click Next, and then Finish.
- Save your configuration changes.
- Create an inter-cell access point group in the multi-core
group cell.
- In the administrative console, click .
- Click Next
- Select a core group from the Available core
group access points list, and then click the right arrow
to add the selected core group to the access point group.
The
selected core group should be the one that you want 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 right 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 your configuration changes.
- Create a peer access point, and peer ports to specify the
remote end points in the multi-core group cell to which you 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 you 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 that are configured in the other cell. You must
specify a peer port for each bridge interface that is in the other
cell.
- In the administrative console, click access_point_group.
access_point_group is the name of the
access point group that already exists in the other cell.
- Configure your 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)
that you want the multi-core group cell to have to this other cell.
- Click Next, and then Finish.
- Save your configuration changes.
- Create an inter-cell access point group in the other cell.
- In the administrative console, click .
- Click Next
- Select a core group from the Available core
group access points list, and then click the right arrow
to add the selected core group to the access point group.
The
selected core group should be the one that you want 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 right 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 your configuration changes.
- Configure bridge interfaces for your 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.
Avoid trouble: 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 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 you 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 shutdown, the core
group state from all foreign core groups is lost.
gotcha
In the administrative console, click access_point_group
- 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 your 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 you are running on Version 7.0.0.1 or later, you 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
your core groups.
- Shut down all core group bridges in all of your core
groups.
- Repeat the following actions for each core group in
each of your cells:
- In the administrative console, click 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 your changes.
- Synchronize your 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.