|
Hello,
First of, the various FAQ entries about SH weight needing to be x2 the
number of expect connections seem not to be true for any recent (2.6.2x
at the very least) kernel. A weight of 1 for each real-server works just
fine here with more then 30 connects/s, hundreds of active and thousands
of inactive connections.
What however does not work is setting the weight to 0 and having quiescent
active. New connections will still be routed to the (now likely dead)
real-server.
None of the /proc/sys/net/ipv4/vs/expire* flags influence that, not a big
surprise as they deal with persistence, but better to try things out before
whining on the ML. ;)
What this means is that it is impossible to have a zero impact server
maintenance with SH, something that is nearly as much a reason to deploy
LVS in many cases as the actual load balancing.
My C abilities are utter crap, but looking at the relevant code from we
see:
dest = ip_vs_sh_get(tbl, iph->saddr);
if (!dest
|| !(dest->flags & IP_VS_DEST_F_AVAILABLE)
|| atomic_read(&dest->weight) <= 0
|| is_overloaded(dest)) {
return NULL;
}
So in theory a weight of 0 (or less :-p) would result in a NULL return for
the destination address. But what I am seeing is it still trys to route
things to the destination based on the hash table, as before.
Does that mean that the if statement doesn't work properly, maybe some
parenthesis like this (atomic_read(&dest->weight) <= 0) would help?
As an aside question, what _would_ the upper layer do when it gets a NULL
back here? My feeling is that a simple "skip to the next real-server"
algorithm would be the best handling. It would probably beat recreating
the hash table every time a real-server weight goes to 0.
Something obvious I'm missing? Any easy patch to fix this?
Regards,
Christian
--
Christian Balzer Network/Systems Engineer NOC
chibi@xxxxxxx Global OnLine Japan/Fusion Network Services
http://www.gol.com/
|
