Best Practices for

Windows Server 2000/2003

Disk Partitioning and Volume Design

By: Craig Borysowich

Chief Technology Architect
Imagination Edge Inc.
www.imedge.net
Introduction
This whitepaper addresses the need for a stable design of disk and volume layouts to ensure that a server is
robust and highly available. This paper discusses a series of industry Best Practices and advice on
designing a solution for proper installation that provides redundancy and fault tolerance, but maintains the
highest levels of performance.

Drive Types
There are wide ranges of drive types available, but the lion share of server hardware available leverages the
SCSI standard for providing local disk solutions. However, SATA, Ultra ATA, iSCSI, or SAN/NAS
solutions are also compatible. The one thing to keep in mind is that off-board disk will likely not perform
as well as on-board dedicated disk to the server. So it is recommended to have at least two local hard
drives for OS, logs etc. and then connect via iSCSI, Ethernet, or Fiber Channel to a SAN/NAS solution.

The higher the speed of the drives the better for performance as well. Taking 15000RPM drives over
10000 RPM drives is recommended for performance.

Software vs Hardware RAID

RAID stands for Redundant Array of Inexpensive Disk and provides a methodology for combining large
numbers of disks into single contiguous partitions and/or providing heightened levels of data redundancy
within a disk partition. There are two possible ways to implement RAID: Hardware RAID and Software
RAID.

Hardware RAID
The hardware-based system manages the RAID subsystem independently from the host and presents to the
host only a single disk per RAID array.
An example of a Hardware RAID device would be one that connects to a SCSI controller and presents the
RAID arrays as a single SCSI drive. An external RAID system moves all RAID handling "intelligence"
into a controller located in the external disk subsystem. The whole subsystem is connected to the host via a
normal SCSI controller and appears to the host as a single disk.
RAID controllers also come in the form of cards that act like a SCSI controller to the operating system but
handle all of the actual drive communications themselves. In these cases, you plug the drives into the RAID
controller just like you would a SCSI controller, but then you add them to the RAID controller's
configuration, and the operating system never knows the difference.

Software RAID
Software RAID implements the various RAID levels in the OS disk (block device) code. It offers the
cheapest possible solution, as expensive disk controller cards or hot-swap chassis are not required.
Software RAID also works with cheaper IDE and ATA disks as well as SCSI disks.

For optimum performance, it is recommended to go with the hardware RAID solution. As more volumes
are created and more advanced levels of RAID are implemented, the software-based RAID can consume a
lot of CPU and memory. The hardware RAID controller should also have a battery backed write Cache to
ensure that sudden power outages do not lose any data.

Note: Before you can use the software RAID in Windows Server 2003, you must convert basic disks to
dynamic disks. In addition, dynamic disks are not supported on cluster storage.

Raid Levels
There are various different levels or methods that can be used to implement RAID technology
 Factors RAID-0 RAID-1 RAID-5 RAID-0+1
Minimum number 2 2 3 4
of disks
Usable storage 100 percent 50 percent (N-1)/N disks, 50 percent
capacity where N is the
number of disks
Fault tolerance None. Losing a Can lose multiple Can tolerate the Can lose multiple
single disk causes disks as long as a loss of one disk.. disks as long as a
all data on the mirrored pair is not mirrored pair is not
volume to be lost. lost. lost
Read performance Generally Up to twice as Generally Improved by
improved by good as JBOD improved by increasing
increasing (assuming twice increasing concurrency and
concurrency. the number of concurrency. by having multiple
disks). sources for each
request.
Write performance Generally Between 20 Worse unless Can be as low as
improved by percent and 40 using full-stripe 25 percent of
increasing percent worse than writes (large JBOD. Can be
concurrency. JBOD for most requests). worse or better
workloads. depending on
request size.
Best use • Temporary • Operating • User and • Operating
data only system shared data1 system
• Log files • Application • User and
files2 shared data
• Application
files
• Log Files

