The virtualization community are asking Microsoft to change their support position for Exchange Server running in VMDKs on NFS datastores. Support is long overdue.  

The virtualized SCSI stack, including initiators and disks inside of a VM, are unaware of the underlying storage protocol that provides data connectivity between a hypervisor and storage device. Support is long overdue and the rationale for the lack of support is not recognized by the storage industry.

The following co-authors (from 7 different vendors & 2 solution integrators) are aiming to work together for the good of our customers and the community too raise awareness of this issue in the hopes that Microsoft will reconsider the support policy.

Josh Odgers (@josh_odgers)

Senior Solutions & Performance Engineer @ Nutanix

VMware Certified Design Expert #90 & vExpert

Vaughn Stewart (@vStewed)

Chief Evangelist @ Pure Storage

vExpert

Chad Sakac (@sakacc)

SVP, Global Systems Engineering @ EMC

vExpert

Matt Liebowitz (@mattliebowitz)

Solution Architect @ EMC

VCP & vExpert & author of Virtualizing Microsoft Business Critical Applications on VMware vSphere

Michael Webster (@vcdxnz001)

Senior Solutions & Performance Engineer @ Nutanix

VMware Certified Design Expert #66 & vExpert

Andrew Mitchell (@amitchell01)

Consulting Architect @ VMware

VMware Certified Design Expert #30

Rob Waite (@rob_waite_oz)

Solution Architect @ Tintri

VCP & vExpert

Nick Howell (@that1guynick)

vTME @ Netapp

vExpert

Chris Wahl (@ChrisWahl)

Solution Architect @ AHEAD

VMware Certified Design Expert #104

Gabriel Chapman (@bacon_is_king)

Solution Architect @ Simplivity

www.gabrielchapman.com

VCP & vExpert

Mahmoud Magdy

Senior Technical Architect

vExpert, MVP and Symantec BExpert

The Details of Microsofts Position

At present, Microsoft supports Exchange deployments on NAS, specifically only on their hypervisor and their file based protocol, SMB 3.0. The intent of our efforts is to address the gap in supporting Exchange in VMware vSphere & KVM with datastores connect via NFS 3.0.

The support policy can be found here and is summarized below...

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.

Another statement of interest in the above link is as follows;

"Configuring iSCSI storage to use an iSCSI initiator inside an Exchange guest virtual machine is supported. However, there is reduced performance in this configuration if the network stack inside a virtual machine isn't full-featured (for example, not all virtual network stacks support jumbo frames)."

While the contributors to this post agree this is not an ideal configuration, it is not a performance issue when used with enterprise grade storage and with properly architected networking.

The support statements is odd as there is a large portion of the VMware market that is deployed over NFS. This configuration is supported and is the preferred means of data connectivity for many. A decade ago, one could run Exchange 5.5 over NAS (CIFS). This support was removed with Exchange 2000. It appears the concerns from the Exchange 5.5. The difference with a virtualized instance is the Exchange application is NOT accessing data via NAS. All VM data access is via virtualized SCSI.

This may be a valid (or legacy) support policy back in the days before virtualization became mainstream, and before the evolution of 10/40Gb Ethernet where performance may have been limited by 1GB connections (as opposed to the NFS protocol itself) or for deployments where NFS is presented directly into the Guest OS which we agree would not work.

The abstraction of virtual SCSI from the underlying infrastructure (FC, DAS, iSCSI or NFS) is shown in the below diagram courtesy of http://pubs.vmware.com

Over the years, the contributors of this community post have seen countless successful deployments of Exchange on vSphere, using both block (FC,FCoE,iSCSI) and file based storage (NFS/SMB) so why is only NFS not supported?

There are a number of blog posts related to Exchange and NFS storage, one such example is by Tony Redmond (@12Knocksinna), titled NFS and Exchange, Not a good combination.

To Tonys credit, he goes much further than most posts we have seen, which in most cases just say Its not supported and give no technical justification as to why.

Tony wrote

One small, but terribly important issue is Exchanges 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.

With a VMDK presented to Exchange, we are not aware of any reason why Exchange (or any other application) would not function exactly the same as if the VMDK was residing on a FC or iSCSI backed LUN, or if a LUN was presented to the guest OS via an In Guest iSCSI initiator.

This is due to vSphere abstracting the underlying storage from the VM. To the operating system running within the guest the virtual hard disk appears and acts just like a local physical SCSI disk, regardless of the underlying storage protocol.

