OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Re: poor ldap load distribution

From: Dan Lannom (dlannomumd.umich.edu)
Date: Fri Jun 01 2007 - 15:01:21 CDT


Victor Duchovni wrote:
> On Fri, Jun 01, 2007 at 02:14:34PM -0400, Dan Lannom wrote:
>
>> I'm trying to use a round robin DNS entry to distribute the queries over
>> multiple ldap servers, but for some reason they are all being redirected
>> to the same system, which is pushing load too high.
>>
>
> In what Postfix context are you using LDAP? Are you using "proxy:ldap:..."?
> Is transport(5) lookups?

I'm using virtual(5) and relay_recipients which is set to
$virtual_alias_maps.

>
> - Most people who care about load, have high volume systems, where
> proxymap(8) is a must for LDAP queries from smtpd(8) and cleanup(8),
> so the picture changes. Each proxymap(8) process (many fewer of
> these) connects to an LDAP server and stays connected. These connection
> count is one or two orders of magnitude lower, but distribution may
> be uneven, and stay uneven, if you roll "heads" a few times in a row.

I'll try out proxymap. I've always considered our email environment
small since we're only accepting ~200k messages per day

I'm typically seeing 60-120 established LDAP sessions all to the same
host, so its more than a few bad rolls.

> On my "busy" server using LDAP via proxymap for virtual(5) rewrites, the
> process counts (sampled just now) are:
>
> 76 smtpd
> 21 cleanup
> 7 proxymap
>
> so 97 would-be LDAP clients are served by 7 LDAP connections from
> 7 proxymap processes, which if LDAP cooperates each pick their
> own IP address for the LDAP server.
>
> I don't actually use multiple A records for LDAP load balancing, rather
> for machines in a cluster, I shuffle the LDAP server preference list from
> host to host, and in some cases use actual network load balancers.

I'll switch to the shuffle method, I was probably trying to do too much
with DNS.

Thanks,

Dan