3

We plan to develop a highly available system based on Microsoft Message Queuing (MSMQ). Currently we are collecting high availability options for MSMQ. We plan to use Windows Server 2008R2 as the underlying operating system.

Which specific technologies are available to make the MSMQ service highly available?

We looked into Windows Failover Clustering and NLB but Clustering seems to have way too high failover times (more than 10 seconds) and NLB does not support transactional messaging.

Does anyone have experience with solutions like VM Ware Fault Tolerance or something similiar? Are you aware of any other solutions providing high availability for MSMQ while supporting low failover times (< 5 seconds) and transactional messaging?

Karl
  • 31
  • 1
  • 3
  • You can use transactional queues and NLB if you use the Remote Receive feature in MSMQ 4.0. No? –  Feb 22 '12 at 12:44
  • It is 2019 already. Is it may be possible that the situation has been changed around Microsoft MSMQ and it's high availability support? – SaWo Feb 22 '19 at 17:50

3 Answers3

3

You're definitely going to want to look into the Server 2008 Clustering feature. You can configure the message queuing service application to provide high availability and fault tolerance. The main prerequisite to setting this up is having a SAN in place.

http://msdn.microsoft.com/en-us/library/dd897482(v=bts.10).aspx

Also if for a great overview on how to set this up visit the Microsoft Virtual Lab: http://go.microsoft.com/?linkid=7091154

RomeNYRR
  • 1,441
  • 11
  • 16
  • The problem is that we need to ensure that no message gets lost during failover and that failover times from main to standby are less than 3 seconds. Is this possible with Server 2008 Failover Clustering? – Karl Feb 13 '12 at 08:55
  • 3 seconds does not sound achievable. On failover, MSMQ needs to re-load (or at least re-map) all the persisted messages from physical storage into memory. The more messages you have, the longer the loading will take. MSMQ will be unavailable until all messages have been processed in this way. – John Breakwell Feb 13 '12 at 20:29
  • It sucks that MSMQ doesn't implement the "always-on" feature that's now in SQL Server. Seems like it would be very doable and would obviate the need for a SAN! – Jeff Jul 11 '13 at 20:11
0

If you need failover times below the typical MSCS ones (they tend to be quite slow), consider setting up NLB with MSMQ over HTTP.

This will take care of the availability and can scale to dozens of nodes.

adaptr
  • 16,576
  • 23
  • 34
  • With NLB we have the problem that it does not support transactional messages due to the stickyness of the MSMQ protocol, so this doesn't seem to be an option either. – Karl Feb 13 '12 at 10:23
  • NLB is a problem for transactional messages because it often rewrites the sender's IP address with that if the NLB device. This prevents transactional acknowledgement messages returning to the senders, which is the main problem. – John Breakwell Feb 13 '12 at 20:32
  • The stickiness of MSMQ is only a performance issue. If you set the NLB to reset connections after a short period of time and configure the MSMQ sender to recover quickly, you can get round that to some extent. – John Breakwell Feb 13 '12 at 20:34
  • Yes, you're right, the main issue is the tx acknowledgement - since we need transactions an NLB is not an option. – Karl Feb 14 '12 at 06:38
0

MSMQ is not really a good solution if you need HA I'm afraid. What about other products? I would suggest checking RabbitMQ, it is supported quite well and migration is not very painful.

siupakabras
  • 70
  • 1