In support of this, Microsoft has a program called Exchange Solution Reviewed Program or ESRP which Microsoft partners can use to validate Exchange solutions. This program requires specific tests including one of24 hours using Jetstress with predefined settings, to validate the subsystem not only system performance, but consistency of the database.

Here is a Jetstress report showing the ESRP test passing with the following VM configuration with Exchange running within a VMDK on an NFS datastore

1 x Windows 2008 VM

1 vCPU (2.6Ghz)

24Gb vRAM

4 x PVSCSI Adapters

8 x VDMKs (2 per PVSCSI)

8 Exchange Databases (one per VMDK)

2 DAG Copies

The 24 Hour test can be viewed here - 24 Hour Jetstress Test

The Databases checksum from the above 24 hour test can be viewed here - DB Checksum

Note: The above test was ran for the purpose of this post, to show the storage abstraction works for Exchange, not to demonstrate maximum performance for the underlying storage platform.

So if a vendor validates a VMDK on NFS implementation by successfully completing Microsofts official tests (via ESRP) is there any reason not to support it?

We believe Microsoft should provide some formal process to storage vendors to certify their solutions for Exchange, in the worst case, at least allowing vendors to submit hardware for validation using Microsofts internal certification/QA process where these tools cannot be shared publicly.

Please show your support for this issue by voting and leaving your constructive or encouraging feedback in the comments at the Microsoft Exchange Improvement Suggestions Forum below. This issue is already rated as the #1 issue so the more support the better!

http://exchange.ideascale.com/a/dtd/support-storing-exchange-data-on-file-shares-nfs-smb/571697-27207

So to Microsoft - and too all the Microsoft Exchange & Storage experts we ask;

1. Can you clarify by providing some form of documentation what the issue is with Exchange on NFS natively. The goal to ensure if there is an issue, its understood by the community

2. Can you clarify by providing some form of documentation what the issue is with Exchange storage in a VDMK on an NFS datastore (where the storage is abstracted by the hypervisor). The goal again is to ensure if there is an issue, its understood by the community and can possibly be addressed in future hypervisors.

3. If the support statement is simply outdated and needs updating, lets work together to make it happen for the good of all Microsofts customers, especially those who have NFS storage from one of the many vendors in the market.

Now for those customers experiencing this issue today, lets discuss the current workarounds available if you need to comply with the current support policy and the continued impact to Microsoft customers if the policy is not updated.

Option 1. Use in guest iSCSI initiators to present LUNs direct to the operating system

Issues

a) Increased complexity of managing two storage protocols (NFS + iSCSI), also some vendors license features like iSCSI at additional cost, so it makes it so expensive to purchase a license on the storage just to support Exchange.

b) Some storage solutions may not support NFS and iSCSI

c) Increased points of failure eg: iSCSI initiator

d) Potential for reduced storage capacity efficiency

e) No ability for the guest to take advantage of advanced storage features that are added to the vSphere storage stack.

Option 2. Present iSCSI LUNs to vSphere hypervisor

Issues

a) Increased complexity of managing two storage protocols (NFS + iSCSI) and additional cost as explained above.

b) Some storage solutions may not support NFS and iSCSI

c) Increased points of failure eg: iSCSI initiator

d) Potential for reduced storage capacity efficiency

Option 3. Run Exchange on physical hardware (not virtual)

Issues

a) Increased complexity of designing and managing another silo of compute/storage

b) Increased datacenter requirements which lead to increased OPEX (ie: Power/Cooling/Space)

c) Decreased ROI from physical hardware compared to virtualization

d) Decreased storage capacity efficiency

e) Increased CAPEX due to reduced flexibility in sizing physical hardware ie: Sizing for end state not current requirements

f) Delayed time to market / upgrades / expansion due to procurement of hardware

g) Increased hardware maintenance costs

h) Increased complexity for Disaster Recovery

It is clear based on the experience of the contributors of this article, that NFS has a large footprint in the market and for these customers using NFS, Microsoft should seek a mutual Win-Win situation for its large and small customers using NFS.

Microsoft should extend support for NFS backed storage deployments to facilitate and simplify Exchange deployments for customers using NFS storage, which without the updated support statement would likely be forced into using multi-protocol or standalone silo type deployment for Exchange, adding complexity and resulting in increased CAPEX/OPEX.

Let's hope Microsoft care about their customers as much as the authors of this document do!

