| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| QM Bridge (Qmgr Alias) Vs Overlapping Clusters (Namelist) |
« View previous topic :: View next topic » |
| Author |
Message
|
| rajln |
 Posted: Mon Nov 12, 2007 7:51 pm Post subject: QM Bridge (Qmgr Alias) Vs Overlapping Clusters (Namelist) |
 |
|
Newbie
Joined: 25 Mar 2007
Posts: 4
|
Folks,
Our company wants to move from being a single cluster (production) to support multi cluster enviornments. We have done bridge POC using qmgr alias which works sweet. But we are also very interested in using namelists to interconnect clusters. Can any body suggest which idea has more advantages in the long run? We are looking at a total of 100 qmgrs for various business division.
Goals:
(1) Maintenance should be low (2)Not all queues should be able accessible between clusters, only certain QMGRs/Queues should be able to talk to certain Qmgrs/cluster in the opposite cluster. (3)Best Workload balancing ? (4)We also lack better understanding and power of using NAMELISTs, can anyone please explain the steps to connect 2 queues (only) between 2 clusters. Other queues in the clusters should be not able to see each other. (5) Message priority has become an issue using just 1 cluster, as one business does not want its messages to be lower priority than others. Does having multi cluster environment resolve this issue ?
(6) Any other benefits of moving towards overlapping/interconnected clusters ?
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 13, 2007 1:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I suspect this is one of those questions with no "right" answer, just a "right for you" answer! 
Throwing my 2 cents into the pot, and saying up front other views are equally supportable:
1) If you want low maintenance, be aware that namelists introduce another component to control. Clusters are typically low maintenance but you'll need to control the contents of namelists carefully, as edits in long lists can be hard to spot and can yield odd results as cluster components move in and out of membership. I quote my current site when 2 people made 2 changes to the same namelist to change cluster membership. Now I agree poor source control allowed both versions of the list to be applied, but we spent a happy couple of hours trying to work out why queue mangers kept joining, leaving and joining as the 2 people kept applying their versions......
2) Again this adds some complexity, and cluster membership must be controled and administered.
3) I don't think this affects workload balancing except to possible bottleneck some of the bridging queue managers. Again, think about cluster membership carefully.
4) It's all about which queues are shared on which queue mamangers by which namelist. Experimentation is the best teacher here, leading to the best design. Or your best design!
5) I can't see how this would affect priority, unless you do something with the message allocation. It might affect throughput... 
6) Like I said up top, IMHO it's horses for courses. If it was me, I'd keep the number of clusters small to alieviate some of the issues I've aluded to above.
Like I said, a personal view, there are counter arguements to many of my points and I'd agree with many of them!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Nov 13, 2007 12:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
A Queue Manager needs to participate in multiple clusters or not. If it does, you use Namelists. If it doesn't you use QM Aliases to allow it to see ajoining clusters. You don't have an option on what to use; its one or the other based on how clusters the QM needs to be in.
(moving this thread to Cluster Forum)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
