Network Deployment (Distributed operating systems), v8.0 > Establishing high availability > High availability manager
When to use a high availability manager
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 product components that use the services that the high availability manager provides. The amount of resources that both the high availability 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 high availability manager consumes can become significant. Disabling the high availability manager frees these resources. However, before you disable the high availability manager, you should thoroughly investigate the current and future needs of the system to ensure that disabling the high availability manager does not also disable other functions that you use that require the high availability manager. For example, both memory to memory session replication, and remote request dispatcher (RRD) require the high availability manager to be enabled.
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, 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 dmgr, 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, disable it on all of the other members of that cluster.
When determining if 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:
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.
- Memory-to-memory replication
- Singleton failover
- Workload management routing
- On-demand configuration routing
Instead of disabling the high availability manager, either create multiple cells or partition the cell into multiple core groups and create bridges. Even if you do not currently use a component that requires the high availability manager, you might require one at a later time.
bprac
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:
- 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 the product is also referred to as the service integration bus.
Workload management routing
Workload management (WLM) propagates the following classes or types of routing information:
- Route information for enterprise bean IIOP traffic.
- Route information for the default messaging engine, which is also referred to as the service integration bus.
- Route HTTP requests through the IBM WAS proxy server.
- Route Web Services Addressing requests through the IBM WAS proxy server.
- Route SIP (SIP) requests.
WLM uses the high availability 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. During typical circumstances, 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.
Workload management provides an option to statically build and export route tables to the file system. Eliminate the dependency on the high availability manager.
On-demand configuration routing
In a WAS ND system, the on-demand configuration is used for IBM WAS proxy server routing. To use on-demand configuration routing in conjunction with your web services, verify that the high availability manager is enabled on the proxy server and on all of the servers to which the proxy server routes work.
Core groups (high availability domains)
Core group scaling considerations
High availability manager
Disable or enabling a high availability manager
Enable static routing for a cluster
Configure transaction properties for peer recovery
Use the dynamic cache service
Enable or disabling stateful session bean failover with the EJB container panel
Related
Distributed environment settings