One of the greatest confusions that I have seen in recent years is that between NAS and SAN.\u00a0 Understanding what each is will go a long way towards understanding where they are useful and appropriate.<\/p>\n
Our first task is to strip away the marketing terms and move on to technical ones.\u00a0 NAS stands for Network Attached Storage but doesn’t mean exactly that and SAN stands for Storage Area Network but is generally used to refer to a SAN device, not the network itself.\u00a0 In its most proper form, a SAN is any network dedicated to storage traffic, but in the real world, that’s not how it is normally used.\u00a0 In this case we are hear to talk about NAS and SAN devices and how they compare so we will not use the definition that includes the network rather than the device.\u00a0 In reality, both NAS and SAN are marketing terms and are a bit soft around the edges because of it.\u00a0 They are precise enough to use in a normal technical conversation, as along as all parties know what they mean, but when discussing their meaning we should strip away the cool-sounding names and stick to the most technical descriptions.\u00a0 Both terms, when used via marketing, are used to imply that they are a certain technology that has been “appliancized” which makes the use of the terms unnecessarily complicated but no more useful.<\/p>\n
So our first task is to define what these two names mean in a device context.\u00a0 Both devices are storage servers, plain and simple, just two different ways of exposing that storage to the outside world.<\/p>\n
The simpler of the two is the SAN which is properly a block storage device.<\/em>\u00a0 Any device that exposes its storage externally as a block device falls into this category and can be used interchangeably based on how it is used.\u00a0 The block storage devices are external hard drives, DAS (Direct Attach Storage) and SAN.\u00a0 All of these are actually the same thing.\u00a0 We call it an external hard drive when we attach it to a desktop.\u00a0 We call it a DAS when we attach it to a server.\u00a0 We call it a SAN when we add some form of networking, generally a switch, between the device and the final device that is consuming the storage.\u00a0 There is no technological difference between these devices.\u00a0 A traditional SAN can be directly attached to a desktop and used like an external hard drive.\u00a0 An external hard drive can be hooked to a switch and used by multiple devices on a network.\u00a0 The interface between the storage device and the system using it is the block.\u00a0 Common protocols for block storage include iSCSI, Fibre Channel, SAS, eSATA, USB, Thunderbolt, IEEE1394 (aka Firewire), Fibre Channel over Ethernet (FCoE) and ATA over Ethernet (AoE.)\u00a0 A device attaching to a block storage device will always see the storage presented as a disk drive, nothing more.<\/p>\n A NAS, also known as a “filer”, is a file storage device.<\/em>\u00a0 This means that it exposes its storage as a network filesystem.\u00a0 So any device attaching to this storage does not see a disk drive but instead sees a mountable filesystem.\u00a0 When a NAS is not packaged as an appliance, we simply call it a file server and nearly all computing devices from desktops to servers have some degree of this functionality included in them.\u00a0 Common protocols for file storage devices include NFS, SMB \/ CIFS and AFP.\u00a0 There are many others, however, and technically there are special case file storage protocols such as FTP and HTTP that should qualify as well.\u00a0 As an extreme example, a traditional web server is a very specialized form of file storage device.<\/p>\n What separates block storage and file storage devices is the type of interface that they present to the outside world, or to think of it another way, where the division between server device and client device happens within the storage stack.<\/p>\n It has become extremely common today for storage devices to include both block storage and file storage from the same device.\u00a0 Systems that do this are called unified storage<\/em>.\u00a0 With unified storage, whether you can say that it is behaving as block storage or file storage device (SAN or NAS in the common parlance) or both is based upon the behavior that you configure for the device not based on what you purchase.\u00a0 This is important as it drives home the point that this is purely a protocol or interface distinction, not one of size, capability, reliability, performance, features, etc.<\/p>\n Both types of devices have the option, but not the requirement, of providing extended features beneath the “demarcation point” at which they hand off the storage to the outside.\u00a0 Both may, or may not, provide RAID, logical volume management, monitoring, etc.\u00a0 File storage (NAS) may also provide file system features such as Windows NTFS ACLs.<\/p>\n The key advantage to block storage is that the systems that attach to it are given an opportunity to manipulate the storage system as if it were a traditional disk drive.\u00a0 This means that RAID and logical volume management, which may already have been doing in the “black box” of the storage device can now be done again, if desired, at a higher level.\u00a0 The client devices are not aware what kind of device they are seeing, only that it appears as a disk drive.\u00a0 So you can choose to trust it (assume that it has RAID of an adequate level, for example) or you can combine multiple block storage devices together into RAID just as if they were regular, local disks.\u00a0 This is extremely uncommon but is an interesting option and there are products that are designed to be used in this way.<\/p>\n More commonly, logical volume management such as Linux LVM, Solaris ZFS or Windows Dynamic Disks is applied on top of the exposed block storage from the device and then, on top of that, a filesystem would be employed.\u00a0 This is important to remember, with block storage devices the filesystem is created and managed by the client device, not by the storage device.\u00a0 The storage device is blissfully unaware of how the block storage that it is presenting is used and allows the end user to use it however they see fit with total control.\u00a0 This extends even to the point that you can chain block storage devices together with one providing the storage to the next being combines, perhaps, into RAID groups – block storage devices can be layered, more or less, indefinitely.<\/p>\n Alternatively, a file storage device contains all of the block portion of the storage so any opportunity for RAID, logical volume management and monitoring must be handled by the file storage device.\u00a0 Then, on top of the block storage, a filesystem is applied.\u00a0 Commonly this would be Linux’ EXT4, FreeBSD and Solaris’ ZFS, Windows NTFS but other filesystems such as WAFL, XFS, JFS, BtrFS, UFS and more are certainly possible.\u00a0\u00a0 On this filesystem, data will be stored.\u00a0 To them share this data with the outside world a network file system (also known as a distributed file system) is used which provides a file system interface that is network enabled – NFS, SMB and AFP being the most common but, like in any protocol family, there are numerous special case and exotic possibilities.<\/p>\n A remote device wanting to use storage on the file storage device would see it over the network the same as it would see a local filesystem and is able to mount it in an identical manner.\u00a0 This makes file storage especially easy and obvious for end consumer to use as it is very natural in every aspect.\u00a0 We use network file systems every day for normal desktop computing.\u00a0 When we “map a drive” in Windows, for example, we are using a network file system.<\/p>\n One critical differentiation between block storage and file storage that must be differentiated between is that, while both potentially can sit on a network and allow multiple client machines to attach to them, only file storage devices have the ability arbitrate that access.\u00a0 This is very important and cannot be glossed over.<\/p>\n Block storage appears as a disk drive.\u00a0 If you simply attach a disk drive to two or more computers at once, you can imagine what will happen – each will know nothing of the other and will be unaware of new files being created, others changing and they systems will rapidly begin to overwrite each other.\u00a0 If your file system is read only on all nodes, this is not a problem.\u00a0 But if any system is writing or changing the data, the others will have problems.\u00a0 This generally results in data corruption very quickly, typically on the order of minutes.\u00a0 To see this in extreme action, imagine having two or three client system all believe that they have exclusive access to a disk drive and have them all defragment it at the same time.\u00a0 All data on the drive will be scrambled in seconds.<\/p>\n A file storage device, on the other hand, has natural arbitration as the network file system handles the communications for access to the real file system and filesystems, by their nature, are multi-user naturally.\u00a0 So if one system attached to a file storage device makes a change, all systems are immediately aware of the change and will not “step on each others toes.”\u00a0 Even if they attempt to do the the file storage device’s filesystem arbitrates access and has the final say and does not let this happen.\u00a0 This makes sharing data easy and transparent to end users.\u00a0 (I use the term “end users” here to include system administrators.)<\/p>\n This does not mean that there is no means of sharing storage from a block device, but the arbitration of it cannot be handled by the block storage device itself.\u00a0 Block storage devices are be made “shareable” by using what is known as a clustered file system.\u00a0 <\/em>These types of file systems originated back when server clusters shared storage resources by having two servers attached with a SCSI controller on either end of a single SCSI cable and having the shared drives attached in the middle of the cable.\u00a0 The only means by which the servers could communicate was through the file system itself and so special clustered file systems were developed that allowed there to be communications between the devices, alerting each to changes made by the other, through the file system itself.\u00a0 This actually works surprisingly well but clustered file systems are relatively uncommon with Red Hat’s GFS and Oracle’s OCFS being some of the best well known in the traditional server world and VMWare’s much newer VMFS having become extremely well known through its use for virtualization storage.\u00a0 Normal users, including system administrators, may not have access to clustered file systems or may have needs that do not allow their use.\u00a0 Of important note is also that the arbitration is handled through trust, not through enforcement, like with a file storage device.\u00a0 With a file storage device, the device itself handles the access arbitration and there is no way around it.\u00a0 With block storage devices using a clustered file system, any device that attaches to the storage can ignore the clustered file system and simply bypass the passive arbitration – this is so simple that it would normally happen accidentally.\u00a0 It can happen when mounting the filesystem and specifying the wrong file system type or through a drive misbehaving or any malicious action.\u00a0 So access security is critical at the network level to protect block level storage.<\/p>\n The underlying concept being exposed here is that block storage devices are dumb devices (think glorified disk drive) and file storage devices are smart devices (think traditional server.)\u00a0 File storage devices must contain a full working “computer” with CPU, memory, storage, filesystem and networking.\u00a0 Block storage devices may contain these things but need not.\u00a0 At their simplest, block storage devices can be nothing more than a disk drive with a USB or Ethernet adapter attached to them.\u00a0 It is actually not uncommon for them to be nothing more than a RAID controller plus Ethernet or Fiber Channel adapters to be attached.<\/p>\n In both cases, block storage device and file storage devices, we can scale down to trivially simple devices or can scale up to massive “mainframe class” ultra-high-availability systems.\u00a0 Both can be either fast or slow.\u00a0 One is not better or worse, one is not higher or lower, one is not more or less enterprise – they are different and serve generally different purposes.\u00a0 And there are advanced features that either may or may not contain.\u00a0 The challenge comes in knowing which is right for which job.<\/p>\n I like to think of block storage protocols as being a “standard out” stream, much like on a command line.\u00a0 So the base level of any storage “pipeline” is always a block device and numerous block devices or transformations can exist with each being piped one to another as long as the output remains a block storage protocol.\u00a0 We only terminate the chain when we apply a file system.\u00a0\u00a0 In this way hardware RAID, network RAID, logical volume management, etc. can be applied in multiple combinations as needed.\u00a0 Block storage is truly not just blocks of data but building blocks of storage systems.<\/p>\n One point that is very interesting is that since block storage devices can be chained and since network storage devices must accept block storage as their “input” it is actually quite common for a block storage device (SAN) to be used as the backing storage for a file storage device (NAS), especially in high end systems.\u00a0 They can coexist within a single chassis or they can work cooperatively on the network.<\/p>\n","protected":false},"excerpt":{"rendered":" One of the greatest confusions that I have seen in recent years is that between NAS and SAN.\u00a0 Understanding what each is will go a long way towards understanding where they are useful and appropriate. Our first task is to strip away the marketing terms and move on to technical ones.\u00a0 NAS stands for Network … Continue reading Comparing SAN and NAS<\/span>