Review: ReadyNAS 1100 NAS appliance
As an alternative to hanging USB drives off some of our production servers we decided to purchase 2 ReadyNAS 1100 NAS appliances. Our primary goal for these where to use them for low access archival storage of large amounts of data. We purchased 2 of these to act as a primary and secondary with the secondary doing a nightly NFS based backup from the primary (More on this later). We bought the 1TB (4x250GB) version and replaced the drives in each appliance with Seagate 1.5TB drives. This swap was pain free and the rebuild time of the array was ~6 hours each. Total cost per appliance including new drives was ~$2,000.
Setup and configure:
Install was very simple. We decided on using the default RAID-X array configuration. We tested using the RAID5 (Which uses Linux's MD based software RAID) but found that RAID-X provides better performance for small files (Our use case). Total usable space was a little over 4TB.
Configuration of the Network and system was straight forward and what you'd expect from a NAS aimed at the SOHO market. The GUI was simple to follow and laid out logically. Getting it on the network and sharing out files took literally a few minutes. Since we are mostly a Linux/Solaris shop we were only focused on NFS exports. With these we found the performance fairly limited unless the NFS export was set to be async, with Writes going from (sync) ~4MBs to (async) ~20MBs. Setting up the backups between primary and secondary was also done through the GUI. It provides several different ways of pushing/pulling backups from different sources using Rsync, NFS Mount, SMB/CIF Mounts, etc. We choose doing a NFS based pull from the secondary server of the data on the primary. We found this to be the best balance of performance and ease of maintenance. One issue we found was that when backing up volumes with large number of files (Ie 10's of millions) the backup log file will fill the 2GB flash root volume. We had to modify the default netgear backup script to relocate this to the RAID volume instead. Another issue is that its using cp and not something like rsync. This means that it will add new files but not remove deleted files on the destination. The solution to this is to make the script use rsync instead of cp, but we have not attempted this yet.
One of the selling points of these devices was the strong support for customization with adding SSH and APT support to the device fully supported by the vendor. Adding these to the device was just a matter of downloading the plugins and installing them through the GUI. Once they were installed we could then add things like development tools and other useful command line utilities such as systat, iozone and bacula-sd. Another benefit of gaining command line access was that we were able to find root causes of performance bottle necks in the different methods of accessing the device (Ie we found that the main bottle neck is CPU, and the best method was NFS over SMB and Rsync because of this).
Performance:
We ran an iozone test directly on the device:
Iozone: Performance Test of File I/O
Version $Revision: 3.300 $
Compiled for 32 bit mode.
Build: linux
Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
Al Slater, Scott Rhine, Mike Wisner, Ken Goss
Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
Randy Dunlap, Mark Montague, Dan Million,
Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy,
Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root.
Run began: Fri May 15 01:57:14 2009
OPS Mode. Output is in operations per second.
Record Size 1 KB
File size set to 1048576 KB
Excel chart generation enabled
Command line used: iozone -i 0 -i 1 -O -r 1k -s 1G -t 1 -R
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 1 process
Each process writes a 1048576 Kbyte file in 1 Kbyte records
Children see throughput for 1 initial writers = 9845.89 ops/sec
Parent sees throughput for 1 initial writers = 9734.81 ops/sec
Min throughput per process = 9845.89 ops/sec
Max throughput per process = 9845.89 ops/sec
Avg throughput per process = 9845.89 ops/sec
Min xfer = 1048576.00 ops
Children see throughput for 1 rewriters = 5629.51 ops/sec
Parent sees throughput for 1 rewriters = 5599.09 ops/sec
Min throughput per process = 5629.51 ops/sec
Max throughput per process = 5629.51 ops/sec
Avg throughput per process = 5629.51 ops/sec
Min xfer = 1048576.00 ops
Children see throughput for 1 readers = 24118.04 ops/sec
Parent sees throughput for 1 readers = 24116.90 ops/sec
Min throughput per process = 24118.04 ops/sec
Max throughput per process = 24118.04 ops/sec
Avg throughput per process = 24118.04 ops/sec
Min xfer = 1048576.00 ops
Children see throughput for 1 re-readers = 26780.61 ops/sec
Parent sees throughput for 1 re-readers = 26778.54 ops/sec
Min throughput per process = 26780.61 ops/sec
Max throughput per process = 26780.61 ops/sec
Avg throughput per process = 26780.61 ops/sec
Min xfer = 1048576.00 ops
Conclusion:
These devices for the money provide a very flexible platform for putting a fair amount of data onto the network. Their main short coming is the limited CPU resources which cause a bottle neck on the performance you can expect from them.