I agree that perhaps I was generalising a little; I was looking at worst case from the pure disk level. You’re right that the array architecture needs to be taken into consideration too, including RAID calculations. I’ll add this as a subject for a future post.

Chris

“For a RAID group of RAID-5 3+1 fibre channel drives, data will be spread across all 4 drives, so this RAID group has a potential worst case I/O throughput of 740 IOPS.”

This does not take into account the overhead of RAID (For instance RAID 05 has a 3-1 penalty on writes). If a customer is only looking at their workload and the ability of the disks in their disk system, they could be gravely mistaken in their design.

For example, the table below shows what HP calls safe IOPS in an EVA system based on drive types:

Found at : http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01671044

Drive Type Vraid type Per Drive Host IOPS
15K Fiber Channel VRAID-1 115 VRAID-5 73
10K Fiber Channel VRAID-1 83 VRAID-5 53
250GB FATA VRAID-1 62 VRAID-5 39
400/500GB FATA VRAID-1 42 VRAID-5 26
1000GB FATA VRAID-1 54 VRAID-5 34

This table states that in a raided config drives perform at half or even a third of their actual capability. I have tested other arrays in the same range as an EVA which perform 2X-3X as many IOPS as an EVA in various raided configurations. IMO understanding the capabilities of the array you are using is more important than understanding the RAW IOPS a disk in a non-raided configuration can produce by itself.

I’v very new to storage architecting and I’m very thankful for people like youself who share the knowledge. Anyhow, I have a quick question on the equation to find out the total I/O on the 15k drive. Where did you get 1000, in the equation 1000/5.4 = 185iops?

Thanks,
morjo

Agreed, there’s an issue of workload mix which can cause problems. What your comments also demonstrate is the requirement to be continually monitoring performance and adjusting the mix of tiers and data location. This can be costly and time consuming, but is necessary in large mixed multi-host environments,

Chris

More than you post depending on workload and other things. But in general more.

A quick google reveals things like this:

270 IOPs per FC drive

tagged command queuing allows you to push them that hard. Of course response time tails off and that would be punishing to drive them that hard if interactive use was the norm.

Secondly, as mentioned, what about usage? What if the DBAs did a normal morning import of data and the array is getting hammered with large IOs for a time? Writes and transfer time for the larger IOs come into play so maybe that 185 IOPS you are quoting is too generous.

“With smaller drives, data has to be spread across more spindles, increasing the available bandwidth.”

Not sure drive size comes into play unless your “Enterprise array” is feature-poor. Barry suggests you can front-end with SVC. You can carve and migrate to meta-LUNs touching more arrays in a clariion. You could carve your LUNs out of a 100 disk pool in an EVA. Or (duck) try an XIV and furgetaboutit. Point not to be overlooked is LUN management can overcome IO issues and future-bound a number of vendors will be working with 1MB “partitions” and side-stepping LUN management pain.

I do a lot of work in storage sizing for VMware deployments and it remains one of the fuzziest parts of the project. Anything we can do to normalize this is a step in the right direction.

Cheers!

Thanks for the comments. Barry, I agree with your comments on service. I don't like the terms tier 1/2/3; your medal comparison suits better – and what a great lead in to advertise SVC!

James, I guess what I was meaning was that I don't see enough of a differentiator between 146 & 300GB 15K drives to call them separate tiers. I think performance is the usual tier 1/2 consideration, so drives of the same performance aren't going to meet that requirement.

rwhiffen, thanks for the words of support!