How granular is your storage? This question is just as relevant today as when I first published this article in 2008!

Many storage challenges focus on correlating high-level uses of data (such as applications) with the nuts and bolts of storage infrastructure. These discussions often revolve around the conflict between data management, which demands an ever-smaller unit of management, and storage management, which benefits most from consolidation. Developing data management capability that is both granular enough for applications and scalable enough for storage is one key to the future of storage.

Storage Management: Scaling Up

As I discussed in a previous Sunday Series piece, Turning the Page on RAID, the data storage industry has traditionally focused on reducing granularity. Disk capacity has expanded, and RAID technology has multiplied this by combining multiple physical drive mechanisms into a single virtual one. Storage virtualization technologies, from the SAN to the server, have also often been touted primarily as a mechanism to reduce heterogeneity. From a technical perspective, therefore, granularity has been an obstacle to overcome.

The core organizational best practice for storage management is the reduction of complexity and the enforcement of standardization. Consolidation of storage arrays and file servers is a common goal, as IT seeks to benefit from economies of scale. The goal of both initiatives is the creation of a storage utility or managed storage service. This mirrors efforts on the server and network sides to consolidate and virtualize hardware.

Although both technological and organizational factors have traditionally driven granularity out of storage, this does not have to be the case. Virtual pools of storage are ideal for providing storage on demand, as disk-focused RAID groups give way to more flexible sub-disk storage arrangements. And an operational focus on standardized storage service offerings has the potential to enable scalable management of these smaller units.

Filing Service

File-based protocols would seem to have more potential for granular storage management, but they have been undermined by the hierarchical nature of modern file storage. Whether the connection to a file server uses NFS, CIFS, or AFP, the key unit of management is actually the shared directory, not the file. All files in the share \\firefly\backups would be located on the same server and would be managed as a unit.

NAS virtualization can change this somewhat, as can more specialized NAS servers. Although Microsoft DFS enables consolidation and virtualization of NAS shares, it does not allow subdivision of shares below the directory level – all files in a directory must be placed on the same server. Tricks like stubbing and links allow for some movement, but these do not solve the core issue. Specialized virtual NAS devices from F5 (the ARX, nee Acopia), NetApp, BlueArc, Symantec, and others have the ability to move files individually, providing as much a virtualized storage environment as any block-focused enterprise array. Avere is also beginning to talk about granular file management.

But even an ideal virtualized file server lacks the kind of granularity demanded by users. They care about data, not files, and most applications consolidate their data storage into a few files. Consider a database, for example, where users want each record treated uniquely but storage devices see just a few much larger files. We need a storage revolution, where someone creates an ideal storage platform in which each individual record or object includes custom metadata and is managed independently. This would truly be a massive change, however, and it is not clear that all applications will follow the object storage model of Google and Amazon.

Small is Beautiful

Barring a revolution in data management, our best hope is to allow greater granularity in storage management. As mentioned above, virtualization technology has the potential to enable management and protection of any unit of storage, right down to the individual block or record. But the reality of storage virtualization has not matched its promise.

What is needed is greater integration. Each layer of virtualization (file system, volume manager, hypervisor, network, array, and RAID) also hides necessary details from lower layers. Consider the case of a virtual server snapshot: The application and filesystem must be in a quiesced state to allow a snapshot to be taken at the storage level, but the storage array has no intrinsic information about how its capacity is used. A given LUN might contain dozens of servers on a shared VMFS volume, so all must be snapped together.

Integration can be enabled by sharing more information through APIs. VMware leverages Microsoft Volume Shadow Copy Service (VSS) integration for shared storage so a VMFS snapshot can call the operating system and even applications (Windows Server 2003 only, for now) to prepare the data. Similarly, VSS can communicate directly with supported iSCSI and Fibre Channel arrays, calling a snapshot at the right moment. And Microsoft is, no doubt, enhancing VSS as we speak.

As virtualization technology matures, expect this type of integration to improve. We hope to see more APIs exposed by VMware and Microsoft, allowing communication up and down the stack to break through the information barrier. Imagine a future where a standard API like VSS can pass a message through VMware, Xen, and Hyper-V to the underlying storage array to initiate a snap. I predict that this kind of integration-enabled granularity is not too far off.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Granularity: The Hidden Challenge of Storage Management
This post was categorized as Computer History, 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.

Fear

Back when I used to teach the “Storage 101″ session at Storage Decisions, I was consistently amazed to find little awareness of enterprise NAS systems. People complained about LUNs and Fibre Channel but when I suggested using NFS or SMB their heads almost exploded. “We would never use that for application storage,” they shouted. “File servers are for home directories, not data center stuff!” Clearly, NAS faces an uphill battle.

