Splish splash, don't take that EMC spinbash

StorageBod wrote today about the wrist action Barry Burke used to spread EMC smack about 3PAR.   Here's the part I like best:

 "3Par took wide striping and made it useable; EMC’s historic implementation using metas and hypers was painful and with the large arrays of today it becomes a full time job to performance manage an array. 3Par made it easy and much kudos to them for doing so. I think 3Par’s legacy will be the ease of management that they have brought to the Enterprise array (and thin provisioning)."

So much for the EMC one-click myth.

Being a good leader of customers, StorageBod likes to grind on vendors for the stuff that matters, like not having software to take advantage of hardware.  This is not an EMC problem, of course - all vendors struggle to get the software released that enables hardware to do great things.

He also likes flattening vendor spins into discussions of dueling features, even though he knows that implementation differences between bolt-on and designed-in technologies matter a great deal. That's being a smart customer because, in the end, product parity is one of the best ways to drive down pricing.

As I said before, we are happy to invite customers to compare our designed-in wide striping and thin provisioning with any other configuration from any other vendor.  Follow these links to 3PAR's  and   Hitachi's  SPC-1 Benchmark reports and check out Appendix C, where it shows all the steps necessary to setup wide striping. The difference is enormous.   EMC of course, doesn't participate in SPC-1 benchmarks, but if they did, their configuration setup data would resemble Hitachi's in length and complexity.  Of course, everybody knows that, except maybe Anarchist, the world leader in SPC bashing. 

Speaking of published numbers, we have some new ones today for Exchange Server 2007 that include thin provisioning (and of course, our completely automated wide striping).  TP performance is very, very close to non-TP performance. Make THAT comparison with other vendors.

The notion that wide striping demands a trade-off between performance and capacity utilization is just FUD. It might be true for bolt-on wide striping implementations, but not 3PAR's.  The highly parallel and randomized nature of 3PAR arrays get more I/Os from every drive than any of our competitors -  with the exception of Exadata - a highly tuned, single purpose database appliance.  But it's not all about high performance necessarily because 3PAR wide striping easily supports multiple service levels including lower cost SATA drives and mixed RAID types, which means tiering is very easy to accomplish with one of our systems.

Comments

[the storage anarchist]

You took the quote out of context - 'Bod clearly compares your CURRENT approach with Symm's HISTORIC approach. Yeah, he doesn't like the "old way," but his comments don't reflect an opinion on the "new way" to provision a Symm.

I myself pointed out that the "old way" was too hard for many of today's environments.

And yes, I know it's a lot easier for recent market entrants to compete against the Symmetrix of 2002, but today you can thin provision and wide-stripe a Symm with only slightly more complexity than either a 3PAR or an XIV.

And existing customers don't have to migrate to a new platform, rewrite scripts, or sacrifice any of the functionality that has made Symm the #1 storage platform for 18 years straight in order to reap the benefits of The Next New Feature.

They can also enjoy the consistent <1ms response times of EFDs without any waiting to boot!

Keep on Rappin', Marc!

[nate]

Hey Marc

I was looking at the T800 disclosure doc and was wondering why 3PAR set the volumes up with the createaldvv command instead of just createvv ? I have seen the createaldvv command in the past but have never seen the need for it. It appears to create VVs that have a "static" user space as opposed to a "fully provisioned" user space, what is the difference? 99.99999% of my VVS are TPVV, I've only fully provisioned a VV in advance on a couple of occasions(and it was only ever for testing).

My array tells me the createaldvv command is depreciated too.

Also what's the advantage with going for two small different VV sizes?(286G and 573G) vs going all 2TB VVs.

Browsing through the HDS doc, your right reading that stuff makes my head want to explode, it's worse than managing Cisco IOS.

HDS did tell me last year they were going to have SPC numbers posted for the new AMS 2k, though seems they haven't gotten round to it yet.

I don't have the doc handy but I dug up a PDF on HDS's site last year talking about performance tuning, and I swear the in the first paragraph, or maybe it was the first sentence of the doc it mentioned how you can get their professional services to help you. Thought it was amusing ! What a way to lead into a document about tuning.

[marc farley]

Nate, let me talk to the benchmarking people and get an answer for you. I don't know off the top of my head.

[marc farley]

Barry, its nice to see you getting a little focus again. I was concerned that you had lost your edge. That post of yours was all over the place, like roadkill.

[the storage anarchist]

Yeah, Sunday driving blogging will do that to you :)

[marc farley]

Nate,

The engineer who ran the SPC-1 test thought it was interesting and amusing - and he was very impressed that somebody took the time to look at the details. He was a newbie here at the time and used the wrong command by mistake - he now uses createvv for everything. But he uses aldvv and so that's what belonged in the SPC-1 report. He also told me he's looked at performance differences between configs generated with both commands - because he was curious - and that and that he saw no difference.

The two different volume sizes relate to the way the SPC-1 workloads are exercised and the impact they can have on the host side. The volumes were setup the way they were to alleviate host-side queue delays.