Re: A proposal for a General Clustering Framework

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

> IMO, IBM and Compaq both Got It Right when they
> put an generalized pub/sub event system in the middle
> of their cluster frameworks.

A generalized event system is a great idea, but I'm not sure that "pub/sub"
belongs in the middle of the cluster framework.  One of the most critical
functionalities for a cluster infrastructure is agreement on which of
several events (which may be merely symptoms of a single actual failure) to
process first.  That process is difficult enough when everyone agrees on the
list of candidates.  At this level, there should be no subscription
requirement; all nodes should get all events, period.  That sort of
filtering belongs at what I'd call the top of the framework, not the middle.

> FWIW, xml-rpc is a perfectly fine mechanism for such
> an event system, once you get the subscription mechanism
> in place.  You probably also want more authentication and
> authorization than is used on things that assume private
> networks for cluster traffic.

I'm afraid you (all) will have to forgive me some of my biases.  I spent a
lot of time developing protocols for this kind of thing, in code that was
later credited to IBM.  One conclusion I reached during that work is that
*RPC is evil* as soon as you depart from the two-party request-response
model for which it was designed.  Yes, yes, I know you can do broadcast RPC
and stuff, but that's just a collection of two-way conversations and
fundamentally different than the sort of true multi-way conversation you
need for cluster stuff.  XML is fine as a representation, and XML-RPC might
be fine as part of a top-level notification API, but deep down in the guts
of things I think all flavors of RPC should be avoided.


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