20+2 will be within all reasonable margins of 2(10+2), or 4(5+2).
How about, say, 17+2 with 3+2?
Thanks,
Randall
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Mohler Sent: Tuesday, November 01, 2011 10:21 PM To: Adam Levin Cc: toasters@teaparty.net Subject: Re: from performance vs rg size to new topic: rg size uniformitywithin the aggregate
"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:
- 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
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters