| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Discourse \ Why more than one QM per machine? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jefflowrey |
 Posted: Thu Oct 13, 2005 1:44 pm Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| hopsala wrote: |
| It is a sad sad world when a measly .ini file is called "code control"... |
Ha.
Try *routing rules* in a flatfile.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| ramires |
| Posted: Thu Oct 13, 2005 2:18 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Make it a triple, hic, where is my queue...?? So many queue managers, so many queues....
Regards |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 14, 2005 5:37 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Administrative drunkeness and sad tales of MQ lore aside, what about the question at hand? It seems to me that the party of qm-per-appl is falling... 
(who's next eh? parry parry thrust parry) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 14, 2005 5:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Like I said, personally for me it depends highly on the application and the environment and the client.
I said for WAS vertical scaling I'll *lean* towards multiple qms per app instance - but I'm not doing that currently - as it was too much overhead.
But if the app had opened it's queue for exclusive input, I wouldn't have had a choice...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tinye |
| Posted: Thu Oct 20, 2005 7:31 am Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 17
Location: OHIO
|
Based on this discussion, I'm now torn....
I've been taking us down a QM per customer route for logical isolation; but now I'm questioning if I've made a big mistake, and need to move future connections to one QM.
Before I start moving in the opposite direction and take my lumps, I want to be certain that I'm convinced.
Let's say that I have one production server serviced by one application, and multiple customers making MQ connections to that one server. By design (and unchangeable), the application makes one connection to MQ for each customer.
In this circumstance, why is it bad for me to have a QM for each customer rather than one QM? I've just been learning MQ on the fly with what I can decipher out of the Information Center; so perhaps it's just my inexperience.
Don't get me wrong....I'm trying to understand, not be beligerent  |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Thu Oct 20, 2005 8:04 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
So, if I am getting you right, you have one server, and (I assume a dozend customers) 12 Queue Managers on it?! Right?
If that is the case, than this is IMHO the same as if I had one car for every road I'm gonna drive on.
There is other ways to seperate flows. No need to necessarily have one QM per Customer.
There are a lot of considerations you would want to make, before you decide on one or more queue managers on one or more servers. For example physycal sites, load of messages and a whole bunch of other things.
my 2 cents |
|
| Back to top |
|
|
| tinye |
| Posted: Thu Oct 20, 2005 8:14 am Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 17
Location: OHIO
|
Yes...that's correct.
I think I understand what you're saying. It sounds like it may boil down to an issue of overhead....more QMs = more overhead = bad?
When I thought about it initially, it seemed like a good idea  Each customer with their own QM, containing everything for just that one customer, their own listener on their own port, etc.
I've seen the light....I'm just trying to convince myself it is better. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 20, 2005 8:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Less QMs = more connections per QM = more channel processes + configuration changes.
But the number of channel processes will not increase at the rate that the overall process count decreases as you remove QMs. Each QM uses many processes.
And the configuration changes are one-time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| scottm |
| Posted: Thu Oct 20, 2005 11:01 am Post subject: |
|
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
What if you want to use the multiple queue managers as a way of decoupling the communication between apps. If we have a different qmgr for each application, then if the application wants to move to a different machine all we have to do is change the channel definitions and possibly transmission queues (because of naming standards).
If they are shared one QM, and one application decided it needed it's own machine, we have to take all of it's MQ object definitions out of the current QM and add them to a new QM and create all new channels and such.
There are also different gov't regulations (HIPAA, Sarbaines-Oxley, Medicare, ...) and require you to do certain things for the data and or machine and it could become cost prohibited to have to make those changes for all the apps that touch a QM or machine just because of one other app that requires it happens to live there.
Strictly from an MQ standpoint, I'd use just one QM. But from a business/gov't regulation/*reality* standpoint, I'd much rather have the flexibility of one app per QM. |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Thu Oct 20, 2005 11:48 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
| scottm wrote: |
| But from a business/gov't regulation/*reality* standpoint, I'd much rather have the flexibility of one app per QM. |
This is about having many queuemanagers on the same server... And if it is not save enough to have different data in the same queue manager it is probably also not save enough to have different data on the same server. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 20, 2005 11:56 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| scottm wrote: |
If we have a different qmgr for each application, then if the application wants to move to a different machine all we have to do is change the channel definitions and possibly transmission queues (because of naming standards).
If they are shared one QM, and one application decided it needed it's own machine, we have to take all of it's MQ object definitions out of the current QM and add them to a new QM and create all new channels and such. |
Nya?! (A sound of general dismay and amazement)
Forgive me, truely, but all that doesn't really make much sense - I sincerely hope you don't have a channel+xmitq per application, as this is not a good MQ design, and I hope you do not name your xmits according to application but according simply to remote QM; otherwise, I don't understand why you have to change anything but QRemotes and QLocals upon transferring applications, with the occasional channel-xmit addition. Not only that, but the more QMs one has, the more one-to-one links he has, and the more channel changes will be required upon appl change; so that amounts to less flexibility, not more.
And finally, let us be honest, I know this is a good application pickup-line "yea, maximum flexibility to move between servers!", I have used it myself on occasion, but it's really not that important - how many times per day do you move applications between servers? I'd bet no more than ~0.05 on average, so the extra 2 min work either way has no real bearing on the matter, regardless of which of us is right.
(If some of what I said (for example, that the xmitq name has to be the name of the remote qm) does not make much sense to you, please open a new thread and I shall happy discuss this, since this is beyond the scope of this one...)
| scottm wrote: |
| There are also different gov't regulations (HIPAA, Sarbaines-Oxley, Medicare, ...) and require you to do certain things for the data and or machine and it could become cost prohibited to have to make those changes for all the apps that touch a QM or machine just because of one other app that requires it happens to live there. |
There was one very important point I was trying to make throughout the thread: This "change in QM parameters for the need of one application" is a VERY rare occurence, and is practically non-existant in a well-maintained environment; a change requiring QM restart, is even rarer.
If you have an example for such a QM parameter, beyond what people already mentioned here, I'd be glad to hear about it, I could be wrong. |
|
| Back to top |
|
|
| scottm |
| Posted: Thu Oct 20, 2005 11:59 am Post subject: |
|
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
While the data may be considered *safe* today to be on the same machine, tomorrow new regulations may come up that makes it *not safe*.
Plus, today we have have multiple apps on one server, and then tomorrow one app may decide to change servers.
Around here, there have been so many changes over the past year or so (some our doing, and some thanks to the gov't) that it was much easier to manage since we had multiple QM when we had multiple apps on a single machine.
As an MQ Admin - I have no rights to tell the apps that they can't move to another machine. |
|
| Back to top |
|
|
| scottm |
| Posted: Thu Oct 20, 2005 12:07 pm Post subject: |
|
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
Over the past year or so, having to change machines or other requirements (some of which could result in heavy fines - if there is downtime) has been a common occurrance, rather than the exception.
Hey - I don't make the rules, I just try to follow them. And if you suddenly had to take half of the MQ object out of a QM to move one app to another machine, then delete those objects from the current QM, that can get to be a pain. If there are in different QMs - then you can easily take one QM from one machine and place it one another.
I'm not saying you have to agree with me - but based on my reality it have been beneficial to have multiple QM. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 20, 2005 12:23 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| scottm wrote: |
| If there are in different QMs - then you can easily take one QM from one machine and place it one another. |
Ah, so you're saying it's easier for you to <tasklist>saveqmgr, install mq, crtmqm and runmqsc<config.file</tasklist> than <tasklist>DEF QR, DEF QL, and only possibly (this may be unnecessary) DEF XMITQ, DEF CHL</tasklist>? To me it seems there's more work in the former...
(Keep in mind that if you have only a few QMs on your network, instead of dozens, the chance that the chl-pair already exists is greater, thus, as stated, xmitq+chl defs will probably be unnecessary)
All that aside, as I stated many times in this thread, I still think the version+fix updates/performance problems and other maintenance tasks deem this more taxing than the alternative.
| scottm wrote: |
| I'm not saying you have to agree with me - but based on my reality it have been beneficial to have multiple QM. |
That may be it - it's "your reality" - and a very zany david-lynch type of reality it sounds; I am a consultant to over 15 sites around here, some bigger than others, and none have such a dynamic environemnt, even those large consortiums (banks and such) who are indeed prone to such regulation-based changes.
Would love to hear more about this, what regulations are you referring to? To what organizations and countries do they apply? Is it truely that bad? |
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Thu Oct 20, 2005 12:47 pm Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
| hopsala wrote: |
Would love to hear more about this, what regulations are you referring to? To what organizations and countries do they apply? Is it truely that bad? |
There are some regulations... For example here in Germany we were not allowed to transport some HR data trough our Middleware (don't ask me the exact details) and had to connect a SAP system (that is located in swizerland) with directly with Elster (A tax declaration transmission system), rather then transporting it trough our usual way.
But basically I completely agree with you... 1 QueueManager is in the most cases easier and way less hassle. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
