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."
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
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!
http://www.adaptec.com/worldwide/common/index.h
iSCSI is useful as an interconnect in a SAN environment. The storage devices exist as their own node on the network, independently of the computers they are attached to. This is good for reliability (can replace the disk independently of the computer if it fails, and vice versa), configuration flexibility, and many other useful things.
iSCSI is nice because it uses standards that are well understood (Ethernet, TCP/IP) instead of custom networks like Fibre Channel. This should make SAN networks cheaper and more common, as well as providing an easy way to bridge a SAN network over the Internet (firewalled and encrypted, of course).
The only difference between a LAN and a SAN will be what you use it for!
Dr. Demento On The 'Net!
iSCSI will be used in a SAN environment. This is only between computers and storage devices, and not betwen computers and the outside world. I think you're confusing SAN with LAN.
It's like how SCSI is set up today on a single computer: there's really no way to get access to the SCSI bus without first gaining access to the host computer. The LAN and the SCSI bus are two entirely different things, separated by the host computer.
When iSCSI is used, this separation should be preserved. The network that is set up for iSCSI, your SAN, should be kept separate from your main LAN. Think of it as a private network that is visible only from your file servers that have a need to access storage devices directly.
Think of a SAN as equivalent to your IDE or SCSI cable. A SAN network typically uses a block-based protocol, that will read and write individual disk sectors without regards to filesystems, access control, and so on. This is designed for maximum speed, not security. It is the job of the file server to translate this into file-based access for outside clients, and enforce the appropriate file permissions.
And yes, you should definitely have good security on your file servers....
Dr. Demento On The 'Net!
I doubt that's going to be the case for the very long term. iSCSI is going to be in the LAN space sooner or later. The protocol does give at least some thought to security, and you can run it over IPSec.
There are plenty of insecure protocols run on local LANs today that can be nearly as bad. I know that it's a bad idea to trust your LAN but nevertheless people do it all the time, especially in physically secure environments like machine rooms.
No, the SCSI equivalent of SATA is called "SAS". Serial Attached SCSI.
http://www.scsita.org/sas/FAQ.html
What's really cool is that SAS and SATA share the same cabling and interface! SAS is a superset of SATA, that adds SCSI's features (multiple devices per port, and so on) to the basic one-device-per-port SATA design. The nice thing is that you can use cheap SATA drives on a SAS setup! This should be good for RAID. Think of SAS as "SATA Plus".
Here's a quote from the link above:
"Serial Attached SCSI complements Serial ATA by adding device addressing, and offers higher reliability and data availability services, along with logical SCSI compatibility. It will continue to enhance these metrics as the specification evolves, including increased device support and better cabling distances. Serial ATA is targeted at cost-sensitive non-mission-critical server and storage environments. Most importantly, these are complementary technologies based on a universal interconnect, where Serial Attached SCSI customers can choose to deploy cost-effective Serial ATA in a Serial Attached SCSI environment."
Dr. Demento On The 'Net!
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.
-73, de n1ywb
www.n1ywb.com
More accurately you'll see SCSI RAID arrays with Ethernet ports. The technology will initially be too expensive to put on individual disks.
iSCSI is really targetted to replace (or augment) Fibre Channel (basically SCSI over fiber optics with 1-2 Gbit data rates). Fibre Channel is very expensive both for the interface cards and for the switches. 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.
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.
I think that SGI's XFS filesystem can share partitions between multiple compute nodes but I don't know if that feature made it into the Linux port. For more info on this kind of thing google "clustered filesystems".
Storage Area Network!
/ 0, ,sid5_gci212937,00.html
http://searchstorage.techtarget.com/sDefinition
It is basically a fast and tight network to connect computers with storage devices. It does exactly what your IDE or SCSI cable does, except over a network.
Dr. Demento On The 'Net!
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
NFS, SMB, and all the other file-serving protocols are file-based. Clients open files on the file server, and do reading and writing from/to those files. The file server is responsible for security, making sure the client has proper permission to access their files. /etc/passwd)
/dev/hda)
(cat
iSCSI is similar to SCSI and IDE: it is block-based. Computers do reads and writes of individual disk sectors, addressed by number, and not in terms of files. It is below the filesystem. There is no security in terms of individual users here, because once the disk is opened, it is wide open. It is much faster than file-based access, though, which makes it popular for databases and such.
(cat
Your file server does a great job at both file-based and block-based access. The server serves up shares and files over file-based protocols, allowing users to connect. Internally, a filesystem is applied to the disks, and the files are translated into individual low-level accesses to read and write various disk sectors. These reads and writes to the disk take place over a block-based protocol.
Everything has its place, and it all fits together... hopefully!
Dr. Demento On The 'Net!
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).
"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????