[Date Prev][Date Next]
Re: OpenLDAP 2.0.13 released
> Here we are looking at a scenario where there will be around 20 million
> records which we will be storing in the ldbm database. Also we are going in for
> selective replication across some twenty slave servers.( each at diff physical
> Currently we are using the back-meta concept of Openldap (which is not a release
> version) where we have multiple instances of ldbm in the master server and hence
> also multiple slurpd processes running in the back ground. But then if we go in
> for any release version of openldap be it 2.0.13 or 14 then i believe we need
> to go in for a single ldbm databse in the master instead of having multiple
> ldbm 's .
> Now my question here is two fold :
> 1. Which is the better way to do a search in the master ..is it by having
> multiple ldbm's ( as we have currently with the back meta concept ) or is it by
> having one single ldbm database .
On one side, back-meta adds an extra (tcpip unless you use ldapi:// URIs
local targets) layer to the search; on another, it allows to split large
databases into smaller ones, so point searches (especially if the base
to resolve the correct target only) could be a little faster.
> Where will be the speed of authentication be faster ?? We need an answer for
> this because we are looking at a record which will exceed more than 20 million
> in the near future...
again, see the above point. If auth is directly performed with a dn,
should not be worse than back-ldbm; if you need to fetch the dn based on
user id with a full naming context-wide search, then it might be a
However I never tried a +20M entry db, my experience is limited to 100K
> 2. Which is the better way of doing replication ? Is it by having a single
> slurpd process doing selective replication across 20 slave servers(as in version
> 2.0.14) or is it by having multiple slurpd processes .
I don't see so many differences in the two solutions from this
Remember that back-meta should be seen as a means to nail together
servers, not as a solution from scratch. I remember you started using it
of the subtree replication issue, which is now fixed since 2.0.13. I'd
it if the single servers can be used by themselves. I mean: if each
serves a subdomain (don't take it literally) and subdomain-related
can be performed directly on the appropriate server, while access thru
is required only by domain-wide operations, then I'd stay with the
solution. Otherwise, if all the operations potentially are domain-wide,
use the back-ldbm solution with partial replication. It sounds less
because the back-ldbm allows much more consistency checks on operations
back-meta can do. Moreover, reducing the number of databases and the
of configuration makes maintenance easier.
> 3. What is the support we may have for back meta in near future? In the sense
> that we wanted to know as to if there are any plans of coming out with a
> release version of back meta in the immediate future. This can then help us to
> decide with what should we go in for production set up.( i.e back meta or
> version 2.0.14)
I don't think there's any schedule about that. It's an extra feature
with limited potential use. At present I think it's only slightly less
mature than back-ldap, from which it descends, so it could be released.
It depends on the demand: the more people need it, the sooner it will
make into release. It is currently developed, it and used in production
environment in my organization. However its use is limited in nailing
together legacy OpenLDAP, Lotus Notes and Active Directory services
for address book and mail routing purposes (many different companies
are merging and maintain independent directories for their stuff).
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:firstname.lastname@example.org
via La Masa 34, 20156 Milano, Italy |