| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Clustering - General |
« View previous topic :: View next topic » |
| Author |
Message
|
| rammer |
 Posted: Mon Feb 09, 2004 7:33 am Post subject: Clustering - General |
 |
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
This is a general question regarding Clustering Design.
Currently we have 14 overlapping clusters, which did work to a certain degree on 5.2 but we did get the usual clustering problems.
We have since reversed this making it temporary to traditional remotes queues whilst we had a rethink on our clustering solution and upgraded to 5.3. CSD4. On our development servers it does appear that the new cluster commands do give you greater control over fixing problems that occur within clustering.
Being as we have virtually stripped out clustering but do need to put it back in we have the chance to switch from 14 clusters to one big one, which may ease administration etc. All clusters belong to the same company and are only created for each new project that comes along, so some only have 3 or 4 queues in them. They are also adminstrated by the same team so security etc should not be a reason for needing many clusters.
My question is does anybody have any ideas what other benefits there are having many overlapping clusters instead of one cluster.
What limitations there are in size, number of objects can be stored in one cluster.
Is there a limit to the number of overlapping cluster you can have ie, how many entries can a namelist store? |
|
| Back to top |
|
 |
| andye |
| Posted: Tue Mar 02, 2004 10:37 am Post subject: |
|
|
Newbie
Joined: 11 Nov 2003
Posts: 7
Location: HURSLEY
|
Hello rammer,
From your description it sounds like you have only one queue manager on the server shared in many clusters. Would it be better to have seperate queue managers for each project. Each project could have its own cluster which doesn't need to overlap with others, and you wouldn't have to worry about namelist size restrictions for sharing the cluster receicers.
With regards to limitation on size, at 5.3, the cache for the repository manager proces (amqrrmfa) is dynamic, whereas at 5.2 versions, a que ue manager recycle was needed to create more space for the cache if it filled.
Hope this is useful. If i've got the wrong end of the stick, please repost with more details about number of QMs, full repositories etc.  |
|
| 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
|
|
|
|
