Print-friendly Version

Introduction to Creating a File Server

The following is a general guide to building a file server, for the inexperienced system administrator. While the principles are applicable to any system, the specifics are targeted towards a UNIX operating system. Both hardware and software concerns are addressed. This article focuses on system design, leaving the exact implementation up to the reader.

The Physical

When building a file server, the number one concern for that file server is to always have the data available. Data capacity, network connections, access methods, and so on, are all important factors in building a file server -- but not if that server is down. It doesn't matter how well a server can perform if that server is not performing at all.

A server's availability is often referenced in terms of percentage of uptime. Typically, management sets this percentage based on the needs of the organization and a cost-to-benefit analysis. For example, a company may wish its web server to have a 99.5% uptime, which means in any one-year period, the server is to be unavailable for no more than 43 hours. But that same company might not want to spend the "x" amount of money it would cost to achieve that uptime, and instead opt for less availability, at the price range that fits the company's budget.

A system's uptime is a function of its fault-tolerance. Redundant parts are used to prevent any one piece from failing and bringing the system to an unusable state. Hardware RAID devices are an example, allowing one drive in the array to fail without any impact on the performance or access to the data on that array. While a completely redundant system is possible in most cases, it is also cost prohibitive. It is best to focus on making redundant those pieces that are more likely to fail -- or that are the most critical -- and purchasing stand-by replacements for everything else.

The primary concerns when dealing with a file server are its data storage devices. There are two aspects of storage to consider: the boot device, and the data store. Both can be physically located on the same device, but it is not recommended. Each device has different requirements for its protection, and this would complicate matters if the two shared hardware.

The boot device contains your operating system and any applications required to make your system a viable file server. Hard drives are big enough today to allow for this data to typically fit entirely on one drive. The loss of this drive, while inconvenient and detrimental to productivity, would not be a complete disaster. A reinstall of the OS and tools would bring you back to the same place you were before the fault occurred. As such, redundancy is not a requirement but a convenience.

A mirror of the boot device will suffice in protecting the time invested in the system configuration without adding much addition cost. After the boot drive fails and the system goes down, a reconfiguration of the server will have it booting the mirrored drive and running as if nothing has happen. Hardware solutions are best for providing this ability, since some products can avoid the system going down and automatically switch the boot drive. Software solutions typically create extra system overhead, but also come at a lower cost.

The data drive has the files the system will be serving. These files are the unique, irreplaceable work of the company's employees. They require as much protection as can be afforded, and so this drive should have as much redundancy as possible.

This logical drive should be physically located on multiple hard drives, using RAID 5. RAID 5 keeps copies of the data of one drive scattered across the other drives in the array. This allows one hard drive to die without any loss of data. The array should have at least one hard drive in standby mode to immediately replace a failure without any human interaction. After the first drive fails and is switched to the standby, the RAID will not become a single point of failure because it can handle a second drive malfunction before any physical intervention is required. Finally, another RAID array can be set up as a mirror of the first, to ensure that the array itself is redundant.

The other pieces of the system do not require online replacement for the average file server role. The cheapest method of protection is just to have an extra part handy in case the first one fails. The motherboard, power supply, network card, keyboard, and so on, can normally be replaced in less than an hour from time of shutdown to time of boot up. Unless you have strict uptime requirements (95%+), you can probably get away with this downtime without impact on your performance metrics.

The Logical

There is no final answer on how to configure your operating system. The following are some of the most common topics that you should be aware of when designing and implementing your system.

File System Layout
When installing the operating system, the installer typically asks how you would like the system partitioned. It used to be that one hard drive was not enough to contain all parts of the OS, so the system would typically be broken up into root (/), swap, /usr, /var, and other major partitions (as per the UNIX flavor). Nowadays, a hard drive can contain all of these partitions and not even be close to full, allowing for expansion.

Reasons still exist for creating more partitions than just root (/) and swap. For example, Linux systems running on x86 hardware have a registry restriction where the boot loader (LILO or GRUB) cannot be outside of the first 8 Gbyte on the boot drive, or the system will not load.

If you want a root (/) partition larger than 8 Gbyte, you have to create a partition to hold /boot (the boot loader and kernel). Another reason to partition is to restrain the growth of files from taking the system down. Some systems crash when the root (/) partition is full. To prevent this, fast-growing directories (such as /var, where log files are kept) can be put onto separate partitions.

Performance concerns would have you scatter partitions across multiple hard drives to increase access time. While the root and swap partitions ran the system (/ and swap on drive 1), the log files could be updated (/var on drive 2), and the X window system libraries (/usr on drive 3) could be accessed by the third-party application (/opt on drive 4). The speed of today's hardware minimizes the usefulness of this overhead, but it might come in handy in those rare cases where milliseconds can matter.

SWAP
How much swap space a system needs depends on how the system will be used. Swap is disk space that is used by the system when memory space needs to be emptied of one program for use by another program. Since most applications are in the 10-100 Mbyte range, your typical desktop only needs 1.5 times memory, up to a maximum of 512 Mbyte. On the other hand, a simulation server working with a 10 Gbyte waveform file might need multiple gigs of swap. A file server, since it is normally tasked only to serving files, requires only the bare minimum dependent on the OS. To be safe, and since disk space is cheap, I configure 512 Mbyte of swap.

Applications/Services
The purpose and content of the server will dictate what software should be running on the server. For security and manageability, only required daemons should be running on a server. It is easier to troubleshoot a problem on a server running three services rather than one that runs 30. All access to the server should be strictly controlled. The accounts that can log in should be limited, as well as the access methods. If possible, avoid adding services such as NIS that add more vulnerability, using local accounts instead. Use a secure connection (such as SSH2) instead of telnet or rlogin, which should be disabled. The fewer things running, the better -- and the fewer people accessing the box, the better. This can keep the problems down and the uptime high.

The method of file access determines the service you should be running. For UNIX clients, NFS will need to be configured. Samba or an equivalent application is required to service Windows machines. A web server like Apache will be needed for HTTP traffic. A secure FTP server such as ProFTPD should be used to serve FTP clients. Other ways to access files are available, but these are the common ones.

What Comes Next

You should now have a fair understanding of the common dilemmas faced when designing a file server. Specific implementations can vary from vendor to vendor, but should fit with the framework detailed in this article. To further your knowledge, here are some other resources that might come in handy:

• Network Server Hardware article from "Designing and Building the Best Small Office Network From the Ground Up" series, Network Computing
• Building a Secure Web Server (PDF) by Jason Novotny and Marcia Perry, DOE Science Grid
• Building a Fax Server by Ted Mittelstaedt, Computer Bits

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.