Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Created by Guest
Created on Jun 1, 2023

DR/HA RDQM Supporting a 5-node solution within a datacenter.

US Bank has 2 datacenters (primary and secondary).  Within each of the datacenters (primary and secondary) there are 2 independent separate pods.  For all practical purposes you can consider these individual datacenters within a datacenter.  This is designed so we can perform maintenance in one pod without impacting the other pod.  We would like DR/HA RDQM to support a 5-node solution within each of our datacenters (primary and secondary).  Within a datacenter, we would put 3 RDQM nodes in pod 1 and 2 RDQM nodes in pod 2.  This way in the event of a loss of a pod we would not have to move to our recovery site.  Please see the attached PDF.   We would expect this solution to also replicate asynchronous between the DR/HA RDQMs from the main site to the disaster recovery site.  With a 5-node solution, the only time we would be required to move to our disaster recovery site is if we have a total loss of our primary datacenter.  With a 3-node solution, if we lost pod 1 which has 2 of the RDQM nodes, we would be forced to move to our recovery site despite the fact that we would still have a fully functioning pod 2.   

US Bank is in the process of moving to DR/HA RDQM and would like to deploy the 5-node solution.  In order to do this we need to know that IBM will support this deployment.  



Idea priority Urgent
  • Admin
    Mark Taylor
    Jul 25, 2023
    • RDQM currently supports three patterns; a 3-node HA configuration, a 2-node DR configuration, and a 6-node HA+DR configuration. The 6-node configuration represents DR between two 3-node HA groups. This Idea is requesting that we support a 10-node HA+DR configuration that has an HA quorum of 5 nodes at each site. A 5-node quorum can tolerate the loss of two nodes, whereas a 3-node quorum can tolerate the loss of only 1 node. This means that a 5-node quorum would need to have multiple failures for RDQM queue managers to go down (or encounter a failure while another node is down for maintenance). There are valid reasons why customers might be interested in this level of resiliency, but it is not a piroirty item for development. Replicating data between more systems also introduces complexity and the potential for performance degradation.

    • It is also worth noting that this customer's particular reason for wanting a 5-node quorum is not valid. They want to divide each of their sites into two availability zones. They have noted that with a 3-node quorum they would have 2 nodes in one zone and a single node in the other zone at each site. They have requested a 5-node quorum so they could have at least 2 nodes in each zone. Although they wouldn't then have a zone with just a single node, they would still lose quorum if they lost the zone with 3-nodes. Dividing a quorum in to two always has this problem, so increasing the number of nodes would not address this problem.

    • The customer also discussed this requirement on the MQ listserv group. A reply on that forum explained the problems with dividing a quorum into two parts, .