MQ clusters across a hybrid multi-cloud landscape

In hybrid and multi-cloud enterprise environments, IBM MQ is a critical component for reliable messaging across diverse platforms and infrastructures. As organizations expand their messaging networks across on-premises data centers and various cloud platforms, the complexity of managing queue managers, channels, and network configurations can increase significantly.

This article describes how IBM MQ clustering simplifies messaging architectures, improves operational efficiency, and looks at some of the more advanced topology considerations.

Scaling messaging networks for the enterprise

Without clustering, hybrid multi‑cloud messaging deployments can struggle to scale consistently across environments while maintaining manageable operational overhead. Without the right approach, organizations lose agility and introduce unnecessary complexity. IBM MQ is like a "messaging network" when deploying it across multiple platforms and locations.

When you individually define point-to-point messaging configurations of channels and remote queues between queue managers, the configuration rapidly becomes untenable as the number of queue targets increases.

As the number of queue managers grows, manual configuration of a messaging network can become increasingly complex and difficult to manage. The network will be hard to scale, and it will become particularly hard to enforce clear boundaries on queue manager usage.

MQ clusters

The answer to the administrative overhead is to use MQ clusters. An MQ cluster is a network of queue managers that are logically associated, which allows them to communicate with each other without having to manually define channels between every pair of queue managers. Instead, queue managers in a cluster discover each other, share information about available queues and services, and automatically configure the necessary connections.

In a cluster, queue managers maintain knowledge about the cluster through repository queue managers, which store information about all cluster members and their resources. This centralized knowledge distribution eliminates the need for extensive manual channel configuration and significantly simplifies the messaging topology. Cluster queues also reduce the amount of configuration required in terms of number of queue definitions and authority rules.

Benefits of MQ clusters

Key benefits of MQ clustering include:

• Simplified configuration: Reduced channel definitions and automatic discovery of queue managers and the queues they contain
• Workload balancing: Automatic distribution of messages across multiple instances of the same queue
• Service availability: Built-in failover capabilities when queue managers become unavailable
• Scalability: Easy addition of new queue managers to the cluster without reconfiguring existing members
• Reduced maintenance overhead: Centralized management of cluster resources

Note that “uniform clusters” are different from traditional MQ clusters. Uniform clusters were introduced to help load balance application connections across an identical set of queue managers. MQ clusters and uniform clusters are not mutually exclusive; you can combine uniform clusters with traditional MQ clusters. Learn more in this article series, “Uniform clustering in IBM MQ” or in the IBM MQ docs. In this article, we will explore how to build a messaging network with traditional MQ clusters.

When to use MQ clusters?

The decision to implement an MQ cluster should be based on your messaging infrastructure's complexity and growth trajectory. Key reasons when to use MQ clusters:

• When you have three or more queue managers that need to communicate. Even with a small number of queue managers, clustering provides the immediate benefits detailed in the previous section.
• When you anticipate growth to three or more queue managers, clustering becomes increasingly valuable as the administrative overhead of point-to-point configurations grows exponentially.
• When you need the messaging network to distribute messages across multiple instances of the same destination queue, clustering provides built-in capabilities without additional configuration.
• When service availability from automatic re-routing is a requirement, clustering offers native support for this pattern.

Scenarios where point-to-point channels might be more appropriate include:

• When the queue managers are owned by different organizations or business units with strict control requirements. For example, it might not be appropriate to have a cluster across your enterprise and the business partner.
• When specific network routing or channel exits are mandated for compliance or security reasons.
• When there are complex ownership and governance boundaries that make shared cluster membership impractical.

Hybrid and multi-cloud clusters

MQ clusters can span different platforms and locations; for example, connecting on-premises queue managers with cloud-based queue manager instances. Providing assured delivery across such divides is one of the greatest strengths of MQ clusters.

Hybrid clusters are a fully supported method for IBM MQ clustering and can successfully operate across:

• On-premises and cloud environments
• Different cloud providers (AWS, Azure, IBM Cloud, and so on)
• Various operating systems (Linux, Windows, AIX, z/OS, and so on)
• Hardware, containerized and traditional software deployments

However, you do need to consider the limitations of the underlying network infrastructure when designing the topology. As shown in the following diagram, when queue managers span different network zones, a full “any to any” connectivity pattern (where every queue manager connects to every other queue manager) might not make as much sense.

We need to consider:

