[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A proposal for a General Clustering Framework



Bill Todd wrote:
> 
> ----- 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.

This is exactly what this technique is designed to support - allowing the
new code to use the old data formats.

> 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.

It's very clear that, in general, one cannot avoid this requirement.  It's
like saying "if one could avoid machines ever going down, one wouldn't need
an HA system".  OK.   What you said is true -- it's just not very helpful. 
Because, it's clear that the infrastructure must support this obvious and
common need.


	-- Alan Robertson
	   alanr@unix.sh

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