Comments on: Storage Protocol Performance Whitepaper from NetApp

By: Arijit

Arijit — Thu, 10 Dec 2009 20:45:39 +0000

NFS only slower by 8-10% as compared to FC..I do not believe that….I get to differ

By: vmware training

vmware training — Mon, 17 Nov 2008 22:25:38 +0000

Has anyone tested the above variables? I too would be interested in seeing that outcome.

By: The SAN Technologist

The SAN Technologist — Mon, 15 Sep 2008 23:38:29 +0000

NFS vs. iSCSI in a VMWare environment…

I think the best vendor marketing campaign in recent storage history has been the full force attack of NetApp against iSCSI for use with VMWare. Now, I can fully understand NetApp not wanting any customers using their “iSCSI”,but iSCS…

By: Erik Bussink

Erik Bussink — Tue, 26 Aug 2008 11:20:39 +0000

This is very interesting whitepaper. I would have loved to see also the CPU utilization fluctuations, if the Fiber Channel was set at 1Gb and 4Gb (probably not natively supported by the equipment used for the test).

By: Erik Bussink

Erik Bussink — Tue, 26 Aug 2008 11:15:52 +0000

> Who cares? Cores are like tribbles…

That’s a classic, that I will remember and re-use

By: Benj

Benj — Mon, 25 Aug 2008 16:19:44 +0000

I personally suspect that relative numbers are used because the actual cpu cost of the storage traffic is rapidly becoming a non-issue. VMworld 2007 also had a session with a powerpoint that provided relative numbers not absolute numbers. With small I/Os (8kb) on iSCSI, I have seen about 1 Mhz per IO (that includes both VM CPU + Host CPU) on software iSCSI. For my workloads, I can assume one core worth of CPU will be busily doing IO work. Who cares? Cores are like tribbles…

I would choose a protocol based on other factors.

By: slowe

slowe — Sat, 16 Aug 2008 12:37:12 +0000

Vaughn,

Right, I believe that’s what Jack was clarifying above. Any clarification as to why potentially misleading relative percentages were used for CPU utilization? I can see that it makes sense with regards to throughput, as Fibre Channel is considered the “standard” for storage throughput. But why use relative numbers for CPU utilization?

By: Vaughn

Vaughn — Sat, 16 Aug 2008 04:42:14 +0000

Scott – I believe your comments on the CPU overhead was misinterpreted. The results are relative percentages. For example if one test has 10% CPU utilization and the second test has 15%, than the relative difference is 50% where the actual difference was 5%.

By: Jack McLeod

Jack McLeod — Fri, 15 Aug 2008 14:12:01 +0000

Two things I’d like to mention.

First, VMware and NetApp produced this TR jointly and this TR is co-branded by both NetApp and VMware. In order to achieve co-branding VMware did an independent confirmation of our results using the configuration detailed in the TR and they achieved the same results. Their equipment was slightly different, but they followed the same testing methodology that we used.

Also, the CPU numbers are all relative in comparison to Fibre Channel. While I’m not at liberty to give exact numbers (and the numbers following are in no way representative of any of the tests), if FC had a 15% CPU utilization and iSCSI had a 25% CPU utilization then that number would actually show iSCSI as being about 67% higher than FC. The formula breaks down to ((A-B)/B)*100, with A representing the actual iSCSI percentage and B representing the actual FC percent.

By: slowe

slowe — Fri, 15 Aug 2008 00:39:35 +0000

Matthew,

I do agree that the likely winner in the long-term is FCoE, but–as you pointed out–it’s likely to be several years before that happens.

Again, I have to go back the mention of “thin provisioning” on NFS…if you are referring to the VMDKs, see the article I wrote that’s linked above. If you are referring to thin provisioning the FlexVols, keep in mind that we can do the same thing with LUNs. In fact, thin provisioning FlexVols and LUNs is a recommended course of action if you are going to also use deduplication.