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."
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!
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".
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!