WAS cloning and WebSphere MQ clustering
Overview
The message listener service can be configured to take advantage of WebSphere MQ server clustering.
WebSphere MQ server clustering is only available with the full WebSphere MQ product installed as a JMS provider.
In this example, the listener configurations are the same for each WebSphere appserver. Each JMS listener is used to retrieve messages from a destination defined to the server.
Each appserver host contains a WebSphere appserver and an WebSphere MQ server.
If a host is only used to distribute messages, it only contains an WebSphere MQ server. There can be many servers defined in the configuration, although for simplicity the information in this topic is based on a scenario containing only three servers as shown in the following figure:
There are three hosts...
- Server host S1...
- WebSphere MQ server.
-
The server is defined to have a queue manager, QM1, and a local queue, Q1. The queue manager belongs to a cluster. The queue is populated by the WebSphere MQ server located on host M3. Applications can add messages directly to the queue, Q1, but would not be subjected to the control of the WebSphere MQ cluster.
- WAS
-
Cloned appserver, WAS1, configured with a JMS listener. The listener is configured to retrieve messages from JMS destination Q1.
- Server host S2
- WebSphere MQ server.
-
The server is defined to have a queue manager, QM2, and a local queue, Q1. The queue manager belongs to the same cluster as QM1 on host S1. As with QM1, the queue is populated by the WebSphere MQ server located on host M3. Applications can add messages directly to the queue, Q1, but would not be subjected to the control of the MQ cluster.
- WAS
-
Cloned appserver, WAS2 (identical to WAS1 on host S1), configured with a JMS listener. The listener is configured to retrieve messages from JMS destination Q1.
- Messaging host M3
- WebSphere MQ server.
-
The server is defined to have a queue manager, QM3, which also belongs to the same cluster as QM1 and QM2. Applications add messages to the queue manager and queue Q1. The cluster to which this queue manager belongs causes messages to be distributed to all other queue managers in the cluster which have queue Q1 defined.
Queue Q1 is not defined as a local queue on this host. If the queue was defined locally, then messages would remain on the server for local processing; messages would not be distributed by the queue manager cluster control to the other queue managers in the cluster that do have the queue defined.
This host does not have a WebSphere appserver defined. All message retrieval processing is performed by the other two appservers on hosts S1 and S2.
Recovery scenarios
There are several failure scenarios that could occur with the clustering configuration; for example:
- WAS server failures.
The failure of any single WebSphere appserver results in the messages for the specified destination remaining on the queue, until the server is restarted.
- WebSphere MQ Queue Manager failures.There are two different failures to consider:
- Failure of a queue manager on the same host as a WebSphere appserver (for example, failure of QM2 on host S2). In this case messages are delivered to the other available appservers, until the WebSphere
MQ server is back online, when messages are processed as expected.
- Failure of the messaging host M3 and its queue manager, QM3. In this case, the result of an outage is more significant because no messages are delivered to the other queue managers in the cluster. In a fully-deployed and scaled production system, host M3 would not be designed to be a single point of failure, and additional messaging servers would be added to the cluster configuration.
- Failure of a queue manager on the same host as a WebSphere appserver (for example, failure of QM2 on host S2). In this case messages are delivered to the other available appservers, until the WebSphere
MQ server is back online, when messages are processed as expected.
Related tasks
Learning about messaging with WAS