Do we really need parallel NFS?

Did some pNFS proponent slip a love potion into the coffee at EMC? Suddenly it’s pNFS time at the company known for its reluctance to embrace file sharing and filesystems in general. The purple prose is flying, with Chad Sakac declaring himself “a big fan of the application of NFS” and Chuck Hollis extolling the “inherent simplicity and ease-of-management of NFS.” The NetApp guys must be amused by the bear hug from Hopkinton, but many are seeing deja-vu all over again.

Chad’s Icky Bits

(Apologies for that heading, but those are Chad’s words, not mine)

Chad Sakac’s red rose for pNFS included a few thorns aimed at good old NFSv3. He calls these the “icky bits” and spills some ink over them:

1. “NFS Server failure behavior,” says Chad, leads to issues as serious as “a guest OS crash” and administrators “resorting to unnatural acts” to compensate. He talks about EMC’s DART OS being optimized to fail over in under a minute to avoid application issues and the difficulty in actually accomplishing this feat.
2. Chad also points out that “NFS client limitations” can lead to “unexpected bottlenecks.” Load balancing large workloads across multiple gigabit Ethernet NICs means hand-tuning, since NFS pins traffic to a single MAC address.

Certainly these limitations were known to many in the storage industry, but haven’t they also been addressed repeatedly? NetApp, EMC, and BlueArc do indeed suggest adjusting NFS heartbeat values to allow time for the cluster to recover, but this seems more a limitation of their clustered server architecture than of NFS itself. Scale-out NFS servers from Isilon and HP don’t seem to require these “unnatural acts.”

As for client limitations, manually balancing client loads is a reality in many large storage architectures, not just NFS. Perhaps the fact that NFS can handle so many more I/O requests in a given timeslice makes this more of an issue, but it tends to be transient.

Chad has repeatedly expressed his love for NFS, especially as a datastore for VMware. Clearly, he intended to point out these “icky bits” to highlight the possibilities for pNFS. But the method used (calling them “icky” for one) resembles mud slinging.

Chuck Wants pNFS

(Chuck’s titles also lend themselves to mis-reading)

Chuck Hollis is more careful in his wording, extolling the virtues of pNFS without calling anything “icky”. Indeed, there’s just one NetApp dig: He says their “emulated containers of LUNs” are “hardly optimized”, which is a welcome change of tone from previous debates.

But the underlying message is the same: pNFS is new and wonderful, encouraging proliferation of hand-holding, flower distribution, and rainbows. Again I ask, is this really true? Is pNFS ready for this kind of adulation when, as Chuck points out, “it’s going to take a while before the rest of the portfolio, industry and ecosystem catches up.  Maybe a year or so.”

Seriously? A year until pNFS is ready for mass enterprise adoption? Admittedly, EMC has been working on pNFS (as MPFS) for a long time, but predictions of “just another year” for a major protocol transition set off warning bells. This is doubly true when most clients (including VMware) don’t yet offer even basic support.

Stephen’s Stance

One wonders if airing this dirty laundry is an attempt to highlight EMC’s pNFS work or to discredit plain old NFS as a datacenter protocol. As I wrote about in Our New Thing Is Awesome (‘Cause Our Old Thing Sucked), the “parade of progress” sometimes degenerates into “out with the old,” and this is perilous for purveyors of durable goods like storage systems.

I am also very concerned with the proliferation of “layout types” within pNFS. It seems that every vendor has a hand in the protocol, and each is adding their own technology to the mix. We started with files and now have both objects and blocks. Will these be widely supported? Do we really need them? Or will pNFS start looking like Bluetooth: Bloated, incompletely-implemented, and ignored except for special use cases.

But my motivation behind this post is simpler than that. I would like to pose a question: Is NFS (v3) really that “icky”? Do we really need pNFS? Or have these problems been solved previously?

© sfoskett for Stephen Foskett, Pack Rat, 2010. | Is NFS v3 Really That Bad?
This post was categorized as Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Are you a vendor blogger or an independent? Can you straddle the line and be both?

