Re: [lvs-users] Trying Hard to Understand the Sync Daemon's Behavior

[Sebastien Termeau <st@xxxxxxxxxxxxxxxx>]

Hi Eric,

Thanks to your post I realized I had a similar problem.
I was not using syncid thus the backup was polluted by the connection info
coming from the master of another cluster.
Are you using the same syncid in a different cluster on the same network?
I think the chapter "37.3" explains the timeout difference on the master and
the backup.
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.server_state_sync_demon.html

I made a modification to LVSSyncDaemonSwap so I can specify the syncid in
the haressource file like this:
       LVSSyncDaemonSwap::master::eth0::15 \

I will send the patch in a separate email on the list.
Regards

Sebastien


On Tue, Aug 4, 2009 at 11:51 PM, Robinson, Eric <eric.robinson@xxxxxxxxx>wrote:

>
> [horms]
> > That is strange. Are these connections that have never
> > appeared on the master?
>
> It's hard to say, but it seems so. Take a look at the following, where
> lb02 is the active load balancer and lb01 is passive.
>
> [root@lb02 ~]# ipvsadm -Lcn|wc -l
> 1286
>
> [root@lb01 ~]# ipvsadm -Lcn|wc -l
> 2228
>
> The passive load balancer has 1000 more connections in its table! Then
> if we look at the actual table entries, we see this on lb01..
>
> [root@lb01 ~]# ipvsadm -Lcn|sort -k 4|more
> IPVS connection entries
> TCP 02:21  NONE        10.0.0.154:0       192.168.5.100:3053
> 192.168.10.64:3053
> TCP 00:43  ESTABLISHED 10.0.0.154:3752    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 01:43  ESTABLISHED 10.0.0.154:3753    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 02:14  ESTABLISHED 10.0.0.154:3754    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 02:14  ESTABLISHED 10.0.0.154:3755    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 02:21  ESTABLISHED 10.0.0.154:3756    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 02:55  NONE        10.0.0.180:0       192.168.5.100:3053
> 192.168.10.64:3053
> TCP 00:55  ESTABLISHED 10.0.0.180:4671    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 02:55  ESTABLISHED 10.0.0.180:4677    192.168.5.100:3053
> 192.168.10.64:3053
> <snip>
>
> ..but this on lb02...
>
> IPVS connection entries
> TCP 05:14  NONE        10.0.0.154:0       192.168.5.100:3053
> 192.168.10.64:3053
> TCP 01:51  FIN_WAIT    10.0.0.154:3756    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 00:01  CLOSE       10.0.0.154:3761    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 00:01  CLOSE       10.0.0.154:3762    192.168.5.100:3053
> 192.168.10.64:3053
> TCP 05:42  NONE        10.0.0.180:0       192.168.5.100:3053
> 192.168.10.64:3053
> TCP 14:42  ESTABLISHED 10.0.0.180:4680    192.168.5.100:3053
> 192.168.10.64:3053
>
> This is just the top of the table sorted by client IP, but note that
> lb01 has 2 more entries for host 10.0.0.154 than lb02 does, and 1 more
> entry for host 10.0.0.180.
>
> [horms]
> > With regards to not timing out, do you have persistence set?
>
> About 2/3 of my ledirectord.cf entries do have persistence set.
>
> [jason faulkner]
> > Are the TCP timeouts for LVS in /proc set the same?
>
> The only timeout setting I see is /proc/sys/net/ipv4/tcp_fin_timeout,
> which is set to 60 on both load balancers.
>
> --
> Eric Robinson
>
>
>
>
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users