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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/linux-cluster > > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
