When you run IOmeter and select a disk, that disk on the array is one device (at least if this is a Block configurations - the LUN which is in a Pool) and the IOPS (187.82) is what the LUN can handle, not the individual physical disks under the LUN that make up the Pool. For FILE it's a bit different as File takes a LUN(s) and creates a file system on the array and then presents that to a host as a device (I think this is correct - I'm not a File person). That File system may behave differently than a LUN on the Block side.
If you have 8 physical disks in the Pool using Raid 6, then you have a 6+2 configuration. Each individual disk can handle about 80 IOPS. So the total Pool can handle about 8 (disks) * 80 IOPS = 640 IOPS for the Pool. The 80 IOPS is based on a small block (less than 32KB IO Size), random IO (combination of Reads and Writes 70/30) workload. If you increase the IO Size, then IOPS will be less, but Bandwidth increases. Check page 115 in the "EMC Unified Storage Best Practices for Performance and Availability - Common Platform and Block Storage 31.5 — Applied Best Practices.pd" document that I attached in my last post.
About 80 IOPS per disk so your first calculation is correct: 80 * 8 = 640 IOPS
About 8MB/s per disk: 8 * 8 = 64MB/s for the raid group.
Both of these calculations are dependent on the IO size and the IO Type (reads or writes) and pattern (random or sequential).
You might try IOmeter for testing from the host. On the array you need to enable Data Logging. Set the Archive Interval to 60 seconds, Enable Periodic Archiving, set Stop After to 1 day, then Start Data Logging. When Data Logging is running you must collect at least 10 data points before a archive can be created. That means you must let Data Logging run for a minimum of 11 minutes (each data poll is one minute).
Set you test to run for at least 30 minutes, then stop test, then Stop Data Logging. A new Archive will be created when you stop Data Logging and will contain the data points from that point back 2.6 hours or to when you started the test.
The FAQ for IOmeter explains how to run it. If you want to test for Throughput you would use a small block IO Size - say 4KB or 8KB size. If you want to test for Bandwidth you would use a larger IO Size - say 32KB or 64KB. You start with 100% Sequential Reads or 100% Sequential Writes, then try 100% Random Reads or 100% Random Writes. Generally 100% Sequential Writes should be the fastest. followed by 100% Random Writes, then 100% Sequential Reads and last 100% Random Reads.
You can also set the Queued IO's to get better performance - I've found that 10 queued IO's seems to provide the best results. You can also set more users (each "User" is a thread) as multiple threads leads to better performance. Try a single User first, then add more to see what you get.
In IOmeter it will show the response times while running - you can set the "update" rate to 1 second for the fastest rate. IOmeter will just send out IO as fast as it can, it does not bother with what the response times are, just how fast it can transmit data. so at the fastest rate the latency should be high.
What this will show is the raw performance of the array and the raid group that you will be using. This will also show the effect of the pre-fetching for the 100% Sequential Reads. The Writes will show the effects of the amount of Write cache configured on the array. You want to use a "Maximum Disk Size" to a size (in sectors) that is greater than the size of the Write cache otherwise the Write tests can run in the Write cache and not really test the underlying disks (the write cache flush to disk when Write cache gets full). If your Write cache is 8GB, then the size of test file should be 2x that size (16GB). In IOmeter you would set the "Maximum Disk Size" to 64,000,000 sectors. This will create a 32GB file on the LUN under test. Not sure how you do this on the File side of the array though. I've only run this on the Block side with a host connected to the Block and not the File side.
The interpretation of the results is pretty much up to you. The values for IOPs (IO per second) and Response Times are what you're looking for. IOPS is what the array is providing for the configuration that you use in the test (the Pool or raid group and the LUN). Response Times are the average of all the IO's sent to the array and how fast the array is responding to each IO sent to it.
kelleg
6 Operator
•
4537 Posts
2098
0
Posted June 24th, 2015 08:00
When you run IOmeter and select a disk, that disk on the array is one device (at least if this is a Block configurations - the LUN which is in a Pool) and the IOPS (187.82) is what the LUN can handle, not the individual physical disks under the LUN that make up the Pool. For FILE it's a bit different as File takes a LUN(s) and creates a file system on the array and then presents that to a host as a device (I think this is correct - I'm not a File person). That File system may behave differently than a LUN on the Block side.
If you have 8 physical disks in the Pool using Raid 6, then you have a 6+2 configuration. Each individual disk can handle about 80 IOPS. So the total Pool can handle about 8 (disks) * 80 IOPS = 640 IOPS for the Pool. The 80 IOPS is based on a small block (less than 32KB IO Size), random IO (combination of Reads and Writes 70/30) workload. If you increase the IO Size, then IOPS will be less, but Bandwidth increases. Check page 115 in the "EMC Unified Storage Best Practices for Performance and Availability - Common Platform and Block Storage 31.5 — Applied Best Practices.pd" document that I attached in my last post.
glen