One of the things I do most frequently when it comes to storage solutions is make sure that a client understands their performance needs. There are really only two factors in disk performance:

• How long it takes for the disk to be read from or written to (measured in IOPS), and
• How long it takes for an amount of data to get from the initiator to the target (measurement of bandwidth, typically Gb/s)

Notice that there’s nothing about Fibre Channel vs iSCSI vs FCoE in there. People often make the mistake of generalizing performance, with the solid misconception that Fibre Channel is higher performing that iSCSI – it’s simply not true. You might argue that the second factor in performance is where Fibre Channel wins. Thanks to iSCSI’s redirect feature and MPIO capabilities, one was as fast as another. Now that 10Gb Ethernet is prevalent in most iSCSI vendors’ products, iSCSI has the leg up. I digress…

Let’s talk about the first factor:

IOPS and What It Really Means

IOPS, or Input/Output Per Second, is made up of two components on all disks but solid state. Those are the spindle speed and the time it takes for the head to move over the target track – the seek time. You can see based off of that information that disk types of the same spindle speed are going to be in the same performance category. Think that for each single disk, you might have this kind of performance:

• 7200 RPM Drives – 80 IOPS
• 10,000 RPM Drives – 120-130 IOPS
• 15,000 RPM Drives – 160-180 IOPS

if you have multiple disks, you can perform some nifty calculations to determine your IOPS rather easily. Accurate calculations are dependent on knowing what percentage of the time you read, and what percentage of the time you write. Have a look at Scott Lowe’s article about IOPS to learn about those calculations: http://blogs.techrepublic.com.com/datacenter/?p=2182

Also, keep in mind that caching plays an important part of an IOPS situation – if there is frequently accessed data, or data that needs to be quickly written to disk in small bursts, caching is a life saver. In almost every situation, more cache is more performance.

Bandwidth and Why It Doesn’t Matter

Whoah! Don’t get on to me for making such a bold statement – of course bandwidth matters… erm… sometimes. In every situation I have analyzed, the bandwidth requirements have been amazingly low – a small percentage of one Gb per second. Modern technologies (and even outdated ones) allow for much greater than that. In every situation I have analyzed after implementing a SAN solution, the real performance data backs up the initial analysis. Because the systems that I work with have tens to hundreds of times the bandwidth that their applications require, I rarely concern myself with the bandwidth aspect of a storage system – at least for the “Quick and Dirty” method.

Sizing Storage – the Quick and Dirty Way

This is why you’re here anyway, isn’t it? Looking for a storage solution for your existing environment? Looking for something for an environment you are planning? Follow these steps:

1. Sum the storage requirements – if you have 100GB used on each of six servers, you need 600GB of space usable.
2. Sum the spindle speeds – if you have six 10,000 RPM disks and 2 15,000 RPM disks, you’d have a total of 90,000 RPM in the system. Because IOPS between spindle speeds are proportionate to the spindle speed itself, this gives us a good starting point.
3. Look at your total RPM and divide it by each of your disk options. For instance, taking the 90,000 RPM number above, I know I would need 13 7200 RPM disks, 9 10,000 RPM disks, or 6 15,000 RPM disks to perform the same as the original system.
4. IMPORTANT: Do a sanity check. If you have eight low traffic web servers each with two 15k disks, you do not necessarily need 16 15k disks… experience tells me you may even be able to get away with a very small number of SATA disks.

If your environment is more advanced, I recommend gathering real performance information from your systems, aggregating that, and analyzing it for the numbers you need. Want help? Get me on twitter – http://twitter.com/bradfair, email me at brad.fair@interworks.com, or give me a call at 405-624-3214.