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

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

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

  1. 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.
    1. In the administrative 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.

      Avoid trouble: The bridge interfaces that you select must all have the same transport chain. gotcha
  2. 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.
    1. In the administrative 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, 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.

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

  3. 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.
    1. In the administrative console, click Servers > Core Groups > Core group bridge settings > Access point groups > access_point_group > Peer access points > New.
    2. 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.
    3. Click Next.
    4. 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.
    5. Click Next and then Finish. Save your configuration.
  4. Optional: If more than one bridge interface is defined in your 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 your changes.
  5. 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

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.

The 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:
  1. Using the administrative console for the primary cell, click Servers > Core groups > Core group bridge settings > Access point groups > DefaultAccessPointGroup > Core group 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 your changes.
  7. Go to the administrative console for the remote cell, and click Servers > Core groups > Core group bridge settings > Access point groups > DefaultAccessPointGroup > Core group 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 your changes.
  13. Save your changes.
  14. Gather the following information for the remote cell:
    • The DCS port for the deployment manager. Click System administration > Deployment manager > 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 Javabean (EJB) cluster belongs. Click Servers > Core groups > Core group settings > DefaultCoreGroup >. Core group members , 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 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 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.
  16. Create a new peer access point that points to the remote cell. In the primary cell administrative console, click Servers > Core groups > Core group 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 you 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 your changes to the master configuration.
  19. Go to remote cell administrative console, and click Servers > Core groups > Core group bridge settings > Access point groups > DefaultAccessPointGroup > Peer access points > New to start the Create new peer access point wizard and create peer access points in the remote 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 you 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.
    2. In the Peer addressability section, select Peer ports, and then click Peer ports > New.
    3. 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 your changes to the master configuration.
  22. Restart both cells.

What to do next

Continue configuring the high availability environment.



In this 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 21, 2010 7:37:48 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v701sca&product=was-nd-mp&topic=trun_ha_coregroupbridge2
File name: trun_ha_coregroupbridge2.html