The following article discusses how Microsoft Message Queuing can function over Network Load Balancing (NLB). This article also discusses possible incorrect configurations of Message Queuing.
Message Queuing is supported in an NLB environment for both sending and receiving messages in the following configurations:
- Non-transactional messaging by using Direct=TCP
- Non-transactional messaging by using Direct=OS with validation disabled
- Non-transactional messaging by using Direct=HTTP
- Transactional messaging by using a specific configuration that uses store and forward servers and a single backend server
Only private queues are supported destinations in any one of these configurations. Because the virtual network name will not have a corresponding Active Directory directory service object, the properties of the destination queue cannot be queried. You may be able to send messages to public queues as long as the public queues are accessed by using a direct format name instead of by using the standard path.
Non-transactional messaging by using Direct=TCP
This configuration functions without any particular configuration changes.
Non-transactional messaging by using Direct=OS
This configuration only works when validation is disabled. To disable validation, you must add the following registry key in Message Queuing 2.0 together with Microsoft Windows 2000 and in Message Queuing 3.0 together with Microsoft Windows XP or Microsoft Windows Server 2003.Warning
Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.Follow these steps, and then quit Registry Editor:
- Click Start, click Run, type regedit, and then click OK.
- Locate and then click the following key in the registry:
- On the Edit menu, point to New, and then click DWORD Value.
- Type IgnoreOSNameValidation, and then press ENTER.
- On the Edit menu, click Modify.
- Type 1, and then click OK.
By default, Message Queuing verifies the message that it receives to determine whether the message is intended for the local computer. If the message is not intended for the local computer, the message is rejected.
When a message is sent to a server that is behind a network load balancer, the message is sent by using the name of the load balancer or by using the network name that is assigned to the virtual IP in the network load balancer. Then, the network load balancer routes the message to a Message Queuing receiver. However, the local Queue Manager on the Message Queuing receiver identifies that the computer name and the destination name in the message do not match, and the Queue Manager discards the message. After you set this registry value, Message Queuing no longer validates the destination computer name and will accept the message.
Non-transactional messaging by using Direct=HTTP
This configuration is supported without any particular configuration changes.
Transactional messaging by using a specific configuration that uses store and forward servers and a single back end server
In this configuration, transactional messaging only supports HTTP messaging when nodes that receive messages map the receiving queue to a single back end server. The HTTP transactional messages are not supported when the destination queues are on the individual nodes.
For more information about this configuration, see the "Microsoft Message Queuing (MSMQ) HTTP Deployment Scenarios for Windows Server 2003 and Windows XP Professional" white paper.
A configuration for transactional messaging where the destination queues reside on each member node behind a load balancer does not support sending or receiving messages for the following reasons:
- Duplicate messages
- Unacknowledged messages on senders
- Incomplete transactions
Transactional messages and acknowledgements
When a transactional message is received by a computer, the message is written to storage, the message is logged, and an order acknowledgement is sent back to the sender. The order acknowledgement is sent back to the IP address that the original message came from by using direct=TCP. Then, the message is received by the sender, and the message is removed from the outgoing queue.
When an acknowledgement is not received by the sending server within a specified time, the original message is re-sent. When the message arrives at the destination, the destination server examines the log and finds that the server has already received that message. Therefore, the destination server rejects the message and sends back another acknowledgement. The destination server will continue to send acknowledgements until the order acknowledgement is received by the sender. The logging prevents a duplicate message from being received, and the order acknowledgement confirms to the sender that the message was received.
Problems with network load balancers and transactional messages
When a message is sent through a load balancer, the destination computer sees the message as coming from the load balancer. Then, the destination computer sends the order acknowledgement through a new session. Therefore, the load balancer cannot use the same logic for maintaining state for a Web server or for a similar service.
The most common problem in this scenario is that several servers send messages across a load balancer, but all the order acknowledgements are sent to the incorrect server. This behavior causes unacknowledged messages to build up in the outgoing queue of sending computers. Additionally, when the order acknowledgement is not received by the sender, the sender will resend the message. The second try to send the message through the load balancer may send the message to a different computer. This computer will not have seen this message before, and the message will be processed as a new message. Remember that validation was disabled to allow for messages to travel across the NLB.
A message that was sent across a load balancer may be received and processed one time by all the servers that are behind the load balancer before an order acknowledgement is received. Additionally, transactions that span several messages cannot always be processed or arrive in order. Therefore, Message Queuing does not support sending transactional messages when you use an NLB.