In-Depth
File System Virtualization: What War?
Good, better, best? There's no answer in sight when it comes to file system virtualization.
The e-mail that filled my inbox recently sounded pretty interesting: “NAS Virtualization Wars Heat Up” or words to that effect. I girded my loins (always wondered what that meant), and decided to travel (telephonically, at least) up to the front lines in Silicon Valley to see what was going on.
Don’t worry. It isn’t much of a war from where I’m sitting.
To tell the truth, it’s not about NAS virtualization at all, but about file storage virtualization. More specifically, it’s about how we will manage and coordinate controlled access to files stored all over a geographically-disbursed enterprise.
The e-mail, as it turned out, was a bit hyperbolic. This war apparently only exists in the minds of a few companies in Northern California: a group of vendors, most of them small, trying to set a de facto standard for resolving a problem that most of us don’t have … yet.
Let’s say you have a lot of files (we are talking in the hundreds of millions) spread out on NFS- and/or CIFS/SMB-mounted volumes located in offices spread over a large corporate campus or across many branch offices. In addition, let’s say that you want to move some storage around to make better use of this infrastructure, but you don’t want your users to endure any disruptions in normal access. You have several options.
For one, you can deploy a new file system that spans all the volumes. That way, moving physical storage around doesn’t really matter. The file system still presents a set of directories to the end user and translates file requests into physical locations of bits on disk.
While this choice might make a certain amount of sense for organizations that are centralizing their storage or otherwise implementing huge and disruptive changes in infrastructure as part of a broader data-management strategy, it is generally not the approach preferred by most companies. Most of us are seeking controlled access without a forklift upgrade—at least not until it has a major brand-name player’s backing (e.g. Microsoft) and becomes part of the file system delivered with an operating system (such as Longhorn).
That leads us to option two: Leverage capabilities in Network File System version 4 (NSFv4) to build a directory service or something that will enable us to treat all storage mounts as nodes in a broader network-based file service. You access directories in a standard way, regardless of where the directories are moved in the physical universe.
Great concept, and IBM has at least two groups working on it at their Almaden Research Center . It is one key element of “distributed storage tank” and, when successful, will remove some of the proprietary features that currently taint Storage Tank itself. Problem is, efforts to exploit NFSv4 are still very much in a primordial state.
A third approach is to “spoof” users and applications about the file storage mounts that are out there. Use an intermediary server or appliance or switch to serve up a picture of the file system and to conceal infrastructure changes in the back end from their view.
NuView currently does this with its StorageX product. You deploy their server, then create from your NFS/CIFS mounts a Global Namespace view to present to your applications and end users. You funnel all file calls through the Namespace server, which will route them to their appropriate targets.
Another approach is taken by Acopia, which makes an “intelligent switch” from a server appliance that imposes a new namespace, file system (questions remain on this one), and even an Hierarchical Storage Management (HSM) scheme over the back-end file storage environment. The company released version 2.0 of its product a short while ago and that’s what touched off the current “war” over file system virtualization.
According to Jack Norris, Rainfinity’s VP of Marketing, Acopia’s press releases are “full of [sound and fury, but signify nothing].” He observes that Acopia’s just-announced version 2.0 isn’t the industry breakthrough they claim, since the major features have been in Rainfinity’s product for over two years. .
What’s more annoying to Norris is the lack of attention “to serious deficits in the Acopia approach” among analysts who cover this space. (Analysts can’t even agree on a name for what Acopia, Rainfinity, NuView, and others are doing. Some call it “NAS Virtualization” while to others it is “Network File Virtualization” or “Network File Management.”) It’s really hard to have a war when nobody knows where to report with their muskets.
One example is data restore, says Norris. “Acopia puts its file system in place with a proprietary namespace. It grows as you add more storage nodes, which they say is a good thing. The problem is new procedures are required to do full or partial restores.”
Rainfinity's solution is an appliance that connects to a port of an existing LAN switch, where it uses the existing namespace to redirect file calls to mount points until all clients can be updated with the new locations of physical mount points that have been changed. Like Acopia, Rainfinity is clawing its way up the functionality food chain to provide new capabilities on its wares. These new features include capacity management, performance optimization, tiered storage management, and storage consolidation, according to Norris. Check out the company Web site at http://www.rainfinity.com for more information.
In the final analysis, all the conflict over “file system virtualization” has many of us rather confused. A file system itself is a form of virtualization. Then there are the implementation issues.
An e-mail forwarded to me by a reader in May copied a chain of correspondence between storage geeks in two large companies considering the relative merits of file-system virtualization solutions from Acopia and Network Appliance (Virtual File Manager, a re-brand of NuView’s StorageX). The first fellow, who was considering the Acopia product, distilled down the pros and cons of the Acopia approach this way:
Pros: Acopia’s CEO is fairly well known in the industry (CEO Chris Lynch is formerly from Cisco Systems by way of its acquisition of ArrowPoint). The company is a Microsoft Gold Partner. They won an award from Leading Lights (same publishing group that publishes Byte and Switch). Cons: Acopia is expensive. The ARX1000 lists for $45,000; the ARX6000 lists for $150,000. You'll need two of them to provide redundancy, so you'll need to double both of these prices. Plus, they have a proprietary file system and their virtualization solution is in-band: it depends on whom you ask, but this can directly impact your network utilization. (Of course, Acopia will cite a report they paid to have done by ESG that states "no impact on network," etc. But, there aren't enough installations to confirm this. Last I heard, they had less than 15 actual customers.)
More Cons: Acopia is used mostly for file migration and then the switch is ripped out and moved to the next location for migration of files. I'm not aware of anyone using it for global namespace purposes. So, you can't leverage the current computer resources one already has—rather you're paying extra for the hardware. You also can't upgrade the hardware as you see fit—rather you'd need to upgrade to a different switch.
The other person in this exchange made some interesting responses. Regarding the “pros,” the response was a simple, “So what?” He added some positives about the Acopia approach that the first writer ignored.
For one, Acopia “virtualizes your NFS/CIFS storage so you can move/manage/upgrade that backend without user downtime or them even noticing. I like to think of it as VxVM for NFS/CIFS. In my case, we're looking at it strictly from an NFS point of view.”
Second, the product enables you to do HSM style management. Files not accessed in a certain amount of time can be migrated transparently between backend storage pools.
Third, Acopia’s product is not trying to pass through the NFS traffic: it's both a server and client and does it's own translation. This is unlike the Rainfinity box, which sat in the middle of the stream and played games with what the clients saw.
Fourth, it offers the simplicity of an appliance. You don't have to set up an OS and then applications and get it all configured to make it run. “It's pretty much plug and play. Just like Network Appliance’s VFM.”
As for the cost issue, the fellow added, “Yup, this is certainly a con. It's gotten better price-wise if you look at how many Acopia volumes they now allow, versus back ends per Acopia volume. But no one has ever said that Network Appliance filers are cheap, but they are good devices.”
There was disagreement over the issue of a proprietary file system between these two knowledgeable end users, with the respondent claiming that Acopia “brings no file system to the table.” This agrees with Acopia’s own press material, which makes no mention of a file system, but flies in the face of the statements of competing vendors, including Rainfinity, and with some public representations of the product made at storage events. There is a lack of clarity about the actual functionality provided in the Acopia product and that seems to be behind much of the present bickering.
The second user acknowledged that the Acopia product operated in-band: “Of course it's in-band, it's virtualizing your backend storage, so it does have an impact. In our case, we'll never see it since we're space constrained, not performance constrained. If absolute raw performance is so darn important, why are you using NFS in the first place?”
On the issue of use as a migration aid, the second fellow added, “So why is this a con? It's more of what the customer is choosing to do with the tool, not with what the tool can do. You need to also say why this is a *bad* thing anyway. And as you say, with only 15 customers so far (maybe more by now), just because some or a lot of them have used it for migration, does that mean that the one(s) who are using it for virtualization (globalnamespace purposes) are doing something extraordinary? Maybe I don't understand your reasoning here, I'd appreciate if you could expand on why you think this is a con of the product as opposed to a misuse by the customer.”
He went on to ask whether NetApp’s VFM software allows the use of another vendor’s back-end storage: “For example, Acopia would let me keep the currently accessed files on the NetApp, but once they aren't used for a while, I could migrate them automatically to cheaper/slower storage. And then I don't need to do backups either of that data, since I know I have backups elsewhere.”
Finally, on the subject of awards, the respondent explained, “I could[n't] care less whether it won an award, but how does it work in the minds of my peers?” This incited the first guy to respond with the most practical observation, “You can actually try VFM before you buy it versus going through a huge 'selection' process to get an Acopia switch in-house to test in your environment. Download is available.”
The second writer conceded this point, “This is a possible advantage, in that you can setup an in-house test without having to bring extra hardware in house. But VFM is not an appliance, which means I now have more work to do setting up the server to host the software. And I have to setup, test, and document all the failover steps for VFM as well So, why am I not buying an appliance which has all this work done for me already?”
This interchange is the sort of thing that should be going on among consumers everywhere. If you are looking for that kind of sensible analysis, we recommend http://www.StorageMgt.org, a free, registration-based community for storage administrators that has just been launched. See you on the Web.
To contribute to this discussion, please write to me at jtoigo@toigopartners.com.