| Author |
Message
|
| francoisvdm |
 Posted: Tue Oct 24, 2006 11:42 am Post subject: BIG Cluster |
 |
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
I'm planning to add 650 queue managers to a cluster?
1. Will it work?
2. Any sizing issues on primary repositories?
3. Any gotchas?
Thanks
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Oct 25, 2006 2:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Now that's a BIG cluster... 
Certainly outside my experience - I've had 15 queue managers in a single cluster but past that I tend to split into smaller clusters and link them.
As to your questions:
1) When you find out, let us know. 
2) They're likely to be on the large side. Check the Clustering manual for the amount of retained information, multiply by 650 & add a margin
3) The amount of network traffic as registration occurs is likely to be impressive. You also should pay more attention than normal to the placement of the FRs and their availability. Make sure that they are positioned evenly through the cluster to prevent network bottlenecks.
Out of morbid curiosity, why so many in a single cluster?
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Wed Oct 25, 2006 3:46 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 25, 2006 3:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Even in this case, a bigger cluster is probably better than more clusters. The last thing anyone wants is a cluster for each application, and Cluster namelists with hundreds of names.
Maybe Francoisvdm is running a qmgr on every employee's desktop.
Other than Vitor's very salient point about the position and sizing of the FRs, the really important thing to remember is that clusters try to create a fully connected network. So you may have network communication and messages moving over links that you aren't necessarily expecting.
If some of those links are bandwidth-expensive, then you may want to make smaller clusters, with single-point overlapping clusters.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 25, 2006 3:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| Even in this case, a bigger cluster is probably better than more clusters. The last thing anyone wants is a cluster for each application, and Cluster namelists with hundreds of names. |
Absolutely. Drawing the boundaries for each cluster (not too large & not too small, where "large" and "small" are subjective) is a serious planning exercise. The number of clusters you have is as important to manage as the number of queue managers to a cluster.
| jefflowrey wrote: |
| Maybe Francoisvdm is running a qmgr on every employee's desktop. |
I wish I could get budget for that many queue manager licenses. Or a tenth of them. Every application in the place running on a single queue manager like angels on the head of a pin. This is their only angelic attribute! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Wed Oct 25, 2006 4:06 am Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
It is for a retailer - 1 queue manager in every store
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 25, 2006 4:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Fair enough. 
Still envy you all that resource though....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 25, 2006 4:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If it was me doing this (and bear in the forefront of your mind it isn't!) I might still be inclined to see if there was a natural subdivision (perhaps by region) into smaller clusters. Taking the previous comments re cluster size & number into full account of course!
But your decision absolutely.
If you do go with one cluster, please post your experiences. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Wed Oct 25, 2006 6:16 am Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
I rceived one reply where somebody had a cluster of 1300 queue managers, but this person could also not help on "how to prepare for impact".
I'll do more research and see what happens.
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 25, 2006 6:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Francoisvdm wrote: |
| somebody had a cluster of 1300 queue managers |
| Francoisvdm wrote: |
this person could also not help on "how to prepare for impact".
|
Perhaps the cluster hit him a bit too hard... 
I await with interest the results of your efforts.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Oct 25, 2006 1:00 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| Francoisvdm wrote: |
| It is for a retailer - 1 queue manager in every store |
so do all stores need to communicate with each other? or is just to the hub? if the latter, why the need for clustering in this situation?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 25, 2006 1:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Michael Dag wrote: |
| Francoisvdm wrote: |
| It is for a retailer - 1 queue manager in every store |
so do all stores need to communicate with each other? or is just to the hub? if the latter, why the need for clustering in this situation? |
Reduced channel Admin perhaps?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 25, 2006 1:08 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Reduced channel admin is not a bad reason to put in a cluster.
But if putting in a cluster opens up security holes - one store writing directly to another, for example - then reduced channel admin may not be a good reason to put in a cluster.
In general, I would not consider an MQ cluster topology for a hub-spoke architecture, at least for the first choice. Channel setup in a *real* hub/spoke is going to be exactly the same as for a cluster - one channel to the hub and one channel to each spoke or one channel to an FR and one channel back. Either way, four objects on two queue managers.
But if Francoisdvm is not doing a strict hub/spoke - but rather a CO group of queue managers in a cluster - then I'd just add the stores to the CO cluster.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| flaufer |
| Posted: Tue Nov 28, 2006 5:38 am Post subject: Re: BIG Cluster |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
| Francoisvdm wrote: |
I'm planning to add 650 queue managers to a cluster?
1. Will it work?
2. Any sizing issues on primary repositories?
3. Any gotchas?
Thanks |
As far as I know:
Clustering means: One cluster transmission queue.
When you end up with some boxes connected via very slow networks to one single gateway and a message volume that may end up in a very large number/amount of messages/data in the S.C.X.Q, you'll probably end up with the queue file filling up and something weird happening.
We were having one big cluster with about 300 queue managers connected to one single gateway queue manager and the system cluster transmit queue was regularly filling up because some endpoint queue managers were undersized, the receiving endpoints were unaivailable (in big companies, somebody may suddenly decide to patch all 2000 windows servers and they all go down at the same time :().
Felix |
|
| Back to top |
|
|
| KeeferG |
| Posted: Tue Nov 28, 2006 9:58 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
650 is a reasonable number for a single cluster but MQ should have no problems handling it. The largest I have seen was around the 3000 mark. I know that work was done to handle systsems this size.
Obviously you will need to look into how many cluster objects you are generating in total as these will reside on the internal cluster queues so you will need to ensure maxdepths and file system space is available.
If possible ensure you have your two full repositories running on some type of HA system such as a Veritas Cluster to ensure as much up time as possible. On a large systems you really do not want any full repository down time if you have a dynamic cluster.
Also consider how often the repositories are being used. Will new cluster objects be created often. Will you be using put disabled queue properties that propogate around the cluster.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Dec 18, 2006 1:33 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
We have one with around 2500 qmgrs. My first question to you is, what platform(s) are involved?
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
|
|
