Patent Application
20120102561
1. Field of the Invention
This invention relates to systems and methods for enabling reservations in SCSI architectures.
2. Background of the Invention
In storage networks such as storage-area-networks (SANs), storage devices are often shared by multiple servers, multiple applications on the same server, or a distributed application on multiple servers. This sharing of storage devices can make it a challenge to maintain data integrity on the storage devices. To maintain data integrity, access to a storage device needs to be controlled to ensure that data accessed by an application is protected during that access from corruption or modification by another application. SCSI architectures attempt to provide such protection using a feature called “reservations” (including persistent reservations). Reservations are created between SCSI initiator ports and SCSI target ports to ensure exclusive access to storage resources when multiple servers are accessing the same resources.
Unfortunately, SCSI reservations fail to adequately protect data accessed by one application on a server from another application on the same server. This is at least partly because SCSI architectures do not provide protection for individual applications, but rather for “application clients.” Such application clients may encompass multiple applications running on a server. When a reservation is created, an application client is tied to an “I_T nexus,” which corresponds to a relationship between a single port on an initiator device and a single port on a target device. Reservations in SCSI are limited to a single I_T nexus or a group of I_T nexuses, where the group of I_T nexuses can be joined by any I_T nexus. That is, SCSI reservations are limited to a single I_T nexus, which is protected from other I_T nexuses, or a group of I_T nexuses that can be joined by any other I_T nexus (some consider this to provide no real protection). These limitations have led to data integrity problems caused by multiple applications communicating through the same I_T nexus and interfering with one another. These limitations have also led to distributed applications not using SCSI reservations at all because it is too difficult to coordinate through which I_T nexus each access will be made.
In view of the foregoing, what are needed are systems and methods to provide more effective reservations in SCSI architectures. More specifically, systems and methods are needed to ensure that data accessed by one application is protected during that access from corruption or modification by another application.
The invention has been developed in response to the present state of the art and, in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available systems and methods. Accordingly, the invention has been developed to provide systems and methods for providing more effective reservations in SCSI architectures. The features and advantages of the invention will become more fully apparent from the following description and appended claims, or may be learned by practice of the invention as set forth hereinafter.
Consistent with the foregoing, a method for enabling reservations in SCSI architectures is disclosed herein. In one embodiment, such a method includes receiving a reservation request from a SCSI initiator. The method then generates a token in response to receiving the reservation request, stores the token, and transmits a copy of the token to the SCSI initiator. An application on a SCSI initiator may attach this token to commands transmitted while the reservation is in place. Upon receiving a command from the SCSI initiator, the method compares the token attached to the command with the stored token. If the attached token and stored token match, the method processes the command. Otherwise, the command is not processed. As will be explained in more detail hereafter, this method protects data accessed by a first application from modification or corruption by other applications, including applications residing on the same server as the first application.
A corresponding system and computer program product are also described and claimed herein.
In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through use of the accompanying drawings, in which:
It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the invention, as represented in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout.
As will be appreciated by one skilled in the art, the present invention may be embodied as an apparatus, system, method, or computer program product. Furthermore, the present invention may take the form of a hardware embodiment, a software embodiment (including firmware, resident software, microcode, etc.) configured to operate hardware, or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “module” or “system.” Furthermore, the present invention may take the form of a computer-usable storage medium embodied in any tangible medium of expression having computer-usable program code stored therein.
Any combination of one or more computer-usable or computer-readable storage medium(s) may be utilized to store the computer program product. The computer-usable or computer-readable storage medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable storage medium may include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CDROM), an optical storage device, or a magnetic storage device. In the context of this document, a computer-usable or computer-readable storage medium may be any medium that can contain, store, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. Computer program code for implementing the invention may also be written in a low-level programming language such as assembly language.
The present invention may be described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus, systems, and computer program products according to various embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions or code. These computer program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Referring to
As shown, the network architecture 100 includes one or more computers 102, 106 interconnected by a network 104. The network 104 may include, for example, a local-area-network (LAN) 104, a wide-area-network (WAN) 104, the Internet 104, an intranet 104, or the like. In certain embodiments, the computers 102, 106 may include both client computers 102 and server computers 106 (also referred to as “host systems” 106). In general, the client computers 102 initiate communication sessions, whereas the server computers 106 wait for requests from the client computers 102. In certain embodiments, the computers 102 and/or servers 106 may connect to one or more internal or external direct-attached storage systems 112 (e.g., hard-disk drives, solid-state drives, tape drives, etc.). These computers 102, 106 and direct-attached storage systems 112 may communicate using protocols such as ATA, SATA, SCSI, SAS, Fibre Channel, or the like.
The network architecture 100 may, in certain embodiments, include a storage network 108 behind the servers 106, such as a storage-area-network (SAN) 108 or a LAN 108 (e.g., when using network-attached storage). This network 108 may connect the servers 106 to one or more storage systems 110, such as arrays 110a of hard-disk drives or solid-state drives, tape libraries 110b, individual hard-disk drives 110c or solid-state drives 110c, tape drives 110d, CD-ROM libraries, virtual tape libraries, or the like. To access a storage system 110, a host system 106 may communicate over physical connections from one or more ports on the host 106 to one or more ports on the storage system 110. A connection may be through a switch, fabric, direct connection, or the like. In certain embodiments, the servers 106 and storage systems 110 may communicate using a networking standard such as Fibre Channel (FC).
Referring to
In conventional SCSI architectures, a reservation may be created between a SCSI initiator port 206 and a SCSI target port 212 to achieve exclusive access to a particular logical unit 210. When a reservation is created, an application client 204 is tied to an I_T nexus (i.e., a relationship between a single port 206 on the initiator device 200 and a single port 212 on the target device 202). Reservations in conventional SCSI architectures are limited to a single I_T nexus or a group of I_T nexuses where the group of I_T nexuses may be joined by any I_T nexus. Although a reservation established for a single I_T nexus may be effective to prevent access to a logical unit 210 by way of another I_T nexus, it does not prevent multiple applications 208 from interfering with one another over the same I_T nexus. As a result, reservations based on an I_T nexus can create data integrity problems where multiple applications 208 communicate over the same I_T nexus.
Referring to
As shown in
When an application 208 needs to establish a reservation with a logical unit 210 in the SCSI target device 202, a reservation request module 302 may be used to transmit a request to the logical unit 210 for a reservation. In response, a token generation module 310 on the target side 202 generates a token for the logical unit 210. In certain embodiments, this token is generated in a substantively unique manner (e.g., pseudo-randomly) for security and/or obfuscation purposes. A store module 312 at the target 202 then stores the token, after which the token is transmitted to the application 208. Upon receiving the token at the application 208, a store module 304 stores the token so that it can be attached to future commands transmitted to the logical unit 210 while the reservation is in place. In certain embodiments, the store module 304 stores the token in a place or in a manner such that the token is not accessible to other applications 208.
When the application 208 to which the token is assigned needs to send a command 320 (e.g., a read or write command 320) to the logical unit 210 that has assigned the token, an attachment module 306 attaches the token 322 to the command 320 and transmits the command 320 to the logical unit 210. In certain embodiments, the command 320 and the token are sent in an Extended Command Descriptor Block (XCDB) with the command in the CDB field and the token in an XCDB Descriptor in accordance with the SCSI architecture. Upon receiving the command at the logical unit 210, a validation module 314 validates the token against the token stored for the logical unit 210. If the tokens match, a processing module 316 processes the command. If the tokens do not match, the command is not processed. In this way, commands originating from applications 208 or other sources that do not have the correct token 322 will be rejected. Thus, while the reservation is in place, the reservation modules 300a, 300b will prevent applications 208 that do not possess the token from interfering with an application 208 that does possess the token. This provides substantially more protection than reservations based on an I_T nexus as used in current SCSI architectures.
Once an application 208 no longer needs the reservation, a clear request module 308 may be used to request that the reservation be cleared. More specifically, the clear request module 308 transmits a request to the logical unit 210 to clear the reservation. The attachment module 306 includes the token with this request so the logical unit 210 can verify that the request originates from the application 208. Upon receiving the request, a clear module 318 at the target 202 clears the reservation, which may include retiring the token.
Referring to
To access data on the logical unit 210 while the reservation is in place, the application 208 sends 408 a command 320 (e.g., a read or write command) to the logical unit 210 with the token 322 attached. Upon receiving the command 320, the logical unit 210 validates 410 the token 322 by comparing the attached token with the stored token. In this particular example, the tokens are determined to match at step 410. Since a match is found, the logical unit 210 processes 412 the command 320. The logical unit 210 then returns 414 a status message indicating that the command 320 completed successfully.
When the application 208 no longer needs the reservation, the application 208 sends 416 a request to the logical unit 210 to clear the reservation. The token is attached to this request to confirm that the application 208 is the originator of the request. Upon receiving the request, the logical unit 210 validates 418 the token and clears the reservation, which may include retiring the token. The logical unit 210 then sends 422 confirmation to the application 208 that the reservation is cleared. At this point, since the token is checked in, the same or another application 208 may send a request 400 to the logical unit 210 to create a new reservation, including a new token.
The token-based reservation scheme described in
The token-based reservation scheme may also enable several applications 208 to work together in a more effective manner. For example, once a first application 208 has finished accessing data on a logical unit 210, the application 208 may pass its token to another application 208 to access the same or different data on the logical unit 210. In other embodiments, several applications 208 may possess the token at the same time, and thus have access to data on the same logical unit 210 at the same time, as long as the applications are coordinated in their action and do not compromise data integrity. Once the applications 208 are finished accessing the data, either application 208 may clear the reservation by sending the appropriate request with the token attached thereto. In this way, several applications 208, whether on the same or different servers or devices, may coordinate their operation using the token-based reservation scheme.
Referring to
Referring to
In selected embodiments, an override command may be provided to override a reservation, if needed. For example, if a server or application 208 on a server freezes up or fails, or if a server or application 208 is rendered inoperable for some other reason, an override command may be established to clear the reservation and the associated token so that the logical unit 210 does not become unusable. If such an override is necessary, notification may be sent, if possible, to the application 208 previously holding the reservation so the application 208 is aware that the reservation was terminated.
The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-usable media according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, may be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
