| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| It's Friday - good time for a discussion. |
« View previous topic :: View next topic » |
| Author |
Message
|
| offshore |
 Posted: Fri May 14, 2004 5:16 am Post subject: It's Friday - good time for a discussion. |
 |
|
Master
Joined: 20 Jun 2002
Posts: 222
|
All,
Throwing this question out here for discussion and probably some debate - haha 
Anyways, everytime someone askes a question about MQ clustering people immediately chime and say "MQ Clustering is not for failover. It's for workload balancing only!"
While I mostly  agree with that, I still think it's also used for failover purposes. Perhaps in MQ clusterings truest form it is for workload balancing, but I am currently using it as a form of fail over also.
Case in point - I use a combination of z/OS qmgrs and Windows hosts all in a cluster. I read most of the IBM Redbook "Websphere MQ in a z/OS parallel sysplex" With I realize this book is mainly geared towards z/OS MQ Series several times a distributed MQ is mentioned throughout the book also.
Ch 7 - "Using Websphere MQ Clustering Technology", specifically deals with clustering in general.
Ch 11 - "High Availability Setup", deals with clustering and also gets into z/OS specifics such as QSG.
Anyways, enough of that and getting to the point:
CH 1 <pg 8>
| Quote: |
Clustering: MQ supports clustering, allowing increased flexibility in workload
management and failover capability. |
CH 7 <pg 122> Under the Workload Management section
| Quote: |
To address high availability concerns by introducing an ability to fail over work
from one server to another. |
*This isn't referring to MSCS/HACMP failover.
CH 7<pg 134> A look at the image will give a better understanding
| Quote: |
If the queue manager MQV2 fails, the workload will automatically be diverted to
the instance of TARGET.Q on MQV3, because the cluster receiver channel with
the NETPRTY of 4 is now the highest. |
The work failover and performing failover tests is mentioned several more times throughout this book. I don't understand how people can say MQ clustering cannot be used for failover?? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri May 14, 2004 5:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It is "failover" in one sense. If you have a queue manager fail, then other queue managers will assume the work.
It is not failover in this sense. If a queue manager fails, while it has work assigned to it, that assigned work will not move to another queue manager.
That is, suppose QMGRC goes down. It currently has unproccessed messages on it's queues. Those messages are unavailable to be processed until QMGRC goes back up.
Suppose as well, that while it was failing, an application on QMGRA directed work towards QMGRC. These messages were put on the transmit queue and labeled to go to QMGRC.
These messages will also not get processed until QMGRC is back up.
Thirdly, suppose an application has opened a cluster queue with BIND_ON_OPEN, and been assigned QMGRC. Until that App closes and reopens the cluster queue, it will continue to send messages to QMGRC regardless of QMGRC's availability.
Because of all of these caveats, I personally believe it is better to tell people getting started with MQClustering that it is not a failover solution, even though it does provide SOME failover functions.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri May 14, 2004 7:05 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I'll have to agree with Jeff. Our experience has been that people will decide to use clustering for failover. Something goes wrong and they start asking why their 'orphaned' messages aren't automatically moved over to one of the other machines in the cluster. At this point, we get into a discussion of high-availability and hardware types of options. |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri May 14, 2004 10:07 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I agree with Jeff as well. I've used queue manager clustering in a production environment before, and it became a huge pain when a queue manager went down, because any messages bound for that queue manager (and already on a transmission queue) would not get rerouted to another server (whereas messages not yet on the transmission queue would get rerouted).
To overcome this problem, we had to create a "distributor" queue manager, where ALL messages would get sent, and then it would figure out which queue managers to send it to in the cluster. This overcame the failover issue but it created another one - because now we had a single point of failure in the cluster!
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| 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
|
|
|
|
