[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Linux "Software RAID"

Sudev Barar wrote:
I hear people extolling the virtues of "software RAID" on the list a
lot.  I'm finally setting up a production server in a school and I have
enough disks to play with to do RAID.  I'm leaning towards RAID 5.  Anyway,
If you're thinking of RAID 5, which is my preferred level, I'd avoid
doing it in software and instead opt for a dedicated RAID card.  Something
like an LSI MegaRAID 150-6 SATA controller.  If you do it in software,
you'll eat up some CPU doing the parity calculations, so you definitely want
to offload that.  However, for just mirroring (say, RAID 1), you should be
fine, because the CPU hit for mirroring is minimal.
I hear lots of people talk about the CPU hit of software RAID.  But how
much hit is there really?  Suppose for argument's sake I can get a hardware
RAID card for $100.  If I instead used software RAID and spent my $100 on a
better CPU, wouldn't I be ahead of the game?
No, I don't believe so.  For one thing, as Dan Young put it, it's much
easier to deal with swapping a failed disk out with a dedicated card.  That
by itself is a *BIG DEAL*.  Additionally, if you do have a disk fail, your
CPU will take an especially big hit, because then it's got to reconstruct
data from the parity info for *all* disk accesses, not just writes.

Furthermore, you don't have to depend on the OS for reading your RAID.  As
long as it's a well-known FOSS-supported card, you can slap it into a
FreeBSD, Net/OpenBSD, Linux, MS Windows, probably even Apple's Mac OS X.
 Much more flexibility.  This has saved my butt before.

Hmm.. I have been using and advising software raids simply because I
do not know of any FOSS programs / enabled cards that will monitor and
report RAID status. Non-FOSS solutions run on Window$.

So how do you know about RAID status? I find that pretty easy using
mdadm and as Rob put it I hardly see any CPU overhead. Yes it is there
when you are re-bulding arrays but I have done disk swap on a running
machine and rebuilt RAID (level 1) without any user complaining of
LTSP slow down.

I would appreciate if a hardware RAID resource list can be compiled
for RAID cards and monitoring software

He wants RAID 5, not RAID 1.  That calls for hardware RAID.

And as for the monitoring, the LSI MegaRAID cards have two ways. The first method is a (binary-only) Linux program called "megarc" that will do that. Should come on the CD with your MegaRAID card. The second method is to check /proc/megaraid. This is how the Nagios plugin does it. On OpenBSD, I use the "bioctl" command to do everything.

If you want hardware RAID on GNU/Linux or any other FOSS system, I say go with LSI. Unlike 3ware/Adaptec/others, LSI actually releases the programming specs for their cards, which is why they're supported by virtually every OS on the planet. The sole exception to that rule is the MegaRAID SAS 8200 series, which are cheap pieces of binary-blob-requiring crap. Every other MegaRAID card (150-x, 8300, 8400, 320SCSI, etc.) is fine.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]