Configure core groups
Subtopics
- Configure core group preferred coordinators
The high availability manager uses an ordered list of preferred core group servers when it selects servers to host the coordinators. If the default list is inappropriate, we can change the list such that other servers are selected as coordinators.
- Change the number of core group coordinators
For a large cell, multiple coordinators are recommended.
- Configure the default Discovery Protocol for a core group
The default Discovery Protocol for a core group establishes network connectivity between a new core group member and the other members of that core group. Perform this task if we need to tune the default Discovery Protocol behavior for a core group. The default value of 60 seconds, which is set by the product installation process, provides an acceptable process detection time for most situations.
- Select an alternate protocol provider for a core group
Perform this task to use an alternate protocol provider instead of the default Discovery Protocol and the default Failure Detection Protocol to monitor and manage communication between core group members. In general, alternate protocol providers, such as the z/OS Cross-system Coupling Facility (XCF)-based provider, use less system resources than the default Discovery Protocol and Failure Detection Protocol, especially during times when the core group members are idle. An alternate protocol provider generally use less system resources because it does not perform the member-to-member TCP/IP pinging that the default protocol providers use to determine if a core group member is still active.
- Configure the default Failure Detection Protocol for a core group
The default Failure Detection Protocol monitors the core group network connections that the default Discovery Protocol establishes, and notifies the default Discovery Protocol if a connection failure occurs.
- Select the version of a core group protocol
There are two major categories or groups of high availability manager protocols. Both of these protocol groups can be independently configured to use newer versions of the protocols.
- Configure core group memory utilization
We can use the console to control the maximum amount of heap memory that is available for the underlying core group transport to allocate.
- Configure a core group transport
When you configure a core group, we can specify the type of network transport we want the high availability manager to use for network communications.
- Configure core group IP caching
The caching of name-to-IP address information can be performed at many levels within the network communication software stack. These levels include within the operating system, the JVM, and within the product components, such as core groups. Core groups use caching to reduce the overhead that is associated with IP address name lookup. We can adjust the interval at which a core group IP cache is cleared.
- Configure core group socket buffers
Most operating systems provide program interfaces for performing operations involving the sending and receiving of data over sockets. Most operating systems also provide administrative capabilities to control the amount of memory allocated per socket used as data buffers.
- Set up IP addresses for high availability manager communications
There are situations where you must select a preferred IP address, or a range of IP addresses we want the high availability manager to use for communication within a core group.
- Specify a preferred server for messaging requests
If a core group includes a cluster of application servers, and a messaging engine is configured for that cluster, any of the servers in that cluster can handle work items for the messaging engine. The default message provider included in the product is based on Service Integration Bus (SIB) technology, and is governed by the Default SIBus policy, which is a One of N policy. This policy ensures that only one of the application servers in the cluster is active at a time). We can modify the high availability group policy to specify that a specific cluster member handles the messaging work.