| Author |
Message
|
| RocknRambo |
 Posted: Thu Apr 26, 2012 9:26 am Post subject: Overlapping cluster |
 |
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
We have three MQ clusters with each cluster having about 10 queue managers, can any share the best practice to implement inter cluster communication?
Is overlapping cluster the preferred option with less moving parts?
Thanks for any pointing
--
RR |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Apr 26, 2012 9:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
From your research (reading the WMQ queue manager clusters manual, for example), what benefits for your organization arise from overlapping clusters?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RocknRambo |
| Posted: Thu Apr 26, 2012 9:53 am Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
Fairly new MQ clustering concepts.. One biggest advantage is see is 'allow independent applications to be administered separately'. The gray area for us is.. for three MQ clusters, if we overlap all three such that message information can go to any of the qmgr of any cluster without remote queue defn and tx queue etc.,... any other challenges we need to be aware of
--
RR |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 26, 2012 9:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| DO NOT OVERLAP CLUSTERS UNLESS YOU ARE SKILLED AND HAVE LOTS OF PRACTICE WITH CLUSTERS. |
|
| Back to top |
|
|
| RocknRambo |
| Posted: Thu Apr 26, 2012 10:01 am Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
Agreed, once we have an agreement on the design and approach... we will have experienced and certified MQ administrators to perform the implementation. The challenge is identifying the best practice and evaluating the options
--
RR |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 26, 2012 10:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| The recommended practice is do not overlap clusters unless you have a compelling need to. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 26, 2012 10:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RocknRambo wrote: |
| One biggest advantage is see is 'allow independent applications to be administered separately'. |
I don't see how having overlapping clusters is going to allow you to do that any more than a single cluster would. Can you elaborate a little?
| RocknRambo wrote: |
| The gray area for us is.. for three MQ clusters, if we overlap all three such that message information can go to any of the qmgr of any cluster without remote queue defn and tx queue etc |
That's rather my point. One of the challenges of overlapping clusters is the control of message flow across them. If your plan is to overlap all three you've logically built 1 single cluster whilst having increaased the administrative effort and risk of error more than threefold.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 26, 2012 10:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RocknRambo wrote: |
| we will have experienced and certified MQ administrators to perform the implementation. |
Not the point being made. The attributes pointed out were "skilled" and "lots of practice with clusters". That's a long way from "certified" and is not implied by "experienced".
The odds of an overalpping cluster being set up wrong or going wrong are very high. Working out what's going wrong (the 2 typical problems being a messge not arriving where it's addressed & a message arriving somewhere it shouldn't be possible to arrive at) require in-depth skills.
It's like message exits. In theory any certified person can develop, install & use an exit. In practice you really need to know what you're doing if you with to avoid distaster. People with the correct level of knowledge & experience to use exits know better than to use exits except as a last resort.
(I have a little over 15 years with WMQ. I've used exits 4 times in that period & have gone to heroic efforts not to make it 5).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rammer |
| Posted: Thu Apr 26, 2012 11:30 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
We use 20 overlapping clusters in a hub and spoke solution works with no issues.
The hub is a full repository for all 20 clusters using a namelist, with the spokes (application queue managers approx 50) being partial respoitory for only one cluster.
If application A which is in Cluster A needs to send to Application B in Cluster B, a alias is created with a target alias on the Hub which is in cluster A and has a Target of cluster queue B on App QMGR B.
This way we only have channels going from Application QMGRS to the Hub and not to each other. This way it allows us to take Queue Managers out for maintenenace if we need to for any reason and messages will store on the Hub and not the sending app's where there is not as much storage etc etc.
This configuration has been in place for over 12 years now and gone through various upgrades from version 5, 6, 7. Only issues we had was when it was on early version of 5..
If I was able to re-design the solution now though I wouldnt bother with so many clusters as they really are not required but at the time of putting the solution in 12 years ago there was a business reason for this which is no longer required, however as mentioned it causes no issues at all.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 26, 2012 11:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rammer wrote: |
| We use 20 overlapping clusters in a hub and spoke solution works with no issues. |
You can't with a straight face use "overlapping clusters" and "hub and spoke" in the same sentence. What you have here is a traditional distributed hub and spoke with all the potential problems (bottleneck, single point of failure, etc) that clusters are intended to mitigate. You're certainly reducing the benefit of clustering if you're manually creating all those alias queues.
If it's worked for 12 years well done. But you don't have 20 overlapping clusters, you have 2 overlapping clusters repeated 20 times. And not that overlapped.
Saving storage on app servers is a poor reason for this kind of design. Disc is cheap.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rammer |
| Posted: Thu Apr 26, 2012 11:53 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| As I mentioned I would change it now, but IBM were on site for a year when it all went in and 12+ years ago that was what they designed and got paid for. Its worked perfect for many years (touch wood), there is more than one hub for resilience, load balancing etc and also fingers crossed they have been fine!.. Unfortunatly there are so many apps that are business critical on here now its difficult to find time to make fundamental changes. The 20 clusters used are per business sector that are no longer even there with mergers etc. Then again I may no longer be here with redundincies being announced today!... |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 26, 2012 2:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rammer wrote: |
| 12+ years ago |
Times change.
| rammer wrote: |
| what they designed and got paid for. |
So they got paid for a year's work installing this elaborate solution? Humm...
| rammer wrote: |
| Its worked perfect for many years (touch wood), |
I say yay, and may it work another 12.
| rammer wrote: |
| there is more than one hub for resilience, |
Which a cluster solution shouldn't need.
| rammer wrote: |
| load balancing etc |
Likewise (load balanced hub & spoke!!)
| rammer wrote: |
| The 20 clusters used are per business sector that are no longer even there with mergers etc. |
I refer to my comment above on increased admin.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 26, 2012 4:27 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Hubs with clusters; or clusters with hubs. Add overlapping clusters.
Could this be more complicated?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| rammer |
| Posted: Fri Apr 27, 2012 12:09 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| Ive not disagreed!... ALthough other accounts I work on in England and USA have similar set ups as well,, perhaps IBM and Candle enjoyed this configuration many years ago! |
|
| Back to top |
|
|
| vimmy |
| Posted: Fri Aug 10, 2012 9:08 am Post subject: alias queue from a qm shared in two clusters |
|
|
Novice
Joined: 29 Jan 2011
Posts: 15
|
| I have a secnario where we had to overlap clusters. An alias queue on a queue manager shared in two clusters and whose target queue bears the same name in both the clusters is sending messages to both the clusters. How do I restrict the messages to go to one cluster alone. I thought since the alias queue as well as the target queue are in one cluster , the messages would be restricted but messages are going to the other cluster also since the sending queue manager is in both clusters. Please advise me how to go about solving this. |
|
| Back to top |
|
|
|
|