For operating system purposes, RAID 1 is perfect. With the minimum size of drives available increasing to
36GB, it is unlikely that you would need to use RAID 0+1 for your system/boot partition. Use only RAID
1 where possible. With the popularity of blade and 1U servers that only allow for two drives, this RAID 1
configuration will become a standard very quickly. The rest of the disk in a system can be used for data in
a RAID 5 configuration.

Basic vs. Dynamic Disk

Windows Server 2000/2003 allows for the configuration of both Basic and Dynamic Disk. Where possible
in a Windows Server 2000/2003 implementation, you should configure all of your partitions as dynamic so
that they can grow when space becomes limited. The performance of a partition seriously degrades when
the free space is below 20%, so dynamic disk can help solve this issues by increasing the space available.

Basic Disks
In essence, a basic disk contains basic volumes, such as primary partitions, extended partitions, and logical
drives. When you use basic disks, you're limited to creating four primary partitions per disk or three
primary partitions and one extended partition with unlimited logical drives. Although these limitations are
real, they aren't as severe as you might think. Basic and dynamic disks differ in the number of partitions (on
basic disks) and volumes (on dynamic disks) that each can contain. Basic disks also use the partition tables
stored in the Master Boot Record—MBR—at the beginning of the disk. To make matters even more
confusing, basic disk volumes also include support for multi-disk volumes—such as volume sets, stripe
sets, mirror sets, and stripe sets with parity.
As a Win2K and NT 4.0 administrator, you've used basic disks and probably have had occasion to "get
fancy" by using volume sets, mirror sets, or stripe sets. However, you might have noticed some limitations
with basic disks, such as having to reboot the system after you make changes to the disk configuration.

Dynamic Disks
The limitations of basic disks and other inconveniences drove the creation of a new type of disk definition
for Windows systems—the dynamic disk. When you initialize a physical disk as dynamic, it's called a
dynamic disk and contains dynamic volumes, such as simple volumes, spanned volumes, striped volumes,
mirrored volumes, and RAID 5 volumes. Dynamic disk storage is divided into volumes instead of
partitions. Dynamic storage lets you manage disks and volumes without restarting Windows.
On a basic disk, a partition is a portion of the disk that functions as a physically separate unit. A physical
disk unit can contain any combination of storage types. However, all volumes on the same disk must use
the same storage type. A volume is a storage unit derived from free space on one or more dynamic disks.
You can format both partitions and volumes with a file system and assign a drive letter. Volumes also have
different layouts (e.g., simple volumes, spanned volumes, striped volumes) and characteristics. Basic disks
used to provide different layout types (e.g., spanned, mirrored, RAID 5) with partitions. However, dynamic
disks provide these layouts in dynamic disk volumes. Other dynamic disk limitations include lack of
support for removable storage devices (i.e., IEEE 1394 FireWire- and USB-attached disks) and an irritation
when using Windows Cluster Service.
Dynamic disks introduce the concept of disk groups. Disk groups (collections of disks organized as
entities) help administrators prevent data loss by organizing dynamic disks. All dynamic disks within a disk
group store configuration data for the entire group (this data is stored in a 1MB region at the end of each
dynamic disk). All configuration information for simple, spanned, mirrored, striped, or RAID 5 volumes
within a disk group are stored on each disk in the group. This "database" of configuration information is
replicated and kept up-to-date across all dynamic disks in the group. If you lose a dynamic disk or you
move the disk group to another system, the OS maintains the configuration information for the disk group.
Win2K systems allow only one disk group (Disk Group 0—DG0) per computer. Microsoft will probably
extend this disk-group functionality in future Windows releases.

Volumes and partitions on the system/boot disk should be configured as dynamic wherever possible.

Partition and volume layout

The RAID 1 pair that you have created can now be broken in to a series of volumes for use by the
Operating System and it's various components.
When performing a base install of the OS from CD, you will be prompted to create the Boot/Install
partition on the hard drive. It is considered to be a best practice to set this partition at 10GB. This means
entering a value of 10,240 MB when entering the partition size.
Once the server has completed installation, you can create more partitions on the volume and organize the
content of the OS accordingly. Depending on the size of the drives you are using, you may want to create
one or two more partitions. Be sure to convert the install partition to be dynamic disk instead of basic disk.
This will allow you to grow the partition later if needed. You should plan to leave 20-40% of the total
volume space unpartitioned
Sample Volume Layout
Using an example of two 36GB HDDs configured as a RAID 1 mirrored pair and leaving 36GB of space to
be assigned, here is a sample of layout of how the disk should be broken into volumes.

