Support for Exchange Databases running within VMDKs on NFS datastores

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!


February 11th, 2014 2:42am

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.  


Free Windows Admin Tool Kit Click here and download it now
February 11th, 2014 5:40am

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
June 5th, 2014 3:19pm

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 18 hours 4 minutes ago typo
Free Windows Admin Tool Kit Click here and download it now
August 12th, 2015 9:26am

Hey guys, great discussion, but this isn't really an Exchange Development issue. I'm going to move this post over to the Exchange discussion forum on TechNet.
August 12th, 2015 11:24am

Hey guys, great discussion, but this isn't really an Exchange Development issue. I'm going to move this post over to the Exchange discussion forum on TechNet.

Free Windows Admin Tool Kit Click here and download it now
August 12th, 2015 12:33pm

Can you name a few?
August 12th, 2015 12:50pm

Hi Eric,

I believe its common courtesy to introduce ones self when having a discussion, If you find "I would appreciate if you would share your full name and employer" offensive I can't help with that but I can advise nothing is implied by my question.

I simply would like to know who I am conversing with especially since your reply may well be the first detailed discussion from a person opposing VMDK + NFS support with some knowledge on the topic. (That is a compliment BTW).

I would also encourage you to re-submit your original post to ensure this thread has context.

Thanks

Free Windows Admin Tool Kit Click here and download it now
August 12th, 2015 7:16pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics