| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Cluster qmgr topology and relaying |
« View previous topic :: View next topic » |
| Author |
Message
|
| rconn2 |
 Posted: Sat Dec 08, 2007 11:10 am Post subject: Cluster qmgr topology and relaying |
 |
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
Hello - my first post on this forum (and hope to become more of a contributor than "asker" in time).
We're trying to establish Clustering across a large Enterprise with a number of environments, firewalled zones, a mix of unix and z/os etc.
QM's will be interconnected, but not every QM will be able to connect to every other QM (some will have to go through other QM's indirectly).
We've been unable to get the following to work in our test lab:
QM1:aix(full) <--> QM2:z/os(partial) <--> QM3:aix(full)
1. Does every clussdr have to point to a full repository?
2. Wouldn't clustering automatically try to create a channel between QM1 and QM3 (even if all the QM's were full)? What if such a connection was not possible (firewalled)?
In other words, does every clustered QM have to be able to connect directly to every other QM? Can some QM's act as relays or gateways to their environment's QM's? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sat Dec 08, 2007 2:12 pm Post subject: Re: Cluster qmgr topology and relaying |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| rconn2 wrote: |
1. Does every clussdr have to point to a full repository?
|
Each QM in the cluster has to have one, and only one, manually defined CLUSSNDR channel to a Full Repository. Each QM in the cluster should be able to reach one other full repository as well (via the automatic cluster sender channel that will be created)
| rconn2 wrote: |
2. Wouldn't clustering automatically try to create a channel between QM1 and QM3 (even if all the QM's were full)? What if such a connection was not possible (firewalled)?
|
You will have to define a CLUSSNDR on QM1 to a full repository, which is QM3. And if that path is not possible you have a problem.
For a healthy cluster:
Every Partial QM needs to be able to reach 2 Full Repositories.
Every Full Repository needs to reach one other Full Repository.
Based on the details provided, I think the safest bet is to create 2 overlapping clusters.
QM1A and QM1B are Fulls for CLUSTER1
QM3A and QM3B are Fulls for CLUSTER2
QM2 is a member of both clusters.
QM2 is a single point of failure, so make sure its Highly Available (hardware cluster for that QM) and/or have a QM2A and QM2B.
Based on the details provided, I don't see a need for clustering. Use conventional channels to connect QM1, QM2 and QM3.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rconn2 |
| Posted: Sun Dec 09, 2007 10:48 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
| PeterPotkay wrote: |
Each QM in the cluster has to have one, and only one, manually defined CLUSSNDR channel to a Full Repository. Each QM in the cluster should be able to reach one other full repository as well (via the automatic cluster sender channel that will be created)
|
So, a QM should be able to access (one by a manually defined channel, one by an automatically defined one) two other fulls. Except a full which needs to just access the other full (in a 2 full cluster).
| PeterPotkay wrote: |
You will have to define a CLUSSNDR on QM1 to a full repository, which is QM3. And if that path is not possible you have a problem. |
This is important for us to know -- and it seems we've made wrong assumptions. Not all QM's will have access to all other QM's. For example, QM1 (representing QM's in environment 1), and QM3 (QM's in environment 3) will each have access to a QM2 but not to each other. QM2 (specifically a mainframe QM) will have to act as a relay.
| PeterPotkay wrote: |
For a healthy cluster:
Every Partial QM needs to be able to reach 2 Full Repositories.
Every Full Repository needs to reach one other Full Repository. |
But does every QM need to be able (via automatic channels) to access every other QM in a cluster? I take it this is what you're saying, but want to confirm.
| PeterPotkay wrote: |
Based on the details provided, I think the safest bet is to create 2 overlapping clusters.
QM1A and QM1B are Fulls for CLUSTER1
QM3A and QM3B are Fulls for CLUSTER2
QM2 is a member of both clusters.
QM2 is a single point of failure, so make sure its Highly Available (hardware cluster for that QM) and/or have a QM2A and QM2B. |
And if we want queues accessible to all QM's, then they'd have to be hosted on QM2 (which would be a member of both clusters)?
Or, as you said, not even use clustering... and just put queues on the commonly accessible to other queue managers' queue manager. The problem w/ this point-to-point approach is that not all clients will have access to that qm, but only to a local one in their environment. Clustering is also preferable as there will be many queues and it'll make administration simpler (than defining many remotes).
Sorry for going on, but I need to nail this down....
n clients --> qm('s) in environment 1
n clients --> qm('s) in environment 3
qm1('s) <--> qm2 <--> qm3('s)
Each qm in a cluster must be able to access every other qm. Since qm1's can't directly access qm3's, then they can't be part of the same cluster. A qm2 can't act as a relay to allow indirect access as automatic channels will be created as needed between qm1's and qm3's and they will fail.
Those qm's which _can_ directly access each other could have their own cluster, so there'd be a cluster1 for qm1's and a cluster3 (am using 3 to keep it consistent) for qm3's. qm2 could then be a member of both clusters. And, queues that need to be available within both cluster1 and cluster3 would have to be hosted on qm2 but could then be made available in both clusters.
The critical points for my understanding: all qm's in a cluster need access to all other qm's in the cluster. And queues, whether in an overlapping cluster design or distributed, are only accessible when hosted on qm's that can be directly accessed.
Are there no relay, pass-through, indirect options? If not, then that's that. If so, is such, worth practical consideration?
[btw, I greatly appreciate your, and any other's, help... I'll do more study also, so am not being lazy.] |
|
| Back to top |
|
|
| rconn2 |
| Posted: Sun Dec 09, 2007 10:56 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
I just thought of a new wrinkle... a client can't get from a cluster queue that isn't hosted on the qm to which it's connected.
So, if queues are on a qm that is a member of multiple clusters, then clients would have to connect to that qm (and not a local qm that's a part of one of the clusters). Ahhhhh.... |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Sun Dec 09, 2007 1:27 pm Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
Hmmm,
Yes, every QMGR in a cluster must be able to communicate with every other QMGR in the cluster (because they will if the clustered object they want to use is hosted on the other QMGR then an auto channel will be built directly to it).
The point to the clustering is to get direct connections between every QMGR with only having to define one receiver channel and one sender channel to one full repository and have the QMGRs figure all the rest out.
So if QMGR2 is in both clusters, then for QMGR1 client's that want to send messages to QMGR3 you will put an QA in cluster 1 on QMGR2 that points to a QL in cluster 2 on QMGR3 and it will get there. Do the reverse for the other direction. Again, so far, clustering has not saved you anything with this number of QMGRs. Indeed, you don't even have enough QMGRs to run a health cluster.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Dec 09, 2007 1:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| rconn2 wrote: |
| PeterPotkay wrote: |
Each QM in the cluster has to have one, and only one, manually defined CLUSSNDR channel to a Full Repository. Each QM in the cluster should be able to reach one other full repository as well (via the automatic cluster sender channel that will be created)
|
So, a QM should be able to access (one by a manually defined channel, one by an automatically defined one) two other fulls. Except a full which needs to just access the other full (in a 2 full cluster).
|
Correct.
| rconn2 wrote: |
| PeterPotkay wrote: |
For a healthy cluster:
Every Partial QM needs to be able to reach 2 Full Repositories.
Every Full Repository needs to reach one other Full Repository. |
But does every QM need to be able (via automatic channels) to access every other QM in a cluster? I take it this is what you're saying, but want to confirm.
|
Every PR needs to be able to get to both FRs
Each FR needs to be able to get to the other FR.
But not every PR needs to talk to every other PR. A PR will create an auto CLUSSNDR channel to another PR only if it needs to send an application's message to it. If PR1 never needs to send a message to PR2, it doesn't matter that PR1 can't talk to PR2.
To the best of my knowledge, MQ clustering is not slick enough to use intermediate QMs in the cluster to get from QMA to QMC via QMB if the path from QMA to QMC is N/A. It will always try to create a direct channel from QMA to QMC and if the path is N/A you will find yourself with a retrying channel.
Put all the QMs in CLUSTER1 that can talk to each other, and make sure there are 2 FRs in CLUSTER1.
Put all the QMs in CLUSTER3 that can talk to each other, and make sure there are 2 FRs in CLUSTER3.
QM2 is a member of both clusters. It has QM Aliases for every QM in both clusters.
In CLUSTER1, the QMs have Remote Q defs pointing at the destination queues in CLUSTER3. The QM Aliases on QM2 will catch those and forward them over to CLUSTER3 QMs.
In CLUSTER3, the QMs have Remote Q defs pointing at the destination queues in CLUSTER1. The QM Aliases on QM2 will catch those and forward them over to CLUSTER1 QMs.
| PeterPotkay wrote: |
QM2 is a single point of failure, so make sure its Highly Available (hardware cluster for that QM) and/or have a QM2A and QM2B. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Dec 09, 2007 4:24 pm Post subject: |
|
|
Guest
|
|
| Back to top |
|
|
| rconn2 |
| Posted: Sun Dec 09, 2007 9:35 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
JosephGramig, PeterPotkay - thanks very much. I need to digest and go over w/ a colleague tomorrow.
bruce - clustering course or Impact 2008 in LV... not an easy decision... |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Dec 09, 2007 9:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
You might also want to take into consideration the effect of a web cluster on the JMS Engine of WAS. Just to be clear this is very different from the "MQ cluster". 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Dec 10, 2007 5:24 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA
|
| PeterPotkay wrote: |
Every PR needs to be able to get to both FRs
Each FR needs to be able to get to the other FR.
But not every PR needs to talk to every other PR. |
Well, if one PR cannot talk to another PR that hosts a queue in the cluster then the PR QMGR will build an automatic channel to it and that channel will go into retry and messages will start piling up in the S.C.T.Q and that will adversely affect everything that QMGR is trying to talk to in that cluster (and now that I read this again, every cluster it talks to).
Every QMGR in a cluster must be able to talk to every other QMGR in that cluster because it might and if it can, that will get you bad results.
Perhaps I'm paranoid or just operate at a higher level of awareness, but if it can happen, then it will happen.
Now, let me go buy a lottery ticket.
Something funny http://www.elfyourself.com/?id=1272471275
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Dec 10, 2007 7:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| JosephGramig wrote: |
| Well, if one PR cannot talk to another PR that hosts a queue in the cluster then the PR QMGR will build an automatic channel to it and that channel will go into retry and messages will start piling up in the S.C.T.Q and that will adversely affect everything that QMGR is trying to talk to in that cluster (and now that I read this again, every cluster it talks to). |
Messages in S.C.T.Q are pulled based on correlID, which is == channel name. So messages piled on S.C.T.Q for one qmgr do not necessarily affect messages going to any other qmgr.
Otherwise, yes.
MQ Clusters automatically form fully connected networks, outside the control of the user. This is why spanning a cluster across major network boundaries is a bad idea.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Mon Dec 10, 2007 1:45 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
We decided to use a DQN...
QM1's: remote q defn's --> QM2: remote q defn's --> QM3: local q
I've not seen it in any of the manuals, but apparantly a remote queue can point to a remote queue which can point to a local queue.
So, we'll have remote q defn's on the client connected qmgrs; the apps will work as now, putting to a q on that qmger. This will send to the hub qmgr which will have its own remote q defn's that point to the destination local queue.
It's an extra-level of indirection and extra set of remote q defn's, but that's just some runmqsc code that won't be too difficult to write.
We also considered qmgr alias', but then the apps would need to use the right alias. There will be a number of destination qmgrs, so this would just add complication and maintenance to app code.
This forum is an excellent resource... all your help in brainstorming this is greatly appreciated! oh yeah... decided I may as well go to Impact 2008 since we won't be using clustering.  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 10, 2007 3:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| rconn2 wrote: |
We also considered qmgr alias', but then the apps would need to use the right alias. There will be a number of destination qmgrs, so this would just add complication and maintenance to app code.
This forum is an excellent resource... all your help in brainstorming this is greatly appreciated! oh yeah... decided I may as well go to Impact 2008 since we won't be using clustering. |
QMGR aliases are supposed to make it easier, consider:
QM1--> QM2-->QM3
on qm1:
def qr(mydest) rname(mydest) rqmname(QM3)
def qr(qm3) rqmname(qm3) rname(' ') xmitq(qm2)
def ql(qm2) usage (xmitq)
def chl(qm1.to.qm2) type (sdr)
conname('qm2host(qm2port)') xmitq(qm2)
on QM2
def chl(qm1.to.qm2) chltype(rcvr)
def chl(qm2.to.qm3) type(sdr) conname('qm3host(qm3port)') xmitq(qm3)
def ql(qm3) usage(xmitq)
on QM3
def chl(qm2.to.qm3) chltype(rcvr)
def ql(mydest)
And this is all it takes to send any message for QM3 from QM1 using QM2 as a hop...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rconn2 |
| Posted: Mon Dec 10, 2007 9:49 pm Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
So, you're saying a remote queue definition will also use a qmgr alias... what a great idea!
This means we won't have to have remote queue definitions on the QM2 middleman qmgr which will make things much simpler.
We tested the remote q's to remote q's to local q's and that works no problem. We'll have to test this qmgr alias technique tomorrow.
I'm thinking... there is a bit of a trade-off to each of these multi-hop techniques:
1. qm1:remote q -> qm2:remote q -> qm3:local q
Disadvantage: requires remote q defn's on qm2.
Advantage: all final destination info is placed and can be maintained on qm2.
2. qm1:remote q:qmgr alias -> qm2 -> qm3:local q
Disadvantage: qm1('s), qm1 represents several such origination qmgrs, will need to know which queues end up at which destination qmgrs so the remote q defn's rqmnames can be properly defined.
Advantage: a few qmgr alias' are needed, but there's no need for a complete set of remote q defn's on the middle (qm2) qmgr.
Overall, I think your #2 suggestion is the better technique, at least in the case we have in mind. We'll have over a hundred queues and several (half a dozen) origination and destination qmgrs. They'll hop thru one of two middle-man qm2's. That's a lot of remote q defn's to be put on the qm2's (which are z/os). The mainframe mq admin will certainly like this approach.
This thread has been like an advanced course in DQN. I read the manual, but wouldn't have considered this approach would work. We'll test this out tomorrow in our lab and I'll post back. |
|
| Back to top |
|
|
| rconn2 |
| Posted: Tue Dec 11, 2007 8:45 am Post subject: |
|
|
Voyager
Joined: 09 Aug 2007
Posts: 79
Location: MD, USA
|
fjb_saper -
I couldn't get the following to work:
def qr(mydest) rname(mydest) rqmname(qm3)
def qr(qm3) rqmname(qm3) rname(' ') xmitq(qm2)
The remote definition doesn't seem to resolve to the alias definition to then get the xmitq defined there.
Instead, I just put the xmitq in the remote definition:
def qr(mydest) rname(mydest) rqmname(qm3) xmitq(qm2)
This works... w/ no need for an alias since all the alias above seems to be used for is to resolve to an xmitq. A qmgr alias could be useful, though, for switching to different xmitqs and channels.
Are you sure your technique w/ the remote and a qmgr alias works? Or if using a remote q defn, is that defn expected to have an xmitq defined since it will not resolve further to any alias -- as seems to be the case? |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2, 3 Next |
Page 1 of 3 |
|
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
|
|
|
|
