Действительно ли openldap подходит для больших производственных развертываний?

I use OpenLDAP supporting a user-base of about 10,000 active users who rely on it throughout the day for everything. Problems are rare. Many services rely on it, for authentication and other things.

However, we have 4 read-only replicas (slaves/consumers) behind a load-balancer, a hidden master and a hot standby master. Used to be 2 front-end servers, but we had load problems during certain peak times (when 4,000 or so of those users were desperately trying to hit it at the same second). All write access to LDAP is via our code.

That equipment and OS is all old and we're working on replacing it with a new setup that will go back to only 2 replicas (that aren't doing as many other things) and "mirror mode" replication between a pair of masters in an HA configuration. Again, problems are rare.

We used to have some problems with replication failing, but that's mostly from when we were using slurpd instead of syncrepl. Also, unclean shutdowns of a server can corrupt the data.

Keys to running OpenLDAP in a large-scale production environment, in my experience:

1. Somebody that understands LDAP and OpenLDAP well. Preferably more than one somebody.
2. Somebody that understands all the other directly related parts of the infrastructure well.
3. Somebody that understands how OpenLDAP replication works.
4. A reasonable understanding of the BerkeleyDB options (or whatever backend you're using), since the defaults aren't quite right.
5. Highly available slaves. More than 1. Better: really load-balanced.
6. **Active-passive masters (active-active master replication is inherently tricky)
7. We back up LDAP data to LDIF every hour and keep a few days worth of those on disk. (the whole server gets backed up nightly)
8. We have scripts to quickly bring a broken slave back to a clean current data replica
9. We have scripts to quickly restore a broken master from the LDIF backups (via slapadd)
10. We can quickly switch to the standby master. (scripts)
11. We monitor that the replication connections are alive
12. We monitor that the replications IDs are current on all slaves
13. We monitor (less often) that the entire contents of the slaves match the master.

Basically, though, if it's a key part of your infrastructure, somebody on your team should really understand it well.

Addendum: By request, the DB_CONFIG file from my openldap DB directory. Look at http://docs.oracle.com/cd/E17076_02/html/api_reference/C/configuration_reference.html for details.

set_cachesize 0 536870912 1
set_flags DB_TXN_NOSYNC
set_flags DB_TXN_WRITE_NOSYNC
set_lg_regionmax 268435456
set_lg_max 536870912
set_lg_bsize 134217728