Why Do Vendor Bloggers Matter?

I suppose it’s best to get some definitions out of the way at the outset. Blogging and social media is a diverse and ill-defined region of the Internet, a world which itself in its infancy. What I write here is focused on my particular corner of the online world: Enterprise IT infrastructure, and enterprise storage in particular. I am sure that other areas, both inside and outside of IT infrastructure, have different norms and values.

In fact, this particular focus on who is a vendor and who is not will seem peculiar to many. Some areas are dominated by insiders blogging for their employer, other companies are entirely absent from the blogging sphere (Exhibit A: Apple), and still others don’t make much of a fuss over who someone works for. Yet concern about payola and bias runs deep even in the most liberal circles.

Can You Trust It?

It boils down to a simple question: How much can you trust what you read? Blogging and other social media activities (Twitter, conferences, forums, etc) have come to dominate discourse and drive search engine ranking. An outspoken social media maven can drive mind-space and thought leadership using these tools. Yet the democratic Internet is open to any and all.

This kind of influence can be very subtle. A connected employee can be expected to be part of the larger conversation about a product, service, or technology. Once also expects them to influence this discussion, and this will always be biased based on their experience and background within the company. Where outside critics see a profit-motivated monolith, an employee sees an all-too-human company trying its best to succeed. And since that success feeds their children, it’s hard to expect them to be too critical.

Certainly some content is inherently trustworthy, especially in technical areas like IT. I love Chad Sakac’s posts on EMC/VMware integration, for example. I also look forward to reading what the VMware and Microsoft employee bloggers write, since they’re so detailed and factual. And finding this kind of content of a personal blog, even without disclosure, wouldn’t raise my hackles. But even the most technical blogs sometimes get into “mine is better than yours” arguments between vendors.

The world of strategy and opinion is much less black and white. Consider just about anything on Chuck Hollis’ blog. He writes at EMC.com and his content is always on point for that company. But many others (from many companies) write similarly corporate-focused pieces with much less disclosure. This is an old PR trick, and the Internet makes it easier than ever both to get published and to disguise affiliation.

But even with the best of intentions, we are all biased in one way or another. Our experience, our employer, our friends, and indeed the entire world we live in influence our experience. It is not a simple thing to be independent of this, and we should expect everyone to be impacted to one extent or another. The trick is to detect overt bias and manipulation.

Throwing Stones

I’m not trying to throw stones here. In fact, I write a vendor blog myself for my employer, Nirvanix. I am very used to wearing multiple hats, and I pride myself on my ability to step into and out of the corporate shadow. But it’s a very difficult game to play, and I’ve failed on occasion.

Rather, I’m hoping that this series of articles will spark some discussion on the whole concept of vendor blogs. I’ll be posting about the spectrum of options that corporate bloggers have, non-blogging soapboxes they use, and best practices to keep everything straight.

If you enjoyed reading this, you’ll probably also like my Foskett Services blog!

© sfoskett for Stephen Foskett, Pack Rat, 2010. | Vendor Bloggers 1: Why Does It Matter?
This post was categorized as Enterprise storage, Personal, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Driving Massive I/O

Chuck Hollis treated us to a discussion of vSphere as an I/O Engine on his blog this morning with some background on multipath IO (MPIO for short), but I’m not sure he did the topic justice. In my opinion, server virtualization is the greatest I/O driver ever brought into the data center, and it messes with all of our preconceived notions about I/O at the same time.

What’s so special about server virtualization?

1. Hypervisors concentrate I/O, shifting loads that were formerly distributed to a large number of I/O channels into a far fewer channels. Picture 10 servers doing what they do. Now put all 10 in a single physical box. All of their storage access must now share a bus, a host adapter, a cable, and perhaps a LUN on the storage system. It’s the difference between lemonade and lemon juice!
2. Hypervisors randomize I/O, chunking everything up and mixing it together. Forget about the carefully-designed read-ahead algorithms and caching used in enterprise storage – VMware, Hyper-V and the rest throw those expectations out the window! Virtualization is a blender – it grinds up your lemons, skin, seeds, and all!
3. Hypervisors demand low I/O latency, forcing infrastructure to get quicker, not just faster. This is one reason that caching, solid state disks, and 10 GbE are going to be huge in virtual environments – all reduce latency by orders of magnitude! As any car guy will tell you, quick and fast are two very different things!

