Source: http://www.freepatentsonline.com/8990463.html
Timestamp: 2018-09-26 11:34:22
Document Index: 416972151

Matched Legal Cases: ['art 220', 'art 310', 'art 310', 'art 310', 'art 310', 'art 320', 'art 430', 'art 430', 'art 430', 'art 430', 'art 450', 'art 430', 'art 470', 'art 470', 'art 430', 'art 470', 'art 490', 'art 490', 'art 430', 'art 490', 'art 510', 'art 520']

Transfer of data storage device features - EMC Corporation
Transfer of data storage device features
United States Patent 8990463
Transferring storage device functionality includes providing a device coupled to the storage device, where the device is separate from the storage device, having the device handle I/O requests between an application and the storage device, and, in response to the application issuing an I/O request, having the device determine if the request corresponds to functionality being transferred and, if so, having the device provide the functionality. The device may be a host computer. The application may run on the host computer. A driver on the host computer may provide the functionality. The functionality may include read only functionality, data compression, data encryption, mirroring, and/or status reporting.
Lecrone, Douglas E. (Hopkinton, MA, US)
Linstead, Paul A. (Shrewsbury, MA, US)
Burt, Denis J. (Plymouth, MA, US)
14/139931
EMC Corporation (Hopkinton, MA, US)
710/74
710/15, 710/33
G06F3/00; G06F13/00; G06F13/38; G06F17/50
Download PDF 8990463 PDF help
20100318501 METHODS AND SYSTEMS FOR RULE-BASED WORM ENFORCEMENT 2010-12-16 Alaimo et al. 707/694
20100265608 Systems and Methods for Storage Channel Testing 2010-10-21 Lee et al. 360/31
Huson, Zachary K.
Muirhead and Saturnelli, LLC
This application is a continuation of U.S. patent application Ser. No. 12/925,709 (pending), filed on Oct. 8, 2010, entitled TRANSFER OF DATA STORAGE DEVICE FEATURES which is incorporated by reference herein.
1. A method of simulating storage device functionality, comprising: providing a device coupled to the storage device, wherein the device is separate from the storage device; having the device handle I/O requests between an application and the storage device; and in response to the application issuing an I/O request, having the device receive the I/O request, and determine, based on a selective criteria input to the device, if servicing of the I/O request is subject to a simulation mode; and when, based on the selective criteria input, the device determines that the I/O request is to be serviced in the simulation mode, having the device provide functionality that would otherwise be handled by the storage device to respond to the I/O request, wherein the device simulates the functionality of the storage device to provide the functionality instead of the storage device, and wherein the device inhibits performance of the actual functionality of the storage device even though the storage device permits the functionality.
2. A method, according to claim 1, wherein the device is a host computer.
3. A method, according to claim 2, wherein the application runs on the host computer.
4. A method, according to claim 3, wherein a driver on the host computer provides the functionality.
5. A method, according to claim 1, wherein the functionality includes at least one of: read only functionality, data compression, data encryption, mirroring, and status reporting.
6. A method, according to claim 5, wherein, for each particular functionality provided by the device, the device returns to the application a response corresponding to a response provided by the storage device in connection with the storage device providing the particular functionality.
7. Computer software that simulates functionality of a storage device, the software being provided in a non-transitory computer readable medium of a device that is separate from the storage device, the software comprising: executable code that handles I/O requests between an application and the storage device; executable code that receives an I/O request from the application; executable code that determines, based on a selective criteria input to the device, if servicing of the I/O request is subject to a simulation mode; and executable code for simulating functionality that, when a determination is made based on the selective criteria input that the I/O request is to be serviced in the simulation mode, provides the particular functionality that would otherwise be handled by the storage device to respond to the I/O request, wherein the executable code for simulating functionality simulates the particular functionality of the storage device to provide the particular functionality instead of the storage device, and wherein the executable code for simulating functionality inhibits performance of the actual functionality of the storage device even though the storage device permits the functionality.
8. Computer software, according to claim 7, wherein the device is a host computer.
9. Computer software, according to claim 8, wherein the application runs on the host computer.
10. Computer software, according to claim 9, wherein a driver on the host computer provides the functionality.
11. Computer software, according to claim 7, wherein the functionality includes at least one of: read only functionality, data compression, data encryption, mirroring, and status reporting.
12. Computer software, according to claim 11, further comprising: executable code that returns to the application a response corresponding to a response provided by the storage device in connection with the storage device providing the particular functionality.
13. Computer software, according to claim 7, wherein the selective criteria input is received at the device from a source external to the storage device.
14. Computer software, according to claim 13, wherein source external to the storage device is the application, and wherein the application issues the selective criteria input to the device to determine whether or not the I/O request is serviced in the simulation mode.
15. A method, according to claim 1, wherein the selective criteria input is received at the device from a source external to the storage device.
16. A method, according to claim 15, wherein source external to the storage device is the application, and wherein the application issues the selective criteria input to the device to determine whether or not to determine whether or not the I/O request is serviced in the simulation mode.
This system described herein relates to data storage facilities and more specifically to the field of transferring the functionality of data storage facilities.
RDF may be used to provide for disaster recovery, whereby one or more R2 devices are provided in remote site(s) along with remote host device(s). The R1 storage device(s) are provided at a primary site with one or more host(s) that perform the work for the system. When a failure occurs at a primary site, the work performed using the R1 device may be transparently shifted to the R2 storage device at a remote site. In such a case, the R2 device, which had been read only prior to the failure, becomes a writeable R2 device (and/or becomes an R1 device) that is usable by the host.
In some cases, the system may be designed/configured to rely on the R2 device(s) at remote site(s) being read only. For example, the data written at the primary site may be financial information that should only be writeable by a relatively secure host at the primary site even though it is readable by less secure host(s) at the remote site(s). After a failover occurs and the previously read only remote storage device(s) become writeable, it may be unacceptable to have the (less secure) remote host(s) be able to write data thereto. Note also that, even in instances where the remote host(s) do not actually write any data, the fact that the host(s) have write access may still be problematic (e.g., in situations where it is necessary to prove compliance to data handling regulations).
Accordingly, it is desirable to provide a system that addresses the issues set forth above.
According to the system described herein, transferring storage device functionality includes providing a device coupled to the storage device, where the device is separate from the storage device, having the device handle I/O requests between an application and the storage device, and, in response to the application issuing an I/O request, having the device determine if the request corresponds to functionality being transferred and, if so, having the device provide the functionality. The device may be a host computer. The application may run on the host computer. A driver on the host computer may provide the functionality. The functionality may include read only functionality, data compression, data encryption, mirroring, and/or status reporting. For each particular functionality provided by the device, the device may return to the application a response corresponding to a response provided by the storage device in connection with the storage device providing the particular functionality.
According further to the system described herein, simulating read only functionality of a storage device includes providing a device coupled to the storage device, where the device is separate from the storage device and where the storage device services read and write requests, having the device handle I/O requests between an application and the storage device, in response to the application issuing a write request, the device denying the request by providing a response to the application corresponding to a response provided by the storage device in connection with the storage device having read only functionality, where the device does not provide the write request to the storage device, and, in response to the application issuing a read request, passing the read request on to the storage device. The device may be a host computer. The application may run on the host computer. A driver on the host computer may deny the request and pass the request on to the storage device.
According further to the system described herein, computer software that handles particular storage device functionality. The software is provided in a non-transitory computer readable medium of a device that is separate from the storage device. The software includes executable code that handles I/O requests between an application and the storage device, executable code that determines if a request corresponds to functionality being transferred, and executable code that provides the particular functionality and returns a result to the application in response to the application issuing an I/O request for particular functionality. The device may be a host computer. The application may run on the host computer. A driver on the host computer may provide the functionality. The functionality may include at least one of: read only functionality, data compression, data encryption, mirroring, and status reporting. The computer software may also include executable code that returns to the application a response corresponding to a response provided by the storage device in connection with the storage device providing the particular functionality.
Embodiments of the system are described with reference to the several figures of the drawings, noted as follows.
FIG. 1 is a block diagram of a multiple host data processing system that can benefit from the system described herein and that includes multiple data storage facilities.
FIG. 2 is a flow chart that depicts a typical prior art interaction between an application and a data set.
FIG. 3 is a block diagram of the organization of a logical migration application that operates in accordance with the system described herein.
FIG. 4 is a flow diagram that depicts the operation of the logical migration application in response to a command.
FIG. 5 is a flow diagram of the operation of an initialization module shown in FIG. 3; FIG. 5A is a more detailed flow diagram of an operation shown in FIG. 5.
FIG. 6 is a block diagram depicting one example of a data structure generated by the initialization module shown in FIG. 5.
FIG. 7 constitutes a flow diagram of the operation of a migration and diversion module shown in FIG. 3; FIGS. 7A, 7B and 7C are more detailed flow diagrams of operations shown in FIG. 7.
FIG. 9 is a flow diagram of the operation of a termination module shown in FIG. 3.
FIG. 10 is a flow diagram illustrating deciding whether to perform dynamic data set migration.
FIG. 11 is a flow diagram illustrating selection of a target logical device for data set migration.
FIG. 13 is a block diagram of the organization of an alternative embodiment of a logical migration application that operates in accordance with the system described herein.
FIG. 14 illustrates an embodiment of an encryption module according to the system described herein.
FIG. 15 is a flow chart that illustrates steps performed in connection with data migration when data migration is coupled with encryption as described herein.
FIG. 16 is a flow chart that illustrates steps that may be performed in connection with decrypting data according to the system described herein.
FIG. 17A is a diagram that illustrates an embodiment where a storage device includes a tamper-proof module.
FIG. 17B is a diagram that illustrates an embodiment where a plurality of host devices may each include a tamper-proof module.
FIG. 18 is a diagram that illustrates components of the tamper proof module according to an embodiment of the system described herein.
FIG. 19 is a schematic diagram illustrating a local storage device and a remote storage device according to an embodiment of the system described herein.
FIG. 20 is a schematic diagram illustrating failover to a remote storage device according to an embodiment of the system described herein.
FIG. 21 is a schematic diagram illustrating a host local coupled to a storage device according to an embodiment of the system described herein.
FIG. 22 is a flow chart illustrating processing performed in connection with handling I/O requests according to an embodiment of the system described herein.
FIG. 23 is a flow chart illustrating processing perform in connection with simulating storage device read only functionality according to an embodiment of the system described herein.
FIG. 24 is a flow chart illustrating processing perform in connection with simulating storage device data compression functionality according to an embodiment of the system described herein.
FIG. 25 is a flow chart illustrating processing perform in connection with simulating storage device encryption functionality according to an embodiment of the system described herein.
FIG. 26 is a flow chart illustrating processing perform in connection with simulating storage device data mirroring functionality according to an embodiment of the system described herein.
FIG. 27 is a flow chart illustrating processing perform in connection with simulating storage device status functionality according to an embodiment of the system described herein.
Communications between the single host 21 and input-output devices, such as the data storage facilities 22 and 23, occur through sub-channels. A sub-channel 31 interfaces the host 21 and the source data storage facility 22; a sub-channel 32, the target data storage facility 23. The secondary host 21A has a similar construction with multiple processors 30A, a memory 24A and sub-channels 31A and 32A.
As previously described, a host application and a data storage facility identify the location of data differently. That is, host applications view data at a logical level as data extents or “extents” and/or data sets of one or more extents. The operating system, such as the MVS operating system (z/OS), converts the host addressing format for the data into an addressing format for the data storage facility.
By way of example, assume that the data storage facility 22 in FIG. 1 is an existing, or source, data storage facility and that the data storage facility 23 is either a new or a preexisting data storage facility that is to act as a target to receive data from the source data storage facility 22. The data storage facility 22 has “n” logical devices with logical devices 22(1), 22(2), 22(n−1) and 22(n) being shown in FIG. 1. The data storage facility 23 has “m” logical devices with logical devices 23(1), 23(2), 23(m−1) and 23(m) being shown. In the following discussion the logical devices in the data storage facility 22 are called “source logical devices”; the logical devices in the data storage facility 23, “target logical devices.”
As known, extents forming a data set may be stored in any number of ways. That is, extents in one data set may be contiguous or non-contiguous. For example, assume that the USR1 application 33 and USR2 application 34 interact with three separate data sets designated as a DS1 data set 35, a DS2 data set 36 and a DS3 data set 37 in the source data storage facility 22. For purposes of explanation, assume that all the extents in the DS1 and DS2 data sets 35 and 36 are contiguous and that each data set resides in one logical device. Assume that the DS3 data set 37 has five extents with two extents, DS3(1) and DS3(2) residing non-contiguously on source logical device 22(n−1), while extents DS(3), DS(4) and DS(5) reside contiguously on source logical device 22(n).
The system described herein has the capability of migrating data sets with contiguous extents, non-contiguous extents or a combination thereof. With reference to the specific embodiment of FIG. 1, the system described herein has the capability of migrating each of the disclosed data sets from the source logical devices 22(1), 22(2), 22(n−1) and 22(n) to target logical devices in the data storage facility 23 without interrupting any interaction between the user applications 33 and 34 and the data in the DS1, DS2 and DS3 data sets 35, 36 and 37. For example, both the DS1 and DS2 data sets 35 and 36 can migrate to one logical device, such as the target logical device 23(1). FIG. 1 also depicts an operation by which four extents of the DS3 data set 37 migrate to contiguous locations in the target logical device 23(m−1) while the fifth extent DS3(5) migrates to the target logical device 23(m).
It may be helpful to review the basic operating steps of a user application as shown by the sequence 41 in FIG. 2. When a user application, such as the USR2 application 34, is initialized, step 42 performs certain preliminary functions that are not relevant to the system described herein. Then step 43 opens one or more relevant data sets. For example, the USR1 application 33 could open the DS1 and DS3 data sets 35 and 37 while the USR2 application 34 could open the DS2 data set 36. In part of that process the USR1 and USR2 applications 33 and 34 retrieve the corresponding data set metadata in step 44. The metadata includes MVS catalog information that provides a volume serial number which the system maps to a particular logical device and UCB at any point in time. The VTOC provides the extent list with a set of cylinder and head ranges.
Step 45 performs the application function using the metadata it has retrieved for controlling I/O requests with various input-output units including, for example, the data storage facility 22 in FIG. 1, and particularly the DS1 data set 35, the DS2 data set 36, and the DS3 data set 37. Moreover, each application that opens a data set to be migrated continues to use the original metadata for that data set until the application closes that data set. That is, when an application terminates, step 46 closes any open data set or data sets that the application opened in step 43. However, when one application closes a data set, it is possible for that data set to still be opened to another application. An understanding of this process is important because when an application closes a data set after a migration occurs, the application accesses the migrated data on a target logical device directly when the application subsequently opens the data set.
Logical Data Migration
In many situations a set of configuration statements control the operation of control applications. In some control applications, a set of one or more configuration statements may initiate different phases of the control application. Different configuration statement sets may enable the commencement of initialization, migration and diversion, and termination phases. It is within the skill of those in the art to generate the necessary configuration statements with knowledge of the function of the control application and the specific configuration of the data processing system.
For purposes of this explanation, a “command” represents a set of configuration statements and describes the information related to the system described herein to enable a person to prepare the necessary configuration statements. A given command will be considered to have the capability of controlling the commencement of a single phase or multiple phases in sequence. Also each phase will be considered to be implemented as a module for performing that specific phase.
With this background, FIGS. 1 and 3 depict one example of a Logical Device Migration (LDM) application 50 that can be characterized as migrating one or more data sets from a plurality of extents in one or more source logical devices to one or more target logical devices. The specific LDM logical application may be expressed as having four separate operating modules, each representing a specific function or related group of functions. These include an initialization module 51, a migration and diversion module 52, a termination module 53 and a monitor module 54.
1. A command identifier, such as “LDM” or an equivalent operation code, which identifies the command as a logical data migration command.
2. Arguments identifying the modules of FIG. 3 to be executed in response to the command. For example, these could include an initialization argument, a migration-and-diversion argument, a termination argument, a monitor argument, or some combination of some or all of those arguments;
3. An identification of the source data sets that will be identified by name, either specifically or via pattern matching, and/or by identifying the various source volumes. Identification of the target logical devices will be made either specifically or via rules such as those used by IBM's Storage Management System, i.e., the so-called Storage Group, or similar facility. There are a variety of ways known in the art to identify data groups, sets and extents in a data storage facility;
4. A threshold argument that establishes the number of cylinders or tracks below which the remaining tracks are copied with application I/O quiesced to establish full synchronization and a mirrored state;
5. When data sets are organized in data groups, an argument can determine whether the group migration is to occur in a consistent manner; and
6. In a multi-host network, such as shown in FIG. 1 formed with another host 21A, whether the host is a primary, or owner, host or a secondary, or non-owner, host.
Once the logical data migration application is loaded and activated, the execution of an LDM or equivalent command will initiate any of a variety of operations or sequences as depicted in FIG. 4. For example, step 55 represents the receipt of the command and activation of the monitor module 54 for transactions between that host and any extent to be migrated in response to the LDM command. Step 56 and 57 process the initialization module 51 according to FIG. 5 in response to a valid argument. If the migration-and-diversion argument is valid, step 58 enables step 60 to process the migration and diversion module 52 in accordance with the steps shown in FIGS. 7 through 10 that migrate the data. If the termination argument is valid, step 61 enables step 62 to process the termination module as shown in FIG. 11. This particular implementation would enable all the procedures shown in FIG. 3 to be processed in sequence in response to one command. However, as will become apparent, a first command typically may include only a valid initialization argument or both a valid initialization argument and a migration and diversion argument. Some time later an LDM command would be issued with only a valid termination argument.
Thus, when the initialization module 51 completes its operation, an environment exists for controlling the data migration. The monitor function is active and the data structures are active. Now, by virtue of an LDM command sent with both valid initialization and migration-ad-diversion arguments or a subsequent LDM command with a valid migration-and-diversion argument, the migration and diversion begins.
Migration and Diversion Phase
To minimize the impact of making a logical data migration concurrently with the normal handling of input-output requests from host applications, it is necessary to continue to respond to I/O requests from such host applications for data even as the extents are being migrated. The monitor module 54 performs this necessary function. Such modules can operate by intercepting I/O requests for special processing by the monitor module 54 as known in the art, one example being disclosed in U.S. patent Ser. No. 10/283,976, which is incorporated by reference herein. FIG. 8 depicts the actions of the monitor module 54 in response to I/O requests from user applications, such as the USR1 application 33 or USR2 application 34 in FIG. 1.
Logical Device Migration
The various objectives of the system described herein are realized by means of the utilization of a logical data migration application that responds to a command. The command identifies all the extents to be migrated in a source logical device and locations in the target logical device to receive those extents. As there is a corresponding address in the target logical device for each extent in the source device, it is possible for diverse extents and data sets to be transferred to a single logical device, unlike prior art data migration systems. At initialization the process generates and populates various control data structures. During migration and diversion, the application copies extents on a track-by-track or cylinder-by-cylinder basis for one or more source logical devices to one or more target logical devices based upon address information in the control data structures. During these operations, a monitor module responds to I/O requests from other applications to the extent in this phase by processing the request and, in the case of write operations, updating the information in the control data structures.
The system described herein has been disclosed in terms of certain embodiments. It will be apparent that many modifications can be made to the disclosed apparatus without departing from the system described herein. For example, the system described herein has been described with respect to a specific implementation in a Symmetrix data storage facility available from the assignee of this application. However, the basic functions that implement the logical data migration of the system described herein are readily adapted for other types of data storage facilities. The disclosure additionally includes specific references to organizations of the logical data migration modules such as shown in FIG. 3 and specific sequences of operations as shown in FIGS. 4, 5, 5A, 7, 7A, 7B, 7C, 8 and 9. Variations in these sequences and the specific functions of each particular step may be altered to implement the system described herein with another type of data storage facility or for the purpose of integrating the logical data migration system with other applications or for utilizing existing utilities such as available in commercially available operating systems. Further, the system described herein has been described in terms of a specific transfer between two logical devices and a source data storage facility and a single logical device in a target data storage facility. The system described herein is equally applicable to performing migrations within a single data storage facility.
Following the step 202 is a step 204 where the actual performance, measured at the step 202, is compared with the desired performance to determine if the actual performance meets or exceeds the desired performance. Note that, as used herein, “performance” may be understood broadly to include data management objectives (e.g., type of remote mirroring used), as described elsewhere herein. Like the step 202, the step 204 is fairly straightforward. As described in more detail elsewhere herein, a set of desired performance characteristics may be associated with each data set and/or a group of data sets. Following the step 204 is a test step 206 which determines if the result of the comparison of the step 204 is okay (i.e., the actual performance meets or exceeds the desired performance). If the result of the comparison is not okay, that is, if the actual performance does not meet or exceed the user's desired performance, then control passes from the test step 206 to a step 208 where a new device for the data set is chosen. Choosing a new device at the step 208 is described in more detail elsewhere herein. Following the step 208 is a step 209 where the data is migrated, as described elsewhere herein.
If the device DEV[DI] does not meet the particular criteria CRIT[CI] at the step 236; then control transfers from the step 236 to a step 242 where the device index, DI, is incremented. Thus, the step 236 rejects any devices that do not meet all of the desired criteria. Following step 242, control transfers back to the step 224 where the criteria index, CI, is set to one to begin iterating through the criteria for another device. Thus, the steps of the flow chart 220 are executed until either there are no devices that meet all of the desired criteria, as evidenced by the step 228, or there is at least one device that meets all the desired criteria, as evidenced by the step 234. Thus, either the step 228 is reached, indicating that there are no devices that meet the desired criteria, or the step 234 is reached indicating that there is at least one device that meets all of the desired criteria.
In some cases, there may be a concern that data on a disk or tape or other medium could be compromised, especially in instances where the data includes personal records of thousands of customers. In some situations, it is desirable to provide data encryption without having to modify any applications that use the data. As described in more detail below, it may be possible to use the data migration mechanism discussed herein to provide such application-independent encryption.
Referring to FIG. 13, a data migration application 50′ is like the data migration application 50 of FIG. 3 in that the application 50′ contains an initialization module 51, a migration and diversion module 52, a termination module 53, and a monitor module 54. The application 50′ may also contain an encryption module 302 that may be used to encrypt data as the data is migrated. However, as discussed elsewhere herein, data may also be encrypted without being migrated to another location. The system described herein may provide encryption/decryption to or from any type of storage medium or device, including disk storage, tapes, DVD's, etc.
In an embodiment herein, the encryption module 302 may use generally known and publicly available encryption/decryption algorithms. For example, the algorithm may be one in which the encryption key is publicly known and available while the decryption key is kept secret by one or more entities that use the decryption key to decrypt data. For such encryption/decryption systems, knowledge of the public encryption key does not provide access or knowledge of the decryption key and/or of the unencrypted text. Examples of such encryption/decryption techniques include the public key encryption provided by RSA Systems of Bedford, Mass.
Other systems may be used for encryption/decryption. For example, the encryption/decryption may be provided by one or more systems that use the IBM Common Cryptographic Architecture (CCA), such as the S/390 system provided by IBM. Other systems may be used that do not rely on any public keys but, instead, use only private keys. For such systems, the measures applied to prevent compromise of the key(s) when decrypting may also be applied to the key(s) when encrypting.
Referring to FIG. 14, the encryption module 302 is shown in more detail as having an input for providing clear (unencrypted) data to the encryption module 302. The encryption module 302 also receives as input an encryption key. As discussed elsewhere herein, the encryption key may be publicly known and available and thus may not require any special handling or vaulting. FIG. 14 also shows an output of the encryption module 302 being the encrypted data. In operation, unencrypted data is provided as an input to the encryption module 302 along with the encryption key. The encryption module 302 may use any one of a number of the well-known and publicly available public key encryption algorithms to encrypt the data.
Referring to FIG. 15, a flow chart 310 illustrates steps performed in connection with a portion of the data migration when data migration is coupled with encryption as described herein. The steps of the flow chart 310 may be performed in connection with the step 131 of the flow chart of FIG. 7A where tracks are copied from a source logical device to a target logical device. The steps of the flow chart 310 may also be performed in connection with the step 137 of the flow chart of FIG. 7A. At the step 137, remaining data is copied from the source logical device to the target logical device in connection with data migration.
Processing for the flow chart 310 begins at a first step 312 where an encryption key is obtained. As discussed elsewhere herein, it is possible to use public key cryptography where the encryption key is publicly available and well-known and does not need to be vaulted or kept secret. Following the step 312 is a step 314 where the encryption key is applied to the data being copied from the source logical device to the target logical device. Following the step 314 is a step 316 where the encrypted data is provided to the target logical device. Following the step 316, processing is complete.
As discussed elsewhere herein, decrypting the thus-encrypted data may be a little more involved since the decryption key should be kept secret. As discussed elsewhere herein, there are a number of techniques for maintaining the secrecy of the decryption key. For the system described herein, the decryption key is maintained within the storage device that stores the data or is maintained with the data migration application so that if a malicious (unauthorized) user were to copy the encrypted data onto a tape or other medium or to remove one or more drives from the storage device, the encrypted data would be unusable because the decryption key is maintained with the storage device or data migration application and thus may only be used by authorized users. Mechanisms that may be used for implementing this are described elsewhere herein.
Referring to FIG. 16, a flow chart 320 illustrates steps that may be performed in connection with decrypting data. Processing begins at a first step 322 where the data is decrypted using the secret/private key. Decrypting the data at the step 322 is described in more detail elsewhere herein. Following the step 322 is a step 324 where the decrypted data is provided to the authorized user of the storage device. Following the step 324, processing is complete.
Note that the functionality described herein may be implemented in connection with a data migration to another location, an “in-place” data migration (described elsewhere herein), or as part of the storage process for one or more volumes, files, and/or any other type of storage unit. For example, a user may create a particular logical volume for storing sensitive data and may configure the system to always encrypt data stored to that volume. In that case, the system will cause data written to that volume to be encrypted and will cause data to be read from that volume (by an authorized user) to be decrypted. As described elsewhere herein, the encryption/decryption may be performed in a manner that is transparent to an application running on a host. For example, the encryption/decryption functionality may be provided on the storage device. Alternatively, the encryption/decryption functionality may be provided on one or more hosts using process(es) that intercept host reads and writes from and to the storage device in order to perform the encryption and decryption.
Referring to FIG. 17A, a diagram 340 illustrates an embodiment where a storage device includes a tamper-proof module 342. The diagram 340 also shows a plurality of directors 344a-344c that are coupled to a memory 346 that is internal to the storage device. Each of the directors 344a-344c may represent a host adaptor, a disk adaptor, and/or a remote adaptor. In an embodiment herein, there may be up to sixteen directors coupled to the memory 346. Of course, for other embodiments, there may be a higher or lower maximum number of directors that may be used.
The diagram 340 also shows an optional communication module (CM) 348 that provides an alternative communication path between the directors 344a-344c and/or the tamper-proof module 342. Each of the directors 344a-344c and/or the tamper-proof module 342 may be coupled to the CM 348 so that any one of the directors 344a-344c and/or the tamper-proof module 342 may send a message and/or data to any other one of the directors 344a-344c and/or the tamper-proof module 344 without needing to go through the memory 346. The CM 348 may be implemented using conventional MUX/router technology where a sending one of the directors 344a-344c and/or the tamper-proof module 342 provides an appropriate address to cause a message and/or data to be received by an intended receiving one of the directors 344a-344c and/or the tamper-proof module 342. In addition, a sending one of the directors 344a-344c and/or the tamper-proof module 342 may be able to broadcast a message to all of the other directors 344a-344c and/or the tamper-proof module 342 at the same time.
Referring to FIG. 17B, a diagram 350 illustrates an embodiment that includes a plurality of hosts 352-354 coupled to a storage device 356. Each of the hosts 352-354 may interact with the storage device 356 independent of each other. Alternatively, some or all of the hosts 352-354 may interact with the storage device 356 in concert. The diagram 350 shows the hosts 352 containing the tamper-proof module 342 while the host 354 contains its own version of a tamper-proof module 342′. In the embodiment illustrated by the diagram 350, the functionality of the tamper-proof modules 342, 342′ is moved from the storage device 356 (illustrated by the diagram 340 of FIG. 17A) into each of the hosts 352-354.
Note that it is not necessary for all of the hosts 352-354 to have a tampered-proof module. For example, the diagram 350 shows the hosts of 353 as not including a tamper-proof module. In some embodiments, it is only necessary to provide a tamper-proof module to hosts performing the encryption/decryption function described herein. Note also that it is possible to have encrypting be performed on either the storage device or one of the hosts while decrypting is performed on the other one and that, generally, the functionality described herein may be provided on any appropriate device or combination of devices and may even be moved during operation.
Note that, in instances where data where data is always encrypted for a particular volume, file, or other storage unit (i.e., where data is encrypted at the time of creation and thereafter), it may be advantageous to have the tamper-proof module 342 be in the host(s) to avoid clear-text transmission of data between the host(s) and the storage device. On the other hand, in instances where data is being encrypted in connection with a data migration (either in-place or to another location), it may be advantageous to have the tamper-proof module 342 be part of the storage device. Of course, it is also possible to have tamper-proof modules be both part of the storage device and part of one or more of the host(s). In addition, it is also possible to provide the functionality described herein separate or at least partially separate from both the storage device and the host(s).
For both the embodiment described in connection with FIG. 17A and the embodiment described in connection with FIG. 17B (and any other embodiments), the tamper-proof module 342 may be implemented using hardware, software, or a combination thereof that does not allow inspection of data inside the tamper-proof module 342. For example, if the tamper-proof module 342 is implemented using hardware (e.g., a single chip), the hardware may have a self-destruct mechanism that is activated whenever someone tries to open the hardware. The tamper-proof module may be implemented using the S/390 system (z/Architecture) provided by IBM, discussed elsewhere herein.
Referring to FIG. 18, a diagram 360 illustrates components of the tamper proof module 342. Note that the tamper proof module 342 may be implemented using hardware, software, or any appropriate combination thereof. When the tamper proof module 342 is implemented using software and/or a significant amount of software, the storage device may be configured to only allow certain access to the tamper-proof module 342.
The diagram 360 shows the tamper proof module 342 as including a key database 362 and a decryption module 364. The key database 362 may include all the public keys/private key pairs used for encrypting and decrypting data. The tamper proof module 342 provides, as an output thereto, the public keys (but only the public keys) from the key database 362. As discussed elsewhere herein, the public keys are not secret and are known or knowable by any entity that wishes to encrypt data.
The private keys of the public key/private key pairs stored in the key database 362 are provided to a decryption module 364. The decryption module 364 receives encrypted data from outside the tamper proof module 342 and provides, as an output of the tamper proof module 342, the decrypted data (clear data). In an embodiment herein, no external access is provided to the key data base 362, the decrypt module 364, or any data communication path therebetween. This may be implemented using tamper proof hardware (e.g., a chip) that self-destructs if opened. Alternatively, there may be software/system implementations that prohibit access to the key database 362, the decryption module 364, and/or any data path therebetween.
In some embodiments, a configuration module 366 may be used for providing data to the key database 362. The configuration module 366 may be appropriately secure and accessible only by authorized users. In embodiments that use the configuration module 366, only the configuration module 366 may provide public key/private key pairs to the key database 362. Having such a mechanism prevents a malicious user from providing their own public key/private key pair to the key database 362 in order to gain unauthorized access to data.
Note that with or without the configuration module 366, so long as entities are only allowed to write data to the key database 362 and not read data, it becomes difficult for a legitimately generated public key/private key pair to be compromised.
The system described herein may be implemented in connection with logical data migration where, subsequent to the logical data migration, any reads of the encrypted data (by an authorized user) use the tamper proof module 342 to decrypt the data. Note also that other mechanisms may be used to manage encrypted data. For example, it is possible to have a system where the data is always encrypted whenever written to a storage device and always decrypted whenever read from the storage device so that all of the data stored on the storage system is always encrypted. Such a mechanism may be activated by an optional flag so that a user may select whether to encrypt data or not. Note also that the system described herein may be implemented at any level of code, including microcode of the storage device that reads and writes data. The system may be implemented by intercepting data reads and data writes so that data that is written is encrypted and data that is read (by an authorized user) is decrypted.
The system described herein may be implemented in addition to any other data modification algorithms, including, for example, data compression. The encryption and decryption modules may simultaneously compress the data and/or the data may be compressed by the before or after encryption/decryption. Furthermore, for some implementations, the encryption/decryption may be provided by a user module where the user provides customized modules for encrypting and decrypting data and the system provides hooks for intercepting the data stream on reads and writes (and data migrations) so that the encryption/decryption algorithm is known only to the user that provides his own customized algorithms. In an embodiment herein, the encrypted data is the same size as the decrypted data.
The system described herein may be implemented using “in-place” data migration where data is read from a particular location, encrypted, and then placed back on to the same location. In such a system, a flag (or other appropriate mechanism) may be used to indicate whether each block is encrypted or not. Of course, it is useful if the encrypted data is the same size as the unencrypted data to avoid having to move the data to another location. Note also that a file (or volume) may be accessible while such “in-place” migration is occurring where each block would be decrypted or not depending upon the value of an indicator (e.g., a flag) that indicates whether or not a particular block has been encrypted yet. Once the “in-place” migration is complete, all of the data for the file (or volume) is encrypted so that there may no longer be any need to check the indicator.
For added security, it is possible to require that the public key/private key pairs need to be digitally signed by an authority recognized by the storage device. Thus, a malicious (unauthorized) user that attempts to write its own public key/private key pair to the key database 362 will have difficulty because there may be a mechanism that rejects all public key/private key pairs unless the public key has been digitally singed by a recognized authority (e.g., a PKI CA). In some embodiments, for additional security, the authority may be required to present its own digital certificate and proof that the certificate has not been compromised (i.e., is still valid). Such proof may take the form of a X-509 PKI CRL or any other appropriate mechanism for proving that a digital certificate has not been revoked. In some embodiments, the digital certificate presented by the authority may include the public key that is the portion of the public key/private key pair.
Referring to FIG. 19, a system 400 is shown as including a local storage device 402 coupled to a local host 404 and a remote storage device 406, coupled to a remote host 408. The local host 404 is also coupled to the remote storage device 406. Work is performed at the local host 404, which accesses the local storage device 402 to store and retrieve data. Data from the local storage device 404 is mirrored to the remote storage device 406 using any appropriate mechanism, such as that provided by the SRDF/S product offered by EMC Corporation of Hopkinton, Mass.
Note that the local storage device 402 is labeled “R1” while the remote storage device 406 is labeled “R2”. The designation “R1” may be used for storage devices which exchange data (read and write) with a host while the designation “R2” may be understood to refer to a mirror target. In some embodiments, R2 storage devices may be configured so that a host may only read data from an R2 storage device. For example, for the configuration illustrated by the system 400, the host 408 may read data from the storage device 406, but may not write data thereto. In other embodiments, R2 storage devices may both act as mirror targets and may also behave like R1 devices in some instances. Note that, as described in more detail elsewhere herein, it is possible to have a mixed system so that, for example, the host 404 may read and write to the R2 storage device 406 while the other host 408 may only read data from the storage device 406. Note also that, in instances where hosts are prohibited from writing to R2 devices, a system designer may rely on the R2 being read only for security/compliance purposes. For example, access may be more restricted to the host 408 than it is to the host 404 in instances where data can only be read from the R2 storage devices 406.
Referring to FIG. 20, the system 400 is illustrated with a fault at the local site containing the local host 404 and the local storage device 402. Note that it is possible for the fault to be with communication link to the local site as well as, or instead of, with the local storage device 402. When such a failure occurs, the storage device 406 may seamlessly take over for the storage device 402 so that the transition is not noticed by a user. In FIG. 20, the storage device 406 may or may not become an R1 device, depending on the system configuration. However, for the host 404 to continue work using the storage device 406, the storage device 406 becomes writeable.
Although the system 400 has failed over and the storage device 406 has become writeable, it may not be desirable to allow the host 408 to write to the storage device 406. For example, the host 404 may have been part of a relatively secure system for entering modifying data while the host 408 is relatively insecure and had been used to read data only. The system may have relied on the fact that the storage device 406 was an R2 device that would not accept writes. The system described herein addresses the issues presented by this.
Referring to FIG. 21, the host 408 is shown in more detail coupled to the data storage device 406. As described elsewhere herein, the host 408 may include an application, a UCB, and a driver that communicates with the storage device 406 (e.g., via a subchannel). The system described herein modifies the driver and/or the UCB so that, in instances where it is desirable to prevent the host 408 from writing to the storage device 406, an application on the host 408 that attempts to write to the storage device 406 receives an error message that is effectively identical to the result received when the storage device 406 is configured to be read only. That is, if an application on the host 408 receives a particular result in response to attempting to write to the storage device 406 when the system 400 is in the configuration illustrated by FIG. 19, then the application receives the same result in response to attempting to write to the storage device 406 in the configuration illustrated by FIG. 20 even though the storage device 406 has become writeable. In the first case (FIG. 19), the result may be provided by the storage device 406 and passed through the driver to the application. In the latter case (FIG. 20), the result may be provided directly by the driver to the application without necessarily communicating with the storage device 406. This is described in more detail elsewhere herein.
Referring to FIG. 22, a flow chart 430 illustrates steps performed to provide the functionality described above in connection with FIG. 21 where a host application is prevented from writing data to the storage device 406 even though the storage device 406 has become writeable. The processing illustrated by the flow chart 430 may be performed by a driver for all hosts/applications that access the storage device 406. Alternatively, the processing may be performed selectively. For example, the processing may be performed for accesses by the host 408 (i.e., by a driver within the host 408), but not for accesses by the host 404. The processing illustrated by the flow chart 430 may also be selectively performed for specific applications and/or groups of applications, specific R1/R2 group(s), etc.
Note that, although the system described herein is illustrated using a driver on the host, the processing performed in connection with the flow chart 430 may be provided by another portion of the host (e.g., an API called by the application). In addition, the processing may be performed by a device different from the host, such as another processing device, provided that the device is separate from the storage device. Similarly, all or some of the application processing may be provided on the other device separate from the host.
Processing begins at a first step 432 where the driver receives an I/O request. Following the step 432 is a test step 434 where it is determined if there is to be any special I/O processing (e.g., inhibiting writes even though the storage device permits writes). In some embodiments, special I/O processing may always be performed (e.g., all applications on a host are prevented from writing). In other instances, the test performed at the step 434 is based on selective criteria, such as the application making the call, the particular R1/R2 group, etc. If it is determined at the step 434 that special processing is to be performed, then control passes from the test step 434 to a step 436 where the special I/O processing is performed. The processing at the step 436 is described in more detail elsewhere herein. Following the step 436, processing is complete. If it is determined at the step 434 that special processing is not to be performed, then control transfers from the test step 434 to a step 438 where the I/O is performed in a usual fashion (i.e., without regard to any special processing). Following the step 438, processing is complete.
Referring to FIG. 23, a flow chart 450 illustrates in more detail the special I/O processing provided at the step 436 of the flow chart 430 of FIG. 22, discussed above. Processing begins at a first step 452 where it is determined if the I/O request (received at the step 432, discussed above) is a write request. If not, then control transfers from the step 452 to a step 454 where the I/O is performed in a usual fashion (i.e., without regard to any special processing). Following the step 454, processing is complete.
If it is determined at the test step 452 that the I/O request is a write request, then control transfers from the test step 452 to a test step 456 where it is determined if the system is simulating read-only mode. As discussed elsewhere herein, the storage device to which the write request is being directed allows both reads and writes, but a mechanism provided in the host (e.g., a driver) simulates the storage device being read-only. The test at the step 456 determines if the particular I/O operation should be subject to the read-only restriction. As discussed elsewhere herein, it is possible to simulate the storage device being read only for the entire host storage device, for specific R1/R2 groups, for specific applications, etc.
If it determined at the test step 456 that the I/O operation should not be subject to the read only simulation, then control transfers from the test step 456 to the step 454, discussed above, where the I/O operation is performed. Otherwise, control transfers from the step 456 to a step 458 where the write request is denied. In an embodiment herein, the calling routine (i.e., the application that performed the write operation) receives a response similar (or identical) to the response received by the calling routine if no special processing is performed but the storage device is actually read only. That is, the calling routine receives the response/status that would be received using the prior art with the storage device set to be read only. Following the step 458, processing is complete.
Note that the system described herein may be used with any number and/or configuration of R1 and R2 devices, the different configurations and failover scenarios described, for example, in U.S. Pat. No. 7,647,525 titled RESUMPTION OF OPERATIONS FOLLOWING FAILOVER IN CONNECTION WITH TRIANGULAR ASYNCHRONOUS REPLICATION (the '525 patent), which is incorporated by reference herein. In the event of a failure at the local site and/or links thereto, operations may resume at either of the remote sites using one of the remote storage devices.
Note that the system may be used in connection with planned failovers as well as unplanned failovers. Furthermore, although RDF has been used to illustrate the system herein, the system is not restricted to being used only with RDF. Furthermore, the system may be applied at the host level as illustrated herein, the application level (i.e., different applications on the same host either read and write data or are restricted to read only), different portions of an application, and/or on any appropriate processing unit.
The system described herein may be used to shift processing from the storage device to the host (or other device) for processing other than simulating read only access. For example, the host may handle data compression, data encryption, data mirroring, storage device status requests, etc. This is explained in detail below.
Referring to FIG. 24, a flow chart 470 illustrates processing performed by a host (or other device) to handle data compression processing that would otherwise be handled by a storage device. The processing illustrated by the flow chart 470 is the special processing performed at the step 438 shown in the flow chart 430, discussed above, and may be provided in the driver (or similar module) so that one or more applications do not need to be modified when the host (or other device) simulates the storage device performing data compression/decompression.
Processing begins at a first test step 472 where it is determined if the I/O operation being handled is a write operation. If so, then control transfers from the test step 472 to a step 474 where the data being written is compressed (using any appropriate compression technique). Following the step 474 is a step 476 where the I/O of the compressed data is performed in a usual fashion (i.e., without regard to any special processing). Following the step 476, processing is complete.
If it is determined at the test step 472 that the I/O operation is not a write (i.e., the I/O operation is a read), then control transfers from the test step 472 to a step 478 where the I/O is performed to read the compressed data from the storage device in a usual fashion (i.e., without regard to any special processing). Following the step 478 is a step 482 where the data is decompressed. Following the step 482, processing is complete. The result of performing the processing illustrated by the flow chart 470 is that the storage device can store compressed data without having to perform the processing necessary to compress and decompress the data and without the application needing to do so either. Thus, the application reads and writes data without regard to whether the storage device is performing the compression/decompression or the storage device functionality is being simulated.
Referring to FIG. 25, a flow chart 490 illustrates processing performed by a host (or other device) to handle data encryption processing that would otherwise be handled by a storage device. The processing illustrated by the flow chart 490 is the special processing performed at the step 438 shown in the flow chart 430, discussed above, and may be provided in the driver (or similar module) so that one or more applications do not need to be modified when the host (or other device) simulates the storage device performing encryption.
Processing begins at a first test step 492 where it is determined if the I/O operation being handled is a write operation. If so, then control transfers from the test step 492 to a step 494 where the data being written is encrypted (using any appropriate encryption technique). Following the step 494 is a step 496 where the I/O of the encrypted data is performed in a usual fashion (i.e., without regard to any special processing). Following the step 496, processing is complete.
If it is determined at the test step 492 that the I/O operation is not a write (i.e., the I/O operation is a read), then control transfers from the test step 492 to a step 498 where the I/O is performed to read the encrypted data from the storage device in a usual fashion (i.e., without regard to any special processing). Following the step 498 is a step 502 where the data is decrypted. Following the step 502, processing is complete. The result of performing the processing illustrated by the flow chart 490 is that the storage device can store encrypted data without having to perform the processing necessary to encrypt and decrypt the data and without the application needing to do so either. Thus, the application reads and writes data without regard to whether the storage device is performing the encryption/decryption or the storage device functionality is being simulated.
Referring to FIG. 26, a flow chart 510 illustrates steps performed in connection with using the system herein to provide data mirroring at the host (or other device) instead of at the storage device. Processing begins at a first step 512 where the I/O is performed in a usual fashion (i.e., without regard to any special processing). Following the step 512 is a test step 514 where it is determined if a write operation is being performed. If not, then processing is complete. Otherwise, control transfers from the test step 514 to a step 516 where the data written at the step 512 is written to the mirrors. Following the step 516, processing is complete.
Referring to FIG. 27, a flow chart 520 illustrates steps performed in connection with using the system herein to service status requests at the host (or other device) instead of at the storage device. Processing begins at a first test step 522 where it is determined if a status request is being performed. If not, then control transfers from the test step 522 to a step 524 where the I/O is performed in a usual fashion (i.e., without regard to any special processing). Following the step 524, processing is complete. If it is determined at the test step 522 that a status request is being performed, then control transfers from the test step 522 to a step 526 where the host (or other device) returns the status of the storage device. Following the step 526, processing is complete.
Note that, in some instances, the order of steps in the flowcharts may be modified, where appropriate. The system described herein may be implemented using the hardware described herein, variations thereof, or any other appropriate hardware capable of providing the functionality described herein. It is possible to implement the system described herein to provide more than one of the functionalities discussed herein, and/or additional functionalities, concurrently. The system described herein includes computer software, in a non-transitory computer readable medium, that executes any of the steps described herein.
<- Previous Patent (Storage device, comp...) | Next Patent (Methods for discover...) ->