A dedicated NFS server with appliance-like ease of use, the FAServer provides affordable performance and data reliability
Bruce Dawson
True to its name, Network Appliance Corp. (NAC) makes a file server that you basically just plug in and use. Attach a few cables, answer a few installation prompts, and the FAServer 400 is up and running, providing up to 27.3 GB of fast, reliable Level 4 RAID storage.
The FAServer is a dedicated file server for LANs with clients supporting NFS (Network File System) protocol--typically Unix sites running TCP/IP as an Ethernet protocol. However, the FAServer isn't just for Unix environments; many multiprotocol networks support TCP/IP, often with NFS support for clients other than Unix machines.
As an NFS server appliance, NAC's FAServer can specialize in file serving an
d provide better performance, reliability, and economy than the general-purpose Unix workstations typically used as NFS servers. With its proprietary file system, tuned to function with both the NFS protocol and RAID 4, the FAServer provides both exceptional performance and such niceties as automatic on-disk incremental backups, hot swapping, and incremental capacity growth. Using a dedicated file server also simplifies administrative tasks, such as backups and account administration, and relieves workstations of the burden of serving files.
Starting at $16,995 for a unit with two mirrored 1-GB hard drives and 16 MB of RAM, the FAServer 400 is actually part of a small product line. At the upper end is the rack-mounted FAServer 1400, which supports redundant power supplies and goes for $20,995 with two 1-GB drives.
What's NFS?
NFS is a network-file-server protocol developed by Sun Microsystems. It layers on top of IP, which runs over a wide variety of media (most typically Ethernet, but seria
l lines, FDDI [Fiber Distributed Data Interface], and wireless LANs are not uncommon).
NFS is a stateless file-sharing protocol, which means that the file server can reboot and its clients won't notice, except for the delay during the reboot. Hence, it is an ideal protocol to run over large networks that have long latency delays or that cover a wide geographical area, such as the Internet.
While NFS is a de facto standard in the Unix world and many Unix systems support it, NFS has not caught on in the PC marketplace. One reason for this is that it requires additional protocols to manage the technical details of such server application necessities as file and record locking and file system mounting and unmounting. These capabilities were designed to run as processes separate from NFS, and that's something DOS doesn't handle as gracefully as Unix does.
However, a number of companies have warmed to the capabilities of Unix, especially for large applications, and have invested in Unix systems
. Companies that want to share data among all their computers--which often include PCs, Macintoshes, and Unix and other systems--can choose from a good selection of TCP/IP software that often includes NFS support as an option.
Not Unix
If you have the idea that the FAServer runs Unix and that you can therefore do things like add additional commands, get ready for a surprise. It's not Unix, or even close to it. The FASware operating system is an embedded system with precious few Unix-like commands--only the bare necessities for administering the system. If it used Unix or a Unix derivative, the FAServer wouldn't be able to provide the performance that it does because of overhead.
Not only does the operating system lack many Unix commands (those it does have are similar to their Unix counterparts), the file system is radically different. NAC named it Write Anywhere File Layout (WAFL for short), because any part of the file system, including the file management information, can be written anywhe
re on a disk. Partly as a result, the FAServer gets around the performance bottleneck that RAID-4 designs typically create because they must update a dedicated parity drive with every write operation.
RAID offers the advantages of data protection through redundancy (the parity drive), a large data space through ganged drives, and high performance through parallel access to multiple drives (known as striping). The technology used to implement the various RAID levels becomes more sophisticated as the level number increases.
RAID 5 is currently the most sophisticated because it stores parity information on all the drives, making the parity updates less of a bottleneck. It also has the disadvantage of requiring that you add disks in increments of whole arrays (instead of single disks).
NAC chose to use RAID 4, which has most of the features of RAID 5 but lets you augment the array incrementally with single disks. (The FAServer operating system supports this.) In addition, NAC's WAFL file syst
em overcomes the performance disadvantage of a dedicated parity drive.
With its WAFL system, the FAServer doesn't overwrite an existing file to update it; it writes the update to a new area and then changes internal pointers to the file. Such updates include any directory and block allocation data that changes, too. The FAServer holds incoming write data and NFS requests in its battery-backed 2-MB cache (upgradable to 4 MB) so that it can organize all new writes and updates into an efficient, all-in-one write operation that occurs in a narrow band across all drives, including parity updates.
WAFL writing episodes occur every 10 seconds or so and are managed so that a dirty server shutdown, such as from loss of power, won't corrupt any data--even that in the battery-backed cache RAM.
Backup Reliability
The WAFL file system has reliability benefits as well. Because old data isn't overwritten immediately, it still exists on the drives. And just as the FAServer maintains the file data, it
also maintains the pointers to that data, so all the data on the drive as it existed at a particular time is recoverable. NAC calls this concept snapshots.
Essentially, a snapshot is a read-only version of the entire file system at a particular point in time. The FAServer maintains up to eight snapshots of the file system that users can access to recover files as long as two weeks after deletion.
A frequent problem with making backups of a running system is that some data will change while a backup is under way. This problem isn't specific to file servers, but is common to all multiprocessing systems. Usually, you should first bring such a system to stand-alone mode so that there is no activity other than the backup.
Because of the FAServer's WAFL file system and snapshots, however, you don't have to bring the server down for backups. When it comes time to back up the server, all you have to do is back up the snapshot files, and file system consistency will be preserved. This one feature
could easily justify the procurement of a FAServer to organizations that want highly available systems.
Of course, this snapshot method is a bit more complex than the traditional file-writing method, so NAC has provided several commands to help in snapshot management. The Administration Guide has also done a good job describing the basic principles behind the snapshot method. The snapshot management commands allow the administrator to reserve space for snapshots, create and delete them, rename them, schedule them, and list them. Snapshots are client accessible (as read-only subdirectories of the mount-point directory), and the administrator can choose to disable snapshots entirely or schedule them as often or as seldom as desired.
Room to Grow
The FAServer 400 has a 50-MHz 486 CPU, an Ethernet board (with thick and twisted-pair Ethernet connections), a small VGA monitor and graphics card, and a 3 1/2-inch floppy drive for loading software. I tested the $16,995 base unit with 16 MB of RAM (ex
pandable to 128 MB) and two 1.08-GB Fujitsu hard drives. Since RAID-4 uses one disk for parity, that leaves 1.08 GB of actual storage.
It's a rather large, wide black tower on casters, with room for up to seven hard drives. An additional chassis ($2995) can hold seven more. Drive capacity can be either 1.08 or 2.1 GB; maximum capacity is 27.3 GB, which appears as a single volume. The unit has four fans, which in older units can be quite noisy. The FAServer I tested had older fans and produced a sound reminiscent of a space heater. I moved it to the computer room because of all the noise.
For an appliance, the FAServer has a surprising number of expansion options. In its EISA expansion slots it can take up to four network adapters, including one or two FDDI adapters and up to two SCSI-2 controllers.
After I completed the review of the 400, NAC started replacing this model with its new 450 (for the same price). The 450 has a slightly larger case that can hold 14 drives instead of seven. All
else, including the electronics and software, remains the same as in the 400.
Setup
Setting up the FAServer was a snap. All I had to do was let it warm up (it arrived when the outside temperature was 10¡F), plug it in, and cable it up. The only glitch was a VGA board that must have worked loose in shipping. Once I discovered how to get into the box and reseat the board, the system came up perfectly.
During the installation process, I had to type in four essential pieces of information: the node name, its IP address and netmask, and the local time zone. I also entered an administration host name; if this is not specified, any node on the network will have root access.
After I provided this information, the FAServer immediately came up on the network. I then went to the administration host and edited the FAServer's /etc /hosts file to add the other systems on the network. Note that the FAServer software doesn't yet support any of the network name protocols (NIS or BIND), so it relies o
n several files in its /etc directory for network information.
After adding some of the systems on the network to the /etc/hosts and /etc /exports files and mounting the FAServer's file system on the clients, I started copying files to and from the FAServer. It was surprising just how quickly the FAServer responded to some systems; it provides better response than a number of general-purpose computers with faster CPUs. And it was an even bigger surprise to see how slowly the FAServer appeared to respond to some slower systems that I tested.
Testing
Used with a DECstation 3100 running Ultrix 4.1, the FAServer ran like a breeze. Copying a 4,058,924-byte file from the DECstation 3100 to the FAServer took 1 minute, 19 seconds, and copying the file in the other direction took 21 seconds. It took 27 seconds to create a 10-MB file on the FAServer from the DECstation 3100 (no local disk I/O); this is in contrast to the 24 seconds it took to create the file on a local disk.
The above numbers we
re gathered on a relatively quiet network (i.e., there was no network file activity). I had also flushed Ultrix's I/O caches by doing a lot of other I/O before starting the tests.
It was not unusual to see "NFS server xxx not responding, still trying" messages while copying a file from the DECstation 3100 to the FAServer. I never saw the messages when copying in the other direction. Technical support at NAC explained that the FAServer can turn packets around a lot faster than some clients can see them, which results in time-outs.
A time-out is the amount of time that elapses before the client tells the server that it missed a packet. If the time-out has been set to the default of 30 seconds, then the client effectively waits 30 seconds before notifying the server that a packet is missing. Reducing the time-out to the 1-second minimum means that the client waits only 1 second before noticing the missing packet.
When I tested the FAServer with an HP 9000 Series 7000 as client, performance
was even faster than with the DECstation. It took only 15.31 seconds to create a 10-MB file on the FAServer from the HP. When performing the same tests on a no-name 33-MHz 386 running Interactive Unix 3.2.2, I saw substantially slower numbers. It took more than 2 hours to copy a 891,110-byte file from the Interactive Unix system to the FAServer, and I aborted the attempt to create a 10-MB file on the FAServer from the Interactive Unix system after about 2 hours.
NAC explained that this slow performance was due to the time-outs and packet resends: The FAServer sent packets back a lot faster than the clients could process them. NFS typically uses the UDP (User Data Packet) data-layer protocol to perform data transfers; since UDP has minimal overhead, it is faster than other protocols. However, UDP does little error checking, leaving reliability checking to the application--in this case, the NFS server and clients. Although there are TCP implementations of NFS to ensure a reliable link at the cost of adde
d overhead, they are not in wide use, and NAC has not yet implemented them in the FAServer.
I experienced similar problems with a Dell 320SLi running DOS 6.0 with Microsoft Windows 3.1, FTP Software's PC/TCP with Interdrive 2.2, and Xircom's Ethernet CreditCard with version 2 of its software. However, the FTP Interdrive (NFS) software installed on that system was much more configurable than the Interactive Unix software, and I was able to reduce the time-outs. Although I then saw better throughput on the Dell, it still did not match the throughput seen with the faster clients.
NAC plans to replace the version 1.2 software I reviewed with version 2.0 in late July. The new version will support DNS (Domain Name Service), a TCP/IP network name protocol.
Administering the FAServer
You can administer the FAServer directly through its console terminal, remotely through a telnet session (only one is permitted), or through SNMP (MIB-II [Management Information Base] is supported). You don't hav
e most of the commands that would be available on typical Unix systems, such as editors, directory listers, and the like. Nor do you have direct access to the file system itself. In fact, to add additional clients, you have to edit the /etc/hosts and /etc/exports files on the FAServer from an NFS client (typically the administration client system specified at installation).
The FAServer telnet session and console are linked together--a useful security feature. When the console password is typed on the FAServer console and a telnet session is active to the FAServer, commands and output on either appear on the other. Unfortunately, there are no provisions for hard-copy output; the FAServer has no serial or parallel ports.
The FAServer also supports the SNMP MIB-II agent protocol and provides commands to query and update the MIB. These are not configured in by default, and if desired, you must hand-edit them into the start-up file at installation time. Of course, your site must have the appropriate
network management software to take advantage of this feature.
Fast and Easy
The FAServer gives excellent performance with fast clients, copying megabytes of files over an Ethernet connection in just a few seconds. However, its quick response time caused problems with slower clients, in some cases slowing file transfers to a snail's pace. If you have slower NFS clients on your network, I'd recommend waiting for a release of FAServer software that can slow its response to match that of the client.
Because of NAC's WAFL file system and RAID-4 optimizations, the FAServer's performance will hold steady regardless of the number of disks on the system. As important as performance to most people, however, will be the FAServer's ease of installation, administration, and expansion, together with the convenience and data reliability of its snapshot file system. A starting price of $16,995 doesn't hurt, either.
The Facts
FAServer 400...................$16,995
(with 16 MB
of RAM, Ethernet port, two 1.08-GB hard drives, monochrome monitor, and keyboard)
Network Appliance Corp.
295 North Bernardo Ave.
Mountain View, CA 94043
(415) 428-5100
fax: (415) 428-5151
Illustration: FAServer WAFL File System
The FAServer makes the most of its RAID-4 drive system by collecting and organizing write operations for periodic disk updates. NAC's WAFL adds to this efficiency; all updated data blocks, as well as changes to directory and allocation information, are written in roughly the same stripe across the drive array. Files are located using arrays of pointers called i-nodes. The root i-node, the only block with a fixed location, describes the file system and points to the i-node file, which in turn points to file blocks, including the block map file that tracks disk allocation and the i-node map file that tracks free i-nodes. One or more layers of indirect pointers are used for larger files (as shown). A snapshot is simply a copy of the root i-node taken at a particu
lar time. Because old data and directory information aren't overwritten immediately, a snapshot can recover old versions of files.
Photograph: Inside the FAServer 400's big black case is room for up to seven 1- or 2-GB SCSI-2 hard drives. Because of NAC's WAFL file system, you can add drives to the RAID-4 array one at a time.
Bruce Dawson is a consultant working for Virgin Software, Ltd. (Manchester, NH). He has been developing low-level Unix, VMS, and DOS applications for the last 10 years. He can be reached on the Internet at
jbd@virgin.mv.com
or on BIX c/o "editors."
Plug-and-Go File Server
