A core group is a high-availability domain that consists of a set of processes in the same cell that can directly establish high-availability relationships. Highly available components can fail over only to another process in the same core group, and replication can occur only between members of the same core group.
A cell must contain at least one core group, although multiple core groups are supported. By
default, a cell has a single core group called
DefaultCoreGroup. A single core group is
usually sufficient. However, some topologies or special circumstances require multiple core
groups. Bridges can be established between core groups.
By default, every deployment manager, node agent, application server, and proxy server is a member of a core group and has the high availability manager service enabled. When a process is created, it is added automatically to a core group. The core group membership is stored in a WebSphere Application Server configuration document. You can move processes from one core group to another. When a core group member starts, the core group transport and the associated default Discovery Protocol, default Failure Detection Protocol, and View Synchrony Protocol also start.
Figure below shows the high availability manager protocol traffic within a core group:
Each core group contains a core group coordinator to manage its high-availability relationships and a set of high-availability policies that are used to manage the highly-available components within that core group.
The following aspects are managed by the core group coordinator:
Maintaining all group information, including the group name, group members, and the policy of the group
Keeping track of the states of group members as they start, stop, or fail, and communicating that information to every member
Assigning singleton services to group members and handling failover of services based on core group policies
When a JVM process with the active coordinator no longer active (because it is stopped or crashes), the high availability manager elects the first inactive server in the preferred coordinator servers list. If there are no servers available, the high availability manager elects the lexically lowest named inactive server.
The newly elected coordinator initiates a state rebuild, sending a message to all JVMs in the core group to report their states. This operation is the most processor-intensive operation of a coordinator.
Core group coordinator
Every core group has a coordinator that manages high availability activities between the core group members. The coordinator manages the failover of highly available singleton services and distributes live server state data to interested core group members. The coordinator uses some CPU and memory (JVM heap) resources to perform these tasks. In some configurations, the amount of resources that the coordinator uses might be large.
The coordinator workload can be divided over multiple coordinator instances. Each instance runs on a different core group member and is assigned a portion of the overall coordination workload. Dividing the workload across multiple coordinator instances enables you to share the associated resource costs across machines. The coordinator function remains highly available, regardless of how its workload is divided or assigned to core group members.
Multiple core group coordinators
The core group configuration data contains a field in which users can specify the number of coordinators. The default value for this field is 1. This default value is sufficient for most installations and applications. Use multiple coordinators when the core group member that is selected as the coordinator uses noticeably more memory or CPU than similar core group members. In addition, some software products that heavily use the high availability framework instruct you to increase the number of coordinators.