« Two Big Deals EMC Architect Tool, and a HUGE new way to get EMC software. | Main | Best job for an Americas Leader of Technologists..interested? »

January 30, 2014


Feed You can follow this conversation by subscribing to the comment feed for this post.


This is a nice categorization. This is very important in recent times given the amount of categorization that is happening.

Disclosure: I work for Oracle

David Nicholson

The fact that I read this three times after midnight is mildly disturbing. Thanks Chad for contributing to the world of the techie double entendre. I will now dream of loosely coupling.

Seriously, though, the timing of this discussion is perfect. With a foundational architectural understanding, discussions become so much easier.

Markus Zappolino

Chapeau Chad finally somebody catched up the topic in the right way.
I tried that in the past in similar way but was not so precise and helicopter view like you.
This really helps me a lot to get in front of Customers and explain this in broader fashion at least at CIO Level.

Eric Gray

Interesting read. Is Gluster Type 4?

Alexander BREViiARIO


This is the Superbowl of posts, the Mother Load when it comes to understanding storage architectures... I can't believe I read the whole thing and understood it, which is what made it enjoyable...
It even reminded me of the original NUMA technology that was deployed by Data General and IBM many years ago. Question: What server architecture type did NUMA utilize?

As to your comment, "storage is so booooring... it's all the way at the bottom" just remember that being at the bottom makes it very "foundational" to everything else above it... When it comes to data storage; the gazillions of bits of data ultimately have to land somewhere! When it comes to servers, the networks, and the layers of software stacks that move them back and forth, all those bits of data are more often than not just passing through...
EMC - Where Information truly Lives!

Chad Sakac

@S. Siresh - thanks for your comment!

@David - LOL - I didn't even catch the double entendre!

@Markus - would love to see how to make this consumable/interesting for a CIO... seems too nerdy for that audience, no?

@Eric Gluster is actually a loosely coupled scale-out (Type 2). It's in the same design centre (not saying the same, but same design centre) as Isilon. You MIGHT be making the classic blunder (and no I don't mean a land war in asia) of conflating the "it's servers with ethernet' (i.e. physical implementation) vs. the software architecture.

@Alexander, thank you ;-) My comment about "storage is so boring" was actually a little tongue in cheek. It was a setup for the point that information is right up there with the app. App + information = what the user ultimately wants.


Fantastic material as always.
I believe that by framing the architectures in this way (as a "phylum") we can more easily get to the standardization of storage/persistence architectures required to build highly efficient internal, external and federated clouds. As complicated as this was to read it is much more clear than the noise of product features that fill the air.


This looks like storage-technology description going 'inside-out' as opposed to traditional 'outside-in' (aka the network perspective), which seems simplistic in comparison.
(though type4 makes things a bit 'outside-outside')
Ultimately, both views are valid, and the real issue is 'who's asking'
(dump users who care about the bottom line ,techies who care about everything or CEOs/etc who go 'in between' the two extremes).
Thank you for this fresh perspective!

Neil Levine

Great blog, Chad. I'm a big fan of clarity through taxonomies :-) I'm a little fuzzy on how you are defining transaction in the context of its being the major difference between type-2 and type-4 architectures. Can you elucidate a little?

Stu Miniman

Hi Chad - lots of interesting topics here. In case you haven't seen, over at Wikibon we put forth a definition of a new category named "Server SAN" that looks to explain many of the same trends that your discuss (hyperscale, distributed architectures) - see http://wikibon.org/wiki/v/Server_SAN_Market_Definition

Andrew Linnell

Great post Chad - brings back some biology and philosophy - heck, er Haeckle's ontogeny recapitulates phylogeny could (almost) apply here too! Trace architectures back in history: shared everything VAX clusters, shared nothing WNT.


Great post, great categorization!
For me, the IBM DS8000 series has always been the one that is hard to classify. In so many ways it seems to belong with EMC Symmetrix and Hitachi USP-V, VSP. But it's not a scale out architecture from the storage controller CPU perspective. Two controllers, you get what you get and can't add CPU. Different from Symmetrix and USP-V/VSP where there is scale out available for storage controller CPU.


Great post. How would you differentiate transactional vs. non-transactional, i.e. type 2 vs. type 4?


Hi Chad, a really Great post ! :)
One question ! Is VPLEX Type 2 ? :p


I read it again. Thanks for sharing your point of view. Nice and deep approach!

Chad Sakac

@Johan - transactional is "small IO size, low latencies (<10ms), low latency variability), and consistent (what is written is considered durable). Many of the Type 4's are much higher latency, more latency variability, deal with much larger IO sizes, and some (not all) aren't even consistent (you need to check that what you're getting is what you thought you wrote) - this last characteristic is about scaling and geo-distribution vs. tight consistency.

@Acosteseque - yup - VPLEX is a Type 2!

@Fernando - THANKS!

Arihanth Jain

Hey Chand thanks for the awesome post.
I am a student and currently working on a thesis topic (building a performance analysis tool for uniform evaluation of type 1 and type 4-CEPH architecture). I still have some difficulties in understanding the distributed storage subsystem. Could you please provide some reference materials (some research papers or any other) for type4?

Thanks in advance!

Andreas Trapp

THE map to use in the storage jungle! Great post!


Relatively good writing but one of the main questions is left unanswered: what is a functional difference between highly-coupled scale-out and tightly-coupled scale-out? By 'functional' I mean 'user-observable'.

What does shared memory add that cannot be achieved with private memory?
What is '“symmetric” IO paths through all brains'? How does it pay into HA and performance?
Tightly-coupled scale-out requires HA controllers. What does it simplify in design? What does it mean for performance? What is lost in loosely-coupled scale-out when HA controllers disappear?
Why data path in loosely-coupled arch is longer than that in tightly-coupled scale-out?


BTW. Cannot find this information anywhere...

Is Isilon's implementation of HDFS transactional (i.e. doesn't contradict to type 3) or non-transactional?

Sergey B.

-- Here’s the interesting thing to understand about “loosely coupled” (Type 2) and “tightly coupled (Type 3).
++ Here’s the interesting thing to understand about “tightly coupled" (Type 2) and “loosely coupled” (Type 3).

The comments to this entry are closed.

  • BlogWithIntegrity.com


  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.