|
On Tue, Aug 23, 2005 at 07:20:23PM +0530, Vijay K wrote:
[snip]
> since i am using checktype as connect my ipvsadm shows weight of both my
> real servres as 1. but when i login into the director which directs to the
> real server,the activeconn column is not getting changed. When i login the
> inactive conn column is getting some value..Can somebody let me know what
> does these columns mean and also when i log in repeatedly also the
> connection is going to the first realserver all teh tiems even though its
> been mentioned rr in config file.
Connect checks just open up a connection to the real-server. If that
works, then the check succeeded and the weight will be set to non-zero
(in your case 1), otherwise it fails and is set to 0. Negotiate checks
are more complex, they open a connection to the real-server, send a
protocol specific request (in your case HTTP) and parse the result for
an expected string. This is intended to check that not only the
real-server is listening, but that it is also capably of serving
requests. If the request you make as a test is representative of the
sort of request that end-users will be making, then this is a pretty
good test that the end-users will be able to get what they are after,
and all is well.
If connect checks are working for you, this probably means
that the real-servers are there and working. If negotiate
checks are not working in the same setup, it probably means
that your the request URL, when retrieved from the real-server,
is either inacessable, or doesn't contain the reply string.
Its pretty easy to debug this either using the -d option
to ldirectory, or just manually requesting the URL, and checking
for the reply string.
For example, lets say your have an http service, one of your real
servers is 10.10.30.30, your request is "index.html" and your reply
string is "Test". You could easily see what is going on using something
like:
lynx -source http://10.10.30.30/index.html
lynx -source http://10.10.30.30/index.html | grep "Test"
The ActiveConn count is the number of connections in the
TCP ESTABLISHED state. This means they have successfully
completed the 3-way handshake, and have not been subsequently
closed by either end. The InActConn is connections in all
other states. If you are seeing InActConn rising, but no ActiveConn,
then it either means, that the connections are completing very quickly,
or the three way handshake isn't completing. In the case of the former
the end-user should get their web page, in the case of the latter they
won't, so it should be pretty easy to work out which is occuring.
You can also view information on all conections by running ipvsadm -L -n.
Ignore the ones with a end-user port of 0, they are internal data for
persistance, not actuall connections.
If you are having problems with the handshake, this most likely means
that the real servers are not handling connections correctly. This
could be because apache isn't alive, or more likely becuase their
default gateway is not set to the linux director.
It could also be because you are trying to access the LVS cluster
from the network that the real-servers are on. This does not work
without mucking around - and I forget exactly how this is done,
see the HOWTO if you really want this.
In any case using tcpdump or ethereal on the linux-director,
real-server and if possible the end-user should show you where
packets are going, and at what point they disapear. This, in
conjunction with using ipvsadm -L -c -n, should allow you
to narrow down the problem.
I notice that you have persistance set with a timeout of 600 (seconds).
This means that if the same end-user reconnects to the virtual service
while a previous connection is still open, or within 600 seconds of
closing the most recent connection, then it will be sent to the same
real-server. This means that rr won't come into effect if you
are just testing from the same end-user. Try turning persistance off,
reducing its timeout (drastically), or using different end-user machines
if you want rr to come into play.
--
Horms
|
