Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm looking into utilizing MSMQ in our enterprise applications. The one area I haven't been able to find information on is with disaster-recovery.

Scenario

A fire has broken out in the server room. All the equipment has been destroyed and we need to run the operations out of a backup site several miles away.

With SQL server, we have replication enabled which provides a stand-by copy of the operation database at the backup site. In the event of disaster, we can switch over to the stand-by site and continue with an up-to-date database.

With MSMQ, I would like to know how I can achieve the same style of replication, so that if the server a queue is hosted on suddenly ceases to exist, we should be able to switch to a stand-by queue which contains the same unprocessed messages.

Can this be achieved? If MSMQ can't easily manage this, is it possible to do something at the storage level?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

There's nothing in MSMQ which will do this automatically. You've got a couple of options.

  1. Build a geographically distributed cluster using storage replication on your SAN to replicate between the two sites. Setup MSMQ as a clustered resource (which is supported).
  2. Use something like double take to replicate the MSMQ folder to a server at the second site. Make sure that MSMQ on the second server is configured to look at the correct folder, and that the MSMQ service on the backup server is disabled.

Make sure that the queue is setup to allow the messages to be read into the queue and not purged after restart of the MSMQ service.

share|improve this answer
    
If we're using storage replication and clustered MSMQ, what would the steps be to fail over in the event of a disaster? –  Tragedian Aug 6 '11 at 9:05
    
At that point the cluster will failover automatically and the client will just need to wait for the DNS change to replicate before they resolve the correct IP address (usually 10-15 minutes depending on AD replication settings). You just need to be sure your cluster is built correctly to survive a site failure. –  mrdenny Aug 6 '11 at 22:22
    
"Make sure that the queue is setup to allow the messages to be read into the queue and not purged after restart of the MSMQ service." You mean don't use express messages? –  John Breakwell Aug 7 '11 at 10:20
    
That sounds correct. I don't remember all the MSMQ terminology. –  mrdenny Aug 13 '11 at 1:25
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.