LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] ldirectord seems stuck

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] ldirectord seems stuck
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Fri, 25 Jul 2008 10:30:09 +1000
On Tue, Jul 22, 2008 at 04:50:27PM -0700, Michael Moody wrote:
> I have two servers, set up using heartbeat/ldirectord.
> (all files are the same on both servers, such as the ldirectord.cf, both have 
> all software updates)
> 
> In my ldirectord.cf I have the following:
> 
> virtual=10.0.0.195:21
>         real=192.168.1.195:21 gate 1
>         fallback=192.168.1.196:21 gate 1
>         protocol=tcp
>         service=ftp
> #       login="testftp"
> #       passwd="testftplvs1"
>         persistent=30000
> 
> On the lvs1 machine, it reverts to the fallback (192.168.1.196), even though 
> the real server is up. I have verified connectivity via the ftp program on 
> the lvs1 server itself.
> 
> TCP  10.0.0.195:21 wrr persistent 30000
>   -> 192.168.1.196:21             1         2           0          1
> 
> On the lvs2 machine, the ipvs table correctly shows the primary real server 
> as active:
> 
> TCP  10.0.0.195:21 wrr persistent 30000
>   -> 192.168.1.195:21             1         2           0          1
> 
> Either as a result of this, or as a cause of this, after so long, the health 
> checks on the lvs1 box begin to stall, meaning dead servers are not removed 
> from the table. I have had to switch to lvs2 as my primary for the moment.
> 
> Can anyone help me to explain/solve this?
> 
> (arp tables show the same mac for 192.168.1.195 on both lvs2 and lvs1)

This is most likely cause by ldirectord thinking that 192.168.1.196:21
is down, even though it is not. Or in other words, when it tries to log
into 192.168.1.196:21 using ftp, it fails for some reason.

As you have things set up, it will try and log in with an empty
username and an empty password, perhaps your ftp server is rejecting this?

Running ldirectord -d may shed some light on this problem.



-- 
Horms



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