The upshot of all of this is that virtual servers are very very hard to satisfy when it comes to I/O. And the “back end” has always been a bit of a bottleneck for virtualization software. Now we have VMware claiming that vSphere 4 can push over 300,000 I/O operations per second (IOPS) without resorting to VMDirectPath and similar “cheater” measures. Of course not all IOPS are equal, and I doubt that that 300k number would hold up with a real-world workload, but it’s impressive nonetheless!

A Brief History of MPIO

Let’s turn back to multipath I/O. PowerPath/VE is just the latest in a long line of path managers, not all of which have been well-loved. Back in my HP-UX days I learned to make the most of PVlinks, the native path management on that operating system. It wasn’t always easy to get it to work well, but it sure was nice to have a path manager built into the operating system! Veritas also offered a multi-platform path manager, DMP, which worked with a variety of array types. Back in the day, both were limited to simple failover and lacked the “intelligence” to deal with the peculiarities of the weird storage arrays we learned to not hate.

Array-specific path managers from storage vendors were much more successful. CLARiiONs used ATF, Hitachi arrays used HDLM, IBM had SDD, and of course EMC had PowerPath. EMC introduced PowerPath in 1997, the software reportedly having been developed by Conley Corporation, which EMC acquired the next year and turned into its Cambridge (MA) development center. After acquiring Data General, EMC adapted PowerPath to support CLARiiON, pushing ATF off stage right. Then they kept right on developing the software, adding support for IBM, HDS, and HP arrays and data migration.

Meanwhile, Microsoft decided that HP and Veritas were on to something when they developed standard path management software, so they began working on a standard multi-path IO (MPIO) driver for Windows. But Microsoft learned a thing or two from the mediocre device support in those old solutions, so they decided to allow vendors to plug their own smarts into the standard Windows Server 2000/2003 MPIO framework. Microsoft provided basic failover capability and third parties, including EMC, wrote their own device-specific modules (DSMs). This MPIO support evolved and spread, standard on Microsoft’s iSCSI initiator and Hyper-V virtualization platform. PowerPath 5.2.1 for Windows already supported Hyper-V thanks to this.

PowerPath and VMware PSA

VMware also learned a thing or two from HP and Microsoft. Although basic path failover support has been included in ESX for years, vSphere 4 takes it to a new level with pluggable storage architecture (PSA). Every version of ESX 4 includes native multipathing (NMP), but Enterprise Plus licensees can use vendor-supplied plugins to enable more advanced path management. As I noted on Tuesday, there are two three different levels of path selection: Basic path-selection plugins (PSPs), more advanced storage array type plugins (SATPs), and complete multi-path plugins (MPPs).

This is what EMC has introduced: An MPP for vSphere 4 called PowerPath/VE. Like the DSM for Windows MPIO, PowerPath/VE for vSphere slots right into an existing MPIO framework and enables advanced path selection and load balancing without mucking with the internals of the hypervisor. PowerPath/VE has all sorts of smarts in it. It has eight different predictive load balancing policies, proactive disconnect, bus testing, and HBA monitoring.

Super VMware guy Chad Sakac described PowerPath/VE as part of the launch. He notes that EMC is first out of the gate with a multipathing plugin for vSphere, but I suspect that just about every vendor will release similar functionality pretty quickly. In particular I expect support to come from NetApp and 3PAR, since they’re so interested in VMware support.

Licensing Questions

