FUD Dud – A Gift From EMC
by Claus Mikkelsen on April 30, 2010
Thank you, EMC. It’s not often I get to offer my appreciation in public.
Now, to those of you readers that think EMC and HDS have patched up any differences we may have had, think again. This discussion is all about FUD – Fear Uncertainty, and Doubt – or as I call it, if you can’t compete by building a better product or solution, try whacking the other guys in the knee caps.
But this example is so absurd that I can’t believe EMC actually took the time to prepare this chart. But thank you, EMC, for it gives me a chance to publicly rebut what is normally only shown to customers in private.
There is a chart floating around that apparently is being shown to, or delivered to, our potential customers as an attempt to demonstrate how evil our storage virtualization product is. Please note that this comes from a storage company with its own storage virtualization product, InVista, that has had rarer worldwide sightings than the Madagascar Pochard (that’s an almost extinct bird, BTW).
So briefly, we handle storage virtualization by allowing our customers to essentially plug in any storage array from any vendor to our USP-V or USP-VM and voila, it’s virtualized. We call this external storage. And as part of this great feature, we offer recommendations or “best practices”, which is the source of the chart that EMC is peddling. The chart describes where different data types are best placed. And, I might add, being a performance claim, it is very conservative in its recommendations. It doesn’t say you can’t put your most performance-critical Oracle database on SATA drives on an external array, there’s nothing stopping you, but why would you? So when I look at this chart I certainly see nothing wrong with it, and certainly nothing that would indicate (in EMC’s words) “Application performance with virtualized data is a serious concern with this architecture”.
Now to be cautious, I did not include the REAL chart that EMC is handing out since it has EMC logos all over the place, but included in their handout is the chart below which is taken in its entirety, from our HDS Users Guide. What EMC is handing out is very slick and well done, mind you, and I wish I could include it in it’s entirety, but that would be improper. I think. I’m tempted, but I won’t.
|
Application |
HDD Type |
|
|
FC Drives |
SATA Drives |
|
|
Database OLTP |
Not recommended |
Not recommended |
|
File operation from host (both read and write) |
OK |
Not recommended |
|
File operation from host (mainly read) |
OK |
OK |
|
Backup |
OK |
Recommended |
|
Archive |
OK |
Recommended |
Let me offer some specifics to address this silly claim by EMC:
- We run performance tests on arrays in their native state, then virtualize them and run the same benchmarks. Guess what? Performance in terms of throughput generally improves, meaning that that database running on your DMX might actually perform better after it’s been virtualized. We still recommend you move it into internal (to the USP-V) storage (non-disruptively, of course) to get even better performance. That’s what this chart says.
- Hitachi Dynamic Provisioning (HDP) was implemented in a way that can dramatically improve performance. I’ve seen benchmarks where HDP on SATA drives outperforms the same workload on FC drives without HDP. And HDP works on external storage as well, so this is all goodness.
- In our virtualized storage environment, we can move data non-disruptively, meaning if that application isn’t performing as well on SATA as you thought, move it to tier 1, or “tier 0” SSD’s. Not to worry…
So I tend to get a bit cynical taking advice on storage virtualization from a company that can’t even build a viable storage virtualization platform. It’s also curious that the company that is making these weird accusations has never submitted to any 3rd-party performance tests of their products, such as SPC.
So when presented with a variation of this chart with bogus accusations, be wise and be cautious, for the courier is not representing it correctly. The chart is accurate as it stands, and any claims that there is something wrong with this architecture is, well, FUD.
Comments (1)
Joseph Murphy on 02 Aug 2010 at 5:18 pm
Claus let me ask some clarifying questions on the specifics you offer “to address this silly claim by EMC”. Claus you say “We run performance tests on arrays in their native state, then virtualize them and run the same benchmarks. Guess what? Performance in terms of throughput generally improves, meaning that that database running on your DMX might actually perform better after it’s been virtualized.”
Are you claiming that an array “virtualized” behind a USP-V with volumes not resident in the USP-V (or internal to the USP-V as you say in the next sentence) will outperform a direct attached array if both configurations are running the same workload?
Claus you say “We still recommend you move it into internal (to the USP-V) storage (non-disruptively, of course) to get even better performance. That’s what this chart says.”
Perhaps you answered my first question with this admission. What your chart says is that HDS does not recommend running a Database OLTP workload with data being “virtualized” by USP-V arrays. What is so hard to understand about that?
Claus you say “Hitachi Dynamic Provisioning (HDP) was implemented in a way that can dramatically improve performance. I’ve seen benchmarks where HDP on SATA drives outperforms the same workload on FC drives without HDP. And HDP works on external storage as well, so this is all goodness.”
I agree with you; Thin Provisioning can offer improved performance to workloads IF the customer invests in enough real disk drives to allow the Thin Provisioned LUNs to be spread across more that a single RAID rank of eight disk drives.
Claus you say “In our virtualized storage environment, we can move data non-disruptively, meaning if that application isn’t performing as well on SATA as you thought, move it to tier 1, or “tier 0” SSD’s. Not to worry…”
How do you decide where to move the data that needs better performance? How are these movements initiated? How do you suggest customers mitigate the impact of the data movement?
Claus you say “It’s also curious that the company that is making these weird accusations has never submitted to any 3rd-party performance tests of their products, such as SPC.”
Claus, you and I both know that the SPC provides little or no information that a customer can use to determine how an array will perform in the customer’s infrastructure. Suggesting that a customer examine an SPC benchmark of a fully configured array in which the vendor has the total storage capacity mirrored and then uses only 1/3 of the available capacity to do I/O applies to no real world customer I am aware of, how about you?
Claus you say “So when presented with a variation of this chart with bogus accusations, be wise and be cautious, for the courier is not representing it correctly. The chart is accurate as it stands, and any claims that there is something wrong with this architecture is, well, FUD.”
While I know that “virtualization”, “cloud computing”, and “storage in the Cloud” are the current directions in the computing industry, IMHO at some point you just have to “get real” and this is one of those points. Someone once said “The truth will set you free”, let me help you to set yourself free!



