Core groups

A core group is a set of application servers that can be divided up into various high availability groups. It is a statically defined component of the WebSphere Application Server high availability manager function that monitors the application server environment and provides peer to peer failover of application server components.

A core group can contain one or more high availability groups. However, a high availability group must be totally contained within a single core group. Any component, such as the service integration bus component of IBM service integration technologies or the WebSphere Application Server transaction manager, can create a high availability group for that component's use. For example, the service integration bus might need a high availability group to support its messaging engines, and the transaction manager component might need a high availability group to support its transaction logs.

A cell must have at least one core group. The WebSphere Application Server creates a default core group, called DefaultCoreGroup, for each cell. All the server processes and Java virtual machines (JVMs), including node agents on all managed nodes, the deployment manager, and application servers residing within a cell are initially members of this default core group.

When properly configured, the default core group is sufficient for establishing a high availability environment. However, certain topologies require the use of multiple core groups. For example, if a firewall is used to separate the proxy environment from the server environment, an additional core group is required in order to provide proper failover support. For this particular type of environment, application servers outside of the firewall are members of a separate core group from the application servers that are inside of the firewall.

The core group contains a bridge service, which supports cluster services that span multiple core groups. Core groups are connected by access point groups. A core group access point defines a set of bridge interfaces that resolve to IP addresses and ports. It is through this set of bridge interfaces that the core group bridge provides access to a core group. If you create additional core groups, when you move core group members to the new core groups, remember that:

• Each server process and Java virtual machine (JVM), including node agents on all managed nodes, the deployment manager, and application servers within a cell can only be a member of one core group. Core groups cannot overlap each other.

• If a cluster is defined for the cell, all of the cluster members must belong to the same core group.

Network communication between all the members of a core group is essential. The network environment must consist of a fast local area network (LAN) with full Internet Protocol (IP) visibility and bidirectional communication between all core group members. IP visibility means that each member is entirely receptive to the communications of any other core group member. A core group consists of the following elements:

Coordinator

The coordinator is the elected, or default, high availability manager. The coordinator is responsible for tracking all of the members of a core group when members leave, join, or fail. The coordinator is not a single point of failure. In the event of a failure involving the coordinator, the preferred coordinator, or a default, picks up the high availability manager work, including the management of the core group.

Core group members

Any application server that is created within a cell that is defined as part of a high availability environment is automatically designated as a core group member.

Messaging subsystem

A messaging subsystem is a subsystem, such as the service integration bus component of IBM service integration technologies, that provides high-speed connections between core group members. This subsystem enables all core group members to quickly and effectively communicate with each other.

Core group bridge service

The core group bridge service is only utilized in high availability environments that contain multiple core groups. Use the bridge service to provide quick and effective communication between core groups.

Policy

A policy is used to control which members of a high availability group are activated. Even though a policy is defined at the core group level, it does not apply to the core group. The same policy can be used by several different high availability groups but all of the high availability groups to which it applies must be part of the same core group. A policy is established for a high availability group when that group is created. The following policies can be specified for a high availability group:

• All active policy: Under this policy, all of the group members are activated.

• M of N policy: Under this policy, M group members are activated. The number represented by M is defined as part of the policy details.

• No operation policy: Under this policy, no group members are activated.

• One of N policy: Under this policy, only one group member is activated.

• Static policy: Under this policy, only specified group members are activated.

In a run-time server environment each core group functions as an independent unit. A Java Virtual Machine (JVM) that is contained within a cell can be a member of one core group only. This JVM can be a node agent, an application server or a deployment manager. However, even though the deployment manager can belong to one core group only, it is still responsible for configuring all of the application servers within a cell, even if multiple core groups are defined for that cell. Every process within a core group contains an instance of the high availability MBean that can be used for various runtime operations within that core group. Java Management Extensions (JMX) connectors can be used to connect and query for this MBEAN in the following ways:

• JMX can connect and query on the deployment manager process just like
  the administrative console and most administrative clients do. This approach is easier because you only have to specify the host name and port numbers. However, if the deployment manager is down JMX will not be able provide access to the MBean.

• JMX can connect and query for the MBean on any process or across multiple processes within the core group. This approach is more reliable because even if the deployment manager is down, the JMX connectors can still access the MBean as long as one of the processes that contains the MBean is still running, .

Because the high availability MBean instances are scoped to a core group, if you have multiple core groups configured within a cell, refine a query for this MBean to the servers that are members of the core group you want to manage.

The coordinator retains and tracks membership and state changes for a core group. To work efficiently, the coordinator must have enough memory to contain the group and state information for the online members of the core group. Configuring multiple coordinators enables this task to be shared equally among a set of online coordinators.

Using the administrative console, you can designate specific servers as preferred coordinator servers. High availability manager coordinators run in these servers. If no preferred coordinator servers are specified, the high availability manager selects them. To minimize churn on the core group, it is recommended that you designate specific servers as preferred coordinator servers and limit how often you restart these servers. The heap sizes for the JVMs and the relative amount of memory that the JVMs use to host coordinator services need to be tuned to ensure that enough memory is available to hold the group and state information for the core group.

While core group members are statically configured, high availability group members are dynamically selected and only exist as run-time entities. The WebSphere Application Server runtime uses a policy matching program to determine the policy that should be used for each high availability group. Each policy includes a match criterion that consists of a set of name=value pairs. The policy matching program matches these name=value pairs with attributes contained in the name of a high availability group. When a match is made, the policy is associated with that high availability group.

Related tasks
High availability manager