Storage Pipeline: 20 Questions

Clearly, iSCSI isn't an either-or alternative to Fibre Channel. Most storage vendors agree, calling the technologies complementary and placing iSCSI on the "edge" and FCP in the "core." To hear many tell it, iSCSI will soon provide an inexpensive means to connect outlying servers to Fibre Channel fabrics in the data center. Some even concede that iSCSI will handle the interconnection requirements of SMBs (small and midsize businesses), which rarely have high-performance transaction-processing databases or other bandwidth-intensive applications. We sometimes hear the expression "SAN for the everyman" to express this position, though it's unclear to us why the everyman needs a SAN. For more on that question, see "SMBs and SANs: Where's the Urgency?".

One thing we took away from the vendor responses: Behind the scenes, an interconnect war is being waged. Only a few years ago, a spokesperson for Cisco Systems stood onstage at a technology conference and dismissed the promised speeds and feeds of Fibre Channel as "yesterday's bandwidth tomorrow." The leading proponent of all things IP has since ratcheted back its rhetoric and, with the acquisition of Andiamo Systems in August 2002, is even selling its own line of FC switches. Cisco has shifted its approach from "technology advocacy" to "consumer advocacy"--apparently a realpolitik acknowledgment that 2 percent of companies account for nearly 65 percent of storage purchases, and that you can't sell a port of anything not Fibre Channel to Fortune 500 storage administrators.

It's telling, however, that the technologies being advanced by Cisco in the Fibre Channel market, like VSAN (Virtual SAN), are transferable to iSCSI. We wouldn't be surprised if the company's current FC play is intended to establish its bona fides in storage while funding R&D aimed at what many observers quietly regard as the future of SANs: iSCSI. Rebuffed in its efforts to have VSAN approved as a standard by the overseers of Fibre Channel standards, ANSI's T11 Committee, Cisco went instead to the Internet Engineering Task Force's IP Storage Working Group, which developed iSCSI, to solicit backdoor recognition of VSAN via a standard MIB to be used in conjunction with SNMP-based device management.

It's the Money, Honey

Unlike Fibre Channel, where per-connection prices have been slow to fall, iSCSI can be operated over existing LANs or, if configured as separate networks for security's sake, can be deployed inexpensively thanks to the dramatically falling prices of Gigabit Ethernet switches and NICs. An unmanaged GigE switch can be had for less than $30 per port, compared with FC SAN switches at $450 to $1,000 per port.The key impediment to iSCSI a year ago was the lack of "targets"--storage arrays and tape devices with connections designed to support block access via the protocol. This is changing rapidly with excellent entries from Snap Appliance and others, and a flood of new boxes about to hit the streets from brand-name vendors like EMC and Network Appliance. Most of the gear also leverages S-ATA disks, providing maximum capacity at rock-bottom prices.

Several Fibre Channel vendors have responded to iSCSI's cost advantage with "dumbed-down" HBAs and switches offering less expensive "entry-level" fabrics they claim are comparable in price to iSCSI. And they toss out other considerations, including the greater familiarity with Fibre Channel today, the "inherently superior" security of Fibre Channel over IP and the widespread availability of quality FC targets, as evidence that these are competitive offerings. We'll see.

Below is our brief analysis of the vendor responses to our questionnaire. Keep in mind the different markets served by the respondents and the audiences to which the answers are aimed. You'll find the complete responses here.

Adaptec

