2

I've got a solution running on a single server right now that uses transactional private queues (msmq/wcf). Windows services consume and process messages on the queues, and the web application layer pushes messages to the queues.

We're moving to an ip load-balanced configuration (round-robin, two servers, single virtual address) and there's no need to maintain message ordering between each node. So, simply replicating the stack (web app, services, queues) will be fine under normal conditions. But I'd prefer a single virtual set of queues so that no messages would be lost or delayed for extended periods if any node goes down.

I'm not new to MSMQ, but haven't configured it for multiple servers like this before. Any suggestions that don't involve reconfiguring servers? I need to stick with the load-balanced configuration.

1 Answer 1

4

You can't load balance transactional queues very easily. You need to ensure the MSMQ host receives messages that contain the IP address of the sender and not the load balancer (if you are using one). If you are load balancing with DNS then probably not a problem although MSMQ is very sticky which defeats load balancing.

Oil and water - MSMQ transactional messages and load balancing:
http://blogs.msdn.com/b/johnbreakwell/archive/2008/11/18/oil-and-water-msmq-transactional-messages-and-load-balancing.aspx

5
  • That's sorta' what I figured(and feared). So, is the preferred configuration clustered failover servers using a SAN for reliable storage?
    – jtalarico
    Jan 21, 2012 at 21:11
  • A clustered failover server will work but doesn't scale as it's to provide reliability rather than performance. Jan 22, 2012 at 16:37
  • Understood - not to belabor the point, but are those the only options? Is that the tradeoff? You can choose maximum reliability or maximum performance, but not both? If there's some other configuration besides an active/passive failover, or a load-balanced farm, I'd love to know.
    – jtalarico
    Jan 23, 2012 at 4:19
  • MSMQ is designed around persistent connections to provide performance. The overhead of re-establishing network connection is regarded as something to avoid. Part of the problem is that the fundamental architecture of MSMQ has been pretty much unchanged since it's birth with the Windows NT4 Option Pack. Nothing has really been done to bring it into the 21st century where load balancing is the norm. Jan 23, 2012 at 18:59
  • There are a few approaches to try and force load-balancing by terminating connections quickly, using Round Robin DNS, etc. but performance would suffer. Jan 23, 2012 at 19:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .