Date: Thu, 31 Dec 1998 14:24:00 -0500 From: Christian Kuhtz <ck@ns1.adsu.bellsouth.com> To: David Boreham <dboreham@netscape.com>, freebsd-current@FreeBSD.ORG Subject: Re: NOW/MOSIX/Beowulf Message-ID: <19981231142400.X4306@ns1.adsu.bellsouth.com> In-Reply-To: <368BCBE7.BCC1FFB5@netscape.com>; from David Boreham on Thu, Dec 31, 1998 at 11:09:27AM -0800 References: <368BCBE7.BCC1FFB5@netscape.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981231142400.X4306>