The use of queue manager clusters
has the following significant benefits:
- Reduced system administration
Clusters need fewer definitions
to establish a network; you can set up and change your network more
quickly and easily.
- Increased availability and workload balancing
You can benefit
by defining instances of the same queue to more than one queue manager,
therefore distributing the workload through the cluster.
If you use clusters with WebSphere Message
Broker,
consider the following queues:
- For SYSTEM.BROKER queues:
- The SYSTEM.BROKER queues are defined for you when you create WebSphere Message
Broker components, and are not defined
as cluster queues. Do not change this attribute.
- For broker, Configuration
Manager, and User Name Server connectivity:
- If you define the queue managers that support your brokers, the Configuration
Manager, and the User Name Server to a cluster, you can benefit
from the simplified administration provided by WebSphere MQ clusters. You might find this
particularly relevant for the brokers in a collective, which must
all have WebSphere MQ interconnections.
- For message flow input queues:
- If you define an input queue as a cluster queue, consider the
implications for the order of messages or the segments of a segmented
message. The implications are the same as for any WebSphere MQ cluster queue. In particular,
the application must ensure that, if it is sending segmented messages,
all segments are processed by the same target queue, and therefore
by the same instance of the message flow at the same broker.
- For message flow output queues:
-
- WebSphere Message
Broker always specifies MQOO_BIND_AS_Q_DEF
when it opens a queue for output. If you expect segmented messages
to be put to an output queue, or want a series of messages to be handled
by the same process, you must specify DEFBIND(OPEN) when you define
that queue. This option ensures that all segments of a single message,
or all messages within a sequence, are put to the same target queue
and are processed by the same instance of the receiving application.
- If you create your own output nodes, specify MQOO_BIND_AS_Q_DEF
when you open the output queue, and DEFBIND(OPEN) when you define
the queue, if you need to ensure message order, or to ensure a single
target for segmented messages.
- For publish/subscribe applications:
-
- If the target queue for a publication is a cluster queue, you
must deploy the publish/subscribe message
flow to all the brokers on queue managers in the cluster. However,
the cluster does not provide any of the failover function to the broker
domain topology and function. If a broker to which a message is published,
or a subscriber registers, is unavailable, the distribution of the
publication or registration is not taken over by another broker.
- When a client registers a subscription with a broker that is running
on a queue manager that is a member of a cluster, the broker forwards
a proxy registration to its neighbors within the broker domain; the
registration details are not advertised to other members of the cluster.
- A client might choose to become a clustered subscriber, so that
its subscriber queue is one of a set of clustered queues that receive
any given publication. In this case, when registering a subscription,
use the name of an "imaginary" queue manager that is associated with
the cluster; this is not the queue manager to which the publication
will be sent, but an alias for the broker to use. As an administrative
activity, a blank queue manager alias definition is made for this
queue manager on the broker that satisfies this subscription for all
clustered subscribers. When the broker publishes to a subscriber
queue that names this queue manager, resolution of the queue manager
name results in the publication being sent to any queue manager that
hosts the subscriber cluster queue, and only one clustered subscriber
receives the publication.
For example, if the clustered subscriber
queue was SUBS_QUEUE and the "imaginary" subscriber queue manager
was CLUSTER_QM, the broker definition would be:
DEFINE
QREMOTE(CLUSTER_QM) RQMNAME(' ') RNAME(' ')
This sends
broker publications for SUBS_QUEUE on CLUSTER_QM to one instance of
the cluster queue named SUBS_QUEUE anywhere in the cluster.
To understand more about clusters, and the implications
of using cluster queues, see the Queue Manager Clusters section
of the WebSphere MQ Version 6 information center
online,
or the Version 5.3 book on the WebSphere MQ
library Web page.