EMC World Day 1: XtremIO 4.0 – the best AFA gets better.

Today we announced XtremIO 4.0.   The bits will be available for customers at no cost in weeks.   Oh, and it’s an NDU upgrade for all XtremIO 3.0 customers.

What’s up?  It’s almost hum-de-ho (a great platform gets even better!) – and face meltingly awesome at the same time :-)

It’s so good, we have lovingly called the XtremIO 4.0 release “The Beast” :-)

Here’s what’s new!

• The number one feature request: the ability to expand a cluster non-disruptively.  Start with 5TB, and non-disruptively scale all the way up to 320TB (8x40TB X-bricks).  A heads up on availability – when you announce something – it needs to be ready before the end of the quarter it’s announced in, otherwise it’s a “tech preview”.   One small caveat is that the 40TB 6 and 8 node clusters will not be available before the beginning of Q3 – but all other configurations are going to be ready before then.    Now, why is scale-out important?   Customers have voted with their feet and their dollars as they have realized scale-out is simply a better and easier way to get the most out of flash.  Customers prefer a scale-out design.   Interestingly, customers were selecting XtremIO over scale up designs even BEFORE we could scale out dynamically (and statistics show a ton of multi X-brick deployments already).   With XtremIO 4.0 - we can scale up dynamically and non-disruptively.   One more design note to make sure people know – you need to go up in even X-brick counts - 1-2-4-6-8.

If you want to see how cluster expansion works in practice, check it out below:

• The number two feature request: rich remote replication –  via native Recoverpoint integration, support for thousands of devices, consistency groups, sub 60-second RPOs.   This was NOT trivial – because we knew we needed to be able to scale out the replication along with the XtremIO cluster – tight RPOs up to the “Beast’s” 1M IOps and low latency is a tricky engineering challenge.   While XtremIO customers were using VPLEX with Recoverpoint or Recoverpoint for Virtual Machines to replicate already, XtremIO had no “platform” based remote replication.   This new capabiltiy also bring heterogenous support.    Oh – and it inherits rich vSphere SRM support, Appsync support, ViPR automation and more.  Yup - XtremIO just went from no “platform” based replication to having the best remote replication in the AFA industry.    This is a big, bold claim – but watch these demos, and judge for yourself…

• 40TB X-bricks.  These have more RAM to ensure all meta-data stays in RAM – and lowers the effective $/GB for workloads that are $/GB bound vs. IOps bound.   And yes, in the picture, you can see these new nodes have a cool new bad-a$$ faceplate for some of the new XtremIO cluster configs :-)
• 8 X-brick (16 node) cluster support.   This means you can have a XtremIO cluster that using AVERAGE data reduction rates is north of 1PB of effective capacity.   Wow.
• Improved performance (on top what was already great).
• Stronger resiliency.   N+2 SSD failures in a single X-Brick, and up to 16 simultanous SSD failures in a cluster.   BTW - Dual SSD failure in an Xbrick is handled gracefully – and with no reduction in capacity efficiency. It’s also worth noting that it also results in no loss of write performance – that’s a big difference between XDP and traditional RAID-6.   This dual parity has been built into the code ever since we’ve shipped the first X-Brick, and now the implementation is complete.   There is NO SPOF in XtremIO – period.  
  • Note: Interestingly, with a huge number of customers – we have yet to hit the dual SSD failure in an Xbrick.  Rebuild times are so much faster than on HDDs, the statistical exposure window is so much shorter.   But, of course, competitors would put the “pull two SSDs” in their competitive training (I get it).   I guess they won’t anymore :-)
• The already awesome snapshot support gets better (consistency group support, 4x greater snapshot volumes, rich refresh and restore with no NAA change, read only support when you want it, a great native scheduler).   Appsync support for rich ecosystem integration with Microsoft, VMware, Oracle and more.

Wow.

You can see now why we acquired XtremIO.  The right architecture, the right engineering team – you could see where they would get in a few years with investment and support.

BTW – those are all the updates in XtremIO 4.0 – there are a LOT.   Its the biggest upgrade yet – here’s the list:

You might see one of those that is the stamp of the sense of humor of the product team :-)

BTW – there a ton of improvements in the UI and manageability – worth a look see, which you can do below:

XtremIO has been winning in the marketplace, and regardless of what anyone says – numbers speak.   They are reflection not of marketing/noise, but customers making their choices.  

With XtremIO 4.0 the various places the AFA competitors were poking (in certain cases legitimately!) are closed.  I’m sure they will find rocks to through, but well, it’s getting to be a pretty small set of rocks.   I’m sure they will, and I look forward to seeing the creative things that people come up with.   Haters are gonna hate :-)

