Author |
Message
|
brin_seb |
Posted: Thu May 11, 2006 10:24 pm Post subject: 1 broker -> 1 cfgmgr or n brokers -> 1 cfgmgr |
|
|
Novice
Joined: 10 Jun 2003 Posts: 24 Location: Luxembourg
|
Hi,
I would like to know what is the best way to do :
- 1 broker -> 1 cfgmgr
- n brokers -> 1 cfgmgr
I don't need to send informations between brokers.
Do you know where I coul found Best Practices ?
Thanks,
RA |
|
Back to top |
|
 |
pottas |
Posted: Fri May 12, 2006 1:04 am Post subject: |
|
|
 Disciple
Joined: 27 Oct 2005 Posts: 185 Location: South Africa
|
|
Back to top |
|
 |
jefflowrey |
Posted: Fri May 12, 2006 3:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
There is never a good reason to have more than one configmgr! Unless, somehow, your production environment has more than one security domain.
You can't use the configmgr to send data between brokers, anyway. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqmatt |
Posted: Fri May 12, 2006 5:34 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
There is one (albeit small) reason to have one Config Manager per broker...
If the Config Manager is hosted on the same queue manager as the broker, then the Config Manager is able to pull back unread deployment messages from the broker (if you do a broker-level cancel deploy in v6). So if you have a development broker that's being started and stopped lots, and you are trigger-happy on the cancel deploy button - then it will help keep the CM and broker in sync.
One might also argue that separate Config Managers also provide another layer of security - to prevent you from deploying to the wrong broker etc. ...but there's not really much in it.
-Matt |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri May 12, 2006 3:46 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Yes, but the only type of "development" broker that you would be deploying to frequently AND starting and stopping frequently AND on which you might be trigger happy on the cancel button would be a "unit-test" broker, which would be on your local machine and would also have it's own local configmgr... _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
vennela |
Posted: Sun May 14, 2006 7:05 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
Quote: |
There is never a good reason to have more than one configmgr! |
In that case then configmgr is a single point of failure for more than one broker right. I am sure we can HA enable the configmgr, but with V6, where configmgr can be created on most of the platforms and the ability to create multiple configmgrs on the same box, wouldn't it be wiser to have a one-to-one relationship between the broker and configmgr.
Also if the configmgr database is messed up, the piece on which we don't have much control since it's derby, we'll be at much smaller risk if it was talking to it's own broker right. I am sure the configmgr proxy api will come to the rescue in this kind of scenarios but I am just mentioning the odds here.
If there are different application people using their own broker, then they may also want their own configmgr instead of they being teamed up with another application group who are known for their production outages. |
|
Back to top |
|
 |
billybong |
Posted: Mon May 15, 2006 12:16 am Post subject: |
|
|
 Disciple
Joined: 22 Jul 2005 Posts: 150 Location: Stockholm, Sweden
|
I absolutely agree with vennela. Having a one-to-one relationship eases the administration burden when (not if) a broker gets unsynchronized with the configuration manager. Only reason to share config mgrs as I see it is if you want to use PubSub across several brokers. _________________ IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon May 15, 2006 11:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
The configmgr is not a single point of failure because the broker does not require it to be running at all!
There is no impact on production traffic if the configmgr dies. The only thing it impacts is operational use - which can be done from the command line - and new deployments (which can also be done from the command line). The only impact that comes at all is if you lose the configmgr database completely, or damage it. Then you have to reregister your brokers by deleting them and recreating them. This is a production downtime - but should fall into a normal maintenance window easily. Also, since you can stop and start the configmgr at any time, you can make sure you properly back it up!
Having a one-to-one ratio of configmgrs and brokers makes the environment insanely complicated. It's at least as bad an idea as having one MQ cluster per application!
As for application teams walking on each other's toes... that's not a technical problem - and trying to solve it using technology is the wrong approach.
There are certain types of security requirements I can see that would make having more than one configmgr a good idea. And if someone was selling Broker as a hosted application, then it would make sense. But for a normal business, it doesn't. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon May 15, 2006 2:46 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
We have one Config Manager per environment. But each of those deploys to all the Brokers in that environment.
Sure, even that is more separation than technically needed, but it feels better from a Security perpective and from a maintenance perspective. If I apply a change to the lab config manager, it gets tested before I mess with the QA or PROD config manager. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon May 15, 2006 3:18 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Peter -
I'm all for that.
I view "production" as a different security domain than "development", even if they are pointing to the same Windows domain.
I just don't see any reason to have more than one configmgr for "production". _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
brin_seb |
Posted: Wed May 17, 2006 11:32 pm Post subject: THX |
|
|
Novice
Joined: 10 Jun 2003 Posts: 24 Location: Luxembourg
|
|
Back to top |
|
 |
|