How to do rough Storage Array IOPS estimates

This post is dedicated to trying to get around the mistery factor that Cache and Storage Array algorithms have, and helping you calculating how many disks you should have inside your Storage Array to produce a stable average number of disk operations per second – IOPS.

Face it, it is very hard to estimate performance – more specifically IOPS. Though throughput may be high in sequential patterns, Storage Array face a different challenge when it comes to random IOPS. And from my personal experience, Array-vendor Sales people tend to be over-optimistic when it comes to the maximum IOPS their Array can produce. And even though their Array might actually be able to achieve a certain high maximum value of IOPS with 8KB blocks, that does not mean you will in your environment.

Why IOPS matter

A lot of factors can affect your Storage Array performance. The first typical factor are the very random traffic and high output patterns of databases. It is no wonder  this is the usual first use-case for SSD. Online Transaction Processing (OLTP) workloads, which by having verified writes (write and read back the data) double IOPS, and since it has a high speed demand, can be source of stress for Arrays.

Server Virtualization is also a big contender, which produces the “IO blender effect“. Finally Exchange is also a mainstream contender for high IOPS, though the architecture since Microsoft version 2010 changed the paradigm for storing data in Arrays.

These are just some simple and common of the many examples where IOPS can be even more critical than throughput. This is where your disk count can become a critical factor, and to the rescue when that terabyte of Storage Array cache is lost and desperately crying out for help.

Monkey-math 

So here are some very simplistic grocery-style type of math, which can be very useful to quickly estimate how disks you need in that new EMC/NetApp/Hitachi/HP/… Array.

First of all IOPS variate according to the disk technology you use. So in terms of Back-end these are the average numbers I consider:

  • SSD – 2500 IOPS
  • 15k HDD – 200 IOPS
  • 10k HDD – 150 IOPS
  • 7.2k HDD – 75 IOPS

Total Front-End IOPS = C + B , where:

C stands for total number of successful Cache Hit IOPS on reads, and B for total IOPS you can extract from your disk backend (reads + writes). Their formula is:

C = %Cache-hit * %Read-pattern

B = (Theoretical Raw Sum of Back-end Disk IOPS) * %Read-pattern + (Theoretical Raw Sum of Back-end Disk IOPS)/(RAID-factor) * %Write-pattern

C is the big exclamation mark on every array. It depends essentially on the amount of Cache the Array has, on the efficiency of its Algorithms and code, and in some cases such as in EMC VNX the usage of helping technologies such as FAST Cache. This is where your biggest margin of error lies. I personally use values between 10% up to 50% maximum efficiency, which is quite a big difference, I know.

As for B, you have to take into consideration the penalty that RAID introduces:

  • RAID 10 has a 2 IO front-end penalty: for every write operation you will have one additional Write for data copy. Thus you have to halve all Back-End IOPS, in order to have the true Front-End IOPS
  • RAID 5 has a 4 IO back-end penalty: for every write operation, you have 2 reads (read old data + parity) plus 2 writes (new data and parity)
  • RAID 6 has a 6 IO Back-ned penalty: for every write operation, you have 3 reads (read old data + parity) plus 3 writes (new data and parity)

Say I was offered a mid-range array with two Controllers, and I want to have about 20.000 of IOPS out of 15k SAS HDD. How many disks would I need?

First the assumptions:

  • About 30% of average cache-hit success on reads (which means 70% of reads will go Back-end)
  • Using RAID 5
  • Using 15k HDD, so about 200 IOPS per disk
  • 60/40 % of Read/Write pattern

Out of these 20.000 total Front-End IOPS, Cache-hit percentage will be:

C = 20.000* %Read * %Cache-hit = 20.000 * 0,6 * 0,3 = 3.600

Theoretical Raw Sum of Back-end Disk IOPS = N * 200

Thus, to arrive at the total number of disks needed:

20.000 – 3.600 = (N*200)*0,6*0,7 + (N*200/4) *0,4

Thus N = 157.7 Disks.

So about 158 disks.

 

Hope this helped.

Advertisements

3 thoughts on “How to do rough Storage Array IOPS estimates

  1. Nice article and like how you put some “context” around the drive rough estimates of IOPs (e.g. Monkey Math).

    Can we get a side of context with them IOPS and other storage metrics
    http://storageioblog.com/side-context-iops/

    Here is a post:

    Part II: How many IOPS can a HDD, HHDD or SSD do with VMware?
    http://storageioblog.com/part-ii-iops-hdd-hhdd-ssd/

    Part of an ongoing series about storage performance including measured IOPs across different types/classes of drives (SSD, HDD, HHDDs) doing various workloads (reads, writes, random, sequential, large, small) IO along with their bandwidth and latency. Thus the monkey math is a general rule of thumb, even the RPM speed of drives can vary today. For example there are some 10K RPM 2.5″ drives that can do the same or more IOPs as previous generation of 3.5″ 15K HDDs.

    Also regarding the RAID math, will also assume that is “monkey math” which is a worse case or what might occur with some implementations. However some implementations of RAID 5 (among others) may not do those extra IOs that are being portrayed as reality in all cases.Good RAID 5 (and others) implementations do not always have to do those extra IO operations that some people talk about. For example a robust RAID 5 (or 6 or 7 or etc) will do write caching (mirrored and battery back-up (BBU) in DRAM, grouping the writes so that an entire stripe can be written along with associated parity updates.

    Some of these RAID implementations also have data integrity safeguards to timeout and do the smaller or less than full stripe write and parity update if full cache line can not be written in time (e.g. write gathering). On the read side there is also read ahead to fetch a cache/stripe line and some multiple of the stripe chunk (or shard) size. Keep in mind that HDDs often have anywhere from a couple MB to up to 64MB of DRAM that helps with read ahead and pre-fetch to help populate the RAID cache lines, and Granted for a worse case scenario, better to have the extra performance of estimating for the worse case vs. underestimating, after all, not all RAID implementations are the same, however some have much less overhead vs. others.

    Cheers gs
    @storageio

    1. Totally agree with your arguments Greg. The numbers for HDD performance given as an assumption do vary, along with (and especially) RAID calculations. As stated in the title of the Post, it is intended to be a simple rough calculation, that hopefully already allows for some insight on the Interval that one might more less expect. I have seen a lot of cases of customers buying the story of fantastic/impossible IOPS sizings from Storage Array providers, so my aim was to provide a very simplistic calculation method.
      Thanks for your comment.
      Cheers,
      Diogo

  2. No worries Diogo and your arguments make good point to help put some context and balance between some of the hype, and fud being tossed around by vendors or their pundits/surrogates. There are also a lot of old Rules of Thumb (RUT) floating around that can lead to both under, or over provisioning not to mention some of the calculators or sizing tools that rely on those old or dated RUTs can result in garbage in and garbage out results.

    Hence there is a place for estimating, calculating, modeling storage performance and capacity as part of planning, there is also using metrics or measurements to refine those estimates. For example measure your current application or workload, profile and characterize them, use those insights as part of the planning. This also ties to looking beyond vendor claims of IOPs, bandwidth or other metrics that matter without context. If you are doing or supporting email such as Exchange, than a trip to the Microsoft ESRP site is in order vs. say to the Storage Performance Council (SPC) site to see how different systems behave among other options.

    Cheers gs
    @storageio

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s