Re: A proposal for a General Clustering Framework

[Michael E Brown <michael_e_brown@dell.com>]

On Tue, 5 Jun 2001, Jeff Darcy wrote:

>
> As for efficiency, this is where we get back to your point highlighted
> previously.  RPC forces *gross* algorithmic inefficiencies for operations
> needed by a cluster infrastructure.  RPC is oriented toward point-to-point
> or broadcast communication, while the most useful conceptual structure for
> many things in a cluster does(membership, voting, some parts of
> heartbeating) is likely to be a ring.  Aggregating point-to-point RPC into a
> star topology based around a temporarily-elected communications server
> doesn't work.  Leader election is one of the services a cluster
> infrastructure *provides*, not one it consumes from elsewhere.  The only
> alternative implementable via RPC is all-to-all, which simply doesn't scale.
> In short, the conceptual model of RPC forces logical-topology decisions in
> directions that are far from optimal for clusters.

<smile>
 Can't we all just be friends?
</smile>

I think it would be pretty easy to define a new 'multicast' protocol spec
to distribute XMLRPC messages. At this point, XMLRPC ceases to be RPC, but
just a generic message passing mechanism. You can then implement the star
model you are talking about.

The model that I am thinking about has libraries on the back-end that are
accessible via XMLRPC through several 'transports' to remote systems. This
gives the flexibility to use libraries in other languages that are already
developed and in use, so we don't have to 'roll our own' protocol and
message passing spec. Along with the 'roll our own' idea we would then
have to write language bindings for several languages and keep them all
up-to-date with the main library.  And _that_ isn't scalable.

HTH,
Michael Brown


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