WAS v8.5 > WebSphere applications > Messaging resources > Interoperation with WebSphere MQ > Interoperation using the WebSphere MQ messaging provider > Network topologies: Interoperating using the WebSphere MQ messaging provider
Interoperation when WAS application servers are clustered and WebSphere MQ queue managers are clustered
WebSphere MQ queue managers are usually clustered in order to distribute the message workload and because, if one queue manager fails, the others can continue running.
In this topic "application server" refers to an application server that is running on WAS and "queue manager" refers to a queue manager that is running on WebSphere MQ.
There are two topology options:
- The queue managers run on different hosts from the application servers
- The queue managers run on the same hosts as the application servers
The queue managers run on different hosts from 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 managers 1, 2 and 3 are part of the same WebSphere MQ cluster.
- Queue manager 1 is running on Host 3.
- Queue manager 2 is running on Host 4.
- Queue manager 3 is running on Host 5.
- Queue manager 3 is responsible for distributing messages between the cluster queues in a way that achieves workload balancing.
- 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 and 2 attach in client mode to queue manager 1.
- Application server 3 attaches in client mode to queue manager 2.
Figure 1. clustering: client mode attachment to queue managers
- If application server 1 fails:
- Application server 2 can take over its workload because they are both attached to queue manager 1.
- If application server 2 fails:
- Application server 1 can take over its workload because they are both attached to queue manager 1.
- If application server 3 fails:
- Restart it as soon as possible for the following reasons:
- Other application servers in the cluster can take over its external workload, but no other application server can take over its WebSphere MQ workload, because no other application server is attached to queue manager 2. The workload that was generated by application server 3 ceases.
- Queue manager 3 continues to distribute work between queue manager 1 and queue manager 2, even though the workload arriving at queue manager 2 cannot be processed by application server 1 or 2.
If you choose not to restart, we can alleviate this situation by manually configuring Q1 on queue manager 2 so the ability to put messages to it is inhibited. This results in all messages being sent to queue manager 1 where they are processed by the other application servers.
- If queue manager 1 fails:
- You should restart it as soon as possible for the following reasons:
- Messages that are on queue manager 1 when it fails are not processed until you restart queue manager 1.
- No new messages from WebSphere MQ applications are sent to queue manager 1, instead new messages are sent to queue manager 2 and consumed by application server 3.
- Because application servers 1 and 2 are not attached to queue manager 2, they cannot take on any of its workload.
- Because application servers 1, 2 and 3 are in the same WAS cluster, their non-WebSphere MQ workload continues to be distributed between them all, even though application servers 1 and 2 cannot use WebSphere MQ because queue manager 1 has failed.
Although this networking topology can provide availability and scalability, the relationship between the workload on different queue managers and the application servers to which they are connected is complex. We can contact your IBM representative to obtain expert advice.
The queue managers run on the same hosts as the application servers
In the subsequent figure:
- Application severs 1, 2 and 3 are part of the same WAS cluster.
- Application servers 1 and 3 are running on Host 1.
- Application server 2 is running on Host 2.
- Queue managers 1, 2 and 3 are part of the same WebSphere MQ cluster.
- Queue manager 1 is running on Host 1.
- Queue manager 2 is running on Host 2.
- Queue manager 3 is running on Host 3.
- Queue manager 3 is responsible for distributing messages between the cluster queues in a way that achieves workload balancing.
- 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 attach to queue manager 1 in bindings mode.
- Application server 2 attaches to queue manager 2 in bindings mode.
Figure 2. clustering: bindings mode attachment to queue managers
- If application server 1 fails:
- Application server 3 can take over its workload because they are both attached to queue manager 1.
- If application server 3 fails:
- Application server 1 can take over its workload because they are both attached to queue manager 1.
- If application server 2 fails:
- Restart it as soon as possible for the following reasons:
- Because no other application server is attached to queue manager 2 no other application server can take over its WebSphere MQ workload. The workload that was generated by application server 2 ceases. Other application servers in the cluster can, however, take over its external workload
- Queue manager 3 continues to distribute work between queue manager 1 and queue manager 2, even though the workload arriving at queue
manager 2 cannot be taken on by application server 2.
If you choose not to restart, we can alleviate this situation by manually configuring Q1 on queue manager 2 so the ability to put messages to it is inhibited. This results in all messages being sent to queue manager 1 where they are processed by the other application servers.
- If queue manager 1 fails:
- Restart it as soon as possible for the following reasons:
- Messages that are on queue manager 1 when it fails are not processed until you restart queue manager 1.
- Because application servers 1 and 3 are not attached to queue manager 2, they cannot take on any of its workload.
- No new messages from WebSphere MQ applications are sent to queue manager 1, instead new messages are sent to queue manager 2 and consumed by application server 2.
- Because application servers 1, 2 and 3 are in the same WAS cluster, their non-WebSphere MQ workload continues to be distributed between them all, even though application servers 1 and 3 cannot use WebSphere MQ because queue manager 1 has failed.
Although this networking topology can provide availability and scalability, the relationship between the workload on different queue managers and the application servers with which they are connected is complex. We can contact your IBM representative to obtain expert advice.