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, you can change the list such that other servers are selected as coordinators.
For a large cell, multiple coordinators are recommended.
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 you 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.
Perform this task if you want 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.
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.
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.
You can use the administrative console to control the maximum amount of heap memory that is available for the underlying core group transport to allocate.
When you configure a core group, you can specify the type of network transport that you want the high availability manager to use for network communications.
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 Java virtual machine, 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. You can adjust the interval at which a core group IP cache is cleared.
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 that is used as data buffers.
There are situations where you must select a preferred IP address, or a range of IP addresses that you want the high availability manager to use for communication within a core group.
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 that is 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). You can modify the high availability group policy to specify that a specific cluster member handles the messaging work.