[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Interesting LDAP replication scenario
Ack.
Forgot to mention that I'm running OpenLDAP 2.0.21 under RedHat 7.2
on the master slapd server and OpenLDAP 2.0.23 on a Sun Cobalt Qube
3 on the slave/site slapd servers.
On Monday, July 29, 2002, at 10:33 AM, Geoffrey L. Wright wrote:
The title says it all. I'm fairly comfortable with developing
against OpenLDAP and have worked on several fairly large deploys.
But all have been very straitforward from a replication
standpoint. I have in front of me now a replication task that
looks fairly tricky -- at least to me...
A picture is worth a thousand words, so here's one that will
hopefully make my situation a bit more clear:
http://www.northernwastes.org/~geoff/rep_diagram.png
Now here's a verbal summary of my scenario:
I have a number of "districts", each which contains a number of
separate physical sites. All sites in a given district have a
common suffix and need to share information. Each district has a
separate database. Right now I have replication working in a
pretty standard way:
1. An LDAP client submits a modify request of some sort to the
slave slapd server.
2. THE slave slapd refers the LDAP client the master slapd.
3. THE master slapd does the modify and writes the change to the
replication log.
4. slurpd sends the change to all slave slapd servers in the district.
So far so good. Everything is pretty much by the book. But
here's my problem:
Many of my sites are in very rural locations and have very
tentative connections to the rest of the world. Connection
downtime measured in days is possible in some cases. At many
individual sites downtime measured in hours is unfortunately
fairly common. When new information is added to any individual
site the site slapd instance I need it to to be accessible to the
users at that site immediately. There are currently about a
hundred of individual sites, with more to be added over time.
Here's what I would _like_ to see:
1. The LDAP client submits a modify request to a site (master?
slave?) slapd server
2. This site slapd server immediate does the modify then (if it is
available) passes the request to the master slapd server at home
base. If not, the site slapd instance periodically checks back
until such time as the home base master slapd server becomes
available and then passes on the request.
3. The home base master slapd does the modify and writes the
change to the replication log.
4. slurpd sends the change to all site (master? slave?) slapd
servers in the district _except_ the original location.
Can this scenario be made to work? Is this really the best way to
do things, or is there another way?
Any help. thoughts or suggestions at this point would be greatly
appreciated...
//glw
_____________________________________________
Geoffrey L. Wright, Senior Partner
Alaska Web Art
P.O. Box 240133 Anchorage, AK 99524
Office - 907.868.8092 Fax - 907.563.2122
_____________________________________________
http://www.akwebart.com