From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] Sent: Sunday, October 30, 2011 6:54 PM To: Eugene Vilensky Cc: Cotton, Randall; toasters@teaparty.net Subject: Re: Is there a graph somewhere of performance vs raid group size?
Its going to be more the total # of data drives across the DATA stripe
of the aggregate at work, no so much the raid groups operating as independent IO buckets.
Yeah, you're right. But for what it's worth, to start off with, I'll only have one raid group per aggregate. We just don't have that many disks yet.
But even with multiple rg's per aggregate, If you start at a just-initialized blank slate aggregate, for instance, and provide a specific workload, an aggregate with n rg's of size 12 is going to perform better than an aggregate with n rg's of size 8. Question is: how much better? I would assume that, the difference in performance would be in the same ballpark no matter what protocol you're using as long as there are no bottlenecks. I could be wrong on that, though.
This can be seen/measured via statit as uniformity of IO across the
data drives in the observed raid group.
Thanks for the tip on (undocumented) statit.
Randall
On Sun, Oct 30, 2011 at 4:27 PM, Eugene Vilensky evilensky@gmail.com wrote:
Randall,
have you seen TR-3838, the Storage Subsystem Configuration Guide? It doesn't have a definitive statement, but it does have a section that starts with the following caveats and describes some reasons for creating larger RAID groups than the prior default:
"4.6 RAID GROUP SIZING
The previous approach to RAID group and aggregate sizing was to use the default RAID group size. This no longer applies, because the breadth of storage configurations being addressed by NetApp products is more comprehensive than it was when the original sizing approach was determined."
Cheers,
Eugene
On Sun, Oct 30, 2011 at 4:23 PM, Cotton, Randall recotton@uif.uillinois.edu wrote:
We're a relatively small shop just getting started with NetApp (1 2020 and 2 2040's all active/active, plus 3 4342's for the 2040's ).
Since committing a disk to a raid group via an aggregate is essentially a permanent thing (you can't change your mind and later shrink an aggregate to pull out a disk from a raid group to use with another node), we'd prefer not to put all our (80) disks in aggregates just yet. We might want more in some nodes and less in other nodes as future needs come into clearer focus. In addition, it's clear that we can later easily add in any disks we've held back as needed and use the reallocate command with the -f option to re-optimize the layout to accommodate the added disks efficiently. So it seems a bit short-sighted to configure all 80 of our disks into aggregates among our 6 nodes right from the get-go (minus the requisite hot spares, of course), as our vendor would have us do.
But in deciding how small to start out with, we don't want to cripple our performance too much. I've looked long and hard on the net to find some data, any data, on DOT 7.x performance vs raid group size, but have come up empty. I understand that performance should be awful and unacceptable if you have a raid group of size 3. I also understand from anecdotal evidence that performance improvements from higher raid group sizes are apparently are not significant once you get to a raid group size of 16 or so.
But what about in between? How does a graph of performance vs raid size look from 3 to, say, 20? Just ballpark data on any type of remotely typical workload would help a lot to start with. Has anyone ever seen or tried to compile this kind of data? Using iometer, perhaps, or any other benchmarking tool? RAID-DP data is preferable, but I'd take RAID-4 data if that's all I can get.
Don't really have the time to do testing myself.
Thanks
Randall Cotton
University of Illinois Foundation
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters