Software vs Hardware RAID

[richb-RBmg6HWzfGThzJAekONQAQ at public.gmane.org (Rich Braun)]

I did some performance comparisons three or four years ago (posted to this
list) when I decided to overhaul my hardware RAID1 server.

Rather than buying a new RAID controller, I concluded it was better, cheaper,
more reliable, faster to go with Linux software RAID.  This is for disk
mirroring.

One of the reliability problems with my old server had to do with one of the
usual bugaboos with computer hardware:  vendors come and go; software and
Linux kernels march on.  The hardware vendor dropped support for my old RAID
card (vendors drop support on practically everything with 24 or 36 months) so
one of the problems I had was that the original driver never had support for
disk failure notification.  In other words, months would go by before I
noticed that an array had degraded and that I needed to rebuild it and/or swap
out a drive.  Lack of vendor support meant I had to get a new card or run old
software.

This is why keep-it-simple advice generally should be listened to. 
Software-anything, if it's comparably reliable to hardware-anything, is *far*
superior in terms of ongoing support--especially if it's open-source.

For me it's case closed.  I'm happy with software RAID mirroring.  RAID5 might
be good now (it was a tad slow on vintage-2003 processors) but software RAID1
is a total win.  You get double the performance on reads (find the 'iostat'
command, install whatever package it's in and you'll be able to see this on
your own running system) and no more than a 3% performance hit on writes,
versus non-RAID.

The mdadm package includes monitoring, and all the runtime support is built
into the kernel.  You'll never have to worry about incompatibility, and you
will have one less hardware component to fail--the RAID card itself--if you
ditch hardware RAID.

If you're talking a big mondo production server where you need to use 15K rpm
drives in a a striped array of 10 disks, and you can't afford to ever take the
system down, then maybe you won't want software RAID (or be able to "sell" it
on management).  But even in those situations I wouldn't be surprised if
reliability turns out no better than software RAID.

It amazes me that so much of the IT industry seems convinced that adding more
hardware inevitably leads to more reliability.  If done right, redundant
hardware will lead to more _availability_ of an end-user application:  but the
extra components will *always* reduce MTBF for the overall system.  The simple
case is RAID1 itself:  if you have two disks with MTBF of 50,000 hours each,
you will be replacing at least one of the disks more often than 50,000 hours. 
IT departments responsible for operating a sufficiently large number of
components might find themselves replacing a hardware item once a day on
average.  Reduce the number of components, you'll reduce the IT workload.

Notice how cities are replacing incandescent bulbs in stoplights with LEDs? 
The labor cost of operating everything from a RAID server to a stoplight
exceeds the component costs, over time.

Hope this gives some food for thought:  the word "reliability" deserves closer
scrutiny.  You have to balance labor cost with system *availability*
requirements.

-rich


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.