What RAID stripe size should our Dell MD3200i have in a VMware environment?

The most efficient stripe size is going to match the I/O size that VMWare requests.  So if VMWARE reads/writes 1MB at a time, you want to configure the disk so that the RAID controller reads/writes 1MB at a time.

As such, determine how VMWARE is configured, and  go from there.

Do you mean the block size that i have chosen on the VMFS datastore?

any easy way to find out what its requesting otherwise?

thanks

VMware I/O block size just follows the I/O block size of the OSs that are run on it so it's that that matters and that depends on the applications running ontop of those OSs. In general it's impossible to determine because there are many apps and OSs all hitting the same storage so I'd take the defaults.

thats a good point about the defaults. I have been running tests with IOmeter and changing the data sizes that it works with to 8kb seems to produce the highest IO's this is still with the RAID stripe set to its default Segment size of 128kb.
So the work inside of the VM does appear to have a direct affect on the SANs performance.
We are just wondering if VMs themselves are a sequential workload? someone who works for a storage vendor told us that VMDKs are sequential, but how can they be if changing the workload type on IOMeter has such a dramatic effect?
we have quite a lot of SQL servers on windows platforms so i assume the Segment size of 64kb is a safe bet for us, I will continue testing and get back to you.

However we do have some file server VMs so i assume these would be best kept on a larger segment size? perhaps these should stay as the 128kb segment default.


thanks for your input so far.

Not sure what they mean about VMDKs being sequential, it's a file and the contents are sequential but that doesn't mean they are accessed sequentially. If you defrag an Exchange database the file is sequential but reads and writes to it are all over the shop.

Actually VMWARE aggregates I/Os unless you are using the vmdirect pass-through I/O that nails controllers and disks to specific machines.  It has to.   Also file systems block I/Os together for speed and efficiency.  This is done within the operating system and sometimes device drivers themselves.   Andy is correct in that determining the blocking is quite difficult.  The only correct way to do it is run software that you may or may not have that measures it at the physical drive level.

IOMETER does NOT measure what goes to disk drives.  It measures what is sent to the device driver in the local machine. What ends up on the disk drive involves VMWARE settings, device driver settings (within vmware), and within the local machines .. then it is further blocked, reordered, and resized by the RAID controller

VMWARE generates highly RANDOM I/O to/from the storage subsystem, so tuning for IOMETER as andy mentions will often result in much slower overall performance.  Unless  you spend some money buying decent tools to measure what you need, then the best thing you can do is use perfmon on the individual machines and monitor QUEUE depth over time.  This tells you how long on average that particular machine waits per I/O of any size.   The smaller the average queue depth (1 or 2) the better overall performance is.  

Just sample over NORMAL operating situations over time, per machine, and then look at changing file system settings and RAID settings.   It is a universal truth that the most efficient I/O is the one you DON'T do (meaning it is cached inside of the host machine).   So the more things that match, the more efficient.

I.e, if NTFS reads/writes 64KB I/O, and you are doing RAID1 then in perfect world, you want to read/write 64KB per disk at a time.  You will be dealing with I/Os of multiple sizes and different levels, so benchmarking can never nail it for you.  You can spend money hiring a pro to measure I/O at the physical drive and tune the RAID for lowest latency (time to complete an I/O basically) for the I/Os on a weighted average, but even if you do that, then a minor change in file system settings, or adding some cache memory changes everything.

So just take it slow, look at the NTFS I/O sizes and perfmon to see what the O/S is doing and look at latency then in parallel contact your RAID vendor and get some performance metrics based on various I/O sizes and mix of read vs writes vs random vs sequential, then try to get everything optimized for a weighted average.

No simple way to do it right, but the simple way to do it wrong is by artificial benchmarking and making assumptions about I/O performance w/o just taking the time to MEASURE them and learn specifications.

Ok thanks for that reply, just out of interest on the IOMeter bit what about this forum post?

http://communities.vmware.com/docs/DOC-3961

I found it very useful and they are saying IOMeter is a great way of testing VM systems.

thanks

It's useful to note that VMware themselves also use iometer - http://www.vmware.com/files/pdf/performance_char_vmfs_rdm.pdf

Its a bit of an open question so a difficult question to answer, but the feedback i received has helped me to get closer to the answer I need.