EMC World 2016: Understanding VxRack System 1000

I want to make something really simple:

• Vblock and VxBlock systems are not a singular THING – they are a Converged Infrastructure system design.
• Similarly, VxRack System 1000 is not a singular THING – it is a Rack-Scale Hyper-Converged Infrastructure system design.
• Conversely, VxRail IS a singular THING – it’s a hyper-converged appliance.

Let’s use an analogy – and if you haven’t seen the Lego Movie: 1) this analogy will be strange; 2) what you are you DOING!  drop everything and watch the movie!

Ok – back?   Let’s continue after the break.   Taking the time to read, internalize – will help a lot with blog posts on VxRack SDDC Nodes and VxRack Neutrino Nodes that are coming!

 

 

These are both Lego – one of the world’s most beloved toys. They are different systems. The first is Lego System. The second is Lego Technics System. They have lots of parts that are engineered to work together.   Some people buy and assemble their own toys by following instructions (that would be a reference architecture).

First consider…

Vblock, VxBlock Systems and VxRack System 1000 are engineered systems.

They are composed of parts that are engineered, tested, manufactured, supported, sustained, managed using a system level design (in this case Lego System could be CI system designs like Vblock and Lego Technics System could be HCI Rack-Scale System designs like VxRack).

The have a whole lot of pieces – servers, network, storage arrays of various types, software-defined elements, software that manages pieces or in whole.

Now, what makes them Engineered Systems is that they DON’T arrive to you at the customer in pieces that you then assemble.  The EMC team and VCE specialists listen, determine what you need, and the VCE factory does the assembly (within parameters we maintain).   There is some combinatorial flexibility within the parameters of the design.    The Engineering teams maintain the Release Certification Matrix (RCM) which is analagous to the “kragle”.  I want to reiterate that key thing to understand when the Vblock, VxBlock, or VxRack System (with all node types) arrives – it is NOT Lego. It arrives completely turnkey and ready to go. It is engineered to the customer specifications, and then “kragled” together in the VCE factory.

Engineered Systems ends up with a lot of customers with confident smiles like the fellow below.

Now – from then on is in compliance with the RCMs, and VCE or our partners do the updates.   You can add blades and incremental storage to Vblocks, and with VxRack Systems, adding incremental nodes is easy (because it’s Hyper-converged and comes with the network) but when you want to add something beyond the parameters of the “kragled” design, you need to either buy another Block, or a Tech Extension (which itself is a integrated system which attaches to the Vblock/VxBlock via the network fabric).

This “glued together Lego” is a good but not perfect analogy. 

Some people (often competitors) say that it’s rigid, and I would say “we’re flexible to a point, but within the system design limits, the answer is YES”.   That tight system design is exactly what gives converged consumption models their raison-d’etre.   We take on the burden (and when are less than perfect, it’s usually traceable to a moment where we didn’t stick to “NO”).  Vblocks, VxBlocks, and VxRack systems are not a reference architecture – they are engineered systems. 

They are also not the right choice for people who prefer to build their own from best-of-breed.   BTW – those people HATE converged infrastructure and resist it furiously.   Why?  Because they WANT to tinker.   I’ve found the point is to direct them to keep tinkering, but not at this infrastructure layer – because it’s BORING.  Let us take on the responsibility. 

In exchange for accepting the parameters of Vblock, VxBlock and VxRack systems – customers:

• get running 4x faster.
• deploy new apps 5x faster.
• experience 96% better availability.
• lower their full TCO of the infrastructure layer by 50%.

That’s not me saying it – it’s the customers.   See here.   See here.   Those are the reasons people are CHOOSING this model.

Now, consider VxRail and it’s Hyper-Converged Infrastructure Appliance competitors.   To continue the toy analogy - they are more like these Hot Wheels cars – equally fun, but in a different way.

