|
Hello,
On Fri, 4 Aug 2000, Tim Wu wrote:
> I found another problem.
> I setup only 2 real servers before starting AB and
> add one while ab is sending. It don't dispatch connections to this
> new real server until I stop AB and wait for a moment.
I already tried to explain this problem. I'll try
again. When you flood the LVS with limited number of client
ports, by default 1024..4999, you can see only N*(5000-1024)
connections in the LVS table. N=Number of client hosts. This
is because the connections are reused, i.e. the new SYN hits
existing entry which is not timed out. But it is already
bound to specific real server. If you add new real server at
this time when your test tool continues to flood LVS with
high rate and all connections are bound to real server, no
new connections are scheduled to the new real server. With
the same high rate if you remove real server, all
connections to this real server are blocked, i.e. their
timeout is not refreshed and if you don't add the real
server in short period of time, these entries expire. After
that point the new connections from the blocked
CLIENT_IP:CLIENT_PORT are scheduled to other (active) real
server.
So, in your test, if you remove a real server, you
can expect that after a little period of time (minutes) some
of the entries will expire. This depends on their state.
They will not block forever. If they block forever this is a
LVS bug. The max default timeout is 15 minutes.
>
> I am sure it's not a problem of LVS because LVS can
> dispatch connections from another client to new real server .
Yes, in a setup with small number of clients you can
expect your flood tools to block. This is the same what
happens with the real clients when you remove real server.
They are blocked until the entry expires or until the real
server is added and the TCP successfully recovers the
connection after retransmissions. If the entry expires the
SYN from this CIP:CPORT will not hit blocked entry (real
server) and will be scheduled to new real server. But
normally, the clients can create new socket and start new
connection from another CIP:CPORT. This connections will not
block except if it is served from persistent service. But
your test tool may be occupies all client ports and so it is
completely blocked. If your client autobinds to port
1024..4999 the min rate that triggers this problem is
(5000-1024)req/60sec, if 60sec is the average timeout for
your connections to expire, i.e. TIME_WAIT/FIN_WAIT state.
I.e. 66req/sec. 67req/sec leads to such problem because
there is a connections which is reused and that can block
the client if the connections are not created in parallel.
>
> Anyone know why? Thanks for help.
The same reason. Connections are reused before they
expire and so are always bound to same real server.
> ----- Original Message -----
> From: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
> To: Tim Wu <chtimwu@xxxxxxxxxxxxxxxxx>
> Sent: Friday, August 04, 2000 12:04 PM
> Subject: Re: hot-plug realservers
> >
> > Hello,
> > The connections are reused and forwarded to the same
> > blocked real server. If you delete the real server for short
> > time it is possible some of the TCP connections to continue
> > after you add it again.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
