Storage virtualization has been a lively topic of discussion for many years in this industry.
File virtualization is a relative newcomer, but it seems to be finding its way from data sheet to deployment much, much faster than storage virtualization.
And, thankfully, we're not having the bombastic discussions with file virtualization, which is a welcome relief .. ;-)
The Basics
The two are somewhat the same, but subtlely different.
One way of describing storage virtualization is "volume management in the SAN". Imagine multiple arrays, each with logical disk drives, also called LUNs.
Imagine some mechanism to combine and present these as "virtual arrays" -- a bit from this one, a bit from another one -- all nicely presented to a server.
EMC uses an intelligent switch to do this (Invista). Hitachi does this by repurposing their large-scale storage controller (TagmaStore). And IBM does using a server-based appliance (SVC).
You can use storage virtualization to consolidate disparate storage arrays, and gain some efficiency, although once you look at the cost of storage virtualization, you'd be tempted to find cheaper ways to do this.
You can use storage virtualization for storage migrations, especially non-disruptive ones, although you'd go through the same cost/benefit analysis before you laid out for this approach as well.
And there seems to be a small market around recycling disparate storage assets into something that's somewhat useable.
HDS got around the high entry cost by simply making it a feature of their array. IBM did some very aggressive bundling deals to drive initial acceptance. EMC had to offer essentially new SAN infrastructure at the time, so entry costs were prohibitive, but that's changed since then.
Despite various marketing claims, I think it's safe to say that it's been a long, slow road between the first part of this decade when the storage virtualization discussion started, and where we are today.
File virtualization does many of the same things. Imagine lots of filers scattered around the organization. What you'd like is a single abstraction of files that users see, independently from the filer that's providing the storage.
Of course, consolidation is interesting. As are non-disruptive migrations. Or recycling stranded assets into something useful.
So, why did file virtualization enjoy much faster adoption (and associated payback) than storage virtualization?
The Size Of The Problem
Traditional storage environments typically have someone looking after them, especially in larger shops. Yes, sometimes things could get a bit out-of-hand, but -- generally speaking -- there were a few people thinking about the environment, doing a bit of planning, etc.
If the role of storage virtualization is to help clean up a messy environment (consolidate a bit, repurpose assets), the attractiveness of the value proposition in one sense is limited by the size of the mess.
Conversely, in many environments no one was really paying attention to the file system environment. More stuff went in, growth went largely unchecked, and one day IT realized they had a monster on their hands.
The size of the mess was larger, and more widespread. So, one view that I have is that file virtualization is more popular simply because it solves a larger, more widespread problem.
Ease Of Deployment
With storage virtualization, you're basically inserting something into a mission-critical I/O stream, usually a FC-based SAN.
That's dicey stuff. Performance issues. Interoperability issues. Support issues. From an IT deployment perspecitve, it's hairy stuff.
With EMC, you're usually looking at upgraded SAN equipment. With IBM, you're looking at new appliances in the data path. And with HDS, you're looking at a new array.
In comparison, file virtualization is a lot less demanding. As an example, with EMC's RainFinity, it's an appliance that just has to mediate and redirect file access to the right place at the right time. It doesn't have to be big and hairy. File requests over IP tend to be a bit more patient and tolerant than millisecond I/O requests.
There's less stuff, less interop, less effort. It goes in pretty quickly, and starts delivering results almost immediately. It isn't a big IT project. Usually, there's little-to-no disruption to the user environment.
That has to be a factor, at least to me.
Roadmap For Future Functionality
OK, you buy a solution to solve a specific problem, but where does it go from there?
In the case of the storage virtualization crowd, most of the roadmap themes tend to be recreating array functionality that already exists: snaps, clones, remote replication.
From a customer perspective, that's not really "new" functionality -- it's just doing things in a different place using a different mechanism. Nice, but not compelling.
By comparison, EMC's RainFinity seems to be heading down an ILM road. Basic archiving, putting files on cheaper media when needed, integrating with backup and CAS, and so on.
Many organizations don't have a slick file management capability to cap the growth, weed out the junk and preserve the important bits. And when you look at where RainFinity is going, you see a picture of things that you need that you probably don't have today.
That's an important distinction.
So, Why Did I Write This Post?
Simple. Sometimes technology is a cool answer looking for a problem to solve.
Many times, I think the evolution of storage virtualization went along those lines. For a while, it seemed that the vendors were saying "look what we can do" and for a while, the response from customers seemed to be "why?".
Other times, technology is developed in response to a growing customer problem.
Files are clearly where the information growth is these days. In most cases, no one was really paying too close attention, so it kind of became a big problem for a lot of people all at once.
And the new functionality that's starting to come along solves new problems, rather than tries to provide a re-creation of things that are already being done.
And as I look at all the new wares that the industry is churning out, I keep asking myself:
Is this a cool technology looking for a problem? Or is this a problem that now has a good answer?
Hopefully, we'll see EMC doing more of the latter, and less of the former.
[BTW, I'm going to be on the road for the next week or so, so posting will be difficult. Hopefully there will be plenty to write about when I return. Cheers!]
Comments