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 » MQ queue manager failover

Post new topic  Reply to topic
 MQ queue manager failover « View previous topic :: View next topic » 
Author Message
raindew
PostPosted: Fri Jun 29, 2012 1:23 pm    Post subject: MQ queue manager failover Reply with quote

Newbie

Joined: 13 Oct 2010
Posts: 9

Hi All,

Wanted to know if failing over of queue manager apart from during the maintenance outage is acceptable in production environment.

Any documentation or link to the best practice as to what are the scenarios when the queue manager can be failed over would be useful.

thanks!
Back to top
View user's profile Send private message
SAFraser
PostPosted: Fri Jun 29, 2012 3:15 pm    Post subject: Reply with quote

Shaman

Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA

It is quite acceptable, if properly designed and configured. Check the System Administration Guide (Configuration and Management section) through the Info Center link above. It describes high availability options for MQ.

Be sure and evaluate your client applications' ability to reconnect as you consider HA solutions.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Sat Jun 30, 2012 3:25 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Usually failover is viewed as acceptable because it is understood that the other choice is merely "fail".
Back to top
View user's profile Send private message
smdavies99
PostPosted: Sat Jun 30, 2012 8:35 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

Many organsations 'fail over' their systems on a regular basis just to make sure that when they need to for business reasons it really does work.

Think of it much like checking the recoverability of your system backups just to make sure that when you really need to, you can.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
exerk
PostPosted: Sat Jun 30, 2012 10:19 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

smdavies99 wrote:
Many organsations 'fail over' their systems on a regular basis just to make sure that when they need to for business reasons it really does work.

But not surprising that a number also do not allow that to happen because it's 'too disruptive'...

smdavies99 wrote:
Think of it much like checking the recoverability of your system backups just to make sure that when you really need to, you can.

...and then finding out they're right up effluent creek without a paddle because they haven't done the above.
_________________
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
raindew
PostPosted: Thu Jul 05, 2012 12:12 pm    Post subject: Reply with quote

Newbie

Joined: 13 Oct 2010
Posts: 9

Problem that we're facing is that some of the applications are not coded for failover. Not sure of how to mitigate this issue. Applications written in .net
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Jul 05, 2012 12:29 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

raindew wrote:
Not sure of how to mitigate this issue.


Apply a trout vigorously to the side of the relevant developer's head?

It's not exactly hard to code an application to deal with a failover nor is it an esoteric concept. Any networked application should have code to deal with temporary connectivity issues and there's no difference if the "network" happens to be wrapped in WMQ. If your applications are coded on the assumption everything is constantly lollypops and daisies, you have more significant issues than managing fail over.

Remember that any WMQ client application should neither know nor care what queue manager it's connected to, both in terms of name and in terms of if that instance of the queue manager is the usual one or the fail over instance.

And before any one says anything, note that I deliberately didn't say "passive". The fail over instance here could be one of the other actives in an active / active set up.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
zpat
PostPosted: Thu Jul 05, 2012 11:15 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

MQ client applications are rarely coded properly in my experience - ones from third-party vendors included.

So a deliberate fail-over during working hours would not be popular at my site and even getting a weekend maintenance slot is hard.

The client auto-reconnect feature can help with this issue (although it does have a number of limitations).
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » MQ queue manager failover
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.