Talk:ISCSI

From Wikipedia, the free encyclopedia

A request: Could someone describe the basic protocol. Such as, What is an "Initiator" and what would an Initiator allow my OS to do? Would an Initiator allow my OS to mount a remote iSCSI device and assign it to a local drive letter/partition?

Another request: Please explain multipath. It is mentioned in the table, but not explained or referenced. —Preceding unsigned comment added by 212.115.193.244 (talk) 07:21, August 27, 2007 (UTC)

Contents

[edit] How does iSCSI differ from Samba or simple networked access?

It's not clear at all what the difference is between iSCSI and, say, a networked share is to a Windows computer. What is the difference in say performance or speed? Is there any? It seems to me that it would be pertinent to compare this storage solution against more commonly understood solutions that are commonly employed in most networks today. As far as I can tell from the article as it stands, the only difference is that it uses SCSI commands over an ethernet network but it tells me nothing of performance compared against a Samba share which is identical except for the protocol over an ethernet network. —Preceding unsigned comment added by 205.248.102.81 (talk) 15:48, 5 November 2007 (UTC)

Your question is answered by clicking on the link for "Storage Area Network", which in turn gives details of the SAN/NAS diference, where Samba is an example of a NAS protocol. --SHayter (talk) 01:56, 3 March 2008 (UTC)

[edit] iSCSI terminology and how iSCSI can be used by an OS Section

This section is fine from a user perspective, though it could use a better title. However, the discussion about the initiator-target relationship is a gross oversimplification that is somewhat incorrect. A bit of discussion on having multiple initiators communicating with a single target is presented in the Storage Devices section. In SCSI (regardless of the transport mechanism), you MAY have multiple initiators. This is useful when clustering disk storage or using SCSI Reservations so that multiple servers can share a tape library ("SAN Storage Options" in backup software parlance). The burden of managing multiple initiators is generally placed on the software, drivers, or OS on the servers sharing the devices.

I will make changes soon if it is not edited. -- Cy jvb 18:17, 5 April 2006 (UTC)

[edit] TODO

*Add blurbs about the use of iSNS, SLP, and CHAP and links to their articles. --Cy jvb 14:32, 6 February 2006 (UTC)
Does anyone actually use iSNS? Clearly it belongs, just curious.
CHAP already has some coverage in the article. --- tqbf 14:15, 13 November 2007 (UTC)

[edit] RFE

The linked article on "Build your on iSCSI SAN" is not a howto or instructional paper of any kind. It's just plain advertisement for an iSCSI-based SAN-solution by Transtec. -- patrickb

  * Seconded and done. -- Cy jvb 17:53, 24 March 2006 (UTC)

[edit] NetBSD has an initiator?

NetBSD having an initiator would be news to me. Additionally, I can't find any evidence of this in their CVS tree. I also haven't seen any mention of this on the NetBSD mailing lists, or with Google.

--Jakllsch 20:34, 8 November 2006 (UTC)


Yes, NetBSD has an initiator I will add links to the initiator and target howtos in the artcile http://www.netbsd.org/Changes/#iscsi-target --[[User:Ke4qqq|ke4qqq}} 2357, 30 December 2006 (EDT)

[edit] NPOV?

