Re: A proposal for a General Clustering Framework

["Jeff Darcy" <linuxguy@tambreet.com>]

From: "David Brower" <David.Brower@oracle.com>
> The 3X factor of message
> size isn't what will kill in a cluster, it is the algorithms affecting
> the aggregate number of messages.

I'll come back to this point in a little while, at a point where you seem
to've forgotten it.

> I see no reason not to use the
> encoding

I agree.  Using an encoding for which parsing tools etc. already exist
cannot be a bad thing.  In the worst case you're no worse off than if you
had "rolled your own", and often you'll be way ahead.

> It may not be efficient, but it does
> allow configurations that are difficult otherwise -- such as geoclusters
> with heartbeats tunneling through firewalls.

Anybody who can solve the many more difficult problems involved in
implementing geographically-distributed clusters isn't going to lose a
single moment of sleep over firewalls.

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.

Please, look up some of these algorithms in Lynch or Mullender.  Think for a
while about whether they can be adapted to use RPC, efficiently and without
creating SPOFs.  Think about whether the kinds of timeouts and
retransmissions inherent in the RPC model really match the requirements for
those same sorts of things in a cluster environment.  RPC is not a bad
thing, but it's a technological mismatch for cluster requirements.

> Wombat is right on another point that the ordering needed during
> cluster transition (barrier services) aren't well served by an
> event system.  I think that is an application for RPC.

See above for an explanation of why that is not so.

> My
> impression is that many cluster people (including those I
> work with) aren't adequately comfortable or familiar with
> RPC systems

That's insulting.  It would be just as true to say that "RPC people" aren't
adequately familiar with anything *but* the RPC model, and in fact I'm
tempted to do so, but I think this conversation can move along more
productively without such pissing contests.



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