In a recent piece I wrote, I referred to what I consider to be the prime best practice: Use the right tool for the job. It’s a simple statement, and one that resonates beyond IT and the technology world. But it can be devilishly difficult to see what the right tool is sometimes. Why not use NAS for virtual machine storage? NetApp has been beating that drum for years, yet NAS has a very small footprint in VMware. How about databases on NFS? Exchange over SMB? Block storage has a massive lead over NAS in all of these areas.

Rear this “best practices” piece, Use Process Solutions For Process Problems, Technical Solutions For Technical Ones

IT folks seem downright fearful of file-level storage protocols. Has NFS really burned them that badly over the decades? Can SMB/CIFS really be as bad as they think?

Loathing

I wonder if this terror has more to do with the products people have used than the fundamental concept of file services. Many NAS servers (and clients) are barely functional. Sadly, NFS and SMB are easy to get 80% right, but the 20% corner case interaction takes decades to overcome. My daily storage consulting work exposes me to a myriad of NAS configurations, and few of the multi-platform combinations end well.

Note: Although it has long been known by a variety of names, the Windows NAS protocol is currently called Server Message Block or SMB. Common Internet File System (CIFS) was a failed mid-1990′s attempt by Microsoft to make this protocol standard on the Internet.

Consider the Mac. Apple added an SMB client to OS X in 2001 but, despite many updates, it is far from reliable. Mac users in general loathe connecting to Windows file servers, and business users have located numerous bugs in the handling of Mac-specific file types. It’s bad enough that one company, GroupLogic, created an entire AFP server for Windows just to solve these tricky issues.

This situation often happens in reverse, too. Windows admins are justifiably cautious when deploying non-Windows SMB servers, whether software (Samba, Novell, etc) or system (NetApp, Celerra, BlueArc, etc). As a very early NetApp user, I watched their CIFS/SMB server evolve over a decade and a half into a fairly robust solution, but the early years were downright painful.

Lest you throw rocks at Redmond, know that SMB is not alone with functionality problems. The interoperability of NFS servers and clients is a bit better thanks to open(ish) standards and open source implementations, but its reputation is just as bad. And Apple’s proprietary AFP protocol is downright notorious.

I’ve been there myself many times. I tried to set up a home server based on open source software (Linux, FreeBSD, Samba, Netatalk, etc) but rejected it outright after many frustrating years. Today I use a Mac Mini for file sharing in OS X and serving iTunes music and movies (goodbye, Firefly!) And years of fighting with Samba in enterprise environments taught me two things: It’s possible to get it running well with Windows clients but it’s astonishingly easy to get it wrong.

Enterprise NAS?

We all know that interoperability is devilishly difficult. I don’t envy the NetApp and EMC engineers that have to tweak and tune their server for every possible client, bugs and all. And I am impressed that, after probably millions of man-hours of work, they were able to come up with something stable for a subset of use cases. But this just makes me even more cautious about third-party NAS servers.

I talk to storage vendors all the time, and many of their new products support NFS and SMB. But my internal alarms start going off when I hear about these products. There are two simple reasons for this:

1. As mentioned above, NAS is rare in primary data center applications. It may be common for user files (euphemistically called “unstructured data”) and certain distributed applications (simulation, rendering, etc), but most use cases still call for block SCSI (FC/iSCSI) storage.
2. As further mentioned, getting NAS right takes a massive amount of effort. New and small vendors tend to slap Samba on their (Linux-based) box and call it a day. This is very, very far from being sufficient for enterprise use.

This is why I usually ignore NAS functionality in storage systems except for long-tenured and deep-pocketed vendors. Although the world is turning to “Unified Storage” and multi-protocol support, I’m focusing primarily on block (SCSI) and cloud (REST) capability because the former has proven somewhat easier than NAS to get working and the latter is both simple and “green field” with no legacy concerns.

© sfoskett for Stephen Foskett, Pack Rat, 2010. | Why Do I Ignore NAS?
This post was categorized as Apple, Computer History, Enterprise storage, Gestalt IT, Terabyte home, Virtual Storage. 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.

This is the second entry in my Top-Ten in Storage series.

Not every innovative product can succeed in the market, and no matter how good some ideas seem, they can fail to make much of an impact. The truth is, people buy solutions, not technologies.

This list includes products so cool, so ahead of their time, that they just couldn’t fail. But they did.

1988 EMC Orion/Allegro