One thing really stuck out in the vSphere launch: PSA is only included in the top-of-the-line Enterprise Plus license. Presumably, this means that, in addition to paying for a PowerPath/VE license, users will have to spring for maximum ESX, too. This is a dumb move, if you ask me. Microsoft made MPIO successful by giving it away with every copy of Windows. They even included it in the free iSCSI initiator download. VMware, in contrast, seems to be actively limiting PSA’s usefulness to the top tier of users. If it was up to me, I would set the VMware MPIO free!

I’m working with EMC and VMware to determine the extent of the NMP/PSA/PowerPath licensing mess. I’ll update this post as I find out the answers!

1. Does every edition of ESX 4 include the basic VMware native multipathing (NMP)?
2. Can one use a vendor-supplied PSA plugin like PowerPath/VE without an enterprise plus license?
3. Does it matter (to licensing) if the plugin is a PSP or an SATP?
4. If “no” to 2 or 3, can PSA be added separately without the plus license if someone wants to use something like PowerPath/VE?

Update: I received a nice email from an EMC engineer correcting me about the plugin types. This kind of open communication is why the web is so great! It turns out that PowerPath/VE is a sort of super plugin called an MPP, not “just” an SATP or PSP. I’ve updated the section above!

© sfoskett for Stephen Foskett, Pack Rat, 2009. | PowerPath To The Virtual People
This post was categorized as Computer History, Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

This news is so fresh you would leave footprints if you step in it, but here’s a collection of my favorite links and coverage so far. I’ll be updating this list throughout the next few days:

• Let’s start with independents:
  • My first post on the topic can be found over at Gestalt IT: EMC Symmetrix V-Max Is Neither Monolithic Nor Midrange
  • Chris Evans was first but promises more than Enterprise Computing: EMC Announced Next Generation V-Max Architecture
  • Storagebod supposes that there will be No DMX5
  • Duncan Epping is watching from a server virtualization perspective: EMC announced the Symmetrix V-Max!
  • Jerome Wendt: EMC Symmetrix V-Max – It’s About Time
• And the press:
  • Beth Pariseau is always smart, as her SearchStorage piece shows: EMC clusters Symmetrix high-end disk arrays
  • And Beth on StorageSoup: EMC launches Symmetrix V-Max, may add spin-down
  • Chris Mellor is dead on in his piece for The Register, Symmetrix and the death of monolithic arrays
  • Lucas Mearian of Computerworld focused his piece on the private cloud: EMC introduces x86-based Symmetrix array for cloud storage
  • Dave Raffo at StorageSoup: EMC V-Max: V stands for bigger
  • Paul Travis at Byte and Switch: EMC Clusters New Storage Systems for Virtual Data Centers
  • And Dave Simpson brings up the rear on his personal blog, but still no word from InfoStor: EMC V-Max: Locked (in) and loaded
• EMC’s bloggers are first out of the gate:
  • Barry Burke has typically prolific and detailed coverage: 
  • • 1.055: symmetrix v-max – a revolutionary evolution
    • 1.056: inside the virtual matrix architecture (my favorite)
    • 1.057: symmetrix v-max – scale up, scale out, scale away!
    • 1.058: v-max does what hi-star can’t?
    • 1.059: fully automated storage tiering (fast)
  • Chuck Hollis’ Symmetrix V-Max: Storage Architecture Redefined is a solid overview
  • Chad Sakac is always good, and his EMC’s VMware Storage Strategy – The 3rd Shoe Drops is a must-read on V-Max, though I’m still left wondering about EMC’s VMware strategy!
  • Mark Twomey’s there with three posts and counting:
    • V-Max: The Scale Out Symmetrix
    • VMax: Auto-provisioning Groups
    • V-Max: SRDF Evolves
  • Dick Sullivan promises You Ain’t Seen Nothing Yet
  • Steve Todd:
    • V-Max Quality
    • Managing V-Max at Scale
  • Len Devanna comments on the Social Launch
