SAN vs NAS: Spelling out the differences
The order of the letters is important
The names almost give away the difference between network attached storage (NAS) and storage area networks (SANs): you would expect a NAS to consist just of storage and a SAN to be a network, and that is true – up to a point.
Designed to be easy to manage, a NAS is fundamentally a bunch of disks, usually arranged in a Raid and consisting of either SAS (serial attached SCSI) or Sata disks just like the ones in most desktops. Users and servers attach to the NAS primarily using TCP/IP over Ethernet, and the NAS has its own IP address. The primary job of a NAS is to serve files, so most NAS systems offer support for Windows networking, HTTP, plus file systems and protocols such as NFS and Mac AFP.
The key difference is whether you need the top performance and reliability of a SAN
While a SAN deals in blocks of data, a NAS operates at the file level and is accessible to anyone with access rights, so it needs also to manage user privileges, file locking and other security measures. The processing and control of this data is performed in large enterprise systems by a NAS head, physically separated from the storage system.
In contrast, SANs allow multiple servers to share a pool of storage, making it appear to the server as if it were local or directly attached storage, and it cannot be accessed by individual users. A dedicated networking standard, Fibre Channel, has been developed to allow blocks to be moved between servers and storage at high speed. It uses dedicated switches and a fibre-based cabling system which separates it from the day-to-day traffic traversing the busy enterprise network, while the well-established SCSI protocol enables communication between the servers’ host bus adaptors and the disk system.
The SAN’s storage usually consists of several large arrays of high-speed SAS disks spinning at up to 15,000 rpm, although solid-state disks are used in situations where performance or energy saving are priorities.
SANs are used for mission-critical data such as big databases, and reliability and performance are key. SANs need to be fast and transparent to the operating system even though the data may travel some distance from the server.
The development of SANs was in part a solution to the problem of slow access to network-attached storage. However, with faster 10Gb Ethernet becoming a standard in the datacentre, we are seeing more convergence between SAN and NAS. Most vendors are offering combined storage systems, available either via block access over Fibre Channel or using file-level access, a trend that is likely to accelerate as 40Gb and 100Gb Ethernet enter the mainstream. Fibre Channel over Ethernet looks set to become the de facto standard for storage over the next decade.
Convergence offers a big advantage if you are managing datacentre storage because you will no longer need to manage, back up and balance data across two separate storage systems. However, if you need to choose between SAN and NAS, the key difference to focus on is whether or not you need the top performance and reliability of a SAN and are prepared to pay the premium. If not, you need a NAS. ®
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
COMMENTS
Tired of these NAS vs SAN articles
Pretty much the ONLY question that should be on anyone's mind when asked to choose between these two techs is "What's my I/O profile?". And if you can't answer this question, you need to ask someone who can.
A block device is much, much more efficient than a NAS when doing block-level operations. These are usually high transaction volume database, streaming and VM applications, all of which require high frequencies of small reads and writes that you'd get writing to a local HDD. If these frequencies are especially high, or you have more than a small number of clients that need this sort of I/O profile, you need a SAN, because a NAS usually won't keep up without a hefty amount of cache RAM to buffer the transaction volume.
As for iSCSI, it's a limited technology because of TCP/IP latency. There are I/O profiles where a 10Gb iSCSI connection will be much, much slower than 2Gb fibre, or channel bonded FCoE. But there are other profiles that suit it quite well, because it's often much faster than SMB/NFS with the right hardware, you're not beholden to any particular filesystem, and you can have real-time, high availability replication if your network infrastructure is designed properly.
As for the author's seemingly key 'fact' about SANs being inherently more reliable: this isn't true. They're inherently more corruptible from client failure than NAS because the client can disconnect mid-transaction, without indicating to the SAN that things have been left in an unfinished state. You can push the responsibility of this to the filesystem, but then that usually precludes using a heterogeneous mix of clients.
Buh?
The article waffles around the subject and fails to point out the one fundamental distinguishing feature between SAN and NAS.
NAS exports a network file system, typically via NFS or CIFS.
SAN exports block devices upon which a standard (local or cluster) file system can be created.
This is the beginning and the end of the distinction between them.
Try working on a proper SAN
"Every SAN I've managed has had issues where it would break it's RAID configuration every 6 months due to the fragility of SAN network communication, requiring extensive rebuilds."
I'm going to make a guess that you've never worked on a full-scale enterprise SAN environment as the above is twaddle. Whoever was buying, configuring or supporting the kit didn't know what he or she was doing. Anybody who works on large enterprise systems with SANs will know that you need top quality kit, support and fundamentally good design. Do it on the cheap and you'll have a disaster on your hands. However, if you need a rock-solid, highly-peformant high throughput system to support huge databases (10s ot TB) over multiple nodes, then an enterprise FC SAN is what will deliver it. Scale that down, don't include redundant paths, path-balancing software or people who know how to manage the things and you will be in a mess. When you have hundreds of servers all relying on storage from a common set of SAN arrays then they have to be absolutely rock-solid. Quite simply a failure in one of our SAN arrays would stop hundreds of servers dead, either because they rely directly on the array, or on servers that are.
I should also add that NAS is almost equally critical in many data centres. There are many very large apps which rely on NAS just as much as SAN. For instance, put a large Siebel system together with many app servers and the DB will usually be on SAN with other, unstructured data held on on a NAS server. In a large enterprise the NAS has to have similar availability to SAN, although it can't match on throughput or predictable response times.
Also, as somebody has pointed out, the important difference between NAS & SAN is the presentation. NAS presents networked file services, SAN presents devices. Simply with a SAN the file systems are local to the servers, with a NAS the file system is held centrally. Some NAS servers can also offer SAN by presenting devices to servers which are mapped to files on the NAS box, which is convenient for consolidation, but doesn't provide for particularly high throughput.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Cloud based data management
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
