[There's a reason that Yoda is the unofficial mascot of SBS. Size indeed matters not.] What's your RAID favorite? - THE OFFICIAL BLOG OF THE SBS "DIVA"
Sun, Oct 25 2009 14:19 bradley

What's your RAID favorite?

This weekend I'm just doing a play install and seeing what sort of RAID array I can build.

RAID levels: Learn about RAID 50:
http://searchstorage.techtarget.com/tip/0,289483,sid5_gci1066983,00.html


 

RAID - Wikipedia, the free encyclopedia:
http://en.wikipedia.org/wiki/RAID

I can do a "0", a 1+0, a 5 or a 50.

  • RAID 0 (striped disks) distributes data across multiple disks in a way that gives improved speed at any given instant. If one disk fails, however, all of the data on the array will be lost, as there is neither parity nor mirroring. In this regard, RAID 0 is somewhat of a misnomer, in that RAID 0 is non-redundant. A RAID 0 array requires a minimum of two drives. A RAID 0 configuration can be applied to a single drive provided that the RAID controller is hardware and not software (i.e. OS-based arrays) and allows for such configuration. This allows a single drive to be added to a controller already containing another RAID configuration when the user does not wish to add the additional drive to the existing array. In this case, the controller would be set up as RAID only (as opposed to SCSI only (no RAID)), which requires that each individual drive be a part of some sort of RAID array.

    • Cross out raid 0 here.

  • RAID 1+0 (or 10) is a mirrored data set (RAID 1) which is then striped (RAID 0), hence the "1+0" name. A RAID 10 array requires a minimum of two drives, but is more commonly implemented with 4 drives to take advantage of speed benefits.
  • RAID 5 (striped disks with distributed parity) combines three or more disks in a way that protects data against the loss of any one disk. The storage capacity of the array is a function of the number of drives minus the space needed to store parity. The maximum number of drives that can fail in any RAID 5 configuration without losing data is only one. Losing two drives in a RAID 5 array is referred to as a "double fault" and results in data loss.
    • RAID 1+0: mirrored sets in a striped set (minimum two disks but more commonly four disks to take advantage of speed benefits; even number of disks) provides fault tolerance and improved performance but increases complexity.
    The key difference from RAID 0+1 is that RAID 1+0 creates a striped set from a series of mirrored drives. In a failed disk situation, RAID 1+0 performs better because all the remaining disks continue to be used. The array can sustain multiple drive losses so long as no mirror loses all its drives

    When the top array is a RAID 0 (such as in RAID 10 and RAID 50) most vendors omit the "+", though RAID 5+0 is clearer.

    Just for grins I'm going to try out 1+0, 5 and 50 and see what each give me.

    Stay tuned.  In the meantime, what's your favorite setup?

    Filed under:

    # re: What's your RAID favorite?

    Sunday, October 25, 2009 7:52 PM by Steve

    Ive been running a 1+0 config on my hyper-v machine and have been very happy with it.

    # re: What's your RAID favorite?

    Monday, October 26, 2009 12:56 AM by Andy Parkes

    Depends on the setup but generally we go for a RAID 1 for system and RAID 5 for data for SBS

    Some other setups (a SQL server for example) we use a RAID 1 for system and also a RAID 1 for data

    Everyone has an opinion on RAID!

    # re: What's your RAID favorite?

    Monday, October 26, 2009 5:53 AM by Chris Knight

    Depends on the I/O mix. For lots of small random read I/O with not much write then RAID-5, RAID-6 or RAID-50. For lots of sequential I/O or higher write ratio, RAID-10.

    Interestingly, for a Hyper-V box, RAID-5/6 works well for a bunch of VMs and RAID-1/10 for the Hyper-V pagefile partitions and any high write ratio applications.

    # Depends on performance value

    Tuesday, October 27, 2009 8:04 AM by Joe Raby

    RAID 1 is usable in software, and manageable via the SBS console.  You don't gain much in the way of hardware RAID for RAID 1 or 0, because the overhead needed for those RAID levels is negligible - the drive controller is going to be the weak link there.  SAS would be the preferable option if it's in your budget, but enterprise SATA has a much lower cost, and still works just fine for small businesses (think 10 seats or less).  

    RAID 5 is where you really should have a hardware processor.  There are a lot of "low-cost" hardware controllers for RAID 5, but many just have a controller BIOS, and the XOR calculation is performed by the host CPU.  Stay clear of those.  If you're going to buy a RAID 5 controller, buy a real one or if you don't care about performance, save your money and use software.  Motherboards with "onboard RAID 5" are usually one of these firmware-based software controllers, but most Intel motherboards with onboard RAID only operate RAID 5 with an Intel Matrix Storage BIOS, which is a CPU-based CONSUMER-level RAID 5.  The server-grade RAID option in the system BIOS switches to an LSI BIOS which doesn't support software RAID 5.  This should be a big hint.

    Where your operating system supports RAID setup natively, I'd suggest using the OS over a non-hardware firmware option.  If it's a SATA controller that has firmware-based software RAID, such as Intel's 2 different options (Matrix or LSI), set the SATA controller to AHCI mode for performance, and leave RAID turned off.  The OS (at least Windows Server 2003) offers easier control of RAID functionality in those scenarios, and there is no performance difference (we've benchmarked the differences here between Intel Matrix, LSI, and Server 2003's built-in software RAID for RAID 0 and 1).

    RAID 50 isn't that reliable.  I've used this option once, and I won't use a conventionally striped array again in any business setup because of the nightmares it posed.

    I'd suggest RAID 6 over RAID 50.  I won't use any "+0" arrays again.

    # Depends on... everything

    Wednesday, December 16, 2009 5:09 PM by Justin

    CPU Speed, RAID card manufacturer, drives, platform, drivers, etc, etc, etc. RAID is one of those things that will perform differently on every piece of hardware you try.

    If you're really wanting to squeeze every extra bit of performance out of your box and you have the time, test out the performance of the different RAID configurations.

    However, for most of us (provided you get a decent hardware raid controller), it's less about the performance and more about the redundancy you want to achieve these days. Server 2008, Exchange 2007 and SQL 2008 got much better about their reading/writing performance, relying more on the ability to expand into available RAM to lower the disk IO. This especially effects SBS, now that we're in the 64 bit era.

    One last thing to note... If you use Hyper-V, use only raw disk access (near 100% performance in 2008 R2) or fixed size virtual disk (uses a bit more CPU than raw access, but still gets very close to native performance). You're just asking for disaster if you don't fully allocate the disk space for your virtual disks. Think having to manage the fragmentation level of the server was enough fun? How about the fragmentation of the server and the virtual disk on the VM host.

    # Depends on... far too much

    Wednesday, December 16, 2009 5:11 PM by Justin

    CPU Speed, RAID card manufacturer, drives, platform, drivers, etc, etc, etc. RAID is one of those things that will perform differently on every piece of hardware you try.

    If you're really wanting to squeeze every extra bit of performance out of your box and you have the time, test out the performance of the different RAID configurations.

    However, for most of us (provided you get a decent hardware raid controller), it's less about the performance and more about the redundancy you want to achieve these days. Server 2008, Exchange 2007 and SQL 2008 got much better about their reading/writing performance, relying more on the ability to expand into available RAM to lower the disk IO. This especially effects SBS, now that we're in the 64 bit era.

    One last thing to note... If you use Hyper-V, use only raw disk access (near 100% performance in 2008 R2) or fixed size virtual disk (uses a bit more CPU than raw access, but still gets very close to native performance). You're just asking for disaster if you don't fully allocate the disk space for your virtual disks. Think having to manage the fragmentation level of the server was enough fun? How about the fragmentation of the server and the virtual disk on the VM host.

    # Depends on... far too much

    Wednesday, December 16, 2009 5:26 PM by Justin

    CPU Speed, RAID card manufacturer, drives, platform, drivers, etc, etc, etc. RAID is one of those things that will perform differently on every piece of hardware you try.

    If you're really wanting to squeeze every extra bit of performance out of your box and you have the time, test out the performance of the different RAID configurations.

    However, for most of us reading this blog (provided you get a decent hardware raid controller), it will end up being less about the slight performance increase of the various types and more about the redundancy you want to achieve for the price point. Server 2008, Exchange 2007 and SQL 2008 got much better about their reading/writing performance, relying more on the ability to expand into available RAM to lower the disk IO. This especially effects SBS, now that we're in the 64 bit era.

    I'm not saying it's not worth optimizing... you just need to do a cost benefit analysis on it. Going RAID-10 for the entire system will give you an extra performance bump, but it also costs significantly more. Bumping up to 15k RPM disks also helps, but again costs significantly more. And with Virtualization, migrating from one RAID type to another or even an entirely new server becomes a trivial task.

    Sure, the decked out Porche (Server) looks great and can do 0 to 60 in no time flat, but if you're going to spend 99.9% of your time in commuter traffic (small workload) then it's all for show.

    One last thing to note... If you use Hyper-V, use only raw disk access (near 100% performance in 2008 R2) or fixed size virtual disk (uses a bit more CPU than raw access, but still gets very close to native performance). You're just asking for disaster if you don't fully allocate the disk space for your virtual disks. Think having to manage the fragmentation level of the server was enough fun? How about the fragmentation of the server and the virtual disk on the VM host.