EMC Elastic Cloud Storage (ECS, formerly “Project Nile”) Reveal!

This is an interesting new thing – all dressed in “bad a$$ EMC black” kitted out with our awesome “Cylon LED”

In the era of “Software Defined” everything – what’s this about?   It seems like quite the opposite – quite “HARDWARE DEFINED” no?

Well, in fact, it’s the clearest example to date of two sides of the same coin: “do you prefer software + bring your own hardware”, or “integrated software/hardware appliance running on commodity hardware”?

Read on for more!

It’s simple – ViPR 2.0 (including ScaleIO) and Project Nile (now EMC Elastic Cloud Storage) are the SAME INTELLECTUAL PROPERTY, but packaged in those two distinct forms, and packaging is important, not superficial.

Here’s how it tends to go down with customers:

• Are you someone like an Hyper-scale Enterprise, Hyper-scale SP/Cloud Provider or Web-scale SaaS player? Want to bring your own hardware?   Do you have an operating model where EVERY thing is software, and you have a team that provides “datacenter iron as a service?” Awesome.  Then you’ll love the ViPR Controller + ViPR Data Services (including Scale IO).   They are software only, and run it on whatever you see fit (including infinite variations).
• Are you someone like an enterprise or SP operating at slightly smaller scales – let’s just say a couple 1PBs (still pretty big!)  While you are likely to WANT the choice of bringing your own hardware, you’re more likely to ultimately want to avoid the mess of hardware sourcing, sparing and maintenance. Awesome.  Then you’ll love EMC Elastic Cloud Storage – an appliance with high performance transactional block, HDFS, Object (and soon NAS), with a simple self-service consumption/chargeback model (in either capital/opex favored economic models – each customer is different, and in pre-configured options).

This distinction has an element of simplicity to it – but the nuance escapes many.

As David Goulden pointed out this morning – let’s say you can save one DIME per GB  (in capex, or opex, doesn’t matter) for every GB you operate.   To make this powerful – visualize A DIME:

 

Here’s how it translates into overall economic impact as you scale up from an individual to an enterprise, to an web-scale environment:

That’s why the hyperscale folks (who are looking at EB scale) generally prefer “software, bring your own hardware”.   You can build a killer operations “iron as a service” team for $100M.   For someone with 1PB and a cost delta of $100K for the price of managing your own hardware value chain – we’ll you can’t hire the right talent for that.

Here’s another exercise that points out something that isn’t obvious to many at first glance. 

Try (seriously, try!) to build a “home brew” configuration of a HA clustered VNXe-like appliance.  You need a general purpose storage thingee for NAS/block and a variety of use cases (vs. one that is hyper-converged with a hypervisor and stores only VMs).  

You’ll likely do this sequence:

1. Start with one of the open ZFS distributions (or if you love the data services of a VNX, perhaps the software-only VNXe “Project Liberty”)
2. Then you’ll realize that you’re going to want support, right?   So you’ll need to license the code.   This will cost a couple $K.
3. Then you’ll need two servers.   You’re going to want them to have some oomph.   Price out 2 quad core sandy bridge servers with 48GB of RAM each, and 4 10GbE ports.   These will likely cost around $3K-$4K each (probably more in fact).    You’re likely going to want them to be able to have a lot of spindles/SSD, so you’ll look for a 2U form factor.
4. Oh wait… they will need to be clustered, and this usually uses some sort of IB or PCIe interconnection (for cache mirroring).  That will add a couple $K.
5. You’ll want a couple SSDs (eMLC likely) and then some SAS disks.   That will cost about $1K per SSD ($400 if you go cMLC) and about $200 per HDD.

Net?  You just built a poor-man’s VNXe (a swiss army knife).   Unfortunately:

• It’s much bigger physically, likely minimally 4U for a solid SSD/HDD count (we jammed all that, including 25 SSDs/HDDs into just 2U with the VNXe).
• You won’t be able to expand it (unless you buy external SAS controllers and disk enclosures – and that jacks up the price tag!)  With the VNXe, you can just keep adding enclosures/disks.
• Even though you’ve licensed the software, you will need to maintain/spare parts.
• Little, but VERY IMPORTANT things like a every drive having a little LED that manifests physical faults properly, well – it works.
• It’s MORE EXPENSIVE to “home brew”.   People don’t believe this, but add it all up – it’s interesting!   Building a “home brew” VNXe ends up costing more than just buying one.

This is why “Project Liberty” isn’t about making “home brew” VNXe’s in place of appliances (and that’s not me defending hardware appliance form factors for all).  Project Liberty is about:

• very small robo (non HA) scenarios (where non-HA configs CAN be built for lower cost).
• enabling people to play/learn/use/develop against VNX code. 
• enabling large VNX customers to be able to have “test/dev” cycles that include “storage platform as a service”.
• enabling large SPs/Cloud providers to create “VNX personas” on top of things like EMC Elastic Cloud Storage – and perhaps doing it where each tenant gets completely isolated logical data services.

But – look at it at the other extreme – at Hyper-Scale, those customers CAN squeeze out pennies at the hardware layers.   They want storage stacks that are “Type 3” loosely-coupled scale-out clusters like ScaleIO and software only vOneFS (which has very low hardware dependencies) and “Type 4” shared nothing distributed systems like the ViPR Data Services stack (which has no hardware dependencies).   And perhaps most importantly – they have operations teams that maintain a huge hyper-standardized hardware “platform” – that “iron as a service” I talked about earlier.

For them - “bring your own hardware, and just add software” makes sense.

EMC Elastic Cloud Storage (aka Project Nile) was born in response to deliver that “Hyper-Scale” architecture that powers the Amazon AWS datacenters and EBS/S3 services, but do it with a BETTER software stack (literally better in all vectors), and offer a package option for customers that aren’t operating at QUITE that scale.  

