« Baby (Private) Clouds | Main | Storage Architecture At Enterprise Scale »

February 04, 2009

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451be8f69e20105370e99c7970b

Listed below are links to weblogs that reference Whither Frankenstorage?:

Comments

Taylor Allis

Chuck - while I do think virtualization has merit only when implemented correctly and aligned to business (not vendor) needs - I agree that several vendors do storage "mash-ups" to stay relevant and stay in the game. It goes to the old adage that you can't create simplicity by adding complexity...

kostadis roussos

Chuck,

Takes one (Franken storage systems like Celerra NX4, EMC VTL) to know one I suppose.

I'll agree that this is not as integrated as it can be, but I am astounded with your chutzpah.

cheers
kostadis

Barry Whyte

Don't you sell one too... Invista? Or would you rather forget about that one? Just because EMC didn't make a go if it doesn't mean to say that it doesn't work and provide benefits. An appliance is not the only solution, but yet another pea in the pod of offerings.

Chuck Hollis

Guys, let's face it.

You did a marketing lash-up with a RAM disk vendor rather than attempt any sort of meaningful integration.

If you go to the list of challenges with this sort of approach, they all apply in this case, don't they?

Chuck Hollis

Hi BarryW

You missed the distinction -- we're not positioning Invista with various odds and ends from other vendors as a "complete storage array". That's what NetApp, HDS and IBM are doing with their approaches in the field.

And I think there's a difference.

Alex McDonald

Really, you think there's a difference to what your doing with what we (NetApp) are doing? You're missing the point -- again. I thought I pinged a trackback, but as it didn't make it, here's my take on your take; http://blogs.netapp.com/shadeofblue/2009/02/much-of-the-mai.html

Barry Whyte

True, there's a big distinction - our products in this area are selling, and Invista........

Mike Ault

And to think EMC would never do this...oh wait...what about grabbing someone elses SSD flash notebook drive and wrapping an EMC disk cover around it...no they wouldn't do that would they...and then call it integrated and developed by them...seems to be a bit of the pot and kettle here.

Chuck Hollis

That's a woefully uneducated comment, Mike.

The STEC was purpose-built for enterprise storage usage, in partnership with EMC. It is not a notebook drive.

The process of making EFDs (enterprise flash drives) "just work" as part of a complete storage array was no small feat.

To this day, no other storage vendor can offer you the ability to pop in a few EFDs and make your applications rock. IT sees no difference whatsoever, other than applications are dramatically faster.

Think about this -- if it was so easy, why hasn't anyone else done it yet? It's been over a year ...

-- Chuck

Chuck Hollis

Hi, this is Chuck ...

So, the fanboi crowd is having real fun with this "pot calling kettle black" thing. I'm sorry, that's no substitute for an honest analysis of what's going on here.

Please, reason with me for just a moment ...

Let's say I need some FC storage, and some EFD storage, and some SATA storage, and maybe some SATA storage that spins down.

Which would you prefer?

A single array (DMX or CX or Celerra) that can do all of the above?

Or a collection of various special-purpose arrays from different vendors, glued together by a virtualization appliance?

That's the argument, boys. Have at it.

-- Chuck

Han_Solo

>Or a collection of various special-purpose arrays from different vendors, glued
>together by a virtualization appliance?

Sorry Chuck....as good as EMC has been to me over the years... the answer is YES, YES, YES. If I have anything to do with it, we have purchased our last DMX's.

I had hope for Invista but its long gone.


/Fortune 40 storage architect here.....not a vendor.

Alex McDonald

Chuck, you really don’t get it, do you.

“Let's say I need some FC storage, and some EFD storage, and some SATA storage, and maybe some SATA storage that spins down.”

I sincerely hope I never meet you in a car salesroom. You’d be burbling on about why round headlamps are superior to square ones, and how the bulbs are lovingly designed from hewn blocks of fused quartz and hand spun titanium coated wire by engineers back at base, when what I want is something that lights the way and stops me crashing into trees at night on my journey home.

Customers don’t want FC, EFD, and all the other tin you screw together. They want to run Exchange, take backups, recover mailboxes, reduce costs, deliver a service and so on. They need integrated solutions at the software level.

