| Author |
Message
|
| fjb_saper |
 Posted: Tue Oct 25, 2011 12:28 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Sorry I missed the fact where the other app was a qmgr....
Now it is somewhat messy, but if the sending qmgr is at V6 and receiving qmgr is V7.0.1 MI, you could still define 2 channels (one for each instance) sharing the same xmitq and have them triggered.
But on failover you would have to update the channel name in the Trigger Data field on the xmitq, and stop one channel and start the other....
This could all be automated on a script.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| LouML |
| Posted: Tue Oct 25, 2011 12:41 pm Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| fjb_saper wrote: |
Sorry I missed the fact where the other app was a qmgr....
Now it is somewhat messy, but if the sending qmgr is at V6 and receiving qmgr is V7.0.1 MI, you could still define 2 channels (one for each instance) sharing the same xmitq and have them triggered.
But on failover you would have to update the channel name in the Trigger Data field on the xmitq, and stop one channel and start the other....
This could all be automated on a script.... |
The problem then, is that all that work needs to happen at the external companies. Not sure how happy they'll be about having to do it.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 25, 2011 12:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| LouML wrote: |
The problem then, is that all that work needs to happen at the external companies. Not sure how happy they'll be about having to do it. |
The alternative for you, is to set up a virtual IP that would forward the call to the running instance... (ip/port). As both instances would not be running at the same time, may be a load balancer could handle it? Talk to your network team...
That is unless you want to put your QM into a true HA and not MI...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 25, 2011 1:08 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| LouML wrote: |
The problem then, is that all that work needs to happen at the external companies. Not sure how happy they'll be about having to do it. |
The alternative for you, is to set up a virtual IP that would forward the call to the running instance... (ip/port). As both instances would not be running at the same time, may be a load balancer could handle it? Talk to your network team...
That is unless you want to put your QM into a true HA and not MI... |
we started there. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 25, 2011 1:14 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The MR01 SupportPac is a channel exit that cycles through a list of CONNAMEs, trying them until one works. It's intended for a WAS Messaging Engine but may be usable (provided your externals are happy to use it) for connecting to MI queue managers. I did evaluate it for that reason some time ago, precisely to see if V6.0 queue managers could use it to connect to MI queue managers, but got stopped before I got it working properly - apparently something more important came up. 
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Oct 25, 2011 4:23 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| If it were me, I'd investigate if MQIPT has been updated at v7.0.1 to handle this kind of situation, where you need to expose an MI qmgr to a non-MI aware qmgr. |
|
| Back to top |
|
|
| LouML |
| Posted: Wed Oct 26, 2011 4:29 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| exerk wrote: |
| The MR01 SupportPac is a channel exit that cycles through a list of CONNAMEs, trying them until one works. It's intended for a WAS Messaging Engine but may be usable (provided your externals are happy to use it) for connecting to MI queue managers. I did evaluate it for that reason some time ago, precisely to see if V6.0 queue managers could use it to connect to MI queue managers, but got stopped before I got it working properly - apparently something more important came up. |
I like this idea. Will look into it.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 26, 2011 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| mqjeff wrote: |
| If it were me, I'd investigate if MQIPT has been updated at v7.0.1 to handle this kind of situation, where you need to expose an MI qmgr to a non-MI aware qmgr. |
From what I looked into last night none of the online documentation for MS81 references a Multi Instance qmgr in V7 and all examples still show host + port as a single destination. Maybe as an enhancement for the next release?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| LouML |
| Posted: Wed Jan 04, 2012 5:42 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| fjb_saper wrote: |
Sorry I missed the fact where the other app was a qmgr....
Now it is somewhat messy, but if the sending qmgr is at V6 and receiving qmgr is V7.0.1 MI, you could still define 2 channels (one for each instance) sharing the same xmitq and have them triggered.
But on failover you would have to update the channel name in the Trigger Data field on the xmitq, and stop one channel and start the other....
This could all be automated on a script.... |
Picking this up again after working on some other stuff...
I had a thought about dealing with external companies running MQ versions that do not support multiple connames on a Sender channel CONNAME definition.
Currently, we have a sender/receiver channel pair setup. So, both sides need to define the CONNAMEs on their sender channels.
Suppose we change this to sender/requestor channel pair. This way, we'd be driving things. Our sender would work as it does now, but for inbound from the external companies, they'd just be connecting to whatever IP we come to them as.
Any comments?
EDITING for Clarification - Ignore the part where I said "Our sender would work as it does now". I meant that our current config is for two-way traffic. We have a sender to them and a receiver from them. For this we're just talking about them-to-us.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| mehedi |
| Posted: Wed Jan 04, 2012 9:18 am Post subject: Re: Anyone running Multi-Instance QM in Production yet? |
|
|
Centurion
Joined: 11 Nov 2001
Posts: 102
Location: PSTech
|
| mqjeff wrote: |
| LouML wrote: |
| Some people have suggested we supply the external firms with a VIP or a DNS name so in the event of a QM failover, the could reconnect. However, this is not the same as the automatic failover provided with MIQM. |
No? Are you sure?
You don't get client automatic reconnect unless the client is at v7.0.1 minimum... Note that client automatic reconnect is not the same thing as failover.
A VIP that is moved by an MQ service that runs at qm startup should provide what you're looking for. But again, clients won't do automatic reconnect if they're not at v7.0.1 |
Jeff, the VIP will get assigned to the active server by the network solution, this without needing the intervention of the MQService. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 04, 2012 9:46 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
| LouML wrote: |
Picking this up again after working on some other stuff...
I had a thought about dealing with external companies running MQ versions that do not support multiple connames on a Sender channel CONNAME definition.
Currently, we have a sender/receiver channel pair setup. So, both sides need to define the CONNAMEs on their sender channels.
Suppose we change this to sender/requestor channel pair. This way, we'd be driving things. Our sender would work as it does now, but for inbound from the external companies, they'd just be connecting to whatever IP we come to them as.
Any comments? |
Clever idea. I don't see why it wouldn't be worth trying out. But it makes me wonder why IBM is not offering it up as a solution in the manuals or a Tech Note - if it works it addresses one of the bigger drawbacks to Multi Instance QMs. Perhaps there is fatal flaw to this concept?
One (minor) problem would be how do you make up for the lack of channel triggering. I guess it would involve some monitoring and scripts on your end to always keep the channel running whenever there is the potential for a message from the other side.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mehedi |
| Posted: Wed Jan 04, 2012 11:29 am Post subject: |
|
|
Centurion
Joined: 11 Nov 2001
Posts: 102
Location: PSTech
|
Peter,
The approach works , there is no fatal flaw, and using VIP(Virtual IP's) is the way to quickly implement Multi-instance qm's ,
without waiting on updates to
1. sdr channels to use multiple connames (for qm's)
2. client connections to use mulitple connames(for client apps) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 04, 2012 5:06 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Just to be clear, the potential "fatal flaw" I was referring to was with the idea of using Server / Requestor pairs to allow pre MQ 7 QMs to talk with a Multi Instance QM - not that Multi Instance QMs were fatally flawed.
Seems like Server / Requestors wold work and would allow the implementation to occur under the control of the MQ Admins (no need to rely on the network team to define and maintain VIPs). If it does work, why no mention of it to date?
VIPs seem like a workable solution as well, although with another player in the mix (the Network guy), and have the added benefit of working for older MQ Clients. But this solution is also missing from IBM's official doc on Mutli Instance QMs. I wonder if these are conscious omissions.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 04, 2012 6:34 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| But this solution is also missing from IBM's official doc on Mutli Instance QMs. I wonder if these are conscious omissions. |
It's a solution entirely outside of WebSphere MQ.
The most you can do with MQ to manage a VIP, or even acknowledge a VIP, is to use an MQ Service object to react to the qmgr startup/shutdown. |
|
| Back to top |
|
|
| LouML |
| Posted: Thu Jan 05, 2012 5:40 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
I have successfully tested it with a RQSTR/SVR instead of a RQSTR/SDR. I did not see how to define the SDR channel on the remote end for callback. The DEFINE CHL runmqsc command requires a CONNAME
Some notes:
- A remote SDR with multiple CONNAME hosts defined will restart upon failover
- A remote SVR channel will not restart upon failover (obvious, but just noting the differences). After failover, the SVR channel (from the remote QM perspective) will remain (or appear to be) running until the DISCINT. So, a STOP and START of the RQSTR channel is needed. I thought of setting up the SVR on the remote end with a very small DISCINT, but then I'd need a script on the local end to repeatedly issue START on the RQSTR channel.
I agree with Peter, sometimes dealing with Network support can be tricky. However, I think between the two solutions (VIP and RQSTR channel), we should be able to move forward in dealing with our external clients.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
|
|
