Storage @ Work

I was in Los Angeles today talking to customers here, asking them about their storage applications. One of the themes that came up repeatedly was the use of Microsoft Windows Server 2003 for file services connected to EqualLogic Storage Systems.

Our customers tend to appreciate administrative efficiency and low cost of ownership. Not surprisingly, they also know they can wring a huge amount of functionality out of plain, vanilla Windows file servers. Similar to the way iSCSI helps them leverage their organization's networking skills, Windows file servers help them leverage their entire organization's Windows admin skills, including system and network management, not to mention the licensing agreements they have with Microsoft. For most of them, setting up a Windows file server is a snap and takes almost no time whatsoever. Microsoft has made the iSCSI SAN components very easy to deal with and setup with an EqualLogic storage system is amazingly simple as most of our customers will testify. In most cases, setting up a Windows File server with EqualLogic storage takes less time and effort than installing an industry leading NAS system.

Some in the industry are trying to make a big deal out of the concept of unified storage. The idea of unified storage is that specialized multi-protocol, multi-network NAS/SAN systems will connect to virtually any type of client system using virtually any network or protocol they might want to use. The extension is that if you have a single technology to work with, it is more efficient own. Hmmm. Sounds a bit like a vendor trap to me.

Even if you don't believe that unified storage is another in a long line of storage vendor traps, the weakness with any one-size-fits-all product is the impossibility of fitting all the requirements equally well. Some functions tend to work well, while others tend to be stuck in perpetual mediocrity.

We have customers that believe unified storage is an unnecessary luxury and waste of their resources. Instead, they have made the shrewd observation that all the standards they need already exist and that their best practices begin by enforcing conformity with those standards. For many, Ethernet, TCP/IP and Windows servers are their core infrastructure standards. They have also come to the realization that EqualLogic iSCSI SANs are an extremely good fit for these standards.

Dave Hitz at Netapp posted an interesting blog last week where he discussed the confusion that exists regarding storage networks and protocols. At the end, he punted and basically decided that a "customer is the expert" approach is best and that if a customer wants to analyze things a certain way, then it was best just to go along with them. Why bother explaining the fine points between file and block I/O when you can just agree with something that goes against your sensibilities, right? Heaven forbid, why screw up a sales opportunity trying to explain to someone who wants to buy a lot of your equipment that everything they just said was goofy? Yes, I get it, and I have to admit it, I've been there. But Dave, don't you think its a bit of a cop out to say 'I've given up, I'll let them believe what they want to believe' in a blog. Whether we like it or not, there are people who hope to catch valuable insights from guys like us - or at least the occasional entertainment of disagreement. So, in the spirit of both, I'm giving you the WAGGING FINGER OF SHAME.

At any rate, I don't think this SAN/NAS protocol/network stuff is actually all that difficult if you forget the protocol junk and focus on the applications. The first thing is to understand that the network used for storage is just a network that can carry both kinds of traffic, just like a cable TV network can carry video, Internet and voice traffic. It does not matter if the network is Fibre Channel or Ethernet (or carrier pigeons), the network is simply a way to transmit information for a storage application.

Rather than talking about protocols, which can turn an otherwise alert human into Rip Van Winkle, it helps to focus on the two primary applications in storage networks: storing and filing. Think of them as being analogous to video and voice applications running on a cable network.

Storing was historically developed to transmit information between computer systems and relatively unintelligent storage devices such as disk drives and tape drives. This is roughly similar to a TV network where the device receiving the information is an idiot box (television). Initially, storing was done over a bus, whereas television was transmitted wirelessly. As the technologies matured, both were adapted for use over networks. Storing over a network is referred to as a SAN, whereas transmitting video signals over the cable network is called highway robbery. In SANs, the storage device performs the storing function without an awareness of what the information is. Likewise a television has no awareness of what is coming out of its picture tube and speakers. Both simply do what they are told to do (its more like a master/slave thing than a client/server relationship). Where storing is concerned, a system program controls the sequence of operations that determines what information is stored, and what address spaces in the device are used to store it. This system program is usually a file system, a database system or a backup system and it has all the responsibility of knowing how to access the information stored in the device.

