Section 4.1. Determining Functional Requirements

4.1. Determining Functional Requirements

The problem with defining a "SOHO server" is that both words mean different things to different people. SOHO might encompass anything from 1 to 25 or more users, and a simple file and print server has very different requirements from a system that also functions as an application, database, web, and/or email server. In short, a "SOHO server" can be just about anything.

At one extreme, a SOHO server can be just a repurposed older desktop system, perhaps with a larger hard drive added. At the other extreme, a SOHO server can be a $15,000 box that uses such technologies as multiple processors, ECC memory, SCSI RAID, redundant power supplies, and so on.

As much as we believe in the advantages of building your own, we think it's a mistake to build the latter type of server, except perhaps for medium or larger companies that will have several such servers in use. A small company can no more afford extended server downtime than can a larger company, and avoiding downtime means having spares on hand. If you're running a dozen such servers, it's no great hardship to maintain a reasonable spares kit. If you're running only one server, the cost of spares can nearly double the cost of building the server.

Accordingly, for a "larger" small company that requires a powerful, sophisticated server, we recommend buying rather than building. Call IBM, buy a server that meets your requirements, and sign up for the best on-site service plan they offer. The cost of 20 people sitting around drawing their salaries while they're unable to work adds up quickly. Even a short server outage may cost the company more than you "saved" by building your own server.

Buy Blue

If you're going to do it, do it right. Don't buy from Dell or another second-tier server vendor. Don't buy HP. Buy IBM, period. We know we'll get mail from people with horror stories about their IBM servers. It happens, but not often. And we'd hear lots more horror stories if we recommended anything but IBM servers.

Most SOHO servers fall between the extremes, and it's such servers that this chapter focuses on. Tables 4-1 and 4-2 list some starting points for configuring a SOHO file or application server appropriate for your own requirements. (In reality, we'd probably not build either of the 1120 user or 20+ user configurations; we'd buy an IBM server instead.)

Table 4-1. Suggested SOHO file server configurations

	15 users	610 users	1120 users	20+ users
CPU	Celeron Sempron	Pentium 4 Athlon 64	Pentium D Core 2 Duo Athlon 64 X2	Opteron Dual Opteron
Memory	512 MB	1 GB	2 GB (1 GB/core)	2 GB/CPU
Disk subsystem	S-ATA S-ATA RAID 1	S-ATA RAID 1 S-ATA RAID 5 S-ATA RAID 0+1	S-ATA RAID 0+1 SCSI RAID 1 SCSI RAID 5	SCSI RAID 5 SCSI RAID 0+5
Ethernet interface	100BaseT 1000BaseT	1000BaseT	1000BaseT dual 1000BaseT	1000BaseT dual 1000BaseT
Backup hardware	DVD+R external hard drives	DVD+R external hard drives	tape drive/changer external hard drives	tape drive/changer external hard drives

Table 4-2. Suggested SOHO application server configurations

	15 users	610 users	1120 users	20+ users
CPU	Pentium D Core 2 Duo Athlon 64 X2	Pentium D Core 2 Duo Athlon 64 X2	Opteron Dual Opteron	Dual Opteron Quad Opteron
Memory	2 GB (1 GB/core)	4 GB (2 GB/core)	application dependent	application dependent
Disk subsystem	S-ATA S-ATA RAID 1	S-ATA RAID 1 S-ATA RAID 5 S-ATA RAID 0+1	S-ATA RAID 0+1 CSSI RAID 1 SCSI RAID 5	SCSI RAID 5 SCSI RAID 0+5
Ethernet interface	100BaseT 1000BaseT	1000BaseT	1000BaseT dual 1000BaseT	dual 1000BaseT
Backup hardware	DVD+R external hard drives	DVD+R external hard drives	tape drive/changer external hard drives	tape drive/changer external hard drives

All of these configurations assume you are running Linux, which for most situations is the best OS choice for a SOHO server. If you run a Microsoft server OS, these configurations may be marginal, particularly CPU and memory. There's no getting around it; Windows server is a pig. When it comes to server hardware, Linux takes tiny sips whereas Windows server takes great gulps.

Although we specify number of users, all users are not equal. One user who runs a CPU-intensive server-based application may put more load on an application server than a dozen users who simply retrieve and save a document or spreadsheet occasionally. The type of load also varies. A shared database that resides on the server may stress the disk subsystem but place fewer demands on CPU and memory. A client/server application that ships large amounts of data to clients may stress the network interface. A server-based application may hammer the CPU and memory but not the disk subsystem. And so on.

SCSI Versus SATA

We recommend SCSI hard drives for any server whose disk subsystem is very heavily accessed. SATA hard drives, particularly in a performance-enhancing RAID, are suitable for servers that experience light to moderate disk activity. In fact, under such conditions, SATA is often faster than SCSI. But when the disk subsystem is being hammered by a flood of disk requests, SCSI simply leaves SATA in the dust. Also, the fastest hard drives are available only in SCSI interfaces.