For transactional workloads that need consistent low latency – there is now no reason to deploy a hybrid.   Period*.

*The SE in me must note that there are a couple exceptions to that very black and white statement:

• Workloads that need RDF, Mainframe or iSeries support.  For that, use a VMAX loaded with SSDs.
• Cases where you need something really small (physically and/or economically).  For that, use a VNXe, and consider the new 3TB all-flash configuration for $25K in 2U.  It’s simple, easy, small, and unified.
• Cases where you need an SDS + commodity hardware design that isn’t as linear, doesn’t have the data reduction data services.   For that, use ScaleIO with a NAND-rich server design.

But… While this XtremIO 4.0 stuff is all great… IMO – this isn’t the story :-)  

The story is the behind the scenes story – less sizzle, but in mature adult way vs a adolesent way – it’s more sexy.   We are the AFA leader now by a good margin, and are accelerating.   This means that we have a ton of data of “XtremIO in the wild”.   Real data of how customers are using it.   What data reduction stuff is real.   What is the scoop on wear at scale and over time.   Want to see?  We (the XtremIO team and I) are determined to share openly and transparently.   I’m SURE that our competitors will find ways to poke at all this – but… whatever.

Read on!

 

This part of the story starts by understanding what we’re talking about.   XtremIO and AFAs are now mainstream.   There are now enough customers and X-Bricks deployed that you can get to real statistics (with smaller sample sizes, it’s less useful).

 

Here’s some more stats.   Now, let me clue you in to the games that all vendors (EMC included) play in marketing – particularly in early days of explosive growth.  

• “Run Rate” is the “last quarter revenue” x 4 quarters.  It’s a forward looking great indicator.   So – we’re already north of a $1B run rate.   That doesn’t mean customers have bought $1B of XtremIO – it means that in the last quarter when we made the statement we were north of $250M of revenue.
• “Growth rates” are often quoted – but note that these are not absolutes, and are silly stats for smaller businesses.   If we sold a single customer for $200K of XtremIO, and then the next quater we sold $20M – we could claim a 10,000x growth rate.   Yeah! 

So – where are we?

Another important metric is customer satisfaction, and the ULTIMATE measure of customer satisfaction is “re-buy” rates.  Something being great is truly great when a customer wants more.   We track this manically for our emerging and high-growth products.

 

The other thing that’s interesting is to see how over a relatively short year, AFAs moved from “Tier 0” or “VDI” storage – and with broader data reduction, denser X-Bricks, deeper ecosystem integration into “broad transactional workload use”

Now – as some of my respected colleagues at competitors would echo (Vaughn, thinking of our VMworld session) thin provisioning is NOT a data-reduction technique.  It simplifies operations, and does enable customers to get more out of systems.   But – to be clear, in our view, it’s not a legitimate thing to claim as part of “data reduction”.  

BTW – every competitor is going to read this whole thing and think I’m talking about THEM.  In the immortal words of Carly Simon: “You’re so vain, you probably think this song is about you”.   I’m not talking about any one in particular – rather that there not a “golden standard for how data reduction is measured”.

What is interesting is to look at what customers do in practice with a platform that ALWAYS is thinly provisioned.   You can’t turn that off.   What you get is this:

What’s interesting is that thin-provisioning as a feature is widely available, but on platforms that started with a “thick” provisioning model, and introduced thin provisioning years ago… well, we don’t see nearly the same use of thin-provisioning in practice.   Of course, the XtremIO design is very, very good (since it’s a architectural “outcome” rather than a “feature”).  

That said – there’s something else at play here.  Given the choice, customers are too conservative :-)   Seriously, they are reluctant or “don’t trust” systems and are fearful of things that might go bump in the night.    Thin provisioning models are really the defacto.  There’s a plea in here for customers that have more “classic” systems: use thin provisioning, it works.

Now – what about the big question – data reduction itself?

I had the good fortune of visiting two great customers on Wednesday last week, and it was interesting to talk to one about this topic.   They are a great EMC customer – with almost everything we have.   They have some VNX and CX4 platforms that are getting long in the tooth (in fact, they just retired a CX300!)  They also have several VMAX platforms.   The local team (great team!) are proposing that in refreshing the workloads on the VNX, the transactional block workloads that support vSphere (both VDI and virtual server use cases) and several of the databases on the VMAX should come off those platforms and be on XtremIO.

