Redpaper - IBM Redbooks

Advantages Disadvantages
Uses the available resources because
WebSphere MQ clustering can direct
messages across all available LPARS.
Takes advantage of cloned applications
and identically configured brokers by
workload balancing, thus reducing the risk
of bottlenecks.
2.3.2 WebSphere MQ shared queues
Gateway queue managers can act as a
single point of failure for the entire
WebSphere MQ cluster.
Multi-part messages and transactions can
cause affinities to particular queue
managers, thus reducing the availability of
the system.
Should Message Broker fail and the queue
manager is still functional, the WebSphere
MQ cluster continues to send messages
to that queue manager even though they
are not processed.
Now that we have examined the issues in using WebSphere MQ clustering to
support HA, this section discusses WebSphere MQ shared queues. Shared
queues rely heavily on the coupling facility and a shared DB2 database to allow
queue managers to form a queue sharing group (QSG). Once the queue
managers have configured the QSG, they can create queues that are available
to all the queue managers in the group.
This functionality sounds very similar to WebSphere MQ clustering and, in many
respects, there is a certain amount of overlap in the service shared queues
provide. However, a shared queue is one instance of a queue which is “shared”
among a number of queue managers. This method differs from WebSphere MQ
clustering in that the clustered queues, despite having the same designation, are
actually separate entities. In practice, once a shared queue has been configured
allowing a number of queue managers to access it, all of the brokers associated
with those queue managers (or any application) could have access to that queue,
despite existing on separate LPARs.
A simple scenario which uses shared queues might resemble the following. A
sending application puts messages to a shared queue. These messages are
then available to all queue managers in the QSG across all relevant LPARs.
Associated with these queue managers are brokers, all of which are retrieving
messages from the same shared queue. Should an LPAR, queue manager, or a
broker fall over, the other brokers would continue retrieving and processing
messages from the shared queue.
Because cloned applications and the broker which serve them are able to a
connect to queue managers in a QSG and because all queue managers in a
QSG can access shared queues, applications do not need to rely on the
14 High Availability z/OS Solutions for WebSphere Business Integration Message Broker V5