Limitations and considerations for uniform clusters

Limitations and other points to consider when we are configuring uniform clusters.

Note: For general requirements when configuring uniform clusters, see also Create a new uniform cluster.

There is no policing of the consistency of queue manager configuration. It is up to the system administrator to configure members of the cluster so that they have a similar configuration. This means that any resource, for example, queue, topic, or authority record, required by an application which can be rebalanced must be declared on all queue managers in the uniform cluster.

If we are running a uniform cluster with an earlier Continuous Delivery release, during migration from IBM MQ Version 9.1.4 to IBM MQ Version 9.1.5 or later, while some queue managers are running the older, and some the newer release, applications will not necessarily be evenly balanced around the cluster. Normal balancing resumes once all queue managers have been migrated.

Once we are running a uniform cluster containing IBM MQ Version 9.1.5 or later queue managers, an administrator must not introduce queue managers from an older release, into the uniform cluster. That is, all queue managers must be at IBM MQ Version 9.1.5 or later. If an administrator introduces a queue manager from an earlier release, an FDC containing error code MQRCCF_CLUSTER_TOPIC_CONFLICT is issued.

In IBM MQ Version 9.1.4, we can aid consistency by making use of the automatic configuration capability alongside the automatic cluster capability. By pre-configuring the cluster full-repositories, it is possible to have a single MQSC script, which is reapplied on each queue manager start, and can be reused by every member of the uniform cluster, ensuring they all have the same definitions. See Create a new uniform cluster for more details on using this. feature.

A uniform cluster queue manager can participate in at most one uniform cluster, and it can also be a member of any number of standard IBM MQ clusters.

However, a uniform cluster queue manager should not be a full repository for anything other than the uniform cluster itself. This is because increasing the number of uniformly configured queue managers beyond two implicitly defines more than the recommended two full repositories for the external cluster; see How to choose cluster queue managers to hold full repositories. If we are trying to replace a single full repository queue manager with a uniform cluster, we should separate the full repository from the application work running on it, and only move the application work into the uniform cluster.

When using automatic definitions for uniform clusters, cluster channels cannot be shared for use in other clusters; that is, you set the CLUSTER attribute to the automatic cluster, and the CLUSNL attribute must be empty.

Automatic balancing causes client applications to eventually balance themselves evenly across members of the uniform cluster.From Version 9.1.3, we can view the details of the application instances, and whether they are balanced, with the DISPLAY APSTATUS runmqsc command.

From Version 9.1.3, we can monitor the current state of applications across queue managers in a cluster, and monitor application instances. For more information, see Monitor application balancing.

There can be times when instances are not evenly balanced, particularly in the following circumstances:

  • There are fewer application instances than queue managers in the cluster.
  • Shortly after client applications have connected to, or left, the cluster.

    To prevent client applications from being rebalanced too often, especially when applications connections are coming and going, limits are set on how often the uniform cluster asks client applications to be redirected. After a period of high connect or disconnect activity, it might take several minutes for the remaining applications instances to be evenly balanced across the uniform cluster.

  • If applications have an affinity to a specific queue manager.

    Only applications that specify MQCNO_RECONNECT can be rebalanced. Applications which have an affinity to a particular queue manager should either specify the no reconnect option or MQCNO_RECONNECT_Q_MGR.

For example, an application creating a durable subscription, could be redirected to another member of the cluster. In order to receive messages for the durable subscription it has created, the application instance has to connect back to the same queue manager in the cluster using MQCNO_RECONNECT_Q_MGR.

Each member of the uniform cluster must be configured to be highly available so that any state specific to that member of the cluster, such as messages that were routed to its instance of a cluster queue before the queue manager failed, is not unavailable for too long. For example, each queue manager in the uniform cluster could run inside a container that will be restarted by a container orchestration service if it fails.

Alternatively each queue manager could be configured as an IBM MQ multi-instance queue manager, or utilize another high availability solution. We must use a reliable storage option to ensure that messages in a particular queue manager are not lost during failover.Attention: Enabling uniform cluster behavior in a cluster that does not have the recommended characteristics, in particular, use of clusters with large numbers of queue managers, is likely to have a severe performance impact. Parent topic: About uniform clusters


Related concepts