There is a lot of listing of companies and there products on the page, some sections ignoring alternative vendors completely, eg under "iSCSI to Fibre Channel, SAS/SATA or SCSI" there is no mention of Broccade, McData, Crossroads, Bridgeworks, Paralan... in favor of Atto. Do we strip details of vendors, or try to expand to cover a fair selection of all vendors, and possibly there target markets (Atto favor digital video markets and have apple support, McData large SAN environments etc). --SHayter 01:05, 15 March 2007 (UTC)

  • Strip them. The iSCSI target vendor & product listing is getting out of hand and adds no value to the article. I had just removed the Atto advertisement from the Virtual Tape Library article as well. Atto information should mostly be confined in an Atto article. As always, Wikipedia is not an index - use Google and trade mags if you need to find vendors. I would like to see the Initiator listing preserved in some way (perhaps combining the OS support table with the bulleted list?). The initiator support list documents the history of the uptake of iSCSI support in the various operating systems. --Cy jvb 11:41, 15 March 2007 (UTC)
    • I've thrown together a modified page at User:SHayter/iSCSI with all the major lumps ripped out, and I've updated the table slightly, though the details would have to be expanded within that table, if I can get a few people to agree, then I'll feel ok updating the main page. --SHayter 18:33, 24 March 2007 (UTC)
      • Very nice. One nit: under "OS Support" the Mac entry is misleading because it implies no iSCSI support prior to 10.5. In fact there has been support since at least 10.3, by third parties. Paul Koning 21:59, 24 March 2007 (UTC)
  • Re the "too many external links" tag -- SHayter's proposed modified edition cures that problem quite well. It doesn't sound like there's objection to that version, so this may be a good time for it to go live. Paul Koning 00:04, 4 April 2007 (UTC)
    • Nice solution! At least I didn't waste much time with the external links. --Ronz 00:15, 4 April 2007 (UTC)
  • The list of random links is getting longer all the time... SHayter, I still like your version and I don't see any signs of dissent... can it go live? Paul Koning 21:57, 17 April 2007 (UTC)
    • Sorry wasn't paying much attention, (work got in the way of play again), since no one has any objections I've moved it in with a couple of other minor changes. With some luck people will now consider contributing to the page rather than just adding there favourite vendors website. --SHayter 00:52, 28 April 2007 (UTC)
      • Very nice... now we need the same sort of treatment on router. Paul Koning 01:00, 28 April 2007 (UTC)

[edit] Irrelevant information/Neutrality

I have issue with the following line:

"Tests have shown excellent performance of iSCSI SANs, whether TOEs or plain Gigabit Ethernet NICs were used. In fact, in modern high-performance servers, a plain NIC with efficient network driver code can outperform a TOE card because fewer interrupts and DMA memory transfers are required."

It has no citation, is not neutral and can be disputed with modern TOE engines combined with an efficient driver/network stack. CPU utilization on the storage server is important as many storage solutions use software RAID internally. You can have the most efficient software in the world, but speed is still limited by the underlying hardware. Also, Intel has things like I/OAT which is another thing altogether.

But does this really have any relevance to the topic? iSCSI storage arrays come in so many shapes and sizes that to make generalizations like this may mislead and misinform. If you remove that line, it does not change the flow of the paragraph to greatly. I also clarified the next sentence, it was very vague. Col.panik 02:43, 31 March 2007 (UTC)

  • Now that I'm looking at it, the comparison of cost is made for ethernet vs. fiber - ethernet can only be faster than fiber if you have a 10GB ethernet cable. You would have to have the same sort of "new infrastracture" you would need for fiber. Granted, the costs may be a bit lower, but fiber probably has a longer life span in terms of upgradability. Col.panik 03:00, 31 March 2007 (UTC)

I'm not sure how comparison between TOE NICs and software-based stacks violates any neutrality. It is unsubstantiated original research which doesn't address the multitude of factors though. :-)

From my experience, that statement is not correct anyway. The issue with using a software stack is not so much the lack of available bandwidth, but the path saturation that is endemic to storage communication. Even before iSCSI, gigabit ethernet controller manufacturers introduced jumbo frame size selection and interrupt coalescing so that interrupts were generated by a timer or by algorithm after queuing packets. Though your CPU will spin less cycles to address interrupts, coalescing will greatly increase latency and force batch processing of incoming communication. To compensate for this latency, an application would need a few outstanding async operations (write/read, etc) to compensate (so long as the operations are not dependent on past ones). Streaming tape based applications need to run sequentially, so this option isn't available. My opinion is that latency is the big killer for storage networks. Ideally, you would want to disable coalescing so that packets are serviced as they come. TOE partially addresses this (the offload engine performs TCP/IP processing and preps it for the SCSI stack) but still increases latency in much the same way that coalescing does.

