Hi folks,
I'm familiar with the NetApp recommendation to keep ~20% free on all volumes ... this allows WAFL to maximize its performance (convert random IO to streaming IO ... i.e. the 'Write Anywhere ...' part of WAFL).
But I'm skeptical that this recommendation applies to V-Series installations, i.e. situations in which the backend array was built by someone other than NetApp.
Seems to me that with V-Series, WAFL may find what it thinks are 128K of contiguous blocks on storage and perform the WRITE ... but ... since the backend array has virtualized the blocks in some fashion, opaque to ONTAP, there is no knowing what really happens. In other words, the blocks which ONTAP specifies do /not/ map to physical blocks ... once the WRITE arrives at the array, the backend will do whatever it thinks best with them, perhaps perform a streaming write to contiguous blocks, perhaps not. Implementation-specific.
-In fact, with a V-Series, I would imagine (I have a rich imagination) that ONTAP doesn't bother to even try to convert random IO into streaming IO -- I would imagine that it just hands the blocks to the backend in a jumble and says "Do whatever".
So, I would like to claim that with V-Series, I can fill up my volumes without impacting write performance ... or, more precisely, that impact is dependent on the characteristics of the backend ... perhaps the backend needs free space in order to optimize its write performance, perhaps it does not. [In our particular case, we're using 3Par, and 'fullness' would not impact performance.]
Would anyone see holes in my thinking?
--sk
Stuart Kendrick FHCRC
Stuart Kendrick wrote:
But I'm skeptical that this recommendation applies to V-Series installations, i.e. situations in which the backend array was built by someone other than NetApp.
This is a very good general point -- one that I thought about a few years back when theoretically looking at V-series + HP EVA 8400...
Seems to me that with V-Series, WAFL may find what it thinks are 128K of contiguous blocks on storage and perform the WRITE ... but ... since the backend array has virtualized the blocks in some fashion, opaque to ONTAP, there is no knowing what really happens.
Exactly. Who knows what really happens. ONTAP will always create a RADI0 column on the "foreign" LUN(s) from the external storage. How it will treat that differently (perhaps) when writing to it compared to a NetApp native back-end, I have no idea.
In other words, the blocks which ONTAP specifies do /not/ map to physical blocks ... once the WRITE arrives at the array, the backend will do whatever it thinks best with them, perhaps perform a streaming write to contiguous blocks, perhaps not. Implementation-specific.
-In fact, with a V-Series, I would imagine (I have a rich imagination) that ONTAP doesn't bother to even try to convert random IO into streaming IO -- I would imagine that it just hands the blocks to the backend in a jumble and says "Do whatever".
Maybe. Who knows? Someone inside NetApp prod dev does of course -- I kinda lost interest after a while and stopped thinking about it. Personally I doubt that ONTAP treats the "foreign" back-ends very much differently (except the simplification of just using RAID0), a lot of work/effort for the NetApp Engineers, for what...?
So, I would like to claim that with V-Series, I can fill up my volumes without impacting write performance ... or, more precisely, that impact is dependent on the characteristics of the backend ... perhaps the backend needs free space in order to optimize its write performance, perhaps it does not. [In our particular case, we're using 3Par, and 'fullness' would not impact performance.]
Empirical knowledge is the path for you I think. Try it in your real environment under your real workload and see what happens ;-)
You're running NetApp V-series + 3PAR from HP in a production setup? Wow. I Wish you luck, hope you don't have a really difficult workload that will pressure all this hard, as there's no way for you to predict how it's going to behave in the end.
Would anyone see holes in my thinking?
Not really, but I think you need wishes for luck all the same and I hope your (NFS) workload is light. If it's anything like this... I'd be scared
CPU NFS CIFS Total Net kB/s Disk kB/s Cache Cache CP CP Disk in out read write age hit time ty util 99% 50154 715 50881 93241 39351 252212 160002 6s 86% 81% F 20% 99% 48552 761 49321 93244 44761 300515 145389 0s 83% 74% 26 19 99% 46779 1010 47798 83425 35630 361639 202821 4 80% 97% 31 23 99% 40288 1023 41324 67574 53174 351792 180049 6 79% 92% 30 24 99% 43701 1070 44828 77962 89316 359056 171009 9 78% 94% 28 24 99% 41142 1301 42484 46582 78844 373385 147728 11 77% 94% 26 24 99% 40974 983 42045 47253 61140 357968 141166 12 76% 92% 26 26 99% 49657 652 50324 47562 44669 264335 92603 7 83% 85% 19 19 99% 52610 637 53255 77844 54978 253477 128584 6s 86% 80% 23 22 99% 47490 803 48305 61724 55596 274441 111016 6s 82% 74% 20 24 99% 50432 638 51078 48117 38057 263544 97620 0s 81% 83% 19 23
Regards, M
I'm realizing that I spoke inaccurately below ... here's my effort to clean up my errors (without, I'm hoping, introducing new ones):
-Keeping ~20% free on a heavily used aggregate makes sense /operationally/ ... the applications are likely to want space, and running out of space is generally detrimental to application behavior. But there is no particular /WAFL/ requirement for this.
-WAFL's de-dupe process wants a few percent free (~4%), in order to give itself working space
-WAFL's write performance can benefit from contiguous free blocks ... but WAFL reserves ~10% of an aggregate's space on creation for various functions, including this one. So filling up the user-accessible portion of the volume doesn't necessarily impact the contiguous free block situation.
-And yes, with V-Series, ONTAP no longer has visibility into physical block layout, so this discussion becomes moot.
hth,
--sk
On 3/15/2012 11:46 AM, Stuart Kendrick wrote:
Hi folks,
I'm familiar with the NetApp recommendation to keep ~20% free on all volumes ... this allows WAFL to maximize its performance (convert random IO to streaming IO ... i.e. the 'Write Anywhere ...' part of WAFL).
But I'm skeptical that this recommendation applies to V-Series installations, i.e. situations in which the backend array was built by someone other than NetApp.
Seems to me that with V-Series, WAFL may find what it thinks are 128K of contiguous blocks on storage and perform the WRITE ... but ... since the backend array has virtualized the blocks in some fashion, opaque to ONTAP, there is no knowing what really happens. In other words, the blocks which ONTAP specifies do /not/ map to physical blocks ... once the WRITE arrives at the array, the backend will do whatever it thinks best with them, perhaps perform a streaming write to contiguous blocks, perhaps not. Implementation-specific.
-In fact, with a V-Series, I would imagine (I have a rich imagination) that ONTAP doesn't bother to even try to convert random IO into streaming IO -- I would imagine that it just hands the blocks to the backend in a jumble and says "Do whatever".
So, I would like to claim that with V-Series, I can fill up my volumes without impacting write performance ... or, more precisely, that impact is dependent on the characteristics of the backend ... perhaps the backend needs free space in order to optimize its write performance, perhaps it does not. [In our particular case, we're using 3Par, and 'fullness' would not impact performance.]
Would anyone see holes in my thinking?
--sk
Stuart Kendrick FHCRC
-
Michael Bergman -
Stuart Kendrick