Question & Answer
Question
You create an IBM MQ queue manager in a container, such as in OpenShift Container Platform (OCP), using the most basic storage type of "ephemeral".
You are able to define queues and put messages in the queues, including persistent messages.
So far, so good.
You are able to define queues and put messages in the queues, including persistent messages.
So far, so good.
.
Then there was a problem with the container system and the pod of the queue manager was deleted and the Kurbenettes function of the container system recreated the pod for the queue manager and the queue manager is recreated and restarted.
.
Then you notice that all the queues that you previously defined (before the deletion of the pod) are GONE!
Is this a bug?
If it is not a bug, why the queues were gone?
Is this a bug?
If it is not a bug, why the queues were gone?
Answer
1) The storage type "ephemeral" is the most basic type and it useful for short-lived testing queue managers.
Due to its nature, ephemeral storage is NOT persistent!
That is, the files stored in ephemeral storage will NOT survive a restart of the pod that has a queue manager.
A way to think about this, is like using RAM and not disk storage. If the PC is turned off, the contents in RAM is deleted.
In short, do NOT use storage type 'ephemeral' for Production queue managers.
Due to its nature, ephemeral storage is NOT persistent!
That is, the files stored in ephemeral storage will NOT survive a restart of the pod that has a queue manager.
A way to think about this, is like using RAM and not disk storage. If the PC is turned off, the contents in RAM is deleted.
In short, do NOT use storage type 'ephemeral' for Production queue managers.
2) For Production queue managers, or for Testing queue managers that are used for long periods of time, you need to use the other storage type: "persistent claim".
If the pod is recreated by Kurbenettes, then the objects and persistent messages in the queue manager, will survive.
A way to think about this, is like using disk storage and not RAM. If the PC is turned off, the contents in RAM is deleted, but the contents of the disk survives the restart.
If the pod is recreated by Kurbenettes, then the objects and persistent messages in the queue manager, will survive.
A way to think about this, is like using disk storage and not RAM. If the PC is turned off, the contents in RAM is deleted, but the contents of the disk survives the restart.
+ For an example in OCP of specifying the storage type "persistent-claim" during the creation of a queue manager, see the attached PDF file:
+++ end +++
[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"ARM Category":[{"code":"a8m0z00000008ORAAY","label":"Cloud"}],"ARM Case Number":"TS012982955","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
24 May 2023
UID
ibm16998089