The world’s not perfect; we’ve not yet cracked the totality of what businesses require. But we’re a lot further along than EMC. You seem happy to claim that you engineer the world’s best headlamp while forgetting about the driver.

NetApp are here to fix customers’ problems with solutions that meet their needs. What are you here for?

Chuck Hollis

Alex, we're all here for the same thing. It's just that some vendors do it far far better than others.

To wit:

Let's take your Exchange example, because it's a good one. And let's solve a few customer problems, shall we?

In larger enterprises (perhaps a market less familiar to NetApp), Exchange 2003 can drive very hot I/O spots, historically requiring the combined I/O bandwidth of many spindles. EFDs handle that part of Exchange very nicely, with better performance and often lower cost than any FC substitute.

Next, the rest of the Exchange datastore that's reasonablly active might go on FC drives. Exchange, as you know, has a "long tail" of infrequently used data that stretches on for quite some time, hence the interest in SATA, and -- of course -- spin-down for the really old archived stuff.

So, that's one way that EMC would solve a customer problem of "how do I get the highest performance and lowest cost from my large enterprise Exchange environment". NetApp couldn't even run a demanding Exchange environment reasonably on their kit.

And that's just for the storage media piece -- EMC could have a backup discussion, an archiving discussion, an e-Discovery discussion, a compliance discussion, a disaster recovery discussion, a security discussion, a migration to Exchange 2007 discussion, a run-your-Exchange under VMware discussion, and a professional services discussions.

How many of these "problem solving" discussions could NetApp have with a customer around our Exchange example?

Few, if any.

Before you try and position yourself as a "customer problem solver" (rather than a #2 storage vendor), you're going to have to beef up your portfolio a bit.

Otherwise, you look like a kid with a hammer, searching for any convenient nail.

-- Chuck

Nigel Poulton

Chuck, I started writing a comment but it got too long so I put some thoughts together over at rupturedmonkey. If you're interested -
http://blogs.rupturedmonkey.com/?p=201

Nigel

Chuck Hollis

Hi Nigel -- yes, I saw your commentary.

I'm not intending to sling mud (well, maybe a little), what I'm trying to point out is that there's yet another architectural distinction emerging in the storage market, and customers have to make choices.

And, of course, I weighed in with my views, as did you!

-- Chuck

Guy

Chuck,

I find this post entertaining. EMC Celerra was the original Frankenstorage device. Take CLARiiON (lower body) bolt the DART blades on top (upper body) and then manage this with a Red Hat based control station (arguably the brain). 3 different operation systems to manage, patch, cluster, debug etc.

Of course the EMC VTL takes this concept even further by bolting VTL and dedupe capabilites from 3rd party vendors on top of CLARiiON.

So I guess the conclusion I draw from your post is Frankenstorage is good, but only if it runs on CLARiiON.

Guy

Chuck Hollis

I understand the distinction might be lost on a few people, so I'll apologize in advance.

Yes, we do assemble various technologies together from our portfolio, integrate them, manage them, and support them. When you've got as many cool technologies as we have, that's inevitable.

But what we don't do is say "hey, call FalconStor for your VTL" and "call TMS for your flash" and "call Copan for your spin-down SATA".

That's the difference I was after.

-- chuck

Barry Whyte

I couldn't help but dig up your past and remind you of your previous FUD around virtualization :

http://www.ibm.com/developerworks/blogs/page/storagevirtualization?entry=how_quickly_we_forget

Chuck Hollis

Hi, this is Chuck

I thought the distinction in how various technologies are assembled would be meaningful to more people. They're certainly meaningful to me.

Obviously, I was wrong.

So, rather than beat a dead horse, I'm going to climb down on this one.

Thanks for all of your comments!

-- Chuck

kostadis roussos

Chuck,

Since you finally, asked a reasonable question, let me give you a reasoned answer.

> When considering the broad range of storage media sevice levels available today (flash, FC, SATA, spin-down, etc.) what's the best way to offer these media choices in an array?

> Is the answer (a) combine smaller arrays from different vendors together behind a virtualization head, or (b) invest the time and effort to build arrays that can directly support all of these media types?


The problem is that you're looking at the hardware deployment only.

The other part of the puzzle is the software stack layered on top of the hardware.

In particular things like snapshots, and replication and clones.

I'll contend that both of our customers would love to buy our software independently of our hardware and replace that NetApp/EMC hardware with cheaper hardware. And so there is a market driver for this kind of virtualized deployment, even if it may not be ideal in our mind.

What's important to note is that the history of computer systems is disaggregation of systems into components with the value going into the software stack. The notion that storage is somehow permanently immune is a problematic thesis.

v-series demonstrates, to an extent, that customers value NetApp software so much that they are willing to buy the components from two different vendors.

I'll also contend that there is value of integration of hardware and software into a single package.

But for a segment of the market splitting the pieces up makes sense.

If it didn't make sense, the v-series would not have been so successful.

And saying that v-series is Frankenstorage or wrong is silly. What's Frankenstorage is selling an integrated system (NX4 or EDL) and saying with a straight face that that is an integrated device

cheers,
kostadis

Chuck Hollis

Hi Kostadis

Grant, for a moment, that all array vendors (NetApp, EMC, et. al.) have similar controller software that does replication, snaps, etc.

Now, from a pure hardware implementation perspective, which is generally better?

A single array that can support combined use of all attractive media types? Or an "array" that uses external virtualization and requires specialized sub-arrays to reach its full potential?

I know you'll never agree with the point (it's against your corporate religion), but -- taken from a pure hardware perspective -- you'd have to torture the facts to arrive at a conclusion that the second scenario is generally better.

