TWI468930B - Performing a data write on a storage device - Google Patents

Description

Perform data writing on the storage device

The present invention relates to a method and system for performing data writing in a storage device. In particular, an embodiment of the present invention provides a mechanism to allow storage subsystems to participate in transactional rollbacks.

In any hardware failure event, data storage within large organizations is of fundamental importance for data reliability and data recovery capabilities. When a large amount of data needs to be stored in a reliable and secure manner, a storage area network (SAN) is a adopted architecture. This technology allows the creation of a network that supports the server's connection to a remote computer's storage device, such as a disk array, which can be rendered as if it were a local connection to the operating system. In such networks, the storage of data and the hardware links between individual components are often seen to contain a large amount of redundancy.

The existence of different methods creates data redundancy. For example, functions such as the snapshot copy function allow the administrator to instantly copy a full disk copy of the data at a point-in-time using available read and write access. Snapshot replication can be used with standard backup tools available in your work environment to create replicas on tape. A snapshot copy can create a copy of the source disk on the target disk. This copy is called a point-in-time copy.

When a snapshot copy is initiated, a relationship is established between the source disk and the target disk. This relationship is the "mapping" of the source disk and the target disk. This mapping allows a point-in-time copy of the source disk to be copied to the associated target disk. The operation of copying from the snapshot is initiated until the storage unit copies all the data from the source disk to the target disk or the relationship is deleted, and the relationship exists between the pair of disks.

When the data has actually been copied, a background process copies the path from the source disk to the target disk. The time it takes to complete the background copy depends on the following criteria: the amount of material being copied, the amount of background copy processing that occurred, and any other activity that occurred.

In storage, the user can create a snapshot copy to get a point-in-time backup of some storage disks. If the user subsequently has a problem with the storage, they can reverse the snapshot copy to restore the saved version of the data. The direction of the snapshot copy relationship is reversible. The previously defined target disk can become the source disk, and the previously defined source disk can become the target disk. The changed material is copied to the disk previously defined as the source.

If the administrator wants to restore the source disk (disk A) back to the point where they originally performed the snapshot copy, the administrator can reverse the snapshot copy relationship. In fact, they reversed the operation of snapshot replication, and the operation of snapshot replication seemed to never happen. The background copy processing of the snapshot copy operation must be completed before it is possible to reverse the disk A as the source and the target disk B.

There are some cases where it is necessary to reverse the original snapshot replication relationship. For example, a snapshot copy relationship has been created between the source disk A and the target disk B, and then data loss occurs on the source disk A. Therefore, it is possible to reverse the snapshot copy relationship so that the disk B is copied to the disk A.

Unfortunately, there are some disadvantages in this method of performing data storage. For example, using the snapshot copy feature, it is directly back to the point in time when the snapshot copy was executed, but in the context of trying to perform a data restore, this is not always the right time. Similarly, when the copying system is implemented as a clock time function, acting as a background, rather than being executed according to the system, this point in time may not be useful for data recovery. Even continuous data protection is not automated and there is no concept of when to perform backups. In addition, because of the nature of many interleaved systems in operation and the need to make them all cross-consistent, replicas tend to be large and contain many combinations of disks. This creates a lot of processing and storage burden. The system must be stopped and refreshed in a holistic manner. In most snapshot replication situations, the application is stopped and the device drive refreshes the cached data before the snapshot is copied. This will refresh all application data to the storage device to create a complete image file containing the disk being copied by the snapshot, possibly the data cached by other disks, and applications not related to snapshot copying.

A first aspect of the present invention provides a method for performing a data write in a storage device, comprising: instructing a device driver to perform data writing on the storage device for the storage device; and indicating by the transaction coordinator The device driver acts as a transaction participant; performs a flashcopy of the storage device; writes the execution data to the storage device; and performs a two-phase commit between the device driver and the transaction coordinator.

A second aspect of the present invention provides a system for performing a data write in a storage device, comprising: a file system for instructing a device driver to perform a data write to the storage device for the storage device; a transaction coordinator for indicating the device driver as a transaction participant; a storage device; and a device driver corresponding to the storage device for performing a snapshot copy of the storage device to cause the execution of the data to be written to the device The storage device and a two-phase commit are performed by the transaction coordinator.

