A high availability manager consumes valuable system resources,
such as CPU cycles, heap memory, and sockets. These resources are consumed
both by the high availability manager and by WebSphere Application Server
components that use the services that the high availability manager provides.
The amount of resources that both the high availability manager and these
WebSphere Application Server components consume increases exponentially as
the size of a core group increases. For large core groups, the amount of resources
that the high availability manager consumes can become significant. If the
services that the high availability manager provides are not used, then disabling
the high availability manager frees these resources.
The capability to disable the high availability manager is most useful
for large topologies where none of the high availability manager provided
services are used. In certain topologies, only some of the processes use the
services that the high availability manager provides. In these topologies,
you can disable the high availability manager on a per-process basis, which
optimizes the amount of resources that the high availability manager uses.
Do not disable the high availability manager on administrative processes,
such as node agents and the deployment manager, unless the high availability
manager is disabled on all application server processes in that core group.
Some of the services that the high availability manager provides are cluster
based. Therefore, because cluster members must be homogeneous, if you disable
the high availability manager on one member of a cluster, you must disable
it on all of the other members of that cluster.
When determining if you must leave the high availability manager enabled
on a given application server process, consider if the process requires any
of the following high availability manager services:
- Memory-to-memory replication
- Singleton failover
- Workload management routing
- On-demand configuration routing
Memory-to-memory replication
Memory-to-memory replication
is a cluster-based service that you configure or enable at the application
server level. If memory-to-memory replication is enabled on any cluster member,
then the high availability manager must be enabled on all of the members of
that cluster. Memory-to-memory replication is automatically enabled if:
Singleton failover
Singleton
failover is a cluster-based service. The high availability manager must be
enabled on all members of a cluster if:
- The cluster is configured to use the high availability
manager to manage the recovery of transaction
logs.
- One or more instances of the default Java™ Message Service (JMS) provider are
configured to run in the cluster. The default JMS provider is the messaging
engine that is provided with WebSphere Application Server.
Workload management routing
Workload management
(WLM) propagates the following classes or types of routing information:
- Routing information for enterprise bean Internet Inter-ORB Protocol (IIOP)
traffic.
- Routing information for the default IBM Java Messaging Service (JMS) provider,
which is also referred to as the messaging engine.
WLM uses the high availability manager to both propagate the routing
information and make it highly available. Although WLM routing information
normally applies to clustered resources, it can also apply to non-clustered
resources, such as standalone messaging engines. Under normal circumstances,
you must leave the high availability manager enabled on any application server
that produces or consumes either IIOP or messaging engine routing information.
For example if:
- The routing information producer is an enterprise bean application that
resides in cluster 1.
- The routing information consumer is a servlet that resides in cluster
2.
When the servlet in cluster 2 calls the enterprise bean application
in cluster 1, the high availability manager must be enabled on all servers
in both clusters.
On-demand configuration routing
In
a Network Deployment system, the on-demand configuration is used for both
proxy server and Web services routing. The high availability manager must
be enabled on all processes to which the proxy server routes work, and on
all processes that are running Web services.
Best practices
Although not required, core groups
are usually homogeneous. If you have a large installation and you need to
set up a mix of processes that do and do not use the high availability manager,
you can:
- Create a new core group and move all application servers on which the
high availability manager is disabled to this core group. A core group that
contains only application servers on which the high availability manager is
disabled does not have to contain an administrative process and have no restrictions
on how large such a core group can become.
- Leave the remaining applications servers that require high availability
manager services in the default core group. You can create additional core
groups for some of the application servers that require the high availability
manager if the default core group becomes too large.