One of the cheapest solutions by far has been the traditional NAS server built on RAID arrays based on parallel ATA rather than SCSI drives. Performance on such RAID systems is often good enough to satisfy the needs of a direct-connect storage subsystem, let alone the needs of a network-attached storage device.

First Intelligent Array (FIA) takes the notion of providing customers with a true "appliance" experience very seriously. The idea is to provide business users with little—as little as virtually no—IT proficiency with all the wherewithal to install and set up a POPnetserver. This goes all the way to supplying color-coded CAT 5e Ethernet cables including a cross-over cable for sites with no Ethernet hub. Accompanying the POPnetserver is a CD with POPassist, which is a software application designed to help systems administrators manage a POPnetserver. In addition there is FIAPOP Data Replicator, which provides a point-and-click mechanism for end users to utilize the POPnetserver as an online backup and restore appliance.

Following in lockstep with the construct of providing an IT appliance for the terminally clueless, the first thing that POPassist does is discover all of the POPnetservers on the network. Making this discovery process all the more tricky, FIA initially names each POPnetserver in the form POP4600XXXXX, where XXXXX is the unit's serial number. So if a designated systems administrator looks in Network Neighborhood or the LiSA LAN Browser any devices that begin with "POPnetserver" will probably be the appliance.

Having automated the discovery process, the first function a systems administrator will want to do is configure the underlying drives and folders that will be shared from server. Once POPassist identifies the NAS server, clicking on the POPmanage button will launch MS Internet Explorer to the server's IP address to start the process. Note that getting to the server and its web-based utility could easily be done manually with any browser. Nonetheless, this is where things get interesting.

Prior to taking that step, we were able to run—albeit not completely—POPassist on SuSE Linux Desktop with the help of CrossOver Office. The only glitch comes in actually finding the POPnetserver. That function would not work, which left us manually inputting the new address we discovered with LiSA.

Levity aside, there is a crucially important function that a system administrator will need POPassist in order to perform. This second function of POPassist is dubbed POPbackup. Using POPbackup the system administrator can backup or restore any combination of vital POPnetserver configuration data and/or user data stored on the POPnetserver to another storage device on the network. This we were able to do using CrossOver Office

Unfortunately, we were not able to run the end-user application FIAPOP Data Replicator from SuSE Linux Desktop. This is a very slick and easy-to-use application that makes end-user backup a reasonable proposition. Like its sibling POPassist, FIAPOP begins by discovering POPnetservers on the LAN and simplifies connection for end users. This is the pitfall for Linux users. Since FIAPOP is an end-user tool, it begins by attempting to get authorization on the requested POPnetserver for the current end user. This function fails with CrossOver Office, which immediately ends the process.

Once authorized on the POPnetserver, the end user can identify any folders for replication on the server. Once that is done, replication is simply a task of clicking on the Upload button. That's easy enough, but  FIA takes this one step further by allowing the end-user to designate folders to be monitored for changes. Once this is done, the next time the end user wants to backup important data, all that's required of the end user is to select the option to backup modified files. Only those files on the end-user's computer that have been changed following the last update will now be uploaded to the POPnetserver.

Managing the POPnetserver from the POPmanage web interface is equally simple, once you get there.

Accessing the appliance using any web browser on any system starts out with the presentation of a login form. Once that form is submitted and the administrator authorized on the server, up pops a Java applet on that central portion of the screen. That Java applet enables the actual management of the FreeBSD server and, like so many other such applets, has been debugged only on Windows systems—or, fortuitously for openBench Labs, a Linux system with CrossOver Office.

On any other system, the central management foreground screen disappears and the system administrator is confronted by just the blue FIA backdrop. It sort of breathes life into the old saying about Java: Write once, debug everywhere.

With the Java applet functioning, however, the administrator has a wealth of information awaiting at the fingertips. The POPnetserver status page graphically lays out the current operation status of the server. This  includes the frequency of ECC errors, temperature, network ports, fans, power supplies, and hard-disk usage.

If an error occurs on the server, such as a memory error, high temperature, network card malfunction, fan malfunction, power supply malfunction, or hard disk failure, the information on this page will be immediately updated. In addition, the server can also be configured so that whenever a significant event occurs, the system will automatically send an e-mail notification message to the administrator

The POPnetserver 4600 offers a simple and easy-to-use approach to change and modify system and network parameters, set up Windows, UNIX, Novell, and Apple Macintosh network settings and configure and maintain the internal hard disks. The system administrator can segments the POPnetserver storage space into multiple shared volumes. The administrator has control over user access rights of these shared folder through a central form with tabs for setting unique properties and privileges for Windows, NFS, Apple, and Novell shares. The administrator can also set up a volume snapshot policy, which can be configured down to an hourly level. When snapshots are taken, how long snapshots are retained, and who has access to the files are all determined by the administrator.

For sites expecting to have a high amount of traffic, a system administrator can configure multiple LAN ports as a "team." In such a configuration, also dubbed "trunking" or "link aggregation," the POPserver simulates a large-scale LAN port by sharing the same network address across all of the individual NICs and consolidating their overall network bandwidth. In addition, if any NIC fails, the others simply continue to run, so a significant degree of network resiliency and redundancy is added.

There are, however, three noteworthy caveats to the NIC teaming scheme. Each NIC in the team must have the same bandwidth. A 100-mbit NIC cannot be teamed with a 1000-mbit NIC. Second, "trunking" is only available when coupled with a switch that supports Cisco Fast EtherChannel (FEC). Lastly, trunking is really a network switching function, so its value only arises when there are multiple simultaneous users.

To test the performance capabilities of the POPnetserver 4600, we attached to the server from both an HP Compaq EVO laptop client with an Intel 100-mbit Fast Ethernet LAN card built-in and an Appro 1224Xi-21 1U Server with dual Intel Xeon processors and dual Intel Gigabit NICs. As expected using Samba and NFS from the client laptop provided little insight into performance. Whether from Linux or from Windows, whether using volumes shared over NFS or Samba, performance was basically wire speed. We would consistently read data from the share on the order of 9-to-11MB per second and write data on the order of 8MB per second.

When we moved to the server, however, things got quite interesting. In the first tests, we ran SuSE Linux Enterprise Server (SLES) on the Appro system. We configured fstab to import and mount an SMBFS volume from our POPnetserver. Using single threaded reads and writes, performance was an expected ho-hum. As we had measured with earlier systems, Gigabit jumbo packets or no jumbo packets, throughput at about 13MB per second on reads was less than blinding. What's more, it did not get better with more processes.

That all changed, however, when we tested another share imported via NFS. This time we obtained throughput results worthy of the server. Single-threaded reads were in the neighborhood of 17-to-18MB per second. What's more, throughput on reads moved up into the range of 75-to-83MB per second with 4 threads. Writes remained right were they were with 100Mbit Fast Ethernet. Since we couldn't stress the bandwidth of 100Mbit Ethernet, there was no reason to expect conditions to change with Gigabit Ethernet.

We then ran Windows 2003 Server Enterprise Edition on the Appro system to test the Samba shares from a true Windows system. The results showed a dramatic improvement in performance. Mounting the Samba shares from the POPnetserver under Windows 2003 Server, throughput scaled in a similar fashion to what  we had measured under NFS on SLES.