Configure the core group bridge between core groups that are in different cells

Overview

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.

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, we might have a situation where a WebSphere proxy server needs the ability to route requests to servers in other cells.

We can use core group bridge custom properties to set up advanced configurations for a core group bridge.

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 shut down, 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 we 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 shut down, the core group state from all foreign core groups is lost.

IBM recommends 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 the core groups, set the IBM_CS_WIRE_FORMAT_VERSION core group custom property to the highest value that is supported on the environment.

• To conserve resources, do not create more than two core group bridge interfaces when you define a core group access point. We 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.

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.

Configure a core group bridge between core groups in different cells

1. Configure bridge interfaces for the 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.
   1. In the console, click...
      Servers | Core Groups | Core group bridge settings | Access point groups | access_point_group | Core group access points

   2. Select one of the listed core group access points. Then click...
      Show detail | Bridge interfaces | New

   3. Select a node, server, and transport chain for your bridge interface.

   4. Click Apply.

   5. 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.

      The bridge interfaces selected must all have the same transport chain. gotcha

2. 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 the configuration.

   1. In the console, click...
      Servers | Core Groups | Core group bridge settings | Access point groups | access_point_group | Custom properties | New

   2. 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, we can set the value to any string value. Setting the value to false does not disable the property. To disable the property, remove it from the list of defined custom properties or change its name.

   3. Click Apply and save the configuration.

   When you complete this step on all the access point groups in the configuration, we can add a bridge interface to one of the cells. We can save the configuration so that it is propagated to all of the nodes. Instead of restarting all of the application servers, we need to restart the new bridge interface server only.

3. Add peer access points and peer ports to the access point group.

   If we defined the cgb.allowUndefinedBridges custom property for all of the access point groups in the configuration, we 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 we add a peer access point, determine the following information about the other cell:

   • Cell name
   • Core goup name
   • Core goup access point name
   • Host and port information. The host and port correspond to the bridge interfaces configured in the other cell. Specify a peer port for each bridge interface that is in the other cell.

   1. In the console, click Servers > Core Groups > Core goup bridge settings > Access point groups >access_point_group > Peer access points > New.

   2. Information for the 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 we 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 we 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 we 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 contained in the local cell. but to prevent the communicating server from changing the data.

        • If we 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 we do not want applications that resides outside of the local cell to read this information.

   3. Click Next.

   4. Select Use peer ports. Specify the host and port information for the peer cell. For example, if you defined a bridge interface in cell_x, use that configuration information for the peer port in cell_y.

   5. Click Next and then Finish. Save your configuration.

4. Optional: If more than one bridge interface is defined in the peer cell, add additional peer ports for each bridge interface.

   1. Click Peer access points > peer_access_point > Show detail > Peer ports > New.

   2. Enter the host name and port.

   3. Click Apply , and save the changes.

5. 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 the 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 the core groups.

   1. Shut down all core group bridges in all of the core groups.

   2. Repeat the following actions for each core group in each of the cells:

      1. In the console, click Servers > Core Groups > Core goup 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 the changes.

   3. Synchronize the 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

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 containing one core group access point for the core group that is in the cell and a peer access point for the other cell.

Example

Example 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.

1. Use the console for the primary cell, click Servers > Core groups > Core goup bridge settings > Access point groups > DefaultAccessPointGroup > Core goup access points.

2. Select CGAP_1/DefaultCoreGroup. and then click Show Detail.

3. Select Bridge interfaces, and then click New.

4. In the Bridge interfaces field, select the deployment manager, wasdmgr02/dmgr/DCS, from the list of available bride interfaces, and then click OK.

5. Click New to create a second bridge interface.

6. In the Bridge interfaces field, select a node agent, such as wasna01/nodeagent/DCS, and then click OK to save the changes.

7. Go to the console for the remote cell, and click Servers > Core groups > Core goup bridge settings > Access point groups > DefaultAccessPointGroup > Core goup access points..

8. Select CGAP_1/DefaultCoreGroup. and then click Show Detail.

9. Select Bridge interfaces, and then click New.

10. In the Bridge interfaces field, select the deployment manager, wasdmgr03/dmgr/DCS, from the list of available bride interfaces, and then click OK.

11. Click New to create a second bridge interface.

12. 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 the changes.

13. Save the changes.

14. Gather the following information for the remote cell:

    • The DCS port for the deployment manager. Click System administration > dmgr > Ports > DCS_UNICAST_ADDRESS, 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 System administration >Node agents > wasna01 > Ports > DCS_UNICAST_ADDRESS, 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 Javabeans (EJB) cluster belongs. Click Servers > Core groups > Core goup settings > DefaultCoreGroup >. Core group members, verify that the 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 System administration > Cell, 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 Servers > Core groups > DefaultCoreGroup > Core group bridge settings, 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.

15. Go back to the 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.

16. Create a new peer access point that points to the remote cell. In the primary cell console, click Servers > Core groups > Core goup bridge settings > Access point groups > DefaultAccessPointGroup > Peer access points.

    1. Click New to start the Create new peer access point wizard.

    2. 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.

    3. 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.

    4. Click Next, confirm that the information that specified for the new peer access point is correct, and then click Finish.

17. Create a second peer access point for the node agent.

    1. Select the peer access point that you just created, RemoteCellGroup/wascell03/DefaultCoreGroup/CGAP_1, and then click Show Detail.

    2. In the Peer addressability section, select Peer ports, and then click Peer ports > New.

    3. 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.

18. Click OK and then click Save to save the changes to the master configuration.

19. To start the Create new peer access point wizard and create peer access points in the remote, go to remote cell console, and click...
    Servers | Core groups | Core goup bridge settings | Access point groups | DefaultAccessPointGroup | Peer access points | New cell

    1. 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.

    2. 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.

    3. Click Next, confirm that the information that specified for the new peer access point is correct, and then click Finish.

20. Create a second peer access point for the node agent on the primary cell.

    1. Select the peer access point that you just created, PrimaryCellGroup/wascell02/DefaultCoreGroup/CGAP_1, and then click...
       Show Detail | Peer addressability section | Peer ports | Peer ports | New

    2. 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.

21. Click OK and then click Save to save the changes to the master configuration.

22. Restart both cells.

What to do next

Continue configuring the high availability environment.

Related concepts

Core group communications using the core group bridge service

Core groups (high availability domains)

Set up a high availability environment

Create backup clusters

Core group bridge settings

Core group bridge custom properties