IBM Integration Community Come for answers. Stay for best practices. All we’re missing is you. Join / Log in Ask a question
Helló,I've been looking for information on how to enable firewalls between MQ cluster members.We have a number of queue managers (40-50), with a centralized architecture (each one could only speak with the center).And we have firewalls between almost everything :) Till now we knew what to enable, but recently we started to use MQ clusters, and the question came: between which hosts should we enable firewalls?I suspect (my logic tells) that we should enable communication at the following cases:* Between the two full repositories* Between the partial repositories and their defined full repository (maybe both full repositories?)* Between all the partial repositories hosting the same queue* Between the client's queue manager and all the partial repositories hosting the queue that the application wants to reachAre these assumptions correct? What else might be needed? Is there any "official" recommendations / best practices on firewalls when using MQ clusters?Thanks,Robert
I'll comment on each of your cases:-
I can't think of any other cases to add to your list.
EDIT: This seems to sum up that you need any-to-any firewall connectivity though your cluster.
If you need to fix the outbound ports that your cluster channels use in order to set firewall rules, you may find this page a helpful reference: Working with auto-defined cluster-sender channels
------------------------------Morag HughsonMQ Technical Education SpecialistMQGem Software LimitedWebsite: https://www.mqgem.com------------------------------
Hi Robert,further to Morag's response, there is one use case I can think of for each of the queue managers hosting a cluster queue instance needing to be able to communicate (and therefore have firewall rules to permit the channels to run).IBM provides a sample cluster queue monitoring program (See https://www.ibm.com/docs/en/ibm-mq/9.3?topic=amqsclm-design-planning-using-sample).This program monitors how many applications have the queue open for input, and adjusts the clwlprty (cluster workload priority) value of the queue to 0 if there are no applications with the queue open for input (ipprocs=0).It can also requeue messages from that queue manager to another so that messages on the cluster queue are not stuck there waiting for an application instance to start before they can be processed. This requeuing process requires that the cluster queue managers can communicate.Regards,Neil CaseySyntegrity Solutions.
Thanks - I edited my list above.
Hi RobertMorag and Neil have already provided excellent answers.
On the 'partial repositories hosting the same queue' - there are probably edge cases where if you have PUTting applications connected to these queue managers, they might still want to route a message to a remote instance - for example if the local queue becomes unavailable for some reason, or you have configured CLWLUSEQ(ANY). If the putting applications are remote, then (aside from the amqsclm exception) as Morag says these should not normally need to communicate.
The only other thing I can think to add, is if either now or in future you add publish subscribe applications using clustered Topic objects, by default these require that ALL partial repositories be able to communicate with all others. In your environment, it sounds like it would be sensible to look at the alternative option 'Routed Topics': https://www.ibm.com/docs/en/ibm-mq/9.3?topic=clusters-topic-host-routing-in-publishsubscribe which is more suited to star/central hub topologies.RegardsAnthony
Hello,thank you all for your valuable responses! They brought some new aspects that we should consider in the future!It is good to see anyway that my initial feelings were quite okay.Have a nice day,Robert
I think this one has you puzzled because gateways weren't mentioned by the OP. You are correct that if gateways were being used then the role of the "client's queue manager" in the OP's description would be played by the gateway.
If you consider a cluster where the client application is connected directly to a cluster queue manager, and where there are no gateways in the picture, then I'm sure your confusion will be removed.
There is no gateway, the client is connecting to its queue manager, which is a cluster member.Greetings,Robert
Hi Robert - I made some edits to my original answer to capture the other discussions in this thread.