| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ with HA when the destination app is down? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Sam Uppu |
 Posted: Mon Oct 19, 2009 12:33 pm Post subject: MQ with HA when the destination app is down? |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
We are using MQ version 7.0.0.1 on Solaris.
There are 3 QMgrs in a cluster called CLUS1. The QMgrs are QM1, QM2, QM3 and there is a cluster queue - CLUSQ defined on QM2 and QM3.
The source app will connect to QM1 and place the msgs onto CLUSQ.
The msgs will load balance between QM2 & QM3. The destination application(2 instances: each instance on QM2 & QM3) will listen on CLUSQ on both QM2 and QM3.
Question:
Now if any of the destination app instance is down either of QM2 or QM3, the msgs wont be processed and will be piling up on the CLUSQ on QM2 or QM3(whichever destination app is down).
We have purchased Veritas for these machines. Can we use the common(share) disk for /var/mqm, /var/mqm/log filesystem for QM2 and QM3 queue managers and Veritas s/w sothat the msgs will be processed by destination app instances whichever is up and if both the instances are up, both will process the msgs from CLUSQ on QM2 and QM3.
Please let me know whether this is feasible?.
Thanks. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Oct 19, 2009 1:16 pm Post subject: Re: MQ with HA when the destination app is down? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| Please let me know whether this is feasible?. |
No.
If both queue managers are up, you'll get file conflicts on /var/mqm. I'd also be surprised if you could explain this kind of set-up to Vertias. Even if you could, how do you plan to explain to QM3 that it should be examining files in the QM2 path?
Now it's straightforward to set Vertias up such that QM2 is restarted on QM3's hardware and vice versa. How well this works is largely reliant on how much spare resource the other machine has.
Another common set up is to have one spare machine (perhaps running low priority batch) and have Vertias fail either QM2 or QM3 onto it in the event of failure.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Oct 19, 2009 1:33 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
The destination app was asking whether anything MQ can detect if the app instance is down(not processing the msgs) and stop sending the msgs to it.
We are using Omegamon for monitoring MQ and we can detect the queue depths if the app is down but it will take some time to get onto the machines and divert the traffic or get hold of the destination app team to make it up and running.
I was looking for any other solution to avoid this outage and automate it sothat the msg processing delay would be avoided.
Thanks for your thoughts. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 19, 2009 1:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
We are using Omegamon for monitoring MQ and we can detect the queue depths if the app is down but it will take some time to get onto the machines and divert the traffic or get hold of the destination app team to make it up and running.
I was looking for any other solution to avoid this outage and automate it sothat the msg processing delay would be avoided. |
I can think of 2 possible solutions, there are undoubtably others:
1) Monitor the app with Vertias, and have it fail over when the destination app fails
2) Monitor the destination queue with Omegamon, assume that the destination app is down if there are no open handles on the queue or the depth is past a threshold and change the cluster attributes to divert traffic to the running instance.
In your position I'd go with option 1, as (given the hardware) it's like falling off a log. Option 2 is a bit more fiddly, but still doable. It also doesn't require Veritas so you can save the license fee for it....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Oct 21, 2009 10:54 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
I can think of 2 possible solutions, there are undoubtably others:
1) Monitor the app with Vertias, and have it fail over when the destination app fails |
If the destination app is configured on Veritas and If both the QMgrs, QM2 and QM3 are up and running, will the two instances of the app will be taking traffic..one on QM2 and the other on QM3?. Doesn't it just similar to configuring QM2 and QM3 on Veritas?.
| Vitor wrote: |
| 2) Monitor the destination queue with Omegamon, assume that the destination app is down if there are no open handles on the queue or the depth is past a threshold and change the cluster attributes to divert traffic to the running instance. |
Can we do this with Omegamon to change the queue attributes and route the traffic to other QMgr?. I know Omegamon can monitor the QMgr and its object but not sure whether it can be of programmable/configurable to take special actions. I am sure I have to look into the Omegamon XE's features on this.
Please shed some light on this.
Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 21, 2009 11:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| Vitor wrote: |
| 1) Monitor the app with Vertias, and have it fail over when the destination app fails |
If the destination app is configured on Veritas and If both the QMgrs, QM2 and QM3 are up and running, will the two instances of the app will be taking traffic..one on QM2 and the other on QM3?. Doesn't it just similar to configuring QM2 and QM3 on Veritas?. |
It's not similar to, it's identical to. What I'm proposing is a straightforward implementation of Vertias that controls and restarts either QM2 or QM3 & their attendant apps in the event of failure. It's out-of-the-box Veritas, the support pac will help with the WMQ part and it's like falling off a log.
It also eliminates any involvement of the WMQ cluster in the HA part, which is the ideal solution.
| Sam Uppu wrote: |
| Vitor wrote: |
| 2) Monitor the destination queue with Omegamon, assume that the destination app is down if there are no open handles on the queue or the depth is past a threshold and change the cluster attributes to divert traffic to the running instance. |
Can we do this with Omegamon to change the queue attributes and route the traffic to other QMgr?. I know Omegamon can monitor the QMgr and its object but not sure whether it can be of programmable/configurable to take special actions. I am sure I have to look into the Omegamon XE's features on this. |
IIRC Omegamon is capable of taking some actions in the event of failure, though I doubt it will handle the failback.
IMHO you should just use Vertias as the HA solution and keep WMQ out of it. It's why you bought Veritas after all. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 21, 2009 11:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| Vitor wrote: |
I can think of 2 possible solutions, there are undoubtably others:
1) Monitor the app with Vertias, and have it fail over when the destination app fails |
If the destination app is configured on Veritas and If both the QMgrs, QM2 and QM3 are up and running, will the two instances of the app will be taking traffic..one on QM2 and the other on QM3?. Doesn't it just similar to configuring QM2 and QM3 on Veritas?. |
To clarify here: this is not how you'd set up Veritas. You don't just put the app under Veritas control, you put the entire stack. So if the app, or the qmgr, or whatever else it needs falls over then Veritas fails the whole lot over, or should be configured to.
But in this scenario, there will always be an instance of QM2 (plus app, etc) and QM3 running. Just not always where you expect them to be.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Wed Oct 21, 2009 2:40 pm Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Thanks Vitor for your help on this. |
|
| 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
|
|
|
|
