| Author |
Message
|
| rammer |
 Posted: Fri Dec 10, 2004 3:46 am Post subject: MQ Clustering |
 |
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Hi,
I have been asked the following question.
Is it possible to use MQ Clustering for failover. I realise they are not looking at true hardware failover so they mean hot availabilty.
What is required is the following:
Messages to be sent from one queue manager to one dedicated queue manager. If there is a problem with the end queue manager a alternative is to be used as fast as possibly can for all subsequent message to be processed and any messages stuck on the faulty queue manager will be processed when recovery has taken place.
The application has got to process all or nothing so load balancing via clustering at first was not thought to be the answer but if I was to say "put Disable" the standby processing queue that is part of the cluster and only "put enable" if we hit a problem would that work? Or are there more conventional ways of doing this.
Regards
Rammer |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Dec 10, 2004 4:03 am Post subject: Re: MQ Clustering |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| rammer wrote: |
| I have been asked the following question. |
So have we.
Many times.
Please look for similar entries in the Clustering forum.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rammer |
| Posted: Fri Dec 10, 2004 4:22 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Sorry Jeff
I should have said I have read through the Clustering Posts but can not find anything that explains it to me in my terms (simple) 
Im not actually sure if using clustering is the best option for this but instead maybe ask the developers to put some logic in there application as to when the put is done it tries to see if the queue is available, the only problem being we may be going via a hub to get to the destination.
Regards
Rammer |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 10, 2004 5:18 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Simple = NO
MQ clustering enables load balancing
Hardware clustering enables failover.
Enjoy  |
|
| Back to top |
|
|
| rammer |
| Posted: Fri Dec 10, 2004 6:06 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Hi I realise it provides load balancing and not fault tolorence its just that I have been asked if we can provide a solution for a standby queue manager in case of failure at the receiving end. So I was thinking of using clustering but on one of the clustered queue managers actually "put" disabling the destination queue so that all messages are routed to the prefered queue manager. If there is a problem with that queue manager we can start the other clustered Queue on alternative QM by "put" enabling the local queue.
Regards
Rammer |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 10, 2004 6:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If your business is not able or willing to pay for real hardware failover, then the cost of downtime is not sufficiently high to warrant real hardware failover.
If that is the case, then it is not worth putting in *any* kind of failover. You will end up spending time implementing a cluster based system, and maintaining it. This will likely end up being just as expensive as a real hardware failover system.
If you don't know the cost of downtime, I'm sure someone does. Get them to tell you before you do anything.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 10, 2004 10:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rammer wrote: |
Hi I realise it provides load balancing and not fault tolorence its just that I have been asked if we can provide a solution for a standby queue manager in case of failure at the receiving end. So I was thinking of using clustering but on one of the clustered queue managers actually "put" disabling the destination queue so that all messages are routed to the prefered queue manager. If there is a problem with that queue manager we can start the other clustered Queue on alternative QM by "put" enabling the local queue.
Regards
Rammer |
Just as easy and simpler to have another QM on another server, on and just sitting there. When your primay QM on your Primary server gets stomped on by Godzilla, stop the SNDR channel on the sending QM, change the conname to point to the back server, start the channel, and problem solved (to the degree your company is willing to pay for).
Any stuck persistent messages on the down server are N/A until you get it back up, if you can get it back up.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rammer |
| Posted: Mon Dec 13, 2004 6:43 am Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Hi Peter,
Know I like that idea very simple.
Cheers
Rammer |
|
| Back to top |
|
|
| dgolding |
| Posted: Mon Dec 13, 2004 6:54 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
| PeterPotkay wrote: |
Any stuck persistent messages on the down server are N/A until you get it back up, if you can get it back up. |
You will have exactly the same problem with stuck messages on a clustered queue manager. So, you lose nothing (with regards to providing a failover solution) by going down this route.
Just a minor point, configure two sender channels, one to the primary, and one the secondary, but both channels sharing the same XMITQ. Then all you need do is stop the primary channel and start the secondary. This saves fiddling about changing the conname back and froth - and becomes a real simple procedure you can give to your first-level ops. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 13, 2004 3:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dgolding wrote: |
| PeterPotkay wrote: |
Any stuck persistent messages on the down server are N/A until you get it back up, if you can get it back up. |
You will have exactly the same problem with stuck messages on a clustered queue manager. So, you lose nothing (with regards to providing a failover solution) by going down this route.
Just a minor point, configure two sender channels, one to the primary, and one the secondary, but both channels sharing the same XMITQ. Then all you need do is stop the primary channel and start the secondary. This saves fiddling about changing the conname back and froth - and becomes a real simple procedure you can give to your first-level ops. |
If you do that however you will have to specify which channel is supposed to be triggered in the xmitq. And you will have to change this every time you switch between normal and backup qmgr channel.
Enjoy |
|
| Back to top |
|
|
|
|
