Re: Being a consumer and a provider for the same database (toward different servers) ?

["Dieter Kluenter" <dieter@dkluenter.de>]

Hi,

jmbajet@gmail.com writes:

> Hello,
>
> I'am using Openldap 2.3.7 on Redhat.
> (I'am French so excuse my bad english !)
>
> I'am trying to define a replication architecture (with syncrepl) for
> my company.
>
> I must make a directory for my company which have 110 subsidiary
> companies . The "main" company is in Paris (France !) and the
> subsidiary companies are in other cities of France.
>
> So the suffix for the directory is o=my-company.
> Each subsidiary has the suffix ou=subsidiary_i,o=my-company
> with i from 1 to 110 ! (yes 110 distinct cities under a wide area
> network !).
>
> - Each subsidiary can write only under his suffix ou=subsidiary_i,o=my-company.
> - No one else but the subsidiary_i can write under ou=subsidiary_i,o=my-company.
> - The main company can write only under ou=main,o=my-company.
> So no multi-master.
>
> Each subsidiary and the main company must have a local replicate of
> the whole directory: Every ou=subsidiary_i,o=my-company plus
> ou=main,o=my-company (110 + 1 replicates !).
>
> Each subsidiary ou=subsidiary_i,o=my-company has his own database (bdb).
> The main company ou=main,o=my-company has also his own databse (bdb)
>
> Every ou=*,o=my-company is a subordinate of o=my-company
>
>
> I would like to design a correct replication process.
>
>
> I have a main server (star architecture) that would :
>
>   - Pull changes (syncrepl) for ou=subsidiary_i,o=my-company from
>   ou=subsidiary_i,o=my-company 's subsidiary_i server with i=1 to
>   110+1) --> so be a consumer, each subsidiary would be a provider for
>   his suffix
>
>   - Then each subsidiary_i server would pull changes from the main
>   server for suffixes ou=subsidiary_j,o=my-company with j <> i  and j
>   from 1 to 111 (other subsidiaries plus main company).
>   
> But to do that the main server must be for ou=subsidiary_i,o=my-company first a consumer (get the changes) then a
> provider to other subsidiaries.

[...]

This sounds like a rather complicated und resources consuming
setup.You should probably think about a back-ldap with proxycaching
design. That is, a master server which holds the full data set and
back-ldap proxycache in your subsidiaries which pull the relevant data
only and update data to the master.


-Dieter

-- 
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6