Slashdot Mirror
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."
And you thought that doing a packet flood could just disrupt communications! Disk IO now could get hammered, right? And corrupted? What's the spec say about that?
Unitarian Church: Freethinkers Congregate!
Anyone who doesn't think this is the beginning of a huge market is insane.
I must be insane.
What is the use case for this, again?
...is a BIOS extension which makes an iSCSI device Int13 accessible (or an "IDE controller" which really is an ethernet card with an iSCSI implementation) and an iSCSI "target" implementation on top of disk images.
I can't wait for raw disk I/O to be sent over TCP/IP networks! This is truly groundbreaking for people in my line of work.
This is going to be even more rewarding than watching my neighbor surf porn on his 802.11b network!
Kudos all around!!
John Q. Hacker
Then we can ALL seem cutting edge!
I bet NCR has a patent that covers this...
"Some nasty reflection attacks were discovered on iSCSI's use of CHAP" I wonder how many more security holes are waiting to be discovered? I would be very careful about how I use this untill it's been tested by fire.
Still the idea is really pretty fucking cool. Ethernet is cheap and fast (especially gigabit) and doesn't have any of the limitations that traditional SCSI or IDE have as far as devices on a chain. This could be a good replacement for Samba in some situations. The standards document is pretty daunting, so I can't tell if iSCSI will allow multiple connections to a single volume, but even if it doesn't there are many single user Samba applications that could be handled better by iSCSI.
-73, de n1ywb
www.n1ywb.com
This sounds really cool, but I am a little unclear on exactly what it means.
Does this mean that soon we will see SCSI disks w/ ethernet ports?
If so...
Can I take a bunch of disks and plug them into the switch on the the beowulf cluster that I am building and have all the nodes use them !!?! If so then this is INCREDIBLE!
-OR-
Would I plug a bunch of disks into a seperate switch that is accessible to the master node, and then the compute nodes use nfs or similar to access the master node just like in a traditional beowulf?
Either way this would give more flexibility than current solutions, and it is a GOOD thing.
Thoughts on tech, Software Engineering, and stuff
iSCSI will be an important leap into the future of technology!!!!1
I mean, seriously! Who gives a rat's buttocks about low latency and high performance and sanity? I mean seriously? Who cares about the praciticality and usefulness and overall sanity?
I mean, Jesus Tap-dancing Christ. Jump on the bandwagon already! It's all about eInternet now. iTCP/IP. eHTTP. eE-mail. Who cares about design grounded in reality anymore? These days, it's all about XML and TCP/IP and Web Services? Jump on the BANDWAGON! Everything should be implemented in XML: it's a rule! The SCSI protocol is hopelessly outdated, since it doesn't use the latest advancements in XML, TCP/IP, ADO.NET, ASP.NET, SOAP and web services.
I mean, you've GOT TO BE INSANE if you aren't smart enough to get in with the technology!
So basicaly this is the SCSI equivalent of Serial ATA. But instead of coming up with some new cabling and hardware, they're just grafting SCSI on top of Ethernet.
Its too bad even gigabit ethernet wont be as fast as SATA. Not that harddrives can typicaly go that fast anyway..
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.
And we really can use firewire to replace scsi.
Here are some answers/clarifycations on some stuff I've already seen in the coments here:
iSCSI is a SAN (Storage Area Network) replacement. It is not a file shareing system like Samba or NFS. The primary advantage of iSCSI over something like Fiber Channel is cost. You can build an iSCSI system with regular Ethernet switches where as Fiber Channel requires "special" switches and cableing. I would think that two systems could use the same iSCSI target, but only where it would make sense and where the file system could handle such access.
Yes, there are already are adapters. (Not quite sure how they are out ahead of the spec, but why would you let a little thing like that slow you down). They connect to the Ethernet switch (usually a gigabit switch) and therefor could boot off a volume via iSCSI.
Cisco also makes a device that can bridge lagacy SAN networks to iSCSI
[End of diatribe. We now return you to your regularly scheduled programming...] - Larry Wall in Configure from the perl
...I bet that in a couple of weeks they will be advertising positions that require "three years experience in iSCSI."
It's hot! It's NOW!
"How to Do Nothing," kids activities, back in print!
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).
One of the lecturers at the local uni did some research into how to have multiple machines interact with a disk over a network without stepping on anyones toes. A Block-Based Network File System
Apple lawyers have sent a cease and desist to the IETF for misappropriation of Apple's i* trademark.
One CPU cycle wasted on digital restrictions management is ONE TOO MANY.
...but will I ever be able to access my Commodore 64's tape drive over TCP/IP?
-- Even if a god did exist, why the fsck should I worship it?
Now we'll need to sacrifice goats for our routers, not just our disk drives!
Oh, no! You have walked into the slavering fangs of a lurking grue!
this is not considered dangerous
goto the iSCSI on www
serve mine with ARM please
"netBSD is not dead its just on your disk and you dont know about it "
regards
John Jones
Wouldn't it be cool to just have an ethernet connector on the computer? And connect everything, mouse, keyboard, webcam and ADSL into the same hub. Routing the packets it even could be possible to switch what computer the keypresses and mouse signals are going to without swapping cables.
...Ethernet over SCSI?
I object to the next comment.
If you open your mind too wide, people will throw trash in it.
I object to the next comment.
no you don't.
In Soviet Russia Ethernet runs over SCSI.
l
No, really! Farralon made a scsi based ethernet adapter for the powerbook.
http://www.macworld.com/1994/11/secrets/989.htm
Actually, I meant to type Farallon
I'm writing a FireWire driver for QNX. FireWire is a local area network protocol suite designed by hardware people, and it shows. FireWire is a packet oriented LAN; you send and receive packets on the wire. That's the level at which FireWire adapters operate. Above this is a layer that creates the illusion that there's a 64-bit "address space" into which you can store and load, 32 bits at a time. This address space is entirely a software abstraction - both ends are usually faking it. In a driver, you typically make something happen by "storing into" a "device register". The software packages up the store request as a packet and sends it. The receiver gets the packet, looks at the address being "stored into", and does something. It then replies with a reply packet. This is usually completely separate from whatever memory system either end has.
Since this "bus" illusion is too slow for bulk data transfer, it's not used for that. Bulk data is sent as packets. All of this looks like a protocol built on top of UDP. You have to match replies with requests, queue, time out, and retransmit, just like UDP.
SCSI, on the other hand, has "commands" and "responses", which makes sense. If something can't do some command, you get an error status back. With FireWire, you have to go read some address from the "bus" to find out what happened. Status returns aren't standardized across devices, either; there's a separate spec for each class of device, and there may be differences between manufacturers. So generic drivers are hard.
Transport of SCSI command descriptor blocks is provided by the Serial Bus 2 protocol (SBP2).
If you configure a Linux system to use firewire storage, you will find that Linux' SCSI is a client of the SBP2 driver, which in turn is a client of the 1394 driver.
SBP2 is more general than SCSI, although that's its most common use. It can also be used to transport IDE commands.
Otherwise what you say is correct. The SCSI part just comes at a higher layer in the protocol stack.
Request your free CD of my piano music.
Very simple explaination about why this is important.
1. count the number of PCI slots in your computer that you have or could add SCSI controllers to.
2. multiply that by 15 (assuming wide SCSI)
3. whatever that number is, iSCSI can give you more disks.
Could be quite nice to house all those noisy disks in the attic at the end of an IP network - hell how long til wireless iSCSI?
All the disks for my machines in one place - makes for quiet PC's.
One iSCSI project I did like was the Intel one (they released some beta drivers for their ServerPro cards under Linux as I recall). They successfully constructed a RAID array on the client machine that consisted entirely of iSCSI devices that were physically made up of huge ram disks in other machines - a RAM disk array! Gotta be some peformance gains there (network speeds notwithanstanding) If you can get 8GB say in each machine you could construct quite a large array purely out of solid state devices.
The software iscsi initiator for linux can be used with PXE to build a diskless iscsi sysstem. I've been running a diskless linux box for my primary work station for about 2 months.
2x the speed of my old ide drive, and i'm just using 100mbit ethernet.
and my harddrive is backed up now.
--Britt