When you design a SOHO server, it's important to determine which server subsystems are likely to be bottlenecks and design accordingly. For example, if the server functions primarily as a database server, you might spend a significant part of your budget on a stacked SCSI RAID disk subsystem and lots of memory, and correspondingly less on CPU, the network interface, and other components. If network throughput is the bottleneck, you might install multiple Gigabit Ethernet adapters on the server and use Gigabit Ethernet switches rather than 10/100BaseT hubs or switches. Designing a SOHO server is all about balanceallocating your budget to eliminate the most important bottlenecks. Of course, each time you eliminate one bottleneck, you uncover another.

We sat down to think through our own requirements for a SOHO server. Here's the list of functional requirements we came up with:

Reliability

First and foremost, the SOHO Server must be reliable. Our server will run 24/7/365. Other than periodic downtime to blow out the dust, upgrade hardware, and so on, we expect our server to take a licking and keep on ticking.

Massive storage capacity

In the past, we routinely used lossy compression formats to cut down file sizes, storing our audio as MP3s and our digital camera images as JPEGs. Hard disk space is so inexpensive nowadays that it's no longer necessary to use lossy compression for many types of files. For example, instead of storing important digital camera images as 3 MB JPEG files, we now store them in RAW format, which produces 20 MB files. Similarly, when we rip one of our audio CDs, we no longer store the tracks in lossy MP3 format. Instead, we simply store the original, uncompressed WAV files, or convert them to FLAC files, which use lossless compression, but produce files significantly larger than MP3 or OGG files. Also, we have begun experimenting with a DV camcorder, which requires 13 GB of storage per hour of video. Obviously, we need a lot of disk space on our server. We decided that 2 TB (2000 GB) would suffice, at least to get started.

Data safety

We've never lost any data other than by our own stupidity, and we want to keep it that way. Accordingly, our initial thought was to configure our server with RAID storage. Just because it's possible to do something, though, doesn't mean it's always the best solution.

RAID prevents data loss when a hard drive fails, and can increase disk subsystem performance on a heavily loaded server. Weighed against those advantages, using RAID requires buying more hard drives (and perhaps a special RAID adapter) and doesn't protect against the more common causes of data loss, such as accidental deletion, data being corrupted by a virus or malfunctioning hardware, or catastrophic loss caused by theft or fire. Even if you have a full RAID storage system, you must still back up your data frequently to protect against loss.

We're paranoid about backup. We do daily backups of our server data directories to the local hard drive of Robert's main desktop system, and copy those backups to DVD+RW discs daily and DVD+R discs weekly. We use rsync to replicate our data continuously from the server drives to networked volumes on other systems, and we capture a snapshot of all our working data every day to external hard drives, which also contain multiple copies of our archived data. All of our video is duped to backup DV tapes. Even a catastrophic server failure would cost us at most a few minutes' work.

So, after considering the advantages and disadvantages of using RAID, we decided to use nonredundant S-ATA hard drives in our SOHO server. By giving up the small additional safety factor provided by RAID, we gain much more available hard disk space and free up at least a couple of drive bays that can be used for later expansion.

Flexibility

Initially, our SOHO server will be almost exclusively a file and print server. It will run Linux, though, so it's likely that at some point the server will transmogrify to an application server of some sort. To allow for that possibility with minimum disruption, we'll configure the server initially with enough processor and memory to allow adding functions incrementally without upgrading the hardware.

Expandability

When we set out to design our new SOHO server, we originally considered building an "appliance" system with a microATX board and a low-power processor in a small form factor case. There are a lot of advantages to such a server. It's small and so can be put anywhere. It doesn't consume much power, produces little heat, and doesn't make much noise. But as we thought about it, we realized that for us the disadvantages of a small system outweighed the advantages. However flexible our initial configuration, it's likely that at some point we will want to expand the server by adding disk space or other additional hardware. The microATX form factor is simply too limiting. With a full ATX motherboard and a larger case, we have room to grow.

Television capture

Although we have a full-blown media center system with complete PVR functionality, there may be times when it would be useful to have additional PVR capability in another system. For example, if we are watching one program on the media center system using "live-pause" while recording a second program, both tuner cards are occupied. If we need to record a second program simultaneously, we're out of luck. The SOHO server system is an ideal "backup PVR." It's lightly loaded, particularly during nonworking hours when we're most likely to want to record programs. It has plenty of disk storage, and is protected by an industrial-grade UPS.

Jim Cooley Warns

Jim commented, "Dumb idea. Why add the risk of corrupting the OS with recording software? Use it on the client and store to the server." And he has a point. But Jim is a Windows guy and we're Linux guys. We agree that installing a TV capture card on a Windows server would be a dumb idea. But Linux is much more stable than Windows. If our TV recording application crashed under Windows, there's a very good chance it would crash the server. Under Linux, if the TV recording application crashes, there's very little chance it would crash anything but itself.