Re: A proposal for a General Clustering Framework

["Bill Todd" <billtodd@foo.mv.com>]

----- Original Message -----
From: "Alan Robertson" <alanr@unix.sh>
To: "Peter Badovinatz" <tabmowzo@yahoo.com>
Cc: "linux-cluster" <linux-cluster@nl.linux.org>
Sent: Wednesday, June 06, 2001 12:26 AM
Subject: Re: A proposal for a General Clustering Framework


> Peter Badovinatz wrote:
> >
>
> [snip]
>
> > This does not say that the framework being proposed/discussed would be
> > immediately extensible to HP clusters, but it is not out of the realm of
> > possibility to consider it happening eventually.
>
> It should be considered a design critera of the *framework*, but not
> necessarily of any particular module/plugin in the framework.
>
> The framework itself is mainly a collection of infrastructure pieces and
> APIs.

I'll make one more plug for having *underlying* mechanisms that can be used
in a more general manner (and then drop the subject).  E.g., something that
allows a heartbeat message to be handled completely at interrupt level
rather than consume more processing resources by being dispatched for later
processing (which might be especially important if heartbeats are broadcast
rather than distributed via some kind of ring or hierarchy).

Defining such general-purpose underpinnings benefits everyone - and you'll
need *something* for the specific purposes you're discussing here anyway.
Making it general-purpose does require more design, but if your goal is the
creation of generally-useful core software for clusters then a
general-purpose inter-node communication mechanism ought to be fairly high
on the list anyway.

The important aspects of such a low-level mechanism include performance
flexibility (see previous examples I've given), representational agnosticism
(e.g., the decision to use something like XML belongs to higher layers:
down here, messages or message segments are just byte streams), a namespace
independent of lower-level identifiers such as IP addresses and process IDs
(e.g., so that messages can be addressed to 'Facility Foo on Node Fred', or
perhaps just to 'Facility Foo', wherever it is; any deeper addressing can be
addressed by the registered Facility Foo handler at the destination if
implementing a full address-hierarchy seems excessive), and support for
features such as encryption and source-node-authentication for interconnect
environments that require such things.  Fast Messages offer one paradigm
that seems to fit the bill (with the caveat that I'm familiar with them only
from casual Web-browsing), and there are likely others.

At a slightly higher level come things like event-notification (membership
changes being an obvious biggie) to facilities - but the internal
communication mechanisms they use aren't of that much interest to the
applications they serve (as long as they work well).

I'm no comm expert (so the above may be naive in some respects), but I have
a pretty good idea of what I need for a distributed file system and cache
and my suspicion is that at least some of what I need would be useful to
other applications as well.  However, if you're just going to use existing
facilities such as UDP over kernel sockets then there may indeed not be all
that much code that would be common (in which case an efficient,
high-performance, low-level message facility might well be a good separate
project - and something you might eventually find useful yourselves).

- bill



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