What Raid For Multiple Reads

doubleJ

doubleJ

Limp Gawd
Joined
Aug 10, 2004
Messages
221
Hello...
I have a server with a 5x500GB raid5 connected to 6 workstations with raid0 or raid1+0. The 6 workstations read data from the server (these are automated dvd duplicators pulling the dvd data from the server). I've found that when all 6 machines are pulling data, the transfer speed pretty much halves the speed when 3 machines are pulling data. My thought is that the hard drive heads aren't able to keep up with the reads.
I was looking at either doing a 4x1TB raid1+0 or a 6x500GB raid5+0. Would either of those give better results when all 6 are trying to read? I figured that 5 drives would be up to the task, but apparently not.
JJ
 
Might want to make two smaller stripe sets or something, and have some machines pull from one and some from the other, or use a higher end RAID card with lots of cache.
 
Here's your problem. Raid 1 offers no performance boost because it is essentially doing the same thing to both drives.

You have listed:
(where s is the speed of a single disk)

Raid 5 with 5 drives has a maximum theoretical performance of 4*s
Raid 1+0 with 4 drives is two raid 1 arrays striped together - Max = 2*s
Raid 5 + 0 with 6 drives is 2x Raid 5 of 3, so 2 data drives - Max = 2*2*s

Therefore Raid 1+0 will be slower than what you have now, and Raid 5+0 will be the exact same speed.

All of that may be irrelevant because you may be hitting a different bottleneck. What kind of network speed are we talking about here - you may not be at the drive limitation. 5 drives should put out more data than GigE can handle. Also what controller are you using?
 
Are these SATA drives?
If so, the problem is simpler: random seek. SATA can't handle random seek. It also mirrors testing numbers; double operations, halve speed, repeat. Sequential or not, multiple different systems shoves you into almost purely random seek in about nothing flat. In that situation, you either need more controllers and more spindles by a lot or you need to go SAS.

If it's SAS, need more data. Controller, specific drives, array segment size, file system and file system segment size, cache and BBU.
 
Thanks for the info, guys...
The drives are sata, but on a quality controller (I don't know the model, but I think it was like $400 or something).
Since none of the testing produced over 1/2 of gigabit speeds, I assumed that the network wasn't the problem. I would still like to test that by moving the server to the workstations, but I'm not allowed.
I can see the random seek problem being likely (is this the same as the little fingery guys not being able to move around the platters fast enough for all the machines?).
It wasn't a problem when we only had 3 duplicators doing cds. But now that we have 3 more and they are all doing dvds, it's really becoming apparent.
JJ
 
Controller is irrelevant. It's a drive mechanical limitation. You're doing all random on the array, which trashes the drive performance and throws it right through the floor. Figure that realistic seek on SATA is triple SAS. Three doing CDs is pretty much nothing. You can cache half a CD with readahead. Now you've got real loads on it, and it's falling apart.
It's what SATA does in most of the situations people throw it into; it's not appropriate for significant random loads, and never will be. It's not appropriate for most general purpose loads either. SATA is for when you need cheap capacity and can tolerate abysmal performance.
 
So, do you guys pretty much agree that SAS would be much more functional for this type of environment? I can certainly look into that option.
JJ
 
Yea I would get some 15k SAS for that.
Get like 5 of the Seagate 15k.6's they can be had for a decent price now that the 15k.7s are out.
Run RAID5
Profit
 
Hmmm...
I didn't realize that they were so small (150GB?). We'll need, at least, 1TB (looking to do 3TB) to store the dvd masters. We currently are running a 2TB and it should be filled in the next year or two.
I don't think scsi is going to work in any form.
So it looks like (assuming the bottleneck is at the drive level and not the network level), that our main options would be to just leave things as they are or split the data up over multiple drives (different arrays or machines).
I wonder if there's a way to queue the transfers to all the machines as a whole instead of just on each machine (each one will transfer 1 at a time, but maybe all machines could only transfer 1 at a time).
JJ
 
Uh, actually, you can get them in 36GB to 450GB capacities currently. The best fit for your need right now would most likely be 300GB 15K. That would require 12 drives; 2x 4+1 RAID5 (1160GB usable roughly) and 2 hotspares. At typical prices of $310 per drive for Hitachi, that's $3,720.00
Yes. It's going to be expensive. Very expensive. Splitting the data across more drives is not going to help. Splitting it across more machines will make it worse. You could queue with something internally written, sure, that'd work fine. But that's a lot of work. And doesn't buy you anything long term besides pushing the problem down the road, and making it even more crippling.

Either way, what you have with SATA or SAS is not a long term solution. You will need to plan out something better, and possibly soon, depending.
 
When I said split across multiple machines, I simply meant that I could use the server as a repository (not active supply) and store some of the data on each duplicator. Then it would require no transfer time. It would be faster for the people running the duplicators, but more work for me to keep them maintained.
I may not have to do the queuing, myself. It's possible that the duplication software already has that facility and I just haven't noticed it.
I didn't see 300/450GB drives on newegg (that's the only place I looked), but you sound like that really isn't the way to go. I think, until sas get's in the 1TB range, that it isn't the valid choice.
JJ
 
