Yesterday Synology released the beta for DSM (DiskStation Manager) 4.1. You can see the announcement with a nice overview of features here. But, as usual, some of the best new stuff in a DSM beta doesn’t make the big announcements page but is instead hidden in the change log. For example:
For those that may not know…VAAI is vStorage APIs for Array Integration. That’s a fancy term that means that they are APIs that let you offload many common tasks to the array. In this way the vSphere host is out of the loop which takes load off the host and speeds up the process. For example, the VAAI Full Copy function lets the storage array perform a clone of a VM by itself without the data going to/from the vSphere host. The vSphere host just tells the array what it wants done and to let it know when it is finished. Much faster. Far less data passing across the storage fabric.
As soon as I saw this release I grabbed the beta. Right now I’m working on an initial review of a DS3611xs unit that Synology sent me. That took a backseat as I loaded up the new beta and started some performance testing.
To start the testing I created a new iSCSI LUN. You’ll notice a new drop down box during creation. And yes, this works with both File LUNs (binary blob on filesystem) as well as block LUNs. One thing that I noticed was that this decision has to be made during LUN creation. If you create a LUN with VAAI disabled you cannot go back and enable it. That goes for LUNs you already have created before upgrading to DSM 4.1, too. That kind of sucks.
Once you create the LUN you connect to it from vCenter/vSphere just like any other iSCSI LUN. You’ll now notice that hardware acceleration is supported.
Output from my test host:
~ # esxcli storage core device vaai status get naa.600140501f7c5fdd0ad1d39f1daf68d5 VAAI Plugin Name: ATS Status: supported Clone Status: supported Zero Status: supported Delete Status: supported naa.6001405729ac07addb01d3c73db4bbd1 VAAI Plugin Name: ATS Status: supported Clone Status: unsupported Zero Status: supported Delete Status: unsupported naa.60014057e339553d95ffd3825d9205d3 VAAI Plugin Name: ATS Status: supported Clone Status: supported Zero Status: supported Delete Status: supported naa.60014052ba18972d25e1d3897d8740da VAAI Plugin Name: ATS Status: supported Clone Status: unsupported Zero Status: supported Delete Status: unsupported ~ #
Even those LUNs with VAAI set to disabled have Zero Status and ATS (Atomic Test and Set) enabled. That’s why it shows Hardware Acceleration enabled for all LUNs. Two of my LUNs show full support (VAAI1 & VAAI2 data stores), two support just Zero Status and ATS (NoVAAI1 & NoVAAI2 data stores)
First test, creating an Eager Zeroed Thick 100GB VMDK on the data stores. Connectivity between the vSphere host and the array is 1Gb Ethernet with jumbo frames enabled. Data will be landing on four SSD disks in a RAID0 volume (VAAI2 & NoVAAI2)
Time to complete the VMDK creation:
Network usage comparison:
As you can see there is a huge difference in time and network bandwidth. Basically, all 100GB of those zeroes has to be sent across the wire without VAAI. A faster interconnect (10Gb) would reduce the time, but not the amount of data transferred. With VAAI enabled the network impact is just a small blip. The array does the rest of the work.
This time I cloned a 20GB VM. Time for completion:
Again, just a small blip during the VAAI operation (ignore that long stretch after) while the non-VAAI operation took far longer and transferred a lot more data.
There are a couple of caveats with the VAAI support in DSM 4.1, at least in the beta. First, as I mentioned earlier, you can’t go back and enable it on an existing LUN. It’s a creation time option. I am waiting on confirmation from Synology on if that will change in the final DSM 4.1 release.
The second caveat…and a big one to me…is that VAAI is only enabled on the xs series NAS units. Those of us that use the smaller units in our lab are out of luck. To be honest I’m unhappy with this. I’d really like to see it working on the 5 and 8-bay units, even if it’s unsupported. Synology confirmed this limitation with me and the reasoning is performance mandates from VMware. During the tests I monitored CPU use on the DS3611xs and they may be correct.
As you can see VAAI operations use more CPU but at a shorter duration than non-VAAI operations. There are times that CPU use during VAAI operations are around 25% of CPU on the DS3611xs….that’s a dual core i3-2100 3.1GHz CPU. If you compare that CPU to the Atoms in the 5 and 8-bay units you can see a problem. Standard benchmarks show the i3-2100 to be about 4 to 6 times faster than the dual-core Atoms. The Atom-based NAS units would be very CPU limited when doing VAAI operations, and in my testing I wasn’t running any other applications or services.
While you can’t really argue with the numbers I’d still like unsupported VAAI operation on the smaller NAS units. Many of us in our labs only use the NAS for the lab, no other applications so some CPU contention is fine.
By the way, the screenshot above is from the new Resource Monitor in DSM 4.1 Beta. It’s great. Splits out CPU usage, shows IOPS of the unit, and all sort of other nice additions.
If you’re familiar with VAAI a lot of the information above is repetitive, but the purpose was to show that the VAAI support in DSM 4.1 Beta is the real deal. As far as I can tell no other NAS vendor in this space offers VAAI capability. That’s a big deal. In fact, VAAI support is lacking in many small NAS arrays from the major players. For example, the VNXe from EMC supports VAAI on NFS (which the Synology does not) but no support for iSCSI. Good job Synology! It’s great to see innovation.