Blog Articles
Read MSP360’s latest news and expert articles about MSP business and technology
iSCSI vs NAS

iSCSI vs NAS: Full Comparison

iSCSI vs NAS: Full Comparison

Choosing between NAS or iSCSI SAN is one of the cornerstones of modern data centers. The times when NAS was ridiculously slow to be used as a backend storage are gone. Now the choice is not so easy, so we are going to explain the main differences between NAS and iSCSI storage.

Table of Contents

    iSCSI and NAS Overview

    The main difference between iSCSI and NAS systems is their storage access architecture. iSCSI is a popular implementation of SAN systems, while NAS is a common approach of connecting storage devices to the user network. In other words, we should not compare NAS and iSCSI directly, so let’s choose one of the NAS implementations - NAS storage over SMB.

    NAS iSCSI scheme

    You can see additional access levels on NAS storage - data sharing software - allowing clients to use NAS as a file and folders “object” storage.

    The typical example of this implementation is Windows Shared Folders based on SMB protocol. It allows you to make local server/PC folders accessible over LAN. So, when we mention NAS - think about it as “NAS using SMB protocol”.

    On the other hand, SAN systems were deployed as a high-performance block-level storage model that presents a storage device on the lowest data level. NAS is an object-level storage that presents ready-to-use files and a folders tree to a client OS.

    Are you tasked with choosing a NAS for your company or your clients? Check out our guide:

    FREE WHITEPAPER
    Guide to Local Backup Storage
    Storage options, steps to select a NAS device, and more
    New call-to-action
    Local Storage Whitepaper icon

    Architecture and Infrastructure Requirements

    Let's highlight the typical use cases for both iSCSI SAN and NAS:

      New call-to-action
    • Thanks to its low data access latency and high performance, SAN is better as a storage backend for server applications, such as database, web server, build server, etc.
    • SAN has built-in high availability features necessary for crucial server apps.
    • NAS is very useful when you need to present a bunch of files to end users. Most of client OSs have built-in NAS access protocols (SMB, NFS, AFS, etc), thus minimizing connectivity efforts.
    • NAS is also a good choice for LAN-distributed storage systems and clients: user files storage, backup repository, etc. You can even access files located in another city. But the support of such flexible access has a drawback - low access latency and limited download speed (SMB barely covers the possibilities of 1Gbps Ethernet) is mostly influenced by the network delivery errors rate.

    To learn more about NAS backup strategies, check out this article:

    Further reading NAS Backup Strategy: Local, Cloud and Hybrid Backup

    That is not a full use-case list since there are a lot of vendor-specific NAS implementations, which allow host server apps data. For example, VMware allows using NAS systems to host a virtual machine's virtual HDD files.

    Both technologies use existing Ethernet networks as a transport layer, and both need additional client-side software to access the data. For example, you can connect the new iSCSI storage to a 1Gbps LAN, install iSCSI initiator software on a PC, and basic SAN storage is ready. But if you plan to use it in a high-loaded production environment, you will face performance and reliability issues.

    NAS is relatively simple to implement since you only need Windows system (or SAMBA-enabled Linux). Almost every desktop OS supports SMB data exchange, and a 1Gbps network is more than enough for nearly all user scenarios. But if using NAS in a large LAN or with heavily-loaded server applications, consider using the separate LAN for better reliability and a modern SMB version for better performance.

    Performance Questions

    When using iSCSI in a corporate environment, it is strongly recommended to use the separate LAN segment for better isolation; use hardware-accelerated network cards for better data exchange performance. You should also buy an iSCSI-enabled storage system or install “iSCSI target software” and carefully configure iSCSI-related hardware and network settings like Flow Control, Jumbo Frames, Spanning Tree, Trunks, etc.

    When it comes to NAS over SMB, two main performance issues arise:

    • Network share the discovery. Poorly configured discovery services will slow down data access and browsing (tens of seconds of seeing nothing in the network share when the service tries to get the content).
    • Protocol-related data transfer issues. Every user operation with data copy is split on a number of commands. Its quantity depends on the SMB version - modern versions are more efficient.

    Microsoft implemented SMB v2 and v3 are for performance server use, so you should ensure that no SMB v1 is involved in performance-demanding data transfers. Latest “v3” version was introduced in Windows 8.

    Moreover, there is a DMA-enabled (direct memory access) option called SMB Direct. It supports RDMA (Remote DMA) network interfaces, thus allowing you to improve throughput and access latency. RDMA also allows you to minimize CPU utilization.

    High Availability

    High Availability (HA) options allow you to continue using the storage system even in case of malfunction. iSCSI has built-in high availability options, such as multipathing and clustering support. Most of HA solutions imply using cluster service (Windows Failover Cluster, for example), thus improving availability on the data access level. One of the key options used for failover - multipathing, that allows you to access a file sharing service or other server app using additional network paths to the iSCSI target.

    On the other hand, NAS with SMB has a feature called SMB Multichannel, allowing you to connect remote shared folders using a few network paths via separate connections. SMB clients can continue working in case one of the file server nodes is interrupted. In this case, you will not only improve storage availability but also increase data throughput (multiply SMB performance by the number of NIC channels).

    You can further improve NAS throughput and simplify data management using the SMB Scale-out feature, available in SMB v3 - all file server nodes are combined to get summarised bandwidth. This feature allows you to scale file servers up with no configuring of multiple volumes, shares, and cluster resources.

    Anyway, iSCSI solutions are typically better for clustering systems because of block-level access required by most of the clusters, and a simpler (thus more reliable and fast) protocol stack.

    Let us summarise the differences between iSCSI and NAS over SMB in the table below:

    iSCSI NAS over SMB
    Data access level Block-level (SCSI commands, data blocks). Object-level (files and folders).
    Directly accessible by clients Need to configure iSCSI software and map it as a device. Just enter the shared folder path as you do it for a website.
    Available using built-in OS tools Typically there is an iSCSI initiator installed for client access, but you need to install an iSCSI target on the storage server to create a data volume. Yes - you can use almost any file browser, including built-in Windows/Linux/Mac.
    Overall performance Depends on LAN infrastructure. It is possible to implement a 10 GbE-based SAN or even higher. Depends on the SMB version used. For a basic v1, it is hard to consume a 1GpE link fully, but SMBv3 allows Multichannel mode, which can multiply overall performance.
    Can be used as a server apps backend Yes, thanks to block-level access using generic SCSI commands. Only for certain server apps (VMware vCenter HA, for example), using SMB v2/3.
    Implementation complexity Production-level implementation requires you to install a special NIC, configure network devices, and install special server software. Careful configuring of built-in server features is enough for effortless access by clients.
    Ready for HA clusters Yes, supported by almost any clustering technology, since it is based on SCSI protocol. Only for certain server cluster technologies that support SMB/NFS storage as a shared volume.

    Summary

    SAN systems (iSCSI) and NAS (SMB) were created for different use cases:

    • It is better to use iSCSI for any application that needs block-level access or strong availability options. But you should also remember about proper iSCSI infrastructure configuration - a simple “just plug into LAN and connect storage” solution works fine only in small or testing environments.
    • NAS is one of the most straightforward ways to share files with end-users. You can even use it for certain server apps if you configure SMB v3 - for example, you can place a backup repository on such share.
    FREE WHITEPAPER
    Guide to Local Backup Storage
    • Main local storage options
    • Checklist on how to choose a NAS device
    • Local backup know-how, and more
    New call-to-action
    Local Storage Whitepaper icon