A Tale Of Two Architectures

Just saw Brad O’Neill’s recent article “Face Off: EMC DMX-3 vs. Hitachi USP 1100” in Storage magazine.

I thought it was very good on several levels, and would recommend it to anyone who’s interested in storage at scale.  Yes, you need to be a subscriber to read it, but if you’re reading this blog, you might consider filling out the form for a free subscription.

As many shops are going to be joining the infamous Petabyte Club over the next few years (or are already there!), I think there will be more and more people interested in what’s going on here.

Even if you don’t think of yourself as ever being interested in high-end storage, there are a few nuggets to consider.

Although Brad went farther than most, there’s still more interesting angles to explore. 

It’s A Small Club

The first insightful thing Brad did was narrow focus on “real” high-end storage, and excluded many of the vendors who aspire to that status.  Good call.

From a pure technology perspective, high-end storage is not about how many drives, or how many ports -- it’s purely an architectural distinction.

High-end storage arrays have large shared non-volatile caches, and multiple front-end and back-end controller boards.  This enables them to establish a performance, functionality and availability envelope that can’t be matched by more simple dual-controller or clustered designs.

I’m sure there are many product marketing departments out there that are frustrated by this characterization, but in my mind, there’s no arguing with the basic architectural differences. 

You’ve either designed a high-end array, or you haven’t.  I’ll probably end up writing more about this in a later post. 

Getting to official market share numbers are difficult, but my interpretation of the Q3 IDC numbers (most recent available) showed EMC outselling HDS consistently in this segment.  Keep in mind that market share fluctuates over time as vendors release new products and customers upgrade in different cycles.

The Use Cases

The second insightful thing I saw were the customers that Brad selected to advocate one point of view or another.  I don’t know whether Brad was smart or lucky, but he ended up picking customers that embodied the fundamental thinking (and markets served) by each vendor.

EMC’s advocate was the Depository Trust Clearing Corporation, or DTCC.  If you’ve never heard of them, they clear financial transactions that underpin the global economy. 

If the DTCC is having a bad day, the world’s financial system is going to have a bad day.

Now, not everyone is going to need continuous multi-site replication for business continuity like DTCC, but it was stunningly clear what was important to this customer: no excuses whatsoever on availability, recoverability or performance.  Plain and simple. 

And DTCC is not alone in this regard – for most businesses, there’s a component of the IT landscape that is clearly “no excuses”, and that’s where DMX-3 has a natural fit.

HDS’s advocate was the North American outsourcing arm of Atos Origin.  For him, it was all about re-using legacy storage in virtualized environments.  It was about driving the cost of storage services down, plain and simple – especially since it seemed he had lots of different storage arrays that he’d acquired through various projects. 

He was very proud that he was using the USP’s virtualization capabilities “in production environments”.  I would hope so.  By the way, Atos Origin is a good EMC customer and partner for other parts of their business.

Two customers.  Two different perspectives.  And two different high-end vendors.

Looking a little deeper …

One key theme in the article focused on different approaches to virtualization.  I think the discussion needs to go a bit deeper – why are you virtualizing in the first place?

For Atos Origin, the driver looked to be stranded asset utilization.  They had lots of different arrays on the floor, and they wanted to drive up overall utilization.  We at EMC would argue that – if what you want is higher asset utilization, there are cheaper and simpler ways to get there.

Good SRM software and ITIL practices, for example.

We continue to believe that using a storage controller for external virtualization makes managing predictable service levels very difficult, compounds the power and cooling equation that many people are wrestling with, and looks very expensive as well. 

It just feels like a work-around.

Now, if you’re locked into a bunch of aged legacy arrays with unreasonably long depreciation schedules (as service providers often are), and you have to buy another array anyway, this may be the only alternative available to you.  But it’s hard for me to think of this as an idealized solution.  And that’s not just because I work at EMC.

We think storage virtualization should target a different use case: non-disruptive movement of production workloads to different service levels.  If you can do it within the array, great.  If you want to do it externally, we see it as a network function, not a storage array function.  Going a bit farther, we see intelligent storage networks as a new platform for new forms storage functionality: replication, security, and so on.

Want to save money on storage, power and cooling?  Consolidate into a single device, rather than multiples.  Want to implement different tiers, service levels and cost points?  Consider tiering within the array – it’ll be cheaper and easier to manage.

Interesting footnote: in a recent post, Hu Yoshida from HDS claims that storage virtualization in the Hitachi model can save money on power and cooling, as well as a long list of other potential benefits.

The case here is weak.  Most of Hu’s claim is based on the assumption of higher levels of storage utilization.  EMC would argue that there are cheaper and simpler ways to get there – you don’t need an array-based storage virtualization if that’s what you want.

If you really want to talk game-changers here, there’s a much broader discussion around server virtualization, data-deduplication, intelligent archiving, and so on. 

More importantly, it escapes me how I can take a bunch of power-inefficient legacy arrays, add one big honkin’ storage array / virtualization device, and somehow come out ahead on the power equation.  I hope Hu provides a bit more detail in the future.

Does consolidation drive the need for higher service levels?

One important aspect I felt that went unexamined was the interaction between consolidation and service levels.

As the degree of storage consolidation increases, I see the need for extremely high service levels increase as well.   You’re mixing different applications with different requirements.  You don’t want one application impacting another. 

Going a bit farther, at this degree of consolidation, how important is non-disruptive configuration changes and microcode updates?  How important does customer service become?  Escalation?  Change control?

If you’re thinking about putting a whole lotta of eggs in a very big basket, maybe there should be more focus on who’s carrying the basket …

Other aspects

As I scanned through all the speeds and feeds, even I got a bit dizzy.  And I’ve been in this market for over a decade.

I think both EMC and Hitachi might do a better job of mapping all those Carl Sagan-esque numbers (“billions and billions”) and nice architectural diagrams into practical use cases that tie to what customers might actually want to do.

I felt that a replication and business continuity discussion might have been useful.  A serious portion of our DMX arrays are intertwined with business continuity concerns.

That being said, I applaud Brad for writing an insightful article, and helping a broader audience understand a bit more about this increasingly relevant part of the storage landscape.

A final thought …

In reality, high-end customers have both needs – they need a “no excuses” platform for part of their environment, and – at the same time – they need to address costs, manage easily, non-disruptively migrate, and so forth.

I’d offer that it’s easier for a vendor (e.g EMC) who’s got the service level discussion nailed to address the other discussion (which we are), rather than the other way around.

Comments

[Storagezilla]

[this is good]
"More importantly, it escapes me how I can take a bunch of power-inefficient legacy arrays, add one big honkin’ storage array / virtualization device, and somehow come out ahead on the power equation. I hope Hu provides a bit more detail in the future."

I suspect the ultimate conclusion involves wheeling the older systems out to the loading dock while all their data now sits on the newer USP. ;)

[Richard]

Previous comment;
"More importantly, it escapes me how I can take a bunch of power-inefficient legacy arrays, add one big honkin’ storage array / virtualization device, and somehow come out ahead on the power equation. I hope Hu provides a bit more detail in the future."

I suspect the ultimate conclusion involves wheeling the older systems out to the loading dock while all their data now sits on the newer USP. ;)"

...and the newer USPs are from HDS.... and easily achieved single-point management... in more ways than one.

Virtualization is a great enabler of this....probably its main function.