Application servers running on WebSphere® Application Server 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.
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 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 following
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.
- 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 following 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 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.
- 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.