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!
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