Around the Storage Block
Showing results for 
Search instead for 
Did you mean: 

Built for flash



A common theme emerges from flash startups when discussing other, more established storage platforms:  “Storage Vendor ‘ABC’ is a legacy storage array retro-fitted with flash but not built for it.”

I agree. But that's because there's no such thing. There's no such thing as "built for flash" or "legacy storage retrofitted for flash." Be it startup or legacy vendor, it makes no difference. The only thing that matters is how the storage solution optimizes and protects I/O. Let me explain.

Everyone who has ever seen a 3PAR StoreServ video or sat through a 3PAR StoreServ presentation has seen this slide:



But not everyone fully appreciates what is actually going on in the picture—not even people who used to actually work with, design and sell 3PAR. 3PAR StoreServ is not “legacy storage” or a “traditional hardware platform” and definitely not the product of an all-flash startup. Not even a little.

3PAR StoreServ is an IO processing platform designed to optimize and protect IO

That is all 3PAR StoreServ has ever been AND it is why it is the only platform able to deliver maximum performance and capacity consumption from the first drive to the last.

Can another platform claim they have no dependency on media or medium? Of course not! Hardware, any hardware, is ultimately a commodity. Realistically speaking hardware should be the bottleneck in any storage architecture. But this isn’t the case with most systems.

Fundamental flaw of inferior designs

Legacy platforms like VMAX or Hitachi’s USPS are designed to be ‘cache dependent’ to offload the negative impact spinning disk has both on IO & latency. The volumes themselves are typically restricted in access to one controller or another with “Active/Passive” LUN ownership, and leverage an underlying RAID group which restricts access to a specific set of drives. Some of these architectures add extra layers on top of the RAID groups in order to show a larger volume to the hosts and potentially extend the stripe.

Ultimately all of the existing storage platforms have a similar design: Front-end connectivity for the hosts, followed by an “inter-controller” pool of CPU and memory resources, back-end connectivity for disk and some mechanism to move data between those controllers:



But these architectures have one fundamental flaw: Front-end Host IO and back-end IO processing inevitably competes for resources in the shared CPU/Memory pool as IO workload increases. Some architectures hit this point faster than others. It is this flaw that keeps the aggregate performance power of the underlying hardware from being the bottleneck in IO delivery and handicaps legacy architectures from ever achieving full consumption of performance and capacity.

Ever see a full VMAX? It’s as mythical as the Loch Ness Monster.

Flash startups are not immune

Modern flash startups are doing a great job of creatively marketing their array designs but they glaze over the fact that the overall IO processing architecture is as “legacy” as the word itself.

Take Pure, for example. While their marketing may claim they were built and designed for flash, their basic architecture, shown below, tells a very different story. The IO Processing model of a Pure or Nimble is the same IO processing model one might find in a NetApp or VNX—Active/Active IO Distribution across the controllers up front, shared CPU/memory resources that can cause contention between front- and back-end resources, and Active/Passive Volume ownership that limits write operations to just the active/owning node:


The flaw in Pure’s architecture is highlighted by deduplication. While Pure may claim dedupe to be “in line” constantly, data reduction is not. As the front-end resources get overrun (CPU/DRAM/SLC (NVRAM)) are overrun with IO contention, Pure stops deduplicating the blocks and only mark them to be deduped later during garbage collection.

For this type of architecture, “Built for Flash” just means: Preserve the write endurance of the SSD at all costs. And while Pure makes every attempt to do just that, it is still not designed to maximize the benefit of Flash. It is, in fact, designed with a dependency on flash.

Architecture matters: optimized for IO

The 3PAR StoreServ architecture is designed to leverage the aggregate resource capabilities of the underlying hardware itself. No other storage platform can truthfully, and with no misdirection, caveats, or omissions, make the same statement.


3PAR StoreServ’s parallel processing of IO, where data and metadata are processed individually through ASIC and CPU respectively, eliminates dependency on the backend media and truly delivers on the promise of flash.

 Our distributed architecture comes complete with Adaptive Sparing—a technology that allows us to leverage spare chunklets only when necessary and not dedicated and allows us to deliver much more usable capacity per physical SSD than other vendors who use the exact same drive: 480GB, 920GB and 1.2TB. (More on Adaptive Sparing)



 If 3PAR StoreServ isn’t “Built for Flash” then why is it that *only* 3PAR StoreServ is able to attain 20% more usable capacity from the same SSD that other vendors use? 

Not claims, actual proof

3PAR StoreServ is the only storage platform, leveraging all flash, independently proven to deliver a sub-millisecond response time under maximum load. Here’s the benchmark proof.

3PAR doesn’t just claim to be 99.9999% available, it’s a guarantee. Here’s more on high-availability peace of mind. 

Only 3PAR StoreServ. . . 

-Only one architecture is proven to be 6-Nines resilient (99.9999% availability) 

-Only one architecture processes IO with no dependency on media

  • Only 3PAR StoreServ is able to leverage the hardware to its fullest allowing for 100% of performance consumption with 98% capacity consumption

-Only one architecture is truly Tier-1 in feature-set, including full replication suite, federation and integration with VMware, Microsoft and Oracle and the most granular of levels 

