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

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

Note: In this topic "application server" refers to an application server that is running on WebSphere Application Server and "queue manager" refers to a queue manager that is running on IBM 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 WebSphere Application Server 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 that is 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
WebSphere Application Server application servers 1 and 3 are running on Host 1. WebSphere Application Server application server 2 is running on Host 2. A IBM MQ queue manager is running on Host 3.
  • 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.

You 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 WebSphere Application Server 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 that is 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 that is 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.
Note: For application servers that are running on the same host as a queue manager, the IBM 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
WebSphere Application Server application server 1, application server 3, and a IBM MQ queue manager are running on Host 1. WebSphere Application Server application server 2 is running on Host 2.
  • 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.

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: March 5, 2017 17:24
File name: cmm_mq_top02_semiclustered1.html