LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: a few questions

To: hotman <zhaohf@xxxxxxxxxxxxxxx>
Subject: Re: a few questions
Cc: "lvs-users@xxxxxxxxxxxxxxxxxxxxxx" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 29 May 2000 14:09:45 +0300 (EEST)
        Hello,

On Mon, 29 May 2000, hotman wrote:

> Hi,all.
> 
> I want know whether the following functions is implemented in the lvs.
> Thank you.
> 
> $B"#(BDelayed Removal of TCP Connection Context
>     Because of IP packet ordering anomalies, IOS SLB might "see"
>     the termination of a TCP connection (a finish [FIN] or reset [RST])
>     followed by other packets for the connection. This problem usually
>     occurs when there are multiple paths that the TCP connection packets
> 
>     can follow. To correctly redirect the packets that arrive after the
>     connection is terminated, IOS SLB retains the TCP connection
>     information, or context, for a specified length of time.
>     The length of time the context is retained after the connection
>     is terminated is controlled by a configurable delay timer.

        There  is a default  timeout of 10+  seconds for the
CLOSE*  states and 60+ seconds for  states after FIN but you
can  tune them  in the  proc fs  (/proc/sys/net/ipv4/vs/) if
secure_tcp  is  ON. You  can  read about  these  settings in
http://www.linuxvirtualserver.org/defense.html

> 
> $B"#(BTCP Session Reassignment
>     IOS SLB tracks each TCP synchronous idle character (SYN) sent to
>     a real server by a client attempting to open a new connection.
>     If several consecutive SYNs are not answered, or if an SYN is
> replied
>     to with an RST, the TCP session is reassigned to a new real server.
>     The number of SYN attempts is controlled by a configurable reassign
>     threshold.

        LVS  has many forwarding methods.  Only using one of
them  (LVS/NAT) LVS can see the output traffic from the real
servers.   Under dDoS when the  real servers doesn't support
SYN  cookies it is very hard to determine if the real server
is running by sending SYN probes.

        Currently,  LVS allows a monitor  software to do its
checks  for the real server  availability. Normally the SYNs
are  answered from the kernel, not from the real service, so
you can't determine by using SYN probes if your real service
is working, only if it is present and not overloaded.

        There  is an easy  way to check in  the real host if
the  real service  is listening  on specific  port. Just let
your  monitor  software  to  bind to  this  port  on  each 5
seconds(2 seconds?). But this trick only detects if the port
is  busy.  Is  that enough?  You don't  need to  pass a real
requests to any real service on each 5 seconds just to check
if the daemon is running.

> 
> $B"#(BAutomatic Server Failure Detection
>     IOS SLB automatically detects each failed connection attempt to
>     a real server, and increments a failure counter for that server.
>     (The failure counter is not incremented if a failed connection from
>     the same client has already been counted.) If a server's failure
>     counter exceeds a configurable failure threshold, the server is
>     considered out of service and is removed from the list of
>     active real servers.

        LVS  puts  a deleted  service  in a  trash.   If all
entries to this real service expire it is purged. But if the
real service is recreated we restore it in the state when it
was deleted but with the counters of active/inactive entries
updated.   The connections can continue after this period of
inactivity,  they  are  blocked from  the  director  but not
droped.

> 
> $B"#(BAuto Unfail
>     When a real server fails and is removed from the list of active
> servers,
>     it is assigned no new connections for an amount of time specified
>     by a configurable retry timer. After that timer expires, the server
>     is again eligible for new virtual server connections and IOS SLB
> sends
>     the server the next connection for which it qualifies. If the
> connection
>     is successful, the failed server is placed back on the list of
> active
>     real servers. If the connection is unsuccessful, the server remains
>     out of service and the retry timer is reset.

        It is a monitor software's job to decide when a real
service  is alive and to add it  in the list for the virtual
service.   You are  free to  use any  monitor software which
uses  any kind of checks to determine when a real service is
alive:  connection establishment, local if-port-busy checks,
receiving  a known reply  from the real  service, the number
of retries and the interval between these checks, etc.

> 
> $B"#(BSlow Start
>     In an environment that uses weighted least connections load
> balancing,
>     a real server that is placed in service initially has no
> connections,
>     and could therefore be assigned so many new connections that
>     it becomes overloaded. To prevent such an overload, the slow start
>     feature controls the number of new connections that are directed to
>     a real server that has just been placed in service.

        This   can  be  achieved  from  the  monitor/control
software if that looks as a big problem. It is preferred the
weights to be updated often and not only on the start of the
real  service. If the real server is deleted and added again
it  is not put with zeroed connection counters (remember for
the  trash), i.e. may be the director thinks it is even more
loaded  than the  time it was  deleted. This  is because new
connections  are not created to this service, the traffic is
stopped  and LVS doesn't  update the entry  state. So, it is
possible some connections to expire in the real host but not
to  be  marked in  the  director.  So,  in  this case  it is
recommended  even fast start :)  Remember that in LVS/DR and
LVS/TUN  mode  the  Director  listens  only  to  the clients
packets,  what  the  clients  think  is  the  state  of  the
connection. This is different from the number of connections
accounted  in the  real server.  "least connections" methods
are  easy to maintain  but are not  correct. The real host's
load  must be used as weight.  The problem is that each kind
of  real service leads  to different load  in the real host.
Don't rely on the "lc" and "wlc" methods fully to distribute
the  load. If you consider the  real host's load there is no
problem with any slow/fast starts.

> 
> $B"#(BSynGuard
>     The SynGuard feature limits the rate of TCP SYNs handled by
>     a virtual server to prevent a type of network problem known as
>     an SYN flood denial of service attack. A user might send a large
>     number of SYNs to a server, which would overwhelm or crash the
> server,
>     denying service to other users. The SynGuard feature prevents
>     an SYN flood denial of service attack from bringing down IOS SLB or
>     a real server. SynGuard monitors the number of SYNs to a virtual
>     server over a specific time interval and does not allow the number
>     to exceed a configured SYN threshold. Once the threshold is reached,
> 
>     any new SYNs are dropped

        In  NAT mode when secure_tcp is enabled LVS tries to
listen  to the real server replies.  If the TCP handshake is
completed  this connection  is marked as  established in the
director's table. Before that we use little timeouts for the
entry  and we  don't follow some  of the TCP  flags from the
client's  packets.  This  mode (secure_tcp)  is suitable for
most  of  the known  services. Of  course, the  real servers
must  be tuned too:  SYN cookies, SYN-ACK  retries, etc. The
state timeouts in the director must be tuned too. Of course,
this complex task results in a violation of the TCP protocol
but the result is very good. The valid clients can work, the
Director's memory is not full.

        This is only one of the defense strategies used from
LVS.   There are more strategies you  can read about, in the
above URL. If that is not enough you can try with the packet
schedulers  (CONFIG_NET_SCHED) which work  on lower (device)
level.

> 
> Regards.
> zhao.


Regards

--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>



<Prev in Thread] Current Thread [Next in Thread>