Re: free/non-free ladp servers comparizon

[Cliff Friedel <cliff@wrkcs.net>]

On Fri, 27 Oct 2000, David Obadia wrote:

> On Fri, Oct 27, 2000 at 10:32:20AM -0400, Cliff Friedel wrote:
> > AMD K6-2 500s running SuSE Linux 6.4 and OpenLDAP 1.2.6.  Lookups are
> > mainly local as we replicate ldap servers like crazy to all our machines.
> 
> What's the use for that? *ALL* your machines? How many do you have? I'm not sure
> the slurpd would appreciate to replicate an average write flow to 50 servers!
>
Two reasons for this.  Speed in authentication (as we have all kinds of
stuff authenticating from LDAP) and failover (should a machine bite the
dust, we can quickly switch to another one).  We actually don't have
1/machine (that was incorrectly stated by me above).  It is actually
1/main use machine.  This means we have 3 LDAP servers for 8
machines.  Sorry for the mistake on my part.

> > If I had all of our machines lookup on 1 server, I am sure our
> > numbers would be even higher.
> 
> Hmmm... the contrary would be odd :-)
> 
> > I have tried to keep the system as decentralized as possible.
> 
> In fact, with a slapd per server, it could not be more decentralized :)
> 
> > As we have only had the ISP open 3 months,
> > I also think the numbers for performance will go up until we hit a
> > consistent threshold.  Statistically though, the numbers seem significant
> > to prove that we are seeing higher numbers than suggested by M$.  One
> 
> > important note to mention:  We turn off nscd to improve performance (I
> > know this sounds wrong, but nscd doesn't seem to be built for high traffic
> > environments.
> 
> Of course If you have 1 slapd / machine, I guess the name service caching daemon
> isn't really useful. However I'd like to have more informations about that?
> How "high" is your "traffic environment" ? I'm currently testing an LDAP-based
> architecture for NIS replacement with OpenLDAP and the libnss-ldap/nscd on
> client systems. It seems to work fine. Could you describe the troubles you got
> more precisely?

We currently house 150 or so accounts and about 30 virtuals.  While that
isn't really amazing, we built the system to handle approximately 10000
users on the 8 machines.  This number was from previous experience with
another ISP where we had 25000 users and used LDAP (Netscape in that
environment on a Solaris Machine - this happened right as I left). Our
main use for the LDAP server is authentication for our dial-ups via RADIUS
(which calls the LDAP server via PAM), SMTP and POP authentication and the
like.  In this environment, we needed something that wasn't going to
require us to have /etc/passwd and /etc/shadow files for each of the
machines but allow us to pass environment variables (such as aliases or
mail redirects) to all the machines.  LDAP seemed to fit this quite nicely
without the security concerns prevalent in the NIS trusted hosts system
model.  One thing I did change from the last implementation is a reliance
on one server for all the LDAP requests.  This haunts my previous employer
to this day as their box is severly overloaded (probably taking well over
1 million requests a day as my guess).  Anyway, by going decentralized and
using a TCP redirector, we should be able to theoretically expand this
system ad infinitum (or at least to the point where finding redirecting 
hardware that size becomes an issue). The only potential problem I have
seen is with UIDs going over 65535 as this could mean multiple users
having the same UID.  I think I have come up with a way around that by
building a design for a hierarchical pyramid of redirectors (level 4
software based) that would examine the packets for various protocols and
dissect them to find who the information was for, look it up in the tables
and reassemble the packet with the proper destination.  Not sure if it
would work, but it is a thought.  Also thought about using different pools
of LDAP servers for different areas and having the machines check them
all.  Not sure how this one would go as it could involve big delays.

> > Was hanging up and causing performance issues).
> 
> A server (running as an LDAP client) has mysteriously frozen (answer to ping,
> socket opening, but 0 traffic, no way to login on the console even though the
> keyboard worked fine) this morning. I'm wondering if this could be due to the
> nscd or the libnss-ldap [probably not]. Anyway what kind of hang up did you
> get? 
> 
Authentication of all types would stop.  Also, during any process that
would require LDAP lookups (ls, ps, etc), names and the like would not
show up and groups would not either.  Once nscd was restarted, everything
would return to normal for a day or two then back to lockup.  Restarting
nscd was the only way it would fix the problem.  SIGHUPS and the like
would not work. 

Sorry this is so long winded.

Cliff