"I want my iSCSI!" Easier said than done.

There has been much banter in the VC and storage industries about whether iSCSI is the biggest bust since eight-track tapes or whether it will still prove to be a valuable and important technology. This argument could not be more shortsighted and self-serving to those who promulgate it than if you paid them for their opinion.

What If ...

Let's pretend I could grant you, oh Savvy Purchaser of All Things IT, complete physical security for all of the information contained in your organization's PCs--desktop and laptop--access to every server in your organization to which you are authorized, simultaneous write-to disks in multiple global sites and completely secure access to all of your data on disk from any device with a standard Ethernet connection (including handheld devices) from any Ethernet node in the world and have the disk operate as though it were physically in your hands. Would you be interested? Oh, and I forgot to mention, not only is this extremely affordable, you wouldn't have to significantly change your infrastructure, and if your network or service provider fails, your job waits exactly where it was when the failure occurred until the failure is corrected.

Well, we need not pretend. This technology is available today. You are familiar with it. It has been heralded in the storage arena as the best thing since the original bread slicer, and it is languishing as surely as Cinderella waiting for her fairy Godmother to appear. It is iSCSI, and it is absolutely looking for a date to the Grand Ball.

No Way

So you say, "No, way, iSCSI is just a cheap technology for propeller heads to play with." Today, if one looked at the market, you'd be correct, iSCSI has been a Pandora's Box for most vendors and many end users because it has not lived up to its initial promise of utilizing existing Ethernet infrastructure to deliver Fibre-Channel quality data transport to a globally distributed user base. Millions have been spent and investors have been burned with little to show for being early to the market except stock certificate wallpaper and Chapter 13 legal proceedings. But why is this? Is the science and engineering flawed? Is market demand waning for the technology? Is the technology being mis-marketed? One opinion is yes to all of the above, and here is why:

Incomplete products: One of the ongoing debates in the iSCSI community has been whether or not it is important to include all of the Error Recovery Levels that are specified in the IETF protocol. Most, if not all, of the early iSCSI products on the market only included the first level of error recovery (ERL 0) and did not include the feature sets of Error Recovery Levels one and two (ERLI, ERL 2). Many of these products came to market before the final version of the iSCSI protocol was ratified by the IETF. Because the upper level storage management feature sets are only included in the upper Error Recovery Levels of the protocol (such as guaranteeing no single point of failure and job loop back) and because these feature sets were not included in most early product releases, the market expectation for quality performance was severely damaged.

Initiators before Targets: iSCSI operates with two main pieces: an initiator (client) and a remote target (data server). An initiator makes a request to a remote target and creates a connection over TCP/IP, which allows a remote disk to behave identically to a SCSI attached device. Many of the early vendors in the space developed only initiators and did not simultaneously develop targets. The reasons for this vary but the end result has been a landscape comprised of hundreds of initiators and very few targets. Because of the complexity of today's data networks, it has proven to be very difficult to provide the quality of service that enterprise storage administrators demand through even simple barriers such as NAT. Since an initiator only manages the request side of the equation, it is not surprising that many of these products will only operate inside the LAN. These products were not designed to, and simply are not capable of, aggregating bandwidth across subnets or managing a request through a complete node or service provider failure. This was a critical miscalculation, and it led to a generation of sub-standard products.

iSCSI is a Cheap Technology: Some of us were taught that the only things that should be referred to as "cheap" are thrills and liquor--most everything else of low cost is properly referred to as "inexpensive." While this may at first blush appear to be nothing more than a semantic argument, it actually illustrates a critical problem with the iSCSI market today. The market has been tainted with poor quality products, dismal performance and overwhelming disappointment. Products were, and are, being marketed as "a poor man's Fibre Channel," or positioned as only acceptable in non-mission critical environments. As one leading iSCSI appliance vendor's senior engineer recently opined (and I paraphrase): "I want to have a product that my bank will use to run its serious data. Right now it will only consider running its advertising with it." This is no surprise when the landscape of iSCSI devices is almost exclusively populated with products designed using technology that is incomplete and incapable of performing at the expected standard. While the early generations of iSCSI were indeed less expensive, alas their performance, by and large, is pretty cheap. These early products left a bad taste in many buyers' mouths (the same mouths which created the current prevailing antipathy toward iSCSI). Is there any wonder as to why? This is a marketing problem and a market perception problem. It will be rectified with solid products that exceed expectations and operate as advertised. Until then, all vendors in the iSCSI market space will be swinging off the back foot while trying to get ahead in the count.

