[Linux-cluster] Interfacing csnap to cluster stack

[Daniel Phillips]

On Thursday 07 October 2004 18:36, Daniel McNeil wrote:
> On Thu, 2004-10-07 at 10:58, Daniel Phillips wrote:
> > On Thursday 07 October 2004 12:08, Lon Hohberger wrote:
> > > On Thu, 2004-10-07 at 02:07, David Teigland wrote:
> > > > Using DLM locks is a third way you might
> > > > solve this problem without using SM or RM; I don't understand
> > > > the details of how that might work yet but it sounds
> > > > interesting.
> > >
> > > It's primarily because it assumes that the DLM or GuLM can ensure
> > > that only one exclusive lock is granted at a time.  Because of
> > > this, the holder of the lock would thereby become the csnap
> > > master server, and the old master will either have been fenced or
> > > relinquished its duties willfully (and thus is no longer a
> > > threat).
> >
> > Suppose that the winner of the race to get the exclusive lock is a
> > bad choice to run the server.  Perhaps it has a fast connection to
> > the net but is connected to the disk over the network instead of
> > directly like the other nodes.   How do you fix that, within this
> > model?
>
> Good question.  Another good question is how would a resource
> manager know to pick the "best" choice?
>
> It would seem to me that the csnap-server is the best one
> to know if this node is a good choice or not.
>
> I can think of a few of ways of handling this:
>
> 1. If this node is not a good choice to run csnap-server,
>     do not run it at all.  If this node is not directly
>     connected to the disk and is using the net to some
>     other node, that other node has to be running, so that node
>     can be the csnap-server.
>
> 2. Use 2 dlm locks.  1 for "better" choices (direct connected,
>     faster connected), and 1 for "other" choices.  The "better"
>     csnap-servers go for "better" lock exclusive while the "other"
>     csnap-servers go the "better" lock for read and the "other"
>     lock exclusive.  If a csnap-server gets the "better" lock
>     exclusive, he is the master.  If a csnap-server gets the
>     "better" lock for read AND the "other" lock exclusive,
>     he's the master.  Same works for multiple priorities.
>
> 2. If a csnap-server get the lock to be master and he is not
>     the best choice, the server can can check if other
>     csnap-servers are queued behind him.  If there are, he
>     can unlock the lock and the re-lock the lock to give
>     another node the change to be master.

There are a few problems with this line of thinking:

  - You will be faced with the task of coding every possible resource
    metric into some form of locking discipline.

  - Your resource metrics are step functions, the number of steps
    being the number of locking layers you lather on.  Real resource
    metrics are more analog than that.

  - You haven't done anything to address the inherent raciness of
    giving the lock to the first node to grab it.  Chances are good
    you'll always be giving it to the same node.

Regards,

Daniel