|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ setup question |
« View previous topic :: View next topic » |
Author |
Message
|
jeevan |
Posted: Fri Aug 24, 2007 9:24 am Post subject: MQ setup question |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
This is for a PM4DATA project. As PM4DATA transfer files over mq, we need a mq infrastrcutre for this.
Basically, there are two approaches in setting mq for pm4data:
1. using mq cluster
2. using regular sdr /rcvr channel
There are many nodes that send data to many other nodes.
Each node will be connected to enterprise server. In cluster, it is easy as once we connect one node to EPS with cluster sdr and cluster rcvr channel, it can send /receive message to/from any other nodes without any additional configuration. This is what I have done in the past projects.
But my currect requirements is to setup regular sdr/rcvr channel to EPS. what configuration does it require on eps to make communcation from any node to any nodes?
I alrady tested sending file ( in fact I am just checking connectivity using ftfping), it does not work. It works from A to EPS and EPS to B but does not work from A to B.
I can think of creating a qmgr alias. But could not think clearly. If there would be one node, i can think of defining a qmgr alias, but there are many nodes the message can /should go.
Could some one give me some idea.
Thanks
Last edited by jeevan on Fri Aug 24, 2007 1:24 pm; edited 1 time in total |
|
Back to top |
|
 |
jeevan |
Posted: Fri Aug 24, 2007 11:42 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
Let me explain the problem in simple mq term. Lets say there are 11 mq queue managers setup in 11 different boxes. Ten out of 11 are connected to one of them, lets say hub qmgr with SRD and RCVR channel.
My question is: What setup and where enables these 10 mq qmgrs to talk to each other without defining direct channel between them and without using mq cluster?
This means, the hub qmgr should work as Router for message. But what should I define at each of the queue manager?
As I said in my previous pos that I can think of hultihopping techhnique- but can not think clearly. Can I have qmgr alisa at each of the queue mqnqger and /or what else and where ?
I would be really grateful if you could give me some hints.
thanks a lot in advance |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Aug 24, 2007 11:57 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
You need to turn on the Default XMITQ on each of the Spoke QMs. The Default XMITQ should be set to the Hub QM on each of the Spoke QMs. The Hub does not have its default XMITQ set.
On the Hub QM you need an XMITQ to each Spoke QM named exactly like the spoke QM names. Or a QM Alias that has that name that points to the XMITQ that goes to that spoke QM if the XMITQ is named differently.
And pray that your Hub QM never ever goes down. Because if it does, all 10 spoke QMs are basically useless. I hope you Hub QM is running on a hardware cluster to insure high availability. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jeevan |
Posted: Fri Aug 24, 2007 12:17 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
PeterPotkay wrote:
Quote: |
And pray that your Hub QM never ever goes down. Because if it does, all 10 spoke QMs are basically useless. I hope you Hub QM is running on a hardware cluster to insure high availability.
|
First of all, thank you very much for the answer. I still have a question. What are we trying to achieve defining a default tranmission queue (XMITQ)? When we set def xmitq, I suppose we do have to mention xmitq in our channel. AM I correct?
Clarifying your concerns, which is very much true, this is dev environment. I already suggested to setup a mq cluster with at least two FRs which is tested and reliable solution . If one goes down, the other provides the services as well as we can do load balancing if necessary.
Thank you once again, |
|
Back to top |
|
 |
George Carey |
Posted: Fri Aug 24, 2007 1:34 pm Post subject: Messages between spokes without MQ clustering |
|
|
Knight
Joined: 29 Jan 2007 Posts: 500 Location: DC
|
MQ Clustering would be the easiest thing to do but as you state it cannot be used (why???) , so you can just fall back to old MQ techniques that would be used before MQ Clustering existed. Here is an example set up that you can repeat/extrapolate for your environment, if you haven't set it up before.
All 10 qmgrs should have bi-directional SDR/RCVR channels to the hub qmgr 11. Lets take two of them say QM1 and QM8 and say you want to send a message from QM1 to a queue on QM8 call it ‘QXon8’. So an application running on QM1 needs to do a PUT of a message that will land on ‘QXon8’ on QM8. Just map out the MQ components you would need to make that happen.
1.) On QM1 create a QRemote ‘QXon8’ which uses the xmit queue to ‘QM11’ (it should already exist right) and has a target queue say ‘hop2QXon8’ and set rqmname to 'QM11'.
2.) Then on QM11 create another QRemote called ‘hop2QXon8’ it will have as its xmit queue ‘QM8’(should again already exist) and a target queue of ‘QXon8’ and set rqmname to 'QM8'.
3.) Then on QM8 create the actual target local queue ‘QXon8’ .
Your done (for one queue any way!!).
You will need to repeat this for every target queue you wish to send to, on every non-hub qmgr Q1,QM2, … , QM10. Make sure your channels are all triggered and you have your own tedious hand made cluster without some of the benefits that come with MQ cluster such as load balancing, rerouting if QMn goes done, etc. . But I assume you cannot have direct connection between non-hub qmgrs as this is your stated requirement.
Hope this helps.
Cheers, _________________ "Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
Back to top |
|
 |
