Configuring workload balancing from outside a cluster

Configure a message path from a queue manager outside a cluster to any copy of a cluster queue. The result is to workload balance requests from outside the cluster to each instance of a cluster queue.

Before you begin

Configure the example, as shown in Figure 1 in Configuring request/reply to a cluster.

About this task

In this scenario, the queue manager outside the cluster, QM3 in Figure 1, sends requests to the queue Q2. Q2 is hosted on two queue managers, QM2 and QM4 within cluster DEMO. Both queue managers are configured with a default bind option of NOTFIXED in order to use workload balancing. The requests from QM3, the queue manager outside the cluster, are sent to either instance of Q2 through QM1.

QM3 is not part of a cluster and communicates using distributed queuing techniques. It must have a sender-channel and a transmission queue to QM1. QM1 needs a corresponding receiver-channel. The channels and transmission queues are not shown explicitly in Figure 1.

The procedure extends the example in Figure 1 in Configuring request/reply to a cluster.

Procedure

Create a QREMOTE definition for Q2 on QM3.
```
DEFINE QREMOTE(Q2) RNAME(Q2) RQMNAME(Q3) XMITQ(QM1)
```
Create a QREMOTE definition for each queue in the cluster that QM3 puts messages to.
Create a queue manager alias Q3 on QM1.
```
DEFINE QREMOTE(Q3) RNAME(' ') RQMNAME(' ')
```
Q3 is not a real queue manager name. It is the name of a queue manager alias definition in the cluster that equates the queue manager alias name Q3 with blank, ' '

Define a local queue called Q2 on each of QM2 and QM4.

DEFINE QLOCAL(Q2) CLUSTER(DEMO) DEFBIND(NOTFIXED)

QM1, the gateway queue manager, has no special definitions.

Results

This diagram shows three connected queue managers inside a cluster, QM1, QM2, and QM4. QM1 is connected to a queue manager outside of the cluster, QM3. QM2 and QM4 each have a queue, Q2, and a remote queue, Q3. — Figure 1. Putting from a queue manager outside the cluster

When an application at QM3 issues an MQPUT call to put a message to Q2, the QREMOTE definition on QM3 causes the message to be routed through the gateway queue manager QM1. When QM1 receives the message, it is aware that the message is still intended for a queue named Q2 and performs name resolution. QM1 checks its local definitions and does not find any for Q2. QM1 then checks its cluster configuration and finds that it is aware of two instances of Q2 in cluster DEMO. QM1 can now make use of workload balancing to distribute messages between the instances of Q2 residing on QM2 and QM4.