| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| mq cluster design |
« View previous topic :: View next topic » |
| Author |
Message
|
| mq4you |
 Posted: Mon Nov 27, 2006 6:34 am Post subject: mq cluster design |
 |
|
Novice
Joined: 27 Nov 2006
Posts: 11
|
hi!
we are planing to build a mq cluster. the cluster will contain multiple, identical queue managers. on top of the queue manager middleware software is installed. this kind of system is the integration layer
at our enterprise.
applications normally use a mq-client. as they do puts and gets, there is a need for a gateway queue manager. but there are also other applications that will have their own queue manager.
to differentiate the queue manager let's call them application queue managers and the others middleware queue managers.
i was thinking about if the application queue managers should be part of the cluster or not.
pro's if application qm's are part of the cluster:
queue managers communicate directly, they don't have to use the gateway qm.
loadbalancing is done locally.
less channel definitions because of the cluster.
con's
security: the cluster has to be a fully connected qm-network. if there are any firewalls between the qms, they have to be opened.
since the application qm's are part of the cluster they share the repository. so application and middleware systems are not
completely separated.
security: if the applications are able to create queues, they could create cluster queues.
other pro's and con's are apreciated.
thanx |
|
| Back to top |
|
 |
| flaufer |
| Posted: Tue Nov 28, 2006 5:30 am Post subject: Re: mq cluster design |
|
|
Acolyte
Joined: 08 Dec 2004
Posts: 59
|
| mq4you wrote: |
hi!
applications normally use a mq-client. as they do puts and gets, there is a need for a gateway queue manager. but there are also other applications that will have their own queue manager.
to differentiate the queue manager let's call them application queue managers and the others middleware queue managers.
i was thinking about if the application queue managers should be part of the cluster or not.
pro's if application qm's are part of the cluster:
queue managers communicate directly, they don't have to use the gateway qm.
loadbalancing is done locally.
less channel definitions because of the cluster.
con's
security: the cluster has to be a fully connected qm-network. if there are any firewalls between the qms, they have to be opened.
since the application qm's are part of the cluster they share the repository. so application and middleware systems are not
completely separated.
security: if the applications are able to create queues, they could create cluster queues.
other pro's and con's are apreciated.
thanx |
Hi there,
from my experience in overlapping clusters, I would try to group the application queue managers into not just one but several clusters.
This has the following advantages:
1. Applications that create cluster queues (publish them into the cluster) can only mess up their own cluster. An exception would be if you use one central getway queue manager to interconnect all cluster, which then would become member of all clusters and would be one point, where all the (unwanted) cluster queues would be visible and could make MQ send messages to them.
2. If the MQ installation on the application machines (application queue managers) is not only owned by yourself, you may find people messing around with it (duplicating queue managers, adding, removing, adding them and so forth). This may end up in a big mess and you would want to reduce this.
3. For your firewall/network issue you were thinking, you would only need to open firewalls to allow any partial repository queue manager communicate with every full repository queue manager. Partial repository queue managers would not want to talk to each other if they don't have to exchange data (correct me if I'm wrong folks).
Hope that give some new ideas to think of.
Cheers,
Felix, who has spend many nights dealing with some admin who did not understand the principles behind clustering and wanted to play around with some queue managers on his one box and thus messed up our application prod cluster and later complained that messages went somewhere they did not belong. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 28, 2006 5:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In my experience, larger clusters are better than more clusters.
In other words, only overlap clusters when absolutely necessary.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
