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
Laurence Field Laurence.Field@cern.ch writes:
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.
[...]
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.
this slapd.conf is malformed, the updateref parameter is missing.
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.
this slapd.conf is malformed als well, the syncprov parameter has to follow all database related parameters.
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?
have a look at tests/scripts/test019
Also, has anyone done any scalability/reliability tests with syncrepl?
Yes I did, cascading databases up to 66 servers and multimaster replication up to 14 hosts and up to 5 M entries. Hardware was Sun Ultrasparc single core 8 GB, rackmounts.
-Dieter
Hi Dieter
Does anyone have an example of how to do a syncrepl where a single slapd instance can act as both the consumer and producer?
have a look at tests/scripts/test019
I took a look at test019 and it seams that the master and slave run on different ports and use different slapd.conf files. Will go through slapd.conf examples in detail to see if I can find any magic tricks that will help me get it working on the same port and in a single slapd.conf file.
Also, has anyone done any scalability/reliability tests with syncrepl?
Yes I did, cascading databases up to 66 servers and multimaster replication up to 14 hosts and up to 5 M entries. Hardware was Sun Ultrasparc single core 8 GB, rackmounts.
This is good to know, I am currently testing the replication of a database with 70K entries between CERN in Geneva and the University of Melbourne. After this I will do some more tests with multiple masters.
Thanks
Laurence
Hi Laurence,
Laurence Field Laurence.Field@cern.ch writes:
Hi Dieter
Does anyone have an example of how to do a syncrepl where a single slapd instance can act as both the consumer and producer?
have a look at tests/scripts/test019
I took a look at test019 and it seams that the master and slave run on different ports and use different slapd.conf files. Will go through slapd.conf examples in detail to see if I can find any magic tricks that will help me get it working on the same port and in a single slapd.conf file.
Actually there are no magic tricks: a simplified slapd.conf
database hdb ... syncrepl rid=001 ... ... overlay syncprov ... database monitor
thats all.
[...]
I will do some more tests with multiple masters.
I'm personally not in favour of multi master. In fact, the 14 hosts environment in out sandbox has been a nightmare :-) That was OpenLDAP-2.4.13.
-Dieter
openldap-technical@openldap.org