NAS, SAN, and SMB

One bad thing about IT is that we love our lettered acronyms for all things tech – IT, AD, DC, NAS, SAN, iSCSI, FCoE, SATA, SAS – it goes on and on and on.  We literally swim in an alphabet soup of acronyms which can be confusing enough for us techies and totally incomprehensible to the average business person.

I’m not going to try to unravel the mysteries of all the acronyms in this post; instead I’m going to look at just two – NAS and SAN – that represent two important ways to provide gobs of storage to your storage-hungry servers and users.

It wasn’t so long ago that both NAS and SAN technologies were out of the reach of the typical SMB.  NAS and SAN were technologies firmly stuck in the enterprise space due to cost and complexity.  Thankfully, that has all changed and SMB’s can benefit from the technologies their larger brethren have been using for years.

So, what do the acronyms NAS and SAN stand for?  NAS is short for Network Attached Storage while SAN is short for Storage Area Network.  And, yes, they do sound kind of similar.

NAS is generally “formatted” storage that is available directly to client machines as shared storage over a network connection.  In the Windows world this means it is available as a Windows share – a mapped drive or a share accessed via a UNC like \sharenamedirectory.  The NAS device itself may be running just about any OS internally but it serves up the shared storage through standard protocols that are used by Windows (SMB, CIFS) or Linux (NFS).  Available NAS devices range from small single-drive units through to the very large devices used in data centres.  Examples of devices used in the SMB space are the devices made by companies like QNAP, Synology and Netgear.  NetApp is the perfect example of a supplier of large-scale NAS devices.

SAN is generally “block” storage that provides “pools” of storage to servers, and sometimes client machines, over specialized networks and network protocols.  Many SAN’s use fibre-optic connections and “fibre channel protocols” while others use copper networking (Ethernet) and iSCSI protocols. In either case the storage that is served up is usually seen by the client system as a raw “drive” which needs to be formatted and managed like any other hard drive.  EMC, Hitachi, IBM, HP and Dell all produce SAN’s (and NAS devices too, for that matter).  As a general rule, SAN’s typically require a “private” network and, in the case of fibre connected SAN’s, fairly expensive switching to provide the necessary connections back to the systems that consume the storage.

So, now that the differences between NAS and SAN are explained, the question becomes “why would a SMB need or use one”?  Good question.

NAS and SAN storage expands the options available for providing accessible storage, for  backup and recovery, possibly saves on licensing costs (think Windows Server licensing and CAL’s), and provides the enabling technology foundation for some of the most advanced features when working with virtualization. 

Taking the last point first; NAS/SAN helps make virtualization really pay back on the investment.  When virtual machines (VM’s) “live” on a NAS or a SAN the hard link back to a single physical server is removed.  This means that multiple physical virtualization hosts connected to a NAS/SAN can host the VM so the VM can be brought up on any of the hosts merely by having the host “point” at the NAS/SAN.  A critical VM can, therefore, can be kept available by simply moving between hosts and, in fact, this is what tools from VMware and Citrix do (eg vMotion).  Back at itgroove we have a small Dell SAN and a three server VMware ESXi environment.  All of our Windows Servers are virtual and all live on the SAN.  We move the VM’s around our three physical servers, as required, in order to balance the load and keep critical VM’s running when maintenance has to be performed on a physical server.

Backup and recovery is another big area of possibilities.  Because NAS/SAN devices are NOT servers, there are many different technologies and applications available to backup/recover data that run independently of the servers (Windows, Linux or otherwise) that access the NAS/SAN storage.  These technologies can give you an extra layer of protection against data loss that “simple” server backup cannot.  For smaller environments (and I count our environment at itgroove as one of those) smaller NAS devices can function as an integral part of an overall backup strategy.  We have had great success using QNAP dual-drive NAS devices as a media target for our backup application; backup copies out to the share on the QNAP on a nighty basis.  Then, once per week, we pull one of the drives one the QNAP and replace it with another, the pulled drive goes offsite and the QNAP rebuilds the RAID1 mirror onto the replaced drive. The QNAP devices also offer remote replication tools and we have a customer that runs dual QNAPS with one immediately replicating new or updated data to the other.

So, there you have NAS and SAN in a nutshell.  There are many, many resources on the ‘Net regarding these technologies and all the vendors mentioned have lots of useful information available.