Re: A proposal for a General Clustering Framework

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

> I have built message based RPC systems that didn't require replies; they
> were RPC because they completely conformed to CORBA interface definitions
> and "oneway" semantics.

If it's one-way in the sense of not waiting for a reply, it's not RPC
according to any meaningful definition of the term.  I think Greg Lindahl
hit it right on the head when he made a distinction between a loose
definition of RPC and a definition that actually distinguishes it from other
kinds of messaging.

> I will note that
> the kernel components of one commercial cluster system I'm working with
> use RPC interfaces to do membership elections, so there is proof by
> existance.

Not so fast, cowboy.  Is this the one-way RPC-that-is-not-RPC of which you
spoke?  What product is it?  How many nodes does it support?  When you say
you "work with it" does that mean you're intimately involved with the
protocol it *really* uses, or do you work with it in some more distant way?

It's not that I distrust you personally, despite your manner.  It's more
that HA is full of bogus claims, "highly available" systems that aren't
highly available, buzzword compliance, inflated claims, etc.  I'm a little
skeptical of convenient claims like that one.

> Another membership system I see uses hand-rolled
> messaging.  Given an unconstrained choice, I'd use a viable RPC system--
> it would keep me from hand rolling messages

Nobody's saying you should "hand-roll" messages.  Well, OK, I'm not.  ;-)
While we're quoting earlier messages in the thread, you might notice that my
very first response said that XML was a great idea *as a representation*.
What I don't think works so well is tying implementors' hands with a "send a
request to X, wait for a response from X" communications paradigm that's an
ill fit for N-way coordination.

> If I were -really- religious, I'd say to take one of the free ORBs
> and use that with a new transport underneath.

Are any of those free ORBs HA-capable, capable at least of failover if not
of outright distributed operation?  If not, they're simply not usable for
many people.

Yes, I know there are people out there interested in non-HA clustering.
With all due respect, I consider that a pretty different problem.  The
world's very different when failure is the "normal" case, worth optimizing
to minimize downtime, rather than a rare case in the shadow of optimizing
for throughput.



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