| Author |
Message
|
| MQooch |
 Posted: Mon Jul 01, 2002 8:27 am Post subject: Platform communication capacity? |
 |
|
Novice
Joined: 11 Dec 2001
Posts: 12
Location: Randy
|
If I have a clustered environment with a large number of QM's(over 1000)...and only two repositories...am I limited to certain single box platforms?
I'm wondering this because of all the transaction updates to the repository when all the QM's are updated at the same time.
Is there a reference to these type of questions?
When clustering everything should the number of QM's involved and configuration repository overhead dictate the number of clusters involved in the entire environvent...2000(1 cluster) vs 500x4(4 clusters)?
Any help would be appreciated!
Thanks,
Randy Collins |
|
| Back to top |
|
 |
| kolban |
| Posted: Mon Jul 01, 2002 9:03 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
In principle, you can have as many queue managers as you like in a cluster. When a resource is referenced on any one queue manager, that queue manager then dynamically learns of its existence and details. Only when that resource is changed in some way, is the change propagated and even then only to those that have previously expressed an interest in such.
If you have a large but relatively static environment, the amount of overhead traffic should be slight and trivial. I would not be concerned about capacity issues.
If there were large numbers of dyanimc clustered changes, that may be a different story. |
|
| Back to top |
|
|
| MQooch |
| Posted: Mon Jul 01, 2002 10:50 am Post subject: |
|
|
Novice
Joined: 11 Dec 2001
Posts: 12
Location: Randy
|
My environment will not stay static...if I add 10 new queues to 2500 QM's then I will get 25000 msg's to a single repository.
In testing my single box holding the repository has locked up with a fraction of those individual boxes with QM's on them trying to communicate with that single box.
Does Any one know of a reference to a single platforms ability to communicate with a large number of individual platforms?
Thanks for the reply!
Randy |
|
| Back to top |
|
|
| kolban |
| Posted: Mon Jul 01, 2002 11:49 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
... hmmm ... there seems to be something intrinsically wrong here. In a clustered environment, if you added 10 queues to 2500 QM's, why would you want to make those cluster visible?
I can't even imagine adding one cluster shared queue to 2500 QM's? Perhaps you could elaborate on your thinking of adding a cluster shared queue to the end QM based machines? |
|
| Back to top |
|
|
| MQooch |
| Posted: Mon Jul 01, 2002 1:15 pm Post subject: |
|
|
Novice
Joined: 11 Dec 2001
Posts: 12
Location: Randy
|
My reasoning for adding all the QM's to the cluster was to cut down on channel definitions. The monster created is that any modification in any QM'er causes the repository's to be updated.
The need was to allow each site to communicate with each other. Most of the 2500 communicate with just two boxes each hold a repository with all the others having machine A as the cluster-sender defined channel. If I add a queue to all the boxes except the two holding the repositories, won't the repository need to know about thast from all the sites?
Thanks,
Randy |
|
| Back to top |
|
|
| kolban |
| Posted: Mon Jul 01, 2002 2:52 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
... Absolutely not. Just because you add a queue or other resource to a queue manager that is part of the cluster doesn't mean that information about that respurce has to be distributed. Each resource (such as a queue) has a "CLUSTER" attribute. If that attribute is not set then the resource is still created but is just not cluster visible.
I would imagine that you would want to add cluster visible resources to your "server" queue managers located at HQ. Each "store" would then be able to see these queues. I can't imagine that you would want to cluster expose any queues local to the stores. |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon Jul 01, 2002 6:35 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
However, MQooch is correct about the number of channels. Even if a large number of the 2500 queue managers are not hosting any clustered queues, if they are a member of the cluster, then they must have a cluster sender and cluster receiver channel going between each of the two repositories. In other words, each repository would have 5000 channels. Now, why you would have a queue manager in a cluster if it isn't hosting any clustered queues is beyond me, but I do see the point that the repositories could become bogged down with such a large number of channels.
I have experience in this area. At a previous company, we had a single NT queue manager with static channels going to about 3000 queue managers (one for each of our stores). The poor thing became so bogged down that we had to write a program that would manually stop a large number of channels, and only start a subset of the 3000 sender channels. These channels would be allowed to run for a few hours, then they would be stopped, and others started. This way, at any time we only had 500 or so channels running. But this meant there was only a particular window during the day for each store to send/receive data with the NT server, and if a particular message missed the window, it would have to wait until the next day. Obviously not the optimal solution. However this was running MQ5.0, and the NT box wasn't very powerful. Oh yeah, the other big difference was that this system was static, not clustered...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nimconsult |
| Posted: Mon Jul 01, 2002 10:56 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
I fully agree with the remark of Brandon. To correlate this remark with the initial question of MQooch:
"When clustering everything should the number of QM's involved and configuration repository overhead dictate the number of clusters involved in the entire environvent...2000(1 cluster) vs 500x4(4 clusters)?"
The question is not about the number of clusters that you should put in place, but about the number of repositories.
If you have 4 repositories instead of 2, then each repository will have one fourth of the channels (1000 channels + 3 * 2 channels to the other repositories), instead of half the channels (2000 channels + 1 * 2 channels to the other repository).
You can run 1000 channels on a W2K box with MQ5.2 and min 512MB.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Jul 02, 2002 4:16 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Imagine a scenario where you have 2000 stores. Each store is sending sales information to the HQ in a trickle feed. When a purchase is made, information about the sale (product, amount etc) are sent back to HQ. Instead of making an explicit channel sender/receiver pair, you make the store part of a cluster, thus the channels are dynamic. Next, the sales receipt information either can not be sent to one queue manager (because of capacity or redundancy), so you create a set of HQ "SALES_QUEUE"'s at multiple server queue managers at HQ. These queues are all cluster visible and hence the stores can round-robin between them or else bind dynamically to a single HQ.
If you also make the idle timeout of the store small (say 10-30 seconds - guess), then on average, only a subset of stores will have active channels.
Now look and see what you have ... unless you actually change the information about the "SALES_QUEUES"s, no overhead information is ever sent (other than initially) from HQ to the store ... you have a static cluster with all the benefits as well as distributed workload ...
This conversation is getting really interesting  |
|
| Back to top |
|
|
| MQooch |
| Posted: Tue Jul 02, 2002 5:30 am Post subject: |
|
|
Novice
Joined: 11 Dec 2001
Posts: 12
Location: Randy
|
I appreciate all the input on this matter! I read minconsult's comment about a w2k box handeling a 1000 channels...we have a choice of using AS400's model 170's at a gig, or 4-way NT's at 2 gig. My guess is that niether will work in a one cluster configuration unless I can point the boxes to more repositories.
My reason for asking the question about 500X4(Clusters) was that each cluster in that configuration would have two repositories and be handeling a max of 1000 channels.
What I have learned is that when you make the commitment to cluster you not only take on the production volume you take on the repository updates.
I guess I'm still wondering if I add a queue to a non rep. QM'er the cluster-sender of that QM'er does update the defined repo. it was pointing to when it was created...right?
I can not see anyway to salvage the one cluster archetecture, but I would certainly pose that question to you all.
With much respect,
Randy |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Jul 02, 2002 7:17 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Nicolas,
As far as I know, it doesn't matter how many repositories you have in your cluster. Every defined queue manager designated as a repository contains a full repository, as oppossed to the partial repositories on the other members of the cluster? The difference? The full repository contains definitions of all objects in the cluster whether that particular queue manager has used them in the past 90 days. On the other hand partial repositories only contain definitions for those clustered objects that queue manager has interacted with in the last 90 days. So just because I go from 2 repositories to 4, doesn't mean that each repository is storing half as much data in its repository.
Furthermore, while you only explicity define a cluster sender channel and cluster receiver channel between a queue manager and one of the full repositories, you'll notice after doing so that channel pairs to all the other full repositories are automatically created on this queue manager. So again, regardless of how many repositories you have in the cluster, for each full repository, there is a channel pair going between it and every other queue manager in the cluster.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Jul 02, 2002 11:57 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
I knew that full repositories by definition hold the entire configuration. My point was to split the number of connections to full repositories on a higher number of machines.
What I have learned from you however is that each queue manager open a channel to every full repository of the cluster. Which mean that my proposal of 4 full repositories does not work. Thank you for the lesson Brandon.
I keep on the fact that a W2K box supports 1000 channels because I have performed such a load test on a non-clustered configuration.
Regards,
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| MQooch |
| Posted: Wed Jul 03, 2002 9:08 am Post subject: |
|
|
Novice
Joined: 11 Dec 2001
Posts: 12
Location: Randy
|
I want to thank everyone that has provided input on this matter.
I am working on trying to find a solid reference that will provide clear differences between max channel requests capability of various platforms...AS400, OS390, NT, and so on.
Once I know this, my design will then go forward based on calculated repository updates by the total number of QM's. My feeling is that I will need to stay around 600 QM'ers per cluster...if using just two boxes in that cluster. This will mean my full repository server would need to handle 1200 channels.
I'm sure there is a server out there that can handle many more channels open to it, I just haven't found it yet.
I compare this to putting 1200 people in a line and running them through the front door of my house...no problem. Now if I line all them up all alone the curb of my house and let them know the first onr through the front door wins $1000...I have a problem with congestion and sending anyone out that front door.
Again I hope the best for everyone over the holiday,
Randy |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Jul 03, 2002 9:45 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Randy,
I'm assuming it would come down to the amount of resources each MCA (message channel agent) consumes. I'm not sure about semaphores, etc., but one of the MQSeries manuals tells how much memory each one requires... Just can't remember where exactly.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| MQooch |
| Posted: Wed Jul 03, 2002 12:46 pm Post subject: |
|
|
Novice
Joined: 11 Dec 2001
Posts: 12
Location: Randy
|
Brandon,
Thanks for the help...I will get the shovel and start diggen. I know there has to be something more accesible on this because of its importance on overal design when clustering.
Have a great July Blast!
Randy |
|
| Back to top |
|
|
|
|
