NetApp Gateway and IBM SVC -- When More Isn't Necessarily Better

I try to refrain from poking at other vendors in my work, and in this blog.  But sometimes, just sometimes, you hear about something that's so wacky, it just deserves a moment of appreciation by all of us in the industry.

I refer to the recent announcement that the NetApp gateways were now qualified for use with IBM's SVC.  See here and here.  One way to accurately describe the announcement would be that you now can buy one storage virtualization device (the NetApp gateway) on top of another (IBM's SVC).

I don't think we'll get a replay of the Sony PS3 situation with long lines at retailers near you.  So why did they do this?

A bit more detail

NetApp's gateways are virtualization devices.  Plug some storage in the back, and you're free to present it as either files or blocks, depending on your need. 

IBM's SVC (storage virtual controller?) is a virtualization device.  Plug some storage in the back, and you can present it as blocks -- virtualized, of course.

So why would anyone need both at the same time?

It gets even weirder ...

Both devices are very similar architecturally -- both are x86-ish dual-controller designs, both have roughly the same performance envelope.  They're not twins, but you can see the family resemblance.

Both devices have the standard storage virtualization management issue: e.g. instead of having just storage and servers to deal with, you now have a new layer that has to be managed as well. 

If you think about it for a second, you've now added a fourth layer of devices to manage: the servers, the NetApp gateway, the IBM SVC, as well as any native management on the actual storage device.  My head hurts just thinking about it.

Both have the standard "bump in the wire" performance issue at scale.  Since they're appliances, they have to terminate every I/O that comes to them, process each, turn around and reinitiate the I/O back to the SAN. 

[If you ever want to make one of these vendors uncomfortable, ask for a "before" and "after" performance characterization -- here's the performance before we put the bump in the wire, here's the performance after we added the bump.  Hint: the numbers will not be the same ...] 

Trust me, a SAN doesn't run any faster with an appliance-based bump in the wire, and it certainly won't run any faster with two of them.

Not only that, this approach is expensive, not only for customers, but for IBM and perhaps NetApp. 

Qualification of any SAN device that sits in a network -- appliance or otherwise -- is expensive and difficult.  We know, we do a bunch of that work.  Virtualization devices can be even harder to qualify.  And here we've got one virtualization device sitting on top of another -- somewhere, there was an engineering team that had to put an exceptional level of effort into qualifying this combination -- and that ain't cheap.

Not only that, providing enterprise-class customer support for this combination is going to require some special investments in skills, processes and not to mention a lab or two that has all this stuff running in it.

I don't think it's going to be cheap for customers either.  These appliances aren't necessarily bargains, and using two of them together makes things very expensive indeed.

So, why did they do this?

Maybe it was done for optics.  IBM has agreed to resell NTAP products, and it just wouldn't do to have a NetApp gateway not be qualified with IBM's "flagship" SVC.  OK, now you can tell a complete story, folks, but I think it'll be difficult to explain this bit to customers (or anyone else with a bit of background in this business)

Maybe it was done defensively.  Maybe smart IBM customers figured out that if they bought a NetApp filer, they really didn't need an SVC.  Don't think this one will play out, though.

Maybe it was done to attack EMC's base.  Between DMX and CLARiiON, EMC has most of the storage footprint out there, and one way to attack it is to try and virtualize it.  NetApp could never find a way to pay for the investment to qualify and support their gateways on EMC storage -- it's an expensive proposition.  To this day, NetApp doesn't support their gateways on EMC products.

IBM bit the bullet a while back and invested in qualifying SVC with EMC storage products.  It had to cost them a boatload to do this.  Hasn't exactly been a popular proposition in the marketplace, so I don't know whether they consider this a good investment or not.

Could be that a few marketing geniuses said "hey, we'll use the work we've done with SVC to sell NetApp gateways to the EMC base".  Yes, they can now say that, but I for one don't want to be the marketing guy who has to present this "solution" to a customer.

One thing is very clear to me.  It wasn't done with customers in mind.  And I've learned the hard way over my career is that every proposition has to answer the same hard question: how will this benefit customers in a new or unique way? 

And, despite my entrenched biases given that I work at EMC, I just don't get it.

Comments

[StorageGuy]

Ever think that some enterprises are standardizing on SVC (to virtualize their estate of HDS, IBM, and EMC kit) and want IP protocols (CIFS & NFS, as well as iSCSI) on the frontend?

Using FC protocol on the NetApp in front of an SVC would be weird, but for the IP stuff it sounds like a natural fit to me.

[Chuck Hollis]

I understand the need -- want to virtualize the entire estate, want choices on the front end to use IP protocols -- no argument there!

But layering one virtualization device on top of another virtualization device just seems like it would be unbearably painful in terms of performance, management and support.

And it's tough. NetApp has all the IP protocols, but hasn't done nearly as good a job as IBM in terms of qual, support and management tools. EMC would sell you two different devices (Celerra for IP, Invista for FC) but would not try and stack one on top of another -- at least, I hope so.

Thanks for reading the blog, and leaving a comment. In the future, please leave a real email address so I can respond with additional detail and color.

Thanks again ..

[c2olen]

Hello there Mr. Hollis.

Take this note from an end-user (customer). We are using SVC (its an acronim for SAN Volume Controller) to our satisfaction. Indeed, it introduces an extra level of management into the server-to-storage path, but in our case.
What we do experience though, is that we only have to cope with the server-to-SVC qualifications, as the backend is handled by IBM. This clears us from the always annoying fact that most host-based multi-pathing software just doesn't like to share the host with other vendor's multipathing software. SDD is free of charge, opposed to other vendors charging per host.

To get back on the virtualization stacking, my gut feeling is that IBM's just filling their NAS gap, untill they can fill it up themselves. Maybe in the SVC itself, or by some other means.

They could just be trying things out, to see reponses and see how it incorperates.

In our shop, we would most certainly not opt for the virtualization stacking.

[Chuck Hollis]

Glad that SVC is working out in your shop. It introduces a few new wrinkles in the landscape, but there's enough known about the environment now that people can make an intelligent choice.

Since I wrote this post, it's become a bit clearer what the logic might have been. IBM has a need to go into a heterogenous storage shop and sell NAS. One way (maybe not the best way) is to have SVC handle the heterogeous storage attach, and the NetApp filer handle the NAS.

But, as you point out, I see this as stacking virtualization, definitely something that should be approached with extreme trepidation.

Thanks for the comment!

[SANgineer]

How do you feel about a "bump-in-the-wire" appliance now? Is it OK now that EMC is doing the same thing?

[Chuck Hollis]

Hi -- actually, it's not the same thing, if you think about it.

First, the Celerra VG8 gateway is fully integrated with the underlying EMC storage platforms: functionality, performance tuning, manageability, etc.

That's not the case for a generic NAS head in front of generic storage.

Second, it appears that the newer Intel processors are now fast enough to do serious metadata processing without getting in the way, in effect doing a form of off-loading.

Sure, it's easy to throw names and labels around ... but in this case, I'm pretty convinced there's something more here.

-- Chuck

[NCDA_Certified]

NetApp aggressive vSeries vFiler can monitor any disks failure and point the finger and tell what physical disk failed via NetApp Operations Manager and NetApp SANscreen.

NetApp SANScreen
http://www.netapp.com/us/products/management-software/sanscreen/sanscreen.html?REF_SOURCE=ntpggl8700000015133s

Operations Manager
http://partners.netapp.com/go/techontap/guided-tour/slideshow1.html

skynet: http://netappsky.com