A third aspect of the present invention provides a computer program product on a computer readable medium for operating a device driver for a storage device, the computer program product including instructions for: receiving an instruction The storage device performs a data writing, indicating, by the transaction coordinator, the device driver as a transaction participant; performing a snapshot copy on the storage device; executing the data writing to the storage device; and executing the transaction coordinator with the transaction coordinator Two-phase submission.

Because of the present invention, it is possible to provide a method for maintaining the integrity of data on a storage device that is coupled to a transaction system, such as a storage area network. The present invention provides an efficient and efficient method of recovering data if a transaction (including data writing) fails without excessive processing or storage burden.

In one embodiment, the present invention is a mechanism for allowing a multi-path/device driver software for a controller disk to be converted into a transactional participant, such as DB2 or Websphere software. The present invention allows a network storage disk to become a transaction file service, wherein a transaction recovery will restore all data written to the storage system to the state in which the transaction started. The device driver can participate in the transaction. If the device driver is notified of a transaction in a particular thread, the drive can record all accesses to the storage disk when the thread is updated. The drive can notify the storage controller of the transaction, which establishes a reversible snapshot copy with a timestamp before performing the first data write.

In preparation, if you want to be able to refresh any cache to the disk, but this does not have to be done immediately for all the data, a complete refresh as an example of today, it can only be used for the updated block as a transaction Part. The system does not have to be stopped. The present invention now allows for only refreshing the data associated with the transaction, the transaction containing the data to be written to the disk on which the snapshot was performed, while other data unrelated in the transaction may remain in the cache. This is because in the operation of the present invention, the device driver and the application server can continue to accept new work for other transactions. When the cache data of each transaction can be refreshed independently, it is not necessary to refresh all the data in order to achieve this operation. Therefore, it is not necessary to wait for all work units to stop. The transaction agreement can be transmitted in data traffic metadata, which is transmitted between the drive and the storage controller. Appropriate configuration options in the file system allow users to set the disk they need and transaction coordination.

Snapshot replication can be incremental, so that only the changed material is copied (or returned) after the previous snapshot replication was triggered. This is the most efficient form of operating snapshot replication. When only the grain that the application writes (during the transaction) must be copied back, and the other parts of the data set that need to be transferred to the destination by the background copy process do not have to be copied back, then no need to be made. Background copy processing.

Preferably, the method further comprises: after receiving an instruction to perform a restoration, simultaneously reversing the data writing according to the snapshot copy. In any resume transfer, the device driver can switch the direction of the snapshot copy to restore the data set to what was at the beginning of the transaction. After receiving an instruction to submit a transaction, the device driver can discard the snapshot copy. The snapshot copy can be discarded after the transaction ends.

More advantageously, the step of performing a data write on the storage device is immediately after the snapshot copy of the storage device is initiated. This ensures that the snapshot copy used by the storage device occurs before the point in time immediately following the actual write action of the storage disk. This will ensure that in any possible future recovery, snapshot copying can be used to reclaim data stored in the storage device only prior to the original state before the data was written.

Ideally, the step of applying a transaction coordinator to indicate that the device driver is a transactional participant is accomplished by the device driver. In the preferred embodiment, the application coordinator is used to label the device driver itself. This approach has the advantage of simplifying the procedure by ensuring that the device driver is marked as a transaction participant for the correct transaction.

Figure 1 outlines the system for performing data writing. The file system 10 is in communication with a device driver 12, which corresponds in particular to the storage device 14. Device driver 12 also communicates with transaction coordinator 16. Both file system 10 and transaction coordinator 16 are software components and are located in one or more servers that include a storage area network (SAN) and storage device 14. In an embodiment of the invention, a large number of servers are interconnected with the storage device to form the entire network. The device driver 12 can be a pure software component or a software component and a physical layer.

The file system 10 and the software components of the transaction coordinator 16 have application interfaces corresponding to external applications, wherein the external applications are also executed in the storage area network. For example, the network can manage a business website that an organization uses to receive orders for goods to be purchased, and the storage device 14 stores orders placed by customers via the website. In this case, an application is executed in the network, and the application has a user interface to receive an order through the website, and then takes necessary actions, such as creating an order for providing storage device 14. The application will interact with the file system 10 to perform the work of writing data to the storage device 14.

