3.022: powerful, trusted and smart...meet dumb and dumber

So I posted back in January a two-part review of the key differentiating features and capabilities that make VMAX Fully Automated Storage Tiering for Virtual Pools (FAST VP) so much better than anything any competitor has put forth to date (or since, for that matter).

If you missed the posts, 3.018 is part 1 and 3.019 is part 2.

Oddly, I received nary a peep from either competitors or their customers about this post, which I found somewhat odd at the time (there was the one commenter who chastised me for being such a VMAX fanboi – sigh!).

Since those posts, I have had the opportunity to become better educated about the implementations of automated tiering from some competitors, including IBM (Easy Tier), Hitachi (Dynamic Tiering), and HP 3PAR (Adaptive Automation Optimization). Vendor documentation and best practices guides mostly, but I also gleaned some information from competitors' and independent blogs along with personal conversations with several with first-hand knowledge.

In my assessment, competitor silence in response to FAST VP simply underscores the assertion I made in those posts that VMAX FAST VP is in a class alone in comparison to those other products.

 

a quick survey of fast vp competition

• IBM's EasyTier is indeed simple, but it is also probably the most inefficient and ineffective implementation of the lot. Observations are that it takes upwards of 24 hours to react to workload changes, requires at least 4X as much flash (and a minimum of 16 SSDs) as FAST VP while slogging huge 1GB of data blobs of data between the 2 tiers that it supports. Simple is as simple does…hardly sufficient for anything but the least demanding mid-tier type applications.
• Hitachi's Dynamic Tiering is in fact barely dynamic, requiring a rather heavy amount of I/O demand for extended period before it decides to move data. Worse, HDT requires the use of the "manual mode" CLI for all but the most static of workloads. In fact, Hitachi's own best practices documents recommend against using HDT for unpredictably dynamic workloads where the working sets change frequently or multiple times per day. If not intended for dynamic workloads, then why is it named Dynamic Tiering?
• 3PAR's chunklet architecture requires so many SSDs to balance the load across their nodes as to be cost-prohibitive – even with the (rather expensive and slow) 50GB SSDs are offering. The performance improvements appear marginal in the real world, due at least in part to the sheer overhead of relocating data across nodes and drives and RAID sets. "Costs more for negligible improvement" is rarely a sustainable competitive advantage.

Of all the implementations I've looked at, FAST VP is clearly the most efficient in data movement (both size and speed of relocation) and the most responsive to changing workloads (minutes vs. hours or days). FAST VP is the only implementation that allows for setting policies on a per-application basis rather than at the pool level (where all applications must compete for the same resources). And only FAST VP provides copy QoS controls, workload prioritization, and customizable schedules for monitoring workloads and for relocation time windows.

Friendly reminder: I am admittedly biased, and these are my own opinions.
Take them or leave them…

If you are considering automated tiering solution to maximize your performance while minimizing your overall storage costs (CAPEX and OPEX), then FAST VP stands alone as your best bet.

And if you are NOT yet considering automated tiering for your next storage acquisition, then you are probably going to pay too much for your storage. With FAST VP on VMAX, most workloads will run faster, cost less, and be more space, power, and cooling efficient than with competitors' all-HDD configurations. And while competitors will claim "me too" should you bring up the Fully Automated Storage Tiering advantage, you should probably ask yourself why they aren't LEADING with their automated tiering configurations.

Better yet – ask them why they're still bidding "old school" storage solutions at all…

 

technorati tags: EMC,Symmetrix,VMAX,FAST VP,Fully Automated Storage Tieringi,IBM,EasyTier,Hitachi,Dynamic Tiering,3PAR,Adaptive Optimization

Comments

[Wout Mertens]

I notice that you don't mention NetApp's Virtual Storate Tiering, perhaps because they're not really tiering but instead caching?

What are your thoughts on this model? Is tiering still relevant if you have lots of flash cache?

[the storage anarchist]

Caching is not tiering, and there can be no doubt that the two are complementary - Symmetrix uses a very large DRAM cache as its foundation, and tiering yields meaningful added performance benefits to VMAX.

For another example, you can see the benefits of combining Flash-based cache with Flash-based tiering in this blog post about a CLARiiON customer's experiences.

Two important things to consider when comparing tiering and caching:

First, caching requires ADDITIONAL Flash capacity, while Tiering does not. With caching, there will always be two copies of date in the cache, while with tiering there is only the one.

Second, and of particular distress to NetApp users, caching writes to flash is not always supported, where tiering (by definition) supports both reads and writes to every tier. CLARiiON does cache writes to FASTCache, NetApp does not.

There has been some speculation that the flash devices NetApp uses are not well suited for mixed read/write workloads, and that they are particularly poor at handling large block sequential writes (WAFL turns random writes into large block sequential).

The flash devices that EMC uses in VMAX, CLARiiON and VNX are specifically selected to handle mixed read/write random and sequential workloads.

[Andriven]

I'd be very curious to have you do some in-depth comparison on Compellent's tiering (can handle shortstroking, etc.) vs. FAST on VMAX.

Realizing of course that Compellent and VMAX don't really compete in the same space...

[Barry Whyte]

Barry,

Easy Tier on SVC and V7000 is driven by the pool extent size, so is configurable between 16MB and 8GB.

WRT more than two tiers... the initial advantage of a function like EasyTier is its ability to make best use of SSD. That is, we have a very expensive ($/GB) medium that provides massive performance (IOP/GB) therefore the best way to use SSD is to spread the IOP over an entire enterprise.

Thus EasyTier.

HLM, i.e. archiving cold data, yes that useful for making use of SATA.

However, if we'd all thought that the 2, 3x difference between 15K and 7.2K meant we needed tiering, wouldnt we all have implemented EasyTier, FAST or VP etc 10 years ago???

Thats not to say that multi-tiering cant help, but EasyTier is aimed at gaining benefits from SSD.

[the storage anarchist]

BarryW-

Good to hear from you again!!!

And your comments do help explain why IBM SimpleTier is so inefficient.

If you focus only on getting performance out of SSD, you wind up with a very expensive solution - especially on the DS8K where the minimum # of SSDs is 16!

Including lower $/GB SATA in the solution enables FAST VP to cost less while improving performance.

Similarly, supporting only 2 tiers limits applicability of the implementation to applications whose working sets remain constant continually. Many (most?) enterprise applications' working sets will change quickly and often - day-time transactions and nightly batch runs, for example. During the batch job, the working set will likely exceed available SSD, but be far too slow if served off of SATA...hence the "middle tier" of 10K or 15K HDDs.

IBM SimpleTier's extent size is always larger than FAST VP (SVC, V7000 and DS8K), and thus is always moving more "cold" data with every bit of "hot" data it promotes...very wasteful of an expensive resource.

Finally, since SimpleTier defines the ratio of Flash+HDD at the pool level, all applications must compete for the same resources. With FAST VP, each application can have its own policy and priority, allowing customers to optimize the most important applications, even as they share pools for maximum utilization.

Thx!

[Kevin Draper]

Bias is an understatement. You mention nothing about cost or do you bring up the performance implications of using FAST with VNX. The added CPU cycles to track the meta data now matter what size can be upwards of 30%. If you are running 20% on your CPUs another 30 is no problem but no customer can afford to run there systems at 20%. If you go beyond that you you loose the ability to do non disruptive upgrades, which again most customers have requirements of 24x7 with minimal to no downtime. Also what are you really getting from tiering? Space savings? I know it's not performance because EMC states FAST is not implemented for performance, although in some environments where the storage has been designed incorrectly may benefit. Just my two cents.

[the storage anarchist]

I'm not a VNX guy - these comparisons are to VMAX FAST VP and compeitive offerings in the enterprise storage space.

However, my understanding is that while FAST VP has some overhead on VNX, using FAST Cache with and/or without FAST VP affords VNX customers with significant performance benefits with minimal overhead.

[Kevin Draper]

VMAX is a whole other discussion but more around the benefit vs cost and complexity. I was a 12 year Symm guy and as robust as the architecture was, unless you have a application that needs the uptime and can justify the cost it doesn't make sense.

[Ken Steinhardt]

Hi Kevin, I think that's exactly the point here, with FAST VP there is potenitally radical positive improvement in both CAPEX and OPEX compared to not just conventional configurations but also alternative tiering products - this is NOT "your father's Symmetrix"...