• Network latency between platforms
• Firewall and security zone restrictions
• Bandwidth limitations
• Connection management complexity

As such, a single cluster spanning a hybrid or multi-cloud landscape may not always be the optimal solution.

When to introduce multiple clusters

Rather than creating one large cluster spanning your entire enterprise, there are several scenarios where implementing multiple separate clusters provides a better architecture:

• Different network zones. When there are network constraints between zones, separate clusters for each network zone make sense. For example, if firewall rules or network segmentation prevent direct connectivity between all queue managers, multiple clusters can respect these boundaries.
• Different administrative domains. Organizations with separate IT teams managing different parts of the infrastructure might benefit from clusters per domain. Each team can maintain full control over their cluster without requiring coordination for every change. This separation of concerns improves operational efficiency and reduces the risk of unintended impacts across organizational boundaries. Obviously, where clusters connect there still needs to be coordination between teams.
• Different business domains. When different business units or applications don't need to communicate with each other, separate clusters provide logical isolation. This improves security, simplifies troubleshooting and enables targeted performance and availability characteristics.
• Architectural clarity. Sometimes, multiple clusters simply provide a cleaner, more maintainable architecture. Separating concerns into distinct clusters can make the overall system easier to understand, document, and manage. Ultimately, this will make it easier to demonstrate that it adheres to important high-level architectural principles such as access controls, data isolation, and robustness.

Communicating between clusters

When designing messaging architectures that span multiple clusters, several patterns can be employed to enable inter-cluster communication. Each pattern offers different trade-offs in terms of availability, scalability, complexity, and operational characteristics. This section explores the various approaches, from simple point-to-point connections to sophisticated overlapping cluster configurations.

Cross-domain communication without cross-domain clustering

The simplest approach to connecting separate clusters is to avoid cluster-level mappings entirely. Instead, standard sender and receiver channels are established between individual queue managers in different clusters.

Key Benefits:

• Simple configuration with all queue managers connecting only to the queue managers it needs to.
• Strong clarity of which queue managers are connected to other queue managers, specifically in regard to direct message traceability.

Limitations:

• Network security needs to be configured for each endpoint.
• Manual channel definitions for each connection point.
• Routing is all manually defined with no cluster automatic routing benefits.

This pattern is suitable when clusters need minimal interaction or when strict isolation between clusters is required for security or compliance reasons.

Single gateway-to-gateway connection

In the gateway-to-gateway architecture, each cluster has a dedicated gateway queue manager from each cluster using sender-receiver communication channels. All inter-cluster traffic passes through the gateway via remote queues defined on the sender’s gateway queue manager.

Note that a gateway is just a normal queue manager within the cluster, but it is the only one with the addition of channels connecting to the other cluster. As such you can bolster the availability of the gateways in the same way as any queue manager (for example by configuring Native HA).

This is perhaps the most architecturally straightforward multi-cluster pattern. The inter-cluster connectivity is cleanly concentrated into the pair of gateway queue managers.

Key Benefits:

• Simple configuration with a single connection point between clusters.
• Clear network boundary and centralized monitoring point.
• Message ordering is preserved between the gateway queue managers.

Limitations:

• While the gateways can be configured for maximum message availability (such as via Native HA), their service availability is limited by the HA failover timescale. For example, if a downstream gateway (for example, QM14) becomes unavailable (such as during an internal failover), messages accumulate on the upstream gateway (for example, QM4) because cluster routing doesn't have an alternative routing path.
• Scaling is limited as there is no automatic load distribution for inter-cluster traffic.

This pattern works well for environments with modest inter-cluster traffic volumes and where the simplicity of a single connection point outweighs availability concerns.

Active-active cluster gateways

To address the single point of failure limitation, the active-active cluster gateways pattern introduces multiple gateway queue managers that actively participate in routing inter-cluster traffic. Gateway queue managers are connected with peer-to-peer communication and can be configured with cluster queues and an MQ service called “cluster queue monitor” to distribute load.

The cluster queue monitor service (amqsclm) is a sample that automatically adjusts workload distribution and reroutes queued messages to queue instances that have active consumers, which helps prevent message buildup and improve availability in clustered MQ environments.

Key Benefits:

• Incorporates the single gateway queue manager benefits.
• Multiple active gateways provide redundancy ensuring continuous service availability.
• Has the ability to improve message availability over the single gateway option.

Limitations:

