|
> > Before 41872 (925 ESTABLISHED)
>
> I assume 41872 is total (FIN_WAIT + ....) and 925 is only
> the ESTABLISHED connections
Correct.
> > 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)
>
> this is not right. It should be similar to the drop
> off for the realserver you show below.
Explain why it should be the same?
> Why do you have ESTABLISHED connections after 23 mins?
> Shouldn't they all have reconnected to another realserver?
> So both the ESTABLISHED and FIN_WAIT counters are wrong
> on the director?
We are running the heartbeat/ldirectord LVS shipped with SLES9. In this
setup you don't setup/use ipvsadm directly, but via ldirectord. We have
the ldirectord "quiescent"-attribute is set to true (it's default).
quiescent = [yes|no]
If yes, then when real or failback servers are determined to be
down, they are not actually removed from the
kernel's LVS table. Rather, their weight is set to zero which
means that no new connections will be accepted.
This has the side effect, that if the real server has persistent
connections, new connections from any existing
clients will continue to be routed to the real server, until the
persistant timeout can expire. See ipvsadm for
more information on persistant connections.
If no, then the real or failback servers will be removed from the
kernel's LVS table. The default is yes.
According to the text above it will produce "server affinity" if "the
real server has persistent connections". If this is the same
"persistense" as in the ldirectord-config (and ipvsadm-config) then we
do not have it set. Nothing is said about it's effects when you do not
have "persistence" set. Is this what we are seeing in our system?
> >
> > 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.
>
> weight=0 means no new connections.
Ok. But if we have "quiescent" set to true and ipvs-persistence set,
then the director would allow new connections from existing clients be
sent to the closed realserver, wouldn't it?
> each new connection request will come from the next port up
> in the list, ie if the last connection was from FromIP:3001,
> the next will be from FromIP:3001.
Ok. So if we have a system as ours (quiescent = true, no ipvs
persistense) should these connections be alloved to be sent to a closed
(weight 0) realserver? Your final comment suggests it shouln't, right?
> > 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.
>
> not right.
Is this "not right" as in "malfunctioning system"?
> > 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?
>
> mostly yes. weight=0 means that current connections are
> maintained. However it's only with persistence that clients
> will be able to make new connections to the same realserver
> (if they connect within the persistence time) (and you don't
> have persistence). Without persistence, a new connection
> request (SYN) will be sent to a realserver with weight!=0.
> In an apache/httpd/html situation, the client-server
> connection is not neccessarily closed after the hits are
> served to the client (the client, or the server can
> explicitely shut them down, but usually will not). I assume
> Tomcat is much the same. So the client will be able to get
> more hits through an ESTABLISHED connection. The director,
> using its own timeouts may not realise that the connection
> has dropped and will send a new request (I think) to the
> same realserver, although I expect the director should see
> the SYN as a new connection request.
>
> Are you using the latest kernel/ipvs?
We are using 2.6.5-7.244-smp at the director and 2.6.5-7.97-bigsmp at
the realserver. We are trying to use the latest kernel which
HP-recommends for the Proliant (we want the HP-management drivers to
function properly). The realserver is lagging behind somewhat as you can
see.
Our option is to go on the SLES10-train. It has not been out for very
long though. Are you familiar with Suse Enterprise and can recommend
something from the LVS point-of-view?
|