Fresh from announcing its acquisition of NAS and iSCSI target array maker Snap Appliance, Adaptec made clear that it's going after iSCSI in a big way. Once the industry leader in parallel SCSI technology, Adaptec was late to take the plunge into Fibre Channel, viewing the technology as transitory. In the late 1990s, it dabbled in, then quickly exited, the FC world, instead pursuing an IP-centric approach to storage networking. We think that had it moved forward with its proprietary UDP-based, rather than TCP-based, implementation of serial SCSI four years ago, Adaptec would own this burgeoning market. However, after deciding to adopt a standards-based approach, the company put aside its EtherStore product and waited for the IETF-sanctioned protocol.Adaptec cites Microsoft's enthusiastic embrace of iSCSI--and its interoperability testing program--as a significant driver, but qualifies its timetable for iSCSI adoption on the basis of Fibre Channel's installed base and iSCSI's inferior speeds and feeds. Interestingly, the vendor refers to the commonly held view of iSCSI performance (75 percent of rated IP network bandwidth) as a myth, and points to both TOEs (TCP Off-load Engines) and increasing processor speeds, as well as the advent of 10-Gigabit Ethernet, as remedies to this purported limitation.

Adaptec, (408) 945-8600. www.adaptec.com

Brocade Communications Systems

Long a driving force in the Fibre Channel community, Brocade submitted a surprisingly inclusionary response to our questionnaire. Only a year ago, we interviewed a Brocade exec who said iSCSI was useful primarily as a technology for attaching "less important" servers to an FC SAN. That's code for, "If the server were important, it would have been connected to the FC SAN from the get-go."

Times have changed. A kinder and gentler Brocade acknowledged that iSCSI and FCP serve different application requirements with different price points, and that both would likely find a home in the market. Hammering the speeds and feeds advantages of FC, Brocade states FCP is achieving four times the performance of iSCSI on Gigabit Ethernet. The company also notes that 10 Gigabit Ethernet, while available, is not widely deployed, then makes the eminently savvy observation that when 10 GigE does become widespread, speed will no longer be the primary issue anyway. We agree--faster processor speeds on servers and improved TOE technology, combined with trunking services in iSCSI, will soon negate FCP's speed advantages.Of particular interest is Brocade's view of interoperability, which the vendor suggests may become as big an issue in the iSCSI world as it has been in the FCP domain; most other respondents disagree, and we stand by our assertion that standards-based interoperability is the only real guarantor of open solutions and a linchpin in avoiding vendor lock-in. Brocade does, however, make a reasonable argument that the iSCSI cost model is off-kilter when you add in the cost for specialized HBAs for SAN-based booting and TOE offload.

Brocade Communications Systems, (408) 333-8000. www.brocade.com

Cisco Systems

Cisco told us at the outset that it doesn't advocate a particular technology, but instead seeks to support whatever the customer wants or needs. It observed that "the importance of interconnect speeds is highly dependent on the applications themselves." Moreover, most Windows-based apps aren't likely to "generate significant and consistent I/O traffic, thus will not require high-speed interconnect." It added that iSCSI may be a good fit for low-cost Windows servers.

A surprise to us was Cisco's recommendation that SAN management be kept out of band--for example, operated across a separate network--even in an iSCSI SAN. No explanation is offered for this guidance, which runs afoul of past assertions made by the company regarding the consolidation of fabric and network functions in an iSCSI SAN.In a shot across Brocade's bow, Cisco rails about FC switch interoperability issues: "There is no technical reason for Fibre Channel not to be as interoperable as iSCSI is, on a protocol and device level. This is the fault of incumbent vendors that view proprietary features and vendor lock-in as business advantages. Customers should demand that vendors dismiss this shortsighted thinking and provide open interoperability among Fibre Channel devices that IP networking users enjoy." We agree but feel obliged to note that Cisco has introduced proprietary technology into its Fibre Channel products as well.

Cisco Systems, (800) 553-6387, (408) 526-4000. www.cisco.com

EMC Corp.

EMC's participation came as a bit of a surprise, given its solid position in the Fibre Channel world. But we reminded ourselves that the IETF working group responsible for iSCSI development has long been chaired by a senior technologist for EMC, David Black.

