Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Storage Pipeline: 20 Questions: Page 24 of 27

The second problem with "universal SAN" thinking is that different applications require different "drinks" of storage. Applications need different RAID levels, different physical disposition of their blocks and support for different file-system semantics to meet the requirements of servers requesting data access. There's no one-size-fits-all storage infrastructure, not with a stack of additional software that operates more or less independently of the storage interconnect. Bottom line: For some applications, DAS is a great choice, just as NAS and SAN may be right for others.

Before SMBs warm up to fabrics, there must be a killer app. With early FC fabric deployments in large enterprises, the SAN was viewed as a mechanism for connecting many distributed servers to a high-end tape library subsystem. Only recently has the business case shifted to one of support for storage scaling behind capacity-hungry databases. But most SMBs have neither large-scale DBs nor high-end libraries. So it seemed fair to ask the vendors in our survey to identify the killer app for iSCSI. Most claimed that iSCSI's key value was as an interconnect to a core FC fabric. While this might be true in the Fortune 500, where an investment has already been made in FC fabrics, it didn't answer our SMB-centric question. So, we'll take a shot.

If you're an SMB stewing over whether iSCSI is right for you, remember first that it's not a mystery. Rather, iSCSI -- or SCSI over Internet Protocol -- is simply a standards-based mapping of the SCSI (Small Computer Systems Interface) protocol to TCP/IP networks. In many ways, it's the same as the mapping of SCSI to FCP (Fibre Channel Protocol), a channel interconnect standard.

Both iSCSI and FCP provide a means for moving SCSI commands and data from an initiator (usually a server) to a target (typically a storage device), then returning the requested data or acknowledgment to the initiator. At present, Fibre Channel boasts greater speed, at nearly 4 Gbps; iSCSI can do only about 75 percent of a TCP/IP link's rated speed, or 750 Mbps over a Gigabit Ethernet connection. But for most SMBs, that speed is plenty. Bigger fish to fry include:

Management Issues: Management is indeed one place where iSCSI and FCP differ. With a Fibre Channel fabric, devices are connected via FCP for the exchange of SCSI commands and data. However, management and control of devices in the fabric must be accomplished through an out-of-band (usually Ethernet- or IP-based) network. In fact, in-band management capabilities were deliberately excluded from FCP when it was developed at IBM in the early 1990s. Truth be told, IBM was not looking to create a storage networking protocol at all, but rather a thin-wire serial SCSI interconnect to replace the parallel SCSI bus. Hence, all IP-stacklike functionality was intentionally left out of FCP.
In the absence of in-band management, and given the inelegance and scaling hassles associated with a "dual network" SAN topology, some FC switch vendors have sought to put their own proprietary in-band management into the FC interconnect. This has contributed to the interoperability difficulties that persist between switches from different vendors.
Although still a storage channel protocol at heart -- SCSI itself is a channel protocol -- iSCSI does have the merit of bringing the in-band data path and the out-of-band control path of Fibre Channel into a single wire, and in a standards-based way. This should translate to greater ease of deployment and scaling over time, as well as provide the interoperability between iSCSI components that has always eluded the FC camp.