Active/active IBM MQ with Uniform Clusters

[@kizmitzify]

Love the starting of a QM with mqsc scripts. Could really help customers keep uniformity across their estate.

[@NickSzabadkai]

Great presentation and good explanations. The best is that you provided us the scripts also. Thanks for that!

[@jk3383]

Good Job, Dave. Highly appreciated your video.

[@stevecook845]

could you publish your scripts, qm.ini and mqsc configurations? would be very useful to be able to reproduce the setup you have here.

[@dware301]

A little late, but I've published the scripts on Github - github.com/ibm-messaging/mq-uniform-clusters

[@syedfawad6276]

this seems all part of vertical cluster , what if we need to have QM1 , QM2 and Qm3 in different machines ? do we only need to update ips in .ini files ?

[@dware301]

Yes, that's correct. The queue managers in a uniform cluster can (even should) be on different machines as long as they can communicate with each other.

[@pongching8697]

Do all queue managers share the same queue files? In other words, if my pub application is connected to QMgr1 and my sub application is connected to QMgr2, can the sub application still receive messages published by the pub application?

[@dware301]

To ensure data consistency, each queue manager manages its own set of messages (so each queue manager should also be made highly available). MQ supports what you need by automatically routing publications between queue managers when there are matching subscriptions, typically by using "clustered topics". I talk about that in this video kzbin.info/www/bejne/qnqwZXiKdsScpJI. This does mean that moving the consuming applications around in a uniform cluster needs to carefully consider the behaviour as the actual subscription (where the messages are held) will typically only exist on one queue manager. There are ways to address that (also covered in that video above, about 40 minutes in).

[@naveent2785]

But why is the CCDT file needs to be updated for the applications and why the application needs to know about new queue managers.. Isnt it taken care at cluster level if new QM is added to the MQ cluster.

[@NickSzabadkai]

I guess, the clients do not know anything about clusters and that's o.k..

[@dware301]

You're right that the CCDT needs to be updated to contain the new queue manager entry, but the application itself doesn't need to be aware of that, just have access to the updated CCDT. There's no need to change the application itself, it'll just dynamically pull in the updated file. It's even possible to point the application at a remotely hosted CCDT file so you can update it centrally. Unfortunately this can't all be handled within the MQ cluster as this does not necessarily know how an application will connect to the queue managers (e.g. knowing how the queue managers are externally addressable to them). Perhaps that can be improved on in the future, particularly in environments where that information is more closely managed

[@NickSzabadkai]

David Ware Thank, missing one detail. When does the client update the ccdt? Before opening a new connection or when restarting? I guess before connection. I hope.😊