The vendor's opening remarks echoed those of other respondents with feet in both protocol camps: iSCSI was characterized as an edge technology until other enabling technologies matured and entered the mainstream, including "management systems, configuration automation, security mechanisms and cost-effective 10 Gigabit Ethernet."We realized that EMC, like Cisco, was confusing the distinction between Fibre Channel fabrics as a dual-interconnect topology and iSCSI as a single-interconnect topology, combining an in-band data path and out-of-band control and management path into a single wire. Instead, it took this to mean the difference between a corporate LAN and a storage network, arguing that an iSCSI SAN would likely be set up as a closed network, separate from the corporate LAN. While true, that wasn't the question.

EMC argues that the past four years have seen a significant investment in "mature, robust" FC fabrics that companies will not replace without a compelling reason. And it took issue with our portrayal of SCSI as a channel I/O protocol, stating that it was not a protocol but rather "an architecture and command set" implemented in different ways by different serializations of SCSI. Although this characterization may be correct--we could argue from a technical perspective EMC's use of the term network to describe Fibre Channel fabrics--it didn't address the question we'd asked.

As for standards and persistent interoperability issues, EMC offered that competition from iSCSI would likely force the Fibre Channel guys to get their interoperability act together. The company did seem genuinely excited about the notion of using iSCSI-enabled NAS as a gateway to back-end FC SANs, but it rejected our question about other scaling solutions, like Spectra Logic's new RXT platform, a disk/tape library hybrid. It dismissed the value of the latter on performance grounds and because it would lock consumers into a particular vendor's product. We couldn't help but see the irony here.

EMC Corp., (508) 435-1000. www.emc.com

Hewlett-PackardHP's response was refreshing. The company took the same position as many other vendors regarding the complementary nature of FC and iSCSI, but also provided some common-sense perspectives. For example, HP pointed out that speeds and feeds differences are less important than often suggested. FC fabric bandwidth is rarely utilized fully, and throughput limitations of iSCSI over Gigabit Ethernet can be surmounted by using multiple parallel connections. In addition, it observed that the dual-connection (in-band/out-of-band) issue is specious.

The company did take exception with our characterization of iSCSI product interoperability, saying that it had yet to be demonstrated that iSCSI switches would be any more compatible than FC switches. This was in stark contrast to most other responses, which accepted out-of-the-box compatibility as a given. Other standout points include the observation that the value of purpose-built platforms and point solutions is outweighed by the value of SANs and that, in the long run, IP-based networking will be used to move data from storage devices to users. What's up for discussion are the pauses and detours along the way.

Hewlett-Packard Co., (800) 752-0900. www.hp.com

IBM

In many respects, IBM has led the iSCSI charge. It was first to market with an iSCSI array--and first to withdraw that product, arguably because it was ahead of the iSCSI standard by nearly two years. Julian Satrain, with IBM in Haifa, Israel, is a powerful presence on the IETF's IP Storage Working Group. That said, the vendor makes much the same case as others regarding the complementary fit for iSCSI in a predominantly FC world within the Fortune 500. In fact, its response contains little that one could interpret as enthusiasm for any particular protocol, barring one twist to the mainstream mantra: iSCSI may also play in the realm of clustered computing, especially massively parallel clusters that are the subject of much experimentation at the High Performance Computing Center of the University of New Mexico. IBM contributes significant money to HPCC and sees iSCSI as a low-cost means to separate storage installed in the inexpensive white-box Linux servers from which HPCC routinely constructs supercomputing clusters.IBM, (800) IBM-4YOU. www.ibm.com

Intransa

Another early iSCSI pioneer, Intransa adopts a decidedly evangelical tone regarding iSCSI. In nearly every category of analysis, it places iSCSI on par with or superior to Fibre Channel, debating purported speed advantages and criticizing other limitations of the Fibre Channel fabric. Based on implementations of its own IP5000 iSCSI array, Intransa claims to have delivered every capability attributed to Fibre Channel, but without the FC HBA, switch, controller ... or price tag. Accompanying PowerPoints explain the product's architecture and business case in considerable detail. In reading the response, we got a sense that this vendor is fighting an uphill struggle--not against Fibre Channel, but against a line of reasoning gone mainstream because of its endorsement by players with three letters for a name. Intransa, we feel your pain.

