Different people have made different trade-offs.
That's really what we're going to be talking about today.
Here are the trade-offs that we made.
Here are the choices that we made.
Here's why we did them.
Here's the benefits that we get for our customers in used cases.
First, the disclaimer.
This is based on public sources for each company.
I only work for one of these companies, so I have to go off what they publicly say about
their architecture.
If it's wrong, I either read the source wrong or they didn't actually disclose it accurately.
We won't be covering every architecture, because quite frankly, some of the ones that are out
there are not all that different from traditional raise.
Other ones don't have a rich set of features, so frankly, their architecture doesn't have
that much to talk about.
Some just aren't that well documented.
There are some out there that they haven't really disclosed anything about the architecture,
so I can't really talk about it.
System scale.
How are capacity and performance scaled in the architecture?
Of these three architectures, one is a fairly traditional scale up architecture.
This is the traditional model for block based storage, the scale up model.
That's not necessarily a bad thing.
There is a familiarity with the scale up model that a lot of administrators have.
Moving to flash, a lot of times they want to carry over with a similar model.
You get more performance out of a scale up model by moving to more powerful controllers.
That's why it's called a scale up model.
Typically these companies have a line of controllers with more CPU and memory in them that gets
better performance as you move up the line.
Also, by adding more spindles.
In the flash based world, that doesn’t always necessarily get you more performance.
More capacity comes from adding more disk shelves to the system.
Once you reach the limitation of your controller, once you've got your fastest controller and
you've maxed that out, you've got to get more capacity or performance by adding additional
storage systems.
You could start with a theoretical system that has 20 terrabytes and 200,000 IOPs, except
this isn't theoretical, I think this is their spreadsheet.
Then you could add more disk shelves and get more capacity, but you're really not getting
more performance, because the controller is actually the limiting factor on performance.
In the scale up architecture, you generally scale performance and capacity together in
some cases.
You actually add more controllers over time to get more capacity.
We call those nodes.
They call those bricks.
Typically those controllers are attached to some amount of capacity.
In our case case, they're internal.
[inaudible 02:25] they use a disk shelf.
In either case, you're getting more capacity with more performance.
One of the nice things is, if you have a mix of capacity and performance you like, it's
not going to get out of whack over time as the system scales.
That's been one of the traditional problems with scale up is, I can add more capacity
to it, but now my ratio of capacity to performance is different.
That means I either have to buy a bunch of performance up front that I didn't need, or
I didn't buy they performance, and now I'm out of performance and I've got to upgrade
my controllers.
One of the unique things about solid fire that extreme IO certainly doesn't offer today,
is the ability to get to an overall balance of capacity and performance with different
node types.
You can build a cluster with a lot of performance and a little bit of capacity, as we saw in
that graph, or a lot of capacity and little bit of performance, or mix nodes to get whatever
balance you want.
You don't have to feel like you're stranding either one of those as the system expands.
Of course, with solid fire today, you can scale out the system and get balanced load
as the system scales automatically.
You don't have islands of storage.
Not that you can't have multiple solid fire systems, but those islands are going to be
much larger management domains and entities.
You have to play less manual management games to keep everything balanced.
Comparing contrasting these, we've talked about a lot of these points.
One advantage of scale up is it's frankly easier to engineer.
There is a lot of complexity when you get to scale out systems.
Distributed systems are very difficult.
A huge percentage of the code in our system deals with the scale out distributed system's
nature of the system.
They are a lot harder things to engineer.
Almost nobody in the industry has ever added scale out to an existing scale up system.
Nobody's ever done it because it is something that really needs to be engineered from the
beginning.
Scale out obviously gives you the ability to scale to more significant capacity and
performance levels, a simpler upgrade path, and the possibility to actually remove nodes
and down grade.
If I had to sum, I'd say that scale up is better for small, fixed, predictable workloads.
If I know what my workload is, and I can size a system capacity and performance to fit that,
very easy.
Put it in, live with it.
If you have larger scale, if you have unpredictable growth, the flexibility of a scale out model
is the better path.
I think that's why the majority of the interesting development in the storage world right now
is in scale out models.