On 09/06/2012 03:45 PM, Chip Burke wrote:
Now that ricci is figured out, I am having some issues with fencing.
It seems VMWare Fence works very well, but our GFS2 volume is not
available until it receives a "success" status. This gives us maybe
30-60 seconds of time where we cannot access the GFS2 volumes which
equates to downtime. SCSI Fencing seems faster, but very unreliable.
If I try to fence a node, it will return "fence somenode success".
Great. But the node can still access the GFS2 volume.
Are you absolutely sure that your array supports SCSI-3 persistent
reservations? When you start cman, you should see that unfencing occurs.
If successful, the devices that comprise your GFS2 volume should have
one WERO (type 5) reservation and one or more registrations.
Can you use sg_persist to verify this? Better yet, use the logfile
option for fence_scsi:
<fencedevice agent="fence_scsi" name="SCSI_Fence" \
logfile="/tmp/fence_scsi.log"/>
This logfile should show you what is happening when either unfencing or
fencing occur.
Also, when you say you can "access" a GFS2 volume after fencing so you
mean you can write to this volume? If fence_scsi is working correctly,
that should not be possible. How exactly are you accessing the volume
after fencing?
Then I am also seeing conflicting information on using Qdisk with
fence_scsi as it seems to be a no-no. I could swear I saw a note
somewhere that Qdisk and fence_scsi worked together in newer versions
of RHEL.
Can you direct me to the conflicting information? As long as your quorum
device is not subject to SCSI-3 persistent reservations it should work.
In your case, this means your quorum device must not belong to a cluster
volume.
Ryan
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
