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.
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 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 WebSphere Application Server 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 that is 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.
- 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:
- You must 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.
Note: If you choose not to restart, you can alleviate this situation
by manually configuring Q1 on queue manager 2 so that 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 WebSphere Application Server 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. You 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 WebSphere Application Server 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 that is 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.
- 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:
- You must restart it as soon as possible for the following reasons:
- If queue manager 1 fails:
- You must 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 WebSphere Application Server 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. You can contact your IBM representative
to obtain expert advice.