One bad thing about IT is that we love our lettered acronyms for all things tech \u2013 IT, AD, DC, NAS, SAN, iSCSI, FCoE, SATA, SAS \u2013 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.<\/p>\n
I\u2019m not going to try to unravel the mysteries of all the acronyms in this post; instead I\u2019m going to look at just two \u2013 NAS and SAN \u2013 that represent two important ways to provide gobs of storage to your storage-hungry servers and users.<\/p>\n
It wasn\u2019t 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\u2019s can benefit from the technologies their larger brethren have been using for years.<\/p>\n
So, what do the acronyms NAS and SAN stand for? NAS is short for N<\/strong>etwork A<\/strong>ttached S<\/strong>torage while SAN is short for S<\/strong>torage A<\/strong>rea N<\/strong>etwork. And, yes, they do sound kind of similar.<\/p>\n NAS is generally \u201cformatted\u201d 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 \u2013 a mapped drive or a share accessed via a UNC like \\sharenamedirectory<\/a>. 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<\/a>, Synology<\/a> and Netgear<\/a>. NetApp<\/a> is the perfect example of a supplier of large-scale NAS devices.<\/p>\n SAN is generally \u201cblock\u201d storage that provides \u201cpools\u201d of storage to servers, and sometimes client machines, over specialized networks and network protocols. Many SAN\u2019s use fibre-optic connections and \u201cfibre channel protocols\u201d 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 \u201cdrive\u201d which needs to be formatted and managed like any other hard drive. EMC, Hitachi, IBM, HP and Dell all produce SAN\u2019s (and NAS devices too, for that matter). As a general rule, SAN\u2019s typically require a \u201cprivate\u201d network and, in the case of fibre connected SAN\u2019s, fairly expensive switching to provide the necessary connections back to the systems that consume the storage.<\/p>\n So, now that the differences between NAS and SAN are explained, the question becomes \u201cwhy would a SMB need or use one\u201d? Good question.<\/p>\n 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\u2019s), and provides the enabling technology foundation for some of the most advanced features when working with virtualization. <\/p>\n Taking the last point first; NAS\/SAN helps make virtualization really pay back on the investment. When virtual machines (VM\u2019s) \u201clive\u201d 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 \u201cpoint\u201d 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<\/a> 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\u2019s around our three physical servers, as required, in order to balance the load and keep critical VM\u2019s running when maintenance has to be performed on a physical server.<\/p>\n 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 \u201csimple\u201d 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.<\/p>\n So, there you have NAS and SAN in a nutshell. There are many, many resources on the \u2018Net regarding these technologies and all the vendors mentioned have lots of useful information available. <\/p>\n","protected":false},"excerpt":{"rendered":"