1

I am trying to understand the optimal number of disks required in a RAID configuration for an application which has been monitored, at peak time, to have the following IOPS.

The disk subsystem is split in to data on RAID 10, tempdb on RAID 1 and logs on RAID1 or RAID10.

I am using the standard calculation to calculate number of disks required

                         Reads fraction + (Write Penalty * Write Fraction)

Number of disks required = ----------------------------------------------------- Single Drive IOPS

It works out as follows with a drive IOPS of 120 :

Data disk

RAID 10

IOPS 240 98% writes 2% reads

Minimal disks required assuming 240 IOPS = 4 Ideal disks required assuming 500 IOPS = 8

TempDB

RAID 1 or RAID 10

IOPS 1.4 49% writes 51% reads Minimal disks assuming 1.4 IOPS = 2 Ideal disks required assuming 3 IOPS = 4

Log Files

RAID 1

IOPS 600 100% writes 0% reads

Minimal disks assuming 600 IOPS = 10 Ideal assuming 1200 IOPS = 20

My question is does this seem correct as per the calculations and how do people implement this kind of setup in the real world. The disk requirement for logs seems huge and overall the ideal implementation would required 32 disks. Would someone realistically buy a server with 32 disks or would some kind of SAN setup be used?

Thanks in advance for any help you can give and sorry for the n00b questions. Any corrections in my assumptions are very much appreciated.

2 Answers 2

2

Let me preface this by saying that raw IOPS numbers on disks can be misleading. The numbers for IOPS are random seeks; if your load is 98% write then there's very little chance it's not a little bit sequential, and your log disks will definitely be less seeky. Sequential writes will be faster than the random-seek numbers will lead you to believe.

That said: not sure about the middle set, it's just 1.4 IOPS vs 3 IOPS? That's very low load, and wouldn't require more disk; is that a typo?

The reason the numbers got so brutal on the last set is the full-write load. In a RAID 1 config, each write has to happen, in full, on every disk. You can't theoretically achieve higher write speed than a single disk in a RAID 1 config, so a 600 IOPS random write load on 120 IOPS disk will bottleneck at the storage. A read will be blindingly fast, but a write is single-disk speed. If a single disk doesn't write fast enough, you need a RAID mode that spreads out the writes.

Now, as far as implementation:

  1. Use RAID 10, and even RAID 0, for write-heavy loads; that's where you'll really see gains in your calculations.
  2. Solid-state disks have big advantages if your load is really seek heavy.
  3. Depending on your hardware, something parity based like RAID 5 (or 5+0?) may be warranted. Don't over-do it with RAID 10 when you don't need to!
6
  • Not a typo, just that this app doesn't depend heavily on tempdb thankfully. I guess the tempdb array could even be raid 0 as it doesn't need redundancy.
    – user63655
    Mar 31, 2011 at 2:26
  • So what would be the best layout for the log files array which is massively write heavy - RAID 10? The main thing that strikes me is the large number of disks required for optimal performance. Do I really need 20 disks? I'm guessing most servers don't come with so many spaces for disks and a SAN would be the only normal way to implement this.
    – user63655
    Mar 31, 2011 at 2:29
  • But those writes are mostly sequential for logs; recalculate based on the log files' data rate against the sequential write rate of the disks. A write-spreading geometry such as RAID 0, 5, 6, 10, 5+0.. all of these would be good potential choices for logs. (parity modes (5 and 6) only make sense your raid controller has a battery-backed write cache and dedicated parity XOR processor) Mar 31, 2011 at 2:34
  • I specced out a supermicro box with 30 ish 15k SAS disks in it for under 20k a few weeks ago - so the spindles are there. I've personally worked with web apps using 24 disks to back their databases. It can happen, and it can happen fast.
    – tsykoduk
    Mar 31, 2011 at 4:01
  • Wouldn't putting tempdb on raid0 lead to query failures (at best) if one of the disks failed. Things like large sorts, and temporary tables would disappear?
    – Ewan Leith
    Mar 31, 2011 at 8:27
0

Taking your last question first, if you're looking at buying 30+ disks, you're probably better off in the long-run if you buy an external disk array. It doesn't need to be a full on fibre-channel or iSCSI SAN, a simple SAS enclosure will deliver the spindles and a chunk of cache in a hardware raid.

The figures seem about right, though if you're using 15K RPM SAS drives, you'd expect them to get about 150 IOPS each.

One thing you've not talked about is capacity, so I assume the database is relatively small? In which case, it's definitely worth looking at SSDs instead of regular disk. Each SSD can replace 10 or more disks.

In the UK a 250GB SSD from Crucial will cost around £320 + taxes. NewEgg are selling the same drive for $500. Stick 4 or 6 of these in a RAID10 array inside a normal server, and forget about the need to split out your tempdb, log files, and data.

1
  • Thanks Ewan. That makes sense. So you could spend 2000 for a RAID 10 and the IOPS would be so high with SSD that you wouldn't even need to split out the disks. Sounds good.
    – user63655
    Apr 1, 2011 at 0:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .