iSCSI Moves Toward Standard

EyesWideOpen writes "The iSCSI technology, which allows computers to connect to hard drives over a network connection such as a company Ethernet network or the Internet, requires only minor changes before the Internet Engineering Task Force endorses it as a formal version 1.0 standard. A final round of comments has been completed on the technology according to the Storage Networking Industry Association, the subgroup that led the creation of the iSCSI, and as a result companies now can start building iSCSI products."

Comments

Re:hum..

[mwjlewis]

There are many advantages to have a storage protocol over the internet.

One example that is in my face is SAN's and the office that I am in. There is 14 offices around the world, and having one centeralized data center would make things so much easier for local office staff, and reduce costs for storage maintance. Less cost for more skilled people in the remote offices.

My $0.02

iSCSI not ready for prime time

[IGnatius T Foobar]

I work at a mid size hosting facility, and we've done quite a bit of experimentation with iSCSI. In my opition it's not ready yet. Either that or it's just a bad idea, full stop.

We do quite a bit with our SAN -- there are a coupla IBM 2105 ESS ("Shark") boxen in the back of the data center with many terabytes of disk online. It's all about Fibre Channel. At least as fast as SCSI, effectively faster when you have all sorts of cache running on the storage side, and you have the flexibility to define exactly how much disk goes to what server, and you can add more dynamically without a power down, etc.

Unfortunately, Fibre Channel is expensive. It requires expensive host bus adapters and even more expensive switches. And of course it runs over fiber optic cable, which isn't exactly penny kit. So the industry decided to try running it over Ethernet.

Now there are iSCSI-to-Fibre gateways, such as Cisco's 5420 Storage Router (which we've evaluated), but there are just problems in general with running block level storage over a TCP/IP network...

• For one thing, it's only as reliable as your network. If you have a network problem such as a down switch/hub etc, you lose your disks immediately.
• Unlike SCSI and Fibre Channel, you can't boot from an iSCSI volume. This is because your operating system has to be loaded, and your TCP/IP stack initialized, before you can load the iSCSI driver.
• Most operating systems want to load their storage drivers before they load their networking drivers. Doing it the other way around challenges all sorts of assumptions made by various system software out there. Sounds trivial, but again, we've evaluated it, and the result ain't pretty.
• By putting block level storage on your LAN, you've increased the capacity requirements by several orders of magnitude. To get any reasonable performance you're going to need Gigabit Ethernet everywhere -- and if you're going to make that kind of investment, you might as well be doing Fibre Channel.

That's why our iSCSI stuff is just sitting around doing nothing right now.

The only place I can see iSCSI being used at this time is for really temporary quick-and-dirty setups, such as a programmer needing another 100 GB online for a one-week project. But even then, NAS seems like a better idea.

Re:iSCSI not ready for prime time

[foobar104]

Are you kidding? When was the last time you used Fibre Channel? Its mostly optical now. All the new HBA's come with optical GBIC's.

You're both wrong. FC is neither "mostly optical" or "mostly copper." Devices like HBAs and switches that use GBICs (modular media adapters) can be either optical or copper depending on the GBIC used, and switched on the fly. You choose optical or copper cables depending on your environment. Copper cables have shorter runs than optical cables-- they can only run 30 feet or so, as opposed to miles for optical-- and they much more bulky. So in a data center where you have literally hundreds of FC cables, you'd probably choose optical to keep the physical size of the cable bundles from getting out of control. For connecting two devices in a rack, you can choose copper cables.

I think the "fiber optic is expensive" thing is a myth, though. I can't say for certain, but I think I remember that the outfit that sells us our patch cables sells 4-wire copper cables and optical cables at roughly the same price.

Possible uses

[Anonymous Coward]

Well, the article is useless, but this white paper clarifies some points.

One exquisite use would be for someone maintaining a lab: imagine remotely partitioning and ghosting 100's of computers from a single console through Gigabit Ethernet, or being able to repartition a colocated server.

One aspect that is disappointing is that it just looks like SCSI over IP. None of the peer to peer aspects of Firewire were mentioned, such as target-disk mode that newer Macintoshes support. It's really nice to be able to reboot, hold 't' and plug my laptop into another Mac and have its hard disk appear on the desktop as though it was an external Firewire disk.

Wave of the future

[Anonymous Coward]

Ultimately, this WILL be the wave of the future.

What iSCSI will allow is a single topology for how information is transferred (persistent storage, transactions, peer-to-peer linkages, etc)

In large datacenters, you currently have Fibrechannel, FICON (a form of Fibrechannel), and SCSI in your mix of persistent storage communications. This is in addition to your already large networks of ethernet, FDDI, ATM, etc.

Each require their own expensive switches.

What iSCSI will eventually provide is a single fabric for all your data traffic. This will result in a substantial cost savings both in equipment investment AND maintenance, which affects the total cost of ownership and return on investment.

This WILL need a substantial rework on the many sides of the IP networks, such as HBA's (Host Bus Adapter) that fully implement the IP stack for performance reasons. Gigabit ethernet takes a substantial amount of your CPU just doing normal transactional data.

I look forward to the long term implementation of this.