Re: Clustering for Linux 2.3.x?!

[Erik Elmgren <erik.elmgren@swipnet.se>]

Quoting Michael Loftis (zop12@mindless.com):
> On Wed, 03 Mar 1999 20:16:07 +0100 Oliver Schersand 
> <oliver_schersand@csi.com> wrote:
> 
> 
> > I like the idea of clustering, but why not go a step forward.
> > 
> > Build a virtual machine which is spawned of many systems. Connect the
> > kernel
> > which a fast network ( giga ethernet ?? scsi ??? firewire ?? ).
> > Greate would be featers like
> 
> This is how I view a cluster...  Not as seperate entities but you get one 
> 'machine' out of many.  You contact any one of the IPs for the associated 
> machines in the cluster and you'll get the one.  If the machine you're 
> talking to drops then (assuming routing allows this) your packets will be 
> answered by one of the other machines.  This would involve alot of work 
> on re-writing the scheduler, networking, and storage systems.  Inevitably 
> you'd have to elect one or more 'masters' that'd keep things mostly under 
> control :)

Well, somebody has to disagree :-)

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. The one place where kernel support is needed is distributed
redundant filesystems, CODA and AFS pops up in my mind -- fast enough?

<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.

Erik

--

Has it ever occurred to you that God might be a /committee/?
--- Jubal Harshaw
-
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