Feature Request: support for NIC teaming

[Anders]

My problem:
I have a physical repository server with 4x 1 Gbit/s NICS in a Network team, teamed together with LACP via the build-in Windows 2012R2 teaming software.
My tape server have a 10G connection.
When I'm doing tape jobs, I get speeds of 1G. Because source and destination IP's and port numbers are identical of all Network packets in the datastream from the repository to the tape server. The teaming software do not load balance the packets across all 4 1G Nics. - The result is my tape jobs run with 95 MB/s instead of 160 MB/s.

In the "Global Network traffic" dialog, there is an option to "use multiple upload streams per job" - If this feature could just get added a "Use multiple upload streams and port numbers per job" it would fix everything.

Would be a pretty easy to implement I think, the multiple streams are already there. We just need each stream to land in different destination port numbers for the teaming software to load balance it.

/Anders

[lando_uk]

I doubt this is possible. I think you'd only get 4Gbit/s over 4 x 1gbe nics using iscsi and MPIO. You'd probably have to have a different IP address for each NIC on your server, and then send separate jobs down each NIC to the destination. It'll never work if you have a single source IP and are using switch assisted LACP.

[Anders]

It Works "fine" for Windows Explorer file copying. I can, from my repository to my tape server, transfer 1 file at 3 Gbit/s. - So Windows Explorer opens multiple connections with different port numbers for each connection.

If I test with iperf between the servers, I get ~950 Mbit/s bandwith. If I run 2 iperf in parallel (with diffrerent port numbers, but same source and destination IP), each iperf get 950 Mbit/s bandwith.

We are running the NIC team with LACP and hash based load balancing. (the MS manual says the hash based load balancing takes into account Source and Destination IP and TCP/UDP port number)
How the Cisco switch acts in the other end of the team I dont know.

[lando_uk]

Ah, are they both Server2012 r2, maybe windows explorer is using SMB3.0 which uses multichannel.

[Anders]

Yep, both servers are Win2012 R2.

[rreed]

Subscribe. I'm interested as well, we have a similar setup w/ 10Gbps stoarge/VM fabric, 1Gbps extraneous device switches, (Dell Force10 --> Cisco 3750), our extraneous device in this case being our tape backup server. (4) 1Gbps NIC's LACP'ed up on the Cisco switch, using Broadcom's BACS utility to LAG up the NIC's, Cisco's ether channel LACP on the switch side. This is where we get into multiple data streams - yes one single data stream, no matter how large the data, will only traverse one NIC. You will not see above 1Gbps. Now, let's fire up multiple data streams, then LAG really starts to shine if/when each one uses a different NIC then you do get aggregated throughput. I am unclear on how Windows (esp. 2012) does file copying server to server vs. how Veeam proxies transfer data. It doesn't look like Veeam *really* uses multiple data streams but again, I'm not sure how it transfers data and that's why I'm here.

What brought me to this thread is investigating issues w/ the "Use multiple upload streams per job" check mark box in the Network Traffic settings. We would like to think we have a high capacity network so our expectations of throughput are high. But I'm tracking some network saturation issues that seem to calm down if I uncheck multiple data streams, pending further investigation. However, my backup jobs appear to have picked up speed (decreased completion times) by unchecking it; this was unexpected. Anyway, I never see more than 1Gbps to my remote server despite my 4Gbps LAG.

Regarding single vs. multiple data stream expectations, try firing up a single robocopy, no matter how many /MT:xx you give it, and you likely won't see more than 1Gbps. Fire up a few DOS windows, each w/ a robocopy simultaneously, then you'll see total throughput shoot up. I would love to see Veeam start supporting true multiple data streams for those of us w/ LAG please.