Intransa, (203) 239-6284. www.intransa.com

LSI Logic Corp. LSI Logic views iSCSI as a boon for stranded servers and even as an interconnect for SMB storage, but it adds that the protocol suffers from a lack of bundled storage devices, storage-management software, and HBAs or software initiators. It also underscores a point made by Intransa regarding a key benefit of iSCSI--distance insensitivity--and says an evolving standard for implementing iSCSI over RDMA (iSER) with 10 Gigabit Ethernet will give iSCSI FC-equivalent latency and throughput.

LSI Logic Corp., (866) 574-5741. www.lsilogic.com

McData Corp.

Another key player in the FC fabric world, McData began its response by echoing the mainstream view of iSCSI and its fit within the second storage tier or in the SMB. But before we had a chance to yawn, the vendor provided some interesting numbers: Most SMBs use servers that cost no more than $6,000; and it's difficult to justify spending $1,500 per server for a connection to a Fibre Channel fabric. All this opens the door for iSCSI.

On the subject of speeds and feeds, even more common sense crept into this response. "Speed sells," McData said succinctly, then made a revelation that would have gotten its knuckles rapped by the Fibre Channel Industry Association a year ago: "With current technology, it's possible to run full Gigabit Ethernet bandwidth with iSCSI (Nishan and Alacritech demonstrated this several years ago). For customers with high performance requirements, however, FC at 2 Gbps is the better choice (more ceiling). For moderate-requirement applications, FC is overkill bandwidthwise, and iSCSI is a suitable alternative."We liked McData's response to our question about the purported security advantages of FC over iSCSI, especially the doublespeak about FC security being linked to the lack of familiarity with the protocol among attackers. Its answer: "Some people will try anything to sell their products."

While McData struck us as overly optimistic about Fibre Channel switch interoperability issues having finally been put to rest, we couldn't help admiring its moxie.

McData Corp., (720) 558-8000. www.mcdata.com

Microsoft

Big goings-on at Microsoft around storage these days. Redmond was among the first to release (and distribute for free) a software initiator for iSCSI, breathing new life into a standard that was delayed for two years. Our sense is that Microsoft doesn't particularly care whether iSCSI, FC or EIEIO becomes the dominant interconnect. It does care about making sure that everything is tested and certified to work with its server OS. This approach is certainly contributing value to iSCSI, as Microsoft's Designed for Windows test-qualification program demonstrates. According to its response to our questionnaire, more than 23 storage targets have passed through the program since its inception, ensuring that the arrays and other devices will work with the initiator software and with Microsoft's growing suite of OS storage services, such as Flexible Volume Mounting, VDS (Virtual Disk Service) and Microsoft MPIO (Multipath I/O).The company goes on to say that SANs are necessary in the SMB for the same reasons as they are in the Fortune 500. However, the SMB is looking for less complexity in SAN deployment, which can be met by iSCSI or by a growing number of simplified FC fabric bundles that Redmond is testing in-house. Microsoft's further observations are an interesting read, especially as they pertain to an integrated architecture beginning with the OS. Whatever your opinion of the company, it has clearly thought its iSCSI strategy all the way through.

Microsoft, (800) 426-9400. www.microsoft.com

Network Appliance

It was evident from the first few paragraphs of its response that Network Appliance wants to bring its own kind of wisdom to the iSCSI versus Fibre Channel debate. The company is championing a reworking of the whole server-to-switch-to-storage paradigm by placing an intelligent appliance between the server tier and the back-end SAN. Such a hybrid gateway architecture could provide, on the NAS appliance, a location for storage management, file system support and other control activities.

Network Appliance already supports a block channel in addition to NFS/CIFS connectivity, and it was the first to qualify its storage as a target for Microsoft's initiator. The former was a requirement imposed by Microsoft with the release of Windows 2000 Server: To continue hosting Exchange on its NAS Filers, Network Appliance was obligated to add a block channel. Now, the company is anxious to exploit this technology and produce Filers that can do blocks and files with equal alacrity.Network Appliance, (408) 822-6000. www.netapp.com