• Edited by Josh Odgers Tuesday, February 11, 2014 2:42 AM
• Moved by Jason Johnston [MSFT]Microsoft employee Wednesday, August 12, 2015 3:22 PM Not a development question.

Great writeup!

One thing I would emphasize is even though its storage + converged infrastructure vendors leading the charge... this is an extremely frequent request from our customers, they really want Exchange + VMDK + NFS datastores to be supported by MSFT so they can virtualize Exchange in the same way they virtualize the rest of their environment.  

Many of them also just ignore this support statement since they know there is no technical reason for it.  

• Edited by Lukas Lundell Tuesday, February 11, 2014 5:45 AM

A great workaround for this outdated support policy is to stop using Exchange. There are plenty competitive products out there that do the same or a better job and are supported in this combination or even native NFS. 

• Edited by pdvanhelden Thursday, June 05, 2014 3:20 PM

Josh,

It's somewhat ironic to hear your comments on negativity when your original post amounts to a not-so-thinly veiled accusation of dirty dealings on Microsoft's part.  That said I have deleted my post and will refactor it to hopefully address your concerns.

I will repost for another reason also.

As you have apparently not comprehended my point about determinacy of state on data on the underlying physical media, I will attempt to explain this more clearly.

The section of text you reposted from the patent refers to the >>virtual<< queue ONLY.

Next you imply (by asking for my full name and employer) that my own motives are suspect.

I'm a former engineer who has been deep into these protocols since long before Microsoft shipped Windows (or Exchange), VMware existed, and even before NFS was first used in a NAS appliance. 

I'll let the quality of my technical analysis speak for my identity and ask (politely, for now) that you to stop trying to "out" me.  I believe that kind of behavior, in addition to being offensive in the implications it carries, can be sanctioned on TechNet.

I will repost tonight.  Looking forward to a constructive dialog.

• Edited by Eric_W Wednesday, August 12, 2015 1:24 PM typo

Thanks Josh,

Let me offer this.

http://virtualgeek.typepad.com/virtual_geek/2009/06/vmware-io-queues-micro-bursting-and-multipathing.html

Please review the above first, then let's continue.

Microsoft's statement on Exchange is (simply put) that they do not support any form of SCSI block-emulation sitting atop NFS, due to Exchange recovery mechanisms which rely on direct access to the underlying physical media.

This makes perfect sense to me because these emulation mechanisms cannot ensure determinacy of state of the data at the LBAs on the >>physical<< device following an abort command acknowledged by a >>virtual<< queue.

By determinancy, I mean that the state of the data on the physical disk following an aborted write >>must<< be known as either:

(a) the original physical data was unchanged (following a successfully acknowledged abort) or

(b) the data >>may<< have been changed (the abort was not acknowledged), or

(c) the data >>was<< changed (the abort command returned as 'failed')

Either way, Exchange definitely knows the state of data on the underlying physical media.

Now if you've had a careful look at the article above, and then re-read VMware's patent that you cited, I believe you will come to the conclusion that determinacy of state of the underlying physical media becomes impossible.

That is my own assessment and I suspect that is also Microsoft's assessment.

Finally, my understanding is that Exchange is very much different from SQL Server in this regard.

I can promise you that I am not a Microsoft employee, and that I have no horse in this race.  I'm just a former storage engineer who understands this problem deeply.  I support the position that >>any<< application that relies on SCSI protocols working exactly as they are defined in the T-10 specifications should take the same position Microsoft has here.

VMware's patent text clearly implies that they are fudging the SCSI abort command and makes no attempt to hide this or state otherwise.  I believe this is because it is effectively impossible to maintain the "pass-through chain" of multiple abort commands all the way down to the physical disk queues and then the acknowledgements of those aborts all the way back up the chain to the application, once there is an NFS file-system obfuscating the I_T_L_Q relationships between block-level initiators and the block-level targets.

This is not just VMware.  I believe that any attempt to present a block-level target that is based on underlying NFS storage necessarily 'breaks' the SCSI abort command chain in exactly the same way.

If any virtualization vendor using NFS as an underlying data store has come up with a solution, then I believe it is incumbent on that vendor to demonstrate exactly how their implementation matches up with the Letter of the Law (the T-10 specification).

Let me add this lastly -- consider that NFS has no equivalent command to match SCSI abort and then ask yourself 'why not'?  Once the chain of Initiator_Target_LUN_Queue nexes is broken by putting NFS in the middle, there's just no way to do it.