Core group settings
To create a core group or to edit an existing core group. A core group is a component of the high availability manager function. It can contain standalone servers, cluster members, node agents, administrative agents, and the dmgr. A core group must contain at least one node agent, administrative agent, or the dmgr.
Before you create a core group understand the relationship of core groups in a high availability environment and know how you intend to use each core group.
To view this admin console page ...
Servers > Core Groups > Core group settings. Then, either select an existing core group or click New .
On the Configuration tab, we can edit fields. On the Runtime tab, we can look at read-only information.
After you specify the core group settings, click Apply before defining additional properties or setting up a core group bridge.
- Name
Name of the core group. This field can only be edited when you create new core groups.
If defining a new core group, specify a name that is unique among the existing core groups. It is useful to other product administrators if the name helps to define the use of this core group, and if it is consistent with the names of the other core groups in the cell.
This field can contain alpha and numeric characters.
The following characters cannot be used in this field:
# \ / , : ; " * ? < > | = + & % 'Also, the name cannot begin with a period (.) or a blank space. A blank space does not generate an error. However, leading and trailing blank spaces are automatically deleted.
For example, DefaultCoreGroup is the name of the core group that contains the dmgr server process.
- Description
This field is optional. If used, it should provide useful information about the core group. Use this field to help describe the purpose of a core group or to provide important information about a core group. For example, the value specified for Description for the default core group DefaultCoreGroup, that is provided with WAS ND, is The default core group cannot be deleted..
The supported length of this field is large enough to accommodate long descriptions. However, long descriptions take time to load and can cause a delay when displaying the page.
- Number of coordinators
Number of coordinators for this core group. The coordinator is the aggregation point for high availability manager information. The coordinator determines group membership and communicates state and status to the other members of the core group.
The default value is one coordinator, although multiple coordinators are advisable for large core groups. All of the data for a core group must fit in the memory of the allocated coordinators. Therefore, if we have multiple coordinators, more memory is available to store the core group data. If a single coordinator is defined in a system with a large core group, the core group data might consume all of that coordinators memory, causing processing errors.
- Transport memory size
Specifies, in megabytes, the maximum size of dynamically allocated memory that the transport can acquire. The range is from 10 to 2147483647 megabytes. However, this value cannot exceed the maximum heap size specified for the Java™ virtual machine. When this limit is reached, congestion control is invoked, and communication between core group members is limited, and processing errors might occur.
- Transport type
Transport mechanism to use for communication between members of a core group. Select either Channel framework or Unicast.
Avoid trouble: If a core group needs to use the core group bridge service, select Channel framework as the transport mechanism for that core group. If we select Unicast, we might receive error message CHFW0029E, which indicates that the transport chain could not be initialized because the address was already in use.
Deprecated feature: Support for unicast transports is deprecated. Select Channel framework as your transport type if the environment makes it possible to do so.depfeat
- Transport chain
Name of the transport chain, if we select channel framework for the transport type.
- Additional Properties
- Core group servers
- Server processes that belong to the core group. Server processes include the dmgr, node agents, appservers, and cluster members. To move server processes to a different core group.
- Custom properties
- Custom properties that are used for configuration purposes.
- Policies
- Policies that determine which members of a high availability group are made active.
- Preferred coordinator servers
- Specifies which core group servers are preferred coordinator servers.
- Related Items
- Core group bridge settings
- Click to navigate to the admin console page where we can define a core group bridge. A core group bridge is required to establish communication between core groups residing in different cells.
- Group name properties
Specifies one or more name=value pairs as the match criterion for a high availability group. If we specify more than one name=value pair, use a comma to separate the pairs. We can specify an asterisk (*) to obtain the selected information for all of the high availability groups within this core group.
Avoid trouble: We can specify multiple properties as the value in the Group name properties field. However, if we specify multiple properties, commas must be used to separate the properties. Blank spaces are not allowed in a value specified in this field.
When a component creates a new high availability group, it establishes a map of the properties for that group. This map becomes the group name, and is used to uniquely identify that high availability group.
After you specify a match criterion or an asterisk...
- Select Calculate groups to determine how many high availability groups have names that match this criterion. The number of high availability groups that are found that have the specified group name properties displays in the Number of matches field.
- Select Show groups to view a list of the currently running high availability groups that match this criterion. This list indicates the following information for each group:
- Its high availability group name
- Whether or not quorum has been enabled
- The policy that is associated with the high availability group. If more than one policy is listed for a high availability group, change the match criterion for one or more of the policies so that only one policy is associated with this high availability group.
- Its status. If only one policy is listed in the Policy column, the OK icon is displayed in the Status column. If more than one policy is listed in the Policy column, the Error icon is displayed in the Status column.
- Select Show severs to view a list of the servers that are hosting active members of the high availability groups that match the value specified for the Group name properties field. For each server, this list indicates:
- The name of the node on which these servers reside
- The version of WAS on which these servers run
- The number of high availability group members that are currently active on these servers
For example, suppose that the following high availability groups are defined for a core group:
- Component A uses the following properties for its group name: [ name=compA, policy=oneofN, owner=smith ]
- Component B uses the following properties for its group name: [ name=compB, policy=MofN, owner=smith ]
- Component C uses the following properties for its group name: [ name=compC, policy=oneofN, owner=smith ]
If we specify policy=oneofN in the Group name properties field and then select Show groups, the groups for components A and C are listed.
If we specify owner=smith in the Group name properties field and then select Show groups, the groups for components A, B and C are listed.
If we specify name=compC,policy=oneofN,owner=smith, which is all of the name properties for component C, in the Group name properties field and then select Show groups, only the group for component C is listed.
Related tasks
Create a new core group (high availability domain)
View the core groups in a cell
Related
Core group collection