This example describes how to create a cluster solution with a server complex (cluster QMC) and a fault tolerant input system which utilize simple workload balancing.
This setup is based on seven WebSphere MQ queue managers, which is divided into 4 clusters for maximum security, so it will be difficult to send data the wrong way in the clusters.
QM1 and QM3 acts as "gateway" QueueManagers, and they are hosting full repositories for all four clusters.
QM2 and QM4 acts as server QueueManagers hosting the server queue QMQ, which offers workload balancing (default based on round robin).
QM7, QM8 and QM9 acts as application QueueManagers hosting some "client" applications, which requires an answer from the servers. This might be Web-servers hosting dot-something. This means that QM7-9 must be able to send messages to QMQ on QM2 and QM4. This is done using QMQ.GLOBAL which is defined as an QALIAS on QM1 and QM3. QMQ.GLOBAL is published using a namelist(BIGCLUSTER) which contains all clusters (QMC, QM7C, QM8C and QM9C). All QALIAS' are defined DEFBIND(NOTFIXED), otherwise this configuration won't work. This makes it possible for all Queue Managers to send messages to QMQ.GLOBAL.
When an answer is returned from the servers QM2 and QM3 the are using the names for example QM7Q.GLOBAL refers to QMQ7 on QM7. QMQ7.GLOBAL is defined on QM1 and QM3 with with CLUSTER(QMC) which means that QMQ7.GLOBAL can be used from cluster QMC only. This means that QM8 and QM9 cannot send messages to QMQ7.GLOBAL.
If you click on the different QueueManagers you will see the configuration of them, queues, channels and so, all presented by MQ-Inventory®. Complete overview of the QMC-cluster.
Download the full stanza for the configuration here.
The following are trademarks of
International Business Machines Corporation:
IBM, MERVA, MQSeries, WebSphere, WFNI, Object REXX