Planning the Layout and RAID Level of Volumes

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

When you design a standard hardware configuration, determine what type of data you plan to store on the file server, the RAID type and level that is appropriate for each data type, and how you plan to divide the disk space into volumes.

Evaluating Data Types

Table 2.18 describes the types of data that are typically stored on file servers and the disk I/O characteristics of the data. Knowing the I/O characteristics can help you choose the RAID level that offers the best performance for that particular type of I/O. If you have other types of data stored on the file server, be sure to estimate their I/O characteristics as well.

Table 2.18 Data Types and Their Characteristics

Data Type	Description	Disk I/O Characteristics
Operating system	The operating system, drivers, and any applications installed on the server, such as antivirus, backup, or disk quota software.	Server startup consists mostly of large reads, because the data required for startup is optimized on the disk. After startup completes, the disk I/O is mostly small reads.
Paging space	Space used by the paging file.	If the server memory is sized correctly, the disk I/O consists of small reads and writes. If the server experiences heavy reads and writes, the server needs more memory.
User and shared data	Documents, spreadsheets, graphics, and other data created by users and stored on the file server.	For user and shared data, disk I/O must be measured on a workload-by-workload basis.
Application files	Software that users install or run from the network.	For application files, disk I/O must be measured on a workload-by-workload basis.
Log files	Files used by database, communications, or transaction applications to store a history of operations (for example, the FRS log file).	Small or large writes, depending on the application.

Choosing Between Hardware and Software RAID

Many computer manufacturers provide server-class computers that support hardware-based RAID. With hardware RAID, you use the configuration utility that is provided by the hardware manufacturer to group one or more physical disks into what appears to the operating system as a single disk, sometimes called a virtual disk or logical unit (LUN). When you create the virtual disk, you also select a RAID level. Hardware RAID typically provides a choice of RAID-0 (striped), RAID-1 (mirrored), RAID-5 (striped with parity), and in some servers, RAID-0+1 (mirrored stripe). After creating these virtual disks, you use the Disk Management snap-in or the command-line tool DiskPart.exe in Windows Server 2003 to create one or more volumes on each virtual disk.

If your server hardware does not have built-in hardware RAID support, you can use the software RAID provided in Windows Server 2003 to create RAID-0 volumes, RAID-1 volumes, and RAID-5 volumes on dynamic disks. Although software RAID has lower performance than hardware RAID, software RAID is inexpensive and easy to configure because it has no special hardware requirements other than multiple disks. If cost is more important than performance, software RAID is appropriate. If you plan to use software RAID for write-heavy workloads, use RAID-1, not RAID-5.

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. For more information about basic disks, dynamic disks, software RAID, and disk management, see the Storage Technologies Collection of the Windows Server 2003 Technical Reference (or see the Storage Technologies Collection on the Web at https://www.microsoft.com/reskit).

Choosing the RAID Level

Choosing the RAID level is a trade-off among the following factors:

Cost
Performance
Availability
Reliability

You can determine the best RAID level for your file servers by evaluating the read and write loads of the various data types and then deciding how much you are willing to spend to get the performance, reliability, and availability that your organization requires. Table 2.19 describes four common RAID levels; their relative costs, performance, and availability; and their recommended uses. The performance descriptions in Table 2.19 compare RAID performance to the performance of just a bunch of disks (JBOD) — a term used to describe an array of disks that is not configured using RAID.

Table 2.19 Comparing RAID Levels

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

1 Place user and shared data on RAID-5 volumes only if cost is the overriding factor.

2 Place application files on RAID-5 volumes only if cost is the overriding factor.

When determining the number of disks to compose a virtual disk, keep in mind the following factors:

Performance increases as you add disks.
Mean time between failure (MTBF) decreases as you add disks to RAID-5 or RAID-0 arrays.
RAID-0+1 almost always offers better performance than RAID-1 when you use more than two disks.
Usable storage capacity increases as you add disks, but so does cost.

Using Dynamic Disks with Hardware RAID

Using dynamic disks with hardware RAID can be useful in the following situations:

You want to extend a volume, but the underlying hardware cannot dynamically increase the size of LUNs.
You want to extend a volume, but the hardware has reached its maximum LUN size.

Before converting hardware RAID disks to dynamic disks, review the following restrictions:

You cannot use dynamic disks on cluster storage. However, you can use the command-line tool DiskPart.exe to extend basic volumes on cluster storage. For more information about extending basic volumes, see "Extend a basic volume" in Help and Support Center for Windows Server 2003.
If you plan to use hardware snapshots of dynamic disks, you cannot import the snapshot again on the same server, although you can move the snapshot to other servers.
If you create a software RAID-0 volume across multiple hardware arrays, you cannot extend the RAID-0 later to increase its size. If you anticipate needing to extend the volume, create a spanned volume instead.

For more information about dynamic disks, see the Storage Technologies Collection of the Windows Server 2003 Technical Reference (or see the Storage Technologies Collection on the Web at https://www.microsoft.com/reskit). For best practices on using dynamic disks, see article Q329707, "Best Practices for Using Dynamic Disks on Windows 2000-Based Computers," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources.

Choosing the Cluster Size

A cluster (or allocation unit) is the smallest amount of disk space that can be allocated to hold a file. NTFS uses 4-KB clusters for volumes over 2 GB. Using a 4-KB cluster size allows you to use NTFS compression on the volume. However, in some cases you might want to use a larger cluster size to optimize NTFS performance.

To determine the cluster size, evaluate the types of files to be stored on the volume so that you can determine whether to use the default 4-KB cluster size. Some important questions to answer include the following:

Are the files typically the same size?
Are the files smaller than the default cluster size?
Do the files remain the same size or grow larger?

If the files are typically smaller than the default cluster size (for example, 4 KB) and do not increase, use the default cluster size to reduce wasted disk space. However, smaller clusters can increase fragmentation, especially when files grow to fill more than one cluster. Therefore, plan to adjust the cluster size accordingly when you format the volume. If the files you store tend to be large or increase in size, and you do not want to use NTFS compression, use 16-KB or 32-KB clusters to optimize performance.

Important

If you plan to defragment volumes on which shadow copies are enabled, it is recommended that you use a cluster size of 16 KB or larger. If you do not, the number of changes caused by defragmentation can cause shadow copies to be deleted faster than expected. Note, however, that NTFS compression is supported only if the cluster size is 4 KB or smaller. For more information about shadow copies, see "Designing a Shadow Copy Strategy" later in this chapter.

Determining the Volume Layout

When you determine the volume layout, you evaluate the type of data to be stored and the number of volumes that you want to create. For better manageability, use separate volumes for each data type where possible, though the operating system and paging file are often placed on a single volume. For example, use one volume for the operating system and paging file and one or more volumes for shared user data, applications, and log files.

If performance is important, place different data types in separate volumes on different virtual disks. Using separate virtual disks is especially important for any data types that create heavy write loads, such as log files. For example, dedicate a single set of disks (composing a virtual disk) to handling the disk I/O created by the updates to the log file. Placing the paging file on a separate virtual disk can provide some minor improvements in performance, but not typically enough to make it worth the extra cost.

To gain some performance benefits while minimizing cost, it is often useful to combine different data types in one or more volumes on the same virtual disks. A common method is to store the operating system and paging file on one virtual disk and the user data, applications, and log files in one or more volumes on the remaining virtual disk.