From owner-freebsd-current Thu Dec 31 11:31:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09019 for freebsd-current-outgoing; Thu, 31 Dec 1998 11:31:59 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns1.adsu.bellsouth.com (ns1.adsu.bellsouth.com [205.152.173.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA09010 for ; Thu, 31 Dec 1998 11:31:58 -0800 (PST) (envelope-from ck@ns1.adsu.bellsouth.com) Received: (from ck@localhost) by ns1.adsu.bellsouth.com (8.9.1a/8.9.1) id OAA12752; Thu, 31 Dec 1998 14:24:00 -0500 (EST) Message-ID: <19981231142400.X4306@ns1.adsu.bellsouth.com> Date: Thu, 31 Dec 1998 14:24:00 -0500 From: Christian Kuhtz To: David Boreham , freebsd-current@FreeBSD.ORG Subject: Re: NOW/MOSIX/Beowulf References: <368BCBE7.BCC1FFB5@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <368BCBE7.BCC1FFB5@netscape.com>; from David Boreham on Thu, Dec 31, 1998 at 11:09:27AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 31, 1998 at 11:09:27AM -0800, David Boreham wrote: > This is an interesting thread. > One point which should be made, and I've not seen > made is that the protocol (LDAP) needs to be > discussed separately from the server implementation > (e.g. Netscape, Novell). Yep. I'm guilty of that, too. ;( > > I've done the evaluation here for the Netscape server, and was > > fairly unimpressed even though we had a simple setup (no distributed > > servers, for example, and from what I understand, this is where > > Netscape's main problems lie). > > 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. > 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. > To partition the data, in order to for example > constrain the size of the working set of each > server, you currently need to have an intelligent > client. The client needs to have some knowledge > of the partitioning scheme in order to locate > the server which contains the target entry. > Perhaps this is what you mean ? That's a theoretical possibility.. Or you teach the directory multimaster and you can still have dumb clients. Assuming a lot of different devices, I don't think it is realistic to expect that all clients are equally intelligent or use the same algorithm to decide where to go. Particularly since, to my knowledge, there isn't even a notion of any type of standard for such behavior. And then there's the issue of me changing the directory and then what (short of going around and telling each client what to do). Use a directory find out where my tree lives? :) The index of all indeces? :) And then you still haven't solved the problem of what happens when your network gets partitioned and you lose access to the central site. Particularly in a SP network, it is by design that the operation keeps on running, even if you lose half your network. SP networks are usually designed to cope with at least 2 point if not 3 point failure. Sure, you can (again) go and teach the client. But then the client has to figure out which server to use and how to respond on failure and convergence. (two affinities: the affinity to cease a resource and the affinity to release a resource). Otherwise all load balancing goes to heck and you have to overengineer everything. That particular kind of overengineering is not an option. :) For instance, SS7 is designed so that the 'protocol' (read: the client) statically knows what to do in failure scenarios. It has no way of automagically learning. And it is very cumbersome to manage and work with. No, I will not let such technology invade my network. ;^) Cheers, Chris -- "Economics is extremely useful as a form of employment for economists." -- John Kenneth Galbraith [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message