VxRack System 1000 is a family of Engineered System variations. They share rack-scale system design parameters, and a common spine-leaf network. If you need a VxRack System 1000 primer (really important before you consider different node types) – read this blog post here.
Now that you’re back, primed on the system-level design and multiple Node types that are supported – let’s dive in on the newest node type: the Neutrino Node.
I don’t want to bury the lead in the context. Here’s the headline on the news:
VxRack System 1000 with Neutrino Nodes delivers a turnkey IaaS, one that is 100% focused on supporting new Cloud Native apps. It’s designed to optimize for elasticity, simplicity, cost-effective scaling – with little focus on “deep resilience”. It’s build by open-source technologies, and is designed to run open-source software stacks.
For customers looking to deploy the turnkey developer’s platform for Cloud Native apps (Native Hybrid Cloud), VxRack System 1000 with Neutrino Nodes is a natural choice. If you want to understand more about Cloud Native Applications – I would suggest reading the Native Hybrid Cloud post here.
… Now, as Virtual Geek readers have come to expect – context, details, background, the juicy story-behind the story! Read on past the break!
Like all VxRack Nodes – the outcome to the customer arrives because of the the integrated hardware and software design, but the magic is in the software.
Think of the software on Neutrino Nodes as enabling “multi-cloud stack, multi-rack infrastructure and IaaS in a turnkey super-simple lifecycle”.
This is cool, and has a fascinating back-story, and one of many examples of 100% organic innovation within EMC.
The story starts when we started to build the Elastic Cloud Storage (ECS) architecture almost 4 years ago.
We had a fair amount of experience with hyper-scale, geo dispersed object storage models, having lead the charge with EMC Atmos.
Atmos was architected to scale, but using application models that were prevalent in 2008 when it was first released (and the Atmos story started with Oceanstore project at Berkeley in 2000 – a cool fact for the history books). While it started with the idea of massive scalability, there was still a set of points in in the architecture that needed resilience (one example of several was the Metadata server, which was based on BerkeleyDB).
So – when the team with experience of Atmos, and the experience of some of the engineering team who worked on Microsoft Azure – we started Elastic Cloud Storage as a next-generation geo-dispersed global scale object store… They decided from the start that ECS needed to use “Cloud Native Principles” soup to nuts.
ECS as an object store was born with a very “microservices” model – and each component was designed for failure. Using the lessons learnt from years of Atmos, we embedded all the metadata in the object store itself. To top it all off, every element ran as a container – using Docker to be specific. I think that ECS was the first completely containerized storage offer from any of the big players.
But – wait a second… ECS isn’t an “ephemeral” app – we’re talking persistence here! There was also a lot of “state planning” needed – after all, one would need to track object persistence to ensure that containers would respect placement logic (on physical servers, racks, datacenters, countries, etc).
Looking around – the container/cluster ecosystem had a lot going on (these were the early days of Mesos, Kubernetes, Docker, CoreOS, etc). But – while they did a solid job of “ephemeral state/health” management – they left the “persistence” to other things. We needed something specific – a container/cluster management stack that optimized for huge scale, but also “understood” the underlying nature of the stuff it was running on. If this wasn’t built – you would need to build that logic into the “cloud native app” itself, which is a huge no-no.
Thus was the inception of the Neutrino software layer.
While not exactly the same as the software in Neutrino Nodes – it was the start. That ECS software stack and the underlying container/cluster manager is now is pressed into production at MASSIVE scale – there is more than 2 EB of ECS deployed and in use – in fact I would wager more of you use it every day without knowing about it (because it’s behind the scenes of the apps that you use).
At the same time – two years ago we started to hear a common refrain at some of our customers:
“I’m trying to get going with these new Cloud Native infrastructure stacks, and while I very smart people, it’s proving to be harder than we thought – we need it to be easier”
When we double clicked on “what that meant” – it meant that the customers had 4 distinct problems:
- They really loved the innovation in the Open Source ecosystem, and wanted to tap in, but often found that the skills to make it sing were in short supply.
- When they DID have the skills, they often were transient – and that their projects would stumble when the human capital would move (1 or 2 people would be the SPOF for a project). Sometimes that uncertainty would be because the ecosystem itself is moving so fast – almost too fast for enterprise adoption.
- That they saw that the ecosystem (OpenStack, Apache Hadoop, Mesos, Cloud Foundry, etc) were all making strides to improve tools/maintainability – but often these were all in different directions, that no-one was trying to tackle “how will I manage several of these stacks?”
- Often – these efforts to “improve stack manageability” were in opposition with the “trunk” of the ecosystem – after all, each entity (no different for EMC, BTW) has a profit motive – to build value and “enterprise-ness” into the commercial offering built off the open source trunk, but then “forking” what you can do from one distribution to the next.
To us – we heard this and said: ”there is an opportunity to attempt to do something cool here”.
We realized we could take the container/cluster management model of ECS, along with its rack-scale infrastructure management/mapping system and tools and try to see if we could make it “generally applicable” to other “Cloud Native Stacks”. If we could pull that off it would be cool because we could hit EXACTLY the 4 problems the customers were grappling with:
- Solve the enterprise skill problem by “industrializing and curating” the stack for the enterprise – making it simple and turnkey for a much broader set of the market.
- Solve the “critical project goes sideways because an employee leaves” problem by taking on responsibility for the offer. EMC (and now Dell/EMC) isn’t going to disappear. Confidence that a project will have permanence is important for enterprise adoption.
- We could solve the “each player is trying to solve for their own domain” by proving out the thesis that it’s possible to build a “lifecycle management” layer that works with many stacks.
- Our profit motive is not in creating a separate “trunk” – and in general we want to be as closely aligned with the core of an open source community, but rather in delivering the stack as a turnkey integrated engineered system – so we naturally are less interested in forking.
While there was a ton of expertise developed through the ECS project, we realized that we needed to jumpstart these efforts by expanding the team with people who knew and understood the open-source ecosystem, could accelerate our OpenStack efforts, and understood the nature of building appliances that target that use case. That was the root of the Cloudscaling acquisition (if you read this blog post from Oct 2014 – you can see in it the fact that we were planning what would become VxRack System 1000 with Neutrino Nodes). – and the combination of the two groups gave the project critical mass.
We have been working on Neutrino Nodes for a while – and it appeared on the scene as “Project Caspian” at EMC World last year (look at the post I wrote then here – this was 7 months post the Cloudscaling acquisition, so you could see we were making progress).
Like all innovation projects, it starts very tight, very focused – and the initial 1.0 release was done quietly on March 1st. Why quietly? For two reasons: 1) we want to hand-hold the first few customers; 2) because we needed to make the Neutrino Nodes compatible with the VxRack System 1000 vision for all forms of Rack-Scale offers, versus a forked platform design.
At EMC World today, we announced the new VxRack Neutrino Nodes (which are really the 1.1 release :-) in VxRack System 1000 will be available in Q3.
Now – in the end, it’s about the SYSTEM, not just the software or the hardware – remember that VxRack System – like all engineered systems is about “consume”, not “build”. We’ll get to the hardware – but I want to spend time on the software first.
The Neutrino Nodes are laser-focused on ONLY new “Cloud Native” use cases – and that means religiously separating the services from the infrastructure management layer.
For the 1.1 release, the first service use case for Neutrino Nodes is OpenStack – which uses the OpenStack Kilo trunk.
Sidebar – some people misunderstood Neutrino as a turn-key OpenStack appliance. It’s better characterized as a “software stack that can enable rack-scale systems that support multiple stacks, across multiple racks”. The OpenStack implementation is the FIRST, but not the LAST.
Now – whether you call OpenStack a “Cloud Native” stack is debatable (and I’m sure people will debate it). Unlike the VMware Photon platform which is also laser-focused on Cloud Native use cases, OpenStack is mostly still focused kernel-mode virtual machine “first” orientation.
What we wanted to show is that we could take OpenStack and make it really, REALLY turnkey. What’s next? Next up to bat (as you could imagine) is the VMware Photon Platform. Right behind it, we’ll
This is where Neutrino Nodes and their software lifecycle stack will prove their mettle. If we can have a singular lifecycle management stack that spans multiple stacks (not just OpenStack) – I think it becomes very, very compelling.
We think that we can deliver that stack in the most turnkey way – and this is a little bit of an “inception” idea – a part of that is the base abstraction is the container (like with ECS). This means that all the OpenStack elements are containerized from the get go.
Now – all that software is runs on the “Platform Node” in a Neutrino configuration. This software layer is the key lifecycle management layer and does all of this:
- Software install and upgrades (bedrock and upgrade services)
- Hardware management and maintenance on platform servers (increasingly using the OnRack platform)
- REST API access to Ansible for other services
- Registry of docker images
- Monitoring and reporting tools
- Elastic search for platform service logs
- Cluster state management
- Node and disk inventory management
- Container-to-node mapping
- Keystone service
- Account service
- The VxRack Neutrino Node and OpenStack UI
- Load balancers for platform servers
- OpenStack APIs
If you look at the elements that do the above – you can see that the Neutrino team’s approach to “built open-source to run open-source”. As we support additional services, their “baseline bits” would also be there (just like OpenStack is in 1.1).
Now – while we use the OpenStack Kilo trunk – we’re aiming for the “mainstream” use cases, so there are some OpenStack features and services that are not supported in this release:
- Unsupported OpenStack features:
- Nova cells
- Host aggregates
- Availability zones and region
- Unsupported OpenStack services:
- Murano, Trove, Sahara, Ironic
- LBaaS, FWaaS, VPNaaS, Designate (DNS-as-a-Service)
- Barbican
- Zaqar
- Manila
- Magnum
That said – the core OpenStack platforms services (Nova, Cinder, Glance, Keystone, Horizon, Neutrino, Heat, Ceilometer) are all there of course.
A question that I’m sure people will have: “I’m thinking OpenStack – do I go VMware Integrated OpenStack, or do I go this way?”
The answer is (to me) simple:
- If you are very into the VMware ecosystem (very common), and want a simple way to leverage OpenStack – go VMware-integrated OpenStack. The easiest way to get VMware-Integrated OpenStack, vSphere integrated containers, along with the whole VMware SDDC as a curated, integrated engineered system is the VxRack System 1000 with SDDC Nodes (see the post here).
- If you are very into the premise that you want something very close to the open source OpenStack trunk (in all likelihood in parallel to a VMware-based stack in the enterprise for apps that need more resilience and infrastructure services) – go VxRack System 1000 with Neutrino Nodes. BTW – reminder… Neutrino will also support VMware Photon Platform for a truly Cloud Native IaaS in the future.
Either way – we have a great answer for you – that’s customer choice!
Sidebar: being transparent about one other “choice”…. Another engineering/strategy topic that we’re working through with VMware is that the SDDC Manager could also be used as a life-cycle manager for the Photon Platform. This is an equally viable, and parallel effort.
The question (that we will figure out over time) is whether Photon Platform is better served via a life-cycle management/rack-scale infrastructure management layer that optimizes for the vSphere SDDC, and targets both “P2 and P3” use case… OR… whether the Photon Platform is better served by the Neutrino software stack which is a life-cycle management/rack scale infrastructure management layer that optimizes 100% for the container oriented “P3, open source world”.
It’s not common for us to pursue 2 parallel paths – after all, customers are different, and the market is huge.
Now – back to Neutrino nodes – in the end, all that software fades into the background, with a simple way of interfacing with the whole system programmatically or graphically:
Now, what about the hardware layer? Here’s an example of the variations for a VxRack System 1000 with Neutrino nodes for the first rack. Note that they always have one or more “platform nodes”, but that subsequent scaling (the ones in red) is as simple as snapping them in.
VxRack System 1000 with Neutrino Nodes – like all VxRack System variations built on FLEX Nodes and SDDC Nodes has that “plan on how you scale BIG” thought through – including the physical ToR network (shared by all VxRack Systems) and the SDN layer.
In the case of Neutrino 1.1, we use Open vSwitch and Neutron – but we think that over time, we’ll be able to get more leverage using NSX, particularly as Neutrino Nodes support Photon Platform.
I’ll keep saying it – this is the big difference between appliances and rack-scale engineered systems, in addition to the broader variations you see in rack-scale systems in personas and node types. Both are delivered in a turn-key fashion, it’s more about “start small and scale out” vs. “start by thinking about HOW to scale really big and then scale out from there”.
And here’s how they map look physically:
Loaded to the maximums for the 1.1 release – you can have up to 4 VxRack System 1000 cabinets with 45 or 45 “bricks” (there are two types) – which can be as many as 180 nodes. Not as big as a FLEX Node based system (1000 nodes), but those limits will increase over time (the factor that governs this is the lifecycle management software part of the stack).
Here loaded with “Rinjin” (2U4N) Nodes….
…And here with “Hydra” (2U1N) Nodes.
The diagrams above are themselves is a simplification – there are 3 different Rinjin and 3 different Hyrda Neutrino Node variations with different CPU/Memory/Storage mix. Of course – we will continue to evolve the platforms, and suffice it to say – I think that as the Dell/EMC merger closes – like all VxRack System configurations – FLEX, SDDC and Neutrino Node variations will continue to expand.
Let’s net this out:
- VxRack Neutrino Nodes are an example of EMC leaning into the Cloud Native and open-source world in a big way.
- EMC embraces both the “build” and the “buy/consume” open-source world.
- If you look at EMC{code} and our core contributions to Docker, Cloud Foundry, Mesos and many, many other projects as well as ones where we are the primary contributor (OnRack as one example) – they are all a recognition that the world of “build” is important. And of course – our contributions are but a part. What VMware and Pivotal contribute is enormous…
- … But we think that for the bulk of the enterprise market – they are going to want to “buy and consume” an industrialized, curated stack, because after all, it building and maintaining this stuff isn’t their business, and doesn’t differentiate them in any material way. It’s not that they can’t (and many will try, and some will succeed!) – customer have a lot of smart people that by their nature want to tinker and build. I think (we think) that we need to make the choice an easy one – buy, don’t build. VxRack System 1000 with Neutrino Nodes represents our inaugural offer to industrialize a turnkey Cloud-Native optimized IaaS.
- VxRack System 1000 with Neutrino Nodes is a great IaaS substrate for the Native Hybrid Cloud stack, along with VxRack System 1000 with FLEX (for customers who want vSphere).
VxRack Neutrino Nodes – welcome to the world!
Let’s end the way we started – the summary:
VxRack System 1000 with Neutrino Nodes delivers a turnkey IaaS, one that is 100% focused on supporting new Cloud Native apps. It’s designed to optimize for elasticity, simplicity, cost-effective scaling – with little focus on “deep resilience”. It’s NOT for general enterprise app stacks (if you need that FLEX Nodes and SDDC Nodes). VxRack Neutrino Nodes are built by open-source technologies, and is designed to run open-source software stacks.
Will be interesting to see customer reaction – will they evolve past “play” into “consume/buy” for Cloud Native apps like we see them doing for traditional enterprise apps?
We have an aggressive roadmap – and Neutrino’s magic is most powerful when we add multiple different services beyond the starting point with OpenStack (top priority is the VMware Photon Platform, and the Apache ecosystem right behind that) – but even now, you can see a dramatic simplification.
We passionately believe that we must make Cloud Native infrastructure turnkey. There are likely going to be mulitple IaaS stacks, and a broad data fabric ecosystem for the foreseeable future. VxRack Neutrino Nodes are turnkey, and show how it’s possible to make the complex simple.
We passionately believe there is an opportunity to accelerate people doing what WILL differentiate their business – which is building new apps in new ways with Cloud Foundry. That means that NHC and VxRack Neutrino are strategically as important over the long term as the Enterprise Hybrid Cloud and Vblock.
What do YOU think???
Comments