+

Search Tips   |   Advanced Search

Configure communication between core groups in the same cell

Configure two core groups with application servers in the same cell.

A cell, by default, contains a single core group, called DefaultCoreGroup. All processes in the cell are initially members of this core group. A single core group is usually sufficient. However, some topologies or special circumstances require multiple core groups. For example, the optimal number of servers in a core group is typically around 50. If the number of members in a core group exceeds this optimal number, we might need to create one or more additional core groups.

If defining multiple core groups within a cell, we should configure core group bridges between those core groups. If we do not configure these core group bridges, each core group is isolated from the other core groups in the cell.

After configuring the core group bridges between the core groups in a cell, each core group member can use the bridges to share its availability status with all of the other members of the configured core groups in that cell.

Requirements:

Recommended:

bprac


Configure communication between core groups in the same cell

  1. Configure an access point group to define the core groups that need to communicate.

    An access point group contains the core group access points for the core groups that need to communicate. Core group access points define the set of servers that provide access to the core group. To configure communication between core groups in the same cell, we can choose an existing access point group, such as the DefaultAccessPointGroup, which is created by default, or we can create a new access point group.

    To create a new access point group:

    1. In the administrative console, click...

        Servers > Core Groups > Core group bridge settings > Access point groups > New

    2. Enter a name for the access point group that is unique within the cell.

    3. Add core group access points to your access point group.

      Choose any available core group access points for the core groups that need to communicate in the cell. A default core group access point is automatically created whenever a core group is created.. Therefore, we should never have to create core group access points. The access point group that we create must have a core group access point for each core group in the cell that needs to communicate.

    When we configure communication between core groups in a single cell, we do not have to add any peer access points to an access point group. Refer to the topic Configure the core group bridge between core groups in different cells. bprac

    If we use an existing access point group, choose an access point group that does not have peer access points. To configure an existing access point group:

    1. In the administrative console, click...

        Servers > Core Groups > Core group bridge settings

      Your current configuration with any existing access point groups is displayed.

    2. Click...

        Access point groups > access_point_group_name> Core group access points

    3. Add core group access points to your access point group. Choose any available core group access points for the core groups that need to communicate.

  2. Create bridge interfaces for each core group access point.

    The bridge interfaces that we add provide access to the designated core group. Create at least one bridge interface for each core group access point. To ensure the availability of a core group access point, IBM recommends that we configure two bridge interfaces for each access point.

    Even though it is possible to define multiple access points for a core group, we should only define a single access point to represent each core group.

    1. In the administrative console, click...

        Servers > Core Groups > Core group bridge settings > Access point groups > access_point_group_name > Core group access points > core_group_access_point > Show Detail

    2. To create a new bridge interface, click...

        Bridge interfaces > New

    3. Select a server to be the bridge interface.

      • Do not select a server that handles production responsibilities, such as filtering requests to cluster members, or WebSphere proxy servers. Any server that is a core group bridge interface experiences extensive memory and CPU usage during core group bridge startup, and failover processing, which occurs when one of the bridges in a core group stops. If we cannot dedicate a server as a core group bridge interface, we should select a node agent as our core group bridge interface.

      • 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

    4. Repeat these steps to create bridge interfaces for each core group access point in your access point group.

  3. 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 we are running on Version 7.0.0.1 or later, set the IBM_CS_HAM_PROTOCOL_VERSION core group custom property to 6.0.2.31 for all of our 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 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.

The core groups in the same cell and configured in an access point group can communicate.


Example

In cell_x cell, we have core groups...

Each core group already has a core group access point.

To configure communication between the three core groups in the cell_x cell:

  1. Create the x_access_point_group access point group, then add access points...

    • x_core_group_ap_1
    • x_core_group_ap_2
    • x_core_group_ap_3

    ...to x_access_point_group.

  2. Create bridge interfaces for each core group access point.

    The following diagram illustrates the bridge interfaces for the x_core_group_ap_2 core group access point:

By creating an access point group and adding all core groups in the cell to the access point group, we enabled communication between all the core groups in the cell_x cell.


What to do next

We can configure this cell to communicate with core groups in other cells.


Related:

  • Core group communications using the core group bridge service
  • Core groups (high availability domains)
  • Configure the core group bridge service
  • Configure the core group bridge between core groups in different cells
  • Configure core group communication using a proxy peer access point
  • Create a new core group (high availability domain)
  • Core group access point settings
  • Core group access point collection
  • Bridge interface collection
  • Bridge interface settings
  • Bridge interface creation