P. 1
Windows Disk Partition Design 2

Windows Disk Partition Design 2

|Views: 14|Likes:
Published by jodyg35950

More info:

Published by: jodyg35950 on May 19, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Best Practices for Windows Server 2000/2003 Disk Partitioning and Volume Design

By: Craig Borysowich Chief Technology Architect Imagination Edge Inc.


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 Minimum number of disks Usable storage capacity Fault tolerance

RAID-0 2 100 percent 2

RAID-1 3

RAID-5 4


50 percent

Read performance

None. Losing a single disk causes all data on the volume to be lost. Generally improved by increasing concurrency.

Can lose multiple disks as long as a mirrored pair is not lost. Up to twice as good as JBOD (assuming twice the number of disks). Between 20 percent and 40 percent worse than JBOD for most workloads. • • Operating system Log files

(N-1)/N disks, where N is the number of disks Can tolerate the loss of one disk..

50 percent

Generally improved by increasing concurrency.

Write performance

Generally improved by increasing concurrency. •

Worse unless using full-stripe writes (large requests). • •

Best use

Temporary data only

User and shared data1 Application files2

Can lose multiple disks as long as a mirrored pair is not lost Improved by increasing concurrency and by having multiple sources for each request. Can be as low as 25 percent of JBOD. Can be worse or better depending on request size. • Operating system • User and 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 1 2 3 Free Space Size 10GB 2-16GB 2GB 8GB Purpose 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. Repeat steps 4 through 6 for each log file that you want to move. Click Exit on the Registry menu. Restart the computer.

7. 8. 9.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->