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

DRROLE(Unknown) - no such documented state

  • 1.  DRROLE(Unknown) - no such documented state

    Posted 02/06/25 01:22 PM

    Hmnm, how come I'm getting this response back from dspmq ? There is no such state according to the docs for dspmq.

    Here's  the complete response from

    dspmq -o all (minus the QMName) - 

    STATUS(Running) DEFAULT(no) STANDBY(Not permitted) INSTNAME(Installation1) INSTPATH(/opt/mqm) INSTVER(9.3.0.0) HA(Replicated) DRROLE(Unknown)ROLE(Not configured) INSTANCE() INSYNC() QUORUM()

    This is on, what I think is, a primary RDQM HA/DR QM.

    Also - how do I find out where the QM IP is for where  (hopefully) it's recovering to? I know what it should be doing because I have the network chart - but what command shows me that IP? I've looked in rdqm.ini and it just has the HA_Replication address in there. - HA_Primary, Alternate and DR_Replication are all commented out.

    thanks folks !



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------


  • 2.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/06/25 09:18 PM

    Hi John,

    If this is an RDQM HA/DR queue manager then if you don't specify the DR_Replication interface then the HA_Replication interface is used locally for what the DR_Replication address would have been used for.

    Your rdqm.ini file should have contents something like this for an RDQM HA/DR Queue Manager.

    Node:
  Name=gemlnxa1
  HA_Replication=192.168.1.120
Node:
  Name=gemlnxa2
  HA_Replication=192.168.1.121
Node:
  Name=gemlnxa3
  HA_Replication=192.168.1.122
