MQ

 View Only
Back to discussions
Expand all | Collapse all

MQ Clusters - Failover

  • 1.  MQ Clusters - Failover

    Posted Tue January 23, 2024 02:07 PM
    Reply

    Hi everyone
    My application used configure with fixed MQ manager name and IP address (ex QM1, 172.16.0.5)
    I would like to build new MQ Cluster, which like
    QM1 , 172.16.0.5, QCLUSTER1
    QM2, 172.16.0.6, QCLUSTER1
    Have any solutions for my application connect to MQ Cluster over virtual MQ and virtual IP?

    Looks like a failover feature.

    Thanks



    ------------------------------
    jason bao
    ------------------------------


  • 2.  RE: MQ Clusters - Failover

    Posted Tue January 23, 2024 05:44 PM
    Reply

    Hello Jason,
    First of all, it depends on whether your application is an "MQ Client" or a "Bindings" kind.
    If it is an MQ Client, you should look at "Uniform Clusters" which may be an answer to this need:

    About uniform clusters

    Ibm remove preview
    About uniform clusters
    The objective of a uniform cluster deployment is that applications can be designed for scale and availability, and can connect to any of the queue managers within the uniform cluster. This removes any dependency on a specific queue manager, resulting in better availability and workload balancing of messaging traffic.
    View this on Ibm >


    If the application is of the bindings type and deposits directly into the queue of an MQ cluster, there are also possibilities, depending on the desired objective.

    HTH, LMD.



    ------------------------------
    Luc-Michel Demey
    DEMEY CONSULTING
    lmd@demey-consulting.fr
    #IBMChampion
    ------------------------------

    Original Message


  • 3.  RE: MQ Clusters - Failover

    Posted Wed January 24, 2024 01:59 AM
    Reply

    Virtual IP is handled via the CCDT (client channel definition table). If you are no familiar with the term, I suggest you look it up in the infocenter and check out how it works...



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

    Original Message


  • 4.  RE: MQ Clusters - Failover

    Posted Wed January 24, 2024 10:02 PM
    Reply
    Hi Luc-Michel Demey
     
    Thank you for your reply
     
    Just checked, my application used both JMS connect (jms:JMSProvider) & binding.
     
    So How to reach my goal. Could you please suggest me.

    Thank you.

    ---------- Websphere app resource config

    <resources.jms:JMSProvider xmi:id="builtin_mqprovider" name="WebSphere MQ JMS Provider"

    ---------- binding

    InitCtx/ptpPFPR> 

    InitCtx/ptpPFPR> 
      JMSADM4089 InitCtx/ptpPFPR
     
          .bindings                 java.io.File
       a  PF.PFC.IN                 com.ibm.mq.jms.MQQueue
       a  PF.PFC.PROCESSED.OUT      com.ibm.mq.jms.MQQueue
     
      3 Object(s)
        0 Context(s)
        3 Binding(s), 2 Administered
     
    InitCtx/ptpPFPR> 


    ------------------------------
    jason bao
    ------------------------------

    Original Message


  • 5.  RE: MQ Clusters - Failover
    Best Answer

    Posted Thu January 25, 2024 05:25 AM
    Reply

    Hi Jason

    Can I check what kind of solution you are looking for here?  There are lots of different approaches to 'clusters' with MQ, and it's important to understand what you're trying to achieve.  It sounds like this is about High Availability, which itself has a number of aspects - keeping the service running if there is a failure somewhere, and keeping persistent message data safe across those failures.

    If you are looking for 'High availability clusters' in the common sense - replicating data between two nodes so that either can pick up processing without data loss - then the best approach in MQ will depend on platform.  Multi-instance Queue managers are one option based on shared storage, RDQM is another on Linux, in cloud/container environments there is 'Native HA', and on the appliance there is a built in HA replication capability.  In all of these approaches, you wouldn't actually call the instances 'QM1 and QM2' or such, they would be seen as two instances of _the same_ queue manager.  Several can be combined with a virtual IP so the client doesn't need to know anything about a failure occurring, it simply reconnects.

    'MQ Clusters', including Uniform Clusters which have been mentioned above, do not replicate messages - they are about workload balancing between a set of 'similar' queue managers, either at the message routing level (traditional) or at the application connection level (Uniform Clusters, a relatively recent addition).  Both will provide 'service availability' options, but either needs to be combined with a replication solution if you want to ensure you can lose nodes without losing message data.  If a client reconnects to a different node in these types of cluster, it truly is connecting to a 'different' queue manager and the application design needs to reflect that.

    Apologies if this was all obvious to you already and your questions really are more at the CCDT/connection management side of things - I just didn't want you to get too far down that approach if it doesn't really provide what you're looking for.

    Regards

    Anthony



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

    Original Message


  • 6.  RE: MQ Clusters - Failover

    Posted Thu January 25, 2024 08:02 AM
    Reply

    Thank you Anthony Beardsmore

    That's all I needed, thanks for your knowledge and time

    Maybe I need both HA (e.g. Multi-Instance Queue Manager) and workload balancing like Unified Cluster features

    Can they be used together?

    Thank you.



    ------------------------------
    jason bao
    ------------------------------

    Original Message


  • 7.  RE: MQ Clusters - Failover

    Posted Fri January 26, 2024 04:53 AM
    Reply

    Hi Jason - yes, you can use Clusters/Uniform Clusters alongside any of the 'replication HA' options - this would be a pretty common and sensible pattern. 

    It will often make sense to have a Cluster of as many queue managers as there are worker nodes in the replication solution - so for example you might have an RDQM group (always 3 nodes) with a Uniform Cluster of 3 queue managers running over the top of it.  In a sense you have 9 queue manager instances at that point (3 replicas, of 3 unique QMs).  3 instances will usually be actively processing (one per worker) - the Cluster allows you to balance workload and application connections around the nodes, and (more or less instantly) continue processing new messages if a node fails - the RDQM group allows you to quickly (typically seconds) recover a queue manager to another node and continue processing 'trapped' messages.



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

    Original Message


  • 8.  RE: MQ Clusters - Failover

    Posted Fri January 26, 2024 06:56 AM
    Edited by Simone Jain Fri January 26, 2024 06:56 AM
    Reply

    Hi Jason,

    It sounds like using Uniform Clusters would be helpful in providing the functionality that you're after. You might want to check out this series to help you get set up and make full use of the framework!

    Kind regards,

    ------------------------------
    Simone Jain
    ------------------------------

    Original Message


  • 9.  RE: MQ Clusters - Failover

    Posted Fri January 26, 2024 10:04 AM
    Edited by jason bao Fri January 26, 2024 10:07 AM
    Reply
    Hello Simone Jain
     
    I have read that series already. and I finished building a Uniform Cluster.
     
    Now I'm trying to figure out how to use QMGR =*ANY_QM with my client app... but I can't
     
    My client application used the JMS xml provider configuration on Windows platform:
    <resources.jms:JMSProvider xmi:id="builtin_mqprovider" name="JMS WebSphere MQ Provider" ...queryManager="QM1"
     
    Sorry for my silly question: how can my client use QMGR of Uniform Clusters?



    ------------------------------
    jason bao
    ------------------------------

    Original Message


  • 10.  RE: MQ Clusters - Failover

    Posted Fri January 26, 2024 11:03 AM
    Edited by Simone Jain Fri January 26, 2024 11:05 AM
    Reply

    Hi Jason,

    ANY_QM refers to a queue manager group defined in the CCDT for a uniform cluster. That queue manager group could be called anything but I've chosen ANY_QM as an example. Within that queue manager group, there should be connection information for each queue manager in you uniform cluster. As well as this, your CCDT should contain separate channel definitions for each queue manager in the uniform cluster. In your client application, you will need to set QMGR to be the name of the queue manager group, prefixed with a *. 

    What this means is that your application will look at the connection information in the queue manager group to connect to any available queue manager in the uniform cluster. Once connected, it will be in the uniform cluster where it will be told to connect to a specific queue manager. To do that, it will look at the separate channel definitions corresponding to each queue manager.

    Essentially, the QMGR for a uniform cluster is actually a group of queue managers and not just one. If you haven't already, I suggest you look at this article which explains the CCDT further and how to create one for a uniform cluster.

    You can also find an example of a CCDT for a uniform cluster here.

    Kind regards,

    ------------------------------
    Simone Jain
    ------------------------------

    Original Message


Related Content