With AFAs, a big portion of their effective $/GB is a function of the data reduction – because a well-designed AFA does data reduction as a normal course of business – inline, all the time.   While the cost of NAND media at various write per day (WPD) factors keeps plummeting (and will continue to drop), without inline data reduction, the TCO is not as clear (in spite of all the operational, simplicity, and of course performance benefits).

This particular customer was VERY skeptical about data reduction rates.   The local team had used our Mitrend data reduction analysis using the customers data – and while the tool suggested a 4:1 (with the customer data) was very reasonable, they were conservative, and modeled the TCO at a 3:1.  That TCO pointed to pulling the workloads onto XtremIO off VNX/VMAX was a no-brainer (BTW – with a much smaller VMAX footprint continuing to support the mainframe/RDF workloads, VNX NAS at the core datacenter going to Isilon, and VNX remaining the small site workhorse)

The customer was skeptical.  So I shared the data I’m about to share with you.  This is from 1,400+ customers and thousands of deployed clusters.  While “your mileage may vary” is true – we’re talking about a very statistically significant sample.

Dedupe: remember, this means that everything written is globally unique.

With XtremIO dedupe is always on, always inline.  It’s not a “feature”, it a “property”.   You can see that the dedupe rate on average would be north of 2:1, close to 3:1.  

So – yes, while you can find customers with 10:1 and 20:1 (or more!), that’s the exception, not the rule.

Compression: remember, this means that repeating patters in the globally unique data can be represented more efficiently (and losslessly of course).   Think of Lempel-Ziv or LZ compression :-)

You can see that the largest population gets between a 41-60% savings due to compression.  That’s a material savings – that means that we’ve halved the effective cost per gig – and like dedupe, it’s transparent and always on.

What is highly dedupe-able (server images) and what is not (databases) and what is highly compressible (databases) and what is not (images) is well known.  But – it’s somewhat moot.  It’s very rare that these arrays (like all arrays) support one workload and one workload only.   In the end, it comes down to the total data reduction.   So – here’s that… across the entire installed base:

So – what’s the net?  This is tricky, and a lot of ways to calculate.

If you bucket the customers, list their data reduction values in a spreadsheet and then average them, the data reduction rate is well north of 4:1, almost 5:1.   That’s how some share this data point.

If you are a little more of a scientist about it, you have to weight them by the capacity they are actually saving (totaling up all the customers raw, physical used, and logical delivered capacity – and then calculating the average from that) – you end up with a value between 3:1 and 4:1.

Yes, your mileage may vary, and it may be more, it may be less – but we’ve passed the point where inline data reduction on XtremIO is a proven technology, and you CAN build it into your economic model.

Now – I guarantee we’ll get a ton of vendor flack here.  I’m not unfamiliar with this territory :-)  It’s common that my blog, where I try to be transparent – ends up in our competitor’s training :-)   Some will claim our data reduction rate sux and theirs r0ck5 :-)

Whatever.

The reality is that data reduction claims have no standard.   Some include their “eliminated repeat zeroes” – sometimes as part of compression.  We don’t – as they are eliminated before compression.   Some include thin provisioning (hah!).   We don’t.   Some include snapshots.  We don’t.   What you CAN count on is that you’re statistically likely with mixed workloads to land somewhere between 3:1 and 5:1.

I’m glad to say that after sharing the data (and confirming that the analysis we did via Mitrend of their data was if anything conservative), we’ll be moving forward, and making a happy customer even happier :-)

Now – beyond data reduction – what about load, writes, and wear?

The customers are POUNDING on these things :-)

The averages in the above are interesting – but look at the more extreme example in the middle.   There is a customer that is generating the IO equivalent of 125K IOps NONSTOP.   And while that’s a lot – look at the customers that have read/written more than 1PB.  This is especially amazing because the typical XtremIO array has 30TB physical flash in it - meaning it has been completely overwritten 30+ times in an average of 6 months of production.  We've been shipping a year, most arrays shipped in Q3 and Q4.

 Wow.

Now – as everyone knows – the writes are what hurt NAND.  They are slower and you can do less of them per second (because NAND needs to write a page of NAND at a time)… Hence AFAs focus so much on everything they can do to reduce writes.   So let’s double click on the write load.

First an interesting fact, and then an interesting stat.  

One of the things that is really unique about XtremIO architecturally is they created what was in essence an inherent object data distribution model for all writes.  That distributed object/hash function and meta data model means that every write is a unique write, there is NEVER an unnecessary write (all data services happen before a write lands).  It also means that writes are distributed all over a cluster.   Why does this matter?  

Well, here’s the stat:

