Integration


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


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


Add a new idea Subscribe
Status Under review
Workspace MQ, MQ Advanced & MQ Appliance
Created by Guest
Created on May 28, 2025

RELATED IDEAS

Alternative resiliency options for IBM MQSeries

While Native HA is the recommended solution to provide the highest resiliency natively in the product, it has several deployment challenges for customer private clouds.

1. High entry cost.   Native HA requires OpenShift or Kubernetes to operate.   That imposes a large initial installation cost for the first MQ instance.

2. High operating cost.   Native HA with DR, requires 2 clusters of 3 for a total of 6 pods/nodes.  That is 6 pods compute/storage etc for single node's MQ performance

3. Limited applicability.  Many customer on-prem datacenters are deployed in pairs within a city or region.  With 2 datacenters its not possible to deploy a Native HA cluster ( 3 nodes ) and establish quorum as there are only 2 datacenters; and a potential third datacenter is too far away ( >5ms latency ).    Alternatively you can deploy across the 2 sites as active/passive with async Native HA DR but is costly;  see #2.

4. Platform complexity.  Customers that have to build and operate their own openshift or kube clusters have a large learning curve and maintenance overhead.  Overhead increases with each deployment site.

Proposal

Refactor Native HA to provide alternative resiliency patterns that can support 2 datacenter deployments ( with far remote third site)

1. Decouple dependency on OpenShift/Kube to allow easier on-prem deployments.  Software or standalone container based.

2. Decouple quorum logic from data nodes such that quorum and data nodes can be independently deployed.  See Apache Kafka Kraft

3. Quorum nodes still require 3 instances but do not have distance limitations that data nodes would have

4. Data nodes deployed in pairs active/passive where active is elected by the quorum nodes and data replication direction is automatically managed upon failures.  Alternatively if both nodes in pair can accept traffic would be better but likely a bigger uplift vs active/passive.

5. Maintain software based replication that does not depend on external hardware or software solutions

 

Idea priority High
  • Guest
    Nov 14, 2025

    quorum/external controller to ensure workers/MQ nodes don't go into split brain and all start offering MQ service .  Preference is for it to be handled within MQ so that no additional software components are required which just adds complexity.

    Option 2 or 3 look best; Voting/controller nodes that can be used for multiple QMs would be efficient - potentially extendable to manage other MQ deployments ( appliances ?). 

    Is option 4 looks to be an extension - gives ability to keep running in 1 Availability Zone if single MQ worker node fails. 

    Reply
  • Guest
    Jun 4, 2025

    5. Maintain software based replication that does not depend on external hardware or software solutions (e.g DRBD)

    Proposal in short is similar to RDQM DR, but replication in MQ instances (not DRBD) and leader actively managed through some external quorum solution

    Reply

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.