Configuring 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, you can change the list such
that other servers are selected as coordinators.
Configuring 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 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.
Selecting an alternate protocol provider for a core group
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.
Configuring 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.
Selecting 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.
Configuring core group memory utilization
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.
Configuring a core group transport
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.
Configuring 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 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.
Configuring 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 that is used as
data buffers.
Specifying 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 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.
Last updated: April 18, 2014 05:01 AM CDT http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-iseries&topic=container_highavail_configuring_core_groups File name: container_highavail_configuring_core_groups.html