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

Re: Supermicro SAS controller



On 5/3/2012 1:27 PM, Ramon Hofer wrote:

> Btw: Wouldn't it be better to use software raid? 

There are many factors involved in this decision, and just as many
opinions available from users who prefer one method over the other.

> In case of failure of 
> the controller I would need to get exactly the same card again?

This in not a primary reason to choose software over hardware RAID.
Though it does seem to be the first mentioned by people with very little
RAID experience.

Something to consider is that mdraid newbies tend to lose their entire
arrays for various reasons.  Whether they're using cheap hardware, or
not paying attention to logs, etc is unclear.  In the past 2 weeks alone
there have been no less than 4 people post on the linux-raid list that
they'd lost an md RAID5 array.  Some were recoverable, some were not.
It's difficult to find many similiar stories via Google of HW RAID HBA
failures causing the loss of entire arrays.

mdraid is quite tolerant with drive errors before it finally kicks them
offline.  Using the firmware RAID on this LSI card, any drive showing
flaky behavior will be kicked very quickly from the array, and if you
configure everything properly, you'll receive and email, sms text, or
page telling you a drive is offline and why.  If you have a spare
configured, the HBA will automatically start rebuilding the failed
drive's contents to the spare drive.  If not, you simply pop the dead
drive out, pop the new on in, and it starts rebuilding automatically.

In a nutshell, (good) hardware RAID typically has every advantage over
linux mdraid but two:

1.  Flexibility--mdraid can span disks across many HBAs
2.  Absolute performance**

**Host CPUs are much faster than HBA RAID ASICs, 3-4GHz vs 500-800MHz,
especially with parity calculations (RAID5/6), and have many more cores,
typically 4-24 in a single or dual socket machine, vs 1-2 cores in an
HBA RAID ASIC.  Thus they have an enormous raw horsepower advantage.  A
good hardware RAID HBA will have RAID5/6 performance similar to mdraid
w/up to ~16-24 SAS 15K drives.  At some drive count beyond that the RAID
ASIC will hit its performance ceiling.

Many people use hybrid setups, where hardware RAID is used at the
controller level and mdraid is used to span the HW RAID devices into a
single Linux disk device, allowing for a single filesystem across dozens
of drives connected to 2, 4, or more RAID HBAs.  With some application
workloads multiple RAID groups are created per controller and these are
then spanned or striped with md, for example high IOPS maildir servers.

You mentioned previously you don't have a high performance requirement
in which case I'd recommend hardware RAID.  That said, if you want to
use RAID5/6 instead of RAID10, md RAID may be more attractive, as the
parity RAID performance of the SAS9240 is less than stellar.  Depending
on your workloads, it may perform great.  Just remember that the LSI
SAS9240 is high end JBOD HBA with RAID firmware.  It's can act just like
a HW RAID card from the viewpoint of the OS and the user, but it not a
HW RAID card.  It's not even an entry level RAID controller--note the
lack of cache and BBU option.

Given what you've told us so far, I'd say you'd likely be very happy
using the HW RAID mode.

> Or if I ever want to exchange the mainboard and use one with a SAS 
> controller onboard?

If your new mobo has an onboard SAS controller it will be an LSI
controller, so this is a non issue.  But why would you switch to that
and toss the 9240 anyway?  They use the same ASIC:  the SAS2008.  Look
at SuperMicro, Tyan, Intel, and Asus  boards.  They all use the SAS2008,
or an older or newer LSI SAS chip.

LSI is the only viable motherboard-down SAS solution on the market, at
least on quality server mobos.  There may be junk floating around the
Asian markets with different onboard SAS chips.  If so, I'm unaware of
them, and I'd recommend to anyone to stay away from them as the chips
will be Marvell, JMicron, etc--cheap and unreliable.

-- 
Stan



Reply to: