| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Clusters by applications, or clusters by qmanagers? |
« View previous topic :: View next topic » |
| Author |
Message
|
| gerimqseries |
 Posted: Mon Jun 06, 2011 3:14 am Post subject: Clusters by applications, or clusters by qmanagers? |
 |
|
Apprentice
Joined: 03 Aug 2009
Posts: 30
|
Dear Experts,
what is the best practice for the following:
Now, we have one cluster (named WMB) for two full repository qmanagers.
It has up to 50 cluster queues.
We think about to separate clusters by applications, not by qmanagers.
Maybe, if we update an application, and issue SUSPEND QMGR CLUSTER, it affects only the specified cluster objects and its applications, and no others.
Do you think, this is a good idea, to make clusters by applications? If yes, what are the advantages/disadvantages of it?
(We had some "storage allocation errors" which needed qmanager restart, and we were not happy. Making clusters by applications helps or not? Or this problem is on QManager, not cluster level?)
Thank You! |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Jun 06, 2011 5:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Storage allocation usually means the physical kind - like RAM, which makes it an o/s configuration issue - not an mq issue.
Application isolation makes sense to keep your more-important applications alive-and-well in case lesser-important applications or their qmgrs or their o/s have problems.
_________________
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 |
|
|
| exerk |
| Posted: Mon Jun 06, 2011 8:57 am Post subject: Re: Clusters by applications, or clusters by qmanagers? |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gerimqseries wrote: |
| Do you think, this is a good idea, to make clusters by applications? |
No.
| gerimqseries wrote: |
| If yes, what are the advantages/disadvantages of it? |
You have stated (possibly) that you have only two queue managers in a cluster, and they have 50 cluster queues (maybe 25 each?). Think of the number of clusters you would need for just those two queue managers if you have 10 applications, and what happens when you add additional applications that may need isolating. My tuppenyworth - one cluster is sufficient for your needs and applications should be isolated using OAM.
_________________
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 |
|
|
| gerimqseries |
| Posted: Wed Jun 08, 2011 7:15 am Post subject: |
|
|
Apprentice
Joined: 03 Aug 2009
Posts: 30
|
Dear bruce2359,
for "storage allocation error" the IBM says nothing, just restart the QM to allocate more storage for repository, but nothing about to tune anything at OS side:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc11350_.htm
qc11350_
Do You have some tip what to tune?
Dear exerk,
I think the clusters have one single point of failure: SYSTEM.CLUSTER.* queues, and amqrrmfa process. So yes, more clusters can not be more powerful than one, and it costs more work for administrators.
My real question: has anybody ever seen an environment, where are lot of MQ clusters in a full repository? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 08, 2011 7:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gerimqseries wrote: |
| I think the clusters have one single point of failure: SYSTEM.CLUSTER.* queues, and amqrrmfa process. So yes, more clusters can not be more powerful than one, and it costs more work for administrators. |
Yes, but more clusters don't resolve that. There's still only 1 SCTQ and (IIRC) a single amqrrmfa process.
| gerimqseries wrote: |
| My real question: has anybody ever seen an environment, where are lot of MQ clusters in a full repository? |
Where I've seen this done has been where cluster traffic has needed to be segrigated, so more by system than by application. The other frequent case in my experience is to bridge network issues (where 1 PR can't directly contact another PR because of firewalls).
I tend to agree with exerk that it's going a little way down this road will ensure you never get a Xmas card from the WMQ admins & it's going to be quite straightforward to get yourself into an administrative mess.
There's probably some middle ground there.
I would seriously think about why you want to do this; I personally would not consider your stated aim a good reason. If you're updating an application, what's that to the cluster? Certainly if you need to restart a queue manager due to this "storage" issue, having multiple clusters on that queue manager isn't going to help or hinder the issues caused by a restart.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 08, 2011 7:40 am Post subject: Re: Clusters by applications, or clusters by qmanagers? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| gerimqseries wrote: |
(We had some "storage allocation errors"
|
Please post the exact storage allocation error error message you received - including the AMQnnnn message identifier.
_________________
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 |
|
|
| exerk |
| Posted: Wed Jun 08, 2011 8:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gerimqseries wrote: |
| ...My real question: has anybody ever seen an environment, where are lot of MQ clusters in a full repository? |
Yes, and it was a real mess. The site thought that segregating applications by cluster was a spiffing idea, but in one particular problem case it took me a week to find out why the Repository manager kept dying on one of the FRs in one cluster - someone had got confused and defined a CLUSSDR from it to a PR. Why did it take a week? Because all 6 queue managers were in about 18 clusters and they hadn't used the same queue managers for FRs for all those clusters, some were PRs in some and FRs in others and I had to debug by 'building' the same set-up on sandbox tin. Don't go down that route because as the number of applications increase so will your number of clusters and it'll all end in tears - no matter how well you document it.
_________________
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 |
|
|
| bruce2359 |
| Posted: Wed Jun 08, 2011 9:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yes, but what a consulting opportunity!
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Jun 08, 2011 9:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| gerimqseries wrote: |
| My real question: has anybody ever seen an environment, where are lot of MQ clusters in a full repository? |
There is at least one very large company that believes that per-application clusters is a good design.
They also believed, for quite a while, that it was a money-saving effort to not have any test systems, and merely have development deploy code directly to production from their desktops. They also believed it encouraged responsibility on the part of the developers. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 08, 2011 10:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Separate clusters seem to make sense where applications need to be separated.
For example: A cluster called RandD (research and development) consisting of marginally trustworthy engineers (apologies in advance) might deserve a separate cluster from FIN (financial) folks. Where engineers need to access financial queues ("more money,please"), a qmgr can be an FR (bridging) for both RandD and FIN clusters.
Separate clusters might make sense for geography. A cluster SF for qmgrs in San Francisco; a CA cluster for all qmgrs in California.
What is too many or too few is in no way clear and definitive. Like exerk and jeff, I've seen my share of horror stories - none of which involved too few 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 |
|
|
| mqjeff |
| Posted: Wed Jun 08, 2011 10:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| Where engineers need to access financial queues ("more money,please"), a qmgr can be an FR (bridging) for both RandD and FIN clusters. |
I wouldn't do it this way. That has a large tendency to make all queues in both clusters visible on all queue managers.
I'd use a PR (in both clusters) to bridge the clusters, and have it do something cluster aliases or otherwise.
Also, again, your suggestion here assumes that there is a separate set of qmgrs for the RandD cluster than for the FIN cluster. This might not be the case that gerimqseries is looking at. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 08, 2011 10:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Lots of possibilities.
_________________
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 |
|
|
| Vitor |
| Posted: Wed Jun 08, 2011 11:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| They also believed, for quite a while, that it was a money-saving effort to not have any test systems, and merely have development deploy code directly to production from their desktops. They also believed it encouraged responsibility on the part of the developers. |
What were the Xmas parties like? Happy games of "Pass the Ticking Parcel"? A cold buffet carefully positioned on the table and uncovered a day or so before anyone starting eating the ham & chicken? A caberet act featuring the juggling of chain saws? 
I don't know about encouraging responsibility on the part of developers (and of course the vast majority of developers need no such encouragement!) but it would certainly foster fear and an aversion to making complex changes...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 08, 2011 11:15 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| What is too many or too few is in no way clear and definitive. Like exerk and jeff, I've seen my share of horror stories - none of which involved too few clusters. |
with both these points.
- There's no "right" number of clusters
- Like everyone who's been doing this for any length of time, I've got stories I can contribute to the relaunched TV show "When Clusters Attack". In each case, the problems were not caused by us having not enough clusters.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 08, 2011 12:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And you forgot to mention Attack of the Qmgr Clone, which can wreak havoc either in a single cluster or in multiple clusters.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
