Re: A proposal for a General Clustering Framework

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

----- Original Message -----
From: "Alan Robertson" <alanr@unix.sh>
To: "Michael E Brown" <michael_e_brown@dell.com>
Cc: "Jeff Darcy" <linuxguy@tambreet.com>; "David Brower"
<David.Brower@oracle.com>; "linux-cluster" <linux-cluster@nl.linux.org>
Sent: Tuesday, June 05, 2001 3:31 PM
Subject: Re: A proposal for a General Clustering Framework

...

> I am cool with this idea except for one thing:  XML-RPC retains the worst
> aspect of 'C' calling sequences - which is potentially deadly for an HA
> system - positional parameters.
>
> The usual problem with positional parameters is that they assume that
> everyone is compiled against the same version of the function definition.
> Within limits, this is fine for a single non-HA system.
>
> However, in an HA system, calls across nodes *cannot* make this
assumption.
> This is because you can *never* take an HA system down all at once and
> upgrade all the pieces of software at once, then bring it back up.  This
is
> in contradiction with the requirements of an HA system never having to go
> down.

While I agree with the observation expressed elsewhere that name/value pairs
would seem to address the problem you describe, I'll also point out that it
is often easier (and/or safer) to define upgrades (at least those that
affect protocol syntax or semantics) such that all nodes get upgraded (one
by one, with no general outage) to new software that continues to use the
old protocols - and then after all upgrades are complete, a synchronous
cluster-wide transition to the new protocols occurs.  Among other things,
this avoids proliferation of run-time conditionals that depend on the
capabilities of each member.

In general, if one can avoid the requirement to support version
heterogeneity across a cluster, life can be a lot simpler.  While version
heterogeneity is clearly required in general networks (where systems are
under the control of completely independent organizations), it's not clear
that (at least what I think of as) a cluster can't reasonably impose such a
constraint.

- bill



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