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.