[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.0.13 released




Hi,
        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
location)

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 .

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...

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 .

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)


Waiting for replies ....

Thanks and regards
Sovan


|--------+------------------------->
|        |          Pierangelo     |
|        |          Masarati       |
|        |          <masarati@aero.|
|        |          polimi.it>     |
|        |                         |
|        |          10/09/01 14:14 |
|        |                         |
|--------+------------------------->
  >--------------------------------------------------------|
  |                                                        |
  |       To:     Sovan Shatpathy/Satyam@Satyam            |
  |       cc:     openldap-software@OpenLDAP.org           |
  |       Subject:     Re: OpenLDAP 2.0.13 released        |
  >--------------------------------------------------------|





Sovan_Shatpathy@satyam-infoway.com wrote:

Please let me bounce in :)

>
> Hi ,
>        Here we  are using the meta version which we have down loaded from the
> head of the CVS tree . We had a requirement wherein we had to go in for
> selective replication across multiple slaves which were configured in
different
> servers and also had individual instances of ldbm database.
>
> So as things stand now we have achieved our aim of doing selective replication
> across multiple slaves having individual ldbm and also in case of the entry
not
> being found in the slave ldapsearch is happening in the root also ie the
master.
>
> Both of the above mentioned requirements was not happening with openldap
2.0.12
> stable version . Now here we have almost through with all testing and are on
the
> verge of moving all the set up to a production setup.
>
> Would like to know if the new stable version of LDAP is going to support our
> requirements and if it is not doing so then can we go ahead with  the meta
> version in a production set up ?

Release 2.0.13 will allow you to use dn-based selective subtree
replication within ONE SINGLE database, so if this was the only
requirement driving you towards back-meta, you may try to use
this new feature.

You need to configure one single database:

     database ldbm
     # use the rightmost part of the naming context as database suffix
     suffix "dc=org"

and set the per-suffix replication in each replica:

     # use subtrees of the base naming context
     # to enable selective replication
     # note: you may configure each slave to use
     # "dc=ncX,dc=org" as suffix, so you don't
     # need to recreate the common entry "dc=org"
     replica host=host1 suffix="dc=nc1,dc=org" ...
     replica host=host2 suffix="dc=nc2,dc=org" ...
     ...
     replica host=hostX suffix="dc=ncX,dc=org" ...

But beware of this bug:

http://www.openldap.org/its/index.cgi/Software%20Bugs?id=1323

you'd better wait for 2.0.14

Pierangelo.

--
Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy   |
http://www.aero.polimi.it/~masarati