doubleJ said:
When I said split across multiple machines, I simply meant that I could use the server as a repository (not active supply) and store some of the data on each duplicator. Then it would require no transfer time. It would be faster for the people running the duplicators, but more work for me to keep them maintained.
I may not have to do the queuing, myself. It's possible that the duplication software already has that facility and I just haven't noticed it.
I didn't see 300/450GB drives on newegg (that's the only place I looked), but you sound like that really isn't the way to go. I think, until sas get's in the 1TB range, that it isn't the valid choice.
JJ
Click to expand...

No, you're misunderstanding.

You have a data repository which has your source. You're yanking from this source with 6+ machines. So long as you have a sole data repository and want to use 6+ machines, you need SAS. That's that. SATA isn't an option until you start talking somewhere in the $250K+ price range and fiber channel to the desktops, by the time you're said and done. SAS will get the job done with what you have now.

But you also have a single PC playing RAID host by the sound of it. That's not viable long term. Copying from single source to 6+ machines over GigE is just not an option without some major changes. LACP, ToE enabled, etcetera. Then you run into the issue of very finite expansion. Long term, you will need to move to something bigger and better.

Short term process improvements would depend on the duplicators themselves. Are they totally reading from the array, or are they caching locally? If they aren't caching locally, cheap SATA drives and caching locally should be the first thing you look at. It's going to come down to that versus SAS. Locally caching solves bandwidth woes and disk seek woes. SAS solves seek woes but not bandwidth woes, so you'll still have to make more improvements with the network.

And don't buy SAS drives from Newegg. Ever. Their prices suck and their shipping sucks worse.
 
They cache the running disc, locally. The seek problems aren't during the burning, but during the copying of data from the server to the duplicators. Transfer rates are way slower than they should be and the software drops jobs if the transfer is too slow.
Each machine has hundreds of gigs of hdd in either raid0 or raid1+0 (depending on the age of the machine). That's what I was referring to by splitting the files up on the machines. I could store 100 dvds on each machine and that machine would only run what's on its drive. It would simply be a duplication of what's on the main repository. If we did go that route, though, we would probably set them all up with raid5.
The kicker is that we just started doing a major push for dvds this year and it will only get bigger. We have such a varied selection (nearly 100 multi-cd packages and about 35 multi-dvd packages) that replication isn't reasonable, either.
I just did some calculating, 4 years worth of dvds (the 35 packages) works out to around 900GB (2.5 per disc, not 4.3). So, 1TB would cover our current and 2TB should cover us for another 4 years at the current rate. Since cd production hasn't been an issue, as far as the seeking is concerned, I could see 8x300GB raid5 working for the dvds.
JJ
 
You must log in or register to reply here.
Back
Top