I’m preparing to migrate our Netware 6.5/Groupwise 6.5 servers to Windows 2003 R2 SP2/Groupwise 7.0.3, with the Groupwise data located on an EMC Clariion SAN with 4GB fibre channel connectivity. The Groupwise agents will run locally on the server’s direct attached storage.
Perfomance test – Windows Server 2003 R2 partition alignment on an EMC SAN
Lately I’ve read much about the little known requirement that Windows machines partitions be aligned on a 4KB boundary to minimize the need for extra reads and writes. Here are some excellent posts that explain the details better than I could. Here are some links on using DiskPart.exe to configure the partition offset, which affects performance greatly, as you will soon see.
I’ve had great difficulty in finding guidance as to the appropriate offset to use with Groupwise. I’ve found articles suggesting Microsoft Exchange use and offset of 32 or 64, while the Clariion Blog suggests offsets of 128 and this EMC best practices white paper says the same.
I setup a test environment consisting of one Dell PowerEdge 1950 Windows 2003 R2 SP2 server, connected to our EMC Clariion SAN via a standard 4GB QLogic Fibre Channel adapter. The Windows installation was nothing special, installed to local storage with the only modifications to the default installation I made was to assign a static IP address. I did disable the Windows firewall and disabled it’s service as well to make sure there was no potential interference by it in my tests.
My SAN administrator carved me out a 20GB LUN for me to test with, and I used the entire 20GB when creating my test paritions. I used HD Tune version 2.55 to perform the hard drive read tests detailed below because I could granularly specify the block size when testing. I’ll need to find another utility to perform the write tests, but that’s for another post. Why use HD Tune and not some SAN specific testing utility? Because I hope to perform similar tests on direct attached storage, and wanted a tool that supported both so I could do some comparisons.
To determine the average size of files in my Groupwise post offices I ran an inventory report in Novell’s Remote Manager on the Groupwise Post Office directory. Each of my 5 post offices came back with a file distribution similar to the graph shown below:
As you can see, the majority of files within the Post Office are 1KB to 256KB in size. Because of this finding, I decided to focus on block sizes of 4KB, 8KB, 16KB, 64KB, and 256KB in my initial tests. Later I expanded the test to 1MB and 4MB files just to ensure I saw similar results with the larger file sizes.
To create my baseline, I used Microsoft’s Disk Management utility to create a new partition of 20GB on a basic disk. I accepted all default settings, then performed a quick NTFS format. Next, I installed the HD Tune utility to the server’s boot drive and started my tests.
The first item I had to configure was to select my LUN, rather than the boot drive as the device to test. The LUN is shown as DGC RAID 5 (21GB) in the below image.
Next I selected the options button
and on the benchmark tab I changed the block size to 4KB. I kept the Test Speed/Accuracy slider at the default level, which prioritized accuracy over speed.
Next I pressed start to begin the test. The test took approximately 4.5 minutes to perform on my test box and returned the following results.
I performed the test for the following block sizes 4KB, 8KB, 16KB, 64KB, 256KB, 1MB, and 4MB to develop my baseline readings. I then rebooted the server, and began to create my new partition using the Microsoft DiskPart.exe tool.
The steps I performed were
1) from a command prompt, run diskpart.exe
2) select disk 2
3) create partition primary align=32
4) exit diskpart
5) format the partition using defaults in Disk Management GUI
Once the format was completed, I ran the HD Tune benchmarks for block sizes 4KB, 8KB, 16KB, 64KB, 256KB, 1MB, and 4MB, and documented them on a spreadsheet.
After this round of tests completed, I deleted the test partition, restarted the server, then repartitioned using create partition primary align=64.
After that test finished I also performed the same batch of tests using the same methodology for create partition primary align=128 and create partition primary align=1024.
My test results:
Post Test General Conclusions
1) CPU utilization is minimally affected by the default partition alignment setting.
2) The rate of data transfer when reading can be greatly increased for 4KB and 8 KB sized blocks by modifying the default partition alignment setting
3) 256KB blocks seem to be minimally affected by any of the partition alignment settings
4) All of the tested settings showed improvements in the Xfer Max MB/s over the default settings
5) Read access times decrease for small files (4KB, 8KB) and larger files (1MB, 4MB) when compared to default settings. This is a good thing.
My plan of action – to follow EMC’s recommendation, which is to use a starting block of 128 to align the partition to the 64KB boundary. If your storage vendor makes no specific recommendation, use a starting block that is a multiple of 8KB.
Note: For Microsoft Windows 2008, as long as you formatted the disk using the Windows 2008 operating sytem, the disk requires no further alignment actions.