I'm not well versed on 10 gigabit ethernet setups, so this may not be true anymore: CPU speeds have progressed enough that disabling interrupt coalescing and fully saturating the data path will not consume more than 5-10% of available CPU cycles. Multi processor/core systems would be impacted even less. With an ideal IOMeter test (100% write, sequential distribution, high block size, several outstanding operations) and using 9000 MTU, the performance difference is stark - a difference in 60 MB/s (coalescing), 80 MB/s (TOE - QLogic 4050), and 120 MB/s (no coalescing) when using a single path. 120 MB/s is close to the maximum saturation that you will get with gigabit. (this was my own unpublished testing)

The differences between production setups would be less noticeable since disk access patterns change depending on the application. As you have said, the statement does not reflect any sort of comprehensive testing. The devices involved, the applications run, and the limitations of the hardware and network would all have an affect on throughput.

I'm not aware of any independent testing comparing software stacks with TOE NICs.

As for the relevance - the performance vs. cost ratio is somewhat important with iSCSI since it is seen as a competitor with Fibre Channel. Others might disagree. --Cy jvb 13:39, 1 April 2007 (UTC)

A statement about performance, once substantiated, would be fine and would be useful. I'm sure some kind of statement like that is easy to substantiate. The performance of iSCSI has been the subject of argument since day one. [1] is closely related (not TOE vs. software but FC HBA vs. software).
You can have all sorts of theories about what sort of aspects of a network stack are important. I think the real answer is that in many cases none of them matter a whole lot once you get to some reasonable level -- but in any case, the right answer is to point to experimental data.
Re ethernet can only be faster than fiber if you have a 10GB ethernet cable -- not completely true. For one thing, you can have multiple links. Also, GigE is faster than "1 Gigabit" FC because FC speeds are baud rate, not data rates -- "1 gig" FC is actually 850 Mb/s FC... (1.0625 GBaud). Paul Koning 17:42, 1 April 2007 (UTC)

[edit] What is iSCSI?

This article is very vague to a "non-techie".

At the very least, shouldn't a description of iSCSI be in the first paragraph of this article?

--angrykeyboarder (a/k/a:Scott) 21:26, 8 November 2007 (UTC)

I'd agree. It needs some help. Can you help? Paul Koning 01:06, 9 November 2007 (UTC)
See iSCSI. What do we think? --- tqbf 01:52, 9 November 2007 (UTC)
Much better. I'm sure the article can use all manner of polishing but this really helps the intro. Paul Koning 18:08, 9 November 2007 (UTC)

[edit] Let's Clean This Up

I've done a lot of work with iSCSI and want to get better at fixing up WP articles.

I've rewritten the lede, started reworking iSCSI#Functionality, and rewritten iSCSI#Security (which was just weird before).

What's a hit list of things we need to fix up? I recognize that this article used to have some very vendor-y stuff on it before, but it looks like most of that has been scrubbed. Some thoughts:

  • The OS Support Overview needs to be cleaned up. I'm not sure the table works; for instance, Linux iSCSI support is "interesting" and deserves a sentence or two.
  • Unfortunately for iSCSI proponents, this article has a glossary issue --- what's a CDB? What's a LUN? What's an HBA?
  • I'd like to get some protocol documentation in here (header fields and the like). Header diagrams are to tech articles what photographs are to WP:BIO articles, yo!

Thoughts welcome. I'm happy to do the grunt work of churning out words if someone else wants to provide guidance and editorial help.

--- tqbf 18:57, 9 November 2007 (UTC)

Re glossary issue: agreed. For the most part (the examples you mentioned) those are SCSI terms rather than iSCSI terms. They might be in a SCSI article; if not that's where the detailed explanation belongs. Paul Koning 20:57, 9 November 2007 (UTC)
That's true, except that it's hard to understand some of iSCSI without knowing things like what a LUN is. I think the bright line is, if iSCSI admins need to know the concept, even if it's a SCSI term, it deserves summary coverage here. By that guidance, we wouldn't put CDB layouts here, but would put LUNs. --- tqbf 21:00, 9 November 2007 (UTC)

