Storage Nation

1.  Everybody has it. 2.  All implementations are the same.

(Federation Square, Melbourne) There have been some excellent discussions recently in the storage blogosphere and on Twitter about the concept of Storage Federation among a number of storage people; known by their Twitter IDs as @stuiesav , @storageanarchy , @rootwyrm , @davegraham , @bwhyte , @ianhf , @esignoretti , me ( @3parfarley ) and others – as the interest continues to increase.  There are two aspects of the discussion that I think are fascinating: first is the role of social media as the means to include customers, vendors and others in an open discussion that typically is conducted privately by a vendor preparing to release a new product or feature, second is the challenge of defining a storage capability with sufficient focus and vendor independence so that is is meaningful. There has been some amount of skepticism about this effort, suggesting that we are predetermined to end up with ambiguous terms that can be interpreted (spun) by anybody (any vendor) to mean anything (our product does it).

I wrote a post yesterday that showed IOPS calculations for a few different native wide striping configurations and I thought I'd add storage tiering to the mix today.  Native wide striping places data from all volumes across all drives in the array (or of a certain drive class if you have mixed drives in your array) and randomizes workloads across all resources.

Latency-sensitive applications are the best candidates for storage tiering to SSDs with 3PAR's AO (Adaptive Optimization .Typically, these are: High performance transaction processing, like securities trading, or Single threaded applications that are idle while storage I/Os complete People ask about Microsoft Exchange and I tell them it benefits a great deal from big, wide striping, but not much from tiering because Exchange performance is mostly a matter of providing adequate throughput. An app that people run daily but is seldom associated with transaction processing is backup.  This SWCSA video discusses backup as well as the prevailing shift to dashcams and the implications for SWCSA branding.  

Chuck Hollis had an excellent post last week, discussing caching.   About 10 years ago a small team that I was a part of looked at starting a company that would do something similar to what IBM's SVC does.  The idea was to create a SAN front end controller with a lot of cache memory that would virtualize  "downstream" storage and provide performance boosts through various techniques such as caching, striping, and multi-way mirroring.  We gave up on the idea when it became apparent to us that the project was quite a bit larger than we initially thought and it was unclear when we would ever have sufficient resources to get a competitive product to market. I think we could have sold the idea to venture capital investors who were throwing money at storage startups, but we couldn't sell it to ourselves. For those of you that wonder why I tend to think SVC is an important product, that's why – I know some of the things IBM did to make it work and I admire their ability to bring it to market

Separated at birth? There have been some interesting discussions lately about storage tiering   And just because 3PAR beat most everybody else to the punch this week with our AO announcement , I think it's important to keep things in perspective – storage tiering does not solve everybody's problems

Yesterday, 3PAR announced Adaptive Optimization (AO), our solution for storage tiering and support for SSD flash drives. Here are the elements of this technology that I believe will have the most impact on customers and the rest of the industry. 1) Tiering works by making copies of data on lower cost, low-IOPS storage to high-IOPS storage – and back again.  Storage tiering has been associated with ILM, which assumed data is initially located on more expensive, high-IOPS storage and, as it ages and is accessed less frequently, is moved to lower-cost, low-IOPS storage. The perception that tiering implies fast to slow data migration was reinforced by Compellent with it's early entrant storage tiering technology, Data Progression .

A couple posts ago , discussing Netapp CEO, Tom Georgens' now famous quote on tiering , I wrote: To be fair, Georgens DID get support from the contrarian Drunken Data.  This was the only reference to Jon Toigo and his blog. Apparently this thoughtless insult set Jon off because a week later he wrote a whole lot of overkill  in response.  Considering the effort he made, it doesn't seem fair to just ignore it all.    1.  I listen to customers, so do Chuck Hollis, Barry Burke, Mark Twomey, Val Bercovici, Alex McDonald, and most of the vendor bloggers.

Unlike many of my fellow bloggers, it seems, I have been engaging with consumers — nearly a hundred in the last two weeks — and gathering their insights about this whole tempest in a teapot called on-array tiering.  That’s code for 1) establishing a tier of Flash SSD in a conventional disk array, 2) adding

While some have wondered whether or not EMC was going to be able to get their FAST product announced this year, others have been keeping their heads down getting work done.  For instance, Symantec, who today announced their Dynamic Storage Tiering feature for SSDs in their Storage Foundation products. Of course, many probably wonder why the heck I'm writing about this seeing how 3PAR doesn't have support for SSDs in it's products yet.  That's easy. A v-Max with FAST is going to be more of a science project than a production system that actually gets work done.  I'm more concerned about customers buying somebody else's SSD-enabled array and using it with Symantec's Dynamic Storage Tiering than I am about FAST on v-Max. But I'm not that concerned because the SSD market has been slow to develop – even by EMC, the company that has been leading the charge (and inventory buildup).  And even though they like to point to the check boxes in the feature checklist, big wide striping (the kind that flattens disk contention problems) with a v-Max is still an exercise in storage contortionism, unlike on a 3PAR, where its the default behavior