| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Anyone seeing similar? 500 qmgrs, 150 clusters |
« View previous topic :: View next topic » |
| Author |
Message
|
| pcelari |
 Posted: Fri Mar 27, 2020 7:43 am Post subject: Anyone seeing similar? 500 qmgrs, 150 clusters |
 |
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
Greetings...
in a recent client assignment, I encountered a clustered environment never seen or imagined before. I wonder if it's because of my limited exposure. So would like to know if anyone else has encountered similar MQ cluster networks.
The client organization has about 500 queue manager, but has over 140 clusters spreading across the network, with large portion of the qmgrs being members of up to 20 clusters.
It seems clusters is used there to enable quick access to queues without having to go through the relatively slow process of setting up a clearly defined distributed queuing. Since MQ Cluster has matured to such a degree and stable, we can safely count on its capability to take care of the message distribution without having to deal with designing a route. Of course, extensive use of clusters tends to make tracing the flow of messages a challenging task, to put it mildly.
Most clients I encountered before have typically no more than 2 or 3 clusters in a single environment - production, QA, or DEV, for good reason I believe.
Would some more experienced members here share your thought over the scale of a reasonable number of clusters in a MQ network, and the advantage/pitfalls of extensive use cluster similar to the above mentioned?
Any insight would be greatly appreciated..
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Mar 27, 2020 8:11 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
My own preference is to have as few clusters as required to achieve the objective, e.g. a 'retail' cluster, a 'wholesale' cluster etc.
I have worked at two client sites where clusters were used to (supposedly) "separate" applications (note the quotes) and reduce management overhead, and in one case six queue managers were in about (from fading memory) 15 different clusters!
In both the above cases there was a woeful lack of documentation of the clusters, and everything else in general actually, which made fault-finding/message-tracking a nightmare.
I'm sure there are others out there that swear by having a zillion clusters, and separate FRs to rule them all, but I'm not one of them.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Mar 29, 2020 3:05 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| exerk wrote: |
| My own preference is to have as few clusters as required to achieve the objective, e.g. a 'retail' cluster, a 'wholesale' cluster etc. |
Agree. It's OK for multiple apps to share a single MQ cluster, as clusters are a primarily a transport and msg delivery feature, and not an application traffic containment feature. MQ clusters automatically envolve to dynamically create all the cluster channels and partial repository queue defs that are required for the app messaging paths. This naturally leads to a degree of app containment.
_________________
Glenn |
|
| Back to top |
|
|
| pcelari |
| Posted: Mon Mar 30, 2020 8:16 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
| exerk wrote: |
| … there was a woeful lack of documentation of the clusters, ... which made fault-finding/message-tracking a nightmare. |
| gbaddeley wrote: |
| … as clusters are a primarily a transport and msg delivery feature, ... MQ clusters automatically envolve to dynamically create all the cluster channels and partial repository queue defs that are required for the app messaging paths. This naturally leads to a degree of app containment. |
thanks for sharing the fundamental problem as well as conceptual advantage!
It seems a proliferation of clusters tends to render a MQ network into a more and more complex one that is increasingly difficult to see through. So when it becomes prohibitively difficult to document, people just stop doing it, which in turn will likely make the mesh unmanageable as time goes on.
would someone of the opposite opinion or experience share the other sides of insight?
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| 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
|
|
|
|