This is the histogram of how long it takes a cluster to hit the point where it starts to over-write itself.  On AVERAGE, a cluster starts to overwrite (reuse already written NAND cells) in less than 6 months.   The chart above ALSO shows that after the initial overwrite which takes 6 months, subsequent overwrites are taking just days.  In other words, customers take a little while to ramp up on XtremIO, but once they really get going, the workloads are immense.  This is when scale-out begins to truly matter.   If your AFA looked awesome at the beginning, and is limping along later – this might be why, and hey, we have programs to help those customers if they are interested.

Here’s a particularly interesting data point (and everyone, understand we DO NOT track any customer’s data, only system use).   This little happy little X-Brick is in the torture lab where we do endurance testing.   This is VERY Xtreme :-) 6PB of writes within 277 days (and since there are 25 SSDs in an X-Brick, hence 242TB of writes per SSD).

The takeaway from the visual is potent (though the colors a little garish :-).  

The writes are PERFECTLY distributed.  There is no hot SSD, or a hot spot on an SSD.   This comes from the fact that XtremIO has no legacy (none) of using NAND as magnetic media.  All writes are hashed uniquely and distributed evenly.  There is no filesystem, or “filesystem-like” layer that you see in architectures whose origins are hybrids.  Why is that important?   avoiding all write amplification (due to shifting stuff around after the fact = more unnessary writes) and maximizing SSD life.  

Also note – that even after that masochistic year filled with 6PB of writes (!), there is 98% write life remaining on each and every SSD.  Is that abnormal?  Well – perhaps a little extreme, but not abnormal.

Looking across the entire customer base, the “life left” is shown on the right.  That 98% “life left” is actually very, very rare.   The vast majority of the customers (95%) have 100% of their write life left.   In fact, there isn’t a SINGLE CUSTOMER that has less than 20 years of happy writes left in their current X-Bricks.

Sidebar: I don’t know if other vendors show their write life left in their UI or via their APIs – does anyone else know?  

I would be VERY curious about this data from arrays in the field with media with different WPD (Write Per Day) characteristics.   I’m not trying to FUD here – in fact, we absolutely will be expanding the NAND use across the whole portfolio (including for cold archive use cases).   The XtremIO write abatement (eliminating write amplification) is best in class, and maybe we’re being a little conservative with eMLC (10-12 WPD) – in fact, looking at the data, we probably are.  If most customers have 20 years left, we could maybe get away with 3-5 WPD media.   Would love to see vendors share similar data.

That’s a profound fact – and while there are lots of marketing efforts about “guarantee” programs, we feel firm and safe (and have the data to support which we’re sharing transparently) about the life of our NAND in XtremIO – and as you can see, architecture matters.   “Putting NAND in a hybrid”, or “all SSD configurations of SDS” may be good (very good!), but that doesn’t make it an AFA.

What about availability?

XtremIO is, well, Xtremely available.   Here’s the data from the XtremIO 3.0 customers:

Look – we’re not perfect.  

The EMC Executive team as a whole sees all the worst cases directly (creates the right sense of urgency – we’re talking about customer’s data here) around the globe, on all our stuff.   I saw my first customer outage with XtremIO last week.  I’ve always thought that how we deal with problems is perhaps the most important thing, and the customer is back up and running.  We can always do even better – across everything we do!

One outage is an anecdote, not a statistic.   The statistics speak because we are now looking at a large installed base.  XtremIO has the highest customer satisfaction ratings in EMC history.   In part, I think that’s because it’s cool.  In part, I think that’s because it’s disruptive.  Most of all, I think that’s because it’s awesome.

While XtremIO doesn’t have RDF with 3 site replication, tens of thousands of replicas, sync replication, or Mainframe support – no AFA does.  With XtremIO 4.0 – XtremIO has the best remote replication in the whole AFA market, including sub 60s RPOs.  It’s not RDF, but it’s incredible.   Can we do more?  You bet. 

• There’s work to further improve the code update procedures and keep IO smooth as silk.
• In a future release, we will introduce even more around native remote replication.  

This isn’t to imply that XtremIO is not ready for mission critical of workloads.  I know of a bank that runs the business off XtremIO….    And hey, if you need a full sync replica, with FAST.X with VMAX3 and XtremIO support, we can do that.   Hey, if you need an active-active stretched vSphere cluster with XtremIO, we can do that too with VPLEX.

So there you have it.   With XtremIO 4.0 – the industries best AFA gets even better.  Best of all – it’s provided at no cost to all customers, and is an NDU upgrade for our XtremIO 3.0 customers. 

