read_realloc for vmware volumes

[jasonczerak]

Has anyone poked around with this and found any usefulness?

[mcope]

Andrew and Eric are correct, read_realloc is trumped by deduplication when it comes to VMs.  I was asking these questions of the development team two weeks ago after reading about read_realloc in the ONTAP documentation.  I'm still trying to find use cases/examples because it sounds like a neat volume option.  The best advice I've been given is to enable it on non-deduplicated NAS volumes on SATA disks where file fragmentation can cause the most noticeable latency.

[amiller_1]

Thanks for the confirmation. Next question then is....if using deduplication (I primarily use it inside volumes that host NFS datastores to VMware so just returning the used space to the volume is quite sufficient), can I instead use a scheduled reallocate with the "-p" option? Any gotchas I should be aware of there?

As best I understand, regular reallocate can increase snapshot space usage (and therefore would diminish deduplication savings as well if I understand the relationship correctly) and the "-p" option can cause speed issues with Single File Restores (which SMVI uses in an NFS scenario).

Thoughts? Concerns?

[amiller_1]

Very curious if anyone has any thoughts here....I'm about to put up a big post outlining where I am right now with VMware, NFS datastores, deduplication, reallocation to get some feedback.....read_realloc being one of the pieces there.

[jasonczerak]

We are in the middle of deploying ESXi 4 on a set of netapp clusters, 10ge, nfs, ibm blades. So far with just 10-ish vms (mix of windows, linux). we are seeing very good de-dup.  Rapid Clone is Sweet.  We do not have the time to validate the use of read_realloc vs scheduled reallocate (the command) or a combo of both, so I'm just flipping the bit for read_realloc and hoping for the best right now.  I'll do some reallocate measures and see what happens after a month of usage.

We are on the last main part here and that's backups. We have an eval of SMVI. That's some neat stuff too. 

[amiller_1]

Ok....a bit more reading here. The docs are pretty explicit that you shouldn't combine read_realloc and deduplicated volumes.

http://now.netapp.com/NOW/knowledge/docs/ontap/rel732/html/ontap/sysadmin/GUID-733A19F3-8226-44EA-8CA5-C86BB814733F.html

http://now.netapp.com/NOW/knowledge/docs/ontap/rel732/html/ontap/onlinebk/GUID-5DDC055A-8158-4B94-8D38-005A1A1E0E66.html

Given deduplication is most powerful in VMware environments (and I use it in just about all my VMware environments), I'm thinking that takes read_realloc off the table. What I'm not sure of right now is whether scheduled reallocates (i.e. "reallocate start /vol/volname" and "reallocate schedule -s '22 0 * 6' /vol/volname") are off the tables as well (as I have been doing that on VMware volumes to improve performance....it has noticeably helped in certain environments).

[eric_barlier]

Also, if your VM guest is relying on sequential reads and writes its not a good idea to enable dedupe as these two technologies are mutually exclusive by nature.

Acutally, from memory I think you need to thin provision as well because freeing up blocks with dedupe and not allowing them to be sent back to aggregate is kind of a

moot excersize, correct? There could be scenarios where this is not needed of course.

Eric

[amiller_1]

Hmm....you could always set a scheduled "reallocate measure" just as a reporting option....would let you see relatively live if scheduled reallocate would make a difference.

I'm also seeing vSphere thin provisioning knock down dedup ratios....still impressive at 30-50% but not the 60-90% that I'd see before thin provisioning in vSphere.