Using IBM MQ cluster queues for input and output
Design your integration node network to use IBM® MQ queues, if appropriate for your business needs.
About this task
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 IBM Integration Bus, consider the following queues:
- For SYSTEM.BROKER queues:
- The SYSTEM.BROKER queues are defined for you when you create IBM Integration Bus components, and are not defined as cluster queues. Do not change this attribute.
- 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 IBM 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 integration node.
- For message flow output queues:
- IBM Integration Bus 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 in 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 integration nodes on queue managers in the cluster. However, the cluster does not provide any of the failover function to the integration node network and function. If an integration node 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 integration node.
- When a client registers a subscription with an integration node that is running on a queue manager that is a member of a cluster, the integration node forwards a proxy registration to its neighbors in the integration node 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
a particular publication. In this case, when registering a subscription,
use the name of an "imaginary" queue manager that is associated with
the cluster; this queue manager is not the one to which the publication
is sent, but an alias for the integration node to use. As an administrative
activity, a blank queue manager alias definition is made for this
queue manager on the integration node that satisfies this subscription for all
clustered subscribers. When the integration node 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 integration node definition is:
DEFINE QREMOTE(CLUSTER_QM) RQMNAME(' ') RNAME(' ')
This configuration sends integration node publications for SUBS_QUEUE on CLUSTER_QM to one instance of the cluster queue named SUBS_QUEUE anywhere in the cluster.