John,
Currently there are two proposed methods of providing Storage over IP: Native SCSI over IP networks (Such as Nishan is attempting) and Tunneling of Fibre Channel over IP. Nishan is taking the proprietary route and creating there own method of Native Scsi over IP, SoIP. There is also a standard being developed, iSCSI, led by Cisco and IBM, to standardize SCSI over IP. This standard is backed by Agilent, HP, EMC and others. I believe the standard is in working draft form. I believe Adaptec is proposing a solution as well.
Issues with Scsi over IP are mainly due to performance as you point out. Fibre Channel and GigE both have transfer rates of 1 Gb/s. FC will soon have 2 Gb/s. Both FC and Gig E are working on 10Gb/s. Transfer rates being equal now and in the future, Storage over IP has extra overhead due TCP. The TCP/IP stack is too software intensive to rival the performance of Fibre Channel. There are efforts being made to implement the TCP/IP stack in hardware to increase the performance so that SCSI over IP can rival the performance of FC networks.
As far as the issue you suggest of Ethernet not being able to support block transfers ala SCSI, this is not an Ethernet issue, as Ethernet is simply the Medium Access Protocol. Support of block transfers would be handled at a higher level.
FC tunneling over Ethernet is being pushed by the SAN companies. Gadzoox and Lucent have partnered.
Crossroads demonstrated FC over GigE at Comdex.
biz.yahoo.com
CNT and Nortel have also partnered.
cnt.com
The tunneling method basically consists of encapsulating FC packets (called frames in the FC world) into IP packets, and sent over Ethernet to another box which unencapsulates them and sends them to the remote FC network. At present time, this is the more viable solution, as it does not require a change in OS behavior, or device interface. To implement Native Scsi over IP, Storage devices must also be changed to interface with the new protocol.
Another drawback of iSCSI or SoIP is that the overall performance of the IP network will be degraded, due to the storage running over it. Assuming companies are utilizing there existing infrastructure, this will affect both the performance of storage traffic and normal IP traffic. A method that might be used would be to separate the two different types of traffic on the network, so they do not effect each other.
I am much more knowledgeable of Fibre Channel then I am of the Ethernet/IP world, so I may not be giving TCP/IP a fair assesment. There are some big players behind iSCSI
On another note, IP is able to be carried on FC networks similar to SCSI. FC is simply a transport system for upper layer protocols to be carried on. Emulex and Qlogic currently make Host Bus Adapters that can be configured to operate as network cards, sending IP on top of FC. Therefore a host with a FC interface can send IP packets to another FC host who will extract the IP packets from the FC frames. Therefore, we have IP connectivity over a FC network. A main benefit of FC is that flow control and acknowledgements are handled at a low layer in hardware as opposed to TCP which is in software. This saves alot of overhead associated with CPU intesive processing of TCP. In the future, I see a FC host sending IP packets over a Fibre Channel network to a "FC to Ethernet" router which will translate the FC frames to Ethernet and send them along the Ethernet network.
With regards to NTAP and the NAS/SAN debate, I'm curious if NTAP has thought of providing a FC interface to their filers. With IP over FC capability, the filer could talk NFS over a FC network to a SAN host, thus NTAP would play in both games, SAN and NAS.
Please forgive this ramble from a first time poster. I found the thread about 5 months ago and am half way through TRFM. I feel extremely fortunate to have wandered upon a forum of such intelligent folks and I look forward to contributing.
Darryl |