• Message ordering cannot be guaranteed across multiple gateways.
• Cluster queue monitoring may help detect and resolve issues, but introduces additional components to monitor and maintain.

This pattern is appropriate when you need better availability than a single gateway but can accept the trade-offs in message ordering and the additional operational complexity.

Overlapping clusters with active-active gateways

The overlapping clusters architecture represents the "gold standard" in that it covers all the bases for connecting clusters in enterprise environments. Gateway queue managers participate as members of multiple clusters simultaneously, creating an overlapping cluster configuration. This enables true cluster-aware routing across cluster boundaries.

Key Benefits:

• Best availability and scalability characteristics.
• Gateway queue managers are members of overlapping clusters, which enables cluster routing across boundaries.
• Multiple gateways (such as QM4, QM5 in one cluster; QM14, QM15 in another) provide active-active redundancy, and the overlapping cluster additionally handle routing based on cluster queue manager health.
• Full repository queue managers can be distributed across multiple locations for resilience.

Limitation:

• Message ordering cannot be assured due to multiple hops and queue managers in the routing path, but ordering can be configured if required even though this reintroduces a single point of failure.
• Requires shared management of the gateway cluster across administrative domains.

This pattern is ideal for production environments requiring high availability and scalability, where multiple teams or domains need to communicate reliably across cluster boundaries.

Multi-cloud deployment configurations

When extending messaging infrastructure across multiple cloud platforms, the overlapping cluster pattern (previously discussed) can be extended to cater for a hybrid multi-cloud landscape. This configuration is essentially an extension of the single gateway-to-gateway pattern but applied in a cloud context.

Multi-cloud active-active overlapping clusters

This pattern extends the active-active cluster gateway approach to a multi-cloud environment, providing the highest level of availability and scalability for cross-cloud messaging, while maximizing the use of clustering to reduce configuration.

However, the overlapping cluster is present in all domains. This potentially results in a need for multiple separate teams to coordinate in management of a single cluster. This could create challenges in areas such as to alignment on versions, infrastructure updates and rollback strategies.

Multi-cloud independent overlapping clusters

To reduce the number of teams administering the overlapping clusters, rather than creating a single interconnected multi-cloud architecture, it might make sense to establish an independent overlapping cluster configurations between each pair of cloud platforms. This creates a mesh of bilateral connections rather than a unified multi-cloud cluster.

The obvious advantage to this pattern is that there is less coordination and negotiation between distinct domain application teams which can be better for different categories of service, where availability requirements might differ such as in a regulated system integrating with an occasional application. The drawback to this pattern is that it requires more MQ configuration and architectural complexity.

Choosing the right pattern

Selecting the appropriate inter-cluster communication pattern depends on several factors:

• Availability requirements: How critical is continuous operation, and what are the availability requirements for the messages being processed by the queue managers?
• Scalability needs: What message volumes are expected? Overlapping clusters scale better than single gateways.
• Message ordering: Should message order be preserved? This might limit your options to simpler patterns.
• Operational complexity: What level of complexity can your team manage? More sophisticated patterns require more expertise.
• Network constraints: What is the shape of the network topology, and what are the latency, bandwidth, and connectivity characteristics between clusters?
• Administrative boundaries: How many teams are involved? Will they be able to understand and resolve issues in an outage?

The simplest starting point for organizations joining a couple of clusters for the first time would be to introduce a gateway queue manager in each cluster, and manualy connect the gateways. This keeps the cross-cluster administration in one place for architectural and operational clarity.

For more advanced, multi-cloud landscapes overlapping clusters with active-active gateways pattern represents the "gold standard" approach providing the best balance of availability, scalability, and manageability.

Summary and next steps

Use of MQ clusters brings many benefits. Often, they are introduced simply to ease configuration and maintenance of multiple queue managers, but they also bring workload balancing, improved service availability and dynamic scalability, They can also be combined with uniform clusters for even deeper load balancing capabilities.

The larger the landscape, the more likely it will have decentralized into multiple separate domains, administered by different teams in different parts of the business. Overlapping multi-cluster architectures can provide significant benefit here, enabling the benefits of clustering, yet retaining the governance and control in each domain.

Using the approaches described in this article, MQ clusters become an essential tool in building messaging networks that span across the entire enterprise, and the same techniques are often used to extend the network into partner organizations as well.

Acknowledgements

With thanks to Anthony Beardsmore for his depth of knowledge on this subject and for helping us both formulate and review the article.