• The opposition is moving fast, too!
  • Marc Farley preempted the announcement with a hilarious must-watch video, EMC insider interview is a fake, and an expose on What’s a tigon anyway?
  • Val Bercovici from NetApp observes that the world might have moved past the need for a Symmetrix, noting “Frames are so 90’s”
  • Hu Yoshida focuses on what the V-Max is not: A storage virtualization platform. Don’t Confuse Symmetrix V-Max with Storage Virtualization
  • Claus Mikkelsen of HDS was also predictably underwhelmed, asking why EMC introduced this roadmap now? EMC – Catching Up With the Past
  • Tony Asaro blogs for HDS about 10 Questions on V-Max

That’s the news that’s fit to print so far! Stick with this post and Gestalt IT’s continuing coverage of the V-Max!

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Tracking EMC’s Symmetrix V-Max Launch
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Frankenweenie saves young Victor in Tim Burton's macabre short film

When is a solution integrated and when is it a Frankenstein-like mashup of tangled tech? Apparently, that line is crossed when it’s your competitor’s offering…

In my time in the storage industry, I’ve seen enough franken-storage come and go to make me skeptical whenever a new “integrated” solution is announced. But a lot of this stuff works just fine, so I also know that integrated solutions aren’t always bad!

The latest industry blog flame war centers around NetApp’s recently-announced solid state storage solution, which pairs a V-Series NAS head and a Texas Memory Systems RamSan-500 flash storage system. Perhaps NetApp’s Val Bercovici did get a bit over-excited in his post on the topic, but he wasn’t just talking about the RamSan: He was laying out how NetApp’s WAFL technology can work in an SSD world, and using some recent performance test numbers on that solution as well as their PAM cache cards as an illustration of this.

The next thing you know, we have EMC’s Storagezilla and IBM’s Barry Whyte calling the company out for what they (and others. like Storagebod) see as an underwhelming product offering. That’s all well and good, and I’ll let the reader decide if NetApp’s moves warranted a press release, but now things have gotten uglier…

EMC’s Chuck Hollis called the whole RamSan idea to account, saying it was “Frankenstorage“, causing NetApp’s Alex MacDonald to engage in a little “I know you are but what am I” in reference to EMC’s CLARiiON/Celerra “unified storage” solutions.

It’s time to bring some sanity to this whole integrated solution concept. Every product in the storage world is an amalgamation of OEM parts to one extent or another, and there are always integration issues. Certainly many of EMC’s offerings could be the subject of name-calling: They use STEC SSD drives in the DMX, they use Quantum deduplication engines in their CDLs, and their Celerra NS platform does include a complete Fibre Channel SAN behind the curtain. But they’re not alone, and not even wrong in doing this: Every vendor relies on OEMs, and as a wise man said, “working with an OEM gives you the flexibility to pick best of breed technologies” and that’s exactly what customers want. Any objective person would welcome qualification and integration of TMS’ RamSan with a solid platform like the NetApp V-Series – it’s a certifiable win for the customer. Just like they would be happy to see EMC leveraging great technology from Quantum and STEC.

Chuck goes on to point out some downsides to these OEM combinations, and they’re certainly fair criticisms:

• When you’re buying this from this guy and that from that guy, it’s bound to cost more because everyone needs their cut.
• Since all attempts at unified heterogeneous device management have failed, a combo is certainly harder to manage than a single device.
• With multiple vendors in the mix, fingerpointing is common once support is needed.

But these criticisms can be mitigated by the vendors themselves. They can give up some margin in order to gain market share. They can create unified management interfaces for the combinations they sell and support. And they can really support what they sell, refusing to give in to the temptation to say “not my problem” when the going gets rough. And companies deal with these problems all the time! Frankenstorage doesn’t have to be so scary…

This post can also be found on Gestalt IT: The Difference Between “Integration” and “Frankenstein”

© sfoskett for Stephen Foskett, Pack Rat, 2009. | The Difference Between “Integration” and “Frankenstein”
This post was categorized as Enterprise storage, Gestalt IT. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

