Author |
Message
|
vinay_s_s |
Posted: Thu Apr 28, 2011 4:10 am Post subject: Automatic MQ switchover |
|
|
 Apprentice
Joined: 17 Nov 2008 Posts: 39
|
Hi Guys,
Is there a way to completely automate the switching of a sender channel from pointing to one destination conname to an other.
For example I have two queue managers - 1 primary and 1 DR. The sender channel at the source side is connected to the primary on the destination side. In case the primary queue manager goes down or the node has any problem, is there a way that the channel would connect automatically to the DR queue manager, reset the sequence number and start running again?
I just want to prevent manual intervention during a disaster. Is there any way to do it?
Thanks,
Vinay |
|
Back to top |
|
 |
exerk |
Posted: Thu Apr 28, 2011 4:21 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Yes, script it. Whether it would be a good idea to have a script that stops a channel, changes the CONNAME, resets the sequence number, and restarts the channel is another discussion. There is of course a way to do it 'natively' depending on platform, WMQ version, and geography.  _________________ 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.
Last edited by exerk on Thu Apr 28, 2011 4:24 am; edited 1 time in total |
|
Back to top |
|
 |
Vitor |
Posted: Thu Apr 28, 2011 4:22 am Post subject: Re: Automatic MQ switchover |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
vinay_s_s wrote: |
I just want to prevent manual intervention during a disaster. Is there any way to do it? |
Yes. Use DR software to fail the same queue manager onto the DR hardware rather than have 2 distinct queue managers. On WMQv7 or higher similar functionality exists in the base product. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
vinay_s_s |
Posted: Thu Apr 28, 2011 4:32 am Post subject: |
|
|
 Apprentice
Joined: 17 Nov 2008 Posts: 39
|
Exerk, Thanks for your input. However, I wanted to check if there is any way or feature in MQ for this to happen. I can write a windows service which keeps checking the status of sender channels using PCFs. If there is a change in status and if the status is not 'running' or 'inactive', just reset the sequence numbers and resolve the channel. This is fine.
Vitor, when you say DR software, do you mean the 'multi instance qmgr'? Thanks to you too, for your response.
Vinay |
|
Back to top |
|
 |
exerk |
Posted: Thu Apr 28, 2011 4:41 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
There is no inherent feature of WMQ that will achieve what you want - unless you use some form of HA. You can write a Windows service but what happens when that service interprets a channel drop as being a disaster and 'fails over'? Or the time taken to build in checks and balances means a recovery SLA missed? Better to use what both Vitor and I were alluding to, which is an MI or other-method HA queue manager. _________________ 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 |
|
 |
Vitor |
Posted: Thu Apr 28, 2011 4:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
vinay_s_s wrote: |
Vitor, when you say DR software, do you mean the 'multi instance qmgr'? |
In this context I mean Veritas, HACMP or any of the other products that handle the switching of resources from principle to alternate.
I'd recommend using whatever's already in place to automatically switch other resources (databases and so forth) from the principle to the alternate. If no such software is in place then what's your automated solution going to be using? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
shashivarungupta |
Posted: Thu Apr 28, 2011 4:52 am Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
vinay_s_s wrote: |
If there is a change in status and if the status is not 'running' or 'inactive' |
Inactive status :
The channel has ended processing normally or the channel has never started. Then why for Inactive ?
 _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
exerk |
Posted: Thu Apr 28, 2011 4:54 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
shashivarungupta wrote: |
Inactive status :
The channel has ended processing normally or the channel has never started. Then why for Inactive ? |
Because INACTIVE is a 'normal' state and the OP wants to identify abnormal states  _________________ 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: Thu Apr 28, 2011 4:58 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
INACTIVE state results from disconnect interval expiring. _________________ 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 |
|
 |
shashivarungupta |
Posted: Thu Apr 28, 2011 5:00 am Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
exerk wrote: |
shashivarungupta wrote: |
Inactive status :
The channel has ended processing normally or the channel has never started. Then why for Inactive ? |
Because INACTIVE is a 'normal' state and the OP wants to identify abnormal states  |
vinay_s_s wrote wrote: |
If there is a change in status and if the status is not 'running' or 'inactive' |
As OP has said clearly if the status is NOT running , its clear he is looking for those status which are not normal !!! ( whereas 'inactive' is normal state and this shouldn't be part of 'if then else' clause )  _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
shashivarungupta |
Posted: Thu Apr 28, 2011 5:02 am Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
bruce2359 wrote: |
INACTIVE state results from disconnect interval expiring. |
Agree !! And that's normal.  _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Apr 28, 2011 5:22 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
vinay_s_s wrote: |
If there is a change in status and if the status is not 'running' or 'inactive', just reset the sequence numbers and resolve the channel. This is fine. |
If by "fine" you mean potentially lose or duplicate a batch of messages then yes, it's fine.
Automatically resolving a channel is not a safe design. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Gerd-in-ZA |
Posted: Thu Apr 28, 2011 12:52 pm Post subject: |
|
|
Novice
Joined: 13 Sep 2006 Posts: 14 Location: Johannesburg, South Africa
|
Is there some "halfway official" writeup that explains the difference between HA (high availability) and DR (disaster recovery)? For an HA solution we have a number of automatic solutions (from HACMP and the like to MI QMs or even shared queues on z/OS). For DR - long distance and not completely lossless (no shared server infrastructure) - we have a number of suggested "patterns" but no fully reliable fully automatic solution. This may change over time - it has already improved dramatically over my younger years.
I suspect the OP here has asked for a DR solution asking HA questions and reaping a few HA answers with a bit of "wise-old-head-shaking" why he didn't know all of this in the first place.
Best practice for a disaster management scenario is to have prepared manually a number of scripts that can be invoked semi-automatically in order to ensure that the failover - which will be somewhat lossy and potentially very expensive to revert - takes place completely under control of humans that can decide to abort and revert if they determine that the disaster case has not been reached yet.
Best practice for an HA scenario is automatic failover with as little visibility to the clients as possible, all based on the one key ingredient: reliable automatic detection of the primary's failure.
Best practice overall: To let HA take its course and take remedial action on the failed components in order to restore the inherent redundancy of the HA solution and then to progress to the DR plans once it is determined that the HA infrastructure is too far gone (both instances) to expect to go back to it in the near future. The time limits for decisions should be clearly defined and communicated well ahead of time, procedures should be practiced regularly. Post mortem analysis needs to be performed after such exercises and procedures and parameters need to be adjusted accordingly where needed.
We should be writing a redbook about this if we haven't yet. _________________ -- Gerd -- |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Apr 28, 2011 1:19 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
exerk wrote: |
shashivarungupta wrote: |
Inactive status :
The channel has ended processing normally or the channel has never started. Then why for Inactive ? |
Because INACTIVE is a 'normal' state and the OP wants to identify abnormal states  |
A healthy channel starting up does not go from Inactive (or Stopped), directly to Running. There are intermediate states. When things are fine, those states exist for a very small window of time, but if your script happens to catch it at just that instance......All of the sudden the simple little script needs to get more complicated. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Apr 28, 2011 1:22 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Gerd-in-ZA wrote: |
I suspect the OP here has asked for a DR solution asking HA questions and reaping a few HA answers with a bit of "wise-old-head-shaking" why he didn't know all of this in the first place. |
 _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|