Storage considerations for IBM MQ Operator

The IBM® MQ Operator runs in two storage modes:

Ephemeral storage is used when all state information for the container can be discarded when the container restarts. This is commonly used when environments are created for demonstration, or when developing with stand-alone queue managers.
Persistent storage is the common configuration for IBM MQ and ensures that if the container is restarted, the existing configuration, logs and persistent messages are available in the restarted container.

The IBM MQ Operator provides the capability to customize the storage characteristics which can differ considerably depending on the environment, and the desired storage mode.

Ephemeral storage

IBM MQ is a stateful application and persists this state to storage for recovery in the event of a restart. If using ephemeral storage, all state information for the queue manager is lost on restart. This includes:

All messages
All queue manager to queue manager communication state (channel message sequence numbers)
The MQ Cluster identity of the queue manager
All transaction state
All queue manager configuration
All local diagnostic data

For this reason you need to consider if ephemeral storage is a suitable approach for a production, test or development scenario. For example, where all messages are known to be non-persistent and the queue manager is not a member of an MQ Cluster. As well as disposing of all messaging state at restart, the configuration of the queue manager is also discarded. To enable a completely ephemeral container the IBM MQ configuration must be added to the container image itself (for more information, see Building an image with custom MQSC and INI files, using the Red Hat OpenShift CLI ). If this is not completed, then IBM MQ will need to be configured each time the container restarts.

For example, to configure IBM MQ with ephemeral storage the storage type of the QueueManager should include the following:

queueManager:
  storage:
    queueManager:
      type: ephemeral

Persistent storage

IBM MQ normally runs with persistence storage to assure the queue manager retains its persistent messages and configuration after a restart. Therefore, this is the default behavior. Due to the various storage providers and different capabilities each support, this often means that customization of the configuration is required. The example below outlines the common fields that customize the MQ storage configuration in the v1beta1 API:

spec.queueManager.availability controls the availability mode. If you are using SingleInstance you only require ReadWriteOnce storage, while multiInstance requires a storage class that supports ReadWriteMany with the correct file locking characteristics. IBM MQ provides a support statement and a testing statement. The availability mode also influences the persistent volume layout. For more information, see High availability for IBM MQ in containers
spec.queueManager.storage controls the individual storage settings. A queue manager can be configured to use between one and four persistent volumes

The following example shows a snippet of a simple configuration using a single-instance queue manager:

spec:
  queueManager:
    storage:
      queueManager:
        enabled: true

The following example shows a snippet of a multi-instance queue manager configuration, with a non-default storage class, and with file storage requiring supplemental groups:

spec:
  queueManager:
    availability: 
      type: MultiInstance
    storage:
      queueManager:
        class: ibmc-file-gold-gid
      persistedData:
        enabled: true
        class: ibmc-file-gold-gid
      recoveryLogs:
        enabled: true
        class: ibmc-file-gold-gid
  securityContext:
     supplementalGroups: [99]

Note: You can also configure supplemental groups with single-instance queue managers.

Note: You do not require shared file systems if you use Native HA (see High availability for IBM MQ in containers). In particular, you should not use NFSv3.