|
ons 2006-11-29 klockan 09:57 -0800 skrev Joseph Mack NA3T:
> On Wed, 29 Nov 2006, Olle ~Vstlund wrote:
>
> > I closed down (set weight = 0) one of our realservers and let the
> > collections drop for 20 minutes. During this time I took snapshots of
> > the connections on the director (cat /proc/net/ip_vs_conn) and on the
> > realserver (netstat -an) at different moments in time. Now, I can
> > compare the /proc/net/ip_vs_conn- and netstat-output. What should I look
> > for?
>
> don't really know, but how about
>
> o do the connections go down at the same rate on the
> director and the realserver?
I now have analysed the data from the realserver close yesterday. The
connections at the realserver disappear within minutes, but at the
director they "just keep hanging on..."
Drop off rate at the director ("cat /proc/net/ip_vs_conn", only the connections
directed at the realserver is counted):
Before 41872 (925 ESTABLISHED)
After 0 minutes: 41796 (931 ESTABLISHED)
After 4 minutes: 41437 (907 ESTABLISHED)
After 12 minutes: 41428 (787 ESTABLISHED)
After 16 minutes: 41386 (772 ESTABLISHED)
After 20 minutes: 41380 (773 ESTABLISHED)
After 23 minutes: 41385 (774 ESTABLISHED)
Drop off rate at the realserver ("netstat -an", only LVS-handled
webserver-connections counted):
Before 167 (31 ESTABLISHED)
After 0 minutes: 93 (28 ESTABLISHED)
After 4 minutes: 0
After 12 minutes: 0
After 16 minutes: 0
After 20 minutes: 0
After 23 minutes: 0
> o does the drop off rate on either machine have anything to
> do with FIN_WAIT time (about 2mins)
I'm trying to understand how ipvs is using the connection-table. It's
used to keep track of all connections I've understood. What I do not
understand is what is actually happening when a realserver is assigned a
weight of 1. I thought this would mean that there would be no new
connections (or new clients) dispatched to the realserver. I wrote a
perlscript to check this out, and arrived at very surprising results.
The script is reading all connections from one of
the /proc/net/ip_vs_conn-snapshots I collected, and then it compares all
connections to the content of another snapshot. First I let a connection
be identified by Protocol + FromIP + FromPort + ToIp + ToPort + DestIp
(i e the six leading fields of a /proc/net/ip_vs_conn-record). The
script suggested that later snapshots contained connections which were
not found in earlier snapshots? I then figured that ipvs allow existing
clients (FromIp?) to open new connections, so perhaps Protocol + FromIP
+ FromPort + ToIp + ToPort + DestIp is not a good
"connection-identifier" for my purposes after all. Instead I tried using
FromIP as a sole identifier of a connection. I ran the script again and
it still suggested that "new connections" were popping after the
realserver had been closed. I have manually verified that new FromIps
are actually popping up in the directors ipvs-table, directed at the
realserver whos weight is 0. This didn't make sense? Then I checd the
STATE of the connections popping up. It was generally CLOSE but I also
saw an ESTABLISHED. My conclusion is that the only implication of
assigning a realserver weight 0 is that SYN-request from a new client
will not be sent to the realserver, but all other types of IP-packets
will be sent there. Is this somewhere near to the truth?
|
