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 (https://ideas.ibm.com).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
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, .