Today I was following up on some harmless messages I have been seeing on some iSCSI Initiators I have setup that provide disk to a number of ESX servers over a Gigabit LAN. It appears that there may be some limitations running the newest flavour of ESX with current IET. One recent comment from an OpenFiler forum which implements a similar configuration to the one used on our Debian Lenny servers states very clearly that IET may not be robust enough to handle peak disk I/O on an optimized Gigabit LAN segment serving VMWare VSphere servers. This post by alhall explains a lot what people have been seeing in some other OpenFiler threads I have been reading today.
In any event, it also has my eye on SCST, another iSCSI subsystem, that is not as mature from a packaging perspective but appears to be a future contender based on the current feature comparison.
The bottom line here is to stick with ESX 3.x with IET for now. As a side note, there are a few IET.conf performance tweaks laid out nicely here with explanations on what each does.
March 30th, 2010 at 8:59 pm
If you are experiencing performance issues with IET why not post it to the IET developers list iscsitarget-devel@lists.sourceforge.net and we’ll look into it.
IET when properly configured performs as well as the underlying storage does. Of course if you want to use it for anything other then a personal home network you really need to be running a later version then what comes with Debian.
-Ross
April 5th, 2010 at 3:04 pm
Yep, this was just a bit of relevant info I stumbled across in Jan when we were considering benefits and possible issues with testing v4.0 on our platform. We haven’t actually had much motivation to upgrade.
I expect IET has moved forwards from here.. and certainly from what is currently in Debian stable. This is a fairly un-researched/experience based post.. and thats why it never made it to devel list. Not an issue we have experienced; just one that took a bit of time to find some context on (hence the repost).
As a matter of interest in one prod environment I access, we run software raid + luks_crypt + LVM2 under VMFS3 (for VMWARE) and OCFS2 (for Xen) on Debian just fine with channel bonding_afs to deliver 2Gbps to the SAN (max 1Gbps per physical initiator host still). Its been supporting our small production environment for some time. If the features are in Debian Stable, functioning, it seems to work great.
The only issue we have seen is when RAID resync I/O on monthly cron checks on large 2TB volumes (which takes more than 24hrs) creates a scenario where the IET queue sometimes appears to overflow sometimes in an instant _ and the kernel sorta borks. No filesystem corruption yet (that we know of) but worked around by applying a cap to the raid_ratelimit_max and raid_ratelimit_min settings that seems to prevent this from happening now. This was the original issue that had some initial iET output similar to the findings in the links above. If this is causing misinformation of confusion, I’ll just remove it.
For us its all about reducing costs and risk to a certain degree, and we have the Debian expertise in house. The Debian platform tends to require less testing and promotion of updates thanks to its strict rules on packages _ so as long as it does what you want it too, its great (albeit a bit outdated right now pending Squeeze). Its a different story for our clients.
The evergreening between distribution release has been great so far, though we have only used IET since Etch in this manner. Lenny update was flawless. We expect more of the same for Squeeze. Not to mention the myriad of other business services also running on Debian stable platforms, so extending that mantra to include IET was straighforward and fit nicely into existing MOPs, etc.