|
Hello Andreas,
Well, the current proc-fs entries are a read-only representation of what
could be set regarding state timeouts. The 'ipvsadm --set' command will set
a) The time we spend in TCP ESTABLISHED before transition
b) The time we spend in TCP FIN_WAIT before transition
c) The time we spend for UDP in general
for IPVS related connection entries.
Let me ask the question of the foreposter again, please:
Where can I get the currently set values of "ipvsadm --set foo bar baz"?
You can't :) IP_VS_SO_GET_TIMEOUTS is not implemented in ipvsadm or I'm
blind, also the proc-fs related entries for this are not exported. I've
written a patch to re-instate the proper settings in proc-fs, however
only in 2.4.x kernels. Julian has recently proposed a very granular
timeout framework, however none of us has had the time nor impulse to
implement it. For our customers I needed the ability to instrument all
the IPVS related timeout values in DoS and non-DoS mode. The ipvsadm
--set option should be obsoleted since it only covers the timeout
settings partially and there is no get method.
I did not find a way to read them out, I grep through the /proc/sys/foo
and /proc/net foo and was not able to see the numbers I set before. This
was on kernel 2.4.30 at least.
Correct. The standard 2.4.x kernel only exports the DoS timers for some
(to me at least) unknown reason. I suggest that we re-instate (I'll send
a patch or a link to the patch tomorrow) these timer settings until we
can come up with Julian's framework. It's imperative that we can set
those transition timers, since their default values are dangerous
regarding >L4 DoS. One example is HTTP/1.1 slow start if the web servers
are mis-configured (wrong MaxKeepAlive and its timeout settings).
This brings me further to the question if the changes of lvs in recent
2.6 development are being backported to 2.4?
Currently I would consider it the other way 'round. 2.6.x has mostly
stalled feature wise and 2.4.x is missing the crucial per RS threshold
limitation feature. I've backported it and also improved it quite a bit
(service pool) and so we're currently completely out of sync :). I'll
try to put some more effort into working on the 2.6.x kernel, however
since it's still too unstable of us, our main focus remains on the 2.4.x
kernel.
[And before you ask: No, we don't have the time (money wise) to invest
into bug-hunting and reporting problems regarding 2.6.x kernels on
high-end server machines. And in private environment 2.6.x works really
well on my laptops and other machines, so there's really not much to
report ;).]
Besides that to my knowledge Linux uses a timeout of about 2h + several
minutes ( 9 * 75 secs?) until a tcp connection timeouts.
Where did you get this number from? Also there is tons of timers
regarding TCP, so you have to be a bit more specific. On top of that LVS
does not use the classic TCP timers from the stack since it only
forwards TCP connections. The IPVS timers are needed so we can maintain
the LVS state table regarding expirations in various modes, mostly LVS_DR.
Browsing through the code recently I realised that the state transition
code in ip_vs_conn:vs_tcp_state() is very simple, probably too simple.
If we use Julian's forward_shared patch (which I consider a great
invention, BTW) one would assume that IPVS timeouts are more closely
timed to the actually TCP flow. However, this is not the case because,
from what I've read and understood the IPVS state transitions are done
without memory, so it's wild guessing :). I might have a closer look at
this because it just seems sub-optimal. Also the notion of active versus
inactive connections stemming from this simple view of TCP flow is
questionable, especially the dependence and weighting of some schedulers.
So, if I set a
lvs tcp timeout about 2h 12 min, lvs would never drop a tcp connection
unless a client is really "unreachable":
The timeout is more bound to the connection entry in the IPVS lookup
table, so we know where to forward incoming packets regarding a specific
TCP flow. A TCP connection is never drop or not dropped by LVS, only
specific packets pertaining to a TCP connection.
After 2h Linux sends tcp
keepalive probes serveral times, so there are some byte send through the
connection.
Nope, IPVS does not work as a proxy regarding TCP connections. It's a
TCP flow redirector.
lvs will (re)set the internal timer for this connection to
the keepalive time I set with "--set".
Kind of ... only the bits of the state transition table which are
affected by the three settings. It might not be enough to keep
persistency for your TCP connection.
Or does it recognize that the
bytes send are only probes without a vaild answer and thus drop the
connection?
There is no sending keepalive probes from the director.
Hope this helps a bit to understand it better. If not, continue to ask,
however I might be unavailable for a couple of weeks now due to heavy
work load ;).
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
