[Linux-cluster] Spectator mount option

[David Teigland]

Sorry for the confusion, I'll try to sort it out...

On Tue, Jun 24, 2008 at 09:54:48PM +0200, Marc Grimme wrote:
> * the spectator node does not get a journal

correct

> * the spectator node cannot replay a journal 

correct

> and therefore cannot be involved in fencing. Or the other way round it
> is not involved in fencing

A node doesn't *need* to be fenced if it can't write to the fs.  If you
*want* spectator nodes to be fenced when the fail, that's fine, just have
them join the fence domain as usual.

> * the spectator node must not have votes. I can but it mustn't.
> * the spectator node is less involved in locking. It does not hold locks?! 
> Does it? Or does it only have read-locks? That is not clear to me. See below.
> 
> On spectator and locking:
> Everything clear except from the locking topic. Why do you think the spectator
> node is less involved in locking. Doesn't it have to request a readlock for 
> any file it wants to read. And as it cannot (if so?!) hold the lock itself it 
> has to ask for it. Isn't this from the network point of view more network 
> traffic then if it would "master/cache" the lock?
> The only advantage would be that no or a less loaded gfs_scand would be 
> running?! I have to admit that this wouldn't be to bad.

I think you're confused by the relationship between the three "features" I
mentioned (1 spectator mount option, 2 zero votes, 3 dlm resource masters).
The key thing to understand is that those three features are *completely
unrelated* to each other; they are completely indepedent, they may or may
not be used together.

Refering to all three collectively as "spectator features" is very
misleading at a technical level.  This misleading language is an
unfortunate accident of marketing.  Technically, the word "spectator" is
only relevant to the gfs mount option (feature 1).  The word "spectator"
has no concrete, technical meaning in cman or dlm.

In your original question about spectators, I believe you were only asking
about the gfs issues (feature 1).  I think we've answered that question
now:  spectator mount option in gfs means the node is assigned no journal,
it cannot do journal recovery, and because it will never write to the fs,
it's ok for it to remain out of the fence domain if desired.  That's all,
it involves nothing different in regard to votes or locking.

So, why bring votes and locking into the picture?  Because if there's an
environment where feature 1 (gfs spectator option) is helpful, features 2
and 3 (voting/locking configurations) might also be helpful.  Again,
there's no technical relationship between any of these features, there's
just a suspicion that people may want to use them together.

I don't think there's any question about the effects of zero votes.

There's a lot of confusion about the dlm configuration.  The dlm settings
have no effect on gfs, all the same gfs locking is done.  The dlm settings
only change the internal dlm algorithm for selecting the master of a
resource.  One node is always the master of a dlm resource; normally the
first node to lock a resource becomes the master.  The new settings change
this so that a fixed node (or nodes) become the master.

Advantages:  When a node is removed, dlm recovery has substantially *less*
work to do when the node was not the master of any resources.  So, this
node will cause less disruption to others in the cluster.  Whether the
overall effect of this is big or small we don't yet know.

Disadvantages:  If a resource is mastered locally, no network messages are
needed to lock it.  So, a side effect of a node *not* mastering any
resources, is that all its locking will involve network messages and
locking may become slower (how much depends entirely on how isolated the
node's fs activity is.)

Dave