ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Automatic MQ switchover

Post new topic  Reply to topic Goto page 1, 2  Next
 Automatic MQ switchover « View previous topic :: View next topic » 
Author Message
vinay_s_s
PostPosted: Thu Apr 28, 2011 4:10 am    Post subject: Automatic MQ switchover Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Apr 28, 2011 4:21 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Apr 28, 2011 4:22 am    Post subject: Re: Automatic MQ switchover Reply with quote

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
View user's profile Send private message
vinay_s_s
PostPosted: Thu Apr 28, 2011 4:32 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Apr 28, 2011 4:41 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Apr 28, 2011 4:42 am    Post subject: Reply with quote

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
View user's profile Send private message
shashivarungupta
PostPosted: Thu Apr 28, 2011 4:52 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
exerk
PostPosted: Thu Apr 28, 2011 4:54 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Thu Apr 28, 2011 4:58 am    Post subject: Reply with quote

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
View user's profile Send private message
shashivarungupta
PostPosted: Thu Apr 28, 2011 5:00 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
shashivarungupta
PostPosted: Thu Apr 28, 2011 5:02 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
Vitor
PostPosted: Thu Apr 28, 2011 5:22 am    Post subject: Reply with quote

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
View user's profile Send private message
Gerd-in-ZA
PostPosted: Thu Apr 28, 2011 12:52 pm    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Thu Apr 28, 2011 1:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Thu Apr 28, 2011 1:22 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » Automatic MQ switchover
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.