| Author |
Message
|
| jhidalgo |
 Posted: Wed Mar 26, 2008 8:21 pm Post subject: cluster design for long distances |
 |
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
Hi mq gurus, I am having the following concern:
I have different installations on different states for the same services, some of these services(most of them) have local (state wise) clustering. So the question is:
Can I move to a universal cluster environment without doing sacrifies on performance(for example not replicating information that I don't need to replicate), stability(too many services depending on the same listeners, etc..), etc. ?
Also, is there any security schema that allows me to manage this universal cluster so I can grant specific permissions (user -> qms) ?
My services are the same across the board, doesn't matter who consumes them as long as I use the currelation IDs
Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Mar 27, 2008 1:37 am Post subject: Re: cluster design for long distances |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jhidalgo wrote: |
| Can I move to a universal cluster environment without doing sacrifies on performance(for example not replicating information that I don't need to replicate), stability(too many services depending on the same listeners, etc..), etc. ? |
All clusters are universal in that they will attempt to form fully connected networks. The only parts that will "replicate" information on a regular basis will be the full repositories. There's a discussion in here somewhere (which I'm too lazy to look up) on the placement of FRs in a large, geographically spread network.
You might also want to consider a minor blaspemy and have more than 2 FRs. While it's writ that thou shall have 2 FRs in a cluster, not 3, not 4 (and thou shall only have 1 while thou are defining the 2nd), there is a case for having them positioned so PRs are not going all over the network for their information. IIRC there's a discussion on that as well. Look it up & weigh the problems of more than 2 FRs against the load on your network.
Basically it doesn't make much difference to the cluster what's where & who's using what.
| jhidalgo wrote: |
| Also, is there any security schema that allows me to manage this universal cluster so I can grant specific permissions (user -> qms) ? |
Security is always at qm level, even in a cluster. Users and applications connect to queue managers not the cluster.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Mar 27, 2008 9:04 am Post subject: Re: cluster design for long distances |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Vitor wrote: |
| You might also want to consider a minor blaspemy and have more than 2 FRs. While it's writ that thou shall have 2 FRs in a cluster, not 3, not 4 (and thou shall only have 1 while thou are defining the 2nd), there is a case for having them positioned so PRs are not going all over the network for their information. IIRC there's a discussion on that as well. Look it up & weigh the problems of more than 2 FRs against the load on your network. |
I thought, recently, there was a discussion, where it was pointed out that there was a technical reason why more than 2 FRs was a "Very Bad Idea", and could break.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 27, 2008 9:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
More than 2 FRs fragments your cluster.
In some cases, there may be beneficial side effects of a fragmented cluster.
It's always better to design MQ network topologies to take real network topologies into account, as well as application traffic patterns.
Consider not using a monolithic MQ Cluster if you've got a solid hub/spoke traffic pattern. If your hub needs load-balancing, or certain spokes need load-balancing, then use cluster gateways or bridges. but maintain a larger hub/spoke model.
Spanning MQ clusters across hard network boundaries and across hard organizational boundaries is a bad idea.
Maintaining any kind of universal security schema/process with MQ across a large MQ network is very challenging, and is usually best handled outside the MQ layer - in the application layer somewhere, or in between (perhaps with DP, perhaps MB 6.1 or etc.). Use MCAUSers on MQ channels to scope incoming messages to appropriate resources - in a cluster you only get one MCA on the clusrcvr, so you only get one scope.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Mar 27, 2008 9:14 am Post subject: Re: cluster design for long distances |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jhidalgo wrote: |
| My services are the same across the board, doesn't matter who consumes them as long as I use the currelation IDs |
Do you get signoff for any MQSC commands run on any of the qmgrs? If not then you have to consider what happens if someone runs a command on a queue manager they think they own, when in fact this alters the behaviour of name lookups in a cluster that you think you own. Put another way, if you widen the scope of your cluster, consider you will need signoff on all MQSC commands run on all queue managers. You'll hear some MQ people using the phrase "a cluster is a single administrative resource", which is another way of saying what I just said.  |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 27, 2008 11:28 am Post subject: Re: cluster design for long distances |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EddieA wrote: |
| Vitor wrote: |
| You might also want to consider a minor blaspemy and have more than 2 FRs. While it's writ that thou shall have 2 FRs in a cluster, not 3, not 4 (and thou shall only have 1 while thou are defining the 2nd), there is a case for having them positioned so PRs are not going all over the network for their information. IIRC there's a discussion on that as well. Look it up & weigh the problems of more than 2 FRs against the load on your network. |
I thought, recently, there was a discussion, where it was pointed out that there was a technical reason why more than 2 FRs was a "Very Bad Idea", and could break.
|
It's that discussion I'm referring to
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 02, 2008 7:23 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I posted the reason why not to use more than 2 FRs based on list serve posts. In a nutshell a PR will only register with 2 FRs. If you have 3 FRs, some PRs will be register with FR1 and FR2, some with FR2 and FR3 and some with FR1 and FR3. When FR1 and FR2 go down you may think since you got FR3 so the cluster is 100% capable.
.
.
.
(Borat pause)
.
.
NOT!
The PRs that relied on FR1 and FR2 can't process any cluster configuration changes.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Wed Apr 30, 2008 6:58 am; edited 1 time in total |
|
| Back to top |
|
|
| jhidalgo |
| Posted: Thu Apr 03, 2008 11:40 am Post subject: |
|
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
I was thinking on having a FR per state, and then 3 PR each, on 7 installations, but according to the posters that is not a good idea because of the bandwidth usage (what is going to be replicated exactly, isn't that solved with v6 because of the compression?).
The other reason is having PRs registered on FRs not optimal (from geographical perspective) but what is the down side of it ?
Thanks. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Apr 03, 2008 10:51 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
jhidalgo,
every PR queue manager has one primary repository - that's where your manual cluster definitions point to. After the creation of these manual definitions all other FRs are propagated to the PR, so you will see the QMgrs and the channel to them.
BUT (as Peter told before) the PR only accepts one of them as the secondary repository - and I you cannot decide, which one.
So if you have several locations and a FR in each location and define on all PR in these locations a channel to th FR in the same location, then - as long as all FRs are available - you should be able, to minimize the network traffic. BUT as soon as more than one FR will be unavailable you may have PRs, which do not have any FR!
You should think about the necessity, to have more than two FRs. The traffic - in "normal" situations - between FR and PR should not be so much, because FRs are only needed, to ask for new definitiones and to refresh the cluster informations after every 27 days. If you cluster definitions do not change every minute or so (what would not be a good design) the cluster administration traffic should be not that big.
So think about having to FRs - let's say one in US and one in EMEA (for a global player) instead of having FRs in each country or location.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| jhidalgo |
| Posted: Wed Apr 30, 2008 6:55 am Post subject: |
|
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
| Quote: |
So if you have several locations and a FR in each location and define on all PR in these locations a channel to th FR in the same location, then - as long as all FRs are available - you should be able, to minimize the network traffic. BUT as soon as more than one FR will be unavailable you may have PRs, which do not have any FR!
|
What if I have channels from each PR to every FR in the cluster ?, the first two channels will be to the FR closer to the PR but then my PR will always have a connection to the FR ?
The problem I'm having is that some guys representing IBM recommend to have more than 2 FR, because the manual says you "can" have more than 2, and I haven't been able to reproduce the problems pointed here.
How can I probe(reproduce the problems in a test scenario) the problems of having more than 2 FR in a cluster ?
Is there a redbook about this specific topic that states all the pros and cons?
Or at least is there anybody on IBM that I can contact ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 30, 2008 7:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jhidalgo wrote: |
| What if I have channels from each PR to every FR in the cluster ?, the first two channels will be to the FR closer to the PR but then my PR will always have a connection to the FR ? |
Aside from the fact you've just created a hub-and-spoke network and lost a lot of the benefits of clustering, AFAIK each PR will still only take 1 primary and 1 secondary FR, irrespective of how many channels there are set.
| jhidalgo wrote: |
| The problem I'm having is that some guys representing IBM recommend to have more than 2 FR, because the manual says you "can" have more than 2, and I haven't been able to reproduce the problems pointed here. |
The manual for my car says it's top speed is 120mph. It doesn't mean it's a good idea to drive it at that speed. Except in that one instance where the tanker behind you has exploded and the fireball is heading towards you.
You can have more than 2 FR. This thread is exploring the wisdom of it, and the problems that can result.
So you've got "some guys" representing IBM? Who are these people? Sales, architect or technical? What are their cluster credentials? How IBM is IBM? Real IBM, business partner or some guys IBM GS found to fill a seat?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jhidalgo |
| Posted: Wed Apr 30, 2008 7:30 am Post subject: |
|
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
These guys are partners, not IBM personal but their representatives for us, that is why I want to contact somebody @ibm.com to clarify on this issue.
The problem I have is that 1. the manual says you can have more than 2, 2. I can't reproduce or create a failure condition, 3. I don't have have an official statement saying exactly what happens when I have more than 2 FRs.
Anybody with the "proof of concept" or scenario that proves something goes wrong
PD: I am not flooding here, in fact I am trying to prove it is a bad idea
 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 30, 2008 7:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Again, there's a post here from PeterPotkay in which he reposts some information from Ian Vanstone that explains exactly why > 2 FRs doesn't work and leads to fragmented clusters.
Again, if you have a solid hub/spoke traffic pattern, then do not try to implement MQ clustering across it.
If you really want load balancing and simplified administration across site boundaries, then implement a boundary cluster, that has gateways into the individual site clusters.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jhidalgo |
| Posted: Wed Apr 30, 2008 8:29 am Post subject: |
|
|
Disciple
Joined: 26 Mar 2008
Posts: 161
|
I know, and I don't want to create more than two FRs, but what I need is to prove it is a bad idea.
How can I create an environment where I can see the issues on having more than 2 FR ?, what is the proof of concept for your recommendation ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 30, 2008 8:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Run a test environment with more than 2 FRs.
You need at least one PR attached to each of the FRs.
Make one FR unavailable and see the effect on each of the PRs, make 2 FRs unavailable and see the effect on each of the PRs etc ...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