-- Chuck

kostadis roussos

Chuck,

The notion that all arrays have similar software is a fantastical stretch of the facts. The fact is that vendors have similar names for technologies that are radically different from each other. And that goes to the core flaw in your argument. The different software stacks have different value propositions, so using a disaggregated model may make a lot of sense.

Assuming the two radically different stacks, your question is: is it better to build an array out of a virtualization layer and storage or combine everything into one box?

It's certainly not my religion to argue that vertically integrated hardware doesn't have value (after all we sell FC and SATA disks in the same device, and if you read our whitepaper, SSD's are in our future). And the volume of vertically integrated hardware vs virtualization layers suggests that most customers value the integration.

But to state unequivocally that the disaggregated system is frankenstorage is problematic.

The value of separation from a customer point of view is the ability to trade off different costs and value. For example, a customer may value the NetApp software but have a large sunk cost in EMC disk. Being able to leverage the software and the cost of the EMC disk (effectively 0) is intriguing.

The counter argument: it's too complex, is the height of vendor arrogance. If you're being virtualized, of course you'll say that because you're losing value. And whether it is or is not is hard for anyone to say unequivocally. Yes you're giving up somethings, but presumably you're also gaining others.

What each customer needs to determine is if the value of the disaggregated model exceeds the costs it introduces.

And I believe that in some cases the answer is yes, and in some cases the answer is no.

But I certainly won't go and call an interesting architectural model Frankenstorage.

So why is the NX4, INMSHO, Frankenstorage? Because it claims that within a single box there is a single set of mechanisms for managing storage, when the facts say otherwise. The storage admin is buying a single box, that from an operational perspective appears as disaggregated storage. So calling it unified drives me nuts.

cheers,
kostadis

Tony Asaro

Consider a storage system that does both - internal and external virtualization - internal and external replication, snaps, etc.

Chuck Hollis

OK, so now we're getting closer.

Hardware efficiencies aside, one could argue that software could hide all evils when integrating together multiple (external) storage types.

While I'll grant that for some forms of basic management and replication it all works, there's a long list of "software features" that usually get forgotten.

For example, is error propogation from the RamSan integrated into OnTap today? Do your performance tools understand what new wrinkles the RamSan brings to the party? Sure, all of that can be done in the fullness of time, but simply assuming that Software Solves All is a bit naive.

One of the more interesting debates in architecture is what belongs in hardware, and what belongs in software. Regardless of how you weigh in on this, you'll have to admit that clean hardware design makes software's job that much easier :-)

