Greetings list
What is the preferred/most reliable level to implement software RAID on a Fedora 7 server?
I know there may be many answers to this, and I'm keen to get a consensus :-)
TiA, and have a great day!
Regards,
Stuart
Stuart Murray-Smith wrote:
Greetings list
What is the preferred/most reliable level to implement software RAID on a Fedora 7 server?
Which RAID level you choose to use should depend on what you are trying to solve.
RAID-0: striping Striping can increase your disk IO throughput by scattering large disk writes across multiple disks and doing them in parallel. Depending on how many disks in your stripe, writing a full stripe can be reduced by "N" if you have "N" disks. What striping does *not* do is redundancy. If you lose any one of your data disks, you've lost all of your data.
RAID-1: mirroring Mirroring is designed to protect your data by keeping multiple copies of it (usually 2, so the cost is N*2 disks). A single write to the partition is split between both drives (in parallel) and doesn't cost that much more than a write to s single disk. What you buy with mirroring is reliability. If you lose one of your disks, you data is still intact on the other one. You also gain the ability to do multiple reads at the same time from your disks, effectively increasing your disk read IO bandwidth by 2. This is often critical for things like servers which want to serve multiple clients at the same time asking for different data. It might also be possible to temporarily "break" a mirror in order to do, say, backups on it. Not all RAID implementations allow you to do this, but for those that do, this is a way to create an instant snapshot of the data, and then do something with it (like back it up) without completely taking the other half out of service. At the end of the backup, the mirror can be "re-built" (just like repairing a degraded array).
RAID-10: striped mirrors A Combination of the above. Each stripe is mirrored, giving you the best of both worlds, but at a cost on N/2 in disks. To some, the reliability is worth it as you end up with redundant data that can serve it back out at the same speed as RAID-0 (2 seperate RAID-0 accesses at once).
RAID-3: Single write bandwidth A RAID-3 is "N-1" data disks with 1 parity disk. When a disk write is done, it is assumed that you are writing to the entire "N-1" disk stripe. The data in the "N-1" disks is used to generate a parity block which is always stored on the Nth disk. A single disk write happens in 1/(N-1) of the time since it can be done in parallel. Some added time may be necessary to compute the parity block, but the writes can all happen in parallel. You also get redundancy. Any single disk can fail, and the data remains intact and usable.
RAID-5: Multiple write bandwidth A RAID-5 is also "N-1" data disks with 1 parity disk. The difference between RAID-5 and RAID 3 is that in RAID-5, it is assumed that you will only be reading/writing to one disk at a time (and its parity disk). And, the location of the parity in any stripe varys from strip to stripe. The benefit of this is that one client can be writing to any 2 of the disks, and (if you have enough disks in your stripe) the likelihood that the next disk access will access 2 completely different disks (in a different stripe) helps alleviate contention for the same disks, effectively increasing your disk IO bandwidth since the separate accesses can happen in parallel.
RAID-6: Paranoid RAID-5 RAID-6 is essentially RAID-5 with a second parity disk. The benefit here is that you can now afford 2 disk failures and still continue to access your data.
RAID-1/3/5/6 all allow your data to run in degraded mode upon a single disk failure (and a double disk failure for RAID-6). Most hardware-RAID systems will allow you to swap out the failed disk for a replacement without taking your array of disks offline. Software-RAID doesn't usually allow this, though I suppose if you implemented an array of USB keys, you might be able to do this using software-raid since USB keys are already hot-pluggable.
Your choice will depend on what you are trying to solve. I haven't seen RAID-3 implemented in very many software raid packages.
There are more levels of RAID than I have indicated above, but in my experience (I used to work for Clariion [ie DG/EMC]), these are the most popular in the real world.
I hope this has been helpful. If you need for information, there are many RAID tutorials available on the WWW.
I know there may be many answers to this, and I'm keen to get a consensus :-)
TiA, and have a great day!
Regards,
Stuart
On Wed, Jun 27, 2007 at 15:06:31 +0200, Stuart Murray-Smith eight32@gmail.com wrote:
Greetings list
What is the preferred/most reliable level to implement software RAID on a Fedora 7 server?
Probably raid 6 with spares as that allows for 2 simultaneous disk failures before you need to go to backups for recovery. And I think that having the spares will result in rebuilds happening as soon as a drive is marked as failed (but I haven't tested to see if that's how it actually works). Having the rebuilds start right away reduces the amount of time in degraded mode where you are fewer failures away from needing to go to backups.
Generally if you REALLY care about this, you'll buy a hardware raid system of some sort. You might also get something with multiple controllers so that if you lose a controller you can still run in degraded mode. Being able to replace drives without having to shut down the system is also important.
For a normal home user, I'd just go with raid 1.
On Wed, 2007-06-27 at 11:01 -0400, Kevin J. Cummings wrote:
Stuart Murray-Smith wrote:
[snip]
RAID-1/3/5/6 all allow your data to run in degraded mode upon a single disk failure (and a double disk failure for RAID-6). Most hardware-RAID systems will allow you to swap out the failed disk for a replacement without taking your array of disks offline. Software-RAID doesn't usually allow this, though I suppose if you implemented an array of USB keys, you might be able to do this using software-raid since USB keys are already hot-pluggable.
Actually if you're using hot-swap SCSI or SATA, the kernel will support hot-replacement. You'll just need manually remove the old driver from the array and add the new one.
- Gilboa
On Sun, 01 Jul 2007 15:08:24 +0300 Gilboa Davara gilboad@gmail.com wrote:
You'll just need manually remove the old driver from the array and add the new one.
I have an Intel SS-4000E fileserver. It is Linux-based, and it does hot drive swapping all by itself with no manual-anything required on a drive change.
I wonder if that functionality could be/should be added to the base kernel, or at least Fedora? It obviously can be done....
On Sun, 2007-07-01 at 12:12 -0600, Frank Cox wrote:
On Sun, 01 Jul 2007 15:08:24 +0300 Gilboa Davara gilboad@gmail.com wrote:
You'll just need manually remove the old driver from the array and add the new one.
I have an Intel SS-4000E fileserver. It is Linux-based, and it does hot drive swapping all by itself with no manual-anything required on a drive change.
I wonder if that functionality could be/should be added to the base kernel, or at least Fedora? It obviously can be done....
At least on the SCSI/SATA controllers that I use, the new disk get enumerated up-ward (on a 4 disk system, if I remove sdb and insert a new drive, it'll become sde). As such, I need to remove sdb from the array and hot-add sde once it is inserted.
- Gilboa
-
Bruno Wolff III -
Frank Cox -
Gilboa Davara -
Kevin Cummings -
Stuart Murray-Smith