Products designed to fail: The iSCSI protocol is designed to have no single point of failure, to aggregate all available bandwidth and to be tolerant of hardware and service provider failure. Many of these features only operate properly in the upper Error Recovery Levels of the protocol--the same ERLs which most vendors have chosen not to include in their iSCSI stack. Further, if one looks at most of the iSCSI products--many of the iSCSI HBAs and TOEs available on the market today--most have only a single Gig-E port. Even if one installs two of these devices (heat considerations aside, natch), this leaves the problem of aggregation across subnets unaddressed: You still can't get there from here. To properly configure the upper Error Recovery Levels (ERL 2 in particular) one simply must have more than one port on an HBA. This is assuming, of course, one acknowledges that a single port, by definition, creates a single point of failure.

Latency v. Global Access: One scenario many iSCSI vendors would like to see is a seamless integration of Fibre Channel and iSCSI devices. This is not an "either/or scenario." iSCSI can transport data globally at the block level while Fibre can zip it around the datacenter at the speed of light, or darn near. There really is a symbiosis here, and it will allow for the scaling of block-level data transport to the globe. Similar to the garden hose, there is some initial latency when you first run data across a hemispheric iSCSI link that doesn't exist with a Fibre Channel. But when was the last time you ran your datacenter Fibre Channel link from New York to Las Vegas? A complete and properly engineered Fibre-to-iSCSI gateway device allows for the seamless transfer of data from a Fibre Channel datacenter to a TCP/IP network with, at most, some barely distinguishable initial latency. No huge infrastructure build-out or re-tooling of the datacenter is required. And nothing would make service providers happier than to start running traffic across all that dark long-haul Fibre that has lain fallow during the past decade. This is not the future. This is possible now.

Way

"So why can't I have my iSCSI?" you ask. Good question. One reason is that there are very few vendors licensing an iSCSI stack that includes all of the mandatory and optional feature sets adopted for iSCSI by the IETF. Very few vendors are producing products that are designed to properly address the upper Error Recovery Levels of the iSCSI protocol.

Similar to VoIP, there is a tremendous amount of institutional resistance to change (see also: fear of proprietary margin erosion.) TCP/IP, Linux and iSCSI are not proprietary. iSCSI allows a good engineer with COTS hardware and the correct components to build an IP SAN that rivals the performance of a good Fibre Channel implementation at a fraction of the cost and without the distance limitations. Further, because it uses TCP/IP and not Fibre, no specialized training or expensive technicians are needed for the care and feeding of your SAN. The important thing to bear in mind is that this is real. This is not vaporware. This can be implemented today.

Keep on Groovin'

"So, iSCSI-Propeller-head-Boy, why do I care?" you ask. Maybe you don't. But let me entice you with what marvels I have seen:

* Take a field engineer's laptop PC frame, with only RAM, Flash memory, an O/S and one or two network ports. Once booted and logged into the network, optionally using a VPN, the field engineer accesses disks located in a secure location half a world away, with the same functionality and performance as regular laptop with local disks. If he loses his "dumb" laptop or it is destroyed, the data is still tucked safely away in that secure location, half a world away, under the auspices of the organization's security policies. (Of note, the Department of Energy announced a few months back that there was a temporary moratorium on laptop computers at certain facilities due to security issues.)

* The same field engineer defaults to simultaneous writes of his data from the field to a primary Linux server and a backup Linux server. He has now completed the onerous task of data backup, which frees the sys-admin to work on a revenue-generating project or other vital task. Needless to say, since the backup Linux server is writing to disk, this makes the tape silo and tape media not only obsolete, but now totally unnecessary (Sarbanes- Oxley Compliance anyone?).

* A handheld wireless PC uses a 240Mb initiator to access any data on any server running target software anywhere on the globe. Any data that can reasonably be transported over the pipes available can now be carried in your pocket--literally, today.

* A home entertainment center is modified using only tools distributed and authorized by the vendor becomes a target (server). Any other device implemented with initiator software, be it a handheld device, a gaming console, a PC or other device can now access the skins for a favorite game or turned into a streaming media center. Ever get tired of hauling those VCR tapes to Mom's house to show her last year's graduation over Thanksgiving? No problem, use the initiator in your handheld (or eventually your smart TV?) to pull the home movies up locally.

Remember, none of this is practical with NFS. No one will ever be able to access a Fibre Channel SAN over a handheld wireless device from any global location. Maybe you only want functionality in your datacenter. But Cinderella is getting antsy, and there is a Ball to go to. So, please, and with apologies to MTV, please, tell your data storage vendors, "I Want My iSCSI!"

You'll thank me later.

Chris Short is vice president of PyX Technologies, Inc. (Concord, CA)

www.pyxtechnologies.com