When to disable a high availability manager
Disabling the high availability manager frees CPU cycles, heap memory, and sockets. For large core groups, the amount of resources freed can be significant.
- Do not disable high availability manager if we are using memory to memory session replication, or remote request dispatcher (RRD).
- 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.
The capability to disable the high availability manager is most useful for 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, we can disable the high availability manager on a per-process basis, which optimizes the amount of resources that the high availability manager uses.
Some of the services that the high availability manager provides are cluster-based. Therefore, because cluster members must be homogeneous, if we disable the high availability manager on one member of a cluster, we must disable it on all of the other members of that cluster.
Many internal components employ the high availability manager infrastructure or rely on internal services that employ the high availability manager. Therefore, the high availability manager services listed are not necessarily an all-inclusive list of services affected by disabling the high availability manager. Also, the list is subject to change because more services can change to use the high availability manager at anytime..
Instead of disabling the high availability manager, either create multiple cells or partition the cell into multiple core groups and create bridges. Even if we do not currently use a component that requires the high availability manager, we might require one at a later time.bprac
Memory-to-memory replication
Memory-to-memory replication is a cluster-based service that we 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:
- Memory-to-memory replication is enabled for web container HTTP sessions.
- Cache replication is enabled for the dynamic cache service.
- EJB stateful session bean failover is enabled for an application server.
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 messaging provider are configured to run in the cluster. The default messaging provider provided with WebSphere Application Server is also referred to as the service integration bus.
Workload management
Workload management (WLM) propagates the following routing information:
- Default messaging engine (service integration bus).
- HTTP requests through the IBM WAS proxy server.
- Web Services Addressing requests through the IBM WAS proxy server.
- Session Initiation Protocol (SIP) requests.
- Enterprise bean IIOP traffic. (iSeries)
Typically, we 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 producer is an enterprise bean application residing in cluster 1.
- The routing consumer is a servlet residing 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. Workload management Beans ClusterMgr and Cluster might return basic information about a cluster. However, if the high availability manager is disabled in any part of our topology, we cannot modify the current settings and have the modifications propagated to all cluster members.
Workload management provides an option to statically build and export route tables to the file system, eliminating the dependency on the high availability manager.
A proxy server cluster does not have all of the same functionality an application server cluster has. For example, because there is no data replication among members of a proxy cluster, failover between proxy servers in the cluster is not supported. If a proxy server is down, all active connections owned by the proxy server go away and then incoming requests fail. However, both proxy servers and proxy clusters support the high availability and failover of backend servers, such that the proxy server can detect if a backend server is down and then forward the requests to a server with the session replicated.
Example output:
myCluster1(cells/mycell/clusters/myCluster1|cluster.xml#ServerCluster_1)
Related:
Core groups Core group scaling Disable or enable a high availability manager Enable static routing for a cluster Configure transaction properties for peer recovery Use the dynamic cache service Enable or disable stateful session bean failover with the EJB container panel Distributed environment settings