iSCSI Specification Approved

nasorsan writes "The iSCSI protocol is a means to transport SCSI commands and data using TCP/IP packets. This ratification by the IETF is "the last major hurdle for iSCSI to become widely supported. . . 'Now that it's done, Microsoft Corp. and Novell Inc. will release drivers, and the games will begin,' says Steve Duplessie, senior analyst at Enterprise Storage Group Inc. 'Anyone who doesn't think this is the beginning of a huge market is insane.'" he added."

Comments

Re:Combine with 1394 over tcp/ip

[n1ywb]

Uh, firewire already uses SCSI. This replaces Firewire. Well not realy since firewire is a lot faster than 10mb ethernet and a lot cheaper than gigabit. But in this case, Ethernet is doing the same thing that Firewire does now.

It's going to come down to Software

[Gerry Gleason]

As to your second question, You could potentially plug all of the disks (or arrays) into an ethernet switch and use them individually, but it's more likely you'd put some kind of front end in place to handle the filesystem tasks. Most filesystems assume they have sole ownership of the disks and can't share partitions between multiple live nodes. You would still gain the ability to partition big disks into smaller chunks per-compute node if you connected the disks directly (and maybe some failover capability) but that would probably be offset by the inability to share data.

Right, you will have boxes of drives on the SAN, just like with current FC based SANs. From what I've seen, the host OSs have to manage 'drive allocation', and as you say, typically this will be whole drive at a time (important for partitioning the I/O load between spindles anyway). The addition of authentication protocals probably would help in binding the drive to a particular system as well.

Since the other reason you want a SAN is for reliability, you're going to want redundancy in the connections anyway. If the drives themselves are iSCSI, they would probably only have one connection per drive anyway (well, maybe not, FC drives are often dual channel, right?). In any case, you'd have dual channels to each system and storage array as well as redundant switches or routers to eliminate all single points of failure.

There are some hints in the article that compatibility issues could become significant quickly. Since at the most basic level, this will be a normal routed TCP/IP network, I'm sure the vendors have all sorts of ideas for 'support' protocols to run on the SAN with the iSCSI packets. It states that people are 'chomping at the bit' to add more protocols, but the committe wants to hold things stable for at least a year for things to sort out. The whole thing could be sunk by various players doing the 'embrace and extend' dance in ways that tend away from full multi-vendor interoperability.

Without reading all the specs and proposals, it is easy to guess that protocols to provide for automatic device detection and allocation would be very useful from a system design perspective, but would also need to be part of the standard to acheive continued support for multi-vendor SANs. Another likely area is RAID support (configuring, fault detection and reporting, rebuilding and maintanance, etc.). Logically, a RAID controller is just another node on the network, but it lies between the hosts and storage devices.

Note to people who think this is something like Serial ATA, it isn't. Serial ATA is a point to point protocal, and it probably is asymetric to boot. TCP/IP is a symetric routed network, so it is a different animal altogether. OTOH, there is no reason why a storage array couldn't be iSCSI on the outside and SATA to the drives (expect products like this from some vendors).

Re:More details please

[nasorsan]

"iSCSI lets everyone leverage the developments of generic ethernet switches, routers, tunnels and bridges rather than having to develop new Fibre Channel ones from scratch."

One problem with this is the performance will be crap using existing ethernet host adapters. There are a few companies working on host adapters with TCP-offload engines. Putting the TCP packets back together and pulling them apart takes a lot of kernel/system CPU cycles and it severely slows the data transmission rates.

Initially, and probably for the next couple of years, host adapters or other hardware that can offload the TCP overhead from the system CPU will be very expensive (more than the current fibre channel HBAs) but overall not having to buy FC fabric switches from Brocade because you can use existing IP hardware infrastructure will be a cost advantage -- but not much. If anything, the prices for implementation will be close to the same for the next year or two and then it depends on how fast the FC stuff becomes cheaper and how fast the iSCSI stuff gets truly developed by hardware companies (Emulex, Qlogic, Adaptec, LSI Logic, etc.) whose R&D budgets are already squeezed tight by the current economic environment.

We'll see. NAS or SAN or iSCSI????