Re: Arguments Pro/Contra Software Raid

On May 9, 2006, at 2:16 AM, Hannes Dorbath wrote:

> Hi,
>
> I've just had some discussion with colleagues regarding the usage
> of hardware or software raid 1/10 for our linux based database
> servers.
>
> I myself can't see much reason to spend $500 on high end controller
> cards for a simple Raid 1.
>
> Any arguments pro or contra would be desirable.
>
> From my experience and what I've read here:
>
> + Hardware Raids might be a bit easier to manage, if you never
> spend a few hours to learn Software Raid Tools.
>
> + There are situations in which Software Raids are faster, as CPU
> power has advanced dramatically in the last years and even high end
> controller cards cannot keep up with that.
>
> + Using SATA drives is always a bit of risk, as some drives are
> lying about whether they are caching or not.

Don't buy those drives. That's unrelated to whether you use hardware
or software RAID.

>
> + Using hardware controllers, the array becomes locked to a
> particular vendor. You can't switch controller vendors as the array
> meta information is stored proprietary. In case the Raid is broken
> to a level the controller can't recover automatically this might
> complicate manual recovery by specialists.

Yes. Fortunately we're using the RAID for database work, rather than
file
storage, so we can use all the nice postgresql features for backing up
and replicating the data elsewhere, which avoids most of this issue.

>
> + Even battery backed controllers can't guarantee that data written
> to the drives is consistent after a power outage, neither that the
> drive does not corrupt something during the involuntary shutdown /
> power irregularities. (This is theoretical as any server will be
> UPS backed)

fsync of WAL log.

If you have a battery backed writeback cache then you can get the
reliability
of fsyncing the WAL for every transaction, and the performance of not
needing
to hit the disk for every transaction.

Also, if you're not doing that you'll need to dedicate a pair of
spindles to the
WAL log if you want to get good performance, so that there'll be no
seeking
on the WAL. With a writeback cache you can put the WAL on the same
spindles
as the database and not lose much, if anything, in the way of
performance.
If that saves you the cost of two additional spindles, and the space
on your
drive shelf for them, you've just paid for a reasonably proced RAID
controller.

Given those advantages... I can't imagine speccing a large system
that didn't
have a battery-backed write-back cache in it. My dev systems mostly use
software RAID, if they use RAID at all. But my production boxes all
use SATA
RAID (and I tell my customers to use controllers with BB cache,
whether it
be SCSI or SATA).

My usual workloads are write-heavy. If yours are read-heavy that will
move the sweet spot around significantly, and I can easily imagine that
for a read-heavy load software RAID might be a much better match.

Cheers,
Steve