[edit] CHAP Security

There's a lot of (probably undeserved) controversy about the use of CHAP in iSCSI; for the time being, rather than spending 3 grafs on it, I just put "attempts" in the sentence describing CHAP. The simplest retort to "it DOES prevent..." is to point out that CHAP is vulnerable to offline dictionary attacks, where, for instance, SSH is not.

--- tqbf 21:01, 9 November 2007 (UTC)

Please don't do that. It is a bad idea to quote papers about attacks on PPP that don't apply to iSCSI -- as indeed it doesn't. As you say, there is lots of undeserved controversy about CHAP in iSCSI; a paper a few years ago from an organization named iSER is a particularly bad example of incorrect information. I've edited the text to state that the iSCSI RFC specifies how to use CHAP safely, with a reference to the applicable section. Paul Koning 21:12, 9 November 2007 (UTC)
You mean iSEC Partners. You might have trouble here, because iSEC got an Addison Wesley book published on this topic, meaning that iSCSI CHAP weaknesses have reliable sources. CHAP, as implemented in mainstream iSCSI, has the same security problems as CHAP in PPP.
I think we should come up with compromise wording here. I'm not interested in pushing a POV, but note that assertions of CHAP's strength are themselves a POV. I suggest:
...using the CHAP protocol, which includes a mechanism to prevent cleartext passwords from appearing...
By way of bona fides and/or COI, I've been doing iSCSI research for a bit; here's a published advisory of mine, and here are two articles [2] [3] (neither of these are themselves WP:RS, just provided so you know where I'm coming from.

--- tqbf 21:31, 9 November 2007 (UTC)

Yes, those are the guys. And while a book may qualify as a "reliable source", I would argue that a standard (such as RFC 3720) trumps a book, unless the book claims and proves an error in the standard. That is not the case here; the iSEC paper simply makes statements that do not apply to iSCSI, and a casual inspection of both documents makes that clear. In other words, it is possible to get a book published that contains inaccuracies. This isn't a question of POV, it's a question of conflicting claims of fact in conflicting sources; in such a case the more authoritative source should be used, and that is the RFC.
"CHAP as implemented in mainstream iSCSI" -- what is "mainstream iSCSI"? There is the RFC. CHAP as implemented per the RFC does not have the same problems as in PPP, because the rules in section 8.2.1 were specifically written to address the known issues of PPP. For example, the paper you quoted earlier may well be correct for PPP (I don't know PPP well enough to say) but it most emphatically is not applicable to a conforming iSCSI implentation. As usual, it is possible that there are nonconforming implementations -- it's hard to say what their properties might be. But if so, that would be a property of a particular bug, not a property of iSCSI the standardized protocol.
Finally, "includes a mechanism to prevent cleartext..." -- that's accurate but I think it says the same thing as what I wrote with a few more words. It doesn't say anything additional about security issues or lack of them. I think what I wrote (the RFC reference) does that. We can elaborate on that if necessary.
Paul Koning 21:50, 9 November 2007 (UTC)
The RFC doesn't address reflection or dictionary attacks directly; other sources do. Regarding "mainstream iSCSI" --- that's iSCSI as implemented by NetApp, the Windows Initiator, and linux-iscsi, though I'll accept alternate definitions. There's an obvious difference between the code in linux-iscsi and the RFC itself.
Like I said, I don't want to push POV either way. I agree, "includes a mechanism" is wordier than "prevents". But it's also more accurate and more verifiable. Again, let's agree on a wording here that neither imputes vulnerability nor implies invulnerability.
One more thing: this article does not refer to the iSCSI Protocol, but iSCSI as a concept. That implicitly includes implementation, deployment, and architecture, as it exists in the real world. The iSCSI RFC is not a controlling document for the contents of this article. --- tqbf 21:56, 9 November 2007 (UTC)
Ok, that's fair. But since the RFC is the standard, it would be a good idea to make it clear when something being discussed is an aspect of a nonconforming implementation rather than of the standard. That way, conforming implementations aren't as likely to be tarred with the tar brush.
I have to disagree with you about reflection and dictionary attacks. Both are directly covered in section 8.2.1:

When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support use of up to 128 bit random CHAP secrets, including the means to generate such secrets and to accept them from an external generation source.

and

Any CHAP secret used for initiator authentication MUST NOT be configured for authentication of any target, and any CHAP secret used for target authentication MUST NOT be configured for authentication of any initiator. If the CHAP response received by one end of an iSCSI connection is the same as the CHAP response that the receiving endpoint would have generated for the same CHAP challenge, the response MUST be treated as an authentication failure and cause the connection to close (this ensures that the same CHAP secret is not used for authentication in both directions). Also, if an iSCSI implementation can function as both initiator and target, different CHAP secrets and identities MUST be configured for these two roles.

(both from RFC 3720, page 101). The first quote talks about dictionary attacks, the second one describes reflection attacks.
Your last edit to the article seems fine to me. It does raise one question: you wrote "most attacks" -- which suggests the question "please list the attacks that it doesn't cover".
Paul Koning 22:09, 9 November 2007 (UTC)
Agreed wholeheartedly on reflection, but in practice, CHAP secrets are almost never 128 bit random numbers; a perfect example of where the RFC and the real world disconnect, and therefore a good thing to capture in the article. Any neutral wording you can suggest for this would be welcome! --- tqbf 22:18, 9 November 2007 (UTC)

[edit] HBA and Hardware Initiator section confusing

I find having two headings for "HBA" and "Hardware Initiator" confusing. They seem redundant to me. I'd like to collapse into one heading, probably the existing subheading of Hardware Initiator

Aarondailey (talk) 08:28, 12 December 2007 (UTC)

Meh. I'm not married to what's there now (fd: i wrote it) but the two subheds are making different points; one is that the protocol is implemented in both hardware and software, and the other is that there is a class of popular products called HBAs that people buy.
I see your point regarding the confusion. I am very section-happy; it's a lazy way to write, but it's effective in technical articles. Maybe the thing to do here is to collapse the hardware/software sections into a single graf, so there aren't two sections headings about hardware initiators next to each other.
One thing I don't want to do is lose the term HBA in the subhed. Normally, WP:MOS would say not to put jargon into subheds, but in this case, I feel like "what the hell is an HBA" is a question iSCSI readers would probably be coming to WP with, because the term is so common.

--- tqbf 17:19, 12 December 2007 (UTC)

[edit] Request suggestions for diagrams

I'd like to start doing more diagrams for technical WP pages, and I'd like to start with this article. Anybody got suggestions for things that would benefit from pictures?

--- tqbf 17:19, 12 December 2007 (UTC)

Perhaps a picture of several computers, several targets and a SAN cloud connecting them all. It could illustrate the concepts of initiator, target and LUNs on that target. You could also include sample names of devices on the initiator and target. Aarondailey (talk) 03:27, 13 December 2007 (UTC)

[edit] iSCSI Software Targets

Hey Guys,

So, I put in the list of iSCSI software targets, and I don't understand why it was removed. Please site a documented reason for why such information doesn't help fulfill Wikipedia's mission to "Store All Human Knowledge". The information in that table, represents weeks of work to gather, and could be extremely valuable to others. It isn't a list of products, most of the links were to opensource projects.

For now, I have put it in my own wiki, and added an external link.

Joey Novak (talk) 18:12, 21 January 2008 (UTC)

"Store all human knowledge"? I don't know about that, but it certainly isn't Wikipedia's mission to store every conceivable list. Paul Koning (talk) 19:16, 21 January 2008 (UTC)


re: Target Wiki I think it might be useful to include a list of vendors (and targets), as long as the list is inclusive of everyone big or small, if it is clearly labeled as such. i.e. a new section labeled iSCSI Options. That wouldn't really be any different than linking music genres to artists.Jame Ervin (talk) 22:34, 7 February 2008 (UTC)