What, When, and Where iSCSI

Advocates of iSCSI represent the protocol as pure SAN: SCSI operated as an application across a true network protocol. They extol the advent of a true SAN that leverages existing protocol services for in- band services such as security (IP has the Ipsec family of protocols) and management (IP offers Simple Network Management Protocol or SNMP). They avoid discussing the vicissitudes of IP networking from the standpoint of storage I/O requirements.

On its face, TCP/IP networking is not terribly efficient. As much as 25 percent of network bandwidth is consumed by protocol overhead. This is one reason why pundits and analysts are fond of linking their prognostications about iSCSI SAN adoption to the evolution of underlying Ethernet protocols. In a word, iSCSI is expected to come into its own in the market once 10-gigabit-per-second gigabit Ethernet (10-GbE) achieves widespread adoption (late 2004 or early 2005, depending on the analyst one reads). Even at 75 percent efficiency, 10-GbE pipes are thought to be adequate to support the throughput and latency requirements of even the most demanding storage application.

Moreover, since 10-GbE switches are expected to be deployed in the " core " (as opposed to the "edge") of enterprise networks ”that is, they will likely be rack-mounted in the company data center ”advocates claim that iSCSI will displace Fibre Channel fabric switches that have already been deployed there. At least, this was Cisco Systems' position in 2000.

As of this writing, a different (and more confusing) set of messages about iSCSI is being heard from the industry. At conferences and trade shows, even frothing-at-the-mouth iSCSI bigots have been ratcheting back the tone and volume of their pitches. Rather than positioning iSCSI as a forklift replacement for legacy fabrics, even Cisco Systems has adopted a conciliatory position: FC fabrics and iSCSI SANs will coexist for the next several years .

This is partly a reflection of the economy. During the current challenging economic period, many vendors have changed their messaging from the more freewheeling "replace every 12 to 18 months to capitalize on technology innovation" to the more conservative "buy and hold for five to seven years to realize strategic value." Intel has backed away from its Infiniband/Virtual Interface Architecture server roadmap, which would have pushed customers to replace their existing Intel servers with a next-generation product, in favor of a strategy predicated on deriving value from existing products over a longer timeframe.

So it is with current messaging around iSCSI. Rather than pressing companies to replace their just-installed FC fabrics, iSCSI SANs are being contextualized alternatively as a mechanism for connecting outlying servers to the core Fibre Channel storage fabric and/or as a "SAN for the rest of us" ”that is, for small and medium- sized companies or for departments or business units within large organizations. As with Intel's VIA server roadmap, the iSCSI roadmap appears to be taking its lead from the economy and conservative purchasing patterns that it encourages.

However, these marketing messages raise a number of questions in the minds of consumers. The first is straightforward enough: Why is the value of iSCSI always discussed in the context of Fibre Channel? Very few FC SANs have ever been deployed. The technology never took hold the way the vendors (and their paid pitchmen within the analyst community) hoped it would. So, why is iSCSI always discussed in the same breath as FC SAN?

In truth, iSCSI is just another way to connect storage with servers for block-level operation. Constantly comparing iSCSI with FC SANs has a limiting effect because it makes people believe that there is only one way to implement the protocol. While iSCSI could be used to build a SAN, it could also be used as a long-distance IP-based storage interconnect, facilitating remote backup or mirroring or SAN interconnection. It could also be used to enable a block channel on a NAS device, encouraging the evolution of a NAS/SAN hybrid.

Moreover, the connections in a SAN are thought to be always on, but iSCSI enables servers and storage devices to interact when necessary, and it doesn't necessitate that an active connection always exist between them. This opens some new possibilities for storage device sharing that do not require the complexity or management hassles of a full-blown SAN.

Another question that deserves critical attention is this: If iSCSI is initially targeted at smaller organizations or departments, what is the "killer application" that will drive its adoption? The bulk of early FC fabric deployments were predicated on a need to share expensive, enterprise-class, tape libraries among multiple storage arrays.

The need for efficient backup resonated with large IT shops , but vendors appear to doubt that iSCSI will play in large corporate data centers in the short term , at least. Even Cisco has backed away from its projection that iSCSI would cause the "SAN-ification" of all the storage in all of the Fortune 500 companies ”in part, because of issues with the performance of the current version of the protocol, and possibly because Cisco now sells both FC and IP switches.

Thus, if iSCSI is targeted to small- and medium-sized IT environments that do not own large tape silos , will backup still be the driving force or "killer app" for its adoption? Until an application is identified that would drive smaller shops away from tenured server-attached and network-attached storage (NAS) configurations, it would seem that vendors might be wasting their time with an iSCSI play.

Other questions around iSCSI go to the core value proposition of protocol, specifically the assertion that provides a more manageable and secure foundation for building SANs. While iSCSI will enable the use of protocols like SNMP and IPSec (standards within the TCP/IP suite) to provide in-band management and security for storage, the question remains whether anyone will actually use these protocols.

During a presentation in Boston, one storage manager observed , "If we had wanted to use SNMP and IPSec, wouldn't we have leveraged them as part of the out-of-band IP network that we already use to manage servers and storage devices in an FC fabric?" The point is well taken. The trade press has carried many articles recently about the reluctance of organizations to implement IPsec, because the protocols impose some significant and labor- intensive administrative requirements, or SNMP, because of the protocol's inherent lack of security. If these protocols are not widely used in safeguarding or managing IP LANs, why would anyone argue that they will add value to IP SANs?

Moreover, despite the claims of vendors that iSCSI SANs are less mysterious than FC fabrics ”that is, that the IP protocols are more familiar than is the Fibre Channel protocol ”more than one storage manager has questioned the meaning of this statement. An attendee at a recent tradeshow wondered aloud , "Wouldn't storage administrators be required to learn Cisco's IOS switch operating system, and does this really impose any less of a learning curve than the need to learn the rarified details of Fibre Channel?"

Another valid and pragmatic question is how vendors will convince their channel partners , resellers, and integrators to sell iSCSI solutions ” especially if FC alternatives will yield a much higher profit margin. While one would like to believe that the intrinsic nobility of resellers and integrators would cause them to sell the solution that best meets client needs, instead of a solution that best lines their own pockets, the proliferation in the field of inadequate solutions based on poor technology suggests that this is not the case. Ultimately, resellers and integrators will decide which technology options are placed in front of their customers. Channel sales organizations (as these groups are sometimes called) have long been identified as the makers and breakers of technology ”particularly in complex sales that require substantial "face time" with customers to conclude.