Just like the XtremIO 3.0 upgrade that filled in the picture – 4.0 is proving the point that the core product architecture is right, and as we fill in features and gaps quickly, the lead in the AFA marketplace is opening up.

Of course, we’re not stopping here.   Through 2015 you can expect more updates, including a whole other pile of goodies.  Of course, VVOL support is also coming to XtremIO.

Would love to hear your thoughts!   What do you want us to do next?

Comments

[Chris Gurley]

Nice, thorough blast of new features! Definitely the biggest release so far.

I have a clarification question, if you don't mind. When you said, "Start with 5TB, and non-disruptively scale all the way up to 320TB (8x40TB X-bricks)", did you mean:

(1) that customers can now start with a starter brick of 5TB and add heterogeneous brick sizes after that to reach milestones on the way to 320TB?
(2) that customers can add larger bricks--say, 1 x 40TB--and migrate off of the original starter 5TB brick, in order to get the dense building block to reach 320TB?
(3) that people can add homogeneous brick sizes to reach points in that range (i.e. 5TB --> 40TB, 10TB --> 80TB, 20TB --> 160TB, and 40TB --> 320TB)?

Closing question: when can we get it? :) (apologies if it was somewhere in the midst of that crazy-full pool of data)

Thanks!
Chris

[Mark Burgess]

Hi Chad,

As per my comment on your VNX blog, what is the timescale for VVOLs support?

The fact that EMC owns most of VMware made me think they would have VVOLs support on all their arrays at vSphere 6 GA instead they seem a little late to the party.

Many thank
Mark

[Jonathan Kowall]

This is so cool. XtremIO has hit on every commitment and continues lead the pack. Congrats to the whole team!

[Chet Walters]

It was my understanding that the 5TB "starter" brick cannot join a cluster. IE, it can be upgraded to the 10TB brick, but that brick cannot be added with another 10TB brick to form a 20TB cluster.

Fact or fiction?

[Aran Hoffmann]

@Chris and Chet
All X-Bricks in a cluster must be the same model. So if you start with a 10TB Starter (5TB) then you can upgrade that non-disruptively to 10TB. Then once you are on 4.0 code you can non-disruptively upgrade that single 10TB X-Brick cluster to dual 10TB X-Bricks in the cluster.

As far as supported limits, the 10TB X-Bricks can only scale up to 4 X-Bricks in the cluster. The 20TB and 40TB X-Bricks can scale up to 8 X-Bricks in the cluster with the 4.0 code.

[LeRoi]

Nice rivew entry

[Chad Sakac]

@Chris @Chet - thanks for the Q - it was answered by @Aran - it's a good clarification. Thank you Aran!

@Jonathan - I'm glad you're pumped! There's always more to do - but yes, an incredibly compelling solution just got better!

[Chad Sakac]

@Mark - support for the VVOLs on XtremIO will arrive in 2016 (see vVNX post for the answer there). I do think we're a little behind, yes - and the teams are working on it furiously. What I'm seeing is that 2015 is the year of "trying on" VVOLs - and with VVOL 2.0 support arrives for remote replication support in the VASA API. This means that while we ARE behind (acknowledged!) - our commitment to be there across the portfolio remains solid.

We were there from the get go, and furiously in sync (as you can see from the years of demos at VMworlds past), but as we got to the finish line for the vSphere 6 release - our release schedules just didn't match up (and VVOL support is, in my view a major release).

It's not a pretty situation, but we are on it.

[Will]

Came across this post while doing some research. Claiming no SPOF is a little misleading compared to some of the competition, isn't it? SPOF has come to mean more than just have a single backup for something. Also, a dual drive redundancy (RAID6 essentially) isn't much of a benefit when comparing to the competition either I think. Cloud based storage is becoming the norm for business with requirements that go beyond a fast RAID platform, and I'm just not sure I see the differentiators with xtremIO still.

You guys are definitely working hard to get out a product that the EMC sales team is selling, there is no doubt about that. EMC sales practices and results really have no bearing on how well a product performs, though. The argument being that even if an organization selects the best product to fit their needs, it is EMC sales policy to "not be undersold" simply to get market share. Is it human nature to still select the best thing, even if it has now become more expensive? Or do the majority of people succumb to "the biggest discount" effect?

Approve this comment or not, it's your purview, but I think these are valid devil's advocate points that need to be considered by those taking a look. There is something to be said for either option in that decision.

[Colo Host]

It's 2017 now, is vvol support available in xtremio (XIO1 not XIO2) yet? I'm on 4.0.2 but not seeing a way to do it at this point.