In-Depth
Family Counseling for SCSI
SCSI implementations may be different in terms of the way data packages flow, but all are members of the same family. Arguments over the superiority of any implementation are heated.
Police officers will tell you that the scariest calls they ever need to make are domestic disputes—those involving arguments and fights between family members. The reason is simple: family members have a tendency to behave more unpredictably and aggressively toward one another—and toward the officer—than do bank robbers and other types of perpetrators.
The same apparently holds true for vendors of products based on various flavors of the Small Computer Systems Interface (SCSI). SCSI is the language on which most enterprise storage today is based. There is ATA out there, of course, and Serial ATA (S-ATA) is showing some momentum, but SCSI is the dominant interconnect language between servers and storage arrays.
The traditional implementation of SCSI is the parallel SCSI bus, but the industry is working furiously to upgrade this to a more elegant Serial Attached SCSI (SAS) implementation. Of course Fibre Channel and iSCSI are both mappings of SCSI to another transport protocol—a serialized channel interconnect in the case of FCP, and a TCP/IP network in the case of iSCSI. Another protocol you might hear about, iFCP, is an encapsulation of Fibre Channel (which uses a serialization of SCSI) so it, too, can use an IP net.
There you have it: the family tree of SCSI. The implementations are different in terms of the way data packages flow from point A to point B, but all are members of the same family. That is probably why the arguments over the superiority of one implementation over another are often so emotional: it’s a family thing.
As a practical matter, storage consumers are less interested in what differentiates the SCSI kinfolk from one another than in what they have in common. We need to have different SCSI kin talk to each other with at least enough civility so that data and instructions reach their targets and responses are returned to initiators.
Sometimes, what is needed is a SCSI family counselor.
Recently, I posed a simple question on the e-mail reflector at the IP Storage Working Group, that arm of the Internet Engineering Task Force (IETF) where much of the development is being done on iSCSI, iFCP, and FCIP (SCSI protocols that use IP) and also a bit on Fibre Channel (because FC guys can’t write management information bases or MIBs nearly as well as IP guys can). My question was, I thought, a non-threatening one, but it opened up some family squabbles that made me happy to have a POP 3 mail server between myself and some respondents.
Specifically, I wanted to know whether some sort of bridge device was available to enable parallel SCSI or Serial Attached SCSI devices to talk to an iSCSI interconnect. In other words, I asked whether anyone had someone come up with a “SCSI family counselor in a box” solution that would let us bridge current infrastructure to newer technologies like iSCSI and SAS? The IP Storage Working Group seemed like a nice family-oriented place to go for the answer.
A barrage of e-mails ensued. Some that I shall not quote here made reference to my mother. Said one fellow, “I didn’t know that they let people like you on the reflector,” whatever that means. Another faceless e-mailer told me, in effect, to shut up: there would never be a need for such functionality because iSCSI was going to rule and all those other weak sister SCSI’s would soon find themselves homeless.
Then came a few useful remarks: first, from ATTO Technologies’ VP of Engineering, David Snell, word was sent of a parallel SCSI-to-iSCSI bridge, first to market, and demonstrated at Storage Networking World in Spring 2003. Dimly recalling the event, the product had a retail price of $4995, about three or four times what most OEMs were looking to pay for such a solution. Checking their web site, I found their iPBridge 2500C/R/D, but no pricing information. There was also no indication that the product could bridge SAS and iSCSI.
Bill Huber, CTO for StoneFly Networks in San Diego, CA, wrote, “The StoneFly Storage concentrator is a bridge. We can connect iSCSI servers (initiators) directly to SCSI and or FC targets. The iSCSI spec fully specifies this behavior. If you want to go the other way [from SCSI to iSCSI], the spec leaves much to be desired. We have bridged existing RAID and Tape systems and it works well. The customer can load a Microsoft software initiator (if it is a Windows shop) and talk to the device as if it was local. The upper layer backup software needs to manage the device sharing—but most of the FC backup packages do this. They cannot tell if the tape is on a FC SAN or an IP SAN.”
Hossein Zia Shakeri, Vice President of Advanced Engineering for SpectraLogic in Boulder, CO, offered, “Just so you know we do have multiple iSCSI - SCSI bridges that are integrated in our libraries. The existing models are CPU offloading.” I expected as much from the company that gave the world one of its first successful implementations of NDMP backup over Gigabit Ethernet.
Finally, Robert “Bob” Griswold chimed in. Bob is Vice President and Chief Technologist for Crossroads Systems in Austin, TX, and offered not only an e-mail, but also a lengthy telephone interview to discuss the question. (The next column will provide a more in-depth report of our discussion with Bob, whose knowledge of, and pedigree in, the industry are wedded to a plain-spoken nature that makes a lot of sense to us.)
He agreed that “There are many working on such products (iSCSI to SCSI, iSCSIto SAS / SATA). Some are farther along than others. Crossroads has demonstrated iSCSI to SCSI and FC at past SNW's, and announced an iSCSI to SCSI product (blade and boxed router) for release at a later date this year. I don't believe that we would consider an iSCSI to SAS/S-ATA a gateway, as much as we would consider it a router, but sometimes the taxonomy doesn't mean anything.”
Bottom line: in the convoluted family tree of SCSI, a few vendors have begun the difficult work of bridging the differences between implementations and enabling multi-interconnect solutions that work. This will become increasingly important as iSCSI, SAS, and FC make their bid for the small-to-medium business (SMB) space. This is, according to Bob, the “sweet spot” in the current market, where companies have some money to spend but do not endorse “rip and replace” as the upgrade strategy of choice.
Your comments can be sent to jtoigo@intnet.net. But leave my mother out of it.
About the Author
Jon William Toigo is chairman of The Data Management Institute, the CEO of data management consulting and research firm Toigo Partners International, as well as a contributing editor to Enterprise Systems and its Storage Strategies columnist. Mr. Toigo is the author of 14 books, including Disaster Recovery Planning, 3rd Edition, and The Holy Grail of Network Storage Management, both from Prentice Hall.