Planning storage for the IBM MQ Operator
- 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.
Ephemeral storage
- 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.
QueueManager
should include the
following: queueManager:
storage:
queueManager:
type: ephemeral
Persistent storage
- spec.queueManager.availability controls the availability mode. If you
are using
SingleInstance
orNativeHA
, you only requireReadWriteOnce
storage. FormultiInstance
you require a storage class that supportsReadWriteMany
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 Planning 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.
spec:
queueManager:
storage:
queueManager:
enabled: true
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.
Storage capacity
When you use the IBM MQ Operator you should try to ensure
that you request volumes that are large enough for your ongoing needs. However, should you need to
increase the storage capacity of one or more volumes, these volumes can be expanded if your storage
class supports volume expansion. Volumes can be expanded either by an online or offline procedure.
An offline procedure requires QueueManager
pods to be restarted, whereas an online
procedure does not. To determine if your storage class supports volume expansion, and which
procedure the volume expansion follows, refer to your storage provider documentation. You should
consider this information when selecting a storage class. For a guide to volume expansion, see Expanding persistent volumes.
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.