High Availability Manager- IBM Websphere Application Server

Understanding High Availability Manager

High availability manager

WebSphere Application Server includes a high availability manager component. The services that the high availability manager provides are only available to WebSphere Application Server components.

A high availability manager provides several features that allow other WebSphere Application Server components to make themselves highly available. A high availability manager provides:

• A framework that allows singleton services to make themselves highly available. Examples of singleton services that use this framework include the transaction managers for cluster members, and the default IBM messaging provider, commonly referred to as a messaging engine.
• A mechanism that allows servers to easily exchange state data. This mechanism is commonly referred to as the bulletin board.
• A specialized framework for high speed and reliable messaging between processes. This framework is used by the data replication service when WebSphere Application Server is configured for memory-to-memory replication.

A high availability manager instance runs on every application server, proxy server, node agent and deployment manager in a cell. A cell can be divided into multiple high availability domains known as core groups. Each high availability manager instance establishes network connectivity with all other high availability manager instances in the same core group, using a specialized, dedicated, and configurable transport channel. The transport channel provides mechanisms which allow the high availability manager instance to detect when other members of the core group start, stop, or fail.

Within a core group, high availability manager instances are elected to coordinate high availability activities. An instance that is elected is known as a core group coordinator. The coordinator is highly available, such that if a process that is serving as a coordinator stops or fails, another instance is elected to assume the coordinator role, without loss of continuity.

Highly available components

A highly available component is a component for which a high availability group is defined on the processes where that component can run. The coordinator tracks high availability group membership, and knows on which processes each highly available component can run.

The coordinator also associates a high availability policy with each high availability group. A high availability policy is a set of directives that aid the coordinator in managing highly available components. For example, a directive might specify that a component runs on a specific process, if that process is available. Directives are configurable, which makes it possible for you to tailor policies to your installation.

The coordinator is notified as core group processes start, stop or fail and knows which processes are available at any given time. The coordinator uses this information, in conjunction with the high availability group and policy information, to ensure that the component keeps functioning. The coordinator uses the policy directives to determine on which process it starts and runs each component. If the chosen process fails, the coordinator restarts the component on another eligible process. This reduces the recovery time, automates failover, and eliminates the need to start a replacement process.

State data exchange

The high availability manager provides a specialized messaging mechanism that enables processes to exchange information about their current state. Each process sends or posts information related to its current state, and can register to be notified when the state of the other processes changes. The Work Load Management (WLM) component uses this mechanism to build and maintain routing table information. Routing tables built and maintained using this mechanism are highly available.

Replication

WebSphere Application Server provides a data replication service (DRS) that is used to replicate HTTP session data, stateful EJB sessions, and dynamic cache information among cluster members. When DRS is configured for memory-to-memory replication, the transport channels defined for the high availability managers are used to pass this data among the cluster members.

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 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. 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 your 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 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:

• Memory-to-memory replication is enabled for Web container HTTP sessions. See Distributed environment settings for more information.
• Cache replication is enabled for the dynamic cache service. See Enabling the dynamic cache service for more information.
• EJB stateful session bean failover is enabled for an application server. See Enabling or disabling stateful session bean failover with the EJB container panel for more information.

Singleton failover

Singleton failover is a cluster-based service. The high availability manager must be enabled on all members of a cluster if 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.

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. See Enabling static routing for a cluster for more information about the Export route table option.

On-demand configuration routing

In a Network Deployment system, the on-demand configuration is used for proxy server routing. If you want to use on-demand configuration routing in conjunction with your Web services, you must make sure that the high availability manager is enabled on the proxy server and on all of the servers to which the proxy server will route work.