|
On Mon, Jun 04, 2007 at 05:29:42AM +0000, Monty Ree wrote:
> Hello, all.
>
> I have operated two LVS-DR system like below.
>
> LVS1
> LVS-DR : linux kernel 2.6.18
> web server : linux kernel 2.6.18(apache+php)
> loadbalancing : sh(source hashing)
> at realserver : just a little FIN_WAIT, TIME_WAIT
> apache KeepAlive : on
>
> LVS2
> LVS-DR : linux kernel 2.6.21
> web server : linux kernel 2.6.21(apache+java+php)
> loadbalancing : sh(source hashing)
> at realserver : lots of FIN_WAIT, TIME_WAIT
> apache KeepAlive : on
>
> when I execute like below.
>
> # ipvsadm -L -n -c
>
> TCP 14:22 ESTABLISHED 221.155.xx.xx:1995 xxx.x.xx.xx:80 xxx.x.xx.xx:80
> ~~~~
> here, 14:22 means expire time, right?
Yes.
> at LVS1, after some seconds, above packets are disappeared.
^ connection entry
> but LVS2, is not.
If you are using connection syncrhonisation and LVS1 is the master
and LVS2 is the backup, here is a rough sketch of what is likely
to be going on.
On LVS1 a connection is established and there is a series
of packets going between the real-server and the end-user
via the master linux-director. During this time the packets
are tracked using a connection entry in the ESTABLISHED state.
This has a time out of 15:00 minutes which is refreshed
each time a packet is received. For the connection
above that would seem to indicate that it has been idle for
38 seconds.
When the connection is shut down by either the real-server
or the end-user, the connectino entry moves into the CLOSE
state, with a much shorter timeout. If no more packets are
received (which usually the case, typically, there will only be more
packets if some arrive out of order), then the connection entry
disappears pretty quickly.
So far so good.
On LVS2 things are a bit different. It doesn't see the packets
sent by the real-server and the end-user. Rather it recieves
connection information via the lvs sychronisation protocol.
These are sent out by LVS1. They are sent out once a connection
has seen 3 packets (the 3-way handshake is complete) and then
every 50th packet. There is also a 2s delay loop in there,
but thats not that important. It is this synchronisation information
that produces the entries that you see on LVS2. And they may be a
little out of date. But its not really that important, because
they are just there in case fail-over occurs, so that LVS2
will be able to forward packets for the connections that were
syncrhized.
The precices details of the timeouts and thes state of
these synchronised connections is not that important,
because while LVS2 is acting as a backup, they aren't used.
So other than consuming a very small ammount of memory, they
do no harm. And, if failover occurs, then the entries that
are used at that time are updated and follow the rules that
LVS1 was previously following. Just think of them as templates
with a timeout, rather than full fledged connection entries.
>
> What's the difference?
>
> and at LVS2, when I connecting using F5(reload),
> I can see over 600 connections, but LVS1 only 5-8 connections.
>
> Is it a kernel problem?
Probably not.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
|
