As a brief example, the dashboard display is a constantly moving visual representation of everything the 7210 is currently doing, providing instant feedback on load and throughput for any or all the protocols in use. The graph displays are not only clickable, but they can be arranged on customized worksheets to provide easy at-a-glance status reports. You can drill down (using the handy drill-shaped icon) into any graph to get more granular data and even pull up a list of files or users who are currently hogging the most bandwidth at that exact moment in time. This works at the file level in most protocols, so if the 7210 is being hammered, you can almost instantly determine not only who is responsible, but also what files are being accessed and from where.
The dashboard shows the various aspects of the 7210 itself, including network I/O, memory and CPU utilization, and independent protocol statistics. Next to each graph heading is an icon representing the health of that particular data point, as denoted by a meteorological symbol. If the icon is a sun, all is well. Clouds indicate that the protocol or system component is working hard, while raindrops indicate that activity is really ramping up. A lightning bolt signifies that the protocol or component is running near capacity. Because the entire interface is constantly updating, it's possible to leave pages open at all times and get a to-the-second report on the filer's health.
Beyond the frankly stunning statistical representation, administering the 7210 is relatively straightforward, using drag-and-drop concepts to build link aggregation configurations and the like. I developed a love/hate relationship with this approach. For example, it's not immediately obvious why a link is or is not available to be configured, and you have to drag a physical interface around to link it. When dealing with configurations that can result in the box being completely inaccessible if a mistake is made, I prefer to have a much clearer representation.
That said, you won't configure the network interface very often; more likely, you'll need to perform it only once. Aside from this quibble, the configuration and management of the server are as easy as one could expect. There's no need for any CLI involvement, and creating storage pools, shares, quotas, snapshots, and such is really quite simple.
The FishWorks GUI ran without issue in Firefox on Linux and Mac OS, as well as in Internet Explorer on Windows.
As a closed appliance, the 7210 doesn't offer much outside-the-box potential, but it delivers plenty of inside-the-box performance. When originally setting up the system, I configured a storage pool (a zpool) and an NFS share via the GUI, then tested it from my Linux workstation, using the single-gigabit NIC on that box. Much to my surprise, using dd to create a 10GB file on the NFSv3 share ran at nearly wire-rate, achieving a 115MBps sequential write time. I then tested with NFSv4 and got the same results. Using Iometer and a Windows Vista system, I was able to get about 90MBps sequential writes, which is quite good.
Sign up for MIS Asia eNewsletters.