NFS and Exchange - not a good combination

NFS has been around for years and some people think that it should be used with Exchange. But it can't. Why? Because you'll probably end up with holes in your database if you use NFS. This might or might not be a problem in your eyes but I don't think it's a good idea. Block-level storage is really the only thing to use with Exchange.

You always know that you’re in the presence of a real expert because they are able to take a complex problem and reduce it to a simple easy-to-understand statement. And so it was when Jeff Mealiffe (Mr. Performance from the Microsoft Exchange product group) spoke about the “Virtualizing Exchange 2013” at Exchange Connections last week. Normally I run a mile when presentations about hardware start. Hardware is interesting, but software provides the magic to make the cold bare metal come alive.

In any case, there’s been quite a lot of commentary about using NFS-based storage with Exchange floating around the Interweb. Jeff reduced the situation to a simple statement that Exchange only supports block-level storage. For the record, the official story for Exchange 2013 is:

The storage used by the Exchange guest machine for storage of Exchange data (for example, mailbox databases and transport queues) can be virtual storage of a fixed size (for example, fixed virtual hard disks (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that's configured at the host level and dedicated to one guest machine. All storage used by an Exchange guest machine for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support the use of network attached storage (NAS) volumes, other than in the SMB 3.0 scenario outlined later in this topic. Also, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't supported.

Jeff’s statement is rather more concise. Block-level storage is required. End of story. No more discussion. It is what it is. Move on.

For whatever reason, the proposition to use NFS appears to be more popular once virtualization is considered, perhaps because it is reasonably common to make large pools of storage available from a SAN to virtual machines via NFS. Such an approach makes sense if the applications that you want to run on the virtual machines are happy to consume storage served up in this manner. Exchange is not.

Exchange has been very consistent about not using file-level storage protocols for as long as NFS storage has been available. And to be fair, storage vendors such as NetApp are very good at telling customers to use their products in block mode when deployed alongside Exchange.

The problem that you face with file-level storage is that ESE, the Extensible Storage database engine used by Exchange (since the year dot) for its mailbox and other databases (such as the transport queues) expect to use block-level storage. One small, but terribly important issue is Exchange’s requirement that it should be able to abort a transaction should bad things happen. Block-level storage allows this to happen but file-level storage supports aborts on a best-effort basis. Simply put, without the ability for an application to signal the storage subsystem that a transaction should be aborted, you run the risk of introducing corruptions into the databases through bad transactions.

Corruptions are bad. From Exchange 2010 SP1 onward, mailbox databases that have copies inside a Database Availability Group can patch single bad pages by detecting the problem and then fetching good copies of bad pages from other database copies. This is an effective mechanism to rid Exchange of the scourge of -1018 errors that used to force complete database restores to return databases to good health. However, the fact that Exchange supports single page patching is no good reason to let the storage subsystem have its wicked way with databases, corrupting pages ad nausem.

It’s entirely possible that you might be faced by some well-attired and glib-speaking salesperson who waxes lyrical about the wonders of NFS. Such is life. If you’re in this situation, ask the salesperson to read up on the topic before they make such a recommendation. This article gives a concise comparison between the two storage modes. If some more technical detail is necessary, you might point them here or here. And there’s always Devin Ganger’s “Exchange 2010 Storage Virtualization Gotchas” to provide tales of the unexpected of a storage nature.

Alternatively, reserve your seat for the Microsoft Exchange Conference (MEC) in Austin next April. I’m sure that Jeff Mealiffe will be speaking at MEC and that he’ll be happy to repeat his simple message that you should not use NFS with Exchange.

Follow Tony @12Knocksinna

Discuss this Blog Entry 3

on Mar 11, 2014

From my point of view, the statements in this article have no sense in a virtualized environment: What the Exchange Server VMs will interact with, will be a virtualized SAS or Scsi disk, not straight the NFS layer. So there will be no room for any data corruption issue, because ESE will see, in facts, a block storage device, not the NFS NAS directly, hence the abort commands and so on will clear without any problem.

Best regards, Emanuele.

on Mar 12, 2014

@Emanuele, You make the point that the NFS vendors have been making for quite a while. Microsoft obviously has an issue with this and is unwilling to budge for their own reasons as outlined in the article (I think the support issue is the most important). Remember, technology is often black and white but business is composed of many shades of grey. I feel that this issue is full of shades.

on Nov 20, 2014

Came across a client that had a vendor install exchange 2013 on NFS. Needless to say it wasn't pretty and that is why I am left to clean up the mess. Corrupted db's and instability. Thanks for your article!

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×