LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Failover with a high persistent timeout

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Failover with a high persistent timeout
Cc: Matthias Krauss <MKrauss@xxxxxxxxxxxxxx>
From: Roberto Nibali <ratz@xxxxxx>
Date: Fri, 13 Sep 2002 12:45:06 +0200
Hello guys,

        Note that setting 0 as RS weight is assumed as "stopped
temporary". The existing connections continue to work. It is
assumed that the RS weight is set to 0 some time before deleting
the RS. By this way we give time for all connections/sessions
to terminate gracefully. Sometimes weight 0 can be used from
health checks as a step before deleting the RS. Such two-step
real server shutdown can avoid temporary unavailability of the
real server. Graceful stop. At least, the health checks can
choose whether to stop the RS before deleting it.

It's also useful to introduce a service level window for maintainance work. If you have a strict SLA with only a few minutes downtime a year and you need to exchange the HD of one RS you can quiesce that particular RS about 1 hour before the maintainance work and if you have a resonable low or most of the time even no active connection rate, you unplug the cable, shutdown the server and fix the problem. Then you put it back in, set the weight to >0 and off you go :)

        If the RS is deleted the traffic for existing conns is
stopped (and if expire_nodest_conn sysctl var is set the conn entries
are even deleted). Of course, if for some connections we don't see packets
these conns can remain in the table until their timer is expired.

Ahh, forget about that one. Joe can you add this to the Howto (Changelog entry)?

        * Added the net.ipv4.vs.expire_nodest_conn sysctl variable.

        The default value is 0, the load balancer will silently drop
        packets when its destination server is not available. It may be
        useful, when user-space monitoring program deletes the destination
        server (because of server overload or wrong detection) and add
        back the server later, and the connections to the server can
        continue.

        If this variable is set 1, the load balancer will expire the
        connection immediately when a packet arrives and its destination
        server is not available, then the client program will be notified
        that the connection is closed. This is equivalent to the feature
        some people requires to flush connections when its destination is
        not available.

BTW, has anyone ever tested this stuff, Julian?

        For non-persistent virtual servers the new conns are always
scheduled to "started" real servers. For the persistent VS the
handling is different, there is an issue with the current persistence
handling when RS weight is set to 0: new connections can be scheduled
to "stopped" RS if "affinity" for this client exists. It is good for
setups that prefer to serve even new connections from client that
finishes its session (multiple connections) to the stopped RS. It is
not good for setups that expect the traffic to stop. Bad clients
can decide never to stop their traffic and to keep the conns open.

Typically http traffic.

        So, sometimes it can be a bad idea the health checks to
play only with weight 0, sometimes it is preferred the RS to be
deleted, usually when persistent virtual servers are used. Or
may be we can implement some control mechanism for such options.
Any ideas for tunable parameters?

I have to check back with you guys on the upcoming 1.1.0 release to see if something general can be put in. Also the per RS threshold limitation stuff was something that would have gone into that direction.

        It is true that we don't have much/any control in the conn
expiration process. May be the devel IPVS 1.1.0 will solve this problem.
Currently, the only way to forget about all connections is to unload
the ipvs module. May be a new conn expiration method can allow the conn
entries to be deleted from any context.

In the netfilter development there is an ugly patch floating around called ctnetlink. Together with a student we've built a new logging mechanism on top of it. Harald was to rewrite the ctnetlink patch and generate a global/general nfnetlink stucture, where one has the possibility to twiddle with every single knob and function he'd like. Maybe we can copy some of the work done there, although I think they first need to clean that stuff up, for example to use netlink sockets and proper locking.

Cheers,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc



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