Core group communications using the core group bridge service
The core group bridge service can be configured to share availability information about internal product components between core groups. For example, by configuring the core group bridge service, each core group can be aware of the status of all of the application servers configured in all of the core groups. Use access point groups to define the core groups that communicate. Do not use the core group bridge service to share application information among core groups.
A core group is a statically defined component of the high availability manager. Each cell must have at least one core group. The product automatically creates a default core group called DefaultCoreGroup for each cell. If we create additional core groups, we can configure core group bridges and access point groups to enable the different core groups to communicate with each other, and share workload management information. If we do not configure a core group bridge between the core groups, the core groups are isolated from each other.
A core group bridge can be configured to enable the following communication scenarios:
- Communication between core groups within the same cell.
- Communication between core groups in different cells
- Communication between core groups within the same cell and one or more core groups in a different cell
- Communication between core groups across different networks
- Communication between core groups using a proxy peer access point.
- Communication between core groups using a tunnel peer access point. This type of communication must be configured if you are using a DMZ Secure Proxy Server for IBM WebSphere Application Server
Core group bridge overview
To configure communication between core groups, configure an access point group. An access point group is a collection of the core groups that communicate with each other. Add a core group access point to the access point group for each core group that needs to communicate.
A core group access point is a collection of server, node, and transport channel chain combinations that communicate for the core group. Each core group has one or more defined core group access points. The DefaultCoreGroup has one default core group access point. However, you might consider configuring more than one core group access point for a core group if that particular core group needs to be connected to other core groups that are on different networks.
The node, server, and transport channel chain combinations that are in a core group access point are called bridge interfaces. A server that hosts the bridge interfaces is a core group bridge server. The transport channel chain defines the set of channels used to communicate with other core group bridge servers. Each transport channel chain has a configured port that the core group bridge server uses to listen for messages from other core group bridge servers.
Each core group access point must have at least one core group bridge server. The core group bridge server provides the bridge interface for each core group access point. Because core group bridge servers within a core group access point serve as backups for each other, IBM recommends that we have two core group bridge servers within each core group access point. Then, if one core group bridge server fails, the other core group bridge server can take over the failed core group bridge server's responsibilities.
If we are configuring communication between core groups that are in the same cell, create one access point group and add a core group access point for each core group that needs to communicate.
If we are configuring the core group bridge between core groups that are in different cells, you still use an access point group. However, create and configure the access point group for each cell. Each cell has an access point group containing a core group access point for the core group that is in the cell, and a peer access point for each peer cell.
A peer access point references a core group access point configured in a different cell. Each access point group must have one peer access point for each different cell. Do not configure multiple peer access points that reference the same cell.
Each peer access point has one or more peer ports or one proxy peer access point.
A peer port corresponds to a bridge interface defined in the peer cell. We can define several peer ports for each peer access point.
Define a proxy peer access point if the peer access point cannot be reached directly by using a peer port, but can be reached by using another peer access point. The proxy peer access point specifies a peer access point that can communicate with the peer core group that cannot be reached directly. The proxy peer must have defined peer ports. Specify one proxy peer or one or more peer ports, but not both.
The following diagram shows a core group bridge configuration between two different cells that is using peer access points with peer ports.
Figure 1. Core group bridge configuration in two different cells
Communication within the cell and outside of the cell
The following example illustrates a configuration between three core groups that are in three different cells. Each cell has one access point group for communication between core groups in the cell. Each cell also has a defined access_point_group_xyz access point group, which contains one core group access point group for the core group that is in the cell, and one core group access point for each of the core groups in the other two cells.
Figure 2. Communication between core groups that are in the same cell with core groups outside of the cell
The following example shows the relationship between bridge interfaces and peer ports for the communication between thecell_x cell and the cell_z cell. In the cell_x cell, two bridge interfaces are defined. In the cell_z cell a peer access point exists for the x_core_group_ap_2 core group access point with peer ports defined that correspond to the bridge interface information defined in the cell_x cell .
Figure 3. Bridge interfaces in one cell correspond to peer ports in the other cell
As a result, the core_group_x , core_group_y and core_group_z core groups can communicate with each other.
Communication between core groups across different networks
In this scenario, one core group is configured to communicate with two or more core groups in different cells across two or more networks. For example, a core group in the cell_x cell needs to communicate with core groups in the cell_y and cell_z cells. Create two access point groups in the cell_x cell. Theaccess_point_group_xy access point group, in the cell_x cell contains a core group access point and a peer access point for the core group in the cell_y cell. The access_point_group_xz access point group in the cell_x cell contains a core group access point and a peer access point for the core group in the cell_z cell. The cell_y cell has an access_point_group_xy access point group, which has a core group access point and a peer access point for the cell_x cell. The cell_z cell has an access_point_group_xzaccess point group, which has a core group access point and a peer access point for the cell_x cell.
Figure 4. Core group communication across different networks
Use a proxy peer access point when the core groups cannot directly communicate. The two core groups must have access to a single core group that can pass information between the two core groups. To understand what a proxy peer access point does, consider a connecting flight when flying on an airplane. To fly from Pittsburgh to London you first have to fly to New York City, where you change planes and then fly to London. New York City is the proxy peer access point for London.
When defining a proxy peer, the x_core_group_2 core group in the cell_x cell cannot communicate directly with the core group in the cell_z cell. However, both core groups can communicate with the core group in the cell_y cell. To configure communication between the cell_x cell and thecell_z cell, configure two access point groups. The core group access point in the cell_y cell is in both the access_point_group_xy and access_point_group_yz access point groups. The following image shows an overview of a proxy peer configuration.
Figure 5. Core group communication using a proxy peer access point
Communication between core groups using a tunnel proxy peer access point
Use a tunnel proxy peer access point when the core groups cannot directly communicate with each other because of a firewall. Typically, when a firewall exists between two core groups, the core groups cannot communicate with each other. However if a DMZ Secure Proxy Server for IBM WebSphere Application Server resides in the demilitarized zone (DMZ) outside of the firewall, we can create a tunnel access point group that enables us to establish a core group bridge tunnel between the core groups that are running on servers inside of the firewall, and the core groups that are running on the DMZ Secure Proxy Server for IBM WebSphere Application Server.
A tunnel access point group defines the access points that the core groups use to communicate with each other. The tunnel access point group consists of tunnel peer access points and core group access points. The tunnel peer access points are used to establish communication with the core groups that are running on the DMZ Secure Proxy Server for IBM WebSphere Application Server. The core group access points are used to establish communication between core groups that are running inside of the firewall.
Even though multiple core groups in a cell inside of the firewall need to communicate with a core group that are running in the DMZ Secure Proxy Server for IBM WebSphere Application Server, only one of the core groups can establish communication at a time. The DMZ Secure Proxy Server for IBM WebSphere Application Serverattempts to serially communicate with each core group inside of the firewall until it successfully establishes communication with one of the core groups. After communication is established, the DMZ Secure Proxy Server for IBM WebSphere Application Server stays connected to that core group until communication fails.
The DMZ Secure Proxy Server for IBM WebSphere Application Server tries to reestablish communication with that core group twice. If the DMZ Secure Proxy Server for IBM WAS cannot reestablish communication with that core group, it tries to establish communication with one of the other core groups for which a tunnel peer access point exists in the tunnel access point group.
Figure 6. Core group communication using a tunnel peer access point
Related concepts
Related tasks