Clustering is a WebSphere MQ feature that is often confusing for many users. I’d like to provide some guidelines you can follow to ensure the optimum health for your cluster. Here’s a list of Ten Tips for MQ Clustering:
- Don’t issue refresh command unless absolutely necessary.
The REFRESH CLUSTER command can cause temporary disruption to traffic as it clears out the local cache. It is not a command that should be issued on a routine basis.
- Have 2 Full Repositories (no more, no less).
When updates are made within a cluster, two messages are sent for repositories.
- Stay current on MQ maintenance.
There are numerous APARs associated with clustering, having the latest fixpacks applied ensures you don’t encounter errors that have already been identified.
- If upgrading MQ, it is recommended that Full Repositories should be upgraded first.
Clusters can contain mixed versions of MQ software, but when developing your migration strategy plan to upgrade the full repositories to latest MQ versions first.
There are some issues with upgrading to V7 if the other qmgrs are not yet at fixpack 18.104.22.168 (refer to previous tip about applying latest maintenance).
- If you want to distribute workload, be sure applications are not doing bind on open.
For round robin to work, the queue should specify the parameter DEFBIND(NOTFIXED) and the queue should be opened with the option MQOO_BIND_NOT_FIXED. Note that round robin does not mean the workload will always be distributed on a one-to-one ratio. There is an internal algorithm which determines how messages are put within a cluster.
- Both Full Repositories should be at the same level of MQ software.
If full repositories are not at the same level, they may be unable to fully communicate necessary updates for features found in the newer version. There are different subscription attributes between V6 and V7 which are held in the cluster repository. Having both full repositories at the same version provides for better communication to ensure repository caches are up-to-date.
- Only define one channel from each QMGR to a Full Repository.
Allow the channel to the other Full Repository to be automatically self-defined internally by MQ.
- Be sure you do not have "temporary" queue manager names.
If a "display clusqmgr(*)" command shows SYSTEM.TEMPUUID* output for a queue manager name, that is indicative of a communication problem between the queue manager and the full repository.
- Name channels so they are unique and identify the queue manager they service.
If you might have overlapping cluster, you may want to name the cluster channel names to have both cluster and queue manager name (ex: TO.CLUSA.QMGR1)
- Consider a dedicated server for full repository queue manager.
If you have your full repositories located on a queue manager that does not have applications connecting, you can schedule software updates, etc. without necessitating application outage.