DRGroup:
  Name=MQGem
  DR_Replication=192.168.1.130
  DR_Replication=192.168.1.131
  DR_Replication=192.168.1.132

    Perhaps you can show us what yours looks like?

    What do you see when you issue a command like the following?

    rqdmstatus -m MQG1

    You've got 6 machines involved here, so it might be worth issuing this command on each of them to understand what is setup correctly and what isn't.

    Cheers,
    Morag



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



  • 3.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/07/25 04:22 AM
    Edited by John Hawkins 02/07/25 06:31 AM

    Thanks Morag, RDQM Status is showing fine:

    Node:                                   node1.domain.com
    Queue manager status:                   Running
    CPU:                                    0.20%
    Memory:                                 440MB
    Queue manager file system:              2075MB used, 73.7GB allocated [3%]
    HA role:                                Primary
    HA status:                              Normal
    HA control:                             Enabled
    HA current location:                    This node
    HA preferred location:                  This node
    HA blocked location:                    None
    HA floating IP interface:               None
    HA floating IP address:                 None
    DR role:                                Primary
    DR status:                              Normal
    DR port:                                7001
    DR local IP address:                    1.2.3.4
    DR remote IP address list:              1.2.3.5, 1.2.3.6, 1.2.3.7
    DR current remote IP address:           1.2.3.5

    Node:                                   node2.domain.com
    HA status:                              Normal

    Node:                                   node3.domain.com
    HA status:                              Normal

    rdqm.ini (obfuscated IP)

    Node:
      HA_Replication=1.2.3.4 (this node)
    #  HA_Primary=
    #  HA_Alternate=
    #  DR_Replication=
    Node:
      HA_Replication=1.2.3.9
    #  HA_Primary=
    #  HA_Alternate=
    #  DR_Replication=
    Node:
      HA_Replication=1.2.3.10
    #  HA_Primary=
    #  HA_Alternate=
    #  DR_Replication=

    #DRGroup:
    #  Name=
    #  DR_Replication=
    #  DR_Replication=
    #  DR_Replication=

    I've also just realised that it's not showing the DR Type either - is that in a file somewhere I can check it manually??

    dspmq still shows unknown status - ah well !

    thanks Morag :-)



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------

    Original Message


  • 4.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/09/25 12:37 AM

    Hi John,

    I think you get one or two extra fields back on rdqmstatus if you run it as root. DR Type might be one of those.

    Have you run rqdmstatus on some of the other nodes too, specifically the 3 DR nodes?

    Cheers,
    Morag



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

    Original Message


  • 5.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 07:34 AM

    Hi Morag,

    Is it expected that on rdqmstatus, both the HA and DR roles show as primary on the same server??

    (See John's post)



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

    Original Message


  • 6.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 10:38 AM

    I'm taking that this means that, should the DR QM restart over here, then there will be two QM on the same machine. I think this is bad config and the DR primary should be set to one of the other three nodes to spread the load across the nodes should that situation occur - there is only one QM in each region - so two nodes are always free. 



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------

    Original Message


  • 7.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/11/25 04:59 AM

    Hey John,

    Just to clear up the HA primary, DR primary status. Having both as primary on one node is expected. It reflects that the node is within the primary site (and its data is being replicated to the DR recovery site), and that the node is the current HA primary, which is replicating its data to the other two HA nodes within its site. You would expect to see this status for the node that is running the queue manager as it is the node where the DRBD device is mounted and writes can be performed.

    The first diagram in https://www.ibm.com/docs/en/ibm-mq/9.4?topic=configurations-rdqm-disaster-recovery-high-availability hopefully provides some clarity on this topology. Within this diagram, Node 1 in the Dublin site would be both the HA and DR primary, while Node 1 in the paris site would be the HA primary but the DR secondary. If a DR failover occurred, Node 1 on the Paris site would now become the HA and DR primary and the queue manager would start there.



    ------------------------------
    Alex Chatt
    ------------------------------

    Original Message


  • 8.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/12/25 06:31 AM

    The DR status is saying "this is where the data on the DR site is being replicated from" -  correct? Under what circumstances would that not be true - can a DR replica mirror from HA secondary? - I don't see why not but how would this happen -  Would this be a deliberate act or automatic that only occurred when the HA primary couldn't reach the DR secondary but could reach it's local HA nodes?

    Also - another question is this: I have two QM - QM1 in Dublin#Node1 and QM2 in Paris#Node1.

    I assume it would make sense to replicate QM1@Dublin#Node1 to Paris#Node2 and set the HA primary for QM1@Paris to be Node2 and not Paris#Node1 (where QM2 is running in HA). Thus, when QM1@Dublin DRs to Paris it is being started on Paris#Node2 i.e. not Paris#Node1 where QM2 is already running.

    Thus in Paris I should be seeing QM1#Node2 as HA primary (running elsewhere) and DR secondary (while it's still in  Dublin). When QM1 switches over to Paris#Node2 - QM1 DR status will switch to Primary on Paris#Node2, running. 

    thus I end up with QM2@Paris#Node1 and QM1@Paris#Node2 all living in harmony.



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------

    Original Message


  • 9.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/12/25 09:17 AM
    Do you mean the DR role or DR status sorry? 
     
    The DR role can only be primary (which is saying, this is the site where the data is being replicated from) or secondary (which is saying, this is the site that the data is being replicated too). There is also "Unknown" but that will normally indicate configuration issues. 
     
    To further use the example in the document, Node 1 in the Dublin centre will report QM1 has having the HA & DR role as primary, but node 2 & 3 in that same site will report the HA role as secondary, while still reporting the DR role as primary. This indicates that their site is the "main/prime" one which is replicating QM1's data to the DR/secondary site, but that nodes 2 & 3 are also getting QM1's data from node 1. Now on the Paris Data centre, all nodes will report the DR role as secondary, but Node 1 will report itself as the HA primary, while 2 and 3 will report as secondary.  Again this reflects the fact that Paris Node 1 is first getting QM1's data from Node 1 in Dublin, and then replicating that data to Paris Node 2 & 3.
     
    As for your second question, Id say its up to the preference of the customer/user what type of configuration they want, but yes this is a very common setup. What I would say though is that the customer/user should be comfortable with all queue managers ending up on running on the same node, as this is possible with HA failovers if "things" were to go wrong on one node.
     
    When querying the status of a Queue manager on its DR secondary site, you should get the QM status of "ended immediately" whether that be on the HA primary or secondary. HA secondary nodes on the primary DR site will reflect "running elsewhere" as long as the queue manager is running on the HA/DR primary node. 
     
    I hope that helps a bit, if not let me know,
     
    Alex


    ------------------------------
    Alex Chatt
    ------------------------------

    Original Message


  • 10.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 03:31 AM

    Hi John,

    About the "DR Type" field, asynchronous replication is the only replication type supported for DR when the queue manager is configured for HA and DR. This field will only show up if the queue manager is configured for DR only.

    Thanks,

    Alex



    ------------------------------
    Alex Chatt
    ------------------------------

    Original Message


  • 11.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 07:33 AM

    Ah ha - that's great. Thanks alot for that ! Is that docced somewhere ?(now you say it, it rings a bell but goodness knows when I last looked at all this stuff)

    I see this statement in the info center - on the DR pages:(https://www.ibm.com/docs/en/ibm-mq/9.4?topic=recovery-requirements-rdqm-dr-solution)

     IBM will support a latency of up to 5 ms for synchronous replication and 100 ms for asynchronous replication.

    Which is a bit misleading if IBM only supports asynch for DR :-)



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------

    Original Message


  • 12.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 08:31 AM

    For DR only queue managers, both synchronous and asynchronous replications are available. We document that DR replication for HA/DR Queue managers is asynchronous only here: https://www.ibm.com/docs/en/ibm-mq/9.4?topic=configurations-rdqm-disaster-recovery-high-availability 

    "The replication between the DR/HA RDQMs on the main site and the disaster recovery site is always asynchronous. With asynchronous replication, operations such as IBM® MQ PUT or GET complete and return to the application before the event is replicated to the secondary queue manager."


    Alex



    ------------------------------
    Alex Chatt
    ------------------------------

    Original Message


  • 13.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 10:50 AM

    Hmm, interesting. Now I'm thinking this...

    The customer doesn't like RDQM - too complex for them . It's also resource intensive for them - They only have one QM in each region so there are always two nodes sitting there not working.

    So, why not move back to good old-fashioned multi-instance - with the usual disk/network issues that this has. But get simplicity back for HA and save one cold machine in each region.

    Then use RDQM for DR to another region. Presumably RDQM DR has advantages over (in this case) AWS EFS replication - which seems to have an RPO of  15 minutes (and possibly more if a heavily used disk). I'm guessing  that RDQM DR has the advantage that you can easily (ish) see what state the data replication is in and the RPO MUST (!?!?!) be better than 15 minutes ?



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------

    Original Message


  • 14.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 05:14 AM

    Hi

    Is there any reason why you have not assigned a floating IP address to the RDQM using rdqmint ?

    Surely it's better to refer to the RDQM service via a single IP address (and even better a single DNS address)?

    I assume this would result in one floating IP address per site if there were 6 hosts involved (3 per site).

    Interesting even Wikipedia mentions this:  IBM MQ offers a variety of solutions to cater for availability:

    Replicated Data Queue Manager (RDQM / 'Easy HA'- MQ Advanced on distributed only): Synchronous replication between three servers that all share a floating IP address.



    ------------------------------
    Peter T
    ------------------------------

    Original Message


  • 15.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/10/25 10:57 AM

    Hi Peter - This is not my system - I'm reviewing it :-) However, there are LB being used. They are certainly fronting the HA machine configuration and looking for health status on ports. So, I would have thought that covered the HA side without using floating IP?

    However, the DR looks to be statically assigned at the moment so there looks to be either LB recommendations or floating Ip that could be used - not clear on why I would use floating IP versus an LB though? Seems 50/50 to me?



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------

    Original Message


  • 16.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/12/25 03:08 AM

    Hi

    What sort of Load Balancer do you use in front of the RDQM? I've never used a MQ LB other than a sysplex VIPA.

    Using a floating IP means a LB is not needed which may make the setup a lot easier.

    The reason for my interest is we have a RDQM without either a LB or floating IP. This was set up by a vendor and I am trying to encourage them to use a floating IP - I assume this is a common and generally good practice?



    ------------------------------
    Peter T
    ------------------------------

    Original Message


  • 17.  RE: DRROLE(Unknown) - no such documented state

    Posted 02/12/25 06:48 AM

    Hi Peter,

    I've seen TCP LB to be used (in AWS, Azure and in private DC) They can't look in to the MQ packets so they just look for the QM Listener liveliness. You could do clever stuff on the QM node to ascertain liveliness but you start to replicate some of the underlying MQ monitoring code that it uses to ascertain it's own liveliness so I usually stop there. (e.g. multi-instance looks at whether certain processes are up or not to ascertain liveliness) (Only MQIPT can look into the MQ protocol and it can do some basic primary/secondary type stuff out of the box)

    I'm not sure there is a best-practice Floating IP Vs LB. I generally find the client has a preference for what they prefer i.e. what they're used to - and most customers are used to working with LB and have them in-place or can work with them easily to put them in place. But then e.g. clouds and Dc have their own floating IP concepts too - so there's too many options to say, IMO ! 

    The one thing I would say is that, in a cloud environment, I would use an LB as then all the config is baked into the terraforms/auto scale groups/LB etc. i.e. putting it at the cloud level can be quite "clean" and visible. IMO - visibility/ease of maintenance  is usually the most important thing as customers techies come and go.



    ------------------------------
    John Hawkins
    Integration Consultant
    ------------------------------

    Original Message


Related Content