| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Multiple Queue manager to separate environment |
« View previous topic :: View next topic » |
| Author |
Message
|
| Jean-Luc Oudart |
 Posted: Fri May 07, 2004 2:41 am Post subject: Multiple Queue manager to separate environment |
 |
|
Newbie
Joined: 13 Apr 2004
Posts: 4
Location: Ireland
|
Dear experts,
Could you tell me the pros & cons of having one Queue Manager for all my live environments or one per environment (same Server):
- maintenance
- security
- scalability
any issues ?
Websphere MQ 5.3 on HPUX 11.0
thanks,
Jean-Luc |
|
| Back to top |
|
 |
| Missam |
| Posted: Fri May 07, 2004 11:07 am Post subject: |
|
|
Chevalier
Joined: 16 Oct 2003
Posts: 424
|
| you can use one server for developing,testing,UAT.But it's good to put the production box on a different server from the above. |
|
| Back to top |
|
|
| Jean-Luc Oudart |
| Posted: Sun May 09, 2004 11:52 pm Post subject: |
|
|
Newbie
Joined: 13 Apr 2004
Posts: 4
Location: Ireland
|
This is to separate different Live (production) environments.
Test & UAT are on a different server.
Jean-Luc |
|
| Back to top |
|
|
| jsware |
| Posted: Mon May 10, 2004 4:02 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
Typically I would keep a single production queue manager. However, there may be a few reasons to have multiple ones.
Maintenance:
Since you have a single software installation, you can't upgrade without downing all the QMs. However, you could down a single QM, back it up and start it again without affecting the others (the files to backup are in different directories).
Security:
You can assign authority to groups only (assigning to principals causes MQ to authorise that principals primary group so beware). The thing that strikes me first is that to support sending reply messages based on the ReplyTo* fields in the MQMD requires you to give put authority to transmission queues unless you do something clever with QM aliases or whatnot. You might be able to limit the risk by separating QMs by application - however this *wont* be water tight. (The problem with reply to messages and transmission queues is that a group authorised to put to a xmitq can send a message to *any* queue on the destination qm, or to any qmgr that the destination qm knows how to deliver to - using put authority settings on channels may also be able to mitigate this risk).
Scalability:
Multiple queue managers adds a few more standard processes to the mix and allocates a few more resources. We have many qms running in non-production environments without problems. Running multiple qms doesn't make the amount of work you can do on a box increase (IMHO).
However, if you can control CPU utilisation by user ID (as you can on AIX5) you could run different QMs under different IDs and max QMGRA at 25% of machine utilisation and QMGRB at 75%.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
