On CBS Sports: Get your fantasy football keeper league
Find Articles in:
all
Business
Reference
Technology
News
Sports
Health
Autos
Arts
Home & Garden
advertisement

Content provided in partnership with
Thomson / Gale

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

Computer Technology Review,  Nov, 2004  by Chris Short

<< Page 1  Continued from page 1.  Previous | Next

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.

Most Popular Articles in Technology
An overview of continuous data protection
Why all those current ratings?
Many countries now have a mobile penetration rate above 100%, report says
The Tata Group's big telecom gamble: VSNL's recent acquisition of Tyco ...
MEASURING BANK BRANCH EFFICIENCY USING DATA ENVELOPMENT ANALYSIS: MANAGERIAL ...
More »
advertisement

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.