Geek question: RAID array performance
Oct. 19th, 2006 11:57 amWe've got a big data store. It's currently built as a single max-size 2Tb RAID 5 array over 11 disks. It performs like a three-legged dog and each of the 300Gb disks has about 75Gb unused (because that would take it over the 2Tb SCSI RAID limit).
We need to rebuild it. We've been advised that volume sizes over 1.5Tb are dogs under SCSI RAID so we're keen not to do that. Our options are:
* RAID 10, 10 disks+hotswap, total volume space 1.5Tb, good write performance.
* RAID 5, 7 disks+hotswap, total volume 1.6Tb, but it feels wasteful of all these lovely disks.
* Two smaller RAID 5 volumes, 4+hotswap and 5+hotswap, giving us .9 and 1.2 Tb respectively. The volumes should behave better, because they're smaller and on fewer disks, but will this just move the bottleneck up to the servers' RAID controller?
Gurus, your wisdom is much appreciated!
We need to rebuild it. We've been advised that volume sizes over 1.5Tb are dogs under SCSI RAID so we're keen not to do that. Our options are:
* RAID 10, 10 disks+hotswap, total volume space 1.5Tb, good write performance.
* RAID 5, 7 disks+hotswap, total volume 1.6Tb, but it feels wasteful of all these lovely disks.
* Two smaller RAID 5 volumes, 4+hotswap and 5+hotswap, giving us .9 and 1.2 Tb respectively. The volumes should behave better, because they're smaller and on fewer disks, but will this just move the bottleneck up to the servers' RAID controller?
Gurus, your wisdom is much appreciated!
It's been a while
Date: 2006-10-19 09:11 pm (UTC)With much reads it can give a latency for the disk to get to a stripe position for reading (ie more stripes means more chance of latency per read) - this might have been reduced by hardware technology on-drive.
there's similiar consideration for writes but I can't recall it.
If data is moving to and from the same devices, can they be split physically, and rejoined logically. This separates the load on each channel.
What are the main constraints? price? physical size/cable size? speed?
The old superserver range I used to work on there were some optimal configurations for which channels and which raid patterns the controller handled better. The high level raid 5 & 10 were a hassle (I recall) because of the extra in-channel bandwidth consumed by the parity and drive command (after all it had to be calculated: fast, then the drive latency probability: medium % but sigificant delay many uS, then the commands placed into the channel 10%-20% bandwidth lost straight away.) also big disks sometimes makes for poor administration wich increases latency chances and put bandwidth hogs on the same highway as smaller, higher priority requests.)