Pierangelo Masarati wrote:
Pete Rowley wrote:
Balance the issues raised in that draft versus having only one master,
which
means a single point of write failure without any write load balancing.
Just curious: I see this "write load balaincing" issue coming up all
times; if I have, say, 2 MMasters, does it mean that each one gets
(roughly) half the write operations? What about the other half to get
in sync within each other?
Hi Pierangelo,
The fact that LDAP directory servers are not intended to support a
high frequency of write operations means that the term "write load
balancer" is not the correct term to use when describing the benefits of
multi-master versus single-master replication - unless you are arguing
how to support systems architects who intentionally (or perhaps out of
ignorance) use LDAP technology in an incorrect manner in their designs.
The correct term to use in this context, IMO, is "highly available write
operations".
If you want to balance operations, then of course you need to use a
load balancer. When you use single-master replication, it means that
even if you use a load balancer, write operations are still not highly
available, e.g. they can not be performed if the master is down.
The key benefit of multi-master replication is that _all_ of the LDAP
operations _can_ be made highly available, and that applications which
need to write something ASAP (think disabling a user's account) should
never fail or be postponed as long as there is either a front-end load
balancer, or clients which can use a failover list of LDAP server names.
The key failure of the single-master replication model is that it
(currently) does not stand up in a highly available system design. If
there were some sort of automatic promotion of replica to master feature
that worked well, then it would certainly be a viable alternative to
using MM replication within a single geographical location / directory
partition.
IMO, the usage of MM replication is most suited for DIT designs which
span across wide area networks with subtree replication across a set of
"international masters", where it unfortunately has not worked very well
at all due to it's design. The recent version of FDS/RHDS is supposed to
address this issue via the use of a "sliding window algorithm", and
subtree replication support was included already in NDS 6.21.
So, how about implementing automatic promotion of slaves to master
status, so that single-master environments can be made highly available?
This is a generic problem, and applies to both FDS and OL. Do you think
it's a good idea or not?
Mike
--
LDAP Directory Consulting - http://www.netauth.com
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
