| Author |
Message
|
| scottm |
 Posted: Thu Oct 20, 2005 12:51 pm Post subject: |
 |
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
What I'm say is:
QMA on machine A happens to have 3 apps using it. There are 50 queues and 20 channels.
App1 decides it is going to get it's own box.
Now we have machine A and machine B.
To get app1 working, we will need to get it's MQ objects, and only it's MQ objects and re-create them over on machine B in a new QM QMB. Then we have to go through QMA and remove those objects. But, be careful and don't remove any that another app happened to share with app1 (transmission queues, channel).
But, if we had QMA and QMB both on machine A and app1 decided to get a new machine - all we'd have to do is move QMB over to machne B and we'd be done.
Of course, there are the common tasks of possibly changing channel names or transmissions queues, or channel connection strings but they are common tasks so I won't bother going through them.
And this type of QM movement seems to be more common than you'd think. Especially when it deals with WebServers. |
|
| Back to top |
|
 |
| sebastianhirt |
| Posted: Thu Oct 20, 2005 1:05 pm Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
| scottm wrote: |
To get app1 working, we will need to get it's MQ objects, and only it's MQ objects and re-create them over on machine B in a new QM QMB. Then we have to go through QMA and remove those objects. But, be careful and don't remove any that another app happened to share with app1 (transmission queues, channel).
|
Sorry, but that's a bad excuse. If you know your environment well enough, that's done in a matter of minutes. And as you say it yourself. All the "changing tasks" you'll have to do anyway. So where is the point then in having many queue managers against one per server.
| Quote: |
And this type of QM movement seems to be more common than you'd think. Especially when it deals with WebServers. |
And if your applications are moving this often, then I would call that bad design and planing. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 20, 2005 1:41 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
I dunno Scott. I will prefix this by stating the obvious: I don't work where you do and don't have all the background details. But based on what I have read so far, the MQ setup you have there is designed so that it doesn't perform as well as it could, and is more complicated than it needs to be. But again, I don't have all the background details.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 20, 2005 2:54 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| I'd like to elaborate on what peter said, and have done so in WMQ General \ Discussion of a specific setup since it doesn't specifically apply to "how many qms per machine" but to more general design questions (must maintain order, n'est pas?). So if you're interested in discussing this, join me in the other thread. |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Oct 21, 2005 7:29 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Another reason to have more than one qmgr per box can be related with type of logging, some applications may need linear logging, some don't have any special request. In this case at least to qmgrs are nedded.
There are also some (I've never seen using it...) tunning paramters like q buffer size and q file size and they are per qmgr, coded inside qm.ini
It may be more complex to have several qmgrs per box, but when in the organization department A asks "what is happening with Mq?" the first thing to check is if qmgr for deparment A is running.
Regards |
|
| Back to top |
|
|
| ucbus1 |
| Posted: Fri Oct 21, 2005 8:40 am Post subject: |
|
|
Knight
Joined: 30 Jan 2002
Posts: 560
|
May be I am missing something here.
I use MQ Workflow and have two conigurations FMC and FMC1 catering entirely to different divisions. Now MQ Workflow creates one queue manager for each configuration.IBM says it is the best practice.
Can somebody tell me why IBM says so if having one QM is the right practice? |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Oct 21, 2005 8:46 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
ucbus1
Probably because when you run the workflow configurator on Windows it creates a new queue manager and all of the objects needed for you.
Goodness knows what it does with the FDL too.  |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Oct 21, 2005 11:32 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| ramires wrote: |
| Another reason to have more than one qmgr per box can be related with type of logging, some applications may need linear logging, some don't have any special request. In this case at least to qmgrs are nedded. |
Interesting point, but like I stated in many previous discussions - logging setup, IMHO, is more complex than it's worth, and was designed when bytes didn't grow on trees; Nowadays you can get a 100GB HD working for you easy, so why bother with configuration? 99 times out of a 100, just use circular logging taking up all your HD, and forget about archiving hassles. (you can note that I implicitly state that image recovery is unnecessary as well)
| ramires wrote: |
| There are also some (I've never seen using it...) tunning paramters like q buffer size and q file size and they are per qmgr, coded inside qm.ini |
Q file size is not a parameter, it grows and diminished according to usage, and Q buffer size is a constant 64KB (see WMQ5.3 WinXP / Queue Files - Research).
Only in z/OS can you change these, and then they may be configured per-queue (it's a bit more complex than that, but it's easily attainable).
| ramires wrote: |
| It may be more complex to have several qmgrs per box, but when in the organization department A asks "what is happening with Mq?" the first thing to check is if qmgr for deparment A is running. |
Or, just checking if the QM on the central machine is running, no difference... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Oct 22, 2005 7:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20765
Location: LI,NY
|
hops,
I assume that when you talk about not wanting linear logging the bulk of your messages is not "send and forget with assured delivery". That type of a load may want you to reconsider your options....
 |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 22, 2005 9:48 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| fjb_saper wrote: |
| I assume that when you talk about not wanting linear logging the bulk of your messages is not "send and forget with assured delivery". That type of a load may want you to reconsider your options.... |
Well, yes and no: You're right that scenarios in which you have persistent send-and-forget msgs are more complex, while in the rest circular logging is easiest and probably best. But what I really meant was that since in most cases you have, say, 100MB thoughput per day and a 100GB HD at your disposal, I would simply define a 50GB circular primary pool or similar, forgetting the hassles of linear logging. So the question is, how often are queue damaged, and is it worth the extra administration? I say not really.
Truth is, I don't know any critical send-and-forget applications that are truely without some message replay abilities, usually if it's important enough (stock exchange, banking, airports) the programmers refuse to trust MQ and save up about a day's worth of activity in application logs (or it's an old appl with this feature already there), thus I may happily relinquish the pleasures of linear management. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Oct 22, 2005 9:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
When it comes to the enterprise, I much prefer to wear both a belt and suspenders.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ramires |
| Posted: Sat Oct 22, 2005 3:43 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Whit circular logging its not possible to recreate a damaged queue, if necesary.
| Quote: |
| Q file size is not a parameter, |
Queue file can be changed with this stanza in qm.ini, this is valid for v5.3. I don't know about v6.
TuningParameters:
DefaultQBufferSize=128000
DefaultQFileSize=1000000000
There is a support pack mention its use, it's MP01. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 22, 2005 4:02 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jefflowrey wrote: |
| When it comes to the enterprise, I much prefer to wear both a belt and suspenders. |
But if suspenders require maintenance and constant monitoring, I'd consider settling for a belt, especially since it's a 100% safe fortified-steel belt... 100% * 100% = 100%, hence one is redundant. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 22, 2005 4:16 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| ramires wrote: |
| Whit circular logging its not possible to recreate a damaged queue, if necesary. |
Of this I am aware, that's why I said:
| hopsala wrote: |
| So the question is, how often are queue damaged, and is it worth the extra administration? I say not really. |
I'd add that if indeed you have message-replay capabilities, you don't need to recover damaged objects - just delete and recreate.
| ramires wrote: |
TuningParameters:
DefaultQBufferSize=128000
DefaultQFileSize=1000000000 |
No wonder I couldn't find this in the manuals (when you mentioned this as a parameter I looked), it's simply not there! thanks for the new info! 
But, If you'll carefully read the section "Opening Queues" you'll see that it is possible (though in a somewhat crooked way) to create some queues with so-and-so buffer and file size, and others with another, so that's not a valid reason for an additional QM on the same machine... |
|
| Back to top |
|
|
| mqdev |
| Posted: Tue Apr 17, 2007 1:29 pm Post subject: |
|
|
Centurion
Joined: 21 Jan 2003
Posts: 136
|
Hopsala,
Maybe this is an old topic - would like to add my 2 cents!
One of the earlier clients that I consulted with, had a huge Cluster in Production (1000+ QMs)- it was a chain of stores and each store had a QM.
We had to simulate a reasonably big cluster in lab just to run a few tests and we had at disposal, just a handful of boxes. We created a mini-MQ cluster with about 50 or so QMs on each box (had 3 boxes - totally had about 150 - 200 QMs in the test cluster). This was one occasion where I used multiple QMs on a single box.
Yet another situation is a Gateway QM into a Cluster of QMs (pre v6.0 does not round-robin messages if the Cluster Q instance happens to be local). Thus QMA and QMB which are clustered with others have another set of QMs - QMA-GW and QMB-GW also clustered with other QMs and Apps connect to the GWs instead of the QMs straight to be able to round-robin in the cluster.
Cheers
-mqdev |
|
| Back to top |
|
|
|
|
