copyjobs via SMBv3 multichannel on roadmap or already possible?

[joergr]

Hi, we have a big blazing fast flash-repository (for veeam copyjobs target) with many 10G nics running w2016. If I copy stuff to this machine from another windows server using standard explorer copy and paste it uses smbv3 multichannel immediately (as you would expect), utilizes all 10G nics to the max - wonderful. But veeam copyjobs use proprietary transport to the windows repository as it seems to me resulting in using only one 10g nic to the max. So - is this on the roadmap or am I missing something, is there a workaround?

[Andreas Neufert]

Let´s discuss data transport a bit.

Veeam uses own functionallity to communicate from source (Proxy) to target (Repository/Gateway Server).
There we use multiple transport channels (Multiple disks and multiple TCP streams) to transport data efficient.
We work with IP addresses (or DNS names). So if you have configured teaming it should saturate the networks with multiple connections if storage is not the bottleneck.

The Target datamover write into local disks (Repository) or to an CIFS share (Gateway Server role). For CIFS we relay on Windows CIFS/SMB transport and when windows can use SMB3 for it then it will go through SMB3.


I think what you ask for is you create an SMB3 share on the target server and select the Veeam Proxy and Veeam Repository Gateway Server. This way the processing use SMB3. But keep in mind that Proxy and Repository run then on one server which could cause a bottleneck as less ressources are available for compression and such things.

[joergr]

Hi Andreas,

first of all thanks for your fast answer. What I ask for is - regarding copyjobs windows veeam machine with local flash to windows veeam machine with local flash - is it on the roadmap to make use of native smb3 multichannel transport communication (no need for an smbv3 network share, just ms apis) if available on both machines without asking the user to configure anything?

Because you know, with windows nic teams or lags or third party port channels - there are other caveats you have to take care of which are not present in the smb3 multichannel implementation - especially the full utilization of multiple nics for a single stream.

On the other hand - I could try a switch independent windows nic team (>=2012) set to active/active. If you guys really use multiple streams for one copyjob, that could do it.

Thanks

Jörg

[Andreas Neufert]

We use our own communication channel as there are so many enhancements included.
Just to name some of them: Encryption, TCP optimizations, TCP cecksum checks (we do not trust the network card drivers/hardware here because we learded it the hard way that there are cards out there that can not be trusted), ...

So there are no plans to use SMB3 for our own internal communication.

But you can use SMB3 if you like by the above described method if this really helps in your situation.

[joergr]

Hi @all, just to give you an update on my research - i tried it with W2016 10G nic teams set to switch independent dynamic active/active mode. It does not work. Somehow windows hashing algorithms do not seem to be able to spread the streams coming from multiple veeam source machines via direct veeam transport. I also tried changing the dynamic balancer of windows to hash based, did not work either. Which on the other hand makes sense because this is incoming traffic and physical switches are unaware of some software balancer behind, it might work for outgoing traffic, though. So I guess 40G is the only good way Of course it would work with the share trick mentioned by Andreas but as he also already mentioned the caveats are too big, mainly no work offload and no good veeam special transport checks. An idea could be to let veeam engineers think of a way to use windows multichannel smb3 mode (no shares) transport for copyjobs veeam to veeam but still implementing their extra transport checks.

[Andreas Neufert]

LACP should do the trick.