MSMQ and non-local storage

A number of companies make use of storage devices that are not physically attached to the machine using them, such as storage area networks (SAN) and network-attached storage (NAS), as well as more exotic geographically dispersed solutions.

The question is whether MSMQ can be used on these and the official answer is no.

This doesn't necessarily mean it won't work, though. As long as these SAN/NAS/wherever solutions support the standard file I/O API that MSMQ uses (WriteFile, flushViewOfFile, etc) then MSMQ is happy. Otherwise MSMQ will see any anomaly, such as a file I/O failure, and will exit. There is no code in MSMQ to deal with disk failure. It is the customer's responsibility to provide reliable fault tolerant hardware.

• Anonymous
  March 01, 2009
  How does that fit in with the support of MSMQ in a clustered environment where SAN storage is the normal way of providing shared disk? Thanks for the blog by the way, really useful stuff.

• Anonymous
  March 01, 2009
  Hi Nathan, That's easy - if you have a MSMQ clustering problem that resists standard troubleshooting then you will be expected to reproduce it on a traditional MSCS system with local disks. Should it not reproduce in an environment that MSMQ was designed/tested on then you will be advised to contact the SAN provider for further support. If required, they can then engage Microsoft through support arrangements like TSANet. Cheers John Breakwell (MSFT)

• Anonymous
  March 01, 2009
  Thanks for that. Would be handy if the MS docs on the subject mentioned it, there are docs discussing MSCS on a SAN: http://www.microsoft.com/windowsserversystem/storage/clustering.mspx http://www.microsoft.com/windowsserver2003/techinfo/overview/san.mspx And a doc discussing clustering of MSMQ http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=349d6584-9510-46f5-904e-2c58fa16eb85 Which doesn't mention that MSMQ clustering can't use SAN storage even though it is  supported with MSCS. Is there an official statement on this as I'll have to update some documentation and review a proposal - going to be a bit more challenging if MS officially say it isn't supported. Cheers

• Anonymous
  March 02, 2009
  The comment has been removed

• Anonymous
  March 02, 2009
  A bit more digging on the subject: From MSDN "When flushing a memory-mapped file over a network, FlushViewOfFile guarantees that the data has been written from the local computer, but not that the data resides on the remote computer. The server can cache the data on the remote side. Therefore, FlushViewOfFile can return before the data has been physically written to disk. However, you can cause FlushViewOfFile to return only when the physical write is complete by specifying the FILE_FLAG_WRITE_THROUGH flag when you open the file with the CreateFile function." Does the storage vendor allow FILE_FLAG_WRITE_THROUGH to work as designed or is the data intercepted and cached somewhere instead for performance reasons? http://blogs.msdn.com/johnbreakwell/archive/2006/12/13/click-boom.aspx Cheers John Breakwell (MSFT)

• Anonymous
  March 02, 2009
  The comment has been removed