Author |
Message
|
etc181 |
Posted: Mon Feb 06, 2006 6:58 pm Post subject: MQ 5.3 Linux Clustering Pro's & Con's |
|
|
Newbie
Joined: 06 Feb 2006 Posts: 5
|
Hello,
We are Looking to deploy Websphere MQ 5.3 in a HA confguration. So far reading the docs it appears I have 2 options
1. One Manager & Queue on a box with a standby to take over. The Standby would use the same SAN and HA DB
2. Cluster the Q managers, mostly using local Queues.
It appears that option 2 will strand some messages for an indefinite period of time (until the failed Q Manager restarts), whereas option 1 prevents this from occuring.
Is this a fair comment? Is there anything else I should be aware of before commiting one way or the other? |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Feb 06, 2006 7:19 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I can't say if it's a fair comment or not.
It's accurate, though.
The first question you should ask is "What does HA mean to me?". And then you should ask "How much is HA worth to me?".
And when you answer these then you'll know if HA is necessary, useful, or not a major priority. And then you can decide if Clustering is good enough.
Remember that there is some down time in any real HA configuration when resources need to switch to and start up on the other machine. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
etc181 |
Posted: Mon Feb 06, 2006 8:54 pm Post subject: |
|
|
Newbie
Joined: 06 Feb 2006 Posts: 5
|
Thanks Jeff,
In this case HA means 2 things:
1. The queue managers remain available (amongst other things we are using Process Choreographer)
2. It is important for any message in the system not to be stranded.
I am keen to use clustering for the potential improvements in scalability and load balancing for performance, However unless it is possible to fail over the Clustered Q managers to continue to work with data that was inflight this will not be a reasonable approach.
Everything I have seen so far indicates this constraint rules out clustering for my circumstances. Are you aware of any mechanism to overcome this? |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Tue Feb 07, 2006 12:15 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
etc181,
HA provides you with continuity of processing in the case of hardware or system failures. The (persistent) messages are available again after a while (when the standby system came up).
MQ clustering provides you with continuous operations (your business may go on), but the messages on the failed system are not availabe (until this system comes up again).
The best solution is a combination of both - two QMgrs in a MQ cluster, each on a HA cluster node. _________________ Regards
Hubert |
|
Back to top |
|
 |
KramJ |
Posted: Tue Feb 07, 2006 5:18 am Post subject: |
|
|
Voyager
Joined: 09 Jan 2006 Posts: 80 Location: Atlanta
|
MQ clusters provide load balancing and reduced administration. For high availability failover you need HACMP. If your only going to implement one, and you main concern is business continuity, use HACMP. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Feb 07, 2006 5:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
HACMP doesn't apply to all platforms. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Tue Feb 07, 2006 11:56 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
jefflowrey wrote: |
HACMP doesn't apply to all platforms. |
or SunHA or VCS (Veritas) or MSCS (Microsoft) or VMS cluster or z/OS SYSPLEX ...
... each platform has its own solution. HACMP exists only for AIX. _________________ Regards
Hubert |
|
Back to top |
|
 |
etc181 |
Posted: Tue Feb 07, 2006 2:11 pm Post subject: |
|
|
Newbie
Joined: 06 Feb 2006 Posts: 5
|
>The best solution is a combination of both - two QMgrs in a MQ cluster, each on a HA cluster node.
This is where I have been confused by the document. Whenever they talk about clustered Q Managers, the Q Manager is local to the app server, using a local Q. I thought this was a limitation of clustering.
Is it possible then to set up 2 MQ Servers (not on the same box as the application servers, using SAN for the Q's)? If so I can see how this could be clustered with each Q manager having a hot standby. That would be ideal for my purposes |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Wed Feb 08, 2006 3:04 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
What you mean are shared queues and these only exist on z/OS. You cannot access the same physical queue (this meas, the same physical file) by more than one QMgr.
BUT, you can put the QMgr file to a SAN and then run the QMgr on another box - BUT NOT AT THE SAME TIME. _________________ Regards
Hubert |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Feb 08, 2006 9:39 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
HubertKleinmanns wrote: |
BUT, you can put the QMgr file to a SAN and then run the QMgr on another box - BUT NOT AT THE SAME TIME. |
This concept was recently posted here. I can't find the quote, but someone made the very good point that by the time you got this to safely work, you have reinvented a hardware clustering solution, and probably not as well as the companies who make hardware clustering solutions.
etc181, your not aiming to reinvent hardware clustering, are you? For instance, how are you going to insure that both QMs don't try and run at the same time? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Wed Feb 08, 2006 11:02 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
Peter,
cluster software and the needed hardware is quite expensive and in the past I had a customer, who wanted to install MQ on a removable disk, take this disk - in case of fail-over - manually to another server in another computer center, and run MQ on the new box .
This is also a sort of hardware cluster . _________________ Regards
Hubert |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Feb 08, 2006 11:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
HubertKleinmanns wrote: |
cluster software and the needed hardware is quite expensive |
But obviously less expensive than not meeting the business requirements, right?
Or else the business requirements are less "requirements" and more "suggestions". _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Wed Feb 08, 2006 11:35 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
jefflowrey wrote: |
But obviously less expensive than not meeting the business requirements, right? |
I would agree, but it is often a decision of the business people, not of the technical experts. Hard to calculate is the loss of reputation, when something goes wrong. _________________ Regards
Hubert |
|
Back to top |
|
 |
etc181 |
Posted: Wed Feb 08, 2006 2:45 pm Post subject: |
|
|
Newbie
Joined: 06 Feb 2006 Posts: 5
|
Hubert, yes, exactly shared Q's is the solution
But I don't have z/OS
Peter, absolutely not looking to reinvent the hardware cluster ( but will need to find one that is supported by the vendor/IBM with MQ )
Indeed this as always becomes a case of how much are you prepared to spend! Budget is not unlimited in this case, but there are valid reasons to specify something which reduces downtime.
Thanks everyone for your help!  |
|
Back to top |
|
 |
GMcCarthy |
Posted: Mon Apr 10, 2006 11:15 am Post subject: |
|
|
 Centurion
Joined: 06 Nov 2001 Posts: 113 Location: Melville NY
|
[quote="etc181
This is where I have been confused by the document. [/quote]
Are you speaking of the MQ Cluster manual?
Does anyone know of a good HA document for MQ? _________________ Regards,
Gina
IBM Certified MQSeries Specialist |
|
Back to top |
|
 |
|