Date: Thu, 31 Dec 1998 12:04:47 -0800 From: dboreham@netscape.com (David Boreham) To: freebsd-current@FreeBSD.ORG Subject: Re: NOW/MOSIX/Beowulf Message-ID: <368BD8DF.C478B885@netscape.com> References: <368BCBE7.BCC1FFB5@netscape.com> <19981231142400.X4306@ns1.adsu.bellsouth.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Christian Kuhtz wrote: > > The current Netscape LDAP server supports multi-server > > replication where each distinct DIT subtree must be > > mastered on one and only one server. > > But you don't support multimaster. Which is a crucial in almost all of our > applications. Replicating read-only tries is only good if the directory is > used as a reference, but not when the intention is to make it an active > container of information. Multimaster replication will be in the next major release. Note that MMR does not solve all the problems associated with distributed databases. For example, a client performs an update on one master. It then queries the directory service to read back the modified entry. Due to load balancing it reads from a different server which has not yet received the update. Client therefore sees inconsistent data. In the end there are fundamental laws of physics involved, which no fancy protocol and no army of wizzard coders can transgress. > > Thus read load can be distributed across multiple > > replication consumers easily. > > But no commits/writes. All commits on a Netscape DS have to be made on a > 'central' server (the owner/master of the tree). I think that's what the > previous poster might've meant. Not quite true. For a given subtree, all writes must be made on a particular designated server. Provided the data is partitioned across the tree, multiple masters are a reality. > That's a theoretical possibility.. <comments snipped> Yes, I agree. A client should not need knowledge of the service topology. Various extensions to the LDAP protocol, the X.500 information model, and our server implementation have been considered to "solve" this problem. Generically it's termed "the distribution problem" in Directory circles. Prototype implementations are in use on my.netscape.com and www.netscape.com and webmail.netscape.com Current product supports LDAPv3 referrals. Clients may connect to an LDAP server of their choice (perhaps determined by DHCP or DNS) and submit a query. That server may refer the client to one or more other servers, which the client may contact in order to resolve the query. Network traffic could potentially be optimized by forwarding the query from server to server rather than having the client re-submit to referenced servers. This forwarding is termed "chaining" in Directory parlance, and could be implemented by any LDAP server transparently to the client. We have an in-house custom server which does chaining, but the current product does not. In any event, the mechanisms for client query interaction in a distributed environment are present in LDAPv3. However, in order to make distribution practical, some additions are needed on the server side. Currently referrals are statically configured. Referral decisions should be made by the server based on a real understanding by it of the service topology and partitioning schemes employed. Clients also need a way to ask a server for the distinguished name of a new entry they wish to add to the service. These are areas in which work is ongoing. Anyway, fascinating as this is, it's going well off topic. Follow-ups should goto to ietf-ldapext@netscape.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?368BD8DF.C478B885>