> 20+2 will be within all reasonable margins of 2(10+2), or 4(5+2).
"Part of the issue here may be theoretical vs. real world. After all, in
theory 'theory' and 'practice' are the same, but in practice they aren't."
---
But..they -are-.
I made those statements, and I will stand by them as a relatively knowledgeably person on these matters.
Build yourself a system in your lab (whomever is able) and watch via statit the distribution of IO across the aggregate FAR above the raid-group level.
20+2 will be within all reasonable margins of 2(10+2), or 4(5+2).
As you increase the # of raid groups, there is a minor cost in managing MORE protection zones (raid groups) but the IO is aggregate wide.
Best practices guide best principles, and they're safe, very safe..but "you have to understand why things work on a starship" (fun quote from a fun movie)
"The other problem is that moving forward if you have optimized your writes
for the 16 disk rg stripe size, some rgs are going to be optimized and
some aren't, which could conceivably affect performance."
---
Im trying to understand this statement as well. Writes are optimized for the full stripe of the aggregate. RG size, again, has nothing to do with it as a "stripe".
Raid groups are zones of data protection.
On Tue, Nov 1, 2011 at 6:28 PM, Adam Levin <levins@westnet.com> wrote:
On Tue, 1 Nov 2011, Cotton, Randall wrote:
> Unfortunately, I've not been enlightened as to performance numbers for
> varying small aggregate sizes with one raid group, so I guess I'll have
Yeah, sorry about that, but it appears we just don't have that information
available to us (and NetApp reps don't seem to want to answer :) ).
> But now to a tangentially related subject:
And an interesting one.
> "...there is no reason one 4+2 and two 16+2s cant perform quite well.
> There is no unreasonable penalty to doing so ... if the right tools are
> used to manage it."
I was somewhat surprised by that comment myself.
> That is, NetApp took the time and trouble to say:
> 1. RAID group sizes within an aggregate shouldn't vary by more than 1
> disk
> 2. Larger RAID group sizes are better (up to a point)
I would certainly stick with NetApp's best practice when it comes to this.
Part of the issue here may be theoretical vs. real world. After all, in
theory 'theory' and 'practice' are the same, but in practice they aren't.
It may be that in theory, different rg sizes may not make much difference.
However, it's possible that the way NetApp implements rgs within an
aggregate that it makes a difference.
> For instance, what are the drawbacks (and how bad are they) to, say,
> adding a 6-disk raid group to an aggregate consisting of one 16-disk
> raid group (instead of spilling for way more disk space than you might
> need by forking over for the full 16 disks necessary to even things
> out?).
One thing to consider is starting out with a large rg and adding a small
one. This also matters if you add a 16-disk rg that's not full yet (you
can create a 16 disk rg with 6 disks, and you'll get 2 parity and 4 data
until you add more available data disks).
The problem here is that if the 16 disk rg is half full and you add a 6
disk rg, the system will begin filling the 6 disk rg to a proportional
size. So, you used to have 14 data disks working for you, and now you
have 4 until they're appropriately full. It's certainly possible to force
a redistribution of data, which will take some time.
The other problem is that moving forward if you have optimized your writes
for the 16 disk rg stripe size, some rgs are going to be optimized and
some aren't, which could conceivably affect performance.
Again, I would go back to NetApp and ask the question outright. They know
their product the best, and they want you to speak well of them and buy
more product, so they'll want you to get the performance you're looking
for.
Hope this helps,
-Adam