|
On Fri, 18 Feb 2000, Julian Anastasov wrote:
> Hello,
> You are probably using VS/DR or VS/TUN in your test.
> Right? Using these methods the LVS is changing the TCP state
> based on the incoming packets, i.e. from the clients. This is
> the reason that the Director can't see the FIN packet from the
> real server. This is the reason that LVS can be easily SYN
> flooded, even flooded with ACK following the SYN packet.
> The LVS can't change the TCP state according to the state
> in the real server. This is possible only for VS/NAT mode.
> So, in some situations you can have invalid entries in
> ESTABLISHED state not corresponding to the connections in
> the real server which effectively ignores these SYN packets
> using cookies. The VS/NAT looks the betters solution against
> the SYN flood attacks. Of course, the ESTABLISHED timeout
> can be changed to 5 minutes for example. Currently, the
> max timeout interval (excluding the ESTABLISHED state) is
> 2 minutes. If you think that you can serve the clients
> using smaller timeout for the ESTABLISHED state when
> under "ACK after SYN" attack you can change it with
> ipchains. You don't need to change it under 2 minutes
> in LVS 0.9.7. In the last LVS version SYN+FIN switches
> the state to TW which can't be controlled using
> ipchains. In other cases you can change the timeout
> for the ESTABLISHED and FIN-WAIT states. But you can
> change it only down to 1 minute. If this can't help
> by 2GB RAM or more for the Director.
>
> One thing that can be done but this is may be paranoia:
>
> change the INPUT_ONLY table:
>
> from:
>
> FIN
> SR ---> TW
>
> to:
>
> FIN
> SR ---> FW
>
>
> OK, this is incorrect interpretation of the TCP states
> but this is a hack which allows the min state timeout to be
> 1 minute. Now using ipchains we can set the timeout to all
> TCP states to 1 minute.
>
>
> If this is changed you can now set ESTABLISHED and
> FIN-WAIT timeouts down to 1 minute. In current LVS version
> the min effective timeout for ESTABLISHED and FINWAIT state
> is 2 minutes.
>
> Regards
>
> --
> Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
I'm using DR on the cluster with 2 real servers. I'm trying to control the
number of connections to acheive this :
The cluster in normal mode balances requests on the 2 real servers.
If the real servers reaches a point where they can't serve clients fast
enough, a new entry with a weight of 10000 is entered in LVS to send the
overflow locally on a web server with a static web page saying "we're too busy".
It's a cgi that intercept 'deep links' in our site and return a predefined page.
A 600 seconds persistency ensure that already connected clients stays on the
server they began to browse. The client only have to hit refresh until the
number of AciveConns (I hoped) on the real servers gets lower and the overflow
entry gets deleted.
Got the idea... Load balancing with overflow control.
But when we activate the local redirection of requests due to overflow,
ActiveConn continues to grow in LVS, while Inactconn decreases as expected.
So the load on the real server gets OK... but LVS doesnt sees it and doesnt let
new clients in. (it takes 12 minutes before ActiveConns decreases enough to
reopen the site)
I need a way, a value to check at that says the server is
overloaded, begin redirecing locally and the opposite.
I know that seems a little complicated....
Help and ideas are welcome
JNA
|
