|
Julian Anastasov wrote:
>
> 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 :)
Yeah, I prefer that monitoring software handles this too, because it
is a unified approach for VS-NAT, VS-TUN and VS-DR, and monitoring
software can detect more failures and handle more things according to
the failures.
What we discuss last time is that the LVS kernel sets the destination
entry unavailable in virtual server table if the LVS detect some icmp
packets (only for VS-NAT) or RST packet etc. This approach might
detect this kinds of problems just a few seconds earlier than the
monitoring software, however we need more code in kernel to notify the
monitoring software that kernel changes the virtual server table, in
order to let the monitoring software keep the consistent view of the
virtual server table as soon as possible. Here is a tradeoff.
Personally, I prefer to keeping the system simple (and effective),
only one (monitoring software) makes decision and keeps the consistent
view of VS table.
Thanks,
Wensong
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
