Configuring core groups

A core group is a high availability domain of container servers. In a stand-alone configuration, core groups are created by the catalog service. These default core groups consist of 20 container servers, where container servers are assigned to a core group on a first come, first served basis. In WebSphere® Application Server environments, you must configure core groups.

About this task

Consider explicitly configuring core groups in deployments that have greater than 20 container servers on multiple hosts. Distribute core group membership across hosts. For optimized failure detection, a core group must not be contained within a single host. Stripe multiple core groups across multiple hosts to ensure that failure detection occurs with the high availability manager in WebSphere eXtreme Scale. When you enable XIO, core groups are still created, but are ignored for failure detection with the containers. Core groups are still used for the catalog servers.

For more information about determining core group sizes, see Core group scaling considerations. Traditionally, 50 servers per core group is a rule of thumb for the maximum core group size.

If the core group is entirely on one host, and you lose the host, backup failure detection is employed. If the status update for a core group does not arrive within the configured heartbeat interval, then the catalog server periodically pings the container servers for their status. These pings are an Object Request Broker (ORB) or IBM eXtremeIO (XIO) calls to the container server. The container server is considered to be down or unavailable to the catalog server if the configured request timeout value passes. For more information about configuring heartbeat intervals and timeouts, see Tuning the heartbeat interval setting for failover detection and Configuring request and retry timeout values.

• Optional: Map your container servers to core groups in a stand-alone environment.

  Update the catalog server properties file to include a list of container servers that are assigned to specific core groups. You can include specific servers that are mapped to each core group. If you have a defined naming convention for your container servers, you can use wild cards.

  The following example maps two individual container servers to different core groups:

  svr1=cg1
  svr2=cg2
  

  The following example creates four core groups. The .* string defines the wildcard part of the server name:

  svr_.*_1=cg1
  svr_.*_2=cg2
  svr_.*_3=cg3
  svr_.*_4=cg4

  For example, the svr_blade1_1 and svr_blade2_1 servers are mapped to the cg1 core group. The svr_blade1_2 and svr_blade2_2 servers are mapped to the cg2 core group, and so on.
• Configure core groups in a WebSphere Application Server environment.

  You can use the WebSphere Application Server administrative console to change the core group membership. For more information, see Moving core group members.