Configuring communication between core groups that are in the same cell

Use this task to configure communication between core groups that are in the same cell.

Before you begin

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

About this task

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, you might need to create one or more additional core groups.

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

After you configure 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.

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 actions to configure communication between core groups that are in the same cell.

Procedure

  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 that are in the same cell, you can choose an existing access point group, such as the DefaultAccessPointGroup, which is created by default, or you can create a new access point group. To create a new access point group, complete the following steps:

    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, you should never have to create core group access points. The access point group that you create must have a core group access point for each core group in the cell that needs to communicate.

    Best practice: When you configure communication between core groups in a single cell, you do not have to add any peer access points to an access point group Refer to the topic Configuring the core group bridge between core groups that are in different cells for more information about configuring communication between cells.bprac

    If you 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, complete the following steps:

    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 you 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, it is recommended that you configure two bridge interfaces for each access point.
    Avoid trouble: Even though it is possible to define multiple access points for a core group, you should only define a single access point to represent each core groupgotcha
    1. In the administrative console, click Servers > Core Groups > Core group bridge settings > Access point groups > access_point_group_name > Core group access points.
    2. Click the name of a core group access point in the access point group, and then click Show Detail.
    3. To create a new bridge interface, click Bridge interfaces > New.
    4. Select a server to be the bridge interface.
      Best practice: A server that you select as a core group bridge interface should not be 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 you cannot dedicate a server as a core group bridge interface, you should select a node agent as your core group bridge interface.bprac
    5. 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.

    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.

    1. Shut down all core group bridges in all of your core groups.
    2. Repeat the following actions for each core group in each of your 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 your changes.
    3. Synchronize your 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.

Results

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

Example

In the cell_x cell, there are the x_core_group_1, x_core_group_2, and x_core_group_3 core groups. Each core group already has a core group access point. The following image illustrates an access point group between the core groups in the cell_x cell and an example of the configuration in the administrative console.

Figure 1. Three core group access points in the same cell belong to the same access point group. Three core group access points in the same cell belong to the same access point group.

Perform the following steps to configure communication between the three core groups in the cell_x cell:

  1. Create the x_access_point_group access point group. Add a core group access point to the access point group for each core group that is in the cell. In this example, add the x_core_group_ap_1 , x_core_group_ap_2, and x_core_group_ap_3 access points to the x_access_point_group access point group.
  2. Create bridge interfaces for each core group access point. The following diagram illustrates the bridge interfaces for thex_core_group_ap_2 core group access point:
    Figure 2. Core group access points contain one or more bridge interfaces.
    Core group access points contain bridge interfaces.

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

What to do next

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




In this information ...


Related information

IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Oct 22, 2010 12:21:29 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-zos&topic=trun_ha_cg1
File name: trun_ha_cg1.html