Things to consider

 

Consider the following before starting to use clusters:

  • If you merge two clusters with the same name, you 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 purpose of distribution lists is to use a single MQPUT command to send the same message to multiple destinations. You 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 you 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, you 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.

    Note:
    Unless you have installed software that guarantees to keep your DNS directory up-to-date, not nominate queue managers as full repositories if they are on systems that use DHCP.

  • Do not use generic names, for example VTAM(R) 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.

  • You can only GET from a local cluster queue, but you 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.

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.