The transaction coordinator 16 is a software component that ensures that any action taken in the network is as close as required for transaction processing. Transaction processing is designed to maintain a computer system, such as the network in question, in a known, consistent state by ensuring that any independent operations performed in the system are not all completed or all cancelled. Each unit of work in the network is managed by the transaction coordinator 16 to ensure consistency of each unit of work. Transaction processing avoids hardware and software errors. The hardware and software errors leave only partially completed transactions, leaving the network in an unknown, inconsistent state. In case the network (or any component connected to it) fails in the middle of the transaction, the transaction coordinator 16 can guarantee that the operation in any uncommitted (not fully processed) transaction is cancelled.

2 shows the state of the system of FIG. 1 after certain work units have been triggered, the work units being located in a network that requires data to be written to storage device 14. As mentioned above, this is the result of an application that performs a certain operation. The application is executed in a network, for example, an end user is in a website managed by a network-maintained enterprise system. Order. As a result, the user's order needs to be stored in the storage device 14, which stores the information associated with the order.

The first action (1) is that the file system 10 instructs the device driver 12 to perform data writing into the storage device 14 for the storage device 14. Corresponding thereto, the second action (2) application transaction coordinator 16 identifies the device driver 12 as a transaction participant. The action (2) shown in the figure is initiated by the device driver 12 itself, but actually the device driver 12 is indicated by the transaction coordinator 16 and may also be executed by other components in the system, such as by the file system 10.

The purpose of this designation is to turn the device driver 12 into a participant in the transaction processing system and assume all of the attendant requirements. Device driver 12 is now part of the system after initiating the action, which must be verified by transaction coordinator 16 with respect to data writing and form part of a large transaction in the sense of transaction processing.

3 shows the next stage of the data write process, that is, after the device driver 12 is indicated by the transaction coordinator 16, it is used to perform a snapshot copy of the storage device 14. This action is illustrated by action (3) in Figure 3 and causes the disk of storage device 14 to be copied to a new storage location 18, possibly a different hardware portion or a simple new logical location throughout the network. . The essence of the snapshot copy function is to make a copy of the data stored in the storage device 14 at a particular point in time. The snapshot copy function generates a background job that copies the data stored in the storage device 14 to a new storage location 18 at a predetermined rate based on the available bandwidth, such as, but not limited to, a new disk. Additionally, any changes to the material in the storage device 14, or requests for data from the new storage location 18, may result in automatic copying of data from the storage device 14 to the new storage location 18.

The device driver 12 initiates a snapshot copy of the contents of the storage device 14 prior to performing any writing to the storage device 14. Indeed, the device driver 12 takes the work of data writing directly without having to benefit from any intermediary action to ensure that a copy is maintained in the new storage location 18, i.e., a new copy of the data prior to execution is written. In effect, device driver 12 prepares a copy of the data stored in storage device 14 to prepare for any failure in the transaction that constitutes part of the transaction.

The last two actions of the process of writing data are shown in Figure 4, including the act of performing a data write on the storage device 14 (4), and the act of performing a two-phase commit between the device driver 12 and the transaction coordinator 16 ( 5). The first of these two actions, action (4), is a conventional data write from device driver 12 to storage device 14. Under the control of the snapshot copy function, if the material has not been copied by the background work, this will trigger the overwrite data in the storage device 14 to be copied to the new storage location 18 in FIG.

The second of the two actions, the action (5) of performing the two-phase commit between the device driver 12 and the transaction coordinator 16, is the requirement for the application transaction coordinator 16 to indicate the device driver 12 as a transactional participant, such as The details of action (2) in Figure 2 above. This action is shown as two-way communication between the two components 12 and 16. In the current work unit containing the data written to the storage device 14, each action element requires a two-phase commit.

A two-phase commit protocol is a decentralized algorithm that ensures that all components in a decentralized network agree to commit a transaction before the transaction is completed. The agreement may cause all components not to submit the transaction, ie to suspend the transaction. In the two phases of the algorithm, first, the transaction coordinator 16 prepares the commit request phase of the participating component, and the transaction coordinator 16 completes the commit phase of the transaction.

The effect of the two-phase commit on device driver 12 is that device driver 12 must send a consent message or an abort message to transaction coordinator 16, independent of whether the data write of action (4) is complete. In addition, device driver 12 must wait for a commit or restore message from transaction coordinator 16 to complete the two-phase commit process. If device driver 12 is instructed to restore data writes, then device driver 12 must access a snapshot copy of the original data that has been overwritten to properly perform the restore.

