Identifying SAN, NAS and DAS
-
There seems to be no end to confusion around the concept of SAN, NAS and DAS. In theory these are very simple and easy to identify (often things that are simple "in theory" become complicated for exactly this reason.)
Let's start with the basics.... SAN and DAS are misnomers. In both cases we sloppily use the terms to refer to ways to use a storage array. Properly the device that we call a SAN or a DAS is just a storage array. How we use that storage array makes it a SAN or a DAS. Until it is used, it is neither. This concept is key, any system is only a SAN or a DAS by use. You can't actually manufacture one or the other, you simply make a storage array and people use it as a SAN or as a DAS (or just leave it in the box and never use it at all.)
It has to be noted that SAN is misused in layers. The acronym stands for Storage Area Network and actually is supposed to refer to the network on which a disk array(s) exist and it is still used that way, but it is also used to refer, somewhat incorrectly, to the disk arrays on that storage network as well and is used for that same storage on a non-dedicated network (LAN) as well as on a dedicated storage network (SAN.) This does little to reduce the confusion around the terms.
The second thing we need to think about is "systems." Storage is often one thing encapsulated in another. This can be drives inside RAID inside SAN inside NAS, etc. Layers upon layers. What is important is to identify which system is being referred to at any given time and not to violate encapsulation when attempting to identify a system. A system has an "interface boundary" in the storage arena so we identify each system by the interface that is presented for consumption of the storage by external devices.
There are two types of these interfaces: block protocols (the SCSI family like SCSI, SAS and iSCSI, the ATA family with SATA, PATA and ATAoE, the Fibre Channel family with FC and FCoE and others like zSAN) and the file protocols (NFS, AFS, SMB / CIFS, AFP, HTTP, FTP, SFTP, SCP and others.) These two families act very differently and present different layers in the storage stack. Block protocols are lower level and provide a "drive appearance", anything attached via a block protocol interface looks to the devices that attach to it as a hard drive. File protocols are higher on the stack and appear to devices that see them as filesystems rather than as raw devices.
Understanding this interface explains the basics when identifying a system. If the interface is a file protocol then the device is a NAS or a FileServer as these are "file" devices. (A NAS and a Fileserver are the same technology. The difference is that a NAS is a specialty, appliancized fileserver and nothing more. Both are file servers. But often these protocols are called NAS protocols.)
If the protocol is a block protocol then the device must be a drive array and would be called a SAN or a DAS (depending on use.)
It's that simple. File Protocol = NAS/FS and Block Protocol = SAN/DAS.
Now, if we have a SAN/DAS, how do we know which one we have? This is very simple. DAS = Direct Attached Storage and SAN = Storage Area Network. Without a network, we can have no SAN. So the easy way to tell them apart is if there is a switch between the storage array and the devices that consume the storage. If there is a switch, it is hooked up as a SAN. If there is no switch, it is hooked up as a DAS.
Many devices are what we call "Unified Storage". That means that a single device can present both block and file storage from the same device. This is extremely common and presents more confusion, but it should not. When presenting a file protocol, it is a NAS. When presenting a block protocol it is a SAN or a DAS. When presenting both? It is both, but the two are still discrete from each other. That they come from a single physical device is really not a factor.
And that's it. You should be able to now confidently identify a SAN, NAS or DAS simply by looking at how the system is used and what interface it presents.
-
Quick Identification Tree:
Is the appearance a file protocol? If yes, it is a file server or NAS. If no, then go to the next question.
Is there a switch? If yes, it is a SAN. If no, it is a DAS.
-
Something that might also help, but is unnecessary as the above explains how to tell one device from another, is that SAN/DAS are "dumb" devices. They just present block storage and are unaware of how that storage is used. They act like "drives" and need no logic of their own. A SAN/DAS is unaware of the filesystem(s) that might be present on itself and has no way to understand what a "file" is.
A NAS is a full computer that needs CPU, memory and an OS. The NAS is filesystem aware and can see the files that are stored on it.
-
Another extension of this is that a NAS, by definition, handles file access arbitration. That is it acts as a gatekeeper handling multiple people having access to the same filesystem and "share" at the same time. The NAS protects users from each other and does not trust end points.
A SAN/DAS can provide raw access to multiple users of a single LUN (or virtual drive) but it does not act as an arbitrator or gatekeeper. The users of the storage have to not step on each other or else they will corrupt the filesystem. The SAN relies on the end users to handle this themselves.
-
I've read some of your posts before and you came off fairly negative on SAN's - is this primarily from single point of failure (incorrect use case) or are they inherently risky? What makes DAS so attractive in comparison (if it is)? When do you choose a SAN vs DAS vs NAS?
-
So what you're saying is that they're all pretty much interchangeable and mean the same thing?
-
@MattSpeller said:
I've read some of your posts before and you came off fairly negative on SAN's - is this primarily from single point of failure (incorrect use case) or are they inherently risky? What makes DAS so attractive in comparison (if it is)? When do you choose a SAN vs DAS vs NAS?
This is an article he wrote about SANs - http://www.smbitjournal.com/2013/06/the-inverted-pyramid-of-doom/.
-
@MattSpeller said:
I've read some of your posts before and you came off fairly negative on SAN's - is this primarily from single point of failure (incorrect use case) or are they inherently risky?
I should be super clear here... I am not anti-SAN at all. SANs are totally awesome. It is the misuse of SAN (or anything else) that I am very negative about. The problem is is that SANs are difficult to understand and very often completely misused. It is only because very few people understand them yet deploy them anyway and storage is generally the most critical component of any infrastructure so playing fast and loose with storage design is much more risky than with, so, getting the wrong CPU architecture chosen.
A SAN is inherently more risky than DAS because of the extra switch. Both are more risky than local storage because of the extra chassis and cabling (and possibly switch.)
Where SAN gets really problematic is when it is used for the wrong reasons and at the wrong time. People often associate ideas like high availability with a SAN but SAN doesn't imply anything like that. SANs are very powerful like a gun. A gun it a very raw tool, but when you let people play with guns without taking a safety training class that's how people blow toes off accidentally. SANs are like that. Very powerful, but they make it way too easy to blow your own toes off.
-
@NetworkNerd said:
This is an article he wrote about SANs - http://www.smbitjournal.com/2013/06/the-inverted-pyramid-of-doom/.
Should be noted that the inverted pyramid would be the same if the pyramid point was a DAS or a NAS too. It isn't SAN that makes it a problem there. It is the upside down architecture resting on a single point.
SAN guarantees that your pyramid is three levels or more. NAS implies it but does not guarantee it. DAS guarantees only two levels. So SAN gets picked on the most but only because it is the only option that has the fact that there is a switching level inherent to the concept.
-
@MattSpeller said:
What makes DAS so attractive in comparison (if it is)?
DAS is always simpler than SAN. They are the same physical devices, just one has an extra switch and one does not. You can take one server and one storage array and hook it up as a DAS, then add one cable and one switch and turn it into a SAN is like ten seconds. Then remove the switch again and go back to DAS.
SAN is nice because you can scale beyond the limits of physical connectors. That is the one and only upside to SAN versus DAS. DAS doesn't need the switch. The switch adds cost, latency (albeit generally pretty small) and risk (an extra device or layer to fail.)
So a SAN is a DAS with a longer dependency chain.
-
The reason that NAS is often preferred to SAN is because it is generally far better understood by IT practitioners. Nearly everyone in IT has worked with mapped drives, and that is NAS. So how they work is obvious and not confusing. A NAS provides arbitration for access and that is critical. The NAS doesn't trust the users, it protects users from each other (or themselves.)
SAN is often confused with NAS and this is where it becomes very dangerous. Because SANs lack arbitration for file access, but because users tend to expect it, it is extremely common for users to destroy data on a SAN because they think that it is robust and provides protections that it does not.
If you were an IT practitioner who know SAN inside and out and did not know NAS well, then that recommendation would be reversed. But the number of people familiar with file protocols is very high and the number familiar with block is very low. So this would be extremely rare.
-
@MattSpeller said:
When do you choose a SAN vs DAS vs NAS?
I wrote about this a few years ago in Choosing a Storage Type.
The rule of thumb is written like this...
Local Storage -> DAS -> NAS -> SAN
Start to the left and stop when the type is an option. Only move to the right when the option to the left is not possible. So local storage is always the default starting point. Many times you need to have external storage, but not nearly as often as people generally assume. You can very often use local storage. Even for some very complex things.
If you must use external storage, DAS is the least complicated (mostly) and does not require a network. So evaluate DAS. If DAS meets your needs, use DAS. If not, move right.
Evaluate if you can do what you need with NAS. It's very rare that you can't use either DAS or NAS for what you want to do. NAS covers nearly every base that local storage and DAS cannot do.
If none of those do what you need, SAN is the storage type that handles the remaining use cases - which basically boil down to large scale storage consolidation. In an SMB, that would be extremely rare. But in an enterprise that large scale consolidation (that is cost savings, not performance or reliability) is a huge factor and makes SAN very common and very sensible there.
-
Having a SAN is like putting NO2 in your car engine. Sure it'll make the car faster, but most people don't need the headache, cost, maintenance and additional wear & tear. If a car mechanic recommended it to every soccer mom who brought in their minivan, or every FedEx truck, they'd be run out of town soon enough. Sadly that isn't yet the case for SMB IT.
-
Common use cases:
Local Storage: Nearly everything. All normal storage use cases. From low cost stand alone servers to super high performance systems to cluster nodes to high availability systems.
NAS: Shared storage for users, generally accessed over a large array of machines. NAS storage tends to focus on "users" rather than "servers."
DAS: Small scale storage consolidation.
SAN: Large scale storage consolidation.
-
I've got them sorted now, thank you!
-
Would it be better to use a file based storage system for the backend of a virtual infrastructure (VMware supports NFS, HyperV supports SMB3.0, Xen will use whatever you have mounted if I remember right) Or use a block based storage system? Is it better to have access to the underlying architecture, or give the hypervisor the raw block storage to do with it what it will? I've got my own ideas on the subject matter, but I would like to hear what other have to say.
-
@Nic said:
Having a SAN is like putting NO2 in your car engine. Sure it'll make the car faster, but most people don't need the headache, cost, maintenance and additional wear & tear. If a car mechanic recommended it to every soccer mom who brought in their minivan, or every FedEx truck, they'd be run out of town soon enough. Sadly that isn't yet the case for SMB IT.
Except that SAN doesn't make you faster, it in fact makes you slower (normally).
-
@coliver said:
Would it be better to use a file based storage system for the backend of a virtual infrastructure (VMware supports NFS, HyperV supports SMB3.0, Xen will use whatever you have mounted if I remember right) Or use a block based storage system? Is it better to have access to the underlying architecture, or give the hypervisor the raw block storage to do with it what it will? I've got my own ideas on the subject matter, but I would like to hear what other have to say.
I'd say it really depends on your situation. Using Scott's post above
Local Storage -> DAS -> NAS -> SAN
If you're using local storage or DAS because they are usable, you're forced into using direct access (though in the case of Hyper-V I'm not really sure what the access is like when access local/DAS?
If NAS fits your bill, then your forced into use a file protocol, and of course lastly, if you end at SAN as the only viable solution you're back to block level.
-
@coliver said:
Would it be better to use a file based storage system for the backend of a virtual infrastructure (VMware supports NFS, HyperV supports SMB3.0, Xen will use whatever you have mounted if I remember right) Or use a block based storage system? Is it better to have access to the underlying architecture, or give the hypervisor the raw block storage to do with it what it will? I've got my own ideas on the subject matter, but I would like to hear what other have to say.
"Better" is tough to determine here. The general recommendation, especially for VMware and Xen which have this very mature, is to use NFS before iSCSI. This is mostly because the protocol provides "accident prevention", is easier to set up and reacts well to bonding. iSCSI requires you to use MPIO and to more carefully control the protocol to protect yourself.
iSCSI will normally outperform NFS, but performance is rarely a major concern and it is only "normally" faster.
So NFS is generally recommended (even by the vendors) because it is safe and easy. If you need more performance and are concerned about NFS then iSCSI isn't really the solution and what you really need to do is look at something with lower latency like FC or SAS.
-
On HyperV, the use of SMB3 is pretty nascent and very vendors provide a good platform for it. So there tends to be a trend to remain with iSCSI for HyperV because of this. Not because SMB3 isn't the better option at a protocol level but because it is so new it remains mostly impractical.
