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 persistent storage to assure the queue manager retains its persistent messages and configuration after a restart. This is the default behavior. Because there are various storage providers, each supporting different capabilities, this often means that customization of the configuration is required. The example below outlines the common fields that customize the IBM MQ storage configuration in the v1beta1 API:

spec.queueManager.availability controls the availability mode. If you are using SingleInstance or NativeHA, you only require ReadWriteOnce storage. For multiInstance you require 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: [65534] # Change to 99 for clusters with RHEL7 or earlier worker nodes

For information about storage considerations for Native HA queue managers, see Native HA.

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

Storage capacity

When you use the IBM MQ Operator, the size of the storage requested is fixed, and cannot be re-sized after creating the queue manager. You must ensure the volume is large enough for your needs.

Encryption

IBM MQ does not actively encrypt data at rest. Therefore you should use passively encrypted storage, or IBM MQ Advanced Message Security, or both, to encrypt your messages. On IBM Cloud® both block and file storage are available with passive encryption at rest.