Interoperation when WebSphere Application Server application servers are clustered but WebSphere MQ queue manager is not clustered

Application servers running on WAS can be clustered together and connected to queue managers running onWebSphere MQ that are not clustered. This setup provides enhanced failover protection over non-clustered topologies.

In this topic "application server" refers to an application server running on WebSphere Application Server and "queue manager" refers to a queue manager running on WebSphere MQ.

There are two topology options:

• The application servers run on several hosts, one of which hosts a queue manager

• The queue manager runs on a different host from any of the application servers

The queue manager runs on a different host from any of the application servers

In the subsequent figure:

• Application server 1, 2 and 3 are clustered in a WAS cluster.

• Application servers 1 and 3 are running on Host 1

• Application server 2 is running on Host 2

• Queue manager is running on Host 3

• A "client" connection is used when the application server and queue manager are running on different hosts. This is a TCP/IP network connection used to communicate with the queue manager. A client connection is also known as "socket attach".

  • Application servers 1, 2 and 3 are connected to queue manager in client mode.

Figure 1. WebSphere Application Server clustering: client mode attachment to queue manager

• If any clustered application server fails, or the host on which it is running fails, the remaining application servers in the cluster can take over its workload.

• If the queue manager fails, or the host on which it is running fails, interoperation ceases.

We can improve availability for this topology by using, for example, High Availability Cluster Multi-Processing HACMP™ to restart the failed queue manager automatically.

The application servers run on several hosts, one of which hosts a queue manager

The following figure shows some application servers that are running on the same host as the queue manager. Other application servers in the same WebSphere Application Server cluster run on a different host.

In the subsequent figure:

• Application server 1, 2 and 3 are clustered in a WAS cluster.

• Application servers 1 and 3 are running on Host 1.

• Application server 2 is running on Host 2.

• Queue manager is running on Host 1.

• The transport type for the connection is specified as "bindings". A "bindings" connection is used when the application server and the queue manager are running on the same host. This is a cross-memory connection used to communicate with a queue manager. A bindings connection is also known as "call attach".

  • Application servers 1, and 3 are connected to queue manager in bindings mode.

• A "client" connection is used when the application server and queue manager are running on different hosts. This is a TCP/IP network connection used to communicate with the queue manager. A client connection is also known as "socket attach".

  • Application server 2 is connected to queue manager in client mode.

For application servers that are running on the same host as a queue manager, the WebSphere MQ transport type for the connection is specified as "bindings then client" mode, that is, if an attempt at a bindings mode connection to the queue manager fails, a client mode connection is made. For application servers that are not running on the same host as the queue manager, the application server automatically uses client mode.

Figure 2. WebSphere Application Server clustering: bindings then client mode attachment to queue manager

• If one of the application servers fails, the remaining application servers in the cluster can take over its workload.

• If host 2 fails, application server 2 will stop. Application servers 1 and 3 can take over its workload.

• If the queue manager fails inter-operation ceases.

• If host 1 fails the queue manager, application server 1 and application server 3 will stop. Inter-operation will cease.