SMB Multichannel is when SMB 3.0 can automatically (no configuration required) use:
- Multiple channels over a single NIC (as well as multiple cores on a CPU, instead of just core 0)
- Multiple NICs between the “client” (an application server such as IIS 8.0, SQL Server, or Hyper-V) and the file server (including a Scale-Out File Server).
SMB Multichannel enables a client and server to make full use of available bandwidth, e.g. you can fill a 10 GbE NIC with SMB traffic, while SMB Direct (RDMA) enables you to do this without the CPU being a bottleneck – by offloading the traffic from Windows.
Jose Barreto (Microsoft) has been writing a series of blog posts on using SMB 3.0 file shares. The latest post has a very important note in there:
… when using a clustered file server, you must configure a separate subnet for every NIC for SMB Multichannel to use the multiple paths simultaneously. This is because Failover Clustering will only use one IP address per subnet, even if you have multiple NICs on that subnet. This is true for both classic file server clusters and the new Scale-Out file server clusters.
That means that your client access networks on the Scale-Out File Server cluster nodes (and the corresponding “clients”) must be on different subnets, or SMB Multichannel will not make use of them. Remember: the SOFS role uses the IP addresses of the cluster nodes.
Make sure to check Jose’s latest post and his blog to learn more.
But I am assuming that we are still okay when using two NICs in one LACP active team. In our case we are using 2 x 10GB ports (Dell R720 / Intel X520) with the ports configure in a single LACP active team.
We are using a two node ScaleOut File Server (Two Dell R720, FCoE toward our NetApp 3240) and our Hyper-V are connecting also via a 2 x 10GB LACP link to access the VMs over SMB 3.0