We may face each other often on the battlefield, but I relish every battle :-) My good friend an colleague Vaughn Stewart has joint the blogosphere - check it out, and add it to your reader!. Vaughan - welcome, and drinks are on me at VMworld!
Vaughan, I love ya, man - but come on (seriously) on TR-3697 - it's like something Chuck would make :-) I love NFS storage for VMware - it doesn't get the love it should, I love iSCSI storage for VMware, I love FC storage for VMware, I love FCoE storage for VMware (and on this one, although I literally have at least a few grand riding on iSCSI, I've come around to the "it's not a conspiracy" view like Dave has here - though "wait" is subjective - VMworld is right around the corner). So long as it's storing VMs and the customer is happy, I'm happy.
"The goal of this testing was to compare the throughput capabilities of ESX 3.5 with NetApp storage using FC, iSCSI, and NFS protocols in a real world environment."
Ok, if that's the case, what's the scoop with:
- 4K/8K IO size only
- 2Gbps FC
- You guys have "throughput/IOPs" shown only in relative, not in absolute.
- 84 144GB drives with 16 VMs driving the IOMeter workloads with * 10GB of data each on them = 1.3% utilization (rounding up!).
This is a workload and a comparison chart that Netapp dreams of - but unfortunately doesn't match the noble testing goal. I love NetApp filers. I own them. I have bought them with my own $$. What they do they do extremely well - but WHY do you guys insist on running workloads in these benchmark docs with these crazy low utilizations??
WAFL = greatest strength in some use cases; greatest weakness in others. That's not BAD, that's engineering. Engineering is all about tradeoffs.
WAFL's tradeoff is free snapshots in exchange for non-linear performance under normal workloads and normal utilization. It's your superpower, and your kyptonite. Kickass write perfomance when there are loads of free spaces to write to. Another manifestation is post-process deduplication - but not not pre-process (which no one has figured out for production storage but is our goal) which is really another GREAT manifestation of WAFLs underlying characteristics) Good read performance overall. Poopy write performance when it's random with a full and fragmented filesystem.
BTW - do NetApp filers catch fire under this condition - NO, but they do slow down. In the same way our arrays don't catch fire with snapshots (as much as you guys say they do). But both are designed for different tradeoffs.
Again - that's not bad, that ENGINEERING - it's all about trade-offs. EMC has many of the same sort of things, in different places. You guys make great platforms, so do we.
Come on, let's not be Chuck here. If you wanted to be real-world - let's do a broad set of IO sizes... you're a smart dude (you REALLY are) - so let's see it at 64K (the current max, larger than that and ESX starts chopping them up. Let's see that a 10%, 20%, 50%, and 80% utilized. Let's see it after a few days of random workload.
I would expect you would see the same thing I see, and the same thing VMware sees (this is covered here - btw, this doc is flawed also - broad IO ranges, but 100% sequential write and read only - but I don't feel bad, those are workloads that favor WAFL over traditional block layout schemes):
Let me summarize (both TR-3697, EMC's docs, and VMware's docs agree!):
NFS and iSCSI are fantastic and near FC in throughput and IOPs on small (4/8K) IO workloads (though consistently higher in CPU utilization - though MHz are close to free these days), but they diverge (this is not bad, it's expected) at large IO sizes, and large througput workloads - even with 2GBps FC (which is the chart above from VMware) - which no one even buys anymore. This is different with 10GbE and jumbo frames of course.
When you publish a benchmark that shows "we filled this to 70%, ran it with a random write workload for 3 days, and THEN ran the benchmark, and we compared it with current FC technology", you can come over for dinner :-) Ok, screw that, I'll buy dinner AND drinks at VMworld!
Ok, that off my chest, I will NEVER let my blog (or me) devolve to being anti-NetApp. You guys are a great company, a great competitor, and are filled with great people. I relish competing, because it brings out the best in both of us (except silly stuff we each do to compete with each other) and that's good for us both, but more importantly, good for customers. I've said it publicly before, I'll say it again:My comment:
"For what it’s worth – personally, certainly I don’t necessarily represent EMC in this context – I appreciate having as formidable a competitor as Network Appliance. With other competitors, we compete with them, and it’s a slow waltz, but with you folks, it’s a tango. It makes us better, win or lose with any individual customer, and in the end, it’s good for the industry and the customers."
And Dave Hitz' comment:
"I completely agree. I feel the same way about EMC."