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

RE: [Linux-cluster] RE: < fecing with out any hardware? >



 

> -----Original Message-----
> From: linux-cluster-bounces redhat com 
> [mailto:linux-cluster-bounces redhat com] On Behalf Of Bowie Bailey
> Sent: Wednesday, May 03, 2006 11:08 AM
> To: linux clustering
> Subject: RE: [Linux-cluster] RE: < fecing with out any hardware? >
> > 
> > This script can be an automatic login to the failed server (ssh,
> > rlogin, serial console) which can execute any remote operation (for
> > example unload the module of the SAN-device) or causing an kernel
> > panic (which is the fencing-method in ocfs2 ;-) ).
> > 

If you have such a script, it cannot be guaranteed to be successful.  If
the server is so misbehaving that it will not respond to ssh, then all
bets are off and this will never succeed.

The question that I have is that there is functionality in the SCSI-3
spec for Persistent Group Reservations.  Basically, what happens is that
each system that wants access to a disk puts a "reservation" and
"registration" on it.  A commercial clustering solution (Symantec) uses
this feature in order to do it's I/O fencing.

The initial reservation on the disk is "Write Exclusive Registrants
Only", meaning that if you are not registered to be on the disk, you
cannot write to it.  When the node comes up, upon synchronizing with all
of the other nodes, etc, it puts it's key onto the disk.  It can then
write to the disk, without any problem.  When the node dies, the
surviving node(s) see that, and eject the dead node, making it
physically impossible to write to the disk.

This of course requires support from the array to do it (it's a SCSI-3
standard, but not all arrays implement it), thereby limiting the choice
of storage to mid-to-high-end enterprise arrays.  

The question is why can't we use that as a fence mechanism, and do away
with the hardware poweroff stuff, if the array supports it?  Of course
the hardware poweroff stuff could be left in for older/lower end arrays,
etc, but I think that options are a Good Thing(TM).


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