« Thoughts on 2011 - Technical Trends for Clouds | Main | ITaaS with NewScale & NetApp »

December 18, 2010

Comments

Patrick

That's the difference between "real" dedup and single instance storage...

Craig

The dedupe EMC could offer today are too limited, this comment come from my fren who use to be the local SE for EMC in my country, they are not block level dedupe enable on the primary SAN yet

Steve

So what's the key difference in how the two dedupe technologies handle VMDKs recently or actively modified/written/read?

How does NetApp's dedupe work compared to how EMC's does?

Wade

Steve, read this thread I started. It covers the dedupe topic. Remember that this may reflect opinion rather than fact. http://communities.netapp.com/message/41914

Chad Sakac

Disclosure - EMC employee here.

All - you might want to see the conclusion of the thread, in the customer's own words.

Chad

Justin

This post deserves a follow up. This is the customer's results.

All,

I thought this thread should have my results posted to it. We have done some extensive testing and had equipment from both vendors onsite. We read through many blogs, articles, white papers and manuals during testing. We used the same data sets and same VMware data stores for these tests.

Let’s start off with the technical specs:

1.) We found the EMC had faster CPU and more Memory per host and cluster

2.) Redundancy – The NetApp isn’t a true redundant system since the controllers are separate. As we saw NetApp was 4 9’s availability versus 5 9’s from EMC

3.) PAM/CACHE – The NetApp cache is read only versus EMC cache as read/write

4.) PAM/CACHE – When either controller reboots the CACHE is cleared versus moved to the other controller on EMC

Let’s discuss capacity now:

1.) We used 1.3TB of RAW disk capacity

a.) EMC had 81% of the RAW capacity as useable

b.) NetApp was 48% of the RAW capacity as useable

2.) Dedupe rates

a.) EMC was a 46% dedupe rate plus we saw gain from compression

b.) NetApp a was 90% dedupe rate

Results:

Manageability was one of the major concerns in our organization as well. NetApp is simple to manage while allowing a robust CLI and a great V-sphere plug-in. However filer view is a very old interface and needs some updating as well. With EMC's current platform, we found that Unisphere is a simple to manage platform and the new vSphere plug-in is robust and works great.

One thing we did note was that response time on EMC fiber channel LUN’s was better than the NetApp LUN’s. Now in our environment I’m not sure that would matter a whole lot but it was worth noting. Reading various blogs also indicated the same results on FC & iscsi; noting that EMC had better performance than NetApp.

I think there is no doubt that the WAFL file system is a great file system and block level dedupe beats out file/byte level dedupe. NetApp appears to have better response from a NFS mount perspective however we had some permission issues getting mounts to work on VMware which was seamless with the EMC.

All in all so far we couldn’t find a compelling reason to choose NetApp for our environment. I think in the end the dedupe differences seem to even out in regards to useable capacity. Well that’s it from our testing and research, I hope this ends up being helpful to someone else out there.

Vaughn Stewart

@Justin

I've reviewed the data and would offer the data with the following observations:

1. The NetApp system is being deployed manually without following best practices and a such returns such poor usable capacity numbers. By simply using the NetApp VSC plug-in for vSphere the customer would be up and running with optimal storage designs in literally one minute.

2. NetApp block level dedupe (both disk and cache) is much more advanced than EMC both in terms of storage savings and performance.

It is unfortunate to learn that I this customer didn't have a world class experience. I'll take the blame for that; however, I'd challenge the assumption of the numbers being shared as what one should expect to see with their deployment.

i would add, both of the point I made above (1 & 2) have been validated by VMware performance engineering in TR-3856, which can be downloaded here:

http://www.netapp.com/us/library/technical-reports/tr-3856.html

Cheers!

The comments to this entry are closed.

TRUSTe CLICK TO VERIFY