Bootstrap FreeKB - IBM WebSphere - Getting Started with Core Group
IBM WebSphere - Getting Started with Core Group

Updated:   |  IBM WebSphere articles

What is a core group?

A core group is a collection of deployment managers (dmgr), administrative agent (admin agent), node agents, and application servers in a cell that communicate with each other for the purpose of ensuring that all of the members of the core group are up and running.

 


How does a core group provide high availability?

If one or more of the core group members becomes unavailable, events will be written to the SystemOut.log stating that the member is unavailable. In this way, the SystemOut.log can be monitored for event "Removing member" from "DefaultCoreGroup" as a way to be notified when one or the core group members is unavailable.

[3/30/19 05:32:00,876 CDT] 00000026 RoleMember    W   DCSV8104W: DCS Stack DefaultCoreGroup.TestRepln at Member cell01\node01\server01: Removing member [cell01\node01\server02] because the member was requested to be removed  by member cell01\node01\server01. Internal details VL suspects others: CC-Situation Normal

 


Default core group

A default core group, most appropriate named DefaultCoreGroup, is created during the installation of the dmgr. In the left panel of the dmgr admin console, select Servers > Core Groups Core group settings, and the core groups will be displayed. In this example, the only core group is the DefaultCoreGroup.

Notice you cannot delete DefaultCoreGroup and the description clearly states that DefaultCoreGroup cannot be deleted. This is because a cell must have a core group, thus there is no way to delete DefaultCoreGroup as a way to guarantee that the cell always contains a core group.

 


Core group members

Selecting a core group and then selecting Core group servers will display the components that are members of the core group. In this example, the core group contains the dmgr, two node agents, and two application servers. 

 

When you federate a node into a dmgr, by default, the node will be a member of DefaultCoreGroup. If using the WebSphere admin console to federate the node into the dmgr, you can select the core group you want the node to be in. If using the addNode.sh (Linux) or addNode.bat (Windows) command to federate the node into the dmgr, you can use the -coregroupname option to specify the core group that the node should be in.

 


Core Group Coordinator

One of the members of the core group will be assigned as the core group coordinator. The core group coordinator keeps tabs on each member, to know if they are still available.

 

Instead of letting one of the members being magically assigned as the coordinator, at Servers > Core Groups Core group settings  > DefaultCoreGroup > Preferred coordinator servers, you can select the member that will be the coordinator.

 


Communication protocol (DCS)

By default, Distribution and Consistency Services (DCS) is the protocol used for communication between the core group members.

 

When DCS is used, "DCS" event will appear in the SystemOut.log.

[3/30/19 05:32:00,876 CDT] 00000026 RoleMember    W   DCSV8104W: DCS Stack DefaultCoreGroup.TestRepln at Member cell01\node01\server01

 


Nodes can only be members only one core group

Each cell will contain at least one core group. For example, if you have 3 cells, each cell will have it's own core group.

  • Cell01 = DefaultCoreGroup
  • Cell02 = DefaultCoreGroup
  • Cell03 = DefaultCoreGroup

A node agent and the application servers in the node agent can only be a member of one core group. In other words, a node agent cannot reside in two or more different core groups. When you federate a node into the dmgr, the node agent and the application servers in the node will automatically be added to the DefaultCoreGroup.

 


Core Group Bridge

Let's say you have two Core Groups in a cell, Core Group "a" and Core Group "b". By default, these Core Groups will be isolated from each other, meaning that the members of Core Group "a" are unaware if the members of Core Group "b" are available, and vice versa. For even more reliability, you can create a Core Group Bridge, so that the members of Core Group "a" will know if the members of Core Group "b" are available, and vice versa. A bridge may also be able to help if one of the Core Groups is using a lot of CPU or memory.

 




Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee



Comments


June 15 2021 by Silvina
Hi Jeremy very clear your article. Just a question: I have a WASND v8 and the problem is that I cannot see the Servers > Core Groups through the console. However I can see the usr/IBM/WebSphere/AppServer/profiles/AppSrv01/config/cells/Prodcell/coregroups/DefaultCoreGroup/coregroup.xml in the file system. Is it a matter of user security permission ? or any other idea ? thanks Silvina

Add a Comment


Please enter 93ac90 in the box below so that we can be sure you are a human.