Building a World-Beating Web Server

Nor do Web servers typically need a great deal of disk space. Even a vast library of documents will typically fit onto one of today's multi-gig hard drives.

What about network performance? Again, this is usually not an issue. The limits on a Web server's network throughput are virtually always always determined by the speed and quality of its connection to the Internet, not by the server's network interface. If the network interface is saturated, chances are it's the network that needs to be redesigned, not the server.

So, what should you focus on when building a Web server? In this author's long and hard-won experience, the three most important factors are, in order:

1.) Uptime.

2.) Uptime.

3.) Uptime.

Yes, that's right. So long as the server isn't horribly slow and the network connection is adequate to handle the traffic, visitors will not notice a delay of an extra millisecond or two. What will turn them off -- and cost your client money and customers -- is downtime. So, when you're asked to build a Web server, your prime concern as a system builder should be the system's reliability. You should focus on top-quality parts (within your budget, of course), resiliency, and redundancy where it will do the most good.

An airtight case

Start by building your system on a good foundation: A solid case with an overrated power supply and excellent ventilation. Bad power and overheating are the two most common causes of system failures.

If the Web server is to be placed at a co-location site -- where space is often rented by height -- opt for a deep, low-profile (preferably 1U), rack-mount case. As a system builder, you may already have a relationship with one or more suppliers. Whichever one you deal with, get the top-of-the-line model, even if it costs a few hundred bucks extra. The results will be worth it.

The same should be true if you're doing a tower design. Pick a unit with a generous power supply and enough room inside to space the disk drives well apart from one another for better cooling.

In all cases, look for a model with good air flow and good filtration. Nothing kills a server quicker than overheating, and dust bunnies aren't good for reliability.

Mother of all boards

Just as you do with the case, you probably already have a favorite supplier of motherboards. So we won't recommend specific models. Instead, we'll give you an idea of how to choose from among your favorite vendor's portfolio.

First and foremost, get a board that accepts -- and uses %96 error-correcting RAM. A surprising number of motherboards accept ECC RAM, but can't actually do any error correction. Make sure the model you pick does, and also make sure that you switch on the ECC in the BIOS before shipping the unit. Base the amount of RAM on the type of work the server will be doing. For example, if it will be running Unix and mostly serving static pages, then 256 MB is plenty. But if it's running any version of Windows, maintaining a SQL database, running heavy-duty Perl or PHP scripts, or composing pages on the fly, then double or even quadruple that amount of RAM.

