New Twist on an Old Idea

By Jim McKinstry

(Back to article)

Corporate open-systems storage environments in the early ‘90s were dominated by internal storage (disks enclosed within a server) or small SCSI-attached DAS (direct attached storage) devices. Over time, companies started deploying NAS (network attached storage) and SAN (storage area network) solutions to utilize storage more efficiently.

Today, there is yet another way to deploy storage to workstations and servers: iSCSI.

What is iSCSI?

SCSI (small computer systems interface) has been used by computers to talk to storage for twenty years now with the first SCSI standard (SCSI-1) being approved in 1986. The current standard is SCSI-3.

The iSCSI protocol, RFC 3720, was approved in early 2003. iSCSI is the protocol that describes how to transport SCSI data over a TCP/IP network. This means that SCSI commands are encapsulated in the payload of the TCP/IP packets. Each packet on a Gig-E network (an Ethernet network which supports a bandwidth of 1000Mb/sec) has a default payload of 1500 bytes and, with Jumbo Packets enabled, can support 9000 bytes.

Since most file systems default to 4KB, either packet size can efficiently transport the data. By utilizing the existing network infrastructure, companies can use iSCSI to inexpensively deploy centralized storage to the most remote areas of their LANs.

Why not NAS?

NAS is good for environments that need to share data between users or servers and have applications that perform adequately with file-level access, TCP/IP reliability and performance. iSCSI is much more like a SAN than a NAS and is sometimes called IP-SAN.

iSCSI accesses data at the block level like a Fibre Channel (FC) SAN and can therefore use the TCP/IP network much more efficiently than NAS, which access data at a file level.

There is far less overhead associated with iSCSI than NAS so it is typically faster than NAS, especially for random IO (e.g., databases, MS Exchange, etc.). Databases can work with NAS devices but they will usually work better, and take less bandwidth, with an iSCSI implementation.

So, if you don’t need to share the data and don’t need the performance and reliability of a FC SAN, then iSCSI is the way to go.

Enterprise-class Features

iSCSI vendors, in a very short period of time, have developed very robust solutions. Like SAN and NAS devices, many iSCSI devices provide snapshots, volume copy and replication solutions. Snapshots can be used for “zero-impact” backups; volume copies can be used for test, development, etc. and replication can be used for disaster recovery.

Another very important feature is the ability to boot from an iSCSI device. This allows IT departments to deploy diskless workstations to each desk. Larger companies (hundreds or thousands of desktop computers) will be able to save large amounts of money on workstations, power, cooling, etc. just by eliminating a disk from each workstation.


iSCSI solutions are typically implemented in one of two ways:

Storage. One way to implement an iSCSI solution is to integrate the iSCSI protocol directly in a disk subsystem. Some arrays are iSCSI only while others can run as NAS and/or iSCSI. Still other arrays have iSCSI and FC capabilities (or iSCSI, FC and NAS).

These solutions work just fine but may not be ideal for all environments. For example, a storage device supporting a large Oracle installation and a good-sized Microsoft Exchange server over FC probably should not be serving out iSCSI LUNs as well; the iSCSI devices would be robbing horsepower from the FC devices.

Also, a device that supports multiple protocols may be a lot more difficult to replace at the end of a lease. A FC device with five or 10 devices accessing it can be difficult to replace; add another 50, 100 or more iSCSI devices to that and the logistics of replacing it become astronomical.

It also may not make sense to have a dedicated iSCSI device in the datacenter. It’s just another device to manage and may have limited scalability and performance. A dedicated iSCSI device does easily scale beyond the capacity and performance characteristics of a single or redundant pair of RAID controllers.

Appliance. Like virtual tape libraries, NAS and many other storage-based solutions, iSCSI can be implemented as an appliance in front of a SAN. An iSCSI appliance is a small server or blade that takes LUNs from the SAN and reallocates them out to the LAN as iSCSI LUNs.

The iSCSI appliance handles all of the overhead associated with TCP/IP whereas the storage-based solution leaves that overhead on the storage device itself. These appliances can be standalone or clustered for high-availability. They also manage all of the advanced features (e.g., volume copy, snapshot and replication).

By front-ending the SAN, iSCSI appliances can utilize older storage that is “retired” from production by redeploying it to the appliance, extending the useful life of the retired asset. A single 4Gb FC port could theoretically handle the load of three-to-four Gig-E ports running at full speed.

Even the best SAN implementation has some storage that is not being utilized. That unused storage can be mapped to the iSCSI appliance and served out over the LAN, increasing the efficiency and ROI of the SAN.

Using an iSCSI appliance also makes it easier to replace the backend storage devices. The appliances can either mirror volumes from a new array with the old backend array or replicate to another appliance which is using the new storage. When the mirror or replication is synchronized, the old storage can be removed; all this occurs without the application servers even knowing.

Where does it fit?

iSCSI will almost certainly never replace SAN or NAS solutions. It is meant to enhance an organization’s overall storage solution not replace any one piece. It won’t replace NAS because iSCSI doesn’t have native file-sharing capabilities and it won’t replace FC because iSCSI doesn’t have the same performance characteristics. iSCSI fits for servers that need block access to data but don’t need the reliability, performance or additional cost of SAN storage.

With Gig-E networks and TOE (TCP offload engine) cards in the servers, iSCSI can perform at speeds similar to 1Gb FC, which is perfectly acceptable for many applications.

There appears to be no slowdown in the growing storage needs within companies. As storage needs grow, the more complex and expensive solutions can become.

Building a large, fast, stable SAN and adding NAS and iSCSI appliances to the SAN is an ideal way to design a storage solution that meets the needs of all the users in the corporation. NAS addresses the shared file needs, SAN addresses the high-performance, high-reliability needs and iSCSI addresses everything in between.

Jim McKinstry is senior systems engineer with LSI Logic, Engenio Storage Group, an OEM of storage solutions for IBM, TeraData, Sun Microsystems, SGI and others.