iSCSI's Effect on the Eternal NAS vs. SAN Debate

Monday May 5th 2003 by Tom Clark

iSCSI's Effect on the Eternal NAS vs. SAN Debate

A few years ago, it was common to see articles in the trade press hotly debating the respective merits of network-attached storage (NAS) and storage area networks (SANs). SANs were denounced as being too difficult to deploy and manage, according to NAS zealots, while NAS was condemned as being too slow and unscalable, according to the SAN fundamentalists. Over time, however, the NAS/SAN jihad abated, as both NAS and SAN vendors realized that each technology has its place and that, besides, both NAS and SAN vendors were having considerable success in the market.

The advent of iSCSI is now changing the terms of the NAS versus SAN debate. Like its Fibre Channel predecessor, iSCSI offers a new means to access storage over a network. Unlike Fibre Channel, iSCSI and NAS operate over the same type of network and so would appear to compete for the same storage market. The response of the NAS and SAN vendors has been to simply provide both NAS and iSCSI as customer options. Network Appliance, for example, is supporting iSCSI on its NAS platform, while vendors such as EMC and HDS are providing NAS processors to front-end their large SAN storage arrays. These products give customers greater flexibility but do not address the basic conundrum of when to use NAS and when to use SAN.

The File (NAS) vs. Block (SAN) Storage Dilemma

Technically speaking, a network-attached storage device is not really "storage attached to a network." The SCSI block I/O characteristic of storage devices occurs between the NAS processor and its attached storage arrays, not between the storage disks and the user network. The network-attached portion of a NAS device is therefore in reality network-attached file serving. When a NAS processor receives a request for a file, the processor must query the file system's metadata for that file, identify the data blocks on disk that compose the file, reassemble the appropriate data blocks in the proper sequence, and wrap the file content in TCP/IP for transmission onto the network. The heavy lifting of writing and reading blocks of data to disk, therefore, occurs behind the scenes, not on the network.

What differentiates a NAS device from a common file server is that the file server operating system has been stripped of superfluous functions and optimized for sending and receiving files via IP protocols such as NFS (network file system) or CIFS (common internet file system). The operating system may be a streamlined version of Unix or, as with Microsoft's new NAS initiative, a streamlined version of Windows. In either case, the NAS processor serves files onto the network to clients, as with traditional file servers, while performing its block SCSI I/O on the back end.

In contrast, SAN technology -- whether Fibre Channel or iSCSI -- serves block I/O directly onto a network infrastructure. Block data transfer over a SAN has an inherent performance advantage, as affirmed by the fact that vendors such as Network Appliance use SAN-attached disks for mass storage. Gigabit transport of data blocks over a SAN enhances throughput and enables the NAS processor to more quickly retrieve the raw material for file assembly/disassembly from blocks. The performance of NAS is thus enhanced by SAN technology.

Like Fibre Channel, iSCSI is a block storage protocol. Whereas Fibre Channel encapsulates SCSI commands, status, and data in Fibre Channel framing, iSCSI performs the same encapsulation in TCP/IP. In a pristine iSCSI environment, both hosts and storage targets have Ethernet or Gigabit Ethernet interfaces, and the IP network serves as the SAN infrastructure. Today, iSCSI device drivers and iSCSI network adapters provide host connectivity, but the mainstream SAN storage targets are Fibre Channel-attached. This requires a high performance protocol gateway such as the Nishan IP storage switch to bring iSCSI hosts to Fibre Channel targets.

Page 2: Cracking the Storage Conundrum

Cracking the Storage Conundrum

Because iSCSI, like NAS, uses TCP/IP as a transport protocol and Ethernet for the LAN infrastructure, it may appear that NAS and iSCSI are just two ways of performing the same task. In reality, the underlying plumbing is actually immaterial, as NAS and iSCSI each perform unique tasks. The decision to use a NAS solution for file access or an iSCSI solution for direct data block access depends entirely on your specific application requirements.

Some applications, such as database systems and Microsoft Exchange, expect direct access to block storage, and so are not easily supported via NAS. A SQL Server platform, for example, reads and writes database records directly from disk using the SCSI protocol, and so would access storage via DAS, Fibre Channel, or iSCSI. Other applications simply access files through volume managers, and so could go directly to storage (direct-attached or on an IP SAN), or they could retrieve those files via a NAS processor. Print-serving, for example, has moderate performance and capacity requirements, and is often supported on NAS. For these applications, the decision to use file (NAS) or block (iSCSI) access is largely a matter of convenience.

High performance applications like streaming high definition video are better supported by the block transfers characteristic of Fibre Channel SANs, although the performance of both NAS and iSCSI are significantly enhanced by new network adapter cards. Today, Gigabit Ethernet cards with TCP off-load engines (TOEs) greatly accelerate packet processing and reduce CPU overhead for both NAS and iSCSI. In addition, most business applications do not require full wire-speed throughput, so the additional protocol overhead of NAS may have negligible impact on the upper layer application.

Performance, Cost, and Convenience Drive the Equation

Cost and convenience are drivers for moderate performance application needs. Both iSCSI and NAS can be supported with free device drivers on each client, with the acquisition cost determined by the cost of the NAS appliance plus storage vs. the cost of an iSCSI gateway plus Fibre Channel storage (today) or iSCSI storage (tomorrow). For customers who have already invested in SAN-attached storage, however, iSCSI is a more economical means of bringing additional workstations or servers into consolidated storage and leveraging existing data replication or tape backup processes.

Because NAS uses common file system protocols such as NFS and CIFS, it is better suited for cross-platform support for Windows, Solaris, Unix, and other operating systems. An engineering department, for example, may wish to share files between both Windows and Unix-based workstations. With NFS or CIFS client software loaded on each workstation, any user can access a shared NAS resource.

This is less easily accomplished in SAN (whether Fibre Channel or iSCSI) environments, although storage vendors may partition large storage arrays for resource sharing between heterogeneous operating systems. Typically, the partitions are segregated so that one operating system (e.g. Windows) cannot access the partition of another (e.g. Solaris). For moderate-performance heterogeneous departments, NAS is a more easily deployed and supported solution.

Given comparable performance requirements, either NAS or iSCSI may be used for many storage applications with equal benefit. Although NAS invariably imposes higher protocol overhead, you may see no practical effect on your application, particularly if TOE-enabled adapter cards are used. If you have already implemented a SAN, however, iSCSI offers a convenient means to bring more server assets into storage consolidation, while still leveraging your mainstream IP network infrastructure. With currently available products, storage administrators can create flexible solutions while avoiding the marketing-inspired, quasi-religious disputes of NAS versus SANs.

Tom Clark
Director of Technical Marketing, Nishan Systems
Author: Designing Storage Area Networks Second Edition (2003) (available at, IP SANs (2002) (also available at

» See All Articles by Columnist Tom Clark

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved