LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Failover with a high persistent timeout

To: Roberto Nibali <ratz@xxxxxx>
Subject: Re: Failover with a high persistent timeout
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx, Matthias Krauss <MKrauss@xxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 13 Sep 2002 14:16:05 +0300 (EEST)
        Hello,

On Fri, 13 Sep 2002, Roberto Nibali wrote:

> BTW, has anyone ever tested this stuff, Julian?

        May be yes but you better to ask Wensong

> >     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.

        The release is going to happen soon :) It will be a
really devel version with some things still missing :) BTW, Wensong added
some stuff related to RS thresholds. Contact him before going
to sync with 1.0.x, 1.1.0 has some changes.

> >     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.

        Sounds good. What does not make me happy is the bad
interaction with the routing. Currently, it is not possible
Netfilter NAT and especially IPVS to work on routers connected to
multiple ISPs and using multipath routes.

        BTW, I have simple idea of moving IPVS to netlink
configuration, where we move the data in the var=value form, nothing
special. The FIB and tc are good examples. But some functions will
be needed to simplify these talks.

> Cheers,
> Roberto Nibali, ratz

Regards

--
Julian Anastasov <ja@xxxxxx>



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