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
