Re: A proposal for a General Clustering Framework

[Alan Robertson <alanr@unix.sh>]

Alan Robertson wrote:
> 
> Greg Lindahl wrote:
> >
> > On Tue, Jun 05, 2001 at 01:56:37PM -0600, Alan Robertson wrote:
> >
> > > > 1) We simply define a new 'lightweight' transport.
> > >
> > > The transport in the architecture heartbeat implements provides for multiple
> > > "pluggable" transports.  The framework will do the same.  So, we don't
> > > define a single transport, but a transport API, and leave the rest to the
> > > plugins.
> >
> > This is good. In particular, you could imagine a simple pub/sub system
> > that would broadcast all published data, and if the local system
> > doesn't have a subscription, it discards it. Or you could have a
> > central server that distributes data only to the actual
> > subscribers. Can you write an API flexible enough to allow both
> > implementations?
> 
> The reason why I didn't worry too much about the event system was because
> it's pretty easy to write one as an application in the framework.  You could
> even make it where all events are seen by all systems in the same order...
> 
> In fact, you could even write one pretty easily on the heartbeat API.  If
> you want events received in the same order everywhere, you might have to do
> a little more work, but it's not really that bad...
> 
> Basically, you have an event daemon on each machine.  Each of these daemons
> has knowledge of who their local clients are.
> 
> Each daemon is responsible for broadcasting events out, and notifying their
> clients of new events that they have subscribed for.
> 
> It's just another cluster-aware app, which you can start up when/if someone
> requests it.

It was just pointed out to me that I didn't answer the question as asked. 
Maybe this is a better answer :-)

Sorry.

You could build either type of implementation on top of the heartbeat API
easily.

Actually there are three kinds that come to mind:

	A master-node concept, where all events are serialized through this one
		machine.

	A distributed version with event-order coherency, where all events are seen
		in the same order by all machines.

	A distributed version without event-order coherency.

I suppose you could install all types simultaneously, but it sounds like it
wouldn't be very useful, and would confuse the apps.

If you design the API properly, you should be able to hide the differences
between the first two from the application.  The third one has different
semantics, and shouldn't be made to look like the other two...  [and it's
probably not that useful anyway...]


	-- Alan Robertson
	   alanr@unix.sh

Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/