So the point is: How much performance will be lost if you place the cool new SoFS between your Storage System and your Hyper-V or SQL Server (The only two Roles that support SoFS and SMB3.02). You understand. It is an additional component with delays in the storage path, an active system that generates physical delays. But how lage is the impact ?
For this we created a 3 server and 1 storage system test scenario (see picture below).
2 Hyper-V Nodes. One connected direct via 2 x 1 GBit/s to and DELL EQL System, the other Hyper-V was connected via 1 x 10 GB RDMA to the SoFS.This SoFS was even connected with 2 x 1GBit/s to the EQL System.
After this we created one VM on each Hyper-V Host. One was on the iSCSI Target and the other was on the SMB share created on the SoFS.
To have just the delay in the system we did not enable the CSV Cache on the SoFS. But what is absolute recommended was the Mellanox RDMA 10 GBit/s Network connection to the SoFS.
We started the test with IOMeter. A couple of test created these average times:
Transfer iSCSI via 2x1GB (10min)
(3 Worker 8 KB 60% random /65 % read)
Total I/O per Second: 4515
Total MB per Second : 35,30
Avg Response Time 9,65 ms
Transfer SMB 3 via 10GB RDMA (10min)
(3 Worker 8 KB 60% random /65 % read)
Total I/O per Second: 4425
Total MB per Second : 34,56
Avg Response Time 9,79 ms
Summary:
A SoFS creates an additional 0,1 ms delay to the response time of the whole system. Focus on the I/O = this will result in a very small I/O reduction (~90 I/O less than direct iSCSI).
This is a great result for the Microsoft SoFS Solution ! So if you need the SMB3.02 Features go and test the SoFS in your hopefully existing test environment!
