[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP and failover
Le jeu 27 juin, David Wright a écrit :
>
> There is a nice "half-ass" solution that has proved useful for me. If your
> main, critical use of OpenLDAP is for nss_ldap and pam_ldap, you can get
> away without a complete failover solution. Just have your master replicate
> to a slave and set
> URI ldap://master.example.com ldap://slave.example.com
> in the config files for these libraries. If they cannot contact the
> master, they will use the slave. Your users won't be able to change
> passwords or shells, or read your company LDAP directory in their
> browsers, but they will still be able to log on and work.
>
this solution seem very simple, but as you say, if the master server
failed, ldap client just can read from slave server.
I have test this solution, with additional bind_timelimit parameter
set to 1, just look the result :
with the primary server up :
mail1:~# time sh -c 'getent passwd | wc -l'
176
real 0m5.507s
(Nb: i don't know why this result is so long, my network is 100Mb/s
commuted, all ldap server have a very poor load, if you have some
idea, i'm very interesting.. i try to increase cachesize value without
success, if i use nscd it's worst.. moreover i sawn bug with nscd)
with the primary server down :
mail1:~# time sh -c 'getent passwd | wc -l'
176
real 0m6.509s
result seem very encouraging, just one supplementary second,
corresponding to my bind_timelimit argument, but there is still
problem with writing operation
> For a complete failover solution, you don't use replication at all. You
> have two identical machines (A and B) which share storage (an external,
> dual-ended, SCSI RAID array) and communicate via a heartbeat. When A
> fails, B takes over A's IP address, mounts the storage, and starts up
> slapd. This can be implemented with open source software. I have tested
> many of the components of this (heartbeats, IP takeover, RAID arrays), but
ok i know linux-ha project but i never test ...
> never actually implemented it in production. I have never been able to
> justify the additional hardware costs (not just the second machine, but
> the really pricy external, dual-ended, SCSI RAID array). If you are
i know very poor things about hardware, do you have more information
about good hardware for do this ?
> interested in implementing this and need a consultant, I would be very
> interested in working with you! :-)
he he, i'll prefer that your company recruit me ;p
>
--
Bruno Bonfils http://www.debian-fr.org