This is a cache of https://developer.ibm.com/articles/awb-introduction-ibm-mq-clustering-frameworks/. It is a snapshot of the page as it appeared on 2026-02-09T21:16:08.589+0000.
An introduction to IBM MQ clustering frameworks
IBM Developer

Article

An introduction to IBM MQ clustering frameworks

Building robust and scalable messaging solutions by using uniform clusters

By Simone Jain

As a busy developer, you're looking for ways to make your messaging more efficient with minimal effort. Well, understanding uniform clusters and how they build on IBM MQ’s core clustering capability is the right place to start!

In this article, we explain:

  1. What clusters are and how uniform clusters build upon them.
  2. How uniform clusters work.

What are clusters?

Since uniform clusters are an extension of clusters, let's first explore what they are. Essentially, a cluster is a logical grouping of two or more queue managers configured so that they can share information with each other.

This clustering allows applications to be horizontally scaled across multiple instances of a queue. The queue managers create channels to maintain connectivity and distribute messages automatically based on resource availability. You can read more about how clusters work in the IBM MQ docs.

The following animation shows how the workload of an application can be spread around to all cluster members.

Animation that shows how the workload of an application can be spread around to all cluster members

While clustering provides a mechanism to distribute workloads across queue managers, the dynamic nature of messaging applications can lead to scenarios where some cluster members become busier than others. For example, some application instances might reconnect frequently, while others might connect for longer periods, placing a greater burden on that queue manager.

The following animation shows message distribution with unbalanced consumers.

Animation that shows message distribution with unbalanced consumers

A queue manager in the cluster might become unavailable due to a temporary outage, in which case any connected clients will need to reconnect elsewhere in the cluster. When the queue manager is back online, its previous connections will not be restored. As a result, there might be a period of time where this queue manager is underutilized compared to other cluster members.

The following animation shows the effect of a cluster member temporarily going offline on the distribution of connecting applications.

Animation that shows the effect of a cluster member temporarily going offline on the distribution of connecting applications

Let's now look at how the uniform cluster framework addresses this type of imbalance in client application connectivity.

What are uniform clusters?

For clusters of almost identically configured queue managers, uniform clusters add the ability to actively balance the application instances between these queue managers.

Uniform clusters deliver more effective horizontal scaling and allow you to add more queue manager instances in response to spikes in demand. Uniform clusters reduce contention of resources and help maximize efficiency, making your messaging solution more reactive.

How does a uniform cluster work?

For a uniform cluster to behave effectively, the cluster members need to be "almost identically configured." By this, we mean that the cluster members need to offer the same core messaging resources (for example, a common set of channels, queues, or authority records). However, some variations can occur through changes in real-time state (for example, some queue managers can contain temporary locations there were created by connected applications), and these won't compromise the uniform cluster's functionality.

When an application instance connects to a queue manager within the uniform cluster, it must also provide its application name. Application names are used to group applications with a particular connectivity and workload pattern, so correct naming of your applications is essential.

After an application instance is connected to a queue manager, it can produce and consume messages as normal. All queue managers within the uniform cluster continually share state information with each other to monitor how many instances of each application name group are connected to each queue manager. If there is an imbalance, the uniform cluster will react. Queue managers with fewer instances of an application name group will request to host additional instances from queue managers hosting more. This negotiation and rebalancing process will continue until the uniform cluster is well balanced.

The following animation illustrates this process.

Animation that shows the negotiation and reconnection process involved in achieving a balanced uniform cluster

Summary and next steps

In this article, we explored how uniform clusters build on the clustering framework to allow you to create a more responsive messaging solution. By removing dependency on a specific queue manager, IBM MQ clusters provide greater resilience to issues without compromising the system as a whole.

Uniform clusters ensure that all queue managers are being used efficiently by balancing application client connections between them. More queue managers can be easily added to, and removed from, the uniform cluster in response to workload.

The IBM MQ clustering technology is particularly well suited to microservice architectures because it ensures reliable communication between components while maintaining loose coupling. Uniform clusters are an incredibly powerful feature that enables developers to create highly reactive, horizontally scalable messaging solutions. To take advantage of this functionality, you will need a CCDT, which we describe in detail in the next article, "A deep dive into client channel definition tables (CCDTs) in IBM MQ uniform clusters."