What was he getting at? Read the comments in Chuck’s post and you’ll understand his implication: Chuck suggests that NetApp “emulates” Fibre Channel in their FAS/OnTap devices on top of the WAFL “file system”, while EMC’s AX storage (behind the NX4) uses “real” Fibre Channel, so it’s better. He goes on to say that EMC is doing a brisk business replacing misfit NetApp FC arrays with real FC kit from EMC. But, as is so often the case, the truth is a little more complex than this: All enterprise storage arrays “emulate” Fibre Channel drives to one extent or another, and using the wrong tool for the job will always lead to trouble.

Is It Real Or Is It Virtual?

Let’s knock one thing out right away: Chuck is right, NetApp is emulating Fibre Channel drives with their FAS arrays. They really do lay out chunks of storage on something kind of like a file system with a bunch of logic mixed in and then pretend that this space is a plain-jane SCSI drive connected over Fibre Channel. And I’ll add to the “scandal” by pointing out that NetApp does exactly the same thing with their iSCSI drives!

Now let’s move on to an even more important point: All modern storage arrays emulate SCSI drives! That’s right, every enterprise storage array is lying, pretending to serve up basic drives but really slicing and dicing them in the background for their own nefarious purposes!

Who is responsible for this deceit? I place the blame on a few: Patterson, Gibson, and Katz started the game with their so-called RAID concept, which kicked things off by allowing a few drives to pretend to be a single one. Data General implemented this with cache in their oh-so-clever HADA, further separating us from The True Disk. But the worst was EMC, with their fully-virtualized Symmetrix array, where there was no definite relationship at all between the LUNs presented to servers and the disks that do all the real work. Some folks would even go so far as to praise this type of post-RAID virtualized storage as innovative!

NetApp takes this “automated lying” to the extreme, forcing their innocent hardware to take honest, well-laid-out blocks of intelligent WAFL space and twist them into vast tracts of dumb pretend-disks. The nerve! Compellent, 3PAR, Dell/EqualLogic, and the rest are just as bad, scattering blocks of data willy-nilly across their disks in so-called “wide stripes“. But don’t let Chuck’s misdirection fool you: EMC is just as guilty with each of their different storage platforms, masquerading as disk drives or file servers and intelligently managing storage underneath! And don’t get me started on the twisted things VMware does to storage!

Modern? Feh! Let’s all hope Apple starts producing their no-feature Xserve RAID again!

Waiting On Angels

So every modern array emulates disks. What was Chuck’s point again? Oh yeah, that the AX Fibre Channel storage used by EMC’s NX4 is superior to the integrated Fibre Channel capability of the NetApp FAS2020! I’m sure he’s right for some use cases and wrong for others. FC on the FAS2020 is a perfect match for some, and the NX4/AX wins in a landslide in some circumstances.

The crux of the argument is the fact that NetApp does all sorts of stuff behind the scenes build and support an FC LUN that the EMC AX FC array doesn’t do. So, although it wouldn’t be fair to say that one was “emulated” and another was not, Chuck would be correct in saying that an FC LUN on an AX is more “real” than one on a NetApp FAS. But arguing over technicalities like this is all angels and pins and doesn’t matter in the real world!

What does matter? In block storage, latency is king. Generally speaking, more cogs and wheels leads to more latency. This is why storage arrays rely so much on large, intelligent caches and vendors are experimenting with all sorts of cool caching technology. But, ignoring cache, high-end arrays generally have worse latency than low-end ones because they have all sorts of translation and virtualization going on in the background. In any I/O situation, increased latency hurts throughput and the perception of performance. And there comes a point when block applications give up waiting and it’s “game over, man!”

I remember migrating from an old CLARiiON 3100 to a brand new Symmetrix 3930 and watching the Symmetrix choke on the incoming data stream. It just couldn’t write fast enough to handle full streaming reads from the (old-tech) CLARiiON. But once everything was migrated and running, the Symmetrix, with its massive (for the time) 16 GB of cache, widely-spaced data layout, and multiple internal channels, completely destroyed the CLARiiON in real-world performance. This pattern continues today, with devices like the DMX and USP offering much better real-world performance than benchmarks or theoretical techno-arguments would suggest.

