Storage considerations for IBM MQ Advanced certified container

The IBM MQ Advanced certified container 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 we 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 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 below outlines the common fields that customize the MQ storage configuration in the v1beta1 API:

• spec.queueManager.availability controls the availability mode. If we 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]

Parent topic: Plan for IBM MQ in containers