The core group bridge service can be configured for communication
between core groups. Use an access point group to define the core
groups that communicate. Use this task to configure communication
between core groups that are in different cells.
Before you begin
Make sure that:
- You have two or more core groups that are in different cells.
Core groups are 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.
- Any core group that uses a core group bridge is configured with
Channel framework as its transport mechanism.
About this task
Use the core group bridge service to share the availability
status of the servers in each core group among all the configured
core groups. Enable the core group bridge only when the service is
required by a WebSphere Application Server component.
For example, the core group bridge is required
when configuring an Enterprise JavaBeans (EJB) backup cluster. Configure
a backup EJB cluster in a different cell to continue servicing requests
when the primary cluster fails. See Creating backup clusters for more information.
When
you configure core group communication between core groups that are
in different cells, you must configure an access point group to connect
the core groups. The name of the access point group must be the same
in all of the connected cells. This task uses the DefaultAccessPointGroup
access point group, but you can create and use another access point
group.
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.
bprac
Complete
the following set of steps 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 Servers > Core
groups > Core group bridge settings > Access point groups > DefaultAccessPointGroup >
Core group access points > CGAP_1\DefaultCoreGroup >
Show detail > Bridge interfaces > New.
- Select a node, server, and transport channel chain that
becomes 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.
By defining two bridge interfaces, you define two core group bridge
servers. If one core group bridge server fails, the other can take
over the work so that the communication between the core groups can
continue.
Important:
The bridge interfaces that
you select must all have the same transport channel chain.
- Add peer access points and peer ports to your access point
group.
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, you should have 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 Servers > Core
groups > Core group bridge settings > Access point groups > DefaultAccessPointGroup >
Peer access points > New.
- Specify the information for your peer access point and
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.
If more than one bridge interface is defined in your peer cell,
add additional peer ports for each bridge interface.
- Click Peer_access_point_name > 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.
During core group bridge state rebuilds, cross-core
group state can be moved between running bridges. This situation
might cause the data to be temporarily unavailable until the bridge
has completed the rebuild process.
If
you are running on Version 6.0.2.31 or later, set the IBM_CS_HAM_PROTOCOL_VERSION
core group custom property to 6.0.2.31 for
all of your core groups to avoid a possible high availability state
outage during core group bridge failover. 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.
Example
The following illustration is an example of a configuration
between two core groups that are in two different cells. Each cell
has a defined DefaultAccessPointGroup access point group, which
contains one core group access point for the core group that is in
the cell and a peer access point for the other cell.
What to do next
Continue configuring the high availability environment.