Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
RAID 10 configuration?
- Thread starter ilpadrino
- Start date
Minimum number of drives for a raid 5 is 3 drives
Minimum for Raid 10 is double this; highly recommend a hot spare or bare minimum, have a couple of cold spares on hand.
For a server for general use ( not dedicated database server) I have found little speed increase of using raid 10 vs raid 5. Such a small difference I converted a raid 10 to raid 5 afetr benchmarking tests
For a raid adapter, I have used LsiLogic cards.
Setting up a server with a u320-2 card this week. Always purchase cards with multiple channels for large drives. For raid 10 this is important.
Scsi bus saturation; large drives or many drives on a channel can out pace the scsi buses ability to transfer data. With the u320 bus, bus saturation is less of a problem. From the limited reviews on the Web (Lsilogic vs. Adaptec), the upper end Adaptec raid adapter seems to be the fastest adapter. According to Adaptec, round u320 cables are the way to go.
Minimum for Raid 10 is double this; highly recommend a hot spare or bare minimum, have a couple of cold spares on hand.
For a server for general use ( not dedicated database server) I have found little speed increase of using raid 10 vs raid 5. Such a small difference I converted a raid 10 to raid 5 afetr benchmarking tests
For a raid adapter, I have used LsiLogic cards.
Setting up a server with a u320-2 card this week. Always purchase cards with multiple channels for large drives. For raid 10 this is important.
Scsi bus saturation; large drives or many drives on a channel can out pace the scsi buses ability to transfer data. With the u320 bus, bus saturation is less of a problem. From the limited reviews on the Web (Lsilogic vs. Adaptec), the upper end Adaptec raid adapter seems to be the fastest adapter. According to Adaptec, round u320 cables are the way to go.
I thought that RAID 10 was 0+1 ?
You mirror the drives then put them in a stripe for speed?
So then the total would be a min of 4 disks?
I could be wrong - that is just the way I understood it!
I believe that all of the HP/Compaq SmartArray RAID cards support it!
You mirror the drives then put them in a stripe for speed?
So then the total would be a min of 4 disks?
I could be wrong - that is just the way I understood it!
I believe that all of the HP/Compaq SmartArray RAID cards support it!
Fishmoon is correct!
Been 3+ years since I setup a "raid 10", at that time my adapter manufacturer considered raid 10 as mirrored raid 5 arrays. From my search on Google, raid 10 is a mirror of two striped sets, and the minimum is 4 drives.Thanks for the correction.
Been 3+ years since I setup a "raid 10", at that time my adapter manufacturer considered raid 10 as mirrored raid 5 arrays. From my search on Google, raid 10 is a mirror of two striped sets, and the minimum is 4 drives.Thanks for the correction.
- Thread starter
- #5
To say which is best, you have to define what you mean by best.
Do you favour performance, availability or a large storage space? For a given budget you can have a raid 0+1 configuration with performance and availability but with a 50% overhead of space. For the same budget you can have raid5 array with lower but in most cases acceptable availability and a better cost-effectivness. Performance is in theory lower, but if I/O isn't a bottleneck it doesn't really matter. Depending on how good a raid controller you have and the load profile, you can actually end up getting just as good and in som cases even better performance with raid5.
/charles
Do you favour performance, availability or a large storage space? For a given budget you can have a raid 0+1 configuration with performance and availability but with a 50% overhead of space. For the same budget you can have raid5 array with lower but in most cases acceptable availability and a better cost-effectivness. Performance is in theory lower, but if I/O isn't a bottleneck it doesn't really matter. Depending on how good a raid controller you have and the load profile, you can actually end up getting just as good and in som cases even better performance with raid5.
/charles
Just finshed a server build with a Lsilogic u320-2 dual channel adapter on a 2.8 Ghz mobo, 2 Gig ram.
The raid 5 array is just under 3x faster than a 2.0 Ghz, u160 raid 5 equipped machine (atto benchmark). The speed of the motherboard might account for roughly a 25% speed increase, the rest is the raid adapter.
Point being , with a U320 dual channel adapter mounted on a fast motherboard, your network adapter(s) are now the bottleneck for a general purpose server ( non dedicated).
From the limited reviews, the Adaptec 2200s adapter is faster than the LsiLogic controller.
The raid 5 array is just under 3x faster than a 2.0 Ghz, u160 raid 5 equipped machine (atto benchmark). The speed of the motherboard might account for roughly a 25% speed increase, the rest is the raid adapter.
Point being , with a U320 dual channel adapter mounted on a fast motherboard, your network adapter(s) are now the bottleneck for a general purpose server ( non dedicated).
From the limited reviews, the Adaptec 2200s adapter is faster than the LsiLogic controller.
RAID 10 is a striped mirror. If you had two drives, it would be simply a mirror - RAID 1. The minimum number of drives would be 4.
With that said, let's take a look at the performance aspects of the equation. A single 10K drive formatted NTFS is capable of ~ 120 IO/sec given a 4K IO size. It's important to know the request size of the application you intend to run, because it forms the basis of being able to accurately predict the load an array will handle. For Exchange or Lotus Notes, the request size is 4K. For SQL it's 8K. If you don't know the request size of your application, you can find it using the perfmon counter - Physical Disk - Average disk bytes/transfer.
Next, we need to know something about the performance characteristics of different RAID types. For RAID 0 it's p*n, where p is the IO/sec of a single drive, and n is the number of drives in the array. For RAID 1 or 10, we have to differentiate between read and write performance. For reads, the formula is the same as it is for RAID 0. For writes, it's p*n/2. RAID 5 gets even trickier. For RAID 5, read performance is p*n-1. For write performance, it p*n/4. When a write to RAID 5 occurs, we write the data, read the data, read the parity, calculate the parity, then write the parity.. whew!
In all of the above calculations, we didn't take cache into account. The effectiveness of cache depends on the IO pattern, the algorithm, and the ammount of cache. For sequential IO, write caching is very good, and can effectively negate the RAID 1/10 write penalty. For RAID 5, at a minimum, write caching can negate the need to read the data back when calculating parity, effectively changing the formula to p*n/3. For sequential writes to RAID 5, increasing the write cache can substantially increase performace beacuse the parity can also be cached. The problem occurs with random data sets. For large random data sets, caching looses it's effectiveness. We still want some minimum amount of qrite caching so that on RAID 1/10 we get around the write penalty, and on RAID 5 we al least calculate the parity in cache.
So how do you set the cache ratio? For RAID 1/10 it's simple. You can use the disk writes/sec, disk reads/sec, and disk transfers/sec counters to figure out your read/ write ratio. The cache ratio on RAID 1/10 would simply be the read/write ratio. For RAID 5, it's a little more complicated. You take the read write ratio, and you must transform it. Say you have a 1:1 ratio. With five reads, that's 5 reads. For 5 writes, that's 10 reads and 10 writes. That brigs us to 15:10, which is a 60/40 split. For a transactional database application, you usually see a 3:1 ratio of reads to writes. The split comes out closer to 80:20 in this case.
Well, I'm out of time. Next time we can talk about queueing, IO completion times, sealing wax, and strings.
Hope this helps
John
MOSMWNMTK
With that said, let's take a look at the performance aspects of the equation. A single 10K drive formatted NTFS is capable of ~ 120 IO/sec given a 4K IO size. It's important to know the request size of the application you intend to run, because it forms the basis of being able to accurately predict the load an array will handle. For Exchange or Lotus Notes, the request size is 4K. For SQL it's 8K. If you don't know the request size of your application, you can find it using the perfmon counter - Physical Disk - Average disk bytes/transfer.
Next, we need to know something about the performance characteristics of different RAID types. For RAID 0 it's p*n, where p is the IO/sec of a single drive, and n is the number of drives in the array. For RAID 1 or 10, we have to differentiate between read and write performance. For reads, the formula is the same as it is for RAID 0. For writes, it's p*n/2. RAID 5 gets even trickier. For RAID 5, read performance is p*n-1. For write performance, it p*n/4. When a write to RAID 5 occurs, we write the data, read the data, read the parity, calculate the parity, then write the parity.. whew!
In all of the above calculations, we didn't take cache into account. The effectiveness of cache depends on the IO pattern, the algorithm, and the ammount of cache. For sequential IO, write caching is very good, and can effectively negate the RAID 1/10 write penalty. For RAID 5, at a minimum, write caching can negate the need to read the data back when calculating parity, effectively changing the formula to p*n/3. For sequential writes to RAID 5, increasing the write cache can substantially increase performace beacuse the parity can also be cached. The problem occurs with random data sets. For large random data sets, caching looses it's effectiveness. We still want some minimum amount of qrite caching so that on RAID 1/10 we get around the write penalty, and on RAID 5 we al least calculate the parity in cache.
So how do you set the cache ratio? For RAID 1/10 it's simple. You can use the disk writes/sec, disk reads/sec, and disk transfers/sec counters to figure out your read/ write ratio. The cache ratio on RAID 1/10 would simply be the read/write ratio. For RAID 5, it's a little more complicated. You take the read write ratio, and you must transform it. Say you have a 1:1 ratio. With five reads, that's 5 reads. For 5 writes, that's 10 reads and 10 writes. That brigs us to 15:10, which is a 60/40 split. For a transactional database application, you usually see a 3:1 ratio of reads to writes. The split comes out closer to 80:20 in this case.
Well, I'm out of time. Next time we can talk about queueing, IO completion times, sealing wax, and strings.
Hope this helps
John
MOSMWNMTK
- Status
Similar threads
