Limitations and considerations for uniform clusters

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

There is no policing of the consistency of queue manager configuration. It is up to your 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 you are running a uniform cluster with an earlier Continuous Delivery release, during migration from IBM MQ 9.1.4 to IBM MQ 9.1.5, 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 you are running a uniform cluster containing IBM MQ 9.1.5 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 9.1.5. 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 9.1.4, you 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 Creating a uniform cluster in IBM MQ 9.1.2 or IBM MQ 9.1.3 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 you are trying to replace a single full repository queue manager with a uniform cluster, you 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 IBM MQ 9.1.3, you can view the details of the application instances, and whether they are balanced, with the DISPLAY APSTATUS runmqsc command.

From IBM MQ 9.1.3, you can monitor the current state of applications across queue managers in a cluster, and monitor application instances. For more information, see Monitoring application balancing.

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.