Is there a limit to the number of times you could remove a queue manager and then add it back into an MQ Cluster? It would be removed properly with its queues and channels correctly declustered prior to deleting the queue manager.

This question is in the context of Infrastructure as Code, where we would need to destroy and rebuild the server and thus its queue manager several times a year and perhaps dozens (hundreds?) of times over the lifetime of the queue manager and its cluster.

Or would it be better to give the queue manager a new name on each rebuild? This would require that no app reference the queue manager by name, a challenge but not an impossibility. A new QM name every few weeks/months would be a royal pain for monitoring and admin tools though. Remote Queue Definitions on other QMs in the MQ network would require some thought, but I think I should be able to make it work with QM Aliases.

Peter

A premise of MQ Clustering is that queue managers are relatively persistent. There is no easy "one command" approach for removing a queue manager and then adding it back (it will have a different QMID). 

A new qmgr name (eg. contains a sequence number) and use of qmgr aliases is a reasonably practical approach.

Have you considered a MQ Client design, with a single qmgr running on a persistent host?

Is there a limit to the number of times you could remove a queue manager and then add it back into an MQ Cluster? It would be removed properly with its queues and channels correctly declustered prior to deleting the queue manager.

This question is in the context of Infrastructure as Code, where we would need to destroy and rebuild the server and thus its queue manager several times a year and perhaps dozens (hundreds?) of times over the lifetime of the queue manager and its cluster.

Or would it be better to give the queue manager a new name on each rebuild? This would require that no app reference the queue manager by name, a challenge but not an impossibility. A new QM name every few weeks/months would be a royal pain for monitoring and admin tools though. Remote Queue Definitions on other QMs in the MQ network would require some thought, but I think I should be able to make it work with QM Aliases.

Peter

Is there a limit to the number of times you could remove a queue manager and then add it back into an MQ Cluster? It would be removed properly with its queues and channels correctly declustered prior to deleting the queue manager.

This question is in the context of Infrastructure as Code, where we would need to destroy and rebuild the server and thus its queue manager several times a year and perhaps dozens (hundreds?) of times over the lifetime of the queue manager and its cluster.

Or would it be better to give the queue manager a new name on each rebuild? This would require that no app reference the queue manager by name, a challenge but not an impossibility. A new QM name every few weeks/months would be a royal pain for monitoring and admin tools though. Remote Queue Definitions on other QMs in the MQ network would require some thought, but I think I should be able to make it work with QM Aliases.

Peter

I'll describe what we are doing.  It's similar to what you're describing in that we can fully update the qmgr on a redeployment, but do not change the name.

All of our MQ clusters are deployed in the cloud as uniform clusters.  The pattern for each cluster is the same -- two queue managers, for example QM00 and QM01.  All the queues are clustered.  Clients connect using a CCDT URL that returns connection information without creating an affinity to a particular qmgr (e.g., "*QM_ANY").  Likewise, the clients must allow the qmgrs to balance the connections if they want to continue working across restarts.  So, if we have four clients consuming from a queue, two will be connected to each qmgr in the steady state scenario.  When a producer puts a message to a queue, the qmgrs balance the load using the default algorithm -- about a 50/50 split considering all things as equal.

The qmgr file system directories in the container where each qmgr is running are on persistent volumes, meaning they persist across redeployments of the qmgr in our Kubernetes space.  The container startup script is able to detect whether it needs to create a qmgr, or is restarting the qmgr, by inspecting the file system.  We have the option to do a force create in the rare case where the file system has become corrupted in some way.

A runmqsc script is always executed whenever the container starts.  The commands have REPLACE as an option so any pre-existing configuration is overwritten.  We use this to manage configuration changes (e.g., adding/changing a queue definition).  The same is true for other changes, such as to the qm.ini file.  The configuration source is maintained in a Git repo.

Our process for making the updates is to merge the changes into the main branch of the repo.  This triggers Kubernetes to begin a redeployment cycle of the qmgr containers (deployed as a stateful set).  It stops one qmgr, at which point all the clients migrate over to the remaining qmgr.  Then, it deploys a new container that pulls the latest configuration as its source.  Once this container is fully up and ready to accept connections, the process is repeated for the other qmgr.  Clients migrate to the new qmgr.  Eventually both qmgrs are running again and the clients are balanced once more.  There is no down time from a client perspective, only limited capacity during the recycle -- which takes about 10-15 minutes to complete.

I  realize this is all high level and I've passed over lots details.  Hopefully, however, you get the gist.  We are fully rebuilding the server that hosts the qmgr, even updating the MQ code base at times (e.g., 9.0 -> 9.1), but without changing the qmgr names.  We patterned our process following an IBM redbook that was published around the same time as MQ 9.0 came out.  This has been in place now for a couple of years and we are very satisfied with the process.

Jim

Is there a limit to the number of times you could remove a queue manager and then add it back into an MQ Cluster? It would be removed properly with its queues and channels correctly declustered prior to deleting the queue manager.

This question is in the context of Infrastructure as Code, where we would need to destroy and rebuild the server and thus its queue manager several times a year and perhaps dozens (hundreds?) of times over the lifetime of the queue manager and its cluster.

Or would it be better to give the queue manager a new name on each rebuild? This would require that no app reference the queue manager by name, a challenge but not an impossibility. A new QM name every few weeks/months would be a royal pain for monitoring and admin tools though. Remote Queue Definitions on other QMs in the MQ network would require some thought, but I think I should be able to make it work with QM Aliases.

Peter