[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Using syncrepl in single slapd instance.
I have been investigating the use of syncrepl as a replacement for the
mechanism we are currently using in our system and become stuck. Here
is the scenario to put the problem in context.
Within our infrastructure there is the order of 1000 Grid services each
of which runs its own LDAP server that contains information about its
structure and state under the DN mds-vo-name=resource,o=grid. Each
institute that that operates a Grid service (in the order of 300
distributed globally), runs an LDAP server containing the consolidated
information from all services within its domain under the DN
mds-vo-name=site-name,o=grid.
In addition, there are about 70 top-level LDAP servers distributed
globally that contain the consolidated information from all sites using
the DN mds-vo-name=local,o=grid.
At the moment the LDAP databases are updated externally via process that
polls the LDAP server for all information, which is very inefficient.
Syncrepl seems to be a better mechanism to use however, I am having
difficulty with one scenario. Using standard syncrepl with a relay, the
site-level LDAP server can be configured with the following slapd.conf
file.
http://lfield.web.cern.ch/lfield/bdii-slapd.conf-basic-rep
However, the site LDAP server is a Grid service and needs to publish
itself. If I try to just to an LDAP add I get the following message,
which I guess is due to the fact that this part of the database is now
"owned" by the syncrepl process.
ldap_add: Server is unwilling to perform (53)
additional info: shadow context; no update referral
I tried to work around this problem by using another database and some
more relays the result of which can be seen in the following file.
http://lfield.web.cern.ch/lfield/bdii-slapd.conf
However, this result with the following error, which suggests that I
can't "mask" a database with a relay that points somewhere else.
bdii-slapd.conf: line 69: <suffix> namingContext
"Mds-Vo-name=resource,o=internal" already served by a preceding bdb
database serving namingContext "Mds-Vo-name=resource,o=internal"
Does anyone have an example of how to do a syncrepl where a single slapd
instance can act as both the consumer and producer?
Also, has anyone done any scalability/reliability tests with syncrepl?
Thanks,
Laurence