Conroller card or onboard Raid?

L

laserbeam

Limp Gawd
Joined
Jan 9, 2005
Messages
168
Hi,
The queston says it all...

I'm about to undertake a project where data volumes are likely to grow quite large. My current mobo doesn't have onboard Raid so I've been looking into controller cards. Please note that this isn't an urgent requirement as the initial size of the data pool will be small. I'm looking to plot a sensible path forward and so budget for it.

My initial investigation leads me to think that the only real value in using a Raid controller vs software Raid is to keep parity load (Raid 5) off the cpu. Seeing as I'm likely to upgrade to a quad core cpu and mobo next year I'm thinking that onboard Raid is the way to go as there'll be plenty of spare cpu capacity to go round.

Is my logic sound or are there other caveats that I'm not aware of?

All advice and guidance welcome:)
 
How many drives are you likely to get up to eventually? What kind of budget have you set aside for storage stuff in the near future?
 
unhappy_mage said:
How many drives are you likely to get up to eventually? What kind of budget have you set aside for storage stuff in the near future?
Click to expand...

I'm thinking that I'll go up to 3-4TB of data and plan to purchase 1TB drives to support that.
 
Personally, i would prefer a hardware raid as the raid can be portable. Onboard controllers usually are not transferrable to another motherboard unless they are of the same chipsets. Even if they are, not 100% chance that it'll be successful.

However, I dun mind onboard raid 0 for OS drive because of the increase in performance. But i'll make sure i have a Raid 5 for backup.
 
I'd go with a dedicated card for a few hundred bucks, might be easier to migrate the array in the future, or do some soft of software array, but even then a dedicated card would be handy.
 
oplin said:
I'd go with a dedicated card for a few hundred bucks, might be easier to migrate the array in the future, or do some soft of software array, but even then a dedicated card would be handy.
Click to expand...

I'm still not comfortable with the argument for hard raid over soft raid. But considering hard raid a little more, which manufacturer and/or products are currently considered to offer the best mix of performance, control, reliability and price? I don't see a whole lot of info out there to allow the consumer to make informed choices.
 
i dont think you can boot off a software raid, but you definitely can boot off hardware raid if its supported by the card.
 
laserbeam said:
Hi,
The queston says it all...

I'm about to undertake a project where data volumes are likely to grow quite large. My current mobo doesn't have onboard Raid so I've been looking into controller cards. Please note that this isn't an urgent requirement as the initial size of the data pool will be small. I'm looking to plot a sensible path forward and so budget for it.

My initial investigation leads me to think that the only real value in using a Raid controller vs software Raid is to keep parity load (Raid 5) off the cpu. Seeing as I'm likely to upgrade to a quad core cpu and mobo next year I'm thinking that onboard Raid is the way to go as there'll be plenty of spare cpu capacity to go round.

Is my logic sound or are there other caveats that I'm not aware of?

All advice and guidance welcome:)
Click to expand...

Hello,

I don't claim to be all the ultimate authority in anything, just my humble observations, but I'd reconsider the software vs. hardware raid. Let me relate a few things to you that I've encountered with my NVRaid over the past few days.

