MQSeries.net :: View topic - Getting rid of Hardware Clustering for my WB-IMB domain

PeterPotkay · Posted: Wed Dec 08, 2004 1:19 pm Post subject:

I guess what it all boils down to is the answer to this question: When does a Persistent message actually get written to the log or the queue file?

The bigger question is: Do I need to hardware cluster (using MSCS) my WB-IMB brokers that are in an MQSeries cluster? These are at 5.3.0.8, on Windows 2000 Advanced servers with SP4, running with Microsoft Cluster Services (MSCS) which provides High Availability. @ servers, running Active/Active.

The fact that they are part of MSCS makes life tougher from an admin perspective then if they were just 2 single machines in an MQ cluster. We are going thru the WB-IMB upgrade process now, and have gone thru MQ upgrades in the past as well, and that blasted MSCS makes the whole process 10 times more complicated. So I wonder, exactly what does this hardware clustering buy me, and if I weighed all the pros and cons, would it make sense to just have the WB-IMB brokers in a regular MQ Cluster and get rid of MSCS?

Here's how I see it. When things are working fine, the MQ clustering distributes the messages evenly between the 2 QMs. If one of the servers went down, MQ Clustering would send all the messages to the server that is still up. The customer does not see any degradation in performance. The one server has more than enough capacity to handle all the work.

Compare it to the situation where MSCS steps in and moves the Broker/QM from the dead server to the live server. Now I have 2 brokers on the same server competing for the same CPUs, so performance is not better. I got to Brokers running at 50% capacity versus 1 Broker running at 100%.

So what does this MSCS buy me? The only thing I can think of is if there is a Persistent message on the QM that goes down, and it meets some criteria, it will be available when the QM comes up on the second node. Two things about this. First, how often is there a message on a queue in WB-IMB, when everything is flowing fine? Second, when a message flies thru a flow, is it in a state where it will survive a QM restart?

All bets are off for non persistent messages. Lets just focus on persistent messages.

So the first one is easy to answer: Almost never. The brokers are so fast, that the input queues just don't back up. There is no queuing. Yes, there are some messages in CATCH and FAIL queues, but those are not needed usually right away, so who cares if they are on a QM that won't be back up for a while. We do use the MQGET node to hold Reply to Info, but those messages are only persistent if the application message is persistent. And again, everything is so fast, the amount of time a message sits on a queue is nil.

The second one is what I need help with. WB-IMB flows sit on the input queue with an outstanding Get With Wait. Between the time the channel drops a Persistent message onto the input queue, and the time the flow does its MQPUT on the output side, to a S.C.T.Q with an MCA with an outstanding Get With Wait, when is the persistent message ever written to the log and/or queue file so that it would survive a QM restart? The reason I ask is because of this quote from the IBM Tech Conference: