RE: “Cloning a 270GB VM on NFS takes nearly an hour.”

Has cloning speed improved with these updates?

The tweaks are important. I would HIGHLY recommend anyone using Celerra NFS to look at the steps we sent over to Jason, which Scott Lowe has posted here:

http://blog.scottlowe.org/2010/01/31/emc-celerra-optimizations-for-vmware-on-nfs/

The Celerra for VMware techbook is also important reading for any EMC Celerra NFS customer using VMware (there are also CLARiiON and Symmetrix with VMware techbooks). These are all publicly and openly available (and orderable in hardcopy if you so desire).

One that is Celerra specific, and very important is the “uncached” filesystem parameter. This means that the Datamover doesn’t cache the IO. Based on the hardware architecture of the Celerra, write/read caching is still done, but it’s done on the block part of the Celerra (underneath the filesystem). The Celerra filesystem read/write caching is tuned for general purpose NAS (wide variety of files of all different sizes), in the NFS on VMware use case, the pattern is different – dominated by a relatively small number of very large files (VMDKs). This paramter (which applies only to the particular filesystem, not the Celerra as a whole) has a very significant effect on performance.

A vcenter plugin is coming very shortly that automates all the filesystem creation and management (along with many, many other very cool things) on EMC Celerra NFS. Come to VMware partner exchange!

http://virtualgeek.typepad.com/virtual_geek/2009/06/a-multivendor-post-to-help-our-mutual-nfs-customers-using-vmware.html

You could also check that your design follows some their general best practices as well as EMC’s docs. Though, I would think when performance testing just 1 VM’s I/O, a load balanced link aggregation setup isn’t going to improve anything since the traffic would be over 1 TCP session to 1 datastore, unless you’re connected to more than 1 datastore and generating I/O concurrently to each. However, your spindle setup would be a huge factor.

@Jason – even if you used link aggregation, you’ll never get more than 1GB of throughput from source to destination. Unless you know something I don’t. I’m pricing 10gb blades for my 6509 which will make bandwith (much) less of an issue.

No problem on the RCU. Please do share the information.

I don’t have managed Gb Ethernet switches that will support aggregation so I’m stuck with the 1Gb pipe for now, which I’m fine with. Will need to note in the tests that performance numbers were performed over a single 1Gb NetGear switch (w/o aggregation).

ps. I got a sweet package tonight. Might need to airline seats for PEX.

http://blogs.netapp.com/virtualstorageguy/2009/12/preview-rapid-cloning-utility-30-vcenter-plug-in.html

(Jason – sorry for the commercial)

@Jason – The 4Gb FC numbers, suggest you are caching a lage amount of the I/O workload.

With the NFS & iSCSI numbers alos are on a 1GbE pipe I would suggest that the only accurate testing you could demonstrate would be shared datastore scaling across a multinode cluster with a common block size (like 4KB as in NTFS & EXT3).

For high performance IO tests you could aggregate the 1 GbE links with iSCSI (& multi-TCP sessions & RR PSP) and compare those results to FC.

Great post. I see the same performance re: large block file copies in NFS operations in my environment. Cloning and snapshot deletions take way longer on my 1GB NFS volumes (which happens to be a FAS3140) as opposed to my 4GB FC LUN’s (which happen to be EMC Clariion). In daily operations, NFS performs comparable to FC. I always took this as the nature of NFS v block protocols, and the trade off for ease of management /scalability. Thoughts?