| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Best Practices |
« View previous topic :: View next topic » |
| Author |
Message
|
| Pavan Kumar PNV |
 Posted: Mon Aug 01, 2011 8:16 am Post subject: Best Practices |
 |
|
Acolyte
Joined: 03 Feb 2007
Posts: 66
|
Under what circumstances would it be ideal to create a new svrconn channel? If we have a shared queue manager, how many client applications (different functionality) should be allowed to use the same svrconn channel.
Also, when would it be ideal to create a new queue manager on the same host. I have seen a thread http://www.mqseries.net/phpBB2/viewtopic.php?t=56223&sid=6cd2cc0deda2a3be273fcb8cb1802598 that speaks to this point, but for what exact reasons would you need another queue manager? In other words, when would you isolate traffic onto another queue manager?
_________________
_____________
Pavan Pendyala
http://pavanz.blogspot.com |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Aug 01, 2011 8:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The answer to the first depends on the model you're using for MQ security. If you're using the built-in functions, then the answer is "every time you need to provide a different security role".
The answer to the second is "it depends". |
|
| Back to top |
|
|
| SAFraser |
| Posted: Wed Aug 03, 2011 9:50 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
A new svrconn definition is cheap from a system resource perspective, while a queue manager is expensive. If we can accomplish our requirements for 1) segregation of traffic and 2) OAM security, we use a new svrconn rather than another queue manager.
This works for us because our queue managers support a single large project. Our need to segregate traffic and secure MQ objects is a way to protect applications from each other.
If our infrastructure supported diverse projects (especially with connections from discrete trading partners), we might need to consider separate queue managers.
We do create multiple queue managers on a single host for different development environments (such as UAT, SIT, etc). We do not like doing this, as a single queue manager could easily service all environments together; however, our development teams are not willing to use unique queue names and channel names for different environments.
For example, a single queue manager might have queues named UAT.ACCOUNTS, SIT.ACCOUNTS, etc. In our case, the queue ACCOUNTS simply exists on multiple queue managers, each dedicated to a single development environment.
mqjeff said it best: "It depends."  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 03, 2011 10:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Robust systems have more than one of something that offers a single-point-of-failure.
I use the term robust systems to encompass computer hardware, cars, planes, security systems, ...
There is a point of diminishing returns in all systems where the increase in redundancy imposes additional risk. Jets with 4 engines have proven to be less reliable than those with 3 engines. More moving parts, more complexity.
One qmgr per application type may make sense, in order to isolate that application from other less critical and stable apps. Then again, finance has its tentacles in all other app areas; so, maybe one big all-application qmgr might work, too.
TEST, QA, and PROD, are usually on separate qmgrs, even on separate hardware or VMware images in a single hardware platform.
"It depends" works for me, too.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| 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
|
|
|
|
