-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Queue manager coexistence #538
Comments
I think it might be possible to run multiple Native HA instances in a single container, but is certainly not best practice for containers, where you usually aim for a single "concern" per container. It seems though that your issue is related to the web console, which already stretches the single concern concept. You can disable the web server associated with each queue manager, and run a single web console server separately. Running a remote web console is supported in MQ (see https://www.ibm.com/docs/en/ibm-mq/9.3?topic=mcarqmco-adding-remote-queue-manager-mq-console-by-using-command-line-cd-only). The main hurdle is that there isn't a sample for setting up a remote web console in containers, so you'd need to build your own container enablement code right now. If this is something you'd like to see in the product, then you can raise an official feature request at https://ibm.biz/mqideas |
We certainly don't test Native HA in the way you're describing, so there are definitely concerns about whether or not IBM could support that sort of usage. If you want to pursue that, I can discuss with the relevant teams. |
Is there a way that queue managers with different names can coexist on the same MQ NHA installation?
We are looking for a way to deploy multiple queue managers with different names on same NHA installation with HELM. It might be essential to meet some requirements of particular software stack, governance and license administration.
Let me explain:
Running a simple queue manager on a single MQ installation means a waste of resources for vCPU licensing, since the MQ container itself needs around 1vCPU assigned in order run smoothly the web console, this without counting the processing of messages, since once MQ starts processing messages a 1vCPU allocation falls short and it is necessary to allocate more resources depending on the load of each queue manager before we start having connection problems in the channels or slow message processing.
Of course that last point is expected and we understand it, however in environments where we pay license per vCPU core assigned to each NHA queue manager, and where we run multiple queue managers for multiple clients under the same cluster, we are talking about a huge waste of 1 full vCPU from our licenses per NHA installation just to achieve that MQ works well by itself in each installation.
Processes running on the system such as the web console consume a large amount of vCPU license resources that are wasted by having multiple web consoles running for each NHA MQ installations.
Being able to allocate multiple queue managers on the same NHA installation would allow us to optimize the allocation of cluster resources as well as our licenses.
The text was updated successfully, but these errors were encountered: