StarWind Software

A little background:
ESX 4.0 running on Dell R900 (64GB RAM) with QLogic 4062 for iSCSI connection. ESX is installed on local RAID 1 drives.
StartWind 5.2 server on Supermicro SC216E2, Xeon E5530 quad, 8GB RAM, Adaptec 2258800 24-port SATA/SAS RAID controller on dual-multilane SAS backplane with 13 300GB 10K RPM SAS drives (mostly RAID 5). Also, 8 Intel E1000 type NICs.

The system has been running VERY WELL with iSCSI using failover configuration with preferred adapters set in ESX to spread load between the two iSCSI channels (A trick I posted last year). All running well with jumbo frames enabled at Starwind NICs, Switch and (I think by default) on the QLogic adapters.

Three targets are setup in Basic Disk mode with clustering enabled (to allow for NIC failover trick to spread load). On Startwind 5.1, RAM caching was not enabled. When I installed v5.2 (last week), all continued to work well. As a test I removed and remounted a target (which had a Win2000 VM on it only) but this time with WRITE-THROUGH CACHING enabled and 1.5GB of RAM assigned. I rebooted the VM on the target and all seemed to work well though I did not do any performance analysis. This configuration worked well and on the weekend, I decided to shut down all VMs on two other targets and remount the targets with RAM CACHING enabled as well. Again, I assigned 2GB of RAM to each target and used WRITE-THROUGH mode. When I went to reboot the VMs, ALL HELL BROKE LOOSE!

First, the vSphere client would not connect to the ESX server. I was able to connect via Putty and start the webservices on ESX. The VMs were powering up but I could not open their consoles. Using Putty, I shut down the ESX server, removed the RAM CACHING from the two targets I had added the caching to and rebooted ESX. Now, I still could not connect the vSpere client until I used Putty to start the webservices on the ESX server. The Win2000 which still had RAM CACHING and worked well before was frozen on its login screen. Only when I removed RAM CACHING from the last target did everything return to normal.

Any advice? Has anyone experience problems with RAM CACHING? Maybe it was the multiple targets that caused problems?

RAM caching is enabled in StarWind 5.5, which is available only as beta version. For now we are still testing this functionality, and do not recommend to use it in production. You can use write-back cache - it would not as fast as write-through is, but more robust.

You can download newest build from site, it has a lot of bugfixes in RAM cache module.

Constantin,

I am not using HA but I guess the way I have the NICs setup, it would look like that since I use failover as a trick. Is there a thread where I can know what the latest release is along with release notes?

We will make such when final version of StarWind 5.5 will be released.
I meant that, if you are using RAM caching in StarWind 5.x, we recommend to download and install newest build, what is avaiable on site.

peekay wrote: The system has been running VERY WELL with iSCSI using failover configuration with preferred adapters set in ESX to spread load between the two iSCSI channels (A trick I posted last year). All running well with jumbo frames enabled at Starwind NICs, Switch and (I think by default) on the QLogic adapters.

Based on reading your post from Sept 2009, it appears you are using two NICs in the StarWind host on two layer2 segments (in a VLAN'ed switch) on two l3 subnets into your ESX host, and using MPIO(?) and a preferred path set-up to provide load balancing and (as a bonus) failover as well. If this does indeed work as advertised, then how does this solution compare to StarWind's new "HA" functionality? That is, why would I need the "HA" version if I have the setup you've described? (sync mirroring is a feature of the StarWind Enterprise / Non-HA, so that takes care of keeping my two iSCSI targets in sync).

That was a workaround, while now we offer solution that 100% work as active-active solution. Also could you please provide me with a link to post on forum, that you`ve cited.

The two-NIC solution was not to replace HA but to improve performance on a single StarWind server system. Other iSCSI target vendors allow LUNs to be attached to specific NICs so you can easily use multiple NICs to spread the iSCSI traffic. StarWind does not support this functionality at this time. We cannot afford HA at this time

So you are saying that StarWind does not allow you to spread the iSCSI target traffic over multiple NICs via MPIO? If this is the case, then it seems like a huge performance limitation (HA does not even come in to play here).

That is not what I meant. I needed more bandwidth without a) buying a 10Gig NIC or b) using link aggregation since it is not supported by ESX. So I use MPIO in a way that allows ESX to "see" to links but really, it is done with VLANs on the same switch. So ESX thinks it is MPIO but really it is just one switch and one StarWind server with two links setup to "load balance" using storage preferred paths.

I guess I am just confused -- if StarWind does not officially support using multiple NICs, then how is MPIO working?

We support using multiple NICs, why not? Either NIC Teaming.

Tulsaconnect.... Starwind DOES support MPIO but ESX has limitations. Because we are using QLogic iSCSI HBA cards, the channels cannot be used for MPIO under ESX. You really need to review the documentation and the purpose of my post and not focus on MPIO in my context!

We`ll do it ASAP. Thank you for feedback.