-Only one architecture is both “scale up and scale out”

  • Start with 2 nodes and scale it full. Scale to 2 more - 100% online and nondisruptive
  • Scale beyond one system: Simply Peer Motion volumes over to adjacent 3PAR StoreServ systems online, non-disruptively

-Only one architecture is independently proven to deliver sub-millisecond response times under maximum load.

By Jorge.jpgJ Maestre     @StorageMuscle    The World’s Strongest Technologist

HP Enterprise Solutions & Architectures Team


0 Kudos
About the Author


Our team of Hewlett Packard Enterprise storage experts helps you to dive deep into relevant infrastructure topics.


please give us vertical node pairing on the 7000-series at least, so you can survive the failure of a node shelf and only lose 1 node from each pair (I'm sure not a common scenario - but how less common is it than a disk shelf failing? I do use cage availability in all cases myself)


My 7450 was just installed on monday, only 16 SSDs but I opted for all 4 controllers up front for persistent cache.

Sunil Thazhathupurakkal

Wow!!! I like the aggression. Everyone and their dog were bashing HP while HP was busy referring to the Ethics manual. This is a refreshing change.


Thanks @suniltn.  We agree it's about time people started hearing some reality and less marketing FUD.  I guess the gloves had to come off in order to get the message out there.  And now yo can see they're all the way off:  Gotta love it!!


Hey Nate - Vish (Sr Director of Product Marketing for those of you who don't know him) asked me to tell you thanks for the feedback and request. We will take a look at this request.

NOW IT get's pace and even speeds UP ! THX for this famous explanation JM ! KR/cheers H

=== Disclaimer: Pure Storage Employee ===




Nice post on the design of 3PAR platform. I find it is best to speak to speaks to what one knows, one's own product. It is too easy to lose credibility by unintentionally misrepresenting a competitor's product and/or capabilities.


If you are so incluined to learn more about Pure's architecutre and why this upstartis the focus of major stoag vendors like HP & EMC, you can read these posts:


- Cheers,



Thanks for the comment Vaughn.  And thanks for taking the time from your numerous videos, tweets, and other social media activities to read my humble blog post.  I have a couple of questions on where you think I'm wrong:


1-  Are you saying Pure is not a 2 Controller Architecture?  (Cuz that would be an eye-opener!)

2-  Or maybe you're saying the Pure controllers are actually Active/Active and not Active/Passive (standby) even though the Controllers actually failover (as shown in numerous videos you guys shamelessly plug on YouTube)?

3-  Or maybe you're saying that you're really a 'scale-out' architecture and that the ACTUAL capacity numbers you guys claim are much larger than the dedupe/compressed numbers you hope can be achieved?

4-  Or, perhaps you're saying that the 80% write-cliff that you guys hit isn't a real number and the actual testing numerous customers have seen is really just "wrong"?

5-  Or maybe you're saying that "Built for Flash" really means you took an "MSA-like" architecture and designed your code to specifically address SSD with an end result of limited IO (Based on your own spec sheet that you publish on your own website), limited scale (again based on your own spec sheet on the same website), and limited backend write attenuation since your OS is constantly trying to achieve a committment to a 512b boundary?  (Again all of this is from your website.)


Don't get me wrong, I think Pure is a great little storage array.  And I also think you marketed it to the right audience:  Low-end spinning disk replacement is a fine place to be.  Buy it in the price range you guys love to target 30-50K


As far as credibility goes, maybe, just maybe, I prefer to do my own research on the subject rather than listen to you guys go on and on and on.  Especially considering how you guys so often change your story.  Is that why you don't publish any whitepapers?  Easy to say one thing and actually do another, or actually say one thing this month and another thing next month, if we can't see the whitepapers.  Nice strategy by the way!


While I'm on the subject...Remember when you used to say "Our dedupe is inline"?  I liked that video.  Well now that everyone knows it's not true, what did you change that to?  


As for 'credibility', I think I'll keep mine where it is:  shiny, happy, and actually real.  Shoot me a private note on LinkedIn some time.  I'll share with you my thoughts on XtremIO.  I think I can help you guys make a really good case...Later homey.

 Agree with Vaughn.  


Clearly you do not know much about Pure's business - 30-50k is not Pure's market. Agressive is fine, but your comments sound defensive and arrogant/condescending - and essentially wrong on technical and business elements - best to stick with what you know, which I assume is HP storage.



Thanks for the feedback smarsh...


But rather than just call me "wrong" why not tell me where I'm wrong?  Tell me what it is that I've said that was "wrong"?  I'm guessing you're either a Pure employee or customer--and that's great.  All the more reason to share with me what's "wrong" about my post. 


While we're at it, a couple of points:


1- We approved all comments here but Pure doesn't do the same on their blogs.  That speaks volumes.  If you have nothing to hide, if I'm "wrong, why not call me out on it and point out where.  Publish a white paper while you're at it.  That would help prove me wrong too.  Clearly Pure does neither and that absolutely reeks of "something to hide" which is disappointing.


2- Arrogant?  Not at all.  Hard to read arrogance into what I wrote.  You're definitely projecting that.  Condescending?  Absolutely.