The processes shown in Figures 2 through 4 can be summarized into the flow chart of Figure 5. The method of performing data writing on the storage device 14 includes: first, in step S1, the pointing device driver 12 performs data writing to the storage device 14 to the storage device 14. Upon completion, the application transaction coordinator 16 identifies the device driver 12 as a transaction participant in step S2. When the device driver 12 is marked, the snapshot copy of the storage device 14 is performed in step S3 of the next step. When the snapshot copy is initiated, data writing is performed on the storage device 14 immediately following step S4, and step S5 performs a two-phase commit between the device driver 12 and the transaction coordinator 16.

Two possible outcomes of the two-phase commit process are represented as two mutually exclusive steps S6 and S7. The first possibility is step S6, which involves receiving an instruction to perform the restoration and reversing the data write based on the snapshot copy. The second possibility is step S7, which involves receiving an instruction to submit the transaction and discarding the snapshot copy. Referring to Figures 2 through 4 and the above description, the most important advantage of steps S1 through S5 is that in a recovery event, if it is not caused by the device driver 12 voted to reject the two-phase commit, it is restored by the indication. The transaction coordinator 16 is caused (after a different participant vote rejection), and then the snapshot copy can be used to reconstruct the data on the storage device 14. The snapshot copy causes a copy of the data stored in device 14 to be copied to the new storage location 18 and can be reversed to effectively eliminate data writes. If there is a decision to submit a transaction containing the current unit of work, then the snapshot copy can be discarded.

10. . . File system

12. . . Device driver

14. . . Storage device

16. . . Transaction coordinator

18. . . New storage location

1 is a schematic diagram of a system for performing data writing on a storage device.

Figures 2 through 4 are further system overviews of Figure 1 showing the flow of data in the system.

Figure 5 is a flow chart of a method for performing data writing on a storage device.

Claims (11)

A method for performing a data writing in a storage device, comprising: instructing, by the storage device, a device driver to perform a data writing to the storage device; and indicating, by a transaction coordinator, the device driver as a transaction participant; The storage device performs a flashcopy; the execution of the data is written to the storage device, and a point-in-time is generated from a source disk to a target disk according to a snapshot copy relationship mapping. Copying; and performing a two-phase commit between the device driver and the transaction coordinator; wherein the transaction coordinator issues a preparation message to a plurality of registered transaction participants in a first phase, and A second stage sends a submission message to the transaction participants. The method of claim 1, further comprising receiving an instruction to perform a rollback, and reversing the data write based on the snapshot copy. The method of claim 1, further comprising receiving an instruction to submit the transaction and discarding the snapshot copy. The method of 2 or 3, wherein the step of executing the data writing to the storage device is immediately after the snapshot copy of the storage device is initiated. The method of 2 or 3, wherein the step of marking the device driver as the transaction participant with the transaction coordinator is performed by the device driver. A system for performing a data write in a storage device, comprising: a file system for instructing a device driver to perform a data write to the storage device for the storage device; and a transaction coordinator for indicating the device The drive acts as a transaction participant; a storage device; and a device driver corresponding to the storage device for performing a snapshot copy of the storage device, generating a source disk to a target disk according to a snapshot copy relationship mapping a point-in-time copy to implement writing the data to the storage device and implementing a two-phase commit with the transaction coordinator; wherein the transaction coordinator is A preparation message is sent to a plurality of registered transaction participants in one stage, and a submission message is sent to the transaction participants in a second stage. The system of claim 6, wherein the device driver is further configured to receive an instruction to perform a restore and to reverse the data write based on the snapshot copy. The system of claim 6, wherein the device driver is further configured to receive an instruction to submit the transaction and discard the snapshot copy. 7 or 8 is the system for performing data writing in the storage device, wherein the device driver is further configured to perform the writing of the data to the storage device after the snapshot is initiated. 7 or 8 is the system for performing data writing in a storage device, wherein the device driver is further arranged to mark the device driver as the transaction participant with the transaction coordinator. A computer program comprising a computer program code, when loaded in a computer system and executed, causes the computer system to perform all the steps of the method of any one of claims 1 to 5.