Author |
Message
|
SAFraser |
Posted: Mon Oct 15, 2007 10:15 am Post subject: Number of Brokers per Domain: Practical Limit? |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
Environment that will have additional brokers:
WMB 6.0.0.3
Windows 2003, SP1
4 Gb RAM
2 multi-threaded 3.00 Ghz CPUs
I am working towards retiring a Configuration Manager server, and moving its brokers to an existing Configuration Manager.
I've been looking here as well as at Redbooks to see if there is a practical limit as to how many brokers can be created in a broker domain. In other words, should I add the the additional brokers to the existing domain or create a second domain?
I only have about 20 brokers on the current domain (each with six execution groups and 25 message flows), but I notice when I open the Broker Topology, it takes about 2.5 minutes. During that time, the CPU is not much used nor is there execessive use of memory.
So my thought is: It is just loading a lot of data, it is perfectly normal, and putting another 10-12 brokers into this domain is quite safe. I know from other posts that broker domains can be very large.
Thoughts? Experience?
Thank you,
Shirley |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Oct 15, 2007 10:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Remember that in v6.0 and earlier, you have to delete a broker in order to register it with a different configmgr.
Remember, also, that the performance of the Broker Topology has much much more to do with the machine that the Toolkit is running on, than with the machine the ConfigMgr is running on. These might be the same. You can also look at increasing the JVM heap of the Toolkit to improve it's performance. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
SAFraser |
Posted: Mon Oct 15, 2007 11:33 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
You mean, delete the definition of the broker in Broker Topology in its Configuration Manager, correct? Not delete the actual broker (mqsideletebroker)?
I believe we did this successfully in 2.1, although there were oddball records in the broker's local store that we had to clean up manually.
I don't mind waiting for the Broker Topology to load.... I just wondered if it indicated anything unhealthy. |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Oct 15, 2007 11:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
You're talking about changing which ConfigMgr the Brokers are Registered with, right?
You need to use mqsideletebroker to do that, unless you want to really really muck around in both the Broker db and the ConfigMgr registry. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Oct 15, 2007 1:53 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If you're on 6.0 and moving the whole domain, just move the configmgr. The procedure is well described. We followed it and were successful the first time around.!!
Note: we did not change version, just host and qmgr...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Oct 15, 2007 6:16 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Right - to be clear.
Are you planning on going from Two ConfigMgrs on Two machines - to Two ConfigMgrs on ONE machine?
Or to ONE ConfigMgr on ONE Machine?
If the later, you need to mqsideletebroker. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqmatt |
Posted: Tue Oct 16, 2007 1:45 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
OK, so this is part helpful reply, part plug.
But... the v6.1 Config Manager will discover configuration information directly from a running broker. This means that:
1) a CM can "adopt" brokers, which effectively allows you to move brokers between Config Managers.
2) the CM will periodically synchronise itself with the broker,
3) there is a now lot more configuration information available to the CM (e.g. mqsireportproperties stuff, such as JVMDebugPort).
Cheers
-Matt |
|
Back to top |
|
 |
SAFraser |
Posted: Tue Oct 16, 2007 7:29 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
I have two Config Mgrs in development.
One runs on a real server in a real data center with real backups and real UPS. It services about 20 brokers in one broker domain.
The second Config Mgr is on a desktop with WindowsXP in a converted-closet-server-room, plugged into God-knows-what type of power and with no backups. It hosts 7-8 of the most important of the development brokers.
I want to move these 7-8 brokers to the Real Server, and let the desktop die a dignified death.
I didn't think this would be a big deal. I thought what I would have to do is:
Remove the broker from the domain on the Old-Bad Config Mgr.
Create/alter channels between the broker server and the Good-Server Config Mgr.
Create the broker on the Good-Server Config Mgr.
Deploy message sets and flows, which effectively tells the Config Mgr what the broker already has.
Possibly: clean the broker local store of obsolete entries in bclientuser and bsubscriptions.
In 2.1, we split one Config Mgr into two, and moved brokers in the process. As I recollect, it was tedious but it worked.
Now I am doubting my own recollection. Maybe it's all different with 6.0; I've been away from broker for two years. I'm just not getting why the broker must be deleted. I know I'm missing something here.
Love the idea of adoption in 6.1 Now where did I see the 6.1 release date posted?
More thoughts welcome. I appreciate your continued patience with my questions. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Oct 16, 2007 8:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
When you do step 1) Remove the Broker from the domain on the old/bad configmgr... it tells the Broker to get ready to be deleted.
Before you can do step 3) Create the Broker on the good-server ConfigMgr, you have to run mqsideletebroker and mqsicreatebroker, so that the broker is in a "ready to be registered with a configmgr" state.
This has been true since 2.1. You may have done funky things with the configmgr and broker database at that point - I even think there used to be something resembling instructions. You can't muck with the ConfigMgr internal repository in v6 - without using the ConfigMgr Proxy API.
Or you could wait a couple of months, until v6.1 is released, and upgrade ONLY YOUR CONFIGMGR on the good server, and see if you can then migrate the brokers without deleting them. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mqmatt |
Posted: Tue Oct 16, 2007 8:21 am Post subject: |
|
|
 Grand Master
Joined: 04 Aug 2004 Posts: 1213 Location: Hursley, UK
|
SAFraser wrote: |
Love the idea of adoption in 6.1 Now where did I see the 6.1 release date posted? |
Planned eGA date is end of November. |
|
Back to top |
|
 |
SAFraser |
Posted: Tue Oct 16, 2007 8:25 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
Shoot, darn it, phooey.
Okay, I get it now. I guess I better evaluate the impact of various alternatives... the issue is *always* downtime for the developers and testers.
6.1 sure sounds good. Maybe I'll wait, as I am knee deep in a thus far fruitless attempt to upgrade MQ to v6.0. November is not far away at all.
Thanks to everyone for the great contributions.
HEY. Will my next post make me a Master? Is it 200 that does it? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 16, 2007 8:39 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
What you could do is back up the DB of the XPConfigManager after you've stopped it on the XP desktop.
Then go and recreate a QM and CM by the same name on a real server in the server room , XPConfigManager.
This new XPConfigManager will have the same friendly name, but under the covers has differnet internal IDs. Now take your DB backup from the original XPConfigManager and overlay the new XPConfigManager's DB. The new XPConfigManager is now seen as the original one.
Change the CONNAME parm in the SNDR channels on the Brokers to point at the new hostname.
We've done this as a test in the LAB. Thankfully we've never had to do it in production. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Oct 16, 2007 9:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Of course, there isn't a "DB" for a v6 ConfigMgr.
but you can use mqsibackupcfgmgr or whatever it's called, and do the same trick - but much easier. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
SAFraser |
Posted: Tue Oct 16, 2007 10:05 am Post subject: |
|
|
 Shaman
Joined: 22 Oct 2003 Posts: 742 Location: Austin, Texas, USA
|
So then we would have:
Two Config Mgrs on two servers
-- become --
Two Config Mgrs on one server
Then... if I didn't want/need two Config Mgrs on one server, I could wait for 6.1 and migrate them gracefully to a single Config Mgr.
Am I understanding this correctly? |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Oct 16, 2007 10:09 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Correct.
And I just noticed both of your CMs are at 6.0 already, so both can live on the same server and like Jeff said, forget the "DB" part and use the config manager commands to export and restore. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|