| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Channel Failover |
« View previous topic :: View next topic » |
| Author |
Message
|
| dawerbuch |
 Posted: Mon Oct 20, 2008 6:59 am Post subject: Channel Failover |
 |
|
Novice
Joined: 16 May 2001
Posts: 20
Location: New York, NY
|
I would like to know how this scenario is being handled by others, please contribute your design.
We have a connection to a customer who does not provide us with a virtual IP. when the customers primary connection point fails, we are expecting to switch over to another connection (same channel name, different host).
If you face this scenario, how are you handling it right now?
Thanks,
Dave
_________________
-=--=--=--=--=--=--=--=--=--=--=--=-
David Awerbuch - IBM Certified MQSeries Specialist
WMQ Systems Administrator
Bloomberg LP
email: dawerbuch -at- bloomberg.com
email: david_awerbuch -at- yahoo.com
Tele: 1-212-617-6184 |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Oct 20, 2008 7:05 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Use of a queue manager alias in the two receiving queue managers will remap the RQMNAME in your QREMOTE, and requires you changing the CONNAME in your channel, and resetting the count.
_________________
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: Mon Oct 20, 2008 7:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Do you know in advance the failover ipaddress? If so, you could automate (script) the stop channel command, alter the conname attribute, start channel command. The channel failure will cause an event message to go to the SYSTEM.CHANNEL.EVENT queue.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Mon Oct 20, 2008 7:24 am Post subject: Re: Channel Failover |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| dawerbuch wrote: |
We have a connection to a customer who does not provide us with a virtual IP. when the customers primary connection point fails, we are expecting to switch over to another connection (same channel name, different host).
|
At their DR site, I assume they have another QM (maybe named the same) with the same channel names. Important question: is that a completely separate QM, or are they failing over all the storage so it will come up with the same QM name, the same data, the same channel sequence #s? I guess not, since if they were doing ALL that, why not provide a VIP. And if they are, I assume they storage replication is asynchronous, so the seuqence #s are gouing to be behind anyway.
I'll assume a different QM, maybe with the same name.
Lets call their QM QM1.
On your QM, make 2 XMITQs.
QM1.XMITQ, feeding a channel to their primary QM1
QM1.DR.XMITQ, feeding a channel to their DR QM1
Then create a Qm Alias on your QM called QM1, pointing at QM1.XMITQ. When DR strikes, you repoint the QM Alias, and any other Remote Q defs, to use QM1.DR.XMITQ. The benefit here is that you can test both sets of channels anytime (assuming they allow you to connect to their DR QM during DR tests) and you don't have sequence # issues. Drawback is if you have open objects you have to force the change on the q defs on your side and then your apps have to reopen the queues because of THEIR disaster.
Otherwise, if you use just one XMITQ and SNDR, when they DR, you stop your channel, change the CONNAME, reset the sequence #s on the SNDR, restart the SNDR. Your RCVR will be out of sequence too. Either its their responsability to reset it from their DR QM, or you provide them with a DR RCVR channel to use just from their DR QM, or you can parse your error logs and reset your RCVR's sequence # to match what their DR SNDR is sending.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 20, 2008 8:18 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter, easier on admin:
Keep the 2 channels concept but with one xmitq only.Both chls use the same xmitq: not a problem since both chls will not be active at the same time.
So when switching just stop chl_1 and modify the chl name in the trigdata of the xmitq to point to chl_2. Start chl_2. Done. The apps don't have to change and you don't have to bother with seqnum and conname on the channels
Additional advantage: messages blocked because of channel retry get to go on the DR channel as they are on the xmitq...
Enjoy 
_________________
MQ & Broker admin
Last edited by fjb_saper on Mon Oct 20, 2008 8:34 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 20, 2008 8:30 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Yes, that is simpler. Can't test both links concurrently like you can if you had 2 XMITQs, but maybe that's not possible or important.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| dawerbuch |
| Posted: Mon Oct 27, 2008 11:41 am Post subject: Channel Failover |
|
|
Novice
Joined: 16 May 2001
Posts: 20
Location: New York, NY
|
| bruce2359 wrote: |
| Do you know in advance the failover ipaddress? If so, you could automate (script) the stop channel command, alter the conname attribute, start channel command. The channel failure will cause an event message to go to the SYSTEM.CHANNEL.EVENT queue. |
Yes, this was my initial thought, because we do know the alternate IP address.
Thanks, everyone for your input!
Dave
_________________
-=--=--=--=--=--=--=--=--=--=--=--=-
David Awerbuch - IBM Certified MQSeries Specialist
WMQ Systems Administrator
Bloomberg LP
email: dawerbuch -at- bloomberg.com
email: david_awerbuch -at- yahoo.com
Tele: 1-212-617-6184 |
|
| 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
|
|
|
|
