At the moment, we have a single LDAP server which we are using with LDAP Account Manager for web-based object management and Atlassian Crowd for authentication. The LDAP server is queried directly by other servers for UNIX-level authentication, i.e. SSH and group membership.
I'm looking at introducing a second LDAP server and I'm leaning towards choosing mirror mode as the replication methodology. Since the only writes to LDAP come via LAM or Crowd, and these are both web-based, I think I could set up an almost identical server to the one I have at the moment and use a system like Amazon's Route 53 DNS service with health checks to allow me to redirect users off to the second server if the first server fails. It occurs to me, though, that either LAM or Crowd could have failed, leaving the LDAP service itself quite healthy. In that situation, all of the writes would still be directed to one of the LDAP servers so is that a problem? The documentation says that "the two providers are set up to replicate from each other but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync." So the only requirement of mirror mode *seems* to be that all writes just go to one provider at a time, i.e. the replication model must be as close to single-master as possible, presumably because of consistency requirements? Or do I need to introduce yet another layer of "something" to direct the writes? The documentation suggests slapd in proxy model or a hardware load balancer, but would my scenario as described above meet the needs? Thanks. Philip
