---

NOTE - The .local and .lan top-level domains (TLDs) are not reserved domains. That means those domains could be put into service at some point in the future and become routable domains. Four reserved domains are identified in RFC 2606 (http://http://www.ietf.org/rfc/rfc2606.txt) for testing: .test, .example, .invalid, and .localhost. Although it's unlikely that the domains .local and .lan would be used as live top-level domains in the near future, a systems administrator who wanted to be absolutely certain that his internal domain would never be publicly routed could use one of the four reserved domains. Doing so would present a special set of challenges, because the .localhost name has special functions for referring back to the local machine, and the other names do not imply permanence.

---

Planning the Storage Layout

Determining the appropriate storage layout for the SBS 2008 server is probably the most complex process in the planning stage. So much of the storage requirement depends on the data needs for the site implementing the new server that it is difficult to make a generalized recommendation for what an appropriate storage layout should look like. The remaining sections in this portion of the chapter cover terminology and some baseline recommendations for bare minimum storage requirements. Depending on the level of usage expected on your server implementations, these baseline recommendations may be insufficient for a final deployment.

Changes in Storage from Previous Versions

Because SBS 2008 is built on updated versions of the included components, there are a number of differences in the way the product handles storage needs. The amount of overall storage capacity needed in SBS 2008 is higher than SBS 2003. Where SBS 2003 could originally fit in a 12GB C: partition, SBS 2008 requires a 60GB C: partition. Exchange 2007 now allows for stores of larger than 75GB and can have multiple stores instead of one, which has implications for total storage capacity as well as disk performance. The following sections cover possible approaches to designing storage for an SBS 2008 server given these and other factors.

Multiple Partitions Versus Multiple Spindles

Finding the ideal storage layout is a giant puzzle with a number of key pieces. In the end, the layout implemented is the result of a number of compromises with these pieces.

Ideally, some suggest that an optimum SBS installation would have three spindles, or separate drive mechanisms. One spindle would contain the OS and key applications, one would contain the Exchange log files, and one would contain the Exchange mail databases. This layout would be optimized for performance because the type of disk access needed to read and process the Exchange log files (sequential) is different from the disk access needed to process the Exchange databases (random). User data could be stored on the spindle with the Exchange logs because most user data would be read and written sequentially, and any system-wide databases would be stored on the spindle with the Exchange databases because they would use a similar type of drive access.

The cost of such a layout, however, would keep a small business from implementing it. To achieve any level of fault tolerance, you would need to at least mirror each of the spindles, a total of six drives. If performance were truly the primary consideration, the two non-OS spindles would likely be a RAID 5 or RAID 50 array, jumping up the number of disk drives to at least eight.

Although SBS 2008 will install and run on a single spindle with multiple partitions, if disk performance is a concern for the operation, the server should be built with a minimum of two spindles—one for the OS and one for the remaining data. At a minimum, both spindles need to be mirrored, but a mirrored OS spindle and a RAID 5 (or similar) array for the data.

If a single spindle is all that can be used in the server, the space in the disk should be partitioned into at least two partitions. The C: partition should contain only the operating system and key applications. Dynamic data should be kept off the C: partition to protect against accidental filling of the disk. Should the C: partition get completely full, the server could crash unexpectedly and cause data problems in addition to downtime. As discussed in Chapter 3, "Installing and Configuring SBS 2008," the default installation places all data and applications on the C: partition, even if multiple partitions or drives are available during setup. Only after setup can you move dynamic data off the C: drive and onto other storage areas of the server.

Minimum Partition/Spindle Sizes

The SBS 2008 installation routine requires a C: partition of at least 60GB before it will perform the installation. This is a far cry from the 12GB C: partition that OEM installs of SBS 2003 regularly used. But a 60GB C: partition still may not be large enough, depending on your server configuration. The following sections provide some baseline suggestions for how to devise minimum partition sizes for your server. These sections assume a two-disk or two-partition installation of SBS 2008.

Sizing the OS Partition

One of the significant challenges in supporting existing SBS 2003 installations is maintaining a server with a very small C: partition. When SBS 2003 was originally released, a 12GB C: drive seemed like it would be large enough. When SBS 2003 SP1 was released, a 20GB C: partition seemed like an appropriate recommendation. With SBS 2003 R2, a 30GB or larger C: partition was recommended. The same progression may well happen over the lifespan of SBS 2008, so when reviewing these minimums, understand that they might not be appropriate in a few years; you should try to have as large a C: partition as reasonably possible.

As for the minimums, SBS 2008 installs and uses about 24GB of disk space on the C: drive after all the dynamic data has been moved to other partitions. The remaining space can be used by new applications, OS log files, and swap file storage.

When planning the size of the C: partition, the swap file is probably the single biggest factor to consider; this has not been the case in previous versions of SBS. Microsoft recommends a swap file of 1.5 times the size of physical RAM installed in the server. Because the 64-bit OS can access 32GB of RAM, this could be significantly more storage than IT consultants have been accustomed to using.

To help gauge how much disk space could be used by the basic installation, plus swap file and memory dump free space, Table 2.2 lists the recommended sizes for swap file and minimum total disk space for C: based on the amount of RAM installed in the system.

Table 2.2 OS Partition Size Minimums

If you expect the usage of space on C: to grow more than 20GB in the life of the server, you would need to adjust the initial partition size accordingly. This also highlights the importance of understanding how your RAM needs in the server might increase over the life of the server. If you initially install the server with the minimum 4GB of RAM, and then discover in a year that you really need to have 16GB for the server plus new applications, the 60GB minimum C: partition might not have enough space to handle the increased swap file size and the other applications. Although you can move all or part of the swap file to a different partition, you will not get a crash dump file generated if the swap file is not stored on the C: partition. This is an important consideration because a crash dump can be used by support professionals to help determine the cause of a system crash if the cause is not evident from the crash code itself. If a crash dump is not created on a system failure, it eliminates one possible tool for identifying and resolving the issue.

Sizing the Data Partition

If trying to determine an appropriate size for the OS partition was a bit vague, coming up with an appropriate minimum size for the data partition is even more nebulous. The guidance for partition size in this section is based upon having sufficient free space on the data partition to perform a repair of the Exchange databases, should such a repair be needed. In general, Exchange needs 1.2 times the size of the database file in free space to perform the repair (specifics of the Exchange database repair process are detailed in Chapter 10, "Exchange Disaster Recovery"). If you have a 60GB mail database, you need around 72GB of free space available on the server to be able to repair the database.

Obviously, trying to figure out how large your mail databases could get over the next few years, and then allocating space not only for the database but the repair space, is going to require a bit of guesswork. The bottom line is that you need to allocate as much disk space as you can for future growth.

Fault Tolerance

Fault tolerance defines a system's capability to recover from a failure of hardware or software in such a way as to minimize the impact on the system. In most computer systems, hard disk drives are the first components to fail because they have the most moving parts and are accessed constantly while the system is powered on. Knowing this, most server systems are built with some form of fault tolerance for the disk system to minimize the impact when a disk drive fails.

SBS servers can achieve fault tolerance for the disk subsystems using either hardware or software solutions. Hardware solutions rely on specialized disk controllers to handle the management of the fault tolerance implementation selected. These controllers are more expensive than standard disk controllers. Hardware fault tolerant solutions provide either a mirrored solution—where two disks of the same size act as one—or a RAID (redundant array of inexpensive disks) solution—where three or more disks function as a single drive. See the next section, "RAID Types," for a more detailed explanation of RAID arrays and their functions.

---

HARDWARE VERSUS SOFTWARE FAULT TOLERANCE - Microsoft servers can implement mirrored and RAID-like solutions via software, avoiding the expense of a specialized disk controller card. Through Disk Manager, partitions of the same size can be mirrored by the operating system or combined into a RAID.

Although more expensive, hardware-based fault-tolerance solutions are preferred over the software solutions for one reason—performance. Although the software implementations Microsoft provides for mirroring and RAID are less expensive from a hardware standpoint, the amount of overhead involved in managing the mirror or RAID has a significant impact on server performance.

---

Traditionally, SCSI or Serial-Attached SCSI (SAS) RAID controllers are the devices of choice for fault-tolerance solutions for the disk subsystem. Over the last few years, many servers have been built using Serial-ATA (SATA) drives attached to RAID controllers for a lower-cost solution than SAS. The lower cost does come with a price, however. SAS drives have a greater data throughput than SATA drives, so for servers where disk I/O is going to be critical, SAS should be chosen over SATA.

RAID Types

RAID—which stands for redundant array of inexpensive disks or redundant array of individual disks, depending on whom you ask—is a specification for combining multiple disk units of the same size into a single logical unit for the purpose of improving read/write performance, providing fault tolerance, or both. Although there are a number of RAID specifications, only a few are actually used in practice. Table 2.3 lists the most commonly used types of RAID and describes their functions, advantages, and disadvantages. The number of disks needed for each RAID type is listed as the total available disk space for each type. (The values are based on 80GB drives used as individual elements in the array.)

One other advantage of a RAID configuration is that most RAID controllers can accommodate a hot spare—an extra disk drive on the controller that automatically becomes active if one of the other members of the array fails. Plus, when combined with a hot-swappable drive technology, the failed drive can be removed and replaced without bringing down the server. The upside is obvious because the system automatically rebuilds the necessary information on the newly activated disk if one fails and reduces the time the server spends without fault tolerance due to the failed drive. The downside is the overhead associated with rebuilding data onto the newly added drive, and that can be observed by end users during the rebuilding process. Use of a hot spare is more commonly found with RAID 5 implementations but can be used with a mirrored configuration as well.

TABLE 2.3 Commonly Used RAID Types