One of the perks of attending the HP Discover conference in Barcelona is getting to sit down with the executive teams for various business units. I spoke with David Scott, SVP & GM of HP Storage, to discuss a series of announcements that hit the air waves yesterday. Out of this conversation, and with collaboration of other peers at the event, I wanted to ponder on a few points around the concept of using all flash disks inside of a storage array. In fact, you can listen to a conversation between Calvin Zito (HP), Chris Evans (Architecting IT), and myself talking about all flash arrays.

[symple_box color=”yellow” text_align=”left” width=”100%” float=”none”]
Note: All travel and incidentals were paid for by HP to attend HP Discover. No other compensation was given.
[/symple_box]

Leading with All Flash Arrays

Design follows a consistent process – start by discovering the use case and requirements driving a project, collaborate and shape the future state strategy, and think up solutions that meet (or exceed) the project’s needs. The conversation should initially avoid product and focus on gathering requirements. By painting a picture of the landscape, such as “We need to support 20 SQL databases that are write intensive during nightly ETL (Extract, Transform, Load) jobs” or “The storage array must be able to handle 750 TB of data without blinking an eye,” an idea of what product(s) will meet the need begin to emerge. The selected solution must be able to handle the requirements – in this example case, an “intense” amount of writes at night (deeper dive into this would be required) and also hold 750 TB of data. This knowledge narrows the field down to a few solutions, and is required to mitigate the indecision caused by having too many choices. Yes, this really exists (we as humans tend to have more trouble making a choice when we have an increased amount of choices).

An industry colleague of mine by the name of Chris Evans, who writes at Architecting IT, has tackled a topic that I’ve been following with some keen interest on All Flash Arrays (AFA). First off – this isn’t about which vendor is better than anyone else. I view almost all solutions as tools in my belt – such as a hammer, wrench, and screw driver all have value for different home improvement projects – and I try not to depend too heavily on any one tool. I chatted with Chris about his post while at HP Discover in Barcelona, mainly around the concept of leading a design with an AFA. At this point in the flash pendulum swing, I see little value in planting a flag in the ground and declaring “I will only look at AFAs” without having first gone through and gathered requirements, in which his post does an excellent job at opening a discussion to look at the feature parity of a variety of solutions that are configured to only use flash devices.

In a not so distant future (10 years?), the AFA will likely become the main stream architecture for organizations looking to consume storage via an external array, while spinning disk will support archival and backup data needs. Flash will both drop in price and increase in capacity, making this leap logical (it’s not there yet). I see hybrid flash arrays, which use a mix of flash and spinning disk, nicely filling the gap of price vs performance for the vast majority of today’s use cases, but with future “monster sized” flash devices – let’s say cheap, consumer grade MLC or eMLC at 1~4 TB per device – writing hot data to spinning disk will increase in rarity.

[symple_box color=”yellow” text_align=”left” width=”100%” float=”none”]
You can also see Calvin Zito’s post (HP) or Vaughn Stewart’s post (Pure Storage) for their AFA comparisons.
[/symple_box]

The Pedigree of an Architecture

The other sticking point that seemed to have a funky odor to it was the debate over what constitutes an All Flash Array. Is it just a storage array filled with flash, such as my all flash Synology DS2411+ with SSDs? Or is it something more – an architecture actually built for handing flash, and all of its subtle caveats (garbage collection, full page write, space reclaim, etc), for long-term enterprise performance? I’d argue for the latter option; my Synology array would certainly not count. While it does have the capability of handling flash devices and reading / writing data to them, it doesn’t really have any special bits under the hood for optimizing for flash. There is some minor levels of TRIM support, but nothing I’d really get excited about.

But to some, a storage array that handles flash drives must be architected from the ground up – such as leaving off the HP 3PAR storage array from comparisons.  That seems a bit silly, considering that HP’s 3PAR 7450, which is designed to contain only flash disks, was able to bench 900K IOPS with a 4K random read workload with less than 1 millisecond of latency – certainly no slouch. This is up from a published 550K IOPS number prior to a software update. And while I think random read benchmarks are silly (how many customers never write data to their array?) it does show a pretty significant improvement in performance over the old number. Add a dash of the “polymorphic simplicity” introduced with 3PAR’s suite of features and its speedy bench numbers, on top of having a model tuned for all flash, firmly pegs it in the AFA category.

Thoughts

Cramming SSDs into a legacy storage architecture will technically function, but is an invalid entry into the world of All Flash Arrays – the array would abuse and destroy the disks, while often missing the boat on a bunch of ways to squeeze real performance out of flash. So long as thought has gone into the design and storage operating system in such a way that the array knows and optimizes the IO stream for flash, it should be able to successfully function in an all flash configuration. I think Chris has done an excellent job at taking point on examining a number of AFA offerings that were painfully missing from the first few rounds. With that said, it’s still important to lead with requirements and make sure that an AFA matches them in a meaningful way.