LDAP how is Failover done?

[Christopher Browne]

On Mon, Aug 8, 2011 at 1:27 PM, Alejandro Imass <aimass-EzYyMjUkBrFWk0Htik3J/w at public.gmane.org> wrote:
> On Mon, Aug 8, 2011 at 12:48 PM, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>> On Mon, Aug 8, 2011 at 12:25 PM, Alejandro Imass <aimass-EzYyMjUkBrFWk0Htik3J/w at public.gmane.org> wrote:
>>> On Mon, Aug 8, 2011 at 12:03 PM, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>>>> On Fri, Aug 5, 2011 at 8:57 AM, Ivan Avery Frey
>
> [..]
>
>> A characteristic case would be where an organization wants integrated
>> control over a number of systems that feed off of LDAP, and has
>> several locations, each of which is sufficiently "trusted" to be
>> considered an authority..
>
>
> Yes indeed a good case for MM. But in your opinion isn't better to
> delegate control and distribute the different parts of the DIT where
> required instead of replicating the whole DIT to the remote sites. I
> _think_ this MM ideas come mostly from MS AD's ways of doing things
> instead of properly defining a distributed DIT and use referrals or
> chaining instead? When people come from the MS AD world they usually
> see the Directory as a simple People, Computers, and Groups DIT
> structure, instead of a rich DIT that combines the best of the X500
> org-based pattern with the DNS pattern.

I haven't had *any* exposure to Microsoft "AD", so that's certainly
not related to my thinking.

Rather, I'm not keen to need to capture changes in a multiplicity of
places when it can be captured just once, thereby eliminating that
redundancy of capture.

In my environment, we have several data centres, and while services
are always being run in one or another of them, there is a quite
conscious agnosticism as to where those services *ought* to be, as one
of the purposes to the multiplicity is the ability to potentially
failover services to a different site.

Supposing we assume 3 sites, and a number of services that are
supposed to be able to be shifted between those sites.

For latency purposes, there certainly needs to be an LDAP server at
each site, and for this to cope with failover, there needs to be
replication of data from all 3 sites to all the "other" sites.

If we were to to use your approach of delegating control, then I think
we'd need to have 4 LDAP "masters":
  - 1 for centralized data across all sites
  - 3, one at each site, to capture the data "mastered" at that site.

And that presumably turns into 12 LDAP servers, once the data gets
replicated to the various destinations (failover, don'tcha know!
:-)).

This also introduces the need to debate, for any given piece of
information, which of the 4 LDAP servers should be used to capture
that information.

And it introduces the risk that, if anyone gets confused in that
debate, different states of that data might get captured on different
LDAP masters, because one person thought it should go on "Global
Master" and another thought it should go on "New York Master".  (Worst
case is where both at least seem to "get it right," and processes
start depending on having this data synchronized on multiple masters.)

Managing 8 replicas rather than 2 doesn't seem to be a big improvement
to me.  And having to puzzle over which, of 4 LDAP masters, should be
used to store a piece of information seems like at least a 4-fold
worsening of things.  Particularly not when 80% of the sysadmins, for
*all* these sites, are sitting in the same room.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists