Home
MQ clusters - Things to consider
The WebSphere MQ Explorer cannot directly administer WebSphere MQ for z/OS queue managers at versions earlier than version 6.
To get the most out of clusters, all the queue managers in the network must be on a platform that supports clusters. Until all your systems are on platforms that support clusters, you might have queue managers outside a cluster that cannot access your cluster queues without extra manual definitions.
If you merge two clusters with the same name, we cannot separate them again. Therefore it is advisable to give all clusters a unique name.
If a message arrives at a queue manager but there is no queue there to receive it, the message is put on the dead-letter queue as usual. (If there is no dead-letter queue, the channel fails and retries, as described in the WebSphere MQ Intercommunication book.)
The integrity of persistent messages is maintained. Messages are not duplicated or lost as a result of using clusters.
Using clusters reduces system administration. Clusters make it easy to connect larger networks with many more queue managers than you would be able to contemplate using distributed queuing. However, as with distributed queuing, there is a risk that you may consume excessive network resources if you attempt to enable communication between every queue manager in a cluster.
If you use the WebSphere MQ Explorer, which presents the queue managers in a tree structure, the view for large clusters may be cumbersome.
The Explorer GUI can administer a cluster with repository queue managers on WebSphere MQ for z/OS V6, without the need for nominating an additional repository on a separate system. For earlier versions of WebSphere MQ on z/OS, the WebSphere MQ Explorer cannot administer a cluster with repository queue managers. You must therefore nominate an additional repository on a system that the WebSphere MQ Explorer can administer.
The purpose of distribution lists, which are supported on WebSphere MQ for AIX, iSeries, HP-UX, Solaris, Linux, and Windows and MQSeries for Compaq Tru64 UNIX, Compaq NonStop Kernel, and HP OpenVMS, V5.1, is to use a single MQPUT command to send the same message to multiple destinations. We can use distribution lists in conjunction with queue manager clusters. However, in a clustering environment all the messages are expanded at MQPUT time and so the advantage, in terms of network traffic, is not so great as in a non-clustering environment. The advantage of distribution lists, from the administrator’s point of view, is that the numerous channels and transmission queues do not need to be defined manually.
If you are going to use clusters to balance your workload, examine your applications to see whether they require messages to be processed by a particular queue manager or in a particular sequence. Such applications are said to have message affinities. You might need to modify your applications before we can use them in complex clusters.
If you use the MQOO_BIND_ON_OPEN option on an MQOPEN call to force messages to be sent to a specific destination, and the destination queue manager is not available, the messages are not delivered. Messages are not routed to another queue manager because of the risk of duplication.
If a queue manager is to host a cluster's repository, we need to know its host name or IP address. You have to specify this information in the CONNAME parameter when you make the CLUSSDR definition on other queue managers joining the cluster. If you were to use DHCP, the IP address would be subject to change because DHCP can allocate a new IP address each time you restart a system. Therefore, it would not be possible to specify the IP address in the CLUSSDR definitions. Even if all your CLUSSDR definitions specified the hostname rather than the IP address, the definitions would still not be reliable. This is because DHCP does not necessarily update the DNS directory entry for the host with the new address.
Unless you have installed software that guarantees to keep your DNS directory up-to-date, you should not nominate queue managers as full repositories if they are on systems that use DHCP.
Do not use generic names, for example VTAM generic resources or Dynamic Domain Name Server (DDNS) generic names as the connection names for your channels. If you do, your channels might connect to a different queue manager than expected.
We can only GET from a local cluster queue, but we can PUT to any queue in a cluster. If you open a queue to use the MQGET command, the queue manager will only use the local queue.
Parent topic:
Concepts and terminologyHome