In a RHEL 5 or 6 cluster using SCSI persistent reservation fencing (fence_scsi), is it normal for the reservation holder to stay the same even after the service relocates?
Environment
- Red Hat Enterprise Linux (RHEL) 5 or 6 with the High Availability Add On
- One or more nodes configured to use SCSI Persistent Reservation Fencing (
fence_scsi)
Issue
- In a RHEL 5 or 6 cluster using SCSI persistent reservation fencing (fence_scsi), is it normal for the reservation holder to stay the same even after the service relocates?
- I can see that all node register to the device, but the reservation never changes, even if the active node with services and VIP changes
Resolution
This is completely normal, and no action is required to correct it.
Root Cause
SCSI Persistent Reservation fencing uses reservations and registrations to control which systems can write to shared storage devices. Nodes register themselves when first joining the cluster, and one node sets up a reservation that tells the SCSI target to only allow registered hosts to have write-access. This reservation has no relation to which node is the owner of a service, the quorum device master, or anything else; its simply the node that set up the reservation for the cluster. If the reservation holder gets fenced, then another node will preempt it with its own reservation, allowing remaining members to continuing writing to the device(s). Nodes that have been fenced have their registrations revoked, so they can no longer write to shared devices until they become cluster members again.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
