|
Patrick,
My tuppence worth...
Personally I think monitoring of systems is probably one of the things the
lvs system shouldn't really get into in it's current form. My rationale
for this is that it's effectively a fancy packet forwarder, and in that
job it excels.
For the LVS code to do more than this, it would require for TCP services
the ability to attempt to connect to the *service* the kernel is load
balancing - which would be a horrible thing for a kernel module to do. For
UDP services it would need to do more than pinging... However, in neither
case would you have a convincing method for determining if the *services*
on those machines was still running effectively, unless you put a large
amouunt of protocol knowledge into the kernel. As a result, you would
still need to have external monitoring systems to find out whether the
services really are working or not.
For example, in the pathological case (of many that we've seen :-) of a
SCSI subsystem failure resulting in indestructable inodes on a cache box,
a cache box can reach total saturation in terms of CPU usage, but still
respond correctly to pings and TCP connections. However nothing else (or
nothing much) happens due to the effective system lockup. The only way
round such a problem is to have a monitoring system that knows about this
sort of failure, and can then take the service out.
There's no way this sort of failure could be anticipated by anyone, so
putting this sort of monitoring into the kernel would create a false
illusion of security - you'd still need an auxillary monitoring system.
Eg - it's not just enough for the kernel to mark the machine out of
service - you need some useful way of telling people what's gone wrong (eg
setting off people's pager's etc), and again, that's not a kernel thing.
All just my tuppence worth of course :-)
Michael.
--
National & Local Web Cache Support R: G117
Manchester Computing T: 0161 275 7195
University of Manchester F: 0161 275 6040
Manchester UK M13 9PL M: Michael.Sparks@xxxxxxxxxxxxxxx
On Wed, 24 Nov 1999, Patrick Kormann wrote:
> Hi!
>
> The hint about the /all/arp_invisible worked great, thanks.
> One feature I'm missing in the lvs-project. Wouldn't it be nice to have a
> switch that would tell ipvsadm 'If one of the realservers is
> unreachable/connection refused, take it out of the list of real servers for
> x seconds' or even 'check the availability of that server every x seconds,
> if it's not available, take it out of the list, if it's available again, put
> it in the list'. That would eliminate the need for seperate checking tools
> and quirks to make lvs a real high-availability system. The problem is that
> all those external checks are never as effective as a decition be the
> 'virtual server' could be.
>
> Mit freundlichen Grüssen
>
> Patrick Kormann
> DataComm (Schweiz) AG
>
>
> ----------------------------------------------------------------------
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
>
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
