[Linux-cluster] Interfacing csnap to cluster stack

[Daniel Phillips]

On Friday 08 October 2004 18:30, Daniel McNeil wrote:
> The csnap server is the best one to know what is best.

It's not running, how can it know?  You probably meant, the csnap agent 
(running in user space on every cluster node).  Then I'd say, how can 
it know by looking only at itself?  (Similar to looking in the mirror 
at yourself and thinking "I'm da man!"  In the real world, it's 
normally other people who decide you're the man, and give you 
responsibilities.)

> See my previous posting on using 2 dlm locks to allow
> different priorities.  A directly connected node will
> be selected if there is one, otherwise one of the "other"
> nodes will be selected.  The csnap server can just do
> the right thing.

Sorry for not responsding to that.  Speed of connection is only one 
metric.  What about the speed and memory capacity of the node itself?  
What about the current workload of the node?  And what about comparing 
these things to other nodes?

> > > (3) Don't use the cluster-lock model.  It has its shortcomings. 
> > > Its strengths are in its simplicity; not its flexibility.
>
> Actually, the DLM can be used in simple ways or very complex
> ways.  It is very flexible.  It does have a different programming
> model that takes time to get use to.

As soon as you start using it in a complex way, you probably should have 
spent your time building the thing you're trying to approximate with 
the dlm.  You'll end up with what you really want, with the same amount 
of effort, or less because you won't spend a lot of time trying to make 
it be something it isn't.

If you find a need for global locking in your design, go ahead and use 
the dlm for it, but don't try to turn the dlm into a resource manager, 
it simply isn't.

Why is it that the hammer/nail effect gets so strong in the vicinity of 
a dlm?

> > Yes, that's the one.  We need real resource management, even if it
> > initially just consists of an administrator setting up config
> > files. Something has to read those config files[1] and respond to
> > server instance requests from csnap agents accordingly.
> >
> > [1] At cluster bring-up time.  The resource manager has to be able
> > to operate without reading files during failover.
>
> IMHO, a resource manager is NOT the right way to do this:
>
> - cluster services should avoid config files if at all possible.
>    If they are are not set up right, the whole cluster can get
>    messed up.  If the cluster changes, the config files might
>    need to change.  The config files will be your single point
>    of failure.  From previous experience, cluster configuration
>    is one of the biggest sources of cluster failure, and you
>    won't know it until a failure -- the worst possible time.

Then the configuration file should let you configure only what needs to 
be configuring.  Anyway, what do config files have to do with needing 
or not needing a resource manager?

> - It makes a low-level function dependent on a higher-level
>    function.  As you say above, the resource manager has to
>    operate very carefully to avoid dead locking.  This is
>    asking for trouble.

Then what we want is a good, low-level resource manager.  Let people 
interface to it and script themselves into oblivion, err, nirvana, but 
make the low level thing very simple and easy to audit.

Regards,

Daniel