About uniform clusters

The objective of a uniform cluster deployment is that applications can be designed for scale and availability, and can connect to any of the queue managers within the uniform cluster. This removes any dependency on a specific queue manager, resulting in better availability and workload balancing of messaging traffic. Uniform clusters are not available on IBM MQ for z/OS ; queue sharing groups provide many of the capabilities of a uniform cluster.

Uniform clusters are a specific pattern of an IBM MQ cluster that provides a highly available and horizontally scaled small collection of queue managers. These queue managers are configured almost identically, so that an application can interact with them as a single group. This makes it easier to ensure each queue manager in the cluster is being used, by automatically ensuring application instances are spread evenly across the queue managers.

Uniform clusters remove some of the manual steps an administrator has to go through to create and administer a group of independent, interconnected queue managers. They move some client connection logic from the client to the queue manager, where information about levels of application activity can inform decisions at the clients, as to which queue managers they should connect to.

We can simplify both initial creation of a uniform cluster, and subsequently keeping the configuration between the uniform cluster members identical, by using the automatic configuration and automatic clustering support. When using this capability, one configuration file describes the cluster and another represents the MQSC configuration to apply to all queue managers in the uniform cluster. On each queue manager restart, the configuration is reapplied and the cluster automatically forms. See Create a uniform cluster for more details on using this feature.

To take full advantage of a uniform cluster, each application should also be scaled into multiple matching instances, preferably with at least as many instances as there are queue managers, if not many more.

• A directory of all clustering resources, discoverable by any member in a cluster
• Automatic channel creation and connectivity
• Horizontal scaling across multiple matching queues, using message workload balancing
• Dynamic message routing, based on availability

Uniform clusters use IBM MQ clustering for communication between queue managers, and balancing of workload between queues. However they differ from typical IBM MQ clusters in the following ways:

• Uniform clusters typically have a smaller number of queue managers in the cluster. We should not create a uniform cluster with greater than 10 queue managers.
• Every member of the cluster has near-identical configuration.
• The cluster is typically used by a single application, or group of related applications.
• The number of application instances connecting to the cluster should be greater than, or equal to, the number of queue managers.

  There should be a good balance between the putting and getting applications.

In a uniform cluster pattern, all queue managers in the cluster offer the same messaging services. For example, you might configure all cluster members to have the same local queues defined, and allow client applications to connect to any member of the cluster. We might also have the same server connection channels defined, and possibly the same authority records, channel authentication rules, and so on. However, members of the cluster can still have some differences in objects and configuration. For example, some applications might create temporary dynamic queues while they are connected to a queue manager. Also, some configuration updates might be rolled out across the members over a period of time; for example, new or updated certificates. As with regular IBM MQ clusters, two of the queue managers will require additional configuration to make them full repository queue managers.

The following diagram shows that the queue managers have similar configurations. They define the same queue called Q1 and the same server connection channel SVRCONN1.

Note that, for multiple queue managers with identical server connection channel names to work with a single client-channel definition table (CCDT), we must use the updated CCDT format introduced in IBM MQ Version 9.1.2. See client channel definition table in JSON format.

Applications names and application instances

An application name is displayed as the APPLTAG attribute of the DISPLAY CONN(*) TYPE CONN command. From IBM MQ Version 9.1.2, there is a change to the way in which the application name is set.

An instance of an application is a set of closely related connections that provide one unit of execution for that application. Typically, this is a single operating system process, which can have a number of threads and associated IBM MQ connections.

For more information about application name and application instances, see Application development concepts.

Non-reconnectable clients

By definition, a non-reconnectable client cannot be reconnected to a different queue manager. Only reconnectable clients can be moved in order to achieve an even workload distribution. However, there might still be a good reason to connect a non-reconnectable client into a uniform cluster: For example, because the client creates some form of persistent state, and some other mechanism is used to ensure that there are instances of the application running in each of the queue managers.

Locally bound applications

Uniform clusters are expected to have IBM MQ applications connecting as client applications, rather than locally bound applications. Locally bound applications are not prevented from connecting to uniform cluster members, but uniform clusters cannot achieve even workload distribution with locally bound applications, because they cannot connect to any other member of the cluster.

• Automatic application balancing
  Automatic application balancing greatly enhances application distribution and availability by enabling an IBM MQ uniform cluster to closely manage application distribution across the cluster, rather than relying on randomization, or a manual pinning of applications to specific queue managers.
• How automatic balancing works
  In the uniform cluster, client connections are grouped together based on the application name. Applications that connect to any member of the uniform cluster using the same application name are considered to be equivalent to any other applications using the same application name.
• Automatic balancing of JMS applications
  When Java Message Service (JMS) applications are balanced automatically, the underlying groups of IBM MQ connections that JMS applications create are moved together.
• How automatic balancing uses automatic reconnect
  From Version 9.2.0, uniform cluster automatic balancing makes use of enhancements to the existing automatic reconnect feature of IBM MQ.
• Limitations and considerations for uniform clusters
  Limitations and other points to consider when we are configuring uniform clusters.

Parent topic: Configure a uniform cluster

Related information

• Specify the application name in supported programming languages