Sidebar: Just like the with the lessons learnt through Project Thunder helped us discover the awesomeness of DSSD - the lessons learnt in VMAX Cloud Edition helped in the birth of the ViPR Controller, and more generally about what the market wanted in Project Nile.

So, what’s in EMC Elastic Cloud Storage?

First: Several EMC manufactured (designed for serviceability, environmentals, and density) dense servers (4 server nodes in 2U, which run the ViPR controller/data services + ScaleIO stacks.   These have NO custom parts – they are commodity servers in every sense of the word – just designed to spec.

Second: several EMC manufactured (again, designed for serviceability, environmentals, density) drive enclosures (picture of one named “Voyager” to the left).  

BTW – there’s an interesting point here that we’ll see how it plays out.   It’s possible with these “engineered” systems to achieve a density that is impossible with “general purpose” rack mount servers.   It’s possible that the emergence of things like ScaleIO, VSAN will drive the server vendors to build “uber storage dense” rack-mount servers – but for now, if you want to max out power/cooling/density/capacity – you need something like Voyager.

Hint – for the Virtual Geek faithful, you can go back in time to a Chad’s world episode here where we previewed a bunch of hardware stuff that Bill DePatie’s crazy team (Global Hardware Engineering – make all the EMC hardware goodies).  We showed the DPE enclosures that would become the new VNXe, the current VNX, this dense “Voyager” enclosure with 60 3.5” disks in 4U (currently this is “capacity geared” sweet spot) – see

The GHE mad crew never stop - there’s an even denser one coming up with 120 2.5 spindles in 3U, and even stranger mSATA/NVMe form factors – these will be very interesting for “performance geared” ECS variations.

Sidebar: In that video, BTW, the thing underneath the sheet I Wade and I didn’t talk about were the EMC manufactured servers – because we knew that EVERYONE would jump to the wrong conclusion (that Project Nile was a “hyper-converged” compute/storage stack).   I think it’s evident architecturally that it COULD be – but it isn’t.   Those compute nodes run the ViPR/ScaleIO code – no different than the “servers” that power a VNX or a VMAX aren’t “servers” in the general computing sense. 

Third, you’re doing to need networking to hook it all up.  EMC ECS has a very high performance 10GbE switched data network, and a 1GbE management network.

Fourth, you’re going to need to pick a couple target design points – we picked these three big “buckets” based on customer demand (some want just Object/HDFS, some want just transactional block, some want a mix) – and then a couple variations in each of the 3 buckets (different scaling points):

 

You can see that EMC Elastic Cloud Storage is initially targeting “Capacity” use cases – there’s no real use of flash in this, and if you wanted IOps, you would pick a different design point (like I’ve pointed out before, there are real-world examples of ScaleIO with dense SSD servers driving 10M+ IOps from ~45 servers!)

The other thing that is interesting – look at the DSSD post and imagine one those bad boys as a “Top of Rack” pool of ultra-low latency pooled flash with native API integration and direct-memory extension.

I suspect that we’ll need some “ultra performance” ECS configurations soon enough :-)

BTW – if you don’t like these configurations for any reason – NO PROBLEM.  Just select the “SDS + bring your own hardware” model – and you have infinite variation.  If you’re a huge customer who wants a variation, but a hardware appliance – let’s talk.  If it’s big enough, perhaps we’ll build a formal ECS variation just for you.  

We won’t do this lightly however, this is an “engineered system” just like a Vblock – it’s the simple “other side of the coin” to ViPR/ScaleIO as SDS: ECS is  SDS bundled with commodity hardware into a fully supported “appliance”.

All in all - EMC ECS is an incredible package.  

• It delivers “better than AWS EBS” transactional storage (because of Scale IO’s scaling model and absolute scaling, much better performance, snapshots, economics, QoS capabilities),
• It delivers “better than AWS S3” object data services (because of the ViPR Data Services S3, Swift, Atmos API support, better geo distribution, better global namespace, lower cost to serve, byte-range modification, HDFS support, total economics package and much more) – all with the simple ViPR Controller self-service portal, northbound APIs, and monitoring for EVERYTHING.
• It makes those available on prem, for enterprises that can’t have data leave (or don’t want to for other reasons), or for service providers who want to compete with AWS and Google and win.

And remember – if you DON’T WANT HARDWARE TO GO WITH YOUR SDS – that’s A-OK by us!

And – we’re putting our money where our mouth is.   EMC ECS is cheaper than the webscale offerings, even AFTER their recent price wars.

 

Welcome world!   EMC Elastic Cloud Storage the first complete (HDFS/Object + transactional storage), Webscale (completely elastic, self-service, and scaling to EB scale) for any datacenter (not just the huge SPs, but for anyone).

Comments always welcome!   What do YOU think?

Comments

[RobSteele]

Awesome to see project Nile finally come to life !!! Where can I play with this ?

[Martin 'Storagebod' Glassborow]

Only one question...when do we get downloadable ScaleIO to play with!!?

I'm going to bug you until we do!!

[Storageous.wordpress.com]

I am not at World this year, is there a video/demo showing the SW element of this ECS? Looks fantastic!

[Derrel]

ECS looks awesome! Oh, and downloadable ScaleIO would be great!

[Fe]

Nice one, when will CloudPool be GA with EMC ECS :)

[Vitaly]

Great post Chad, thank you.
The only thing which is confusing here is that there is no clear statement that ScaleIO is just one of available options in ECS. There might be other backends like Isilon or VNX instead of ScaleIO and this still will be an ECS appliance.

[Hari.S]

Hi Chad,
can we also see ECS integration with Isilon. if yes that will provide big traction from Bigdata perspective, since isilon provide benefit of hadoop version as well.