It is possible to read the documentation for clustering and think that “Active-Passive” means running MSMQ on just one node and “Active-Active” is spreading MSMQ across both nodes, giving you fault tolerance AND load-balancing. Unfortunately this isn’t the case.
You can’t have an Active/Active MSMQ implementation using a common queue storage. You can, though, have multiple instances of an Active/Passive MSMQ implementation, each with their own queue storage.
To demonstrate how this work in practice:
- Create a 4-node cluster with the nodes are named NodeA through NodeD.
- Share four disks, labelled M: through P: for mesage storage.
- In Cluster Manager we will create 4 resource groups, each containing an MSMQ resource (MSMQResourceA through MSMQResourceD) associated with a unique network name (MSMQServerA through MSMQServerD) and IP address (10.0.0.1 through 10.0.0.4).
- For load-balancing the resources, we will assign each group to a particular node. This doesn’t mean that the resources cannot be moved to another node in case of failure – it just determines the default host for them.
So this would give us:
- Machine NodeA owns MSMQResourceA + disk M: and messages can be sent to MSMQServerA\queuename or 10.0.0.1\queuename
- Machine NodeB owns MSMQResourceB + disk N: and messages can be sent to MSMQServerB\queuename or 10.0.0.2\queuename
- Machine NodeC owns MSMQResourceC + disk O: and messages can be sent to MSMQServerC\queuename or 10.0.0.3\queuename
- Machine NodeD owns MSMQResourceD + disk P: and messages can be sent to MSMQServerD\queuename or 10.0.0.4\queuename
Each node can function as an MSMQ server processing messages. The downside is that no single network name can be used to reach all the MSMQ services unless you put an Network Load Balancer (NLB) in front and then you have the usual MSMQ/NLB limitations.
This arrangement does provide a lot of processing power and resilience but the system design is going to be more complicated.