Sanrad

Next to McData, the vendor that seemed to have the most fun with our questionnaire was Sanrad. It took singular delight in gainsaying the anti-iSCSI rhetoric promulgated over the past few years by the FC camp. Sanrad makes switches that can support Fibre Channel and iSCSI. It believes that the both technologies are capable of supporting the lion's share of applications in use by businesses today, and that the future for iSCSI is very bright. It even said that we inadvertently gave it an additional sales tool when we pointed out the dual-network topology required by Fibre Channel (we'll be looking for our royalty check.)

The vendor observed that iSCSI should be an open solution in the "pure IP" sense of the expression, and while conceding that some storage vendors are seeking to sell bundled iSCSI per the FC fabric model, the company said it doesn't view this as necessary or desirable.

Sanrad, (510) 521-2424. www.sanrad.comSnap Appliance

At the risk of being criticized for letting a vendor speak its mind twice, we must point out that responses to this questionnaire were received in advance of Adaptec's announcement that it would buy Snap Appliance. From an iSCSI standpoint, this is a marriage made in heaven: A leader in RAID controllers meets a leader in SMB NAS appliances; the offspring will likely be a full range of inexpensive iSCSI-compatible arrays.

Snap Appliance (Adaptec acquisition under review by the Federal Trade Commission, expected to be approved by the time this goes to press), (800) 806-3724, (408) 795-3600. www.snapappliance.com

Spectra Logic Corp.

Spectra Logic's longstanding reputation for its tape library engineering excellence, its footprint in the SMB space and its just-announced RXT library that offers massively scalable disk capacity in addition to its stock-in-trade tape library robotics, put it on the shortlist of vendors to receive our questionnaire.RXT is not marketed as primary storage, but its potential to leverage removable SATA disk and its support for a broad range of connectivity options make it a potential spoiler in the iSCSI versus FC competition. We even slipped a question into the survey that mentioned RXT by name as a low-cost alternative for SMBs considering a SAN. We hope the Spectra Logic folks will keep their sense of humor as they read vendor responses to this question.

For its part, Spectra Logic didn't represent the RXT as a "SAN killer"; in fact, it doesn't market the RXT as primary storage at all. Instead, it used its insights into the SMB market to reinforce the logic of the iSCSI value proposition.

Spectra Logic, (800) 833-1132, (303) 449-6400. www.spectralogic.com

Jon William Toigo is a CEO of storage consultancy Toigo Partners International, founder and chairman of the Data Management Institute, and author of 13 books. Write to him at [email protected].

We composed 20 questions designed to ferret out how storage vendors really feel about iSCSI. Fourteen vendors responded, and as you might expect, their stances varied dramatically based on their respective Fibre Channel market shares. But one thing came through crystal clear: iSCSI isn't going away, and it won't be marginalized. Whether it falls prey to the kinds of interoperability problems that plague Fibre Channel users (and swell FC vendor coffers) remains to be seen. If iSCSI is in your future, or if you just have a penchant for standards-based technologies, these responses are required reading.In "20 Questions," you'll find our analysis of iSCSI's future and synopses of the vendor responses. View the complete list of questions here; full vendor questionnaire responses can be found here.

1. In its early development years, iSCSI had several prominent champions within the vendor community, including IBM and Cisco Systems. The early position of iSCSI advocates was that it would replace Fibre Channel as an interconnect for building SANs. With the delays in standards development, the party line seemed to change: FC would be used to build "core" fabrics, while iSCSI would be used to connect outlying servers to FC fabrics. What is your position on the technical fit for iSCSI?

2. As an IP-based protocol, iSCSI is limited in terms of speeds to available bandwidth less overhead, which is generally interpreted to mean that the technology is capable of delivering roughly 75 percent of the rated speed of the TCP/IP network pipe in megabits or gigabits per second. FC advocates have leveraged this as a major differentiator between FCP and iSCSI. How meaningful is this speed difference today? How meaningful will it be next year with the introduction of 10-Gbps IP nets?

