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/ _______________________________________________ LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users