|
Hi all,
On Fri, 26 Nov 1999, Wensong Zhang wrote:
> Currently, the LVS can handle ICMP packets for virtual services, and
> forward them to the right place. It is easy to set the weight of the
> destination zero or temperarily remove the dest entry directly, if an
> PORT_UNREACH icmp from the server to the client passes through the LVS
> box.
PORT_UNREACH can be returned when the packet is rejected from the
real server's firewall. In fact, only UDP returns PORT_UNREACH when the
service is not running. TCP returns RST packet. We must carefully handle
this (I don't know how) and not to stop the real server for all clients if
we see that one client is rejected. And this works only if the LVS box is
default gw for the real servers, i.e. for any mode: MASQ(it's always def
gw), DROUTE and TUNNEL (PROT_UNREACH can be one of the reasons not to
select other router for the outgoing traffic for these two modes). But LVS
cn't detect the outgoing traffic for DROUTE/TUNNEL mode. For TUNNEL it can
be impossible if the real servers are not on the LAN.
So, the monitoring software can solve more problems. The TCP stack
can return PORT_UNREACH but if the problem with the service in the real
server is more complex (real server died, daemon blocked) we can't expect
PORT_UNREACH. It is send only when the host is working but the daemon is
stooped. Please restart this daemon. So, don't rely on the real server,
in most of the cases he can't tell "Please remove me from the VS
configuration, I'm down" :) This is job for the monitoring software to
exclude the destinations and even to delete the service (if we switch to
local delivery only, i.e. when we switch from LVS to WEB only mode for
example). So, I vote for the monitoring software to handle this :)
Regards,
Julian Anastasov
|
