First of all, for those that don't know what the Cisco 5420 does, here is a little primer from Cisco's Web site.
Q. How does iSCSI work?
A. The iSCSI driver in the host intercepts the SCSI commands and transports them to the Cisco SN 5420 using TCP/IP. In the Cisco SN 5420, the SCSI commands are then sent to the storage device over Fibre Channel or SCSI parallel bus. The status, or in the case of a READ [ETG1], the data is then sent to the host as SCSI data over TCP/IP. The net result is that the storage device appears to the operating system (OS) [ETG2] and applications as if it were directly attached.
Q. How is the iSCSI implemented?
A. A host is configured with a Cisco SN 5420 iSCSI driver as one of its device drivers. The driver is configured with an IP address of one or more Cisco SN 5420s. When the driver is started, it queries the Cisco SN 5420s for available iSCSI targets and logical unit numbers (LUNs). The host creates devices in the device table for each of the target/LUN combinations. When the host wishes to communicate with one of the iSCSI targets, it sends commands to the iSCSI target/LUN. The driver wraps the command in a TCP/IP packet and sends it to the Cisco SN 5420. The Cisco SN 5420 unwraps the SCSI command and, based on the configured iSCSI target/LUN <-> FC/SCSI target/LUN mapping, forwards the command to the appropriate device. Returned information follows an inverse path back to the host.
OK, so now we know what it does and how it works... let's talk about the options.
iSCSI is brand new and is being touted as the be-all/end-all of storage networking. The primary benefits are cost savings in infrastructure and talent, as all those networking folks out there already know how to do IP. The other benefit is that iSCSI is "block oriented," meaning applications that are currently being used with traditional SCSI drives do not have to be altered in any way to make use of the technology.
Some of the HBA vendors out there are now shipping iSCSI based adapters where the iSCSI driver (and redirector) are implemented in hardware. This should help speed up access to storage over an iSCSI implementation.
Traditional NAS also has its advantages though. First of all, most NAS vendors provide storage pooling with their solution, which can virtualize back end RAID devices. Then there is snapshots technology for backup, and the best of all, is all you need is the NIC card that is currently in the servers, with no extra drivers or hardware to implement across the enterprise.
NAS, due to its ASYNC nature and file based I/O, is also best for long distance connections, since latency is not as much of an issue. On iSCSI, since the application is using the SCSI protocol, long distance latency may cause timeout issues to the application. (In other words, using the Internet as your backbone may not make sense for block I/O).
If you have the network bandwidth for iSCSI (switched 100 Ethernet or Gigabit Ethernet for best results) then iSCSI may be a very cost effective way to provide block based SCSI I/O to servers via your existing network. Just remember though, that you may still need a SAN to provide the spinning disks for all those servers connecting via iSCSI, and for high performance apps, SAN is the way to go.
This was first published in May 2001