|
On Friday 09 November 2007, Joseph Mack NA3T wrote:
> On Fri, 9 Nov 2007, Ruben Laban wrote:
> > Hello list,
> >
> > No ideas on the issue stated below as of yet?
>
> apparently not (just so you don't think you're being
> ignored, sometimes we don't have an answer).
I'm aware of that. I'm no fan of 'bumping' threads to get attention in
general, but this one has been bugging me for quite some time now.
> > What could cause entries in the IPVS table to remain in
> > the established (or any other) state even though there is
> > no traffic flowing between the CIP/VIP/RIP?
>
> neither end has closed the tcp connection?
That's one very likely scenario. We're using LVS-DR so the director only sees
half the traffic. Except you'd think (or atleast I do) that after a given
timeout period, the entry would be purged eventually. I just checked the IPVS
table on our backup loadbalancer, and it had ~125000 entries! Of which ~6000
with state ESTABLISHED. The last failover occured october, 23rd. I'd think
those entries should have expired by now?
> > We're using persistency by the way. Though from what I've
> > read, the given persistency timeout is only used once when
> > a new connection arrives.
>
> there are lots of problems with persistency, but it was the
> first method we got to work for maintaining
> client-realserver affinity. Another less intrusive method is
> the -SH scheduler. You might find it causes less problems.
I'm not fond of having to enable persistency on our loadbalancers, but the web
application that's behind it, requires it, unfortunately.
I've looked into the -SH scheduler as well a while ago. But I couldn't find
enough information on it. Especially the behaviour when one realserver goes
down. Will the hashing scheme cause all connection to be kicked to another
realserver because of the redistribution of the hash due to the number of
realservers changing?
Regards
--
Ruben
|
