Hi, Sorry for not answering back earlier. Thank you for your answers. I understand now, why this is all happening as it is. As I'm dealing with many clients, I also have plenty options to balance per client, instead of per share. I, for now, with the current setups, won't be able to balance on NICs per client, but I have enough bandwidth and the NICs will still be useful in case of network failover scenario's. Thanks again and have a good week! Samy > On 8 Nov 2019, at 18:06, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Fri, Nov 8, 2019 at 11:29 AM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >> >> On Fri, Nov 08, 2019 at 11:09:10AM -0500, Olga Kornievskaia wrote: >>> Are you going against a linux server? I don't think linux server has >>> the functionality you are looking for. What you are really looking for >>> I believe is session trunking and neither the linux client nor server >>> fully support that (though we plan to add that functionality in the >>> near future). Bruce, correct me if I'm wrong but linux server doesn't >>> support multi-home (multi-node?) >> >> >> The server should have complete support for session and clientid >> trunking and multi-homing. But I think we're just using those words in >> slightly different ways: > > By the full support, I mean neither client not server support trunking > discovery unless that sneaked in when I wasn't looking. That was the > piece that I knew needed to be done for sure. > > When you say it fully support trunking do you mean it when each nfsd > node runs in its own container, right? Otherwise, I thought more code > would be needed to support the case presented here. nfsd would need to > have a notion of running something like a cluster node on a particular > interface and distinguish between requests coming from different > interface and act accordingly? > >> >>> therefore, it has no ability to distinguish >>> requests coming from different network interfaces and then present >>> different server major/minor/scope values and also return different >>> clientids in that case as well. So what happens now even though the >>> client is establishing a new TCP connection via the 2nd network, the >>> server returns back to the client same clientid and server identity as >>> the 1st mount thus client will use an existing connection it already >>> has. >> >> So, this part is correct, it treats requests coming from different >> addresses the same way. >> >> Although you *can* actually make the server behave this way with >> containers if you run nfsd in two different containers each using one of >> the two network namespaces. >> >> There are also things the client could do to distribute traffic across >> the two IP addresses. There's been some work on implementing that, but >> I've lost track of where it stands at this point.... > > Client can and will do trunking in case of pNFS to the data servers if > the server presents multiple IPs. Otherwise, we just have nconnect > feature but that doesn't split traffic between different network > paths. > >> >> --b.
