Limitations and considerations for uniform clusters

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

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

Importance of uniformity between queue managers

By default, any application that declares itself as reconnectable might be rebalanced to an alternative queue manager in a uniform cluster at any time. This means that any resource, for example, queue, topic, or authority record that is required by such applications must be declared on all queue managers in the uniform cluster.

Consistency of queue manager configuration is not policed. It is up to your system administrator to configure members of the cluster so that they have a similar configuration.

However, you can aid consistency by using the Automatic configuration from an MQSC script at startup capability to share MQSC scripts that define objects for the cluster and therefore ensure that all have the same definitions. For more information, see Creating a new uniform cluster.

This uniformity extends to full repository queue managers for the cluster. Although for traditional IBM® MQ clusters it is often considered best practice to separate the full repositories onto stand-alone systems, in a uniform cluster, the model is that full repositories fully participate in the cluster and process application workloads alongside other nodes.

Note:

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 or later, while some queue managers run the older, and the newer release, applications are not necessarily evenly balanced around the cluster. Normal balancing resumes once all queue managers are migrated.

Once you are running a uniform cluster that contains IBM MQ 9.1.5 or later queue managers, you 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 or later. If you introduce a queue manager from an earlier release, an FDC containing error code MQRCCF_CLUSTER_TOPIC_CONFLICT is issued.

Overlapping uniform clusters and traditional IBM MQ clusters

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. It might be helpful to think of the uniform cluster as acting as a single queue manager in the wider cluster.

A uniform cluster queue manager must act as a full repository only for the uniform cluster itself. Any queue manager that belongs to a uniform cluster but might also belong to a wider traditional IBM MQ cluster, cannot be used as a repository outside the uniform cluster. For more information, see How to choose cluster queue managers to hold full repositories.

To replace a single full repository queue manager with a uniform cluster, separate the full repository from the application work that is in progress on it, and move only the application work into the uniform cluster.

When you are 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.

Application balancing considerations

Application instances are not always evenly balanced, particularly in the following circumstances:

When there are fewer application instances than queue managers in the cluster.
During a short period after client applications connect to, or leave, 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 rebalanced. After a period of high connect or disconnect activity, it might take several minutes for the remaining application instances to be evenly balanced across the uniform cluster.

For more information, see Application balancing trouble shooting.

Application affinities

Not all applications are suitable for automatic rebalancing across a uniform cluster. Only applications that specify MQCNO_RECONNECT are rebalanced. Applications that have an affinity to a particular queue manager must either specify the MQCNO_NO_RECONNECT option or MQCNO_RECONNECT_Q_MGR. The latter allows HA failover but not rebalancing.

Examples of applications that create an implicit affinity to a queue manager:

Applications that create durable subscriptions.
Applications that create permanent dynamic queues, for example, to receive reply messages.
Applications that expect strict message ordering or require all messages in a sequence be processed by the same application instance or both.

These applications must specify MQCNO_NO_RECONNECT or MQCNO_RECONNECT_Q_MGR options rather than MQCNO_RECONNECT.

For more information, see Reconnection options.

Message availability

While application balancing can rebalance connections around failed or temporarily unavailable queue managers, uniform clusters do not replicate message data across their members. For data availability, if a node fails, each member of the uniform cluster must also be configured to be highly available. Many data replication and high availability solutions are available, and can be combined with uniform clusters for maximum service and data availability, for example:

Replicated storage that supports a container instance that is automatically restarted by container orchestration. For more information, see Single resilient queue manager.
RDQM queue managers. For more information, see RDQM high availability.
Multi instance queue managers. For more information, see Multi-instance queue managers.
Native HA. For more information, see Native HA.
IBM MQ Appliance HA. For more information, see High availability.

Scalability and performance of uniform clusters

To enable the closer integration and sharing of application state between queue managers in a uniform cluster, a higher level of intercommunication is needed than in a traditional IBM MQ cluster. Therefore, scaling to large numbers of queue managers in a single uniform cluster is not recommended because the additional communication has detrimental effect on performance.

For both performance and management reasons, it is preferable to think of a uniform cluster as acting as a single traditional queue manager that provides messaging to a number of related applications, but is not a sole messaging service across an enterprise. In this pattern, small numbers, up to 10, queue managers are typically sufficient to support large numbers of client application connections. Application balancing makes it simple to start with small numbers, for example 3 queue managers, and scale up by adding more queue managers.

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.