Planning scalability and performance for IBM MQ in containers

In most cases, scaling and performance of IBM® MQ in containers is the same as IBM MQ for Multiplatforms. However there are a few additional limits that can be imposed by the container platform.

• Limit the number of threads and processes.

  IBM MQ uses threads to manage concurrency. In Linux®, threads are implemented as processes, so you can encounter limits imposed by the container platform or operating system, on the maximum number of processes. From Red Hat® OpenShift® Container Platform 4.11, there is a default limit of 4096 processes per container. For older versions of the OpenShift Container Platform the limit is 1024 processes. For compatibility of IBM MQ Operator versions with OpenShift Container Platform versions, see Compatible Red Hat OpenShift Container Platform versions. While this is adequate for the vast majority of scenarios, there may be cases where this can impact the number of client connections for a queue manager.

  The process limit in Kubernetes can be configured by a cluster administrator using the kubelet configuration setting podPidsLimit. See Process ID limits and reservations in the Kubernetes documentation. In Red Hat OpenShift Container Platform, you can also create a ContainerRuntimeConfig custom resource to edit CRI-O parameters.

  In your IBM MQ configuration, you can also set the maximum number of client connections for a queue manager. See Server-connection channel limits for applying limits to an individual server-connection channel, and the MAXCHANNELS INI attribute for applying limits to the whole queue manager.

• Limit the number of volumes.

  In cloud and container systems, network-attached storage volumes are commonly used. There are limits to the number of volumes that can be attached to Linux Nodes. For example, AWS EC2 limits to no more than 30 volumes per VM. Red Hat OpenShift Container Platform has a similar limit, as do Microsoft Azure and Google Cloud Platform.

  A Native HA queue manager requires one volume for each of the three instances, and enforces instances to be spread across Nodes. However, you can configure the queue manager to use three volumes per instance (queue manager data, recovery logs and persisted data).

• Use IBM MQ scaling techniques.

  Instead of a small number of large queue managers, it can be beneficial to use IBM MQ scaling techniques such as IBM MQ uniform clusters to run multiple queue managers with the same configuration. This has the added benefit that the impact of a single container restarting (for example, as part of container platform maintenance) is lessened.