Sunday, December 18, 2011

SCSI-3 persistent reservations

SCSI-3 Persistent Reservations (SCSI-3 PR) are required for I/O fencing and resolve the issues of using SCSI reservations in a clustered SAN environment. SCSI-3 PR enables access for multiple nodes to a device and simultaneously blocks access for other nodes.

SCSI-3 reservations are persistent across SCSI bus resets and support multiple paths from a host to a disk. In contrast, only one host can use SCSI-2 reservations with one path. If the need arises to block access to a device because of data integrity concerns, only one host and one path remain active. The requirements for larger clusters, with multiple nodes reading and writing to storage in a controlled manner, make SCSI-2 reservations obsolete.

SCSI-3 PR uses a concept of registration and reservation. Each system registers its own "key" with a SCSI-3 device. Multiple systems registering keys form a membership and establish a reservation, typically set to "Write Exclusive Registrants Only." The WERO setting enables only registered systems to perform write operations. For a given disk, only one reservation can exist amidst numerous registrations.

With SCSI-3 PR technology, blocking write access is as simple as removing a registration from a device. Only registered members can "eject" the registration of another member. A member wishing to eject another member issues a "preempt and abort" command. Ejecting a node is final and atomic; an ejected node cannot eject another node. In VCS, a node registers the same key for all paths to the device. A single preempt and abort command ejects a node from all paths to the storage device.

Example for performing SCSI-3 PR reserve and eject:

A good practice (used in SunCluster) is to use the machine IP as the registeration key. To obtain the key in hex format:

$ gethostip -x $HOSTNAME
7F000101

Registering a key:

$ sg_persist --out --register --param-sark=7F000101 /dev/emcpowera1

Reserving device:

$ sg_persist --out --reserve --param-rk=7F000101 --prout-type=3 /dev/emcpowera1

Repeat the key registeration for the peer node and try to preempt the device from the peer node:

$ gethostip -x $HOSTNAME
7F000102

$ sg_persist --out --register --param-sark=7F000102 /dev/emcpowera1

$ sg_persist --out --preempt --param-sark=7F000101 --param-rk=7F000102 --prout-type=5 /dev/emcpowera1

1 comments:

Ruby Claire said...

VCS logic determines when to online a service group on a particular system. If the service group contains a disk group, the disk group is imported as part of the service group being brought online.



Reservation forms