Partition Size Purpose

1 10GB
2 2-16GB
3 2GB
Free Space 8GB
EFI Boot partition and Windows Server 2000/2003 system disk
Page File Partition - should be set to double the size of the page file
required.
Active Log Files Volume
20% Available for dynamic allocation to the other three volumes in
case the get full

It is important to separate all logs from the system/boot partition. In case of a serious blue screen condition
or corruption on the system volume that requires a rebuild or restore of that partition, you will still have a
preserved set of logs on the other volume. These can then be used for forensic purposes to aid in problem
determination from the previous build. If you want to simplify the configuration in the table above, then
you can merge partition 2&3 together and store your active logs with the extended page file. All other
applications and data should be installed on a separate RAID5 disk array or SAN/NAS volume. After
installing applications, you may want to grow the log space and keep all server and application logs on the
same volume so that they are easier to find or can be collected by log aggregation servers more easily.

Page File configuration

You should change the configuration of your paging files to reduce the space requirement on partition 1

To change the size of the virtual memory paging file

1. Open System in Control Panel.
2. On the Advanced tab, under Performance, click Settings.
3. In the Performance Options dialog box, click the Advanced tab.
4. Under Virtual memory, click Change.
5. Under Drive [Volume Label], click the drive that contains the paging file you want to change.
6. Under Paging file size for selected drive, click Custom size, and type a new paging file size in
megabytes in the Initial size (MB) or Maximum size (MB) box, and then click Set.
If you decrease the size of either the initial or maximum page file settings, you must restart your
computer to see the effects of those changes. Increases typically do not require a restart.

A best practice is to set the page file total size to 1.5 times the amount of RAM on the server. So a server
with 4GB of RAM should have a 6GB page file. Page files will also grow dynamically as needed, so you
should set the partition to double the size of the page file or in this example 12GB.

Blue screen memory dumps typically land on the c: drive or system partition. It is considered a best
practice to make the page file on the system partition the minimum size allowed by the OS - usually the
exact memory size - then set the maximum size to be equal to the minimum. Add a page file to cover the
rest of the page file size requirements on the second partition (likely drive D). This will guarantee space is
available for the memory dumps during a STOP condition and allow the page file to run amok on a separate
partition. Running multiple page files this way may also enhance server performance. So, the minimum
size of the second page file should be set to 50% of the ram size with the maximum being set to the exact
memory size.

Microsoft recommends that you create a paging file for each physical volume on the system. On most
systems, multiple paging files can improve the performance of virtual memory. Thus, instead of a single
large paging file, it's better to have many small ones. Keep in mind that removable drives don't need paging
files.
Moving Log Files
Best Practice is to move the logs off of the system/boot partition to ensure that the files are available in case
of a blue screen or a volume corruption that requires the system partition to be reformatted. Keeping a
drive location where all logs from the OS and other applications can be collected make it easier to
troubleshoot and also provides a single point for log aggregation tools to collect their information.
By default, Event Viewer log files use the .evt extension and are located in the following folder:

%SystemRoot%\System32\Config

To move Event Viewer log files to another location on the hard disk, follow these steps:
1. Click Start, and then click Run.
2. In the Open box, type regedit, and then click OK.
3. Locate and click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog
4. Click the subkey that represents the event log that you want to move, for example, click
Application.
5. In the right pane, double-click File.
6. Type the complete path to the new location (including the log file name) in the Value data box,
and then click OK.

For example, if you want to move the application log (Appevent.evt) to the Eventlogs folder on
the E drive, type e:\eventlogs\appevent.evt.
7. Repeat steps 4 through 6 for each log file that you want to move.
8. Click Exit on the Registry menu.
9. Restart the computer.