EMC’s RAM-based storage array predated and presaged its Symmetrix, offering lightning-quick I/O for very small workloads. But the Orion had a few serious drawbacks: It was astonishingly expensive, offered tiny capacity, and was never available for open systems. EMC’s initial offerings in the open systems market, Centriplex and Harmonix, also deserve mention though the company proved its worth with its “best” Symmetrix a few years later.

1985 3COM 3Server

I’ve written about the 3Server before, but let’s sum up: Before RAID, SAN, and NAS, and even before NetWare and NFS became entrenched, 3COM introduced a flexible multi-disk network storage and print server called the 3Server. It was an innovative combination of hardware and software, but it lost out to NetWare on open PC hardware in the market. Although the 3Server lasted just a few years, it made a lasting contribution to the field: Its 3+Share software became 3+Open, then LAN Manager, and was finally absorbed by Microsoft to become SMB/CIFS.

HP AutoRAID (High Availability Disk Array Model 12)

The first post-RAID virtual sprang fully-formed from the big brains at HP to challenge the industry-leading modular offerings from Data General’s CLARiiON and DEC/Compaq’s StorageWorks. It one-upped everyone with automatic relocation of LUNs between different RAID levels based on workload about a decade before Compellent, EqualLogic, and 3PAR had anything of the sort. But the AutoRAID had two key drawbacks: Like mama bear, it wasn’t big enough for big companies but was too big and expensive for little ones, and it was SCSI-only (though a Fibre Channel bridge was a common accessory). Some of the concepts lived on in the HP EVA line, but AutoRAID didn’t last long.

Microsoft Object File System (OFS)/Relational File System (RFS)/WinFS

Microsoft shoulda-coulda-woulda revolutionized file storage with nearly every major operating system release. It looks the same every time: A database/filesystem hybrid that would add structure to the vast unstructured file world. Despite the hype, we haven’t seen it yet. 

MangoSoft Medley

Consider the typical LAN: Lots of clients with lots of hard drive space connected to a server with yet more disk capacity. Wouldn’t it be nice if the space on these clients could be used as a virtual network server? Well that’s just what MangoSoft announced in 1997, gaining much attention in the PC press. Sadly, the idea never really caught on, although MangoSoft continued. But distributed network storage has become the industry’s Brigadoon, trotted out as a new idea year after year.

StorageNetworks

This is my flop – I worked for StorageNetworks from 1999 through 2001.

StorageNetworks was launched in 1998 to provide off-premise storage and backup as an on-demand service for enterprise customers. They sought to take advantage of the emergence of high-speed Fibre Channel connectivity over metro distances to commoditize storage capacity. But only Houston (where I worked) had an acceptable infrastructure for the service, so the company changed focus to hosting centers. Then off-site backup. Then software. Nothing worked apart from vendor-independent services, and the (now public) company was shy to base its revenues on that. StorageNetworks was gone in 2003, but does the service remind anyone of Amazon S3 or Nirvanix? Maybe it was just ahead of its time.

Compaq VersaStor

Announced in 1999, VersaStor would have been a revolution in Fibre Channel SANs, a full out of band virtualization solution leveraging specialized HBAs directing traffic. It was continually pushed back, finally being “merged” (after Compaq) with HP’s StorageApps in-band SANLink to become CASA. But then EMC sued HP over virtualization patents, derailing CASA, and the whole mess was permanently shelved at the end of 2003.

IBM Ice Cube/Collective Intelligent Bricks Hardware

IBM rocked the storage press in 2003 with their announcement of Almaden Research’s Ice Cube concept. Instantly dubbed “Lego brick storage” (trademarks be damned!), the storage units could be stacked in two dimensions, scaling without limit. Coolest of all (literally), the bricks were chilled with water! Although the concept progressed, we still haven’t seen it. But this didn’t stop Seagate from developing a similar concept, ISE, which is now Xiotech’s main offering. IBM’s Storage Tank and VSS could have been nominated, too, but I’m not a sadist.

Revivio CDP

Revivio was the pioneer of continuous data protection (CDP), with great technology and people. But no one (other than Symantec, eventually) bought it.

Pirus

Little Pirus was working on a small but scalable virtualized target when it was acquired by Sun in September of 2002. Their technology was launched as the StorEdge 6920, a mini alternative to the HDS USP in 2004, but (according to insiders) it didn’t exactly light the world on fire. Sun finally pulled the plug on the 6920 in early 2007, with HDS taking over continuing support for anyone who bought the moribund product.

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Top Ten Coolest Enterprise Storage Flops
This post was categorized as Computer History, Enterprise 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.