iSCSI's Effect on the Eternal NAS vs. SAN Debate Page 2
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.