| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Queue Manager as a single point of failure? |
« View previous topic :: View next topic » |
| Author |
Message
|
| JohnRodey |
 Posted: Wed Jun 29, 2005 10:05 am Post subject: Queue Manager as a single point of failure? |
 |
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
I know this may sound like a redundant topic.
I understand that if you are worried about the QM being a SPOF you can use hardware clustering, although this just solves the scenario of when a machine dies, then the other machine will pickup the others workload.
But hardware clustering wouldn't solve the issue of if a QM goes down. The applications waiting for messages from it will fail, and all application wanting to post messages to it will fail.
How do we get around this?
Does MQ offer a solution for this or does this solution have to be implemented in our code?
I guess, ideally I'm looking for a way for MQ to see request coming in for a dead QM and forward those requests to another QM (whether they be requests for gets or puts).
I don't think clustering QMs would ever be able to solve this either, because even if you have a gateway QM that handles distributing message you are still relying on the gateway QM to be up and running. |
|
| Back to top |
|
 |
| JohnRodey |
| Posted: Wed Jun 29, 2005 10:30 am Post subject: |
|
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
I guess what I really trying to get at is that I want to make MQ act like an app server.
Where I can have multiple app servers clustered together, and if one app server goes down then clients accessing that app server still act as if nothing went wrong. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 29, 2005 11:25 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you looked at WebSphereMQ version 6 and the Service Bus? Look up as well WebSphere Application Server version 6
Looks to me like you want to have multiple managers on the same bus.
Enjoy  |
|
| Back to top |
|
|
| JohnRodey |
| Posted: Wed Jun 29, 2005 12:30 pm Post subject: |
|
|
Centurion
Joined: 13 Apr 2005
Posts: 103
|
| So, without editing my code, is this functionality impossible with version 5.3? |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 29, 2005 12:41 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I don't see your problem. If you run the apps under MSCS or HA/CMP on the same platform as the queue manager, then they will be restarted as part of failover processing (along with the queue manager).
Of course there will be a momentary application outage.
If the apps run on different servers to the queue manager using client connections, then the code logic just needs to deal with the 2009 error and re-establish a connection (retry loop with a short delay) when the queue manager is failed over.
I prefer dedicated queue managers (active/passive) on HA/CMP or MSCS and apps servers with client channels to the active queue manager.
We do not see QMs as a SPOF - you do need to make sure the MQ apps have proper logic to reconnect after the QM fails over, that's all. It just needs to retry the same connection, as the IP address will move over.
You can play around with designs to use active/active QMs and make the apps try client connections to one of several queue managers from a list until successful, this may provide faster recovery and also can give load-balancing.
Or just use a mainframe QM, which never fails (and if it does there would be little point in sending messages to any application on it).
If you want to improve MQ application resilience, just use several apps servers reading the same queues, with client connections. They will automatically "compete" for messages and if one fails the others will simply get more messages. MQ client is underrated as a simple and flexible solution!
I have never used MQ clustering (can't see the point as it can result in orphaned messages), however you can combine this with hardware clustering if you enjoy an "interesting" life... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jun 29, 2005 7:21 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
| I have never used MQ clustering (can't see the point as it can result in orphaned messages), however you can combine this with hardware clustering if you enjoy an "interesting" life... |
We have our WB-IMB Brokers running on hardware clustering inside an MQ cluster. (The below applies for plain Queue Managers as well.)
If anyone Broker goes down, the MQ cluster automatically and instantly send all new work to the remaining brokers.
If anyone Broker goes down, the hardware clustering brings that broker up on the alternate node within minutes. As soon as it is up, the stranded messages are processed, and the broker rejoins the MQ cluster, to once again start sharing the workload.
Powerful stuff when used together.
If you have an MQ cluster, and you have QMs outside of the MQ cluster that need to chat with the QMs inside the cluster, then yes, you need a gateway QM, and it is a SPOF, and you minimize that risk by using hardware clustering. But it will never be 100%. Maybe 99.9999%.
However, for the other QMs, with competing clients, MQ clustering and hardware clustering, you can get the service as a whole to never appear to be down.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