Filing applications (or services) were historically developed to transmit data files between intelligent systems, analogous to the way a person can tell a story to another person over the phone. Both file services and the telephone system were developed for network environments connecting multiple intelligent entities. The system that provides the file storing service is called a NAS system, whereas the person listening to the story on the phone is simply called by their name or pronoun such as "yo" or "mom". Both enti COMMENT: AUTHOR: Paula Long DATE: 04/25/2007 12:06:56 EMAIL: plong@equallogic.com URL: Marc, as always, you have given a very thoughtful answer and a clear explanation of the difference between file access and block access to data. Believe it or not, I have talked to smart people who get confused by the difference between NAS and iSCSI SAN. It had nothing to do with the wire and everything to do with how customers' applications access their data. The applications they run access the data using file semantics. On Windows there are very few applications that talk to physical disks (raw devices in UNIX-speak); in UNIX there are fewer that talk to the raw device now than when I did DB work, but still more than zero. The fact that administrators create a physical device then put a file system on it immediately is what muddies the water. With a good SAN implementation, the administrator never views the LUN/disks again. They see their drive letter or a UNIX mount point. So when someone says their applications talk to files, people tell them they must want NAS. It’s historical more than anything else. If you ask a more specific question—for example, do you want to have your database or mail server talk to your storage using NFS or CIFS?—they look at you like you’ve grown a second head. It’s difficult for them to comprehend why you would add that additional unnecessary layer between the storage and the application. Not everyone hears/reads NAS and automatically understands this to mean NFS, CIFS or some other distributed file system protocol. NAS is an overused term that can confuse people. It means Network Attached Storage. When some folks hear “network” they think “Ethernet.” You say “iSCSI,” they hear “Ethernet.” Hence the confusion; our language is precise if you understand the history of the term NAS, and don’t confuse the term “NAS standards” with Network Attached Storage. We should make sure we don’t argue with customers. At the same time, we should make sure we clearly understand what they are telling or asking us. Our definitions and theirs aren’t always the same. So I guess I agree with David that the terms can confuse people. I am not sure that saying “There’s no difference” is the answer, though, since you’ll have one disappointed DBA if she finds her database talking NFS or CIFS to access storage. Paula

Dave Hitz and I are going back and forth in our blogs, explaining our views on language - specifically the lexicon of storage. Dave's most recent post reiterates the explanation given in his previous post. Apparently he didn't like the fact that I awarded him the wagging finger of shame for willingly blurring the definitions of SAN and NAS.

My take on it still the same. The terms we use stand for something and provide a way for us to communicate complex concepts quickly. When we start polluting the definitions of accepted terms like SAN, for instance, we create confusion about things that are already complex - and this wastes a lot of time. A room full of people discussing storage can make a lot of progress if everybody clearly understands the terms. That same group without a shared lexicon will have a very difficult time succeeding. You can use the word "hammer" to refer to a hammer, a pair of pliers, or a screwdriver; or you could use the word "tool" to generically refer to these things. I think the problem you are having Dave is the lack of a generic term for a network that does "storage stuff". I use the term "storage network".

It has always been a problem in storage networking and I've always thought the term "SAN" was flawed. Let's face it - it was a term adopted by the Fibre Channel industry a decade ago to get the market to identify the technology with a new storage architecture. Your customers will use whatever terms they want to use and I don't particularly care what terms you use with them. However, I think you understand the difference between your role as a thought leader in this industry and your role as a sales support dude at Netapp. If you had written about the need for a better generic term for networks with storage traffic, that would have been a good topic, but instead you wrote about how it doesn't really matter what you call it and suggested we kidnap the term SAN for that purpose. This just creates confusion, which leads to wasted time, arguments, blame and all the other unfortunate things that go on when people don't communicate effectively. The finger wags because you are contributing to the confusion.

Storage-zilla has a post where he points to an EMC White Paper that explains how Netapp Filers make their SAN (block I/O) storage work through their WAFL-based filers.

The same argument the Zilla man lays out here works for EqualLogic of course too. If you are looking for iSCSI performance, make sure you check out EqualLogic iSCSI SAN solutions as well as those EMC and Netapp boxes.

