|
Hi Julian,
On Fri, 2 Sep 2005, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 1 Sep 2005, Agostino di Salle wrote:
>
> > Hi,
> > I think there are three bugs in LVS code that are related to the problem
> > reported in this mailing list by other users ("taking realserver out for
> > maintenance" and similar problem).
> >
> > The first problem is that LVS don't expire ESTABLISHED connection that
> > point to a realserver with weight == 0 when expire_nodest_conn is enabled.
>
> This is intentional, the flag is for deleted real servers.
> It is known that people desire different things when setting weight
> to 0 but the current semantic is that it does not drop connections
> in the middle.
I can understand the current semantic but:
- if I'm putting a real server out-of-service for maintenance (setting
weight to 0) it could be nice to let finish the current ESTABLISHED
session.
- if the monitoring software (example keepalived) report the failure of
a the real server (server stop responding due to server unreachable or
process down) setting its weight to zero, it would be nice to notify
immediatly to the client the failure of the real server instead of having
the client waiting the tcp timeout to close the connection.
If the monitoring software put the weight to zero instead of deleteing
the real server and expire_nodest_conn is enabled, maybe it is reasonable
to delete the connections...
IMHO, the best solution is to have for both virtual and real servers two
more variables:
* admin_status = in-service, out-of-service, no-new-connection
* operational_status = ok, failed
In this way a iser or a monitoring software can decide what to do of
current connection in any possible situation.
> > The second problem is that LVS don't expire connection template
> > (persistent connection information) that point to a realserver with weight
> > == 0 when expire_quiescent_template is enabled.
>
> This is bug but the right fix is to replace 'if (ct->cport)'
> with 'if (ct->vport != 65535)', it seems i broke it with some
> hashing optimizations.
correct, this way you invalidate the template just one time saving
resource. Maybe it could be nice also to reset the timeout of the
invalidated template to 60 sec in order to delete the entry from the
connection table ASAP.
> > The third problem is that LVS refresh connection template expire time only
> > on new connection and not everytime that a packet arrive for a real
> > connection related to an existing connection template.
>
> Wensong should comment if a flag is useful for such behavior.
> But a solution that sets timer to the persistent timeout when last
> connection is detached in ip_vs_control_del is more acceptable, there
> is no reason to waste resources for every packet.
correct, the connection template expire only after the last
controlled connections expires, so it would be best to reset the template
timer everytime a controlled connections expires.
regards,
Agostino
|
