| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| failover with non MI qmgr |
« View previous topic :: View next topic » |
| Author |
Message
|
| jeevan |
 Posted: Thu Apr 22, 2010 6:14 am Post subject: failover with non MI qmgr |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
Is it possible to set up qmgrs in MQ7.0.1 such that a cluster connection fails over to another queue manager which is not a MI qmgr. In fact these are completely two different queue managers.
The queue manager in question is running on AS400. We have a maintenance windows on friday night for about 4 hours. An ecom systems requires that the as400 is available at 24/7.
We can have another queue manager into anohter as400. But our challenge is how to make the cluster sender channel setup so that when the primary qmgr is down, it goes to secondary. Does the routing also have qmgrid in the mesage header so that these message can not landon the different queue manager.
We know we can turn this into distributed channel but we want to investigate whether we can do this in clustering environment. This requires that we have two conneciton name in the cluster sender channel and when it can not make a conneciton to the first qmgr, it goes to the second and makes a connection. Also, the message header does not have any qmgrid info.
Thanks
Last edited by jeevan on Mon Apr 26, 2010 5:05 pm; edited 1 time in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Apr 22, 2010 6:30 am Post subject: Re: failover with non MI qmgr |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeevan wrote: |
| Does the routing also have qmgrid in the mesage header so that these message can not landon the different queue manager. |
Yes. This is what causes messages to get "stuck" when you try and use an WMQ cluster for failover.
You should also realise that you never switch cluster sender channels to different destinations. This is Clustering 101. The sender channel points to a full repository, not to any given queue manager that might be the target of a message. That's the job of the cluster auto defined channels.
You can achieve something close to what you're trying by switching the priority of routes within the cluster, there have been a number of discussions in here on this subject. Nothing alters the basic fact that once a message has been addressed to a specific queue manager by the cluster (taking into account multiple targets, workload balancing and all the other good stuff), once it's on the SCTQ it's address to a specific queue manager and you can't change that without a lot of dancing.
So in your specific case, if you can make the maintenance wait until all the messages have started to flow to the secondary and the primary queue manager is finished then it could work albeit in a very manual way. In an actual failure situation you're going to have problems.
Also don't mix up multiple instance queue managers with cluster queue managers. A MI queue manager might or might not be in a cluster; it doesn't affect how the cluster works.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 8:08 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
WMQ clusters do not address stranded messages - messages that have been put to a queue AND the qmgr fails.
You might be looking for a front-end ip switch (virtual ip addressing) that routes inbound connect requests to whichever qmgr is available.
_________________
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 |
|
|
| jeevan |
| Posted: Mon Apr 26, 2010 5:03 pm Post subject: Re: failover with non MI qmgr |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| Vitor wrote: |
| jeevan wrote: |
| Does the routing also have qmgrid in the mesage header so that these message can not landon the different queue manager. |
Yes. This is what causes messages to get "stuck" when you try and use an WMQ cluster for failover.
You should also realise that you never switch cluster sender channels to different destinations. This is Clustering 101. The sender channel points to a full repository, not to any given queue manager that might be the target of a message. That's the job of the cluster auto defined channels.
You can achieve something close to what you're trying by switching the priority of routes within the cluster, there have been a number of discussions in here on this subject. Nothing alters the basic fact that once a message has been addressed to a specific queue manager by the cluster (taking into account multiple targets, workload balancing and all the other good stuff), once it's on the SCTQ it's address to a specific queue manager and you can't change that without a lot of dancing.
So in your specific case, if you can make the maintenance wait until all the messages have started to flow to the secondary and the primary queue manager is finished then it could work albeit in a very manual way. In an actual failure situation you're going to have problems.
Also don't mix up multiple instance queue managers with cluster queue managers. A MI queue manager might or might not be in a cluster; it doesn't affect how the cluster works. |
Thank you Vitor. I compledtely forgot when I said having two connection parameters in cluster sender channel. You are absolutely correct. A cluster sender channel from a PR goes to FR not to a another PR(destination qmgr which hold the destination queue(s) )
I forgot to mention that we are trying to save licensing cost. So we are not looking both qmgr running silumtaneously. This is just for 4 hours in a week. I do not know much about what is available in as400 for failover( active/passive) for which IBM only charges fees for software in one box assuming the technology is considered as failover.
We have thought about utilising channel priority but have not given more thoughts.
We are also thinking about mirroring and starting the back up qmgr once the primary goes down manually or by same script which one shuts down and brings the second one.
if there wouuld not be cost saving objective, we can just join the qmgr on cluster with higher/lower channel priority so once the priormary goes down, messages go to the other one without any further efforts. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 26, 2010 8:07 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
In order to save licensing cost you will either have to have your qmgr used as DR like in V6 or as a multi instance qmgr in V7.
Have fun 
_________________
MQ & Broker admin |
|
| 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
|
|
|
|