George Carey |
Posted: Fri Aug 24, 2007 1:42 pm Post subject: previous posts |
|
|
Knight
Joined: 29 Jan 2007 Posts: 500 Location: DC
|
Sorry I stepped away to quickly test my steps (as I hadn't set it up in awhile myself) and came back and hit submit and did not see the alternative post (likely simpler) of PeterP's using default Xmitq. And yes, I hope your hub is HAed.
rgrds, _________________ "Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
Back to top |
|
 |
jeevan |
Posted: Fri Aug 24, 2007 3:17 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
George/Peter,
Thank you very much for your valuable suggestion. My application is PM4DATA. It asks if we want to use the default transmision queue while installation. We already have installed it, so I think we can not use default transmission queue( I am not sure whether I can change that features in pm4data). The poing i am trying bring up here is, the destination queue can not be defined as the same connection is used for different purposes and use different queues. Would that be a problem?
George, I agree with you that we are going back but as I said, they may probably change the mq configuration soon. I will take these points to them and hopefully, they see the point.
Have nice weekend |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Aug 24, 2007 3:52 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Spoke QMs are called Spoke1, Spoke2, Spoke3....Spoke10.
Hub QM is code-named, er, HUB.
On each of the Spoke QMs, define a XMITQ called HUB that feeds a channel to HUB.
If you have any remote q defs defined on Spoke1-10, you can easily specify the XMITQ as HUB in the definition. But what about the apps that dynamically reply to the Reply2Q and Reply2QM? If an app on Spoke1 puts to queue called ReplyQueueA on QM Spoke2 the put will fail (actually the MQOPEN / MQPUT1 will fail) because Spoke1 will not know how to resolve to Spoke2. Sure, you could go a define QM Aliases on Spoke 1 for all the other Spoke QMs, but that's a pain. Anytime you add a new Spoke you gotta go everywhere and define a new Alias.
Instead, you turn on the Default XMITQ attribute of Spoke1 and say HUB is the default XMITQ. Now any message that cannot resolve will "catch" that default xmitq and be sent to the HUB.
Once the message gets to the HUB, it will see an XMITQ for the QM its trying to get to and the HUB will forward the message to that Spoke QM.
You could have 100 spoke QMs. If you add another one you dont have to do anything on all 100 spoke QMs. You just make sure the new spoke QM is properly talking to the HUB, you set the new spoke QM's defaut XMITQ to be HUB and instantly all 101 spoke QMs are able to talk to each other through the HUB.
DO NOT set the HUB QM's default XMITQ to a spoke QM. You will end up with an endless loop.
But again let me reiterate that now your HUB is very, very, very important. If it goes down your entire MQ network is dead.
I used to have a Hub and Spoke. The Hub was rather reliable. We used hardware clustering. But no solution is 100%. Whenever there was a problem with the Hub, ugh. I got rid of Hub and Spoke, elegant as it was, and have a combination of MQ clustering and point to point. I sleep easier knowing the entire company is not relying on one Hub server!
Hub and Spoke only makes sense if:
You are always adding and deleting QMs that all need to talk to each other (to much work to define 56 channels and XMITQs each time)
-AND-
you are afraid of MQ clustering -OR- you are in the stone age and using a version of MQ older than MQ 5.3 ~csd5 or 6. Prior to that MQ clustering was still a bit flaky. MQ Clustering nowadays is very stable. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jeevan |
Posted: Mon Aug 27, 2007 1:43 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
Peter,
Thank you very much for your detailed explanations. However, I still have one doubt as I could not test this setup in a single computer.
Let's suppose I have 3 qmgrs:
MH1
MH2
MH3
My requirement is to enable the app(pm4data ) to put message on either of the two local queues:
CQ.EXIT
CQ.FTS.DATA
On qmgr MH3 connecting to MH1 (MH1 is source node/qmgr and MH3 is destination node/qmgr). Let's not get confused with a node. A node is just a qmgr for our purpose.
As I said, I can not turn the default xmitq on so I am going to define a qmgr alias for MH3 (in this case and for all destination qmgr in future) at qmgr MH1. The definitions of MQ objects at different qmgr are as follows:
At MH1
xmitq : MH2
remote queue ( qmgr alias) MH3 defined as follows:
rqmname : MH3
xmitq : MH2 ( for hub)
rqname : TEST2 ( a remote queue in MH2)
sender channel to MH2
at MH2
a receiver channel from MH1
a sender channel to MH3
a xmitq MH3
a remote Queue TEST2 with following details
rqname : MH3
xmitq : MH3
destination queue ( blank) as I do not know which queue is chosen by the systems to put the message
At MH3
receiver channel from MH2
What I am trying to test here is whether I can leave the rqname blank in TEST2 remote queue definition at MH2 supposing the initial message has the name of the destination queue, and leaving blank at TEST2 definition, it will find that queue once the message arrives in qmgr MH3.
Thank you very much, |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Aug 27, 2007 3:48 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Why can't u turn on the default xmitq?
Anyway, if you can't / wont, do this:
At MH1
xmitq : MH2
remote queue ( qmgr alias) MH3 defined as follows:
rqmname : MH3
xmitq : MH2 ( for hub)
rqname : BLANK (don't put anything here, otherwise its a plain remote q and not a QM Alias)
sender channel to MH2
at MH2
a receiver channel from MH1
a sender channel to MH3
a xmitq MH3
At MH3
receiver channel from MH2
the local queues CQ.EXIT and CQ.FTS.DATA
The app connected to MH1 will need to put to CQ.EXIT or CQ.FTS.DATA while also specifying the destination QM as MH3. The MH3 QM Alias on MH1 will catch this message and send it to MH2 and MH2 will send it to MH3.
Or, you can define a plain old remote q on MH1 like this:
Q Name - CQ.EXIT
Remote Q Name - CQ.EXIT
Remote QM Name - MH3
XMITQ - MH2
If you do this you don't need the MH3 QM Alias on MH1, but it doesn't hurt to have it either.
If you turn on Default XMITQ, you don't need the remote q def OR the QM Alias on MH1 as long as the putting program specifies the destination QM on the MQOPEN / MQPUT1. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jeevan |
Posted: Fri Sep 07, 2007 3:29 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005 Posts: 1432
|
Peter,
It worked wonderfully. I implementated today. But I am trying to pusht folks to move into MQ cluster.
Thank you very much, |
|
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
|
|
|
|