So Which Is Better?

But Chuck and the rest were not talking about high-end stuff here. They are comparing the architecture of entry-level enterprise kit and drawing conclusions about which is best. I personally don’t care what the internals of the system look like. I care how well it works.

I have personally seen Microsoft Exchange running on low-end FC-connected NetApp FAS arrays, and it worked great. I also helped a customer migrate off of EMC AX that didn’t give them the performance they needed for their databases. In truth, lower-end gear is often over-sold and unable to deliver the performance, features, and reliability specified on data sheets and in vendor presentations.

That’s right, there’s more to this picture than raw performance. Consider manageability, for one. NetApp is offering a single-interface integrated system with all protocols (CIFS, NFS, iSCSI, and FC) available from one device. They also offer similar levels of integration for their (really nice) snapshot, replication, and deduplication technology. WAFL is busy doing a lot of great stuff, so I really wouldn’t be surprised if EMC’s less-integrated NX/AX offering beats them on performance at the same price point. Which is more important to you, integration, performance, or features? And I bet that, if you spent a bit more on a higher-end NetApp box, you could have it all.

On the flip side, EMC is offering a really compelling entry-enterprise combination at a nice price point. The latest NX should be on everyone’s NAS short list, and I’m sure the simple FC of the AX array would work well in a smallish Exchange, VMware, or SQL Server environment. It’s not as unified as NetApp’s offering management- or feature-wise, but it’s still pretty good.

Pick the right tool for the job, though. Neither the NX4 nor the FAS2020 is a good fit for a high-I/O application, and that’s a fact!

This post can also be found on Gestalt IT: Of Emulated Fibre Channel, Virtualization, And The Right Tool For The Job

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Of Emulated Fibre Channel, Virtualization, And The Right Tool For The Job
This post was categorized as Computer History, Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Great! But I thought the new era for IT was a cloud with choice, mobility, and application support, as trumpeted by EMC’s VMware subsidiary! Wasn’t Cloud vServices from VDC-OS supposed to be the prototype cloud strategy for the datacenter?

What we have here is a simple clash of marketing amusingly taking place at (nearly) the same company. VMware figured out how to extend their server virtualization products outside the confines of the data center, and laid that technology out as a strategy with the trendy “cloud” name. Meanwhile, mother EMC is working on next-generation content storage software and decides to roll that out as a strategy and also jumps on the “cloud” meme. What’s an IT manager to do?

Defining Atmos

As predicted, EMC’s Atmos (code-name Maui) is a distributed software layer to handle the storage and management of data objects across geographically-dispersed storage devices. EMC’s Chuck Hollis demonstrates Atmos with a simple, practical example, perhaps making it sound too much like Akamai but generally getting the point across. You have a data object, write it to Atmos through REST/SOAP or CIFS/NFS, assign some metadata, and the software takes care of data placement for you. It’ll add local copies, replicate for availability and performance, compress or deduplicate, manage versions, and all sorts of goodies (if you ask it to).

But EMC already has a capable object storage platform, the Centera. We’ve just got used to the content-addressable storage (CAS) label for object storage (even though this name misses the point of object storage, in my opinion) and now EMC wants us to learn a new label for a somewhat-similar device? Steve Todd, EMC’s object guy extraordinaire, lays it out:

SAN Value = Centralized, secure multi-tenancy for blocks.

NAS Value = Centralized, secure multi-tenancy for files.

CAS Value = Centralized, secure multi-tenancy for objects (content + metadata).

COS Value = Globalized, secure multi-tenancy for content with rich policies.

Ok, so the defining capabilities of Atmos are its global scale and rich policies. And the fact that “objects” has become “content”, presumably since Atmos can handle traditional NAS (CIFS/NFS) chores as well.

Prayers Answered?

It sounds like EMC is answering my prayers for a storage revolution, delivering a highly-capable object storage platform that transcends the old limits of blocks, directories, and files. Steve Todd points out that Atmos handles five policy categories out of the box:

