[lvs-users] IPVS error : "no destination available"

Khosrow Ebrahimpour khosrow.ebrahimpour at ec.gc.ca
Tue Sep 18 00:34:55 BST 2012


On 2012-09-14, at 5:12 PM, Khosrow Ebrahimpour wrote:

> Hi List,
> 
> I run a cluster of ldap servers behind LVS and recently started to see 
> connection timeouts from clients that are connected to the loadbalancer. If 
> those same clients are connected directly to the realserver, there is no 
> issue.
> 
> The loadbalancer is running LVS-DR with a LC scheduler with two realservers. 
> And each time there's a timeout error both realservers are available and 
> there's no error logged by the LDAP service.
> 
> After looking through various log files, I found that about once a day I get 
> this error:
> 
> Sep 13 06:27:20 lvs1 kernel: [39885980.112929] IPVS: lc: TCP 10.10.10.11:389 - 
> no destination available
> 
> I was unable to find any kernel variables to increase max connections (I looked 
> here http://www.kernel.org/doc/Documentation/networking/ipvs-sysctl.txt). 
> 
> A thread on the lvs-devel ( http://archive.linuxvirtualserver.org/html/lvs-
> users/2010-05/msg00036.html
> ) list mentions the variable ip_vs_dest_totalconns. Is there a way to 
> increase this?
> 
> Any help is appreciated.
> 


More clarification:
I never set the "--l-threshold" and "--u-threshold" variables and they are both set to 0. And so if my understanding of IPVS is correct, I should never hit that limit. Here's a quick snapshot of my thresholds and the connections as they are right now.

  IP Virtual Server version 1.2.1 (size=4096)
  Prot LocalAddress:Port            Uthreshold Lthreshold ActiveConn InActConn 
    -> RemoteAddress:Port
  TCP  ldap.example.com:ldap lc
    -> ldap1.example.com:ldap      0          0          159        46        
    -> ldap2.example.com:ldap      0          0          156        297       
  TCP  ldap.example.com:ldaps lc
    -> ldap1.example.com:ldaps     0          0          601        1065      
    -> ldap2.example.com:ldaps     0          0          607        138       


As you can see the systems are busy, but don't seem to be overloaded in any way. 



More information about the lvs-users mailing list