Changes between Version 27 and Version 28 of SCSI_FencingConfig_RHEL5
- 05/22/11 01:10:43 (5 years ago)
v27 v28 1 == Using SCSI Persistent Reservations with Red Hat Cluster Suite == 1 == Using SCSI Persistent Reservations with Red Hat Cluster Suite == 2 2 === 1 Introduction === 3 3 When cluster nodes share storage devices, it is necessary to control access to the storage devices. In the event of a node failure, the failed not should not have access to the underlying storage devices. SCSI persistent reservations provide the capability to control the access of each node to shared storage devices. Red Hat Cluster Suite employs SCSI persistent reservations as a fencing methods through the use of the fence_scsi agent. The fence_scsi agent provides a method to revoke access to shared storage devices, provided that the storage support SCSI persistent reservations. … … 31 31 In order to use SCSI persistent reservations as a fencing method, all shared storage must use LVM2 cluster volumes. In addition, all devices within these volumes must be SPC-3 compliant. SCSI-2 devices are not supported. If you are unsure if your cluster and shared storage environment meets these requirements, a script is available to determine if your shared storage devices are capable of using SCSI persistent reservations. See section 5.1. 32 32 33 === 4 Limitations === 33 === 4 Limitations === 34 34 In addition to these requirements, fencing by way of SCSI persistent reservations also some limitations. 35 35 … … 42 42 * Devices used for the cluster volumes should be a complete LUN, not partitions. SCSI persistent reservations work on an entire LUN, meaning that access is controlled to each LUN, not individual partitions. 43 43 44 * fence_scsi can not be used in a 2-node cluster [[http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=66c513bfc91bdd325c3620b4da9c66d5028fcf23|yet]]. 44 * fence_scsi can. 45 45 46 * fence_scsi cannot be easily used with qdiskd in a predictable manner today 47 * Predictability can be enhanced utilizing Eduardo Damato's patches: 48 * STABLE3 branch: [[http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=66747c23e6791b7a3360c85f36ad4c865ebea7d4|1]] [[http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=710af80f016ce390f957c3726c1825411598d2c8|2]] [[http://git.fedorahosted.org/git/?p=cluster.git;a=commit;h=305b7f1c01f195d0df069eadf805433d522e789e|3]] 49 * RHEL5 branch: [[https://bugzilla.redhat.com/show_bug.cgi?id=511113|bug 511113]] 50 * the qdiskd LUN must be separate from CLVM LUNs or else qdiskd will require quorum to start, causing a chicken-and-egg problem 51 * doing this means your quorum disk will ''not'' get fenced when the rest of the LUNs are fenced 52 * a clever heuristic could be used to detect loss of ''other'' LUNs 46 * fence_scsi can be used with qdiskd only in RHEL 5.4.z and later. The qdiskd LUN must be separate from CLVM LUNs (see qdisk man page section 1.4 "Limitations" for more information). The reason for this limitation is the prevent the quorum disk from being fenced with the other LUNs are fenced. 53 47 54 48 To assist with finding and detecting devices which are (or are not) suitable for use with fence_scsi, a tool has been provided. The fence_scsi_test script will find devices visible to the node and report whether or not they are compatible with SCSI persistent reservations.