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.

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

IMO Jeff Mealiffe's comments don't align with yours as he continues to spread the word (Slide 15 of the presentation below) that Write ordering, Forced Unit Access, Write Through and protection from Torn I/Os are required for Exchange and this is exactly the same as what the SQL team require AND allow to be certified (to their credit!)

Jeff's Presentation: http://video.ch9.ms/sessions/mec/2014/ARC305_Mealiffe.pptx

SQL Server I/O Reliability Program Review Requirements: http://download.microsoft.com/download/F/1/E/F1ECC20C-85EE-4D73-BABA-F87200E8DBC2/SQL_Server_IO_Reliability_Program_Review_Requirements.pdf

So Let's agree to disagree about VMDK on NFS and talk about VHDX files on SMB 3.0? What's your position here? (and i'm not interested that MS say they have tested it and its a supported config) 

Support statement for Exchange says:

"Also, in a virtualized environment, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't supported."

SMB 3.0 (NAS/File storage) is presented to Windows/Hyper-V which presents VHDX files as block-level storage to the guest.

So if the Exchange teams fears about abstraction are indeed true (which they are not) SMB 3.0 with VHDX (and VMDK on NFS) should not be supported. Interestingly only a competitors solution (vSphere w/ VMDKs) isn't supported and nor can any vendor do what you suggested and demonstrate to the Exchange team how there storage works, trust me, we've tried and they are not interested in even having the discussion. 

As I don't know who you are I can only assume you have no influence on this topic at MS, BUT If you do, I challenge you to ensure vendors are given a chance to "demonstrate exactly how their implementation matches up with the Letter of the Law" as you put it. This is all the storage/virtualization industry is asking for. Hell, the Exchange team could just give vendors the documentation of how satisfied themselves that SMB 3.0 and VHDX "matches up with the Letter of the Law" and the same tests (where applicable) could be EASILY ran on VMDK on NFS.

(Frankly IMO, the MS Exchange team are scared of being proven wrong AND they don't want to promote vSphere deployments so they will never do this, neither reason is related to the technical implementation of SCSI protocol emulation via VMDK on NFS though)

Me on the other hand, I would LOVE for somebody to prove that VMDK on NFS doesn't work as I have described as in theory if it didn't work properly, this would be a major challenge for all vSphere customers using NFS which I would want to help lead the resolution of.

So there's a challenge for you if choose to accept it. If you want to contact me privately I'm sure we could arrange a Windows server on iSCSI and another on NFS for you to prove your point, or even just prove you could tell which one is which.

Regarding your don't have a "Horse in the race" comment, neither do I. Nutanix (my employer) has iSCSI for Acropolis and vSphere and SMB 3.0 for Hyper-V all of which are fully MS supported so its not impacting our business, in fact, if anything its making us money as our Global Services team have to deploy solutions (like iSCSI in-guest) for customers when deploying Exchange which takes longer (albeit not much) than direct on VMDKs. If anything, the support statement being updated would help Nutanix competitors who in some cases don't have the multi-protocol support we do.