Exchange Server can benefit from having basic disk partitions track-aligned. Diskpar.exe is used for aligning a partition at the storage level, which, if used to create the partition, can have a significant positive performance impact on the storage and is highly recommended. Before I go into the details of how to do this, I’ll give some basic definitions. A partition is the container you create on an initialized disk to format and then use. Multiple partitions can be created on a single physical disk, and each partition will function as a separate disk (even though the partition will appear to be a separate disk, the total throughput of the physical disk is unchanged – so if you make two partitions on each disk and use them equally, they will each effectively only have half the available i/o rate. This is important to keep in mind for capacity planning). A sector is the smallest accessible unit on a physical disk, with multiple sectors comprising a track. A partition that is track misaligned will occasionally cause 2 I/O operations instead of one depending on the actual drive geometry.
Even though some storage obfuscates sectors & tracks, using diskpar will still help by preventing misalignment in cache, or wasted cache. If the disk is not aligned, every Nth (usually 8th) read or write crosses a boundary, and the physical disk must perform two operations. At the beginning of all disks is a section reserved for the master boot record (MBR) consuming 63 sectors. This means that your partition will start on the 64th sector, misaligning the entire partition. Most vendors suggest a 64-sector starting offset, meaning that your partition starts on the 65th sector vs the standard 64th. Check with your particular vendor before standardizing this setting on a particular storage array. The key is to have it aligned on a 4 KB boundary from the start of the disk, of which choosing 64 sectors is 32 KB, and aligned. (64 * 512 bytes per sector = 32,768 bytes)
It is important to differentiate the sector alignment, with file level fragmentation and allocation unit size. Most Exchange Server I/O is random 4 KB read & write to the database .edb file. We don’t notice a huge statistical difference in normal file fragmentation on a database LUN. Since Exchange best practice is to place all database files in a storage group on the same LUN, as they grow, they will fragment each other pretty severely. I have only heard of one case where serious file-level fragmentation impacted Exchange, and that was when a customer ran a 3rd party application on the same partition as the database files, and it created/deleted millions of very small files in a day. If you dismount the databases, and perform an disk-level defrag, against each database LUN, you will eradicate the file level fragmentation. It is not recommended to have any other files on the exchange database or log partitions (it is especially important not to share the log partitions with other programs, since log access to the drive is sequential, and random access to the drives hosting the drive will significantly reduce the performance.)
Exchange accesses the database file (edb) in random 4 KB read/write, which is, by default, the allocation unit size on the partition. The default allocation unit size of 4 KB, which can be set at partition format, is the best practice. If you use the default allocation unit size of 4096 bytes and have a starting offset that is a multiple of 4096 bytes, then your partition will always align on a 4 KB boundary. Setting the allocation size to be larger than 4 KB will disable NTFS compression [Exchange log and database files should always be uncompressed], and is useful in rare streaming backup solutions of extremely large databases where a larger allocation unit size will increase backup speed.
Diskpar:
You have 2 switches, (i)nfo, and (s)et, and a parameter. The parameter which you must add is the disk number. This is discernable in disk manager (diskmgmt.msc)
1) First I query the disk and notice that the starting offset is 32256 bytes, which is not aligned.
C:\>diskpar -i 2
---- Drive 2 Geometry Infomation ----
Cylinders = 13056
TracksPerCylinder = 255
SectorsPerTrack = 63
BytesPerSector = 512
DiskSize = 107389255680 (Bytes) = 102414 (MB)
---- Drive Partition 0 Infomation ----
StatringOffset = 32256
PartitionLength = 107380998144
HiddenSectors = 63
PartitionNumber = 1
PartitionType = 7
2) Notice 32256 / 4096 = 7.875 , which is not an integer. We want to change this to improve performance.
3) Now I set it to 64 sectors, and select the full available partition size.
C:\>diskpar –s 2 (yes, it’s really this easy)
---- New Partition information ----
StatringOffset = 32768
PartitionLength = 107388862464
HiddenSectors = 64
PartitionNumber = 1
PartitionType = 7
4) Now we get 32768 / 4096 = 8. Yeah!
5) Now open up disk manager and format the drive.
Diskpart:
In Windows 2003 SP1, diskpart.exe has included diskpar.exe functionality. The main difference is that diskpar creates a partition in sectors (512byte), and diskpart uses kilobytes. In the example below we take a disk w/o any partitions and create it with the same starting offset of 32768 as the above diskpar.exe example.
C:\>diskpart
Microsoft DiskPart version 5.2.3790.1830
Copyright (C) 1999-2001 Microsoft Corporation.
On computer: Exchange2003
DISKPART> select disk 1
Disk 1 is now the selected disk.
DISKPART> create partition primary align=32
DiskPart succeeded in creating the specified partition.
Resources:
Microsoft:
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/r...
http://www.microsoft.com/resources/documentation/windows/2000/professional/reskit/en-us/part6/proch3...
3rd Party:
http://h71019.www7.hp.com/ActiveAnswers/downloads/Exchange2003EVA5000PerformanceWhitePaper.doc
http://www.emc.com/pdf/techlib/exchange_2000_symmetrix.pdf
- Robert Quimbey