Lucas Mearian at Computerworld wrote about Dell's acquisition of EqualLogic and concludes that it will force a split in the Dell/EMC partnership.

I think Lucas is an astute observer of the industry, but my previous opinion posted on the VMTN forums and my agreement with Chuck Hollis' blog posting yesterday weren't swayed by what Lucas had to say.

Dell and EMC both have a lot more at stake here than the iSCSI business that EqualLogic brings to the table. They do business with a much broader set of products than iSCSI storage - such as VMware. Dell is a very valuable sales channel for EMC and EMC is a very important technology provider for Dell. There will always be some level of competition among the largest companies in the technology sector. It creates a bit of a mess sometimes, but having interdependencies between companies provides stability and efficiencies that ultimately result in broader solutions at lower costs.

I suspect this deal will actually end up creating additional opportunities to expand the business between Dell and EMC. I'm not always right about these things, but that's what my intuition is telling me.

I just got done sitting in on the Wikibon conference call about storage clusters. Wikibon is an idea that I like: open discussions and content that intends to engage subject matter experts, vendors, analysts and customers.

But noble goals do not make for satisfying group gropes. The call today was a mashup of perspectives and expectations that never came together. I think the problem is that the words "cluster" and "storage" conjure up images that are as consistent among people as ink blot interpretations.

This is going to be Wikibon's challenge. They don't want to control the discussion as much as facilitate it. Unfortunately the storage industry has a serious penchant for willful fragmentation. Its one of the reasons why the vocabulary of storage is so confusing. Anyway, the call ran down many different threads without much fusion of ideas across them. One of the more interesting threads involved a discussion of Google and Amazon style storage, with Robin Harris insinuating that all large companies were going to need to adopt such designs. Hmmmm. Not sure about THAT one. Then there was the usual confusion about whether or not we were talking about clustered file systems or clustered SAN storage and whether or not that meant Fibre Channel and whether or not Fibre Channel had much of a future and yadda yadda yadda. Yikes!

I give Peter Burris a lot of credit for attempting to create a recorded summary out of the preceding discussion. His EMC-centric analysis of the storage universe came through a bit strong, but its not difficult to understand considering his many years of breathing and drinking EMC details and their role in the industry.

EqualLogic sells distributed iSCSI SAN storage systems that are built by adding storage modules that work together in an Ethernet network. We don't call in "clustered" - we don't call it "grid". Its distributed, its modular, its very easy to install and manage and it's performance scales as you add systems to the group. I really believe that the future of storage is already available from EqualLogic, its just that most industry observers have not taken the time to understand it.

By now, Netapp's new identity isn't exactly "new" news but it's about as good as it gets in the storage blogosphere. So I was trying to figure out today what I didn't like about Netapp's new logo and it finally occurred to me that it reminded me in some incomplete way of the EqualLogic logo. What's with that? Anyway here is a video I shot last night about it and a few links to other people's comments.

Stephen Foskett - Pack Rat
Dave's Blog (inside out Dilbertization - a techie talking marketing)
The Register and it's hilarious reaction
Zerowait High Availability
The Occasional blog
Inspired by Foskett (see his link above)
Mojo-man

A new roadrant where I bust a knuckle, avoid another bad driver and recall a childhood fear, thanks to the beating heart graphic that Netapp is using.

In case you didn't see it, Dave Hitz posted again on their logo story. He doesn't sound too defensive, in fact, I think he shows some pride - maybe he designed it himself?

Zilla man spotted it after the Register outed it.
Freaking unbelievable.

I thought IBM had decided to go with Netapp as their choice for NAS solutions. Now I read in Tony's blog this week that they have something else for people that want wall to wall NAS coverage. What's up with that?

The only thing I can think of is a lack of agreement on something between the two companies. There are so many questions. Are SOFS and N-series storage compatible? Do they integrate? If not when does a customer buy one and not the other? Is this what it means to simplify things for customers? Where does SOFS really come from? Is it the next iteration of SFS? Was SFS the bastard stepchild of GPFS? If not, will it re-appear as something else to plug a perceived hole in the N series product line? What about Netapp's plans to have super-scalable NAS? And what about iSCSI and Fibre Channel? Do they go to prison in a SOFS world?

The soap opera of storage continues.......