Storage arrays/RAID configurations

  • Before I start, I want to say that I've done some poking around here and found a few threads that have been helpful but they're quite old, so I didn't want to bump them in case that's not done here, hence the new thread.

    I've also read the chapter on Disk I/O Configuration in The Accidental DBA[/url], so I think I'm getting there, but I don't have anybody in real life I can check things like this with so I'd appreciate any help if it's going please. I apologise in advance if the questions sound stupid- I am doing my best to do as much as possible myself.

    So, I have a physical server that needs more space on two particular drives, E which has the log on it, and G which has the mdf and ndf files on it. I have been told the following by a sysadmin:

    The server is currently configured as six drives in three RAID1 pairs - so if the G and E drives need to be expanded, we need to either add four drives (two pairs) or add two additional drives and convert the existing RAID sets to RAID5

    The thread and the ebook both suggest that the log should be on RAID1 (if it's a single log, which it is) and the rest should be on RAID5. Does this sound right?

    (This is a fairly low-transaction database with many more reads than writes. Also, money is fairly tight here, so RAID10 is not an option :-P.)

    Thank you!

  • I prefer R1 or R10, though I certainly understand economics.

    If you convert to r5, and that might work fine for your workload, I wouldn't add 2 drives, I'd add 3 and have a hot spare. If R5 fails, and you have multiple drives from the same vendor/batch/generation, it is entirely possible you lose another one in short order. I'd have a spare in there, alerts set up, and kick of a rebuild ASAP of the failed drive, which I'd then replace quickly.

  • Hi Steve, this is called a RAID 5E right ?

    Why not RAID 0 for the transaction log ?

    Jonathan Bernardez Bernardez
    ___________________________________________________________
    DBD. MCSA SQL Server 2012

  • The transaction log is important. Without it, my system stops. R0 isn't acceptable for me.

    Not sure what R5 + a spare is, but I'd just have one spare in the system for both arrays and others handy nearby as replacements.

  • You mentioned this is primarily a read heavy box, correct? If that's the case then going to RAID 5 might be the move to make if cost is a concern but keep in mind changing the disk subsystem is not something that should be taken lightly. Although writes aren't the majority here understand that they will suffer going from RAID 1 to RAID 5 given the penalty by design.

    For every one write, you have 4 operations to do:

    A) Read the data to be changed

    B) Read the corresponding parity

    C) Write the change

    D) Write the updated parity

    A lot of good advice already shared but I wanted to chime in with this factor considering you're likely not expanding space because you want to but rather you want to have capacity for more data to be written to those disks:-)

  • Thanks for the replies.

    Steve Jones - SSC Editor (10/18/2013)


    I prefer R1 or R10, though I certainly understand economics.

    RAID1 for everything?

    If you convert to r5, and that might work fine for your workload, I wouldn't add 2 drives, I'd add 3 and have a hot spare. If R5 fails, and you have multiple drives from the same vendor/batch/generation, it is entirely possible you lose another one in short order. I'd have a spare in there, alerts set up, and kick of a rebuild ASAP of the failed drive, which I'd then replace quickly.

    That does sound good but I don't think we have that kind of setup yet. We're a long way behind what most people consider the bare minimum! Which makes me think I should be concentrating on resilience first and foremost.

    You mentioned this is primarily a read heavy box, correct? If that's the case then going to RAID 5 might be the move to make if cost is a concern but keep in mind changing the disk subsystem is not something that should be taken lightly. Although writes aren't the majority here understand that they will suffer going from RAID 1 to RAID 5 given the penalty by design.

    For every one write, you have 4 operations to do:

    A) Read the data to be changed

    B) Read the corresponding parity

    C) Write the change

    D) Write the updated parity

    A lot of good advice already shared but I wanted to chime in with this factor considering you're likely not expanding space because you want to but rather you want to have capacity for more data to be written to those disks

    This was what I was worried about. This is a database that mostly has reads, but a few times a month there are some semi-automated processes (taking place during business hours) that are very write-heavy. From what you're saying above, if we moved to RAID5 there would be times when the system could theoretically grind to a halt, whereas if we were on RAID1 it might perform a little faster- is that roughly it?

    Thanks again. I appreciate the help.

  • Don't get caught up too much in the R5 penalty. It certainly is a bigger hit than R1/R10, but I've run SQL Server databases for years on R5 and it has worked well.

    The resiliency is a big deal. I've definitely had issues where we lost a drive and another one in a week. Not having a spare that rebuilds quickly is an issue. I'd honestly be more concerned about that than performance. If performance suffers, re-evaluate.

    However, you need monitoring. You need to know the IOPS you get now, the latencies from the various files (from DMVs) and read/write levels. Once you have that, you can re-measure with a change and decide how things are performing.

    I prefer R10 for everything, but R1 works well. We used to run SQLServerCentral with R1 for OS, R1 for data, R5 for logs/backups. 8 drives.

  • Thanks. It sounds like it could go either way and I'll just have to try it and see.

    I'll take some metrics then, and probably try RAID5 and see how that goes. Unfortunately my sysadmin isn't very interested!

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply