Solid State Disks: Enterprise/VMware Ready or Not?

I always want to want to try stay above-board, but can't stop myself from pointing out something that's WAY off.

Read this article, then come back.....

You back?  Read on....

First of all if I was someone at HP, I would likely agree with the statement and positions in the article, because as predominantly a printer/desktop/laptop/server vendor that world view of "Solid State Disk" is kind of right.   When I get my new Macbook Pro (I can't wait!) I'm considering an SSD, but the SLC devices are too small capacity wise.   The only MLC device that seems to be worth much right now is the Intel x-25 family, and it's about 9x the price of a 250GB 7200 RPM drive (and right now, I have to buy it with a Core i7 proc :-)   SSD won't be mainstream in laptops/desktops/servers until around 2011-2012.

Wait - am I agreeing then?  NO.

There's a reason we call what EMC has been shipping for a YEAR "EFDs" (Enterprise Flash Drives) rather than SSDs.   These were developed in partnership with STEC, and are materially different.   They are SLC-based, but have large capacities (we're on our second gen already - up to 400GB capacities).  They have LOTS of extra cells, so their lifetime and read/write cycles are in line with traditional spinning rust drives.  they have extra large SRAM and more logic to handle all the write-levelling needed and buffering needed with enterprise workloads.  

AND - we needed to make changes to the arrays (DMX, CX and....) themselves to optimize for these use cases.   It wasn't trivial - and it's been more than a year and (as far as I know) we're still the only ones shipping.   We've seen the cost per drive rapidly fall from 40x to 8x  (more than a Fibre Channel  15K RPM drive) in about 1 year.

In the end, they have 30x the IOPS, and 10x better response times than our fastest FC drives.   So... Are people using these?  Yes, in volume.  

Yeah, but why would someone deploy on something that costs 8x times more per drive (particularly in today's economy)?...

Because, it saves you a TON of money.

Everyone understands "capacity dedupe" - i.e. I will be able to store 1TB worth of files on 500GB worth of storage.  Right?   Value prop?   Save money by buying less disks, right?  Right! - and saving money is good.   Capacity dedupe and data reduction techniques are almost a "defacto" factor in backup use cases, and an increasingly important technique for production storage use cases.   But, it's an applicable technique where you are capacity bound, not IO bound.

Ok, what is the equivalent about for IO-bound workloads?  EFD is like "IO dedupe" - spend less money, get more IOPs.  Sometimes, the name of the game is latency in milliseconds - and here, spend less money, get lower latency (in some cases the ONLY way to get lower latency!)   While you're saving money, how about using less footprint, no need to make complex short-stroked configs, and consume less power.   In EMC's case, our arrays can mix EFDs, FC, and SATA drives - and for most consolidated mixed workloads, a little EFD goes a long, long way.   

For the last few years, capacity was growing faster than IOPs, EFDs represent a quantum leap forward for IO-bound workloads.

And that's before you do the analysis of the business value of performance.   I've got the data from a recent test for a mid-sized customer who's SQL Server workload was 50% faster with the introduction of just a small number of EFDs (5) took a 29.5 hr job down to 15hrs.   Another workload completed 80% faster.   BTW - they were doing that on a low-cost, mid-range platform with iSCSI-connected hosts!   The workload was IOPs bound - period.  

Now, before the DBAs go to town: "you might be able to get much better than that with some application optimizations!"   Answer to that is YES - and that's why EMC has a huge consulting practice with business application expertise - we can help there too.  But SOMETIMES you can't (for many reasons).

Next... What about the effect of read caching, doesn't that negate (or at least reduce) the need for EFD, and make "SATA perform like FC"?   Read caches aren't anything new - and large caches are increasingly popular.   Memory = good.   But read cache can't do a thing for an random read cache miss.   We've done loads of tests, and seen for ourselves that EFDs have a HUGE benefit, even when the read cache hit rate is very high.   Check it out.

This shows - even though cache (SRAM or slower SDRAM) is much faster than flash....  even at 95% read cache hit percentages, Flash is has 72% better response time than FC.  

And here's a nugget from the Oracle testing we did with EFDs on the CX.

That's a 12x "IO Dedupe" (or put another way - reduced the drive count by 92%).   What if we turn on the write cache?   Even better. 

In the full doc - here - it's interesting to see the effect of various configs in more detail, including oodles of performance data.   You can get the same for the DMX here.   You want SQL Server?   Here.    Exchange?   Here.  DB2 on z/OS?  Here.   in each case - HUGE savings, HUGE performance gains, HUGE business benefit (critical database activities that take 1/3 the time)

So - in a down turn, people are buying this stuff (even if HP says they think it will be another 2-5 years?)  YES.

For perspective, we sold 4x MORE EFD on CX4 than we forecast (at that was in late Q3/Q4).   I know the state really well here, as I'm trying to get drives to VMware for high end performance envelope testing for their next major release (which is FAST - faster than I expected), and literally we're shipping EFDs to customers so fast that I can't get them to VMware (though I will push until I do - come to EMC world, we'll share results!).  

What's the connection with high performance and VMware?   Answer is simple - VMware is ready for almost any app - any workload.   We're working together to prove it as much as possible, and with the upcoming release, that's more true than ever.    And in these cases, doing that cost-effectively  "IO dedupe" in the same way that low-performance workloads benefit from capacity dedupe mechanisms.  

Comments

[the storage anarchist]

Chad -

One note about that cache hit rate table - it uses 6ms as the example response time of a 15K rpm drive. This response time is BEST CASE for a 15Krpm drive, and is usually attained only if data is stored on a fraction of the drive (to minimize head movement). It is not uncommon to see heavily loaded 15K drives delivering 10 or even 20ms response times - under these same loads an EFD will still deliver virtually constant 1ms response.

Said another way, 2-6x is the WORST CASE improvement you can expect from EFDs.

[Rob]

> One note about that cache hit rate table - it uses 6ms as the example response time of a 15K rpm drive

Those must be old crusty drives.

> This response time is BEST CASE for a 15Krpm drive

Maybe 7 years ago, sure.

Here's a 450 GB FC or SAS interface, average seek of 3.4 ms:

http://www.seagate.com/docs/pdf/datasheet/disc/ds_cheetah_15k_6.pdf

[Rob]

never mind. it was late. 3.4 + 2 ms = 5.4 ms for response, not 3.4 ms you have to account for latency. It is late, sorry.

[Nike Air Force 1]

Fold a beautiful shapes,Carrying my endless blessings, Captures the fresh morrowind, Fly by your side, May this paper cranes stope in your heart, For you to Rome yesterday, Welcomed the exhaustion of happiness tomorrow!