StarWind Software

Greetings,
We are currently implementing a iSCSI SAN using fast commodity hardware and Intel network adapters. We have recently purchased StarWind.

We are using a Intel PRO/1000 Quad-port PCI express network card in the iSCSI target running StarWind. We are connecting all four ports to a dedicated gigabit switch using the Static Link Aggregation mode of Intel's PROset teaming software, which gives us a 4Gbps link.

The client servers have Intel PRO/1000 dual-port PCI express NICs with both ports configured the same way, so they have 2Gpbs links. We are confident that this client/target arrangement will yield superb performance.

The question is, do StarWind and StarPort offically support using Intel adapters with Intel's teaming software? Are there known data integrity issues?

My concern in this area is that the MS initiator says it is not supported, and Intel's answer (at this URL http://www.intel.com/support/motherboar ... 027892.htm) says "Adapter Teaming using Intel's ANS is not supported for those ports transferring iSCSI traffic. This is due to limitations of the third-party iSCSI target/initiator software."

However I have seen occasional references in other places (even on the MS and Intel websites!) that this is recommended for performance and failover purposes. So what is RocketDivision's stance on Intel adapter teaming with StarWind and StarPort?

Many thanks!

Brett Milner
Director of I.T.
Cumberland University

Hi,

The NIC teaming technology creates a virtual NIC adapter that can be used by all system processes and services as any other NIC.

So there is no problem for StarWind and StarPort to communicate with each other over a teamed NIC, while the NIC is properly configured and is able to send/receive TCP/IP packets.

Thanks! I thought that would be the case and I wasn't sure why MS has a prohibition against it, since initiators work at the IP level (unless they are doing something odd with theirs). It is also odd since they support using their initiator within a virtual machine under Virtual Server 2005 R2, which also abstracts a "real" NIC just as Intel's adapter teaming does.

I did some informal testing since the initial message which proves the reliability of the Intel teaming solution. 8 gb of iso files were copied from a client machine to 20gb image file on the StarWind target server, using the hardware arrangement described in my original post. While the copying took place, I unplugged and reconnected network cables at random from the target and the client. The iso files were then expanded and checked after the transfer and no errors were found, and no errors were generated during the transfer. I may do some actual performance testing soon and list the results here.

Thanks again!

Good Please keep us updated about your progress Thanks!

This is an old thread. However, the page referred to at Intel is still up:

http://www.intel.com/support/motherboar ... 027892.htm

Adapter Teaming using Intel's ANS is not supported for those ports transferring iSCSI traffic. This is due to limitations of the third-party iSCSI target/initiator software.

Contrary to this, a guide is for download here:

Implementing NIC Teaming on a StarWind Machine
http://www.starwindsoftware.com/impleme ... nd-machine

Since the guide is on-line, I'm confident it is possible to combine teaming of NICs with iSCSI traffic, but how come that Intel doesn't support it? Is it because teaming may fail with iSCSI products from other suppliers than StarWind Software?

At least this is confusing.

You can team NICs. And you can run iSCSI traffic over teamed virtual NIC. The problem is it does not scale very well. So MPIO and custom load balancing firing requests one-by-one over pool of connections belonging to the different network interfaces work much better. That's why it's not recommended to team NICs to increase performance (just to keep channel redundant). And with V5.8 and up there will be zero sense to do it as StarWind is going to have own MPIO stack.

Thanks Anton! That explains it.

Good

Gustav wrote:Thanks Anton! That explains it.