[Linux-cluster] disk fencing

[James Devine]

I had looked at qdisk, it looks like qdisk is just a way for the nodes
to share information about what it thinks the current cluster status
is.  It looked like external fencing still needed to take place, which
was normally some power or network intervention.

I was thinking of using the disk to do the fencing also.  It could use
the status information provided in the quorum disk for nodes to
determine if they are fenced off or not.  In the case of complete
cutoff from disk, the remaining nodes would have to work under the
assumption that the failed node(s) were no longer trying to access
disk as they were making no more status updates to the quorum disk for
a period of time.  So they would be "fenced off" as it were, and the
remaining nodes could continue on without them until the node(s) came
back and made further status updates to the quorum disk.  This way,
fencing could be done completely independent of the hardware running,
no need for network or power management.


On Sat, Jul 18, 2009 at 12:50 AM, Ian Hayes<cthulhucalling at gmail.com> wrote:
> I'm not sure what you're asking here, but it sounds like you're describing a
> qdisk.
>
> If a node loses heartbeat with the rest of the cluster, that's a fencin'.
> Doesn't matter if it can still access the shared storage, and if it has lost
> communication with the rest of the cluster, you probably don't want it
> accessing your data anyway.
>
> On Fri, Jul 17, 2009 at 9:20 AM, James Devine <fxmulder at gmail.com> wrote:
>>
>> Has anybody looked into using the network for heartbeat only, and disk
>> for fencing in GFS?  i.e. using the disk to communicate quorum when
>> network heartbeat is lost between 1 or more nodes.  If the disk is
>> still accessible to all nodes, this should be a valid way to
>> communicate quorum, if not, then the remaining nodes, assuming enough
>> for quorum, should be able to continue knowing that nodes it can't
>> communicate with either have been fenced or can't read/write to disk
>> anyway.  Does this sound like a valid approach?
>>
>> --
>> Linux-cluster mailing list
>> Linux-cluster at redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-cluster
>
>
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>