LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Problem with RR scheduling method?

To: Lorn Kay <lorn_kay@xxxxxxxxxxx>
Subject: Re: Problem with RR scheduling method?
Cc: Thomas.Proell@xxxxxxxxxx, lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Tue, 7 Nov 2000 21:51:29 +0000 (GMT)
        Hello,

On Tue, 7 Nov 2000, Lorn Kay wrote:

> I guess I should have said that I can force a connection to either server by
> simply removing the other one from the ipvsadm hashed routing table.

        Please, show every action you take for this RR "test", step by
step. The output you posted in the previous mail does not show anything
wrong. I don't understand, where is the real problem?

        FYI, when a real server is deleted with ipvsadm -d,
ipvsadm -D or ipvsadm -C, the connections to this server are not
deleted. If you add the same real server again to its virtual service,
the connections that were blocked (and are not expired yet) can continue,
for example after TCP retransmissions. This is a good reason after
ipvsadm -C, ipvsadm -A and ipvsadm -a you to see any connections in
the statistics. Is this the case?

> My ipchains is very big and ugly, I've tried to just pull out this relevant
> part:
>
> Chain input (policy DENY):
> target     prot opt     source                destination           ports
>
> <snip>
> -          tcp  ------  0.0.0.0/0            200.100.100.31          * ->
> 80
> -          tcp  ------  0.0.0.0/0            200.100.100.31          * ->
> 443

        I assume the above is the marking (ipchains -L -v -n)

> ACCEPT     tcp  ------  0.0.0.0/0            200.100.100.31        1024:6553
>   ->   80
> ACCEPT     tcp  ------  0.0.0.0/0            200.100.100.31
> 1024:65535 ->   443
>
> <snip>
>
> (Where "200.100.100.31" would be the VIP I'm using for the FWMARK 3). (This
> isn't really my VIP).

Regards

--
Julian Anastasov <ja@xxxxxx>



<Prev in Thread] Current Thread [Next in Thread>