On 10/15/08, Mark S <
tokenrain@gmail.com> wrote:
> I would some advice and how best to go about setting up a redundant
> infrastructure for my ldap consumer servers.
>
> I work for a company that has remote offices around the world.
>
> In our main office we have setup 2 OpenLDAP servers running 4.x version of
> the software in a MirrorMode configuration. I have load balancer which
> points a single VIP to the server that I want to be the authoritative writer
> at any point in time.
>
> Around the world I have around 42 servers that I would like to slave off
> these master servers.
>
> First off does anyone think having 42 slaves to a single master is going to
> kill the server. It is an 8 core box with gobs of RAM.
>
> The other question is on how I obtain replication redundancy. Do I simply
> point my syncrepl provider to the VIP that hosts the master server. When the
> VIP re points in case the a server failure the salvea should just
> reconnect? Has anyone ever used 2 syncrepl stanzas against the same DIT.
> Something like below. This way the slaves always has a connection to both
> servers in the MirrorMode config. If one goes down then the other
> replication thread will continue getting updates. Is this a supported
> configor does it create a lot of conflicts in deciding who to get the
> updates from since it will receive 2 updates when both servers are live.
my understanding of mirrormode was that you would point your servers
(for writing) at a vip (say master.yourname) or back-ldap server, which
refers to the preferred server master1.yourname, and only if that is unavailable,
would the vip send traffic to master2.yourname.
in this case where one master is preferred, replication traffic between servers
would predominately be in one direction, hence clock / replication issues or
who-updated-who-first issues, would reduce or go away, which is why it is
better than multimaster if your goal is redundancy.
reads can be directed at either master1.yourname or master2.yourname,
as both would be same for the purposes of reading. you can explicitly refer
writes to your master server, in the slap.conf of your distributed servers
above assumes writes are less frequent than reads, which is usually
typical with ldap data.. your mileage may vary.