Finding backup software that will natively support that software raid is damned tough, the only real method I've found thus far is to use True Image plus a Bart PE CD. Very few if any software vendors actively support software raids directly. Companies like Acronis have provided a plugin for Bart PE and makes it very helpful, others like Norton's Ghost 10 leave you high and dry (that I've been able to find at least). Oh and DriveImage XML doesn't support raided disks, well sorta, you can backup, but not restore...yeah, been there...

What's the first step in flashing a system bios? Most people would respond with "setting your Bios to factory defaults", right? Well I don't know about the other brands of boards out there, but I can tell you that doing that on my board, for whatever reason, will hoop the software raid. ASUS sets the raid option to off by default. So if anything should happen to your Bios intentionally or not, you'll most likely lose the raid and all the data. (Learned this the hard way)

If it was me, hell it is me, I'd be seriously considering a real hardware raid controller. I'm debating on the 3Ware 9590SE at the moment as the past few days have been a bit trying for me with the software raid. Faster read/writes, less CPU utilization, portability and reliability wins in my book, but now I have to come up with the $500+ for the card... :(

Whatever you decide to do, good luck to you, I just wanted to add my experiences over the past couple days.

--MF
 
In terms of moving from onboard RAID to a raid card.... I just successfully moved my 300GB array RAID 1 from an onboard promise solution on an Asus A8V mobo (circa 2003) to a promise card, TX2300 to be exact. Worked fine!

I suggest Promise as they are a wonderful RAID vendor. Never had any issues.
 
laserbeam said:
My initial investigation leads me to think that the only real value in using a Raid controller vs software Raid is to keep parity load (Raid 5) off the cpu. Seeing as I'm likely to upgrade to a quad core cpu and mobo next year I'm thinking that onboard Raid is the way to go as there'll be plenty of spare cpu capacity to go round.

Is my logic sound or are there other caveats that I'm not aware of?
Click to expand...

This is often claimed, but is way off in practice. You don't see many posts of "how should I overclock my CPU to raise my RAID performance?" or "CPU shoot-out for RAID performance", or "Single-core vs. dual-core RAID performance", etc., for reason. A reason is that (1) when you have a poor RAID 5 implementation, it's slow (especially during writing), and the CPU utilization is also low. The system is spending a lot of time communicating with the drives, and hence the throughput is low, and the CPU utilization is also low. You cannot materially improve the performance of such systems with faster or more CPUs.

Now, there is a valid argument that a good hardware RAID implementation will have potentially better throughput and likely lower CPU utilization than a software one. But to get to high CPU utilization with a software/chipset RAID implementation, (2) it has to be fast, and there has to be good data throughput.

Moreover, when you have a fast RAID implementation, the file-level performance scales with the drives and IO bandwidth, not so much with the CPU. Increasing the CPU performance / count is always a valid approach when you're CPU bound (and using a dedicated processor a valid alternative), but you need to get there first, and be CPU-bound.

Many people have never seen systems for which (2) applies according to their criteria, so think that all software/chipset RAID implementations fall into category (1).

To talk about "RAID 5 performance", you need to make distinctions regarding read and write performance, large and small accesses; random and sequential. Inexpensive RAID 5 implementations can give great sequential write performance, contrary to (1), however all RAID 5 implementations will have some issues with small and random writes. The expensive RAID 5 implementations will apply huge amounts of cache and smarter caching and access algorithms to help deal with these issues. The inexpensive ones generally can't, and some will be dumb and slow regardless of cost.

For these reasons and others, I would not advocate hosting the OS on a RAID 5 implementation, and would suggest keeping it simpler and on a separate drive. When you don't have the OS on a complex RAID, it's both easier to maintain the OS and the RAID array. Then you don't need low-level support for imaging the array; you can do it at the OS level. Of course, you need to deal with OS backups separately, but this is easier when it's not on RAID. (RAID 1 is a valid exception, because it can often be dealt with just as a simple single drive. However, even here, the OS is better on a separate array than co-located with the data.)

Finally, add-on RAID implementations are generally superior in their feature set, notably regarding conversion and expansion. These features are a bit overrated and overused IMO, because they're used to avoid having a backup, which is a bad idea, however, they have their place, especially when you have a backup to save you if things go wrong -- doing RAID-level operations with an external backup fall-back is logically better because it gives you an additional way to get it right.
 
Madwand said:
This is often claimed, but is way off in practice. You don't see many posts of "how should I overclock my CPU to raise my RAID performance?" or "CPU shoot-out for RAID performance", or "Single-core vs. dual-core RAID performance", etc., for reason. A reason is that (1) when you have a poor RAID 5 implementation, it's slow (especially during writing), and the CPU utilization is also low. The system is spending a lot of time communicating with the drives, and hence the throughput is low, and the CPU utilization is also low. You cannot materially improve the performance of such systems with faster or more CPUs.
Click to expand...

This isn't why I was suggesting soft raid and quad core though I accept your point. From what I've been reading desktop soft raid gets held back by computationally intensive tasks being handed off to the CPU. When I get going with this project i will be CPU bound on one processor - the nature of the specialized, math intensive, application I'll be using. Given enough memory and system bandwidth using onboard raid "should" be fairly quick. This view has been reinforced by a review I read which showed $300 hardware raid controllers being hammered, performance wise, in most tests by the onboard raid of an ASUS mobo. Performance is important to me as when I start to scale the data input then message rates could become very high. In my mind's eye I'm leaning towards 5x1TB Hitachi drives in Raid 5 mode. Clearly, I want a Raid configuration that gets the most out of the drives while maintaining reliability and giving control. How I do that with the PC hardware out there isn't clear.

Madwand said:
Moreover, when you have a fast RAID implementation, the file-level performance scales with the drives and IO bandwidth, not so much with the CPU. Increasing the CPU performance / count is always a valid approach when you're CPU bound (and using a dedicated processor a valid alternative), but you need to get there first, and be CPU-bound.
Click to expand...

You're ahead of me here as you're referring to a "fast" RAID implementation. To me the pre-requisites for that are (assuming cpu and memory resources are good), high throughput disks (I will have these), good system bandwidth (i think I'm ok there if I stick with my current mobo), and a good Raid controller (not there yet). And then, if all of the initial criteria for performance are met then I could be forgiven for thinnking that hardware Raid offers marginal, if any, performance advantage over onboard raid. The review I point to above would support that hypothesis unless there is a price point at which hardware raid starts to kick ass. The relative quality of the raid cards out there isn't clear. At what price does quality gear start to appear I wonder?

Madwand said:
The expensive RAID 5 implementations will apply huge amounts of cache and smarter caching and access algorithms to help deal with these issues. The inexpensive ones generally can't, and some will be dumb and slow regardless of cost.
Click to expand...

You see, this is interesting because none of the reviews out there discuss these points. I've worked with enterprise raid in the past and know how important this can be. However, even in the enterprise space the arguments for software vs hardware raid are complex. But then, some of the software raid applications out there are very, very good.

Madwand said:
For these reasons and others, I would not advocate hosting the OS on a RAID 5 implementation, and would suggest keeping it simpler and on a separate drive.
Click to expand...

The raid 5 will be used to house a database of compressed binary data.
 
hi laserbeam,

it seems like you're already fixed on using onboard Raid. No matter how much we convince you, you still want to use onboard Raid. So, you should just go ahead with onboard Raid.
 
laserbeam said:
The raid 5 will be used to house a database of compressed binary data.
Click to expand...

Interesting (as is the rest of the post). I'd want to know the access pattern and performance/ bandwidth goals and whatever I could about the rest of the load on the system before I got into specifics of "you need this or that".

There can be a big difference in performance according to the access pattern. If you have nice big/sequential accesses, then odds are that a good on-board RAID 5 can be fine. If it's really a "database" access pattern, esp. one that is significantly write-intensive, then RAID 5 on any implementation might be the last thing you should think of (unless individual databases are small enough that they'll fit in cache entirely perhaps).

If you don't already know the access patterns, you can use HD access trace tools such as ones from Sysinternals to capture basic information.
 
Madwand said:
Interesting (as is the rest of the post). I'd want to know the access pattern and performance/ bandwidth goals and whatever I could about the rest of the load on the system before I got into specifics of "you need this or that".

There can be a big difference in performance according to the access pattern. If you have nice big/sequential accesses, then odds are that a good on-board RAID 5 can be fine. If it's really a "database" access pattern, esp. one that is significantly write-intensive, then RAID 5 on any implementation might be the last thing you should think of (unless individual databases are small enough that they'll fit in cache entirely perhaps).

If you don't already know the access patterns, you can use HD access trace tools such as ones from Sysinternals to capture basic information.
Click to expand...

I think I may do that seeing as I have neither the application or disks in place yet. The traffic pattern I anticpate will be small, sequential db writes (predominantly) but that's an assumption on my part. I'm a bit surprised that you think raid 5 may be the last thing to think of. I thought raid 5 was suited to sequential write operations? Be aware that though this is a Db, it is not a multi-user, random access Db.

In an ideal world I'd go for 4-way mirrored stripes. I like that configuration but since I'm not made of money raid 5 is my fallback.

Contrary to the opinion of another corespondant I'm leaning towards buying some kind of hard raid setup. Am a bit wary though about paying over the odds for a Lorry as opposed to a sports car though. I think I'll give this some more thought and check out some of the products listed by unhappy_mage.

Thanks for your input.
 
naro said:
hi laserbeam,

it seems like you're already fixed on using onboard Raid. No matter how much we convince you, you still want to use onboard Raid. So, you should just go ahead with onboard Raid.
Click to expand...

To question the consensus view doesn't mean that the contrasting view is held as fixedly as you might think...
 
laserbeam said:
The traffic pattern I anticpate will be small, sequential db writes (predominantly) but that's an assumption on my part. I'm a bit surprised that you think raid 5 may be the last thing to think of. I thought raid 5 was suited to sequential write operations? Be aware that though this is a Db, it is not a multi-user, random access Db.
Click to expand...

I didn't mean sequential access in that remark -- I just meant random access.

For example, the Intel/StorageReview IOMeter database access pattern is defined as 8 KiB accesses, 67% read, 100% random. For the write proportion of this test, RAID 5 will show very poor results, and pretty much any other choice will be better.

http://www.digit-life.com/articles/hddide2k1feb/iometer.html
http://storagereview.com/articles/200003/20000313OSandBM_5.html#IOMeter_AP

RAID 5 can do much better with sequential accesses, and even small sequential writes can be nicely cached and optimized by an on-board implementation, if not the OS.

I'm going to back off from any general claims as to what "the best database access pattern" looks like. Mentioning that your app is a database just brought to mind the possibility that there might be a significant non-sequential component. Your implementation and usage will of course be the ultimate authority on the access pattern.
 
You must log in or register to reply here.
Back
Top