VxRack FLEX – who is it for, what’s the latest, and what’s next?
- March 17, 2017
Over the last few months as VxRail has taken off, VxRack SDDC has been launched, the Dell EMC position on the XC platform has become more clear – and finally as people have internalized that HCI and CI (VxBlock) will coexist for years… I’ve started to get a question that is a real head-scratcher for me, and I’ll paraphrase:
“Is VxRack FLEX important, what is its future, and what are the use cases?”
The answers to the compound question are simple: “Is it important? Heck yeah. What is it’s future? Bright. What are the use cases? There are many.”
Making it really clear, the role of VxRack FLEX is right in the name. It’s FLEXIBLE.
Now – FLEXIBILITY and SIMPLICITY are design centers that pull product teams and offers in opposite directions (and if you think otherwise, there’s a bridge in Brooklyn that someone wants to sell you)
Yes, good design, and good software/automation can make any given offer simpler (or if you do it wrong, more complex) – but as a general principle, you gain simplicity as you start to “pin down” independent variables and assign fixed values – reducing optionality, but increasing system level integration and simplicity.
Put otherwise, VxRack FLEX is always going to require more expertise than an HCI rack-scale system that “pins down” the core abstraction/virtualization layer to always being vSphere for example (like VxRail, VxRack SDDC).
Covering the whole market requires that we cover these two ends of the HCI spectrum (flexibility and simplicity) with the best offers in the market – so VxRack FLEX plays a critical role both today and tomorrow.
Read on past the break to understand more. I’ll deconstruct each of the 3 points, and also share where we are taking VxRack FLEX next!
Let’s start by looking at a couple of customer VxRack FLEX installations:
What do you see in common?
The first thing people observe is that VxRack FLEX systems are BIG. Q: Is that the defining element – scale? A: No.
The defining elements are NOT that VxRack FLEX systems can be big (though they certainly can – they scale like nothing else I know of!).
The defining elements for VxRack FLEX are the three points: 1) heterogeneity; 2) compute/network/storage independent scaling; 3) complete freedom in resource redirection.
Let’s be clear – all HCI Rack Scale Systems from Dell EMC share a common characteristic: networking is part of the system design and integral to the product offer.
This is true of both VxRack FLEX and VxRack SDDC, our two current HCI Rack-Scale offers.
The “bigness” (scale) is the first thing people see – and incorrectly think of as how to “segment” or build a mental taxonomy of where they apply. Darn humans… we’re so tactile – we ground ourselves in the physical always.
With HCI – some of the traditional ways that people segment infrastructure (“SMB, Mid-Range, Enterprise Datacenter”) just don’t apply – no matter how one tries.
Frankly, when we started with VxRail, we thought it was reserved for “SMB/ROBO” – we figured out quickly that wasn’t right as people pressed it into action in datacenters with tens, and then many tens of appliances.
With HCI appliances – like VxRail or XC – frankly, there is nothing stopping a customer from having hundreds of them in a core datacenter. Start small – scale as big as you want/need. You can see a massive VxRail deployment here.
Now, it’s not a hard and fast rule that VxRack FLEX has to be big – but the simple reality of making the network part of the system design means a set of pretty dense/powerful ToR switches, management switches, and there’s of course the minimum node counts (4 for VxRack FLEX). You can’t see it in each of the pictures above, but each cabinet has integrated ToRs with many 40GbE ports, many Tbps of aggregate switching capacity – and SDN operational models have always figured into the design centers of VxRack systems.
That means that the smallest HCI Rack-Scale system (think “scale really big!”) will always start bigger, and start with more capital gear than HCI appliance (think “start small!”) – because it is designed to snap in nodes, and scale horizontally across many cabinets in an integrated system fashion.
That said – as a general principle, if you know you are going to need more than 10 or so HCI Appliances, you should REALLY consider starting HCI Rack-Scale systems.
Asking yourself this question forces a dialog along these lines: “If we know we will be needing a lot of east-west network traffic for SDS, and ultimately we will need to scale across cabinets – shouldn’t we be evaluating whether we should make the network design part of the system? And while we’re at it, shouldn’t we evaluate whether we are ready for network transformation with SDN?”. The answer may be “no, we are not ready for network transformation” (in which case you deploy a truckload of HCI appliances) or the answer may be “yes, we are ready” (in which case you start with a smaller HCI Rack Scale system).
In the 2 x 2 quadrants of the Dell EMC HCI portfolio – this distinction (HCI Appliances, HCI Rack-Scale Systems) represents the “left and right”.
Ok – so if “bigness” is not the main point – let’s get back to what IS defining about VxRack FLEX…
Understanding the critical role of VxRack FLEX is to understand that HCI design centers have an orientation that I don’t know how to refer to other than “vertical” or “horizontal”.
“Vertical” denotes a design orientation around a specific stack. VxRail, VxRack SDDC are examples, as well as the current approach of the Microsoft Azure Stack. This design center deeply roots the design (both the hardware choices and more importantly the software and lifecycle management) around fixing one or more variables, like the hypervisor.
For example, VxRail and VxRack SDDC start with a core assumption: “Every host will run ESXi”. This then leads to: “every workload will be a VM”. This then leads to: “natural boundaries are vSphere and vCenter boundaries”. This then leads to… So on, and so on. The advantage of this approach is nothing can match its INTEGRATION & SIMPLICITY (operative words) with that particular set of stack choices.
“Horizontal” denotes a design orientation where HCI is viewed as a pool of compute/network/storage resources that can be used across many stacks, and very generalized use cases. This leads to a much more FLEXIBLE (operative word) design – from the hardware variability to how the SDS layer needs to work. It also means that resource (compute/storage/network) distribution cannot pre-suppose any given natural “stack boundary”. The management and orchestration stack of horizontal HCI models is much more challenging – because no variables are “pinned down”. The advantage of the “horizontal” approach is nothing can match its FLEXIBILITY (operative word) across different stack choices.
Here’s a chicken scratch diagram (yes, I’m enjoying my new XPS 13 2-in-1 🙂
The “vertical” stack on the left is fully integrated all the way up to the abstraction. In the example of our two VMware HCI offers that are vertically integrated (VxRail and VxRack SDDC), the abstractions are vSphere which leads to ESXi/vCenter, vSAN, and in the case of VxRack SDDC – VxRail’s HCI Rack-Scale system sibling (remember, Rack-Scale = network included) – NSX. This is always the case with VxRail and VxRack SDDC.
Note that this tight coupling means that the integration of the whole set of HCI offers goes further – which makes them fundamentally simpler. “Fixing” those variables also means that things like vSphere cluster boundaries, vCenter maximums – these trickle down into all the elements of the design. What workloads can you run? Good thing with vSphere as the “fixed variable” is you can run a heck of a lot – the majority of enterprise workloads, frankly. But – not all. If someone said “I need a workload that does 5 million IOps”, it would be a bear, if not impossible. It also means that you can simplify certain choices – for example, you don’t need any imaging services other than those needed to image nodes with ESXi. You don’t need hardware telemetry that is independent of what you get through ESXi. You can get by with a simple hardware abstraction layer.
The “horizontal” stack on the right is integrated, but not all the way up to the abstraction. You could use multiple different abstractions. Uniquely with VxRack FLEX – this heterogeneity isn’t just a one time choice (“pick your hypervisor”), but literally you can have vSphere, KVM, and physical hosts with no hypervisor all on the same system at the same time.
Note that this looser coupling is fundamentally more FLEXIBLE (there’s that operational word). Frankly, almost any workload – aside from those that need the most stringent remote replication requirements, or cannot run on an x86-based system – can run on a VxRack FLEX system. It means that “some assembly is always required”. The integration doesn’t go all the way up into the abstraction layer. Yes, you can use vSphere (in fact, that’s the most common abstraction on VxRack FLEX), and it works great – but vSphere deployment/patch/lifecycle – this falls outside the system itself. It means also that the management & orchestration layer needs a lot more modularity – after all, it can be pressed into many, MANY use cases.
This “horizontal” and “vertical” distinction is the other way of looking at the 2×2 matrix of our HCI offers at Dell EMC. VxRail and VxRack SDDC represent the “vertical” orientation. XC and VxRack FLEX represent the “horizontal” orientation.
Not that it matters, but it’s interesting – we are organized around this principle.
What are common VxRack FLEX use cases? Frankly as a “horizontal HCI stack” – there are a million. It can be used as a simplifying set of infrastructure for any “horizontal” infrastructure use case. Here are some common examples we see:
Now – in several of these cases, Dell EMC also has a “vertically integrated” approach as well as the “horizontal” one. For example, running EHC on VxRail would be an example for Transforming IT operations with a very simple, very “vertically integrated” stack. Another example would be Modernizing Applications could be NHC on VxRail also. Both EHC and NHC will both will also be available on VxRack SDDC as well.
However, some customers prefer the horizontal HCI Rack-Scale approach – a common pool of compute/network/storage for all workloads simultaneously. Let me give you some real world examples:
There you have the FIRST of the things that make VxRack FLEX important – and reinforces the core value of FLEXIBILITY: any mix of workloads, any hypervisors, physical hosts – all at the same time, on the same system.
Second – hardware variability and independent CPU/storage scaling.
When you design a “vertically integrated” stack – you know that you can assume certain “common combinations” of compute/memory/storage. Yes, there’s a broad range of configurations with VxRail and VxRack SDDC – but how the stack “comes together” ends up building around what you generally see in 99.9% of the cases with that abstraction model. You can see this “pop out” in some of the vSAN best practices. It’s relatively hard to create a mix which is VERY CPU heavy/storage light, or CPU light and VERY storage heavy with VxRail or VxRack SDDC. This is one of the reasons BTW that we’re working together with VMware to make bringing external storage (including SDS server SAN with ScaleIO) to bear to VxRack SDDC over time.
Conversely, with VxRack FLEX – node mix and match is very FLEXIBLE.
Frankly, the 3 examples in the diagram above here are just that – examples. You can mix and match node types all over the place with VxRack FLEX, covering an almost infinite range of CPU/storage mix and ratios. In fact, a system could have multiple domains with different combinations. This is important, because in VxRack FLEX – we can’t make any assumptions about common use cases.
There you have the SECOND of the things that make VxRack FLEX important – and reinforces the core value of FLEXIBILITY: any mix of CPU/Memory/Network/Storage – because we need the flexibility for almost any set of datacenter workload mix.
Third – completely flexible resource distribution.
When you cannot assume any given abstraction – you need to be able to move resources that are fungible to any workload. The power of ScaleIO as the SDS that underpins VxRack FLEX shines in general, but very much so in this area. You can see how this need is echoed in the “two types of SDS” post I did here – and why ScaleIO is at the core of VxRack FLEX. The flexibility of a SDS that is a “server SAN” is that the capacity/bandwidth/IOps can be distributed in any way one could possibly need.
For an example, if you use the nodes in a dense storage configuration – you could take 24 nodes and direct the full oomph of the 24 nodes to a single workload. Think of the OLTP example for the hotel chain – that workload does need millions of IOps for a single set of host that are clustered (and in that case a physical host).
Furthermore – the pool of storage resource pooling and distribution is completely independent of abstraction. You can assign it all to one VM, one host. You can pool it across clusters. You can share IOps across tenants, or dedicate them. The idea of a “vSphere cluster” as a natural boundary would not be applicable – because by definition, vSphere is one (the most popular) abstractions, but not the only one.
There you have the THIRD of the things that make VxRack FLEX important – and reinforces the core value of FLEXIBILITY: resources can be distributed anywhere across the system – because we need the flexibility for almost any set of datacenter workload mix, and can’t assume any “natural abstraction boundaries”.
There you have it – VxRack FLEX is FLEXIBLE.
It means that VxRack FLEX can be put into an incredibly broad set of use cases – but needs a little more work for the customer to integrate into any one given stack or use case. Some readers may scratch their head and say “I don’t get it”. That’s OK – it means you’re likely someone that has a very VMware-centric world-view (which is great!) For those people, VxRail and VxRack SDDC are the Dell Technologies manifestation of that vertically integrated stack by Dell EMC and VMware – and no better choice for that type of customer.
Conversely, others naturally think: “No way – I want my HCI Rack-Scale system to be flexible enough to support vSphere and other use cases, and I’m willing to trade off SIMPLICITY for FLEXIBILITY”.
Customers in my experience very rapidly sort themselves into one of the two architectural approaches – and it’s our intent to lead in all forms of Hyper-Converged infrastructure, just like we lead in all forms of Converged Infrastructure (VxBlock).
So – what’s next for VxRack FLEX? A lot.
While most analysts/market noise is about the battles in the HCI appliance space and market (and it is hot, fast and furious!) where VxRail is making massive headway – I believe that VxRack FLEX will be a billion dollar market in the next 2 years (along with VxRail and VxRack SDDC).