HCIA examples (and I’ll stick to VxRail, but if you think about it’s peers, I think you’ll agree the analogy fits.

There are a fixed number of models.

Those models are completely fixed (you can’t really tweak a sub-element).

They are completely self-contained and just put on the track and go.

You don’t need need to talk to someone to get requirements, who then assembles to those specifications.  You pick the car and the color and go.

There no “kragling” step.

They are… Appliances.   Not Engineered systems.  

It also means that the defining element of Engineered systems not just metaphorically, but technically (the network/SDN domain) is not needed with Appliances – because the domain of “how these fit together” is outside the “system scope”.

This analogy helps explain why the average time to evaluate and purchase a VxRail Appliance is measured in days, and arrives in days (weeks right now – it’s so hot, we have a backlog). If you want turnkey, holy smokes, there’s nothing easier.

Conversely, Vblock/VxBlock/VxRack engineered systems involve design and planning, and considerations – and once purchased, arrive in our targeted SLA of 45 days.

There’s no value judgement in there – but highlighting the difference.

Why do I explain this, and why right now?

I’ve seen some people (my colleague @Chris_Mellor, who is normally so tight on decoding us) describe VxRack System 1000 in the wrong way (don’t bother following the link, he’s wrong here) – and I can see why. I’m here to correct that – because this post is all about VxRack System 1000, and understanding VxRack Node types.

First – let’s cover what is true of ALL VxRack System 1000 configurations:

1. They are rack-scale – they always start with a top-of-rack spine-leaf network design, and contemplate scaling well beyond a single rack. They share ToR standard and design principles. Sometimes we’ve needed to adapt the Node design to plugin – but we take that principle (“Rack-Scale system design can’t be lightweight on the network”) seriously.
2. They are all hyper-converged, software defined, and use industry-standard servers as their “nodes”. Each brings a Software Defined Storage model, and some also bring an Software Defined Network Model.
3. They all have an integrated management plane that is optimized around the use case and node types.
4. They will all integrate with VCE Vision for passive management (context in the system, capacity, RCM).   They don’t yet.   Working on this.
5. Ultimately, they leverage a set of Nodes as building blocks. These are a combination of specific software and paired industry standard servers – designed around a specific use case.

What gives VxRack Systems their “personality” (and workload/use case fit) are the Node types used.

Nodes are just industry-standard hardware, so understanding them isn’t about the hardware, but the software.  The behavior, scaling, and use cases for a given Node type are defined by the software that is paired with the hardware, and they are designed together. Currently there are 3 node types:

1. FLEX Nodes (Shipping now) – aims at heterogenous IaaS use cases.
2. SDDC Nodes (quotable now, shipping at the end of May) – aims at the homogenous VMware SDDC use cases.
3. Neutrino Nodes will GA in Q3 – aims exclusively at the Cloud Native infrastructure use cases.

Each brings Node type implies a set of SDS, SDN choices and an integrated management plane.

Hopefully this is helping build a deeper understanding:

• Appliances are turnkey.   VxRail our Hyper-converged infrastructure appliance offer.   VxRail is what competes with Nutanix, Simplivity, and many others that are also appliances (though they may not call themselves that).
• Hyper-Converged Rack Scale Engineered Systems are also turnkey – but do involve a “design and kragle” phase.   They are turnkey because of the process and the software that auotmates addition of Nodes to the system once it’s in place.  VxRack Systems are our offer in this category.

Ultimately the market will determine whether we’re right and these two hyper-converged approaches (appliances and engineered Rack Scale systems) are different – but I think they are.

Why do I think they are different?  Well, we support a LOT of customers – with a LOT of diverse use cases. IMO – there is no one combination for all customers.

Time will tell which of these prove to be the most commonly adopted (there’s no question the number of customers for whom appliance are enough is larger – but I suspect the overall market by size Rack Scale Systems is actually much larger).

There’s great flexibility in being able to support different use cases with a common VxRack System architecture, and the configurability that comes with different node types.

Sidebar: Our intent is to continue to work to bring together several horizontal management layers across all node types inclusive (but not limited to) the passive reporting/RCM functions of VCE Vision – which is currently supported on VxRack Systems with FLEX Nodes, but will ultimately support SDDC and Neutrino Nodes. I know that we must further “bring together” the management model of the 3 different VxRack System node types. Ultimately – that’s our goal – to extend and integrate the management models of all VxRack System Node types – being able to manage mixed Node Types in a single system view, and ultimately even perhaps provide a simple path from VxRail deployments into VxRack System 1000. Working on it!

I used Lego Technics as my analogy for VxRack Systems, so let’s continue that by showing these as the 3 types of VxRack Nodes that currently exist – FLEX Nodes, SDDC Nodes, and Neutrino Nodes.

I’m going to need to dig into my collection of parts here…. Let me see what I can dig up…

Ok – here are three standard technics pieces:

Let’s call the grey one the VxRack SDDC Node (because VMware uses the grey in their logo). SDDC Nodes are focused on the VMware SDDC use case only, but doing that better than anything else out there – PERIOD.

Let’s call the yellow one the VxRack FLEX Node. FLEX Nodes are focused on supporting heterogeneous IaaS use cases out there better than anything else out there – PERIOD.

Let’s call the black on the VxRack Neutrino Node. Neutrino Nodes are focused on supporting Cloud Native use cases out there better than anything else – PERIOD.

I want to reiterate – while there is some hardware/software linkage – the thing that is the dominant factor in the Node “flavor” and behavior is software, not hardware.

Let’s talk about these ones in more detail:

VxRack SDDC Nodes

• Currently 1 node type: 1U1N node hardware platform
• Abstraction: vSphere only, and vSphere optimized in every way.
• SDS: VSAN
• SDN: NSX
• Management and Orchestration: Beyond VxRack Manager (low level hardware) and VCE Vision (passive parameter Also brings VMware SDDC Manager to the party, which makes deployment and lifecycle of the VMware SDDC stack simple an easy – inclusive of vRealize Operations and NSX. Supports VMware-Integrated OpenStack and VMware-Integrated Containers.
• Scaling: scales to a maximum of 256 Nodes (1:1 correlation of Nodes/Hosts due to 1U1N form factor in the v1.0 release), in multiples of the vSphere cluster size maximums.
• What is a VxRack System 1000 populated with VxRack SDDC Nodes ideal for? Simple -  customers who are all-in on VMware and the SDDC stack.   A VxRack System 1000 composed with SDDC nodes can be thought of as the “Rack-Scale, engineered system, larger sibling of VxRail Appliances”.

VxRack FLEX Nodes

• More than 20 node types: 1U1N, 2U1N, 2U4N node hardware architecture, with broad CPU/Memory/Storage variations.
• Abstraction: vSphere and Linux (RHEL today). Working on other Linux variants, bare-metal and Hyper-V.  When in bare VxRack Node form (not engineered system) – these are supported today, but there’s more work to do to make them supported in VxRack System 1000 deployments.  Working on it!
• SDS: ScaleIO
• SDN: None or NSX
• Management and Orchestration: Uses the VxRack Manager fundamentals, along with VCE Vision.
• Scaling: scales to 1000 Nodes
• What is a VxRack System 1000 populated with VxRack FLEX Nodes ideal for?  Simple - customers who want a very horizontally scalable, and open rack-scale system, and want an SDS that spans clusters, and different abstraction models

 

VxRack Neutrino Nodes

• 2 node types: 2U1N, 2U4N node each with 3 different CPU/Memory/Storage variations.
• Abstraction: OpenStack/KVM (and vSphere Photon shortly)
• SDS: ScaleIO, also connects to Elastic Cloud Storage
• SDN: Neutron, moving to NSX
• Management and Orchestration: The Neutrino software layer is optimized for, and delivers a turnkey multi-cloud stack, multi-rack lifecycle management model for IaaS models that focus on high elasticity, low infrastructure resilience (i.e. optimized for Cloud Native app workloads).
• Scaling: scales to 45 Nodes (up to 180 hosts if using 2U4N Nodes).
• What is a VxRack System 1000 populated with VxRack Neutrino Nodes ideal for?   Simple - customers who are looking for lightweight abstraction models to support pure P3 workloads, and do not want or need deep infrastructure resiliency or services.

 

 

I’m going to do standalone posts on VxRack System 1000 with SDDC Nodes (available now, shipping at the end of May) and Neutrino Nodes (shipping in Q3), so I don’t want to provide more details here.

BTW – this post isn’t some sort of “hypothetical” :-)   If you want to see what a VxRack System 1000 (in this case populated with about 500 VxRack FLEX nodes) looks like here’s an example being deployed (all nicely “kragled”) at a customer site (thank you for sharing guys!)

Let’s summarize!

1. Vblock, VxBlock and VxRack are Engineered Systems – we build them to match the customer, using standardized parts, processes and supported engineering specifications.   They are turnkey. It makes them flexible within certain boundaries – and that’s a good thing for customers looking for Engineered Systems.
2. VxRail is an appliance – they are available in any color you want so long as it’s black.  You just need to take them out of the box and off you go. They are turnkey.   That very fixed nature is good thing for customers looking for appliances. It makes them super easy to order, easy to fulfill, easy to install (and BTW, they are available in more than just black, there are several different variations you can choose :-).
3. Vblock is one system design. VxBlock is one system design. VxRack System 1000 is one system design. None of them are one THING.
4. VxRack System 1000 as a system design supports 3 node types today:
1. VxRack FLEX nodes – for heterogenous general purpose IaaS.  Hugely horizontally scalable, vSphere, but others abstraction models as well.
2. VxRack SDDC Nodes – da bomb when it comes to customers uniquely focused on VMware SDDC at scale-points of 50+ nodes and want the network fully integrated so they can scale across racks.  If you can get away with 1000-3000 VMs, you can run that at the scale point of VxRail and be done with it.
3. VxRack Neutrino Nodes – for cases where people are all about cloud native apps, and don’t want or need deep infrastructure resilience, but want insane infrastructure elasticity.

More to come on VxRack System 1000 with SDDC Nodes and Neutrino Nodes to come!

Wondering – did this help clarify?

I suppose the world for EMCers and EMC partners would be simpler (and easier to internalize) if you ONLY do Hyper-Converged Infrastructure Appliances (think of VxRail and it’s competitors)….

…. But dear reader – put on your “truth-o-meter” – do you think appliances are sufficient to cover the market (of course single product startups will say “YES”, but what do YOU think)?

Looking forward to your answers!

BTW… If you’re wondering if I used the Lego analogy casually, here’s a picture of my laptop as I type this.

I. Have. Issues.

Comments

[Csgiddens]

Great write-up on the VxRack systems and looking forward to seeing them in action! Thanks Chad.

[Chad Sakac]

@Csgiddens - thank you for taking the time to read and comment!

[Vinnie]

Hi Chad - this write-up is spot on as usual. Your enthusiasm and ability to explain are second to none! My observation is that you make things sound sexy while Nutanix makes them look sexy.

(this is probably not a fair comparison because you don't make the websites, but....)

If you can influence EMC web layouts, now would be a great time to do so. Check out Nutanix and EMC websites on both your laptop and smartphone.

Which experience is sexier? Do you think that leads to customer conversion? Does it matter?

Thank you for your thoughts-