Re: [PATCH] ipvs: Fix reuse connection if RS weight is 0
From: yangxingwu <hidden>
Date: 2021-10-28 02:50:15
Also in:
linux-doc, lkml, lvs-devel, netfilter-devel
hello On Thu, Oct 28, 2021 at 5:09 AM Julian Anastasov [off-list ref] wrote:
Hello, On Wed, 27 Oct 2021, yangxingwu wrote:quoted
what we want is if RS weight is 0, then no new connections should be served even if conn_reuse_mode is 0, just as commit dc7b3eb900aa ("ipvs: Fix reuse connection if real server is dead") trying to do Pls let me know if there are any other issues of concernMy concern is with the behaviour people expect from each sysctl var: conn_reuse_mode decides if port reuse is considered for rescheduling and expire_nodest_conn should have priority only for unavailable servers (nodest means No Destination), not in this case. We don't know how people use the conn_reuse_mode=0 mode, one may bind to a local port and try to send multiple connections in a row with the hope they will go to same real server, i.e. as part from same "session", even while weight=0. If they do not want such behaviour (99% of the cases), they will use the default conn_reuse_mode=1. OTOH, you have different expectations for mode 0, not sure why but you do not want to use the default mode=1 which is safer to use. May be the setups forget to stay with conn_reuse_mode=1 on kernels 5.9+ and set the var to 0 ?
The problem is we can NOT decide what the customers do, many of them run kubernetes with old versions of kube-proxy. And most importantly, upgrade to new version is a very long and painful process, that's why we want to fix this at the kernel level
The problem with mentioned commit dc7b3eb900aa is that it breaks FTP and persistent connections while the goal of weight=0 is graceful inhibition of the server. We made the mistake to add priority for expire_nodest_conn when weight=0. This can be fixed with a !cp->control check. We do not want expire_nodest_conn to kill every connection during the graceful period.
ok, got it, I will try to fix this problem
Regards -- Julian Anastasov [off-list ref]