-- Chuck

kostadis roussos

> One of the more interesting debates in architecture is what belongs in hardware, and what belongs in software. Regardless of how you weigh in on this, you'll have to admit that clean hardware design makes software's job that much easier :-)

Excellent point, but it begs the question of what do you mean by hardware?

When I hear the term hardware, I think silicon and cables.

So, for example, a DMX, in my mind, has some hardware and some software. Much like a FAS is a hardware platform but has a lot of software. The DMX integrates all of the hardware (silicon and cables) into a single device through the use of software.

So what is the hardware?

kostadis

W. Curtis Preston

Chuck,

First I will answer your question because you claim no one is answering it. You asked "When considering the broad range of storage media sevice levels available today (flash, FC, SATA, spin-down, etc.) what's the best way to offer these media choices in an array?"

My answer: I don't care. I don't care about how you pulled it off. I care about whether the dang thing works and whether it makes my life easier or harder. How reliable is it? How much of my time does it take to administer? How much does it cost to buy and own? How fast is it?

Your question is a restated build-vs-buy question, and my response is the same thing I say to CommVault who says their stuff is better because of their unified architecture and that they built it themselves, vs bad boys like EMC and Symantec that have cobbled together backup & archive software from many companies. Making it yourself (or in your case having it all in one case) doesn't make it better, it only makes it take longer. When it's done, the better product should win, regardless of how it was assembled.

I answered your question, but I can't help but bring up my own favorite piece of Frankenstorage, and that's the EMC 3DL 4000. It's two VTLs from two different vendors (Falconstor on the front and Quantum on the back) plugged into each other with a little bit of glue from EMC to make them look like one. Yes, the customer gets to manage it from a single console, but...

1. The Falconstor piece adds no value that additional storage on the Quantum part of it wouldn't add (the 4200 & 4300 may offer a faster ingest rate, but it will still be gated by the ingest rate of the 3DL/Quantum box on the back end, which is approximately that of the 4100). Sure, you could plug in more 3D/Quantum boxes to the back of a 4200 or 4300, but now it's really starting to look Franken-like -- especially since each 3DL/Quantum box won't know about each other and will be a dedupe silo.

2. The Falconstor piece on the front of the Quantum piece adds less value than simply purchasing a second Quantum-based box. If the Quantum-based 3DL engine can do 4 TB/hr, and a customer needs 8 TB/hr, the EMC answer would be to upgrade from the 4100 to the 4200 or 4300. By doing that, you increase the non-deduped throughput but not the deduped capacity or throughput. If you bought two Quantum-based boxes, you'd double both.

It's GOT to cost more than just buying a deduped box from any vendor that isn't front-ending their box with another vendor's box.

The retort is that it gives customers a big non-deduped storage place in front of the dedupe storage place. You can get the same thing by just putting more disk on the 3DL/Quantum side (for capacity), and/or by buying a second Quantum-based box (for throughput).

The ONLY thing this product brings to the table is fulfilling EMC's promise of bringing dedupe to the EDL 4000 customers that were naive enough to buy it with the promise from EMC that "dedupe is coming." I get that.

But why would you try and sell this monster to someone who doesn't already have a 4000? I'm OK (with some performance concerns on restore) with the 3DL 1500 and the 3DL 3000. Why isn't there just a 4000 that offers the throughput of the Quantum back end of the 3DL 4100 without the Falconstor front-end? Why are you trying to force customers to buy this bolted-together solution?

Again, I don't care how you put a product together. I care how much it costs and how easy it is use (performance, manageability, etc) vs competing solutions and the EMC 3DL 4000 loses out on both counts.

Chuck Hollis

Hi Curtis -- good to hear from you!

Where did you end up after the GlassHouse gig? Are you working for a vendor now?

When I originally posed the question, I was talking about storage arrays, not backup devices. I believe that a modern array should be designed to offer the widest possible selection of storage media types and service levels, and that arrays that were not designed to do this will be at a disadvantage.

Your answer was "I don't care".

