QNAP's TS-EC1279U-RP 12-bay Flagship Rackmount NAS Review
by Ganesh T S on April 29, 2013 4:30 PM EST- Posted in
- Enterprise
- Storage
- NAS
- QNAP
Encryption Support Evaluation
Consumers looking for encryption capabilities can opt to encrypt a iSCSI share with TrueCrypt or some in-built encryption mechanism in the host OS. However, if requirements dictate that the data must be shared across multiple users / computers, relying on encryption in the NAS is the best way to move forward. Most NAS vendors use the industry-standard 256-bit AES encryption algorithm. One approach is to encrypt only a particular shared folder while the other approach is to encrypt the full volume. Some NAS vendors have support for both approaches in their firmware, but QNAP only opts for the latter. Details of the QNAP's encryption key management mechanism and other caveats are available here.
On the hardware side, encryption support can be in the form of specialized hardware blocks in the SoC (common in ARM / PowerPC based NAS units). In x86-based systems, encryption support is dependent on whether the AES-NI instruction is available on the host CPU (not considering units based on the Intel Berryville platform). Current generation Atom CPUs (and even the Core i3 CPUs) don't support AES-NI. Fortunately, the Xeon E3-1225 used by QNAP in the TS-EC1279U-RP supports AES-NI. The impact of enabling encryption should be minimal.
We created an encrypted volume and reran our Intel NASPT / robocopy benchmarks on a CIFS share. The results are presented in the graph below (with the unencrypted volume numbers for comparison purposes).
As expected, encryption does carry a performance hit, but the impact is not very extensive. Depending on the type of workload, the penalty varies between 7.2% and 38%. We will be shortly carrying out a review of an Atom-based NAS where we will see that the penalty is much bigger.
Facebook
Twitter
RSS
23 Comments
View All Comments
Evadman - Wednesday, May 1, 2013 - link
Why is this so expensive for the performance, and why is single client performance so bad? Granted I deal with actual enterpise class SAN devices from EMC and the like, but even my ~4 year old personal server can beat this box. My crappy home server is a 20 rotational Hitachi 3 TB GST Deskstar 0S03230 disks in RAID 60, a E5200 CPU and an Adaptec 52445 running on MS Server 2008, not even close to being decent for enterprise level. Besides the disks, it cost under a grand and will max out a quadlinked 4gbps connection with one client, I don't need to add 3 or 4 as your graphs show that this box needs. There is no excuse for a 20 rotational disk device to beat this 12 disk SSD NAS/SAN before hitting the network limit. I should get a dozen SSD's and a 10 gig switch and see what my crappy box can do just for kicks. *makes notes to see if a spare switch can be found in the office*ganeshts - Wednesday, May 1, 2013 - link
The single client performance is for a single client with a 1 GbE link (so it can't max out a 4GbE link obviously). Client machines usually have only a single GbE port.Our multi-client graphs show performance with multiple clients and indicate limitation because of the network link bandwidth on the NAS side
Evadman - Thursday, May 2, 2013 - link
I must be misreading the graphs being presented then. This real world graph: http://images.anandtech.com/doci/6922/qnap_ts1279u... shows 5 clients, each at ~20MB/s for a total of 80 MB/s. Theoretical maximum is 125 MB/s, Adding the control data to the payload of the frame, and you should have about 97.5% data. So it looks like it taking more than 5 clients to get to the 1gbps limit. On the single client CIFS graph here: http://images.anandtech.com/graphs/graph6922/54437... only 2 of the performance benchmarks appear network limited at 123 MB/s. Office Productivity is low at 25-28 MB/s, as that is probably what a small business is going to be doing the most of. Is this a client/CIFS issue and not a NAS/SAN issue?