Second, minimize the number of connectors -- especially bus connectors -- that stand between the board and its peripherals. Connectors are another common point of failure in computer systems. So you maximize reliability by choosing a motherboard that integrates the peripherals you need. A built-in network interface is a must, and built-in video is a good idea. Not much will be happening on the screen, and a Web server shouldn't be running an active GUI if it's possible to avoid it, so graphics performance is a non-issue. (If your customer insists on running Windows, they'll be stuck with a GUI, but it should be used as little as possible.) Look for a board with built-in RAID, since it's key to uptime. For more on this, keep reading.

Finally, turn off all unnecessary peripherals, both in the BIOS and the operating system. If the server runs UNIX, then rebuild the kernel to exclude all unnecessary drivers. This will minimize the likelihood of problems due to spurious interrupts. It will also leave more resources for the peripherals that are being used.

Disk storage

When it comes to disk storage, as with other components of the system, the watchword is reliability. As a rule, SCSI drives are a disk manufacturer's most conservatively designed and carefuly manufactured products. So if there's room in your budget, go for SCSI technology rather than IDE. If you must use IDE, scan the Internet forums to discover whether users are reporting problems with your intended model. Also, make sure that each IDE drive is on a separate cable; no doubling up allowed. Use good cables; I recommend the Teflon ones from Granite Digital.

Configure the drives as an array of mirrored disks. That way, if a drive quits, the system will lose no data and will continue to run while you replace and rebuild the drive. On a budget of only a few thousand dollars, you may not be able to afford to provide hot-pluggability, but at least you can allow a bad drive to be replaced at leisure -- or when there's a backup server ready to be swapped in. Again, space the drives as far apart as possible in the enclosure to allow good ventilation.

When installing the operating system on the server, be sure to configure it for fault tolerance -- in particular, to be able to handle unexpected shutdowns or reboots. Hopefully, either your customer or their co-location site already has uninterruptible power -- if not, then budget in $400 to $500 for a 1500VA UPS (uninterruptible power supply) -- but sudden restarts do sometimes occur, even under the best of conditions. All it takes is someone tripping over a cord or poking the wrong button, or a long power outage.

Configure the system to communicate with its UPS and do a graceful shutdown if the battery is running out. Set the file system to its most conservative settings. In BSD Unix, use the "softupdates" feature to avoid disk corruption on partitions that are frequently updated -- for example, those that hold the Web server logs. On all Unix systems, mount the all-important root partition as "synchronous" to minimize the chances that the system will fail to restart after a reboot.

Display? What display?

As mentioned earlier, a Web server should mind its business, namely, serving Web pages. It shouldn't be running a GUI, or, if it must, due to the choice of operating system, it should devote as few resources to the display as possible. You, likewise, should devote as little money to this function as possible.

Depending on your customer's preferences, you may be configuring the system for "headless" operation (sometimes with a serial terminal), a KVM switch, or a separate display and keyboard. If physical access to the system is difficult or time-consuming for your client, consider budgeting for a "virtual console" card. This will let them look at what the system's text mode display would show, if one were attached, during the boot process. This can be a lifesaver if a system stops during the bootstrap and requires operator attention to continue. (For an example of one such product, see PC Weasel.) If necessary, add an external modem to allow your client to dial into the virtual console card.

Brains of the outfit

Don't blow your budget on a high-end CPU. While your client may think you're cutting corners if you put in a real slowpoke, a CPU that's in the middle of the current pack -- today, that's a 2.4 GHz Pentium 4 or an equivalent Athlon -- will be more than adequate. It will also leave you more cash to spend on components that matter. Also, don't even think about multiple processors. No operating system is as stable when doing symmetrical multiprocessing as it is when running on an old-fashioned, single CPU system. If a server with one processor won't handle the load, then consider deploying multiple servers with round-robin DNS, or offloading burdensome functions such database management to another machine. This is far more cost-effective than paying for an SMP (symmetric multiprocessing) motherboard. Multiple servers also allow automatic failover if one of them goes down.

As you assemble the system, make sure the CPU has a good heat sink, one that is coupled to the CPU with a top-rated thermal compound. The metal-bearing pastes and epoxies are best, but be sure not to get them on the pins or the motherboard. The last thing you -- or your customer -- needs is an overheating CPU.

Hacker-proof security

Web servers, by their very nature, must be out on the Internet. That also means they're exposed to hacking, tampering, and break-ins. Hackers will rattle the doorknobs seeking to get in, and they may deface, crash, or even hijack the server if they can. Putting your server behind a firewall with an intrusion-detection system may stop some attacks. But even if such a firewall is available, the best course is to make the server secure enough to stand on its own.

I suggest you start by picking a highly secure operating system, such as one of the BSD Unix implementations, rather than any version of Microsoft Windows. Windows averages one newly discovered security problem per week and was the target of the Web-based Code Red and Nimda worms. Linux has a better track record than Windows, though not as good as that of the BSDs -- especially OpenBSD, which has had only one significant security hole in six years. FreeBSD is very popular among Web server operators; it's the OS of choice for Yahoo!, and was used by Hotmail for quite some time even after the company's acquisition by Microsoft.

In all cases, it's advisable to turn off any operating-system services, or "daemons," that are not needed for Web service. Use the OS's built-in firewall to block all protocols other than those necessary for Web service or maintenance of the server. Disable all protocols, such as FTP and Telnet, which allow passwords to be sent "in the clear." (Instead, use SSH, SFTP, or WebDAV over SSL to upload files to the server.) Limit the IP addresses from which the server can be administered. Even better, limit adminstrative sessions to those coming in over a separate, in-house Ethernet interface. This may not be possible if the server is co-located, but it's ideal in a corporate setting.

Finally, if at all possible, deliver the system to your customer with all of the necessary software running and some sample Web pages already present. Hopefully, you've stayed within budget and made a reasonable profit on the machine. You deserve it -- a Web server that stays up is worth its weight in gold.

BRETT GLASS is an author, electrical engineer, and consultant. He founded Lariat, the first wireless broadband provider, in Laramie, Wyo.