[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    [Linux-ha-dev] [Fwd: Re: draft of updated GRITS note]
From:       David Brower <dbrower () us ! oracle ! com>
Date:       2000-03-08 2:35:07
[Download RAW message or body]

A co-author nails me

-dB

-------- Original Message --------
From: "Gary D. Young" <gdyoung@us.oracle.com>
Subject: Re: draft of updated GRITS note
To: David Brower <dbrower@us.oracle.com>, jleys@us.oracle.com

            Gary Young (mailto:gdyoung@us.oracle.com)

Add another space before my name.
> 
<snip>
>     remains in effect until a quorum group is formed and issues
>     commands to the resources.  The plausible initial policies are
>     "read only" and "no access"; some resources may only be able to
>     enforce "no access".  A "writable" boot policy would be defeat
>     the purpose of the fence.

Fix that last sentence. Perhaps strike the word "be".

>     - Worst Case group members, who will have a third party wired
>       to their reset buttons to force them to be "fenced."  This
>       is an always correct final solution.  The "X10" system can
>       be used to turn off the power to particularly non-cooperative
>       entities.

"This is an always correct final solution." Sounds kind of awkward to
me. Perhaps "This final recourse solution has guaranteed correctness."

>     OPEN: The current proposal does not address layers of fencing or
>     escalation and isolation.  It might be useful to identify levels
>     at which fencing may be stopped without doing higher levels.  For
>     instance, if all disk i/o may be stopped by frobbing the
>     fibrechannel switch, then turning off the power may not be
>     necessary.

Remind me please: what's frobbing?

>     Potential protocols include:
> 
>         ONC RPC
>         CORBA
>         HTTP
>         HTTPS
>         COM/DCOM
>         SMB extensions

Was there some reason why TCP/IP was not included? It's most likely
going to be the communications module used for the first version,
so it seems kinda silly to leave it out. All of the above probably
make use of TCP/IP in some fashion.... perhaps "sockets" or
something would be the appropriate terminology here?

>     To establish ordering of quorum generations, GRITS must consider
>     the possibility of wraparound.  It is suggested that something like
> 
>     static inline x_before_y (unsigned x, unsigned y)
>     {
>         return ((signed) (x - y)) < 0;
>     }
> 
>     will suffice.

Certainly there will be some default generation number that is used
when you initially request the forming of a cluster. So if you happen
to wrap around to it, any new nodes will either assume they are
already part of the cluster, or the storage unit may assume they are
since they have the correct generation number.

Potential solutions could be:
1) to skip the "magic number" assigned as default when incrementing.
2) try to arrange the protocol so that you must have the correct
generation number AND be considered part of the group by GRITS.

Hm. Is this point so obvious that you just glossed over it, or
am I hitting something meritous here?

>     FIXME - For this to work, we need to fix the width of the
>     generation, to 16, 32, or 64 bits.  My inclination is to make it
>     64 bits.

Putting it at 64 bits would make it rather unlikely that the ceiling
is ever hit. 1ms network latency * 2^64 is "sizable". Some machines
may have to do their own 64 bit arithmetic if they don't have 64
bit libraries (or 64 bit processors), but that's not a serious issue.

>     FIXME - There are also issues regarding the need for stable
>     storage for the epoch in resource agents.  What epoch should they
>     obey at resource boot.
> 
> Resource Settings
> 
>     A resourceSetting is a combination of
> 
>         { resource, node, allow|deny }
> 
>     ResourceSettings are a list or array of resourceSettings to
>     cover a set of resource/node bindings.

I'm still keen on putting "administrate" as one of the attributes.
Then fencing "administrate" access from all the rest of the nodes
would result in quorum being established. If everyone seeking
quorum had the protocol of "fence everyone else off, and if those
all succeed then you're the reconfig leader". (If two people were
vying, obviously one of them would fence the other first, and
then at least one of the other's fencing commands would fail.
Whoever else they fence in the process would be redundant.)

This has issues when the reconfig leader dies, though.... but
I suppose any quorum service has to be able to recover from
the token being lost.

>     OPEN:  the current proposal does not address errors or timeouts
>     that could be returned from Set operations.

Ack/Nack-ing each set request would have its merits. The option of
querying after each request to verify that it went though has a flaw
when of someone interfering between your set and your verification
request.

> NATALIE
> 
>     The NATALIE extensions to NFS are additional RPC interfaces to
>     perform manipulation of the live state of the NFS servers.  In
>     particular, NATALIE supports forceable eviction of mounting
>     clients.  This is principally useful for cluster "fence off", but
>     is administratively useful on its own merits in non-cluster
>     environments.

Gee... that second sentence is producing too many mental images. :)
 
> Summary of open areas and problems
> ----------------------------------
> 
>     1.  Can we use fencing to resolve quorum?  How would that
>         actually work?

See above. I think it will work.

>     4.  Error reporting and propagation have not been addressed.  If
>         an attempt to fence fails, what to we do?  This leads to
>         hierarchies above.

My gut feeling says to either acknowledge every fence request or to
acknowledge none.

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.tummy.com
http://lists.tummy.com/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[prev in list] [next in list] [prev in thread] [next in thread]