Use this task to configure communication between core groups
that are in different cells.
Before you begin
Verify that the following conditions exist:
- You have two or more core groups that are in different cells.
A core group is a statically defined component of the high availability
manager.
- Any cell that uses core group bridges to connect to core groups
in other cells have a name that is unique when compared to the names
of the other cells.
About this task
A core group bridge should be used in situations where
the availability status of servers in different cells needs to be
shared across all of those cells. For example, you might have a situation
where a WebSphere proxy server needs the ability to route requests
to servers in other cells.
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
Avoid trouble: When creating a core group bridge between two core
groups in different cells, the member communication key value of both
access point groups in both cells must match. By default, the member
communication key defaults to whatever the name of the access point
group is. There are two ways to do this:
- Make two access point groups the same name.
- If the names of two access point groups are different, set the
member communication key of either access point group to the name
of the other access point group.
gotcha
To configure a core group bridge between core groups
in different cells, complete the following procedure for each of the
cells in your configuration.
Procedure
- Configure bridge interfaces for your core group access
point. Configuring a bridge interface indicates that the
specified node, server, and chain combination is a core group bridge
server. This node and server use the specified chain to communicate
with other core groups.
- 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 at least two
bridge interfaces for each core group access point to back up your
configuration. 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.
Avoid trouble: The bridge interfaces
that you select must all have the same transport chain.
gotcha
- If you want the ability to add core group bridge servers
to the configuration without restarting the other servers in the configuration,
define the cgb.allowUndefinedBridges custom property on all of the
access point groups in your configuration.
- In the administrative console, click access_point_group >
Custom properties > New.
- Type the name as cgb.allowUndefinedBridges and set the
value to any string.
The existence
of the cgb.allowUndefinedBridges property automatically enables this
property. Therefore, you can set the value to any string value. Setting
the value to false does not disable the property.
To disable the property, you must remove it from the list of defined
custom properties or change its name.
- Click Apply and save your configuration.
When you complete this step on all the access point
groups in your configuration, you can add a bridge interface to one
of the cells. You can save the configuration so that it is propagated
to all of the nodes. Instead of restarting all of the application
servers, you need to restart the new bridge interface server only.
- Add peer access points and peer ports to your access point
group.
If you defined the cgb.allowUndefinedBridges
custom property for all of the access point groups in your configuration,
you do not need to add peer access points or peer ports to the listener
cell.
Add a peer access point for each core group that is in
another cell. Within each peer access point, you should configure
a peer port that corresponds to each bridge interface in the other
cell. 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. Specify a
peer port for each bridge interface that is in the other cell.
- In the administrative console, click access_point_group.
- Specify the information for your peer access point.
In addition to specifying a name for the peer access point,
you must complete the following actions:
- Specify the remote cell where the peer access point resides.
- Specify the name of the core group in the remote cell to which
the peer access points belongs.
- Select either Use peer ports or Use proxy peer access
points, depending on whether the peer access point can be reached
directly or can only be reached indirectly through another peer access
point.
- Select the level of access that you want a server from another
cell to have to the local cell when that server uses this access point
to establish communication with the local cell.
- If you select Full access, the communicating server can
read data from and write data to the local cell. This level of access
is appropriate if there is no reason to restrict read or write access
to the local cell.
- If you select Read only, the communicating server can read
data from the local cell, but is not permitted to write data to the
local cell. This level of access is appropriate if applications running
in other core groups need to access data that is contained in the
local cell. but you want to prevent the communicating server from
changing the data.
- If you select Write only, the communicating server can
write data to the local cell, but is not permitted to read data from
the local cell. This level of access is appropriate if applications
running in other core groups need to write data to the local cell,
but the data stored on the local cell is sensitive. For example, the
local cell might contain customer account numbers, and you do not
want applications that resides outside of the local cell to read this
information.
- Click Next.
- Select Use peer ports. Specify the host and port
information for your peer cell. For example, if you defined
a bridge interface in cell_x, use that configuration information
for your peer port in cell_y.
- Click Next and then Finish. Save your
configuration.
- Optional: If more than one bridge interface
is defined in your peer cell, add additional peer ports for each bridge
interface.
- Click Peer access points > peer_access_point >
Show detail > Peer ports > New.
- Enter the host name and port.
- Click Apply , and save your changes.
- 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.
Results
You configured the core group bridge between core groups
that are in different cells.
The following figure illustrates
the resulting core group bridge between the two core groups that are
in two different cells. Each cell has a defined access point group
that contains one core group access point for the core group that
is in the cell and a peer access point for the other cell.
Example
The following example illustrates the configuration steps
that are performed to set up a core group bridge between two cells.
In this example:
- The two cells are referred to as the primary cell and the remote
cell.
- wasdmgr02/dmgr/DCS is the name of the deployment manager on the
primary cell, and wasdmgr02/dmgr/DCS is the name of the deployment
manager on the remote cell.
- wasna01/nodeagent/DCS is the name of a node on both the primary
cell and the remote cell.
- CGAP_1/DefaultCoreGroup is the name of the core groups on both
the primary cell and the remote cell.
- Using the administrative console for the primary cell, click
- Select CGAP_1/DefaultCoreGroup. and then
click Show Detail.
- Select Bridge interfaces, and then click New.
- In the Bridge interfaces field, select
the deployment manager, wasdmgr02/dmgr/DCS,
from the list of available bride interfaces, and then click OK.
- Click New to create a second bridge interface.
- In the Bridge interfaces field, select
a node agent, such as wasna01/nodeagent/DCS,
and then click OK to save your changes.
- Go to the administrative console for the remote cell, and click .
- Select CGAP_1/DefaultCoreGroup. and then
click Show Detail.
- Select Bridge interfaces, and then click New.
- In the Bridge interfaces field, select
the deployment manager, wasdmgr03/dmgr/DCS,
from the list of available bride interfaces, and then click OK.
- Click New to create a second bridge interface.
- In the Bridge interfaces field, select
the node agent, wasna01/nodeagent/DCS, from
the list of available bride interface, and then click OK to
save your changes.
- Save your changes.
- Gather the following information for the remote cell:
- The DCS port for the deployment manager. Click , and write down the
port number for DCS_UNICAST_ADDRESS. In this example, the DCS port
for the deployment manager is 9353.
- The DCS port for the wasna01 node agent. Click , and write
down the port number for DCS_UNICAST_ADDRESS. In this example, the
DCS port for the node agent is 9454.
- The name the of the core group in the cell to which the Enterprise
Javabean (EJB) cluster belongs. Click , verify that your servers
are members of the DefaultCoreGroup core group, and then write down
the core group name. In this example the core group name is DefaultCoreGroup.
- The name of the cell. Click , and then write down the name that
displays in the Name field. In this example,
the name of the name of the cell is wascell03.
- The name of the core group access point. Click , expand the DefaultAccessPointGroup field,
and write down the name of the core group access point that displays
when you expand Core Group DefaultCoreGroup.
In this example the name of the core group access point is CGAP_1.
- Go back to the administrative console for the primary cell and
gather the same information about the primary cell. In this example:
- The DCS port for the deployment manager on the primary cell is
9352.
- The DCS port for the wasna01 node agent on the primary cell is
9353.
- The name of the core group in the cell to which the EJB cluster
belongs is DefaultCoreGroup.
- the name of the cell is wascell02.
- The name of the core group access point is CGAP_1.
- Create a new peer access point that points to the remote cell.
In the primary cell administrative console, click .
- Click New to start the Create new peer
access point wizard.
- Specify the name of the new peer access point, RemoteCellGroup,
in the Name field, wascell03 in
the Remote cell name field, DefaultCoreGroup in
the Remote cell core group name field, and CGAP_1 in
the Remote cell core group access point name field.
- Click Next, and then select either Use
peer ports or Use a proxy peer access point.
For this example, we select Use peer ports ,
and specify washost02 in the Host field,
and 9353 in the Port field.
These values are the host name and DCS port number for the deployment
manager on the remote cell.
- Click Next, confirm that the information
that you specified for the new peer access point is correct, and then
click Finish.
- Create a second peer access point for the node agent.
- Select the peer access point that you just created, RemoteCellGroup/wascell03/DefaultCoreGroup/CGAP_1,
and then click Show Detail.
- In the Peer addressability section, select Peer ports,
and then click Peer ports > New.
- Specify washost04 in the Host field,
and 9454 in the Port field.
These values are the host name and DCS port number for the node agent
on the remote cell.
- Click OK and then click Save to
save your changes to the master configuration.
- Go to remote cell administrative console, and click to start the Create new
peer access point wizard and create peer access points in the remote
cell.
- Specify the name of the new peer access point, PrimaryCellGroup,
in the Name field, wascell02 in
the Remote cell name field, DefaultCoreGroup in
the Remote cell core group name field, and CGAP_1 in
the Remote cell core group access point name field.
- Click Next, and then select either Use
peer ports or Use a proxy peer access point.
For this example, we select Use peer ports ,
and specify washost01 in the Host field,
and 9352 in the Port field.
These values are the host name and DCS port number for the deployment
manager on the primary cell.
- Click Next, confirm that the information
that you specified for the new peer access point is correct, and then
click Finish.
- Create a second peer access point for the node agent on the primary
cell.
- Select the peer access point that you just created, PrimaryCellGroup/wascell02/DefaultCoreGroup/CGAP_1,
and then click Show Detail.
- In the Peer addressability section, select Peer ports,
and then click Peer ports > New.
- Specify washost03 in the Host field,
and 9353 in the Port field.
These values are the host name and DCS port number for the node agent
on the primary cell.
- Click OK and then click Save to
save your changes to the master configuration.
- Restart both cells.
What to do next
Continue configuring the high availability environment.