• Replication
• Compression
• Spin-down
• Object de-dup
• Versioning

So we write some data to Atmos, using either traditional NAS or webby dubby protocols like SOAP, and can then apply policies in any of these five categories to that data. One can also extend the Atmos to accept other policies, but the absence (out of the box) of concepts like encryption, secure deletion, retention, and access control are surprising.

I am quite puzzled about how practical these policy capabilities will be in the real world. How exactly would an application say “I want you to compress that file I wrote over NFS just now?” Hitachi’s HCAP platform, for example, also has policy capabilities and a NAS front end, and although archiving applications can communicate their policy needs, I don’t see lots of current general-purpose applications using it.

Strategic Storage?

This brings me to my puzzlement: The default Atmos policies are all general-purpose, production computing ideas, not the special-purpose, archiving and retention needs served by Centera, HCAP, and the rest. So the Atmos is clearly intended to be a production data storage system, not an archiving system to compete with Centera.

Since mainstream business applications currently don’t have any capability to specify policies like these when writing files, and since NAS protocols lack any means to communicate them even if the apps want to, we can conclude that EMC expects that Atmos users will write special applications to take advantage of it.

EMC certainly doesn’t expect that the NAS-capable Atmos will simply replace today’s distributed NAS solutions. NAS is a sideshow for Atmos. The real action will be in the REST/SOAP webby dubby applications that will be written with the platform in mind and will take full advantage of these capabilities.

If this is true, and I and others suspect that it is, then Atmos really isn’t a game-changing platform unless you change your game. If you write new applications to store data with SOAP, Atmos is a nice in-house alternative to Amazon S3 or Nirvanix, and offers a very compelling set of data management capabilities. And if you want to set up shop to compete with those service providers, Atmos is a dream come true with built-in multi-tenancy.

Datacenter Strategy

So EMC alone has two seemingly competitive datacenter strategies. And then there’s Microsoft, which announced its Azure cloud platform recently, and Amazon and the other cloud providers.

So let’s say you’re a CIO for a large corporation. Which of the following strategies is more compelling:

1. Use VMware VDC-OS to add capabilities and Cloud vServices extend your current virtual infrastructure geographically
2. Recompile and tweak your Windows applications to leverage Microsoft Azure
3. Develop new applications to take advantage of the impressive storage capabilities of an in-house EMC Atmos system
4. Point your new applications at a third-party cloud provider like Amazon or Nirvanix

IT people are practical. Although we love new technology, we tend to be cautious. We also hate massive software development efforts, and only sanction them when they’re absolutely necessary. Given these personality traits, I’d say VDC-OS and perhaps Cloud vServices still stands out as the most likely and practical scenario for the majority of applications and businesses.

This is not to say that EMC Atmos will be a flop. I’m impressed by the technology, and expect that Atmos will find buyers, just as Centera did. And Atmos might even replace Centera once EMC adds retention policies to it and scales it down as well as up and out. But Atmos will not redefine the datacenter. We’re stuck with blocks and files, and VMware’s practical strategy is a winner in that world.

Update: Marc Farley compares Atmos to WAFS, with ominous implications, and echos my recent question on what is and is not innovative.

Update 2: Chuck Hollis, Storagezilla, and Len Devanna have all come right out and said that this is only intended for certain customers with massive distributed storage needs, and is not intended as a new datacenter strategy. Even the “cloudfella” says “ciao”:

Update 3: More great information, including a reply regarding VDC-OS and Atmos from the one and only Chad Sakac, more great detail about the inner workings of Atmos from Steve Todd, and even more info from Dave Graham. Finally, although I think that Cloudfellas video is cute, I wouldn’t categorize it as viral. But those Mozy ads are awesome!

See my posts on Gestalt IT for similar enterprise IT infrastructure commentary

© sfoskett for Stephen Foskett, Pack Rat, 2008. | EMC Atmos Versus VMware VDC-OS: Will The Real Cloud Strategy Please Stand Up?
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.