+

Search Tips   |   Advanced Search

When to use a high availability manager

A high availability (HA) manager consumes valuable system resources, such as CPU cycles, heap memory, and sockets. These resources are consumed both by the HA manager, and by product components that use the services that the HA manager provides. The amount of resources that both the HA manager and these product components consume increases nonlinearly as the size of a core group increases.

For large core groups, the amount of resources that the HA manager consumes can become significant. Disabling the HA manager frees these resources. However, before disabling the HA manager, you should thoroughly investigate the current and future needs of the system to ensure that disabling the HA manager does not also disable other functions that you use that require the HA manager. For example, both memory to memory session replication, and remote request dispatcher (RRD) require the HA manager to be enabled.

The capability to disable the HA manager is most useful for topologies where none of the HA manager provided services are used. In certain topologies, only some of the processes use the services that the HA manager provides. In these topologies, we can disable the HA manager on a per-process basis, which optimizes the amount of resources that the HA manager uses.

Do not disable the HA manager on administrative processes, such as node agents and the deployment manager, unless the HA manager is disabled on all application server processes in that core group.

Some of the services that the HA manager provides are cluster-based. Therefore, because cluster members must be homogeneous, if you disable the HA manager on one member of a cluster, you must disable it on all of the other members of that cluster.

Leave HA manager enabled on a given application server process if the process requires any of the following HA manager services:

Avoid trouble: Many internal components employ the HA manager infrastructure or rely on internal services that employ the HA manager. Therefore, the HA manager services listed are not necessarily an all-inclusive list of services affected by disabling the HA manager. Also, the list is subject to change because more services can change to use the HA manager at anytime. gotcha


Best practice

Instead of disabling the HA 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 HA manager, you might require one at a later time.bprac


Memory-to-memory replication

Memory-to-memory replication is a cluster-based service configured or enable at the application server level. If memory-to-memory replication is enabled on any cluster member, then the HA 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 HA manager must be enabled on all members of a cluster if:


Workload management

Workload management (WLM) propagates the following classes or types of routing information:

WLM uses the HA manager to both propagate the routing information and make it highly available. Although WLM routing information typically applies to clustered resources, it can also apply to non-clustered resources, such as stand-alone messaging engines. Typically, you must leave the HA manager enabled on any application server that produces or consumes either IIOP or messaging engine routing information.

For example, if:

When the servlet in cluster 2 calls the enterprise bean application in cluster 1, the HA manager must be enabled on all servers in both clusters.

Workload management MBeans ClusterMgr and Cluster might return basic information about a cluster. However, if the HA manager is disabled in any part of the 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. Use this option to eliminate the dependency on the high availability manager.

Avoid trouble: A proxy server cluster does not have all of the same functionality that 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 that has the session replicated.

Example output:


Related concepts

Core groups (high availability domains)
  • Core group scaling considerations
  • 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