NFS and Exchange - not a good combination

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