|
Well, I'm not sure if I should claim this is problem with LVS
implementation.
Since LVS-TUN uses IP masquerading, client IP, port was being bound to a
destination. The timeout of this binding is TCP_TIME_WAIT ~2mins.
In our setup, we have client IP, port "reuse" much faster than this 2mins,
since we are using a few client machines, and driving a high thruput
server.
So when a node(real server) goes down, all its client bindings are
transferred to other nodes, but when it comes back up, they don't get
redistributed, b'cause the bindings don't timeout soon enough!!!! :(
So as a result the new node gets a trickling few requests(few masquerding
entries have timed out)
This short interval (IP, port) reuse, I guess is not a practical
scenario, but for experimental testbeds it is...
The solution I applied was to reduce the MASQ_TIME_WAIT and also to
enforce that every new SYN (thank TCP for this) goes to scheduler
by taking a MASQ cache miss(this does not appear to be such a performance
hit). Works great!!
- Kiran
On Mon, 18 Nov 2002, Joseph Mack wrote:
>Kiran Nagaraja wrote:
>
>> Mon correctly removes an unreachable backend node (node crash). And
>> dutifully adds it back when the node comes back up. and ipvsadm shows all
>> the 5 nodes are active in the set. But at this point, the node in question
>> sees only about 1-5 requests/sec???? While the others are seeing almost
>> N/4 requests/sec instead of N/5 where N was 500 in our case. Any ideas
>> why this would happen?
>
>nothing obvious.
>
>How about you disassemble the failout process, ie remove a realserver
>with ipvsadm from the command line, and then add it back, and see
>the request rate.
>
>Joe
>--
>Joseph Mack PhD, Senior Systems Engineer, SAIC contractor
>to the National Environmental Supercomputer Center,
>mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
>
>_______________________________________________
>LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
