|
Hello,
On Fri, 2 Sep 2005, Agostino di Salle wrote:
> > 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.
It is now in this way, weight 0 stops only new connections
that reach the schedulers. The question is how long to wait these
connections to finish. The user tool can delete the real server
some time after weight was set to 0. If weight 0 is set for short
time there is no need to drop connections. Weight 0 allows the real
servers to shutdown existing connections if the reloaded resource
requires so, we don't stop the traffic that closes such connections
or sessions. Removing connections in IPVS is not the first priority, you
can always use the defense settings to save memory by removing
connections. First IPVS priority is to allow real server and client to
talk. If real server is put back in service and the real server
didn't closed any connections they can continue, in some cases
long living and inactive connections do not notice that weight was set to
0 as RS didn't closed them. The main thing is that you have two steps: set
weight to 0 and then remove real server. May be it is not enough in
some cases.
> - 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.
ICMP_PORT_UNREACH to established client?
> 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...
expire_nodest_conn works for active connections, inactive
connections still can remain.
> 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
Yes, it can be a per RS integer with flags as relying only on
weight==0 is not enough. Then IPVS can know what to do in different
situations:
- stop new connections (it is always assumed)
- stop new connections (in session) scheduled by persistent template
- reply with ICMP_PORT_UNREACH to break active connections
- drop packets (expire_nodest_conn)
- break persistence (expire_quiescent_template)
Regards
--
Julian Anastasov <ja@xxxxxx>
|
