[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: using slapd-ldap to fail over to upstream servers
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Michael Dean
> hi
>
> we have an openldap 2.1.19 server running on a solaris
> machine as an LDAP
> proxy to three NDS servers. when one of the NDS servers fails
> the idea is
> that the next server in the 'uri' directive will take over ie ..
>
> database ldap
> uri "ldap://nds1/o=nds ldap://nds2/o=nds ldap://nds3/o=nds"
> idletimeout 600
> timelimit 60
> threads 128
>
>
> when 'nds1' is completely offline the cut-over to 'nds2' will work no
> worries, but when the 'nds1' server is coming back online or
> when it gets
> overloaded it tends to get swamped with requests from slapd
> and eventually
> slapd will open up it's limit of connections trying to get to 'nds1'
> because it thinks it should keep trying 'nds1'
>
> what I think I'd need is something to force slapd to cut over
> to the next
> server in line when requests are taking too long to complete, is this
> possible? perhaps a "connecttimeout" might be useful in this situation
The library's connection timeout feature only applies to the creation of the
connection. If the NDS server accepts the connection, but is slow to process
the incoming LDAP requests, then the connection timeout doesn't help. If the
NDS server is swamped with more connect requests than it can answer, then a
connect timeout may help. Currently there's no back-ldap config to set the
connection timeout. This was recently added to back-meta in CVD HEAD so I
guess we can patch it in easily enough, but it won't make it into release
2.1.
Also since release 2.2 has connection pooling, this whole situation will need
yet another approach. If all your requests reuse a single connection then the
connection timeout is irrelevant. Also there's no mechanism in libldap to
force the next URL in a list of URLs to be used after a connection has been
made. To switch to the next URL you would have to explicitly abandon all
outstanding requests on that LDAP session handle and then create a new handle
using ldap_initialize with an edited URL list, skipping the server that you
just abandoned.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support