3. Related to the above, how important is interconnect speed to applications? Haven't we made do with much slower storage interconnects in the recent past?

4. Both FC fabrics and iSCSI SANs utilize IP-based applications for management. In the case of iSCSI, management (or control path) is handled in the same network pipe as data and SCSI command traffic. In FCP, the control path and data path use different wires. From the standpoint of scaling, simplified infrastructure and design elegance, iSCSI seems to have an advantage over Fibre Channel's "dual network" design. What do you think?5. Both iSCSI and Fibre Channel use a serialization of SCSI, a channel protocol for storage I/O. The key technical difference is the transport used by each interconnect (TCP for iSCSI, FCP for FC fabrics). If the two are more similar than dissimilar, why should a company field a separate channel interconnect rather than use existing investments in networks to interconnect storage and servers?

6. FC SANs are increasingly seen behind NAS heads, which are said to act as gateways to SANs and provide hosting for SAN management utilities. Taking this design choice to the next level, wouldn't it make sense for NAS gateways to support both NFS/CIFS and iSCSI on the front end in order to aggregate storage traffic?

7. ISCSI standards do not seem to have been "held hostage" to proprietary vendor interests the way FCP standards have been at ANSI (it is an established fact that vendors can develop FC switches that fully comply with ANSI standards, yet fail to be compatible with one another). From the consumer's perspective, isn't it smarter to go with iSCSI-based technologies because of product interoperability?

8. At one point, vendors touted iSCSI as the foundational technology for building "SANs for the rest of us""that is, companies that are not necessarily Fortune 500 status. Do you embrace this view? And if so:

9. What has happened to TOE (TCP Off-load Engine) technology, once touted as a prerequisite for iSCSI SANs? Was it simply hype intended to keep HBA vendors from losing market share to vendors of simple NICs in an iSCSI world? Or has TOE development proved more daunting than originally thought? Why aren't we hearing more about TOE?

10. FC fabric advocates claim that FC fabrics are more secure than iSCSI SANs. What do you think?

11. Microsoft's iSCSI initiator seems to be winning mind share among vendors (Cisco recently opted to use the Microsoft initiator in place of its own in Windows shops). Do you support the Microsoft iSCSI initiator with your products? Does a target device also need to utilize Microsoft target definitions to work with a Microsoft initiator? Microsoft says it does, some target vendors say it doesn't.

12. Some vendors seem to be suggesting that Fibre Channel is superior to iSCSI because of its end-to-end support of "native Fibre Channel drives." Is there such a thing as a "native Fibre Channel drive," or are we really talking about SCSI drives with integral Fibre Channel-to-SCSI bridges in the electronics of the controller or disk?

13. Fibre Channel fabrics do not seem to respond to Metcalfe's law of networks, which states that as more nodes are deployed, the value of a network should increase and the cost per node should decrease. Fibre Channel fabrics seem, in fact, to become more difficult to manage as they scale, in many cases eliminating many of the value gains promised by vendors; in general, they remain the most expensive platform for data storage. FC fabric per-port costs have been extremely slow to decline.By contrast, per-port costs of Gigabit Ethernet switches and GigE NICs have fallen dramatically in only a two- to three-year time frame. 10-Gigabit Ethernet is expected to follow this pattern as well. So from a cost standpoint, doesn't iSCSI have a better story to tell price-sensitive consumers than Fibre Channel?

14. The industry has given mixed messages about the fit for iSCSI: Is it a data center technology because that is where the big switches are located, or is it an "edge technology" because workgroups and departments do not require the speeds and feeds of data centers? What is your take?15. With SNMP, DHCP and other established protocols in the IP world, it would seem that iSCSI will hit the ground running with services that were missing altogether from FCP. Is this an advantage?

16. Some vendors are "dumbing down" their Fibre Channel products to facilitate their deployment in SMBs. Is this your strategy, and what do you see as the benefits and drawbacks of such an effort?

