Here’s an email question I received today and my response:
Does IBM have any write up for the advantage of using mq clustering vs non clustering setup? I am trying to get our application teams on board with using clustering. I was going to setup all our test servers in a test cluster and add suffix to the queue names per the environments the queues resides on.
Application programmers are going to throw a fit having to make changes to their target queue names, etc. We use WMQ clients to our AIX servers and I know once they connect to a qmanager in the test cluster they can hit any clustered queue, so they will not have to make any changes to connect to a certain test environment qmanager to connect to its queue like they do today.
The first thing that comes to mind is the first part of the WMQ Queue Manager Clusters manual, in particular the Getting Started… section.
There is a white paper out there by Scott Meridew you may want to look at.
When the apps are JMS, changing the queue names is in the managed object definitions. I know several shops that scripted this up so that the definitions inherit from an environment property or are tailored by Ant scripts. You are MUCH better off having all the non-production destinations in one cluster namespace and using qualified queue names than having to select by connecting to dedicated environments. Whenever I have encountered resistance to using qualified names, this has evaporated once a few applications started using the cluster and found how easy it was to point to different versions of services upstream or downstream. In fact, it is arguably the case that doing any kind of SOA requires a clustered environment.
If you are successful in selling the idea, please consider the following:
- Dedicated QMgrs for full repositories. Separating your repositories from application assets is crucial to keeping the cluster healthy. Make this your baseline from the beginning and you won’t have a big remediation project later. Use dedicated servers if possible. An small AIX LPAR works fine.
- Exactly two full repositories per cluster. No more, no less.
- One big cluster is better than several smaller overlapping ones. Sounds like you are headed in this direction with the queue naming already.
- Channel names like <CLUSTER>.<QMGR> and not like TO.<QMGR> as described in the book.
- Do not use the same namelist for queues, QMgrs or channels. If you use the channel naming convention above, you will never need a namelist for channels anyway. If you use dedicated QMgrs for full repositories, they will never host application queues so you won’t be able to use the same namelist for QMgrs and queues.
- Cluster members need one and only one explicitly defined CLUSSDR.
- To properly secure the cluster requires a CHAD exit. Only supplier of these currently is CapitalWare, as far as I know. See MQAUSX for details.
- Minimal security of the cluster (without an exit) can be done by setting MCAUSER on the CLUSRCVR channels to a low-privileged user ID and setting permissions as described in my article.
— T.Rob
