Active/active in IBM MQ means capacity and availability through parallelism: multiple queue managers or sysplex members handle messages at the same time instead of leaving a standby idle. Retail peaks, global banks, and cloud microservices often outgrow a single hub—even a highly available one—and need several engines pulling the same workload pool or partitioned queues. Clusters federate queue managers with automatic routing. Queue sharing groups let z/OS applications put and get the same queue name from any healthy member. Competing consumers on one queue multiply tasks without multiplying queue managers. This tutorial contrasts active/active with active/passive, explains cluster and QSG patterns, discusses ordering and idempotency, covers workload management attributes, and guides when architects should not force active/active complexity on a simple hub.
| Aspect | Active/active | Active/passive |
|---|---|---|
| Goal | Scale + survive node maintenance | Fast failover of one hub |
| Nodes working | Many concurrently | One active, one standby |
| IBM MQ examples | Cluster, QSG, many instances | Multi-instance, RDQM standby |
| Complexity | Routing, ordering, CF capacity | Shared disk or replication |
| Logical QM name | Often many names or group attach | One name survives failover |
In an IBM MQ cluster, multiple queue managers publish their availability to a repository. Applications can put to a cluster queue name; the queue manager routes to a suitable instance based on CLWLUSEQ, CLWLRANK, CLWLWGHT, and related attributes. All members can be running channels and processing messages simultaneously. Full repositories hold complete cluster knowledge; partial repositories cache subsets. Automatic channel creation connects members when traffic appears. Beginners should study cluster workload management before tuning weights randomly.
12345/* Illustrative cluster put flow Application MQPUT to CLUSTER.PAY.IN Local QM resolves via repository Message routes to member with running instance Multiple members may host instances over time */
A queue sharing group is active/active for shared queues stored in the coupling facility. Applications connect to the group; any member can access shared queues. When one member is stopped for maintenance, others continue. Private queues remain on individual members. CF structure sizing and structure recovery levels dominate availability—not identical to Linux MIQM but the mainframe answer to horizontal MQ within a sysplex.
Even on one queue manager, ten application instances each MQGET from the same queue—that is active/active consumption. No cluster required. Scale is limited by one queue manager engine and disk. Combine with clusters when you need cross-host scale.
Strict global ordering across all messages, legacy apps that assume single-server hostnames, or teams without cluster operations skills may suffer more from active/active than from a well-tested active/passive hub with client reconnect. Start simple; add cluster or QSG when metrics prove need.
Scenario: three datacenters, 50k msgs/sec, maintenance windows monthly, strict hub name for partners. Evaluate active/passive MIQM in each DC versus cluster with three full repos versus QSG if on z/OS. Document tradeoffs in one page for architects.
Active/active is every checkout lane open at the supermarket. Active/passive is one lane open and a backup cashier ready to replace someone who leaves—only one lane serves each customer at a time per register set.
Many helpers pick apples from the same big basket at once. Active/passive is one helper working while another waits to swap in if the first gets tired.
Design cluster queue names for PAY in three cities with CLWL weights favoring local DC.
Explain ordering risk when two consumers MQGET the same queue concurrently.
Compare QSG active/active to Linux cluster active/active in five bullets.
1. Active/active implies:
2. MQ cluster is active/active because:
3. QSG on z/OS provides:
4. Multi-instance is NOT active/active because: