How to Argue Against RAID5 - Forum - OpenEdge Development - Progress Community
 Forum

How to Argue Against RAID5

This question is not answered

Does anyone have a simple, concise argument against RAID5 for Progress, suitable for use against non-technical management and a "this is how we've always done it" mentality? This is RHEL 7, but I doubt that matters...

Thanks in advance -- Jim

All Replies
  • http://www.baarf.dk/

    wss.com/.../

    --
    Tom Bascom
    tom@wss.com

  • Sometimes "non-technical management" are well-meaning but uninformed.  While others have their minds made up already and don't want to be confused by facts.  When the latter are involved, lucid explanations of the concepts and of real-world lessons learned are only so useful.  The real problem is that they have any say at all in technical decisions.

  • >

    > Does anyone have a simple, concise argument against RAID5 for Progress, suitable for use against non-technical management and a "this is how we've always done it" mentality? This is RHEL 7, but I doubt that matters...

    >

    Short answer: RAID 5 costs you more.

    Slightly longer answer:

    It will cost you a lot more moeny in the long run and at times when you can least afford it. This is so because inherent in the design of RAID 5, RAID 6, RAID DP, etc (all variants of the same design) is the fact that writing to disk is slower with RAID 5 etc than it is with other array architectures like RAID 10. Salesmen will claim this is mitigated by having large caches. That helps but will not solve the problem.

    For example, let's say you have a RAID 5 setup with 3 disk drives (the minimum required). When a disk block is written to the array, it must be written to two separate places - once to a disk block that has the data and then a "parity block" used for recovery purposes must also be written. Sometimes but not always, the data on the other drive has to be read in order to compute the parity block. With RAID 6, there are two parity blocks. So the 3 disk array (or 4 if RAID 6) has the same or less write thruput than a single disk drive.

    Simply put, what all this means is that writing can be slow, especially when doing some bulk maintenance operation like restoring a backup after a crash, dumping and loading, reseeding a replication target, or index rebuilds. All those operation will take longer than they need to and that will result in increased unplanned downtime when doing disaster recovery. Increasing unplanned downtime costs money.

    The cost of the increased downtime can easily surpass the cost of a decent disk setup. =

  • Ages ago Tom posted a definitive way to demonstrate RAID 5's shortcoming - Simulate a "downtime" scenario by D&L a database that's a fair bit bigger than the RAID's cache, or do a restore of a database of similar size. Watch the through-put drop when the cache gets full and calculate how much the resulting downtime would cost the company. 

  • If you want to sum up the above in more non-technical terms:

    1. RAID-5 sacrifices write speed by design.

    2. Every change to your data will get written to disk at least 3 times (persistent storage because that's what a DB is for, before-image and backup in case something goes wrong), often 4 times (after imaging). If you want to get rid of those extra writes: DON'T. They're your basic safeguard to ensure you can recover when something goes wrong.

    Conclusion: RAID-5 guarantees your database performace will suffer when you reach a certain level of create-update-delete workload.

    3. When something goes wrong and you need to recover, restoring the system will cause a lot of disk writes that need to happen as fast as possible to minimize downtime. Because downtime only costs money and doesn't gain any.

    Conclusion: RAID-5 will turn any disaster into a bigger disaster.

  • > On Aug 15, 2019, at 7:05 AM, frank.meulblok wrote:

    >

    > Update from Progress Community

    >

    > frank.meulblok

    >

    > If you want to sum up the above in more non-technical terms:

    >

    > 1. RAID-5 sacrifices write speed by design.

    >

    > 2. Every change to your data will get written to disk at least 3 times (persistent storage because that's what a DB is for, before-image and backup in case something goes wrong), often 4 times (after imaging). If you want to get rid of those extra writes: DON'T. They're your basic safeguard to ensure you can recover when something goes wrong.

    >

    > Conclusion: RAID-5 guarantees your database performace will suffer when you reach a certain level of create-update-delete workload.

    >

    > 3. When something goes wrong and you need to recover, restoring the system will cause a lot of disk writes that need to happen as fast as possible to minimize downtime. Because downtime only costs money and doesn't gain any.

    >

    > Conclusion: RAID-5 will turn any disaster into a bigger disaster.

    >

    Restating no. 3: RAID-5 performs worst when you need it most. Disaster reecovery delays will cost lots of money.

    and adding no. 4:

    4. Salesperson's lie: "Yes, those problems were common with some of the early RAID-5 systems. They have been solved in our (modern, proprietary, special) storage arrays.". This is not even close to true.