I'm good with that, since you're not a large purchaser of storage arrays. If you were a real customer, I'd take the next step and show how arrays that were designed to do this do a better job than those that weren't, and I'd stop there.

And then your train left the tracks, and it turned into a vehement rant about EMC's disk libraries. Why you felt to do this, I don't know.

Rather than take it up here, I'll ask my good friend and EMC blogger Scott Waterhouse at http://thebackupblog.typepad.com -- he does a very good job on these topics, far better than I could do.

I hope that -- wherever you landed -- things are going well for you.

-- Chuck

Scott Waterhouse

Curtis, my perspective on some of these issues:

The Falconstor piece absolutely does add value.

There are some features of the VTL code that are either more mature or more robust on the Falconstor side--a small example: the number of library and tape drive emulations available to the user is much greater than with Quantum.

The 4106 definitely offers a faster ingest rate than the Quantum based dedup engine. But typically backup windows are shorter than a day is long.

Put another way: if you have a 8 hour backup window, you have a 16 hour dedup window. As a business, and as an IT organization, meeting the first window is pretty important from an SLA point of view.

Which is why you want fast ingest. You go on to say: "Sure, you could plug in more 3D/Quantum boxes to the back of a 4200 or 4300, but now it's really starting to look Franken-like -- especially since each 3DL/Quantum box won't know about each other and will be a dedupe silo."

And in fact, that is exactly an option we offer: one dedup engine for every DL Engine. And yes our solution entails one dedup silo for every dedup engine, but then again so does every other solution I am aware of. That is the nature of the beast at the moment; no solution offers a clustered dedup store (failover yes, shared dedup store no) as far as I know. Except Avamar.

So calling out EMC on that score seems a little unjust.

2. You said: "The Falconstor piece on the front of the Quantum piece adds less value than simply purchasing a second Quantum-based box."

Not true.

As I indicated, there are a few things that the 4000 line of VTLs bring to the table that the Quantum based product does not (ACSLS, tape caching, robust emulation, and so on).

Further, when you say: "the EMC answer would be to upgrade from the 4100 to the 4200 or 4300" I am not quite sure where to go with that.

Having been in that situation many times I can assure you that a) we don't have a 4300, it is a 4406; b) that was not often my answer because of the next point; and c) I think our answers are generally more nuanced based on customer requirements.

So without knowing the customer requirements are it is tough to say what to recommend. Do you need to double your throughput? From where? Why? For how long? What backup application (because TSM is pretty different for example).

"The ONLY thing this product brings to the table is fulfilling EMC's promise of bringing dedupe to the EDL 4000 customers that were naive enough to buy it with the promise from EMC that dedupe is coming." You mean all 3000 of them? :) "But why would you try and sell this monster to someone who doesn't already have a 4000?" Because they require fast ingest and fast restore? Because they require robust VTL capability? Because they want policy control over if and when data gets deduplicated? Because they have a backup window and not all day (in the literal, 24 hour sense) to do backup? Because they would prefer a smaller number of virtual tape front ends to a much larger number of deduplication engines?

Finally: "Again, I don't care how you put a product together. I care how much it costs and how easy it is use (performance, manageability, etc) vs competing solutions and the EMC 3DL 4000 loses out on both counts."

Honestly, I couldn't disagree more.

The ease of use on the DL3D 4000 line is unsurpassed. It adds (basically) two screens to the DL Console. The DL Console for our traditional VTL is something our customers are strongly embraced--there are over 5000 of them out there. So, to review: it offers very good performance (much better than almost anything else out there); it offers very good manageability with great flexibility in an easy to use package. It is very price competitive versus any other offering.

So it is faster than almost anything else out there; easier to use; more flexible; and price competitive.

So what was the concern? ;)

The comments to this entry are closed.

Chuck Hollis


  • Chuck Hollis
    Chief Strategist, VMware Storage and Availability Business Unit
    @chuckhollis

    Chuck works for VMware, and is deeply embroiled in all things software-defined storage these days.

    Previously, he was with EMC for 18 years, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Holliston, MA with his wife, three kids and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not buy him a drink when there is a piano nearby.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!