[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Clustering for Linux 2.3.x?!
Quoting Albert D. Cahalan (acahalan@cs.uml.edu):
> Erik writes:
>
> > I consider this to be exactly the /wrong/ way to go about it! Why? It'll
> > make application lazy. And why is that bad? Because redundancy is needed
> > in apps too, and we'll end up implementing clustering both in kernel and
> > in the apps.
>
> Some people need redundancy in apps. Some people don't.
Could you give an example of a large clustered app where redundancy wouldn't
be any benefit at all? Failing that (the question is slightly unfair) please
describe the least redundancy requireing app. Note that more nodes increases
the rate-of-faliure...
> > The one place where kernel support is needed is distributed
> > redundant filesystems, CODA and AFS pops up in my mind -- fast enough?
>
> No, not appropriate at all. CODA and AFS are designed for large
> networks. CODA at least does not support locking. Neither supports
> simple sharing of disk space accross the machines. You would want
> data to migrate to where it is needed.
Yes that was my intended functionality, I had the delusion that both of them
could do this. A new fs "clusterfs" might be needed, mostly for the shm apps
though.
> Kernel support is also needed for process ID allocation and scheduling.
For distributed-ipc: yes. For message-passing: no. What will the cost be for
the common case if such modifications are made??
> > <mantra> message-passing, message-passing, message... </mantra>
> >
> > Finally: the distributed ipc isn't BAD, but IMO new clusterd apps should
> > not be implemented using it.
>
> Sure they should. Some people are comfortable with the API.
> Programmer time often costs more than machine time.
That was one of these damned generalizations ;-). There will be times when a
shared-memory approach is better, that will never stop me from promoting the
right way [TM] of doing clusterd apps :-). And if you have a problem that is
far better solved with a shared-memory algorithm than a message-passing one?
Then the p/p is probably better on a large SMP than on a cluster.
Erik
-
Linux-future: thinking about the future of the Linux kernel
Archive: http://humbolt.nl.linux.org/lists/
Wish list: http://users.ox.ac.uk/~mert0236/linux-future.html