Building an MSMQ Cluster
Why?
Why bother clustering MSMQ at all? Fault Tolerance. As you probably know, Microsoft Message Queuing (MSMQ) is a queuing system which is typically used as middle-ware between applications. MSMQ can store almost any type of data within MSMQ messages, and route them to another MSMQ queue manager where they can be retrieved by the receiving application. MSMQ already provides an extra layer of reliability in the case where something on the back-end may not be available, the front-end can continue to receive requests and store them as MSMQ messages. So what happens if the computer running MSMQ goes down, and the entire machine becomes unavailable? That's where a cluster helps us, as it adds provides fault-tolerance for those types of scenarios. Node #1 fails, and Node #2 automatically takes it place. An extremely simple and relatively inexpensive (given today's hardware costs) solution.
How to Cluster MSMQ?
All you need to cluster MSMQ in addition to the hardware and basic cluster setup, is a network name resource, and a disk-resource. Step-by-step instructions can be found in the white-paper titled Deploying MSMQ 3.0 in a Server Cluster.
How Many Instances? How does my Application Distinguish Between Local and Clustered MSMQ?
After you've successfully clustered MSMQ, it's important to understand the difference between local and clustered MSMQ. By default the local instance of the Message Queuing Service is set to Manual after MSMQ has been clustered, but it's still there, and can easily be started at any time. If you try running an MSMQ Application from the local command prompt, it's either going to use the local MSMQ Service, or if that service isn't started, it's probably going to generate an error.
For most people in a typical two-node cluster, there are three instances of MSMQ. Two local instances (one on each node) and the clustered instance which runs on the Active Node. The clustered instance an be failed over between nodes from Active to Passive and vice-versa. There aren't always three instances though, a better way of stating that you can have (# of cluster nodes) + (# of clustered instances of MSMQ) nodes.
So, if there are so many available instances of MSMQ, how do you get your application to use a particular instance? The answer depends on the the computer name that the application sees as its native computer name. If you launch a regular command prompt and type in " set COMPUTERNAME" it should display the current computer name. If this is the name of the local node, then the application will try to use the local instance of MSMQ. In order to get something to run within the context of the cluster, it needs to be using the same Network Name resource as clustered MSMQ. This can be accomplished in one of two ways:
-Cluster your application in cluster administrator, ensuring it has a dependency on the same Network Name Resource being used by clustered MSMQ. Then select the "Use Network Name as Computer Name" option
-Create a clustered command prompt. Basically create a clustered resource for cmd.exe, and ensure that you follow the rules above and create a dependency on the same Network Name Resource being used by MSMQ, and ensure that the "Use Network Name as Computer Name" option is selected. When you bring the resource online, you should see the command prompt. From this clustered command prompt, try the same "set COMPUTERNAME" test I mentioned above. This time you should see the virtual cluster name being displayed instead of the local node name. If you run your application from this clustered command prompt, it should see clustered MSMQ as it's native instance. You can also run Computer Management (compmgmt.msc) from this prompt to administer clustered MSMQ. Be aware that the prompt will not be displayed if you aren't either physically at the node, or if you're not logged in using the /console switch through mstsc.
Administering Clustered MSMQ
In order to properly administer clustered MSMQ, it's recommended to either run Computer Management from a clustered command prompt (see above), or otherwise you can use the MMCV utility. MMVC will allow you to launch Computer Management using a particular computer name, so you can easily specify the name of your virtual clustered server. The syntax to use is "mmcv.exe -s <myVirtualServerName>", it's an extremely useful tool, and I'd strongly suggest including a copy of it on all of your MSMQ cluster nodes. You can find out more about MMCV and find a link with a download in the following article: How to use the Mmcv.exe utility to manage clustered Message Queuing resources
Helpful Tips
Most clusters have multiple IPs, use the BindInterfaceIP registry key with clustered MSMQ to ensure that MSMQ binds to the correct IP: A cluster node with two network cards does not receive messages
Ensure that the local instances of MSMQ are set to run using the Local System account, even if they're stopped and set to manual. Having them set to use a particular user in an environment running clustered MSMQ will most likely cause issues.
If you're going to be using Public Queues, or will have clustered MSMQ installed with the Active Directory Integration option, then ensure that Kerberos is enabled on your Network Name Resource in Cluster Administrator. This will create an object for the virtual machine in Active Directory which will hold MSMQ's public information.
Keep in mind that clustered MSMQ inherits the installation settings from MSMQ on the nodes, so only select the features that you need in order to minimize overhead.
Failover over the cluster is equivalent to restarting the MSMQ service. In short, express messages will be lost, so if you need to preserve your data, then ensure that the message are either set to "recoverable" or use transactional queues.
I hope that you found this brief explanation of clustering MSMQ to be useful, and please don't hesitate to post any comments, questions, or suggestions.
Comments
Anonymous
August 22, 2007
Is that tumbleweed blowing past? ;-)Anonymous
February 07, 2008
This is very informative and good start for the begginers.Anonymous
February 18, 2008
This has explained a lot, but I have a question. We would like to set up a private queue, one a cluster, we would like a multicast queue. We will then have applications that will connected to queues on the same multicast address. We have been told that we can only have one queue on a cluster, is this true? thanks richieAnonymous
May 19, 2008
RichieNSS, What exactly were you told about "one queue on a cluster"? A multicast queue is listening on a IP-address/port-number combination. I think what you are after is: Running X applications, each with a dedicated queue. Having X queues, each with the same IP-address/port-number combination. When a message is multicast, each queue and therefore each application gets a copy. Is that right? That will work fine. Cheers John Breakwell (MSFT)Anonymous
November 09, 2008
"When you bring the resource online, you should see the command prompt." Does this mean an icon appears on the desktop? I've tried the above but nothing happens.Anonymous
October 07, 2009
the url don't work for the deployment doc not even from other ms web site can you check this and let us know daniel.gagnon@hp.comAnonymous
December 16, 2010
Deploying Message Queuing (MSMQ) 3.0 in a Server Cluster www.microsoft.com/.../confirmation.aspxAnonymous
October 05, 2011
The comment has been removedAnonymous
August 20, 2012
Why do we need to run the local message queuing with " local Account" why nor a service account. If yes arise, what type of issues arise. Ashwin Thakur