MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Back to discussions
Expand all | Collapse all

MQ clusters and firewalls

  • 1.  MQ clusters and firewalls

    Posted 05/22/23 05:24 PM

    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 reach

    Are these assumptions correct? What else might be needed? Is there any "official" recommendations / best practices on firewalls when using MQ clusters?

    Thanks,
    Robert



    ------------------------------
    Grebenár Róbert
    ------------------------------


  • 2.  RE: MQ clusters and firewalls

    Posted 05/22/23 10:39 PM
    Edited by Morag Hughson 05/23/23 05:55 PM

    Hi Robert,

    I'll comment on each of your cases:-

    • Between the two full repositories
      Yes, definitely - the two full repositories need to be able to share their knowledge of the cluster objects between them.
    • Between the partial repositories and their defined full repository (maybe both full repositories?)
      Yes - both the full repositories. While you may only manually define how a partial repository connects to one of the full repositories, the partial will discover and automatically connect to the other one as well, so you need to ensure communication is possible with both the full repositories.
    • Between all the partial repositories hosting the same queue
      I can't immediately think of any reason why these partial repositories would need to communicate with each other (outside of the next bullet point).
      EDIT: Thanks to Neil and Ant - there are indeed times when partial repositories hosting queues would need communication between them, mainly to do with re-routing arriving messages that can't be successfully delivered:-
      • A target queue becomes PUT(DISABLED) (or unavailable for other reasons) and messages are already en route. These will go through the cluster "choose routine" again and be rerouted to another good target - this requires connectivity between these partial repositories
      • The sample cluster monitoring program also does message re-routing when a target queue is not being processed successfully, and this has the same requirements as above. The messages are re-driven through the cluster "choose routine" to find another better destination.
    • Between the client's queue manager and all the partial repositories hosting the queue that the application wants to reach
      Yes, this is definitely an important one!

    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

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------



  • 3.  RE: MQ clusters and firewalls

    Posted 05/23/23 02:48 AM

    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 Casey
    Syntegrity Solutions.



    ------------------------------
    Neil Casey
    Senior Consultant
    Syntegrity Solutions
    Melbourne, Victoria
    IBM Champion (Cloud) 2019-22
    ------------------------------

    Original Message


  • 4.  RE: MQ clusters and firewalls

    Posted 05/23/23 05:56 PM

    Thanks - I edited my list above.



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 5.  RE: MQ clusters and firewalls

    Posted 05/23/23 04:07 AM

    Hi Robert

    Morag 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.

    Regards
    Anthony



    ------------------------------
    Anthony Beardsmore
    IBM MQ Development
    IBM
    ------------------------------



  • 6.  RE: MQ clusters and firewalls

    Posted 05/23/23 05:56 PM

    Thanks - I edited my list above.



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 7.  RE: MQ clusters and firewalls

    Posted 05/23/23 08:11 AM

    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



    ------------------------------
    Grebenár Róbert
    ------------------------------



  • 8.  RE: MQ clusters and firewalls

    Posted 05/23/23 12:59 PM
    • Between the client's queue manager and all the partial repositories hosting the queue that the application wants to reach
      Yes, this is definitely an important one!
      This one has me somewhat puzzled. I would have thought the answer to be between the client's queue manager and the gateway into the cluster and the gateway and all the the (partial) queue managers hosting the queue...


    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message


  • 9.  RE: MQ clusters and firewalls

    Posted 05/23/23 05:59 PM

    Hi Francois,

    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.

    Cheers,
    Morag



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


  • 10.  RE: MQ clusters and firewalls

    Posted 05/24/23 03:37 AM

    There is no gateway, the client is connecting to its queue manager, which is a cluster member.
    Greetings,
    Robert



    ------------------------------
    Grebenár Róbert
    ------------------------------

    Original Message


  • 11.  RE: MQ clusters and firewalls

    Posted 05/23/23 05:57 PM

    Hi Robert - I made some edits to my original answer to capture the other discussions in this thread.



    ------------------------------
    Morag Hughson
    MQ Technical Education Specialist
    MQGem Software Limited
    Website: https://www.mqgem.com
    ------------------------------

    Original Message


Related Content