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

Re: [Linux-cluster] Interfacing csnap to cluster stack

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.


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