Monthly Archives: July 2014

SMB 3 NAS is preferable to DAS in a Windows environment

Microsoft is investing heavily in the Network Attached Storage (NAS) protocol SMB 3 and is clearly laying out a road map that suggests NAS is the future as opposed to Direct Attached Storage (DAS). Consider:

  • SQL Server 2012 system d/b and user d/bs, as well as Hyper-V 2012 workloads can be placed on NAS provided the NAS is SMB 3!
  • Microsoft made significant speed improvements in the SMB 3 client and server to have NAS achieve 97% of the speed of DAS, and this is without hardware acceleration.
  • Microsoft invested in SMB 3 Multi Channel by aggregating the bandwidth using parallel TCP channels using multiple NICs at the SMB 3 protocol layer. Multi Channel is all about speed AND reliability where failed I/Os are seamlessly moved to a different TCP channel when one channel fails.
  • Continuing on the speed theme, Microsoft invested in RDMA support via SMB Direct, which requires not just SMB 3, but also SMB 3 Multi Channel. The maximum IOPS on a Windows system is achieved when using SMB 3 NAS with SMB Direct support, NOT with DAS!
  • Going back to the reliability theme, SMB 3 includes support for Persistent Handles, which combined with the Witness Protocol, ensure applications such as SQL, Exchange, and Hyper-V never see an I/O failure, and the I/O is seamlessly moved to a different node as needed. This only works with SMB 3 NAS, and does NOT work with DAS!
  • I have been asked numerous times “But Microsoft has invested in Storage Spaces and Tiering where data is moved between SSD and spinning media to optimize performance. Does that not indicate Microsoft advocates DAS?” And my answer has always been “Storage Spaces is even more valuable when used as the storage backing a Windows Server 2012/R2 NAS!” Using Storage Spaces does not mean one has to abandon NAS.
  • Microsoft supports deduplication of VDI VMs, but the only supported configuration is with the VDI VM files residing on an SMB 3 based Windows Server 2012 R2 based NAS! (and not with DAS!)
  • To provide examples of other Microsoft efforts leveraging SMB3 , consider the simple “copy” or “xcopy” command to say copy a GBs large file. Microsoft changed the CopyFileEx API to leverage all SMB 3 features including SMB 3 credits, SMB 3 Multi Channel, and SMB Direct (RDMA) to ensure the file copy is as fast as possible.
  • The Microsoft Hyper-V team re-wrote live migration in Hyper-V 2012 R2 to leverage SMB 3. While migrating a VM, Hyper-V 2012 setup its own TCP channel to copy the VM RAM. Hyper-V 2012 R2 uses SMB 3, and thereby gets the speed/reliability improvements of SMB 3 while doing the same copy.

Why NAS hosting Hyper-V VDI VMs needs to support SMB 2 not just SMB 3

If you spend some time on storage startup websites, no matter whether they are providing Flash storage, converged storage/computing, or VM aware storage, you will find that all of them seem to find VDI as a low hanging fruit. They all have a dedicated description of how they can supply great VDI storage solution.

Hyper-V requires NAS to be SMB 3.0 capable to host Hyper-V VM files. This is reasonable, given that SMB 3.0 provides both the speed and reliability that SMB 2.X cannot.

 But while Microsoft Hyper-V 2012 imposes the requirement of the NAS being SMB 3.0 capable, customer requirements often impose an additional requirement of the NAS also being SMB 2.X capable. And some other requirements as well, as we shall shortly see.

 This is because many customers often use Hyper-V to run VDI VMs. If these VMs run Microsoft Windows 7, the VMs are only SMB 2 capable. Further, a typical use of VDI VMs is to redirect all logged in user home directories to a NAS share. This is where the Microsoft Excel, Word, and PowerPoint files generated by the VDI VM users are stored.

And the customer will always ask “I just bought a NAS to store my Hyper-V VMs. Why can the same NAS also offer a share for the user home directories?”. And that is where comes in the requirement that not only should the Hyper-V capable SMB 3.0 NAS not only offer SMB 2.X support, but also a richer support in terms of supporting oplocks and byte range locks and other such features used by Microsoft Office, but not by Hyper-V.

This is why a particular company, in which I have an interest has implemented both SMB 2 and SMB 3, and regularly tests that its protocol stack implements the full range of SMB 2 and SMB 3 features, especially so all SMB features regularly exercised by Microsoft Office.