Microsoft Scale-Out File Services on Windows Server 2012 R2 Deployment Considerations

[bmacdonald16]

This guide addresses the creation and operation of a Server Message Block (SMB) file-sharing solution that uses the most current version of SMB with industry-standard x86 servers running the Windows Server® 2012 R2 operating system (OS). It incorporates best practices from both Nimble Storage and Microsoft to describe the most efficient use of a high-performance and highly available network-attached storage (NAS) infrastructure.

The guide provides instructions with technical tips. It outlines best practices for creating and using a Microsoft® Scale-Out File Services (SOFS) cluster with Nimble Storage® arrays and a Fibre Channel (FC) or iSCSI infrastructure. The guide assume that the audience has a basic understanding of FC and iSCSI concepts, Windows® environments, and Nimble technology.

Microsoft Scale-Out File Services on Windows Server 2012 R2 Deployment Considerations

[pbitpro96]

Great help! Thanks!

I'm currently seeing if SMB3 shares with a 3-node SOFS can effectively (and cost efficiently) replace my departmental and application NFS shares. 

RDMA question for you Brian:

In this scenario, does SMB Direct (with RDMA card) make a difference? Or is that outside (above) this stack? Is it the application servers and the "production network" the ones that need RDMA? Is it needed on the iSCSI side?

Thanks again!

[Chris_Lionetti]

Well, If you are going to be using SMB to act as a repository of files, there are a few questions.

1. What type and size of files do you expect.
   • reason I ask is that its not as well suited for home folders, or where you expect to have millions-to-billions of files. It is better suited to handle a smaller amount (thousands) of files that need block like performance. i.e. Hyper-V VHDs, or SQL DBs,

If you DO expect to put millions-to-billions of files on the shares, you would be better suited to use a Windows Failover Cluster implementing General File Services. A general file services cluster, will loose the ability to host Hyper-V and SQL DBs, but it gains other features such as being able to load the NFS server and host a share as both NFS and SMB at the same time, or some other features that SOFS lacks compatibility with such as DFSR/BranchCache/FSRM/etc.

1. RDMA is NOT needed on the iSCSI side. It is commonly used in three places;
   • (Cluster Network Only) It is used to speed up cluster interconnect traffic. I.e. on a SOFS cluster, the data comes into node3 due to SMB multi-channel, but node1 is hosting the share, node3 can move the write operation to node1 on its CSV network
   • (Production: Client to Server) It can be used by a client that is communicating with the cluster. note, this would be useful only for massive read or write operations, i.e. I am doing a Live Storage Migration and moving an entire VHD from share1 to share2 or a DB from place to place.
   • (Production: Client to Client) It can be used by the client to talk to eachother. This is common when your clients are running Hyper-V in a Hyper-V cluster, and they Live Migrate the vms around the cluster automatically to balance the load. Since the VM must copy its entire RAM contents from node to node to move the VM, this bulk copy is perfect for RDMA.

What you will note from each of these examples of where to use RDMA is that the data is commonly already in memory. RDMA can shave 0.25ms off a 8KB transaction, and this benefit would be very low value if you data were stored on physical spinning disk with a latency of 9ms, the value would be much greater when your data is stored on a SSD with a latency of 1ms, and it will absolutely supercharge when the data to be transferred is already in RAM such as a VM's RAM.

If you are not running Hyper-V or SQL, its more likely that you wont need RDMA on the production networks.

If you are running General File Services and not SOFS file Services, you generally wont need it either.

I have a tendancy to write too much, I hope this helps you, and let me know if I didn't hit the question such that the answer makes sense.