17. Does iSCSI offer anything that FC fabrics do not to facilitate storage virtualization?

18. Describe the products your company is developing that support iSCSI.

19. Compare key pricing and capability differences for your iSCSI solutions versus comparable FC solutions.20. What, if anything, does iSCSI contribute to data protection in a networked storage world?

We've been pondering a question that none of the vendors we queried is talking about: Do SMBs (small and midsize businesses) typically need SANs at all? The subtle message emanating from the Fibre Channel community and counterparts in the iSCSI world is that storage fabric topologies are the universal answer to DAS (direct-attached storage) issues.

There are two problems with this thinking.

First, none of the storage topologies in use today -- whether DAS, NAS (network-attached storage) or SANs -- are, in fact, truly networked storage. Why? The best definition of a network we have right now is the OSI (Open Systems Interconnection) model, which defines layers of functionality in a full network protocol. Not even TCP/IP, which adheres to this model more closely than Fibre Channel, complies with it fully. A truly networked storage topology would comprise an any-to-any configuration of nodes communicating on a peer basis with no single point of management -- a lot like the Internet.Instead, current storage topologies are all forms of direct-attached storage: DAS is the direct attachment of storage to server, NAS is a thin-server OS bolted to an array, and SANs are switched server-attached storage. In truth, iSCSI doesn't create a storage network either; it's a channel protocol operated over a network interface. But iSCSI moves us closer to networked storage by using TCP/IP as a transport.

It's a Zen riddle, really: All storage is networked by virtue of the fact that applications access storage from servers attached to a network, the LAN. Yet no storage is networked nowadays because it all remains direct-attached. You figure it out, Grasshopper.

That said, we find it curious that over the past five years, DAS has become the whipping boy of storage vendors. To be sure, the direct attachment of storage arrays to servers has its foibles, including data-accessibility limitations, impediments to virtualization and management, and a disruptive scaling model. Fabrics address these problems, in theory at least, by breaking the hardwired storage-server relationship and creating an infrastructure that can deliver "a drink of storage" to any application that needs it. We say "in theory" because the market-share leaders in the FC SAN world today recommend that "zones" (switch-software-based aggregations of servers and storage targets) be defined on a single initiator (server)/single target (array) basis. This once again establishes a one-to-one relationship between servers and arrays, which, while perhaps making sense from a performance perspective, defeats the purpose.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.Interoperability: FC vendors insist that Fibre Channel's superior speeds outweigh its faults. Moreover, they say steady improvements are being made in device interoperability. It's difficult to gauge the veracity of such claims, however.

Following a "plugfest" at the University of New Hampshire in June of last year, more than 100 vendors issued press releases heralding major improvements in interoperability. A few months later, after the Fall Storage Networking World event in Orlando, Fla., the wire services were again cluttered with press releases touting improvements in management and interoperability. In both cases, engineers working behind the scenes in the show labs had very different interoperability stories to tell -- off the record, of course. There's a reason why nearly all FC fabrics deployed today limit their components to the products of a single vendor and its posse.

In contrast, iSCSI will support virtually any hardware that will work with free, standards-based initiator software. No muss, no fuss. This leads us to another key selling point of iSCSI: It's cheap.

Cost Comparisons: Although iSCSI SANs may use specialized HBAs that off-load TCP stack processing from servers to improve performance, such products are not technically necessary. Because iSCSI is a TCP/IP protocol, you can set up an iSCSI SAN with just standard NICs -- and we have. Of course, as Sanrad says in our survey, to optimize performance you may want to use an iSCSI HBA, which is simply a NIC with TCP off-loading and other features that reduce server or storage-array loading from stack processing. Nice to have, but not required.

Moreover, no special support is required from switches to enable iSCSI traffic. While some switch products are appearing in the market with special value-add features, like better traffic management and prioritization for iSCSI traffic, these features are optional -- always a consideration for SMBs.