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.
Each RG is an independent parity protected zone across the entire data stripe of the aggregate.
You dont want a TON of raid groups, because you have to calculate parity for all of them, which is why you have a range of options between defaults, and max allowed...depending on your tolerance for recovery times in your business planning. More RG's, less overhead for parity (which really isnt overhead, your business plan tells you that COST to data protection).
As long as all of your raid groups in their current configuration are of the same time horizon (made at the same time, or reallocated since adding drives to any RG or adding new RG's) then the stripe wants to operate as a whole across the ENTIRE aggregate.
This can be seen/measured via statit as uniformity of IO across the data drives in the observed raid group.
On Sun, Oct 30, 2011 at 4:27 PM, Eugene Vilensky evilensky@gmail.comwrote:
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