Porting storage metadata

Migrating data from an old storage device to a new storage device includes creating new paths to the new storage device, freezing old paths to the old storage device, transferring metadata corresponding to the old storage device to the new storage device, where state information is transferred from the old storage device to the new storage device, and thawing the new paths. Migrating data from an old storage device to a new storage device may also include creating new volumes on the new storage device and transferring data from the old storage device to the new storage device. Migrating data from an old storage device to a new storage device may also include dismantling the old paths.

BACKGROUND OF THE INVENTION

1. Technical Field

This application relates to the field of storage devices, and more particularly to the field of migrating data between storage devices.

2. Description of Related Art

It is desirable to be able to move user applications and data among servers and storage arrays in a non-disruptive fashion while the user is actively using the applications and/or data. Although various techniques exist to facilitate non-disruptive data migration, these techniques do not necessarily properly transfer I/O state information. However, many systems rely on metadata, such as I/O state information, for proper operation. For example, in some computer cluster configurations, each of the computers maintains its state (active or passive) and, in some cases, changes its state, based on I/O metadata. Such a system may not operate properly if data was migrated without also properly migrating the metadata.

Accordingly, it is desirable to provide a system that can migrate data as well as associated metadata, including state information, associated with the data.

SUMMARY OF THE INVENTION

According to the system described herein, migrating data from an old storage device to a new storage device includes creating new paths to the new storage device, freezing old paths to the old storage device, transferring metadata corresponding to the old storage device to the new storage device, where state information is transferred from the old storage device to the new storage device, and thawing the new paths. Migrating data from an old storage device to a new storage device may also include creating new volumes on the new storage device and transferring data from the old storage device to the new storage device. Migrating data from an old storage device to a new storage device may also include dismantling the old paths. Transferring metadata may include exporting the metadata from the old storage device to a platform-independent format and then subsequently importing the metadata to the new storage device, where a format of the metadata on the new storage device may be different from a format of the metadata on the old storage device Each of the paths may include a source port, a target port, a LUN, and a state descriptor. The paths may correspond to SCSI connections. A process manager may interact with a SCSI driver to transfer the metadata.

According further to the system described herein, computer software, provided in a non-transitory computer readable medium, migrates data from an old storage device to a new storage device. The software includes executable code that creates new paths to the new storage device, executable code that freezes old paths to the old storage device, executable code that transfers metadata corresponding to the old storage device to the new storage device, where state information is transferred from the old storage device to the new storage device, and executable code that thaws the new paths. The computer software may also include executable code that creates new volumes on the new storage device and executable code that transfers data from the old storage device to the new storage device. The computer software may also include executable code that dismantles the old paths. Executable code that transfers metadata may include executable code that exports the metadata from the old storage device to a platform-independent format and executable code that imports the metadata to the new storage device, where a format of the metadata on the new storage device may be different from a format of the metadata on the old storage device. Each of the paths may include, a source port, a target port, a LUN, and a state descriptor. The paths may correspond to SCSI connections. A process manager may interact with a SCSI driver to transfer the metadata.

According further to the system described herein, handling hibernation of a process includes freezing paths corresponding to the process, freezing the process, and obtaining a snapshot of data and metadata for the process. Handling hibernation of a process may also include, following obtaining the snapshot, thawing the paths corresponding to the process. Metadata for the process may be stored in a platform-independent format. The paths may correspond to SCSI connections. Handling hibernation of a process may also include, following obtaining the snapshot, restoring the snapshot and then resuming the process, and following resuming the process, thawing the paths. Handling hibernation of a process may also include, following thawing the paths, freezing the paths a second time, following freezing the paths a second time, restoring the snapshot and then resuming the process, and following resuming the process, thawing the paths a second time.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

Referring toFIG. 1, a diagram30shows a plurality of hosts32-34coupled to a plurality of storage devices36-38via a network42. The hosts32-34represent any processing devices. There may be any number of hosts and the hosts32-34may or may not be the same (i.e., the same type of device). Similarly, the storage devices36-38represent any storage devices. There may be any number of storage devices and the storage devices36-38may or may not be the same (i.e., same type of device). Each of the hosts32-34may be selectively coupled to one or more of the storage devices36-38to access data therefrom through the network42. Note that each of the storage devices36-38may be coupled to more than one of the hosts32-34. The network may be any appropriate mechanism for providing data interconnections, including a SAN, a WAN, a LAN, the World-Wide Web, a cloud, etc. or some combination thereof.

The system described herein provides for porting executable images (e.g., programs) from one of the hosts32-34to another one of the hosts32-34, porting data images (e.g., data) from one of the storage devices36-38to another one of the storage devices36-38, and/or both. As discussed in detail herein, it is desirable to be able to maintain metadata (state information) in connection with porting executable images and/or data. The system described herein provides a mechanism for doing so. The hosts32-34are connected to the storage devices36-38via paths therebetween. Paths are described in more detail below.

Referring toFIG. 2, the host32is shown in more detail as including a plurality of applications52-54, a SCSI driver56, and a process manager58. Although the specific host32is shown inFIG. 2, the discussion herein is meant to include any host or other processing device. The applications52-54represent any number of applications that may perform any appropriate type of processing. The applications52-54send and receive I/O through the SCSI driver56, which provides appropriate low level driver functionality to the applications52-54. In an embodiment herein, the SCSI driver56may provide conventional SCSI I/O functionality.

The host32also includes a plurality of ports62that provide logical I/O channels for the host32. Each of the ports62may correspond to a separate physical connection or at least some of the ports62may correspond to the same physical connection. The SCSI driver56may maintain a connection table indicating which of the ports62is coupled to which of the applications52-54and also possibly indicating the state of each of the ports62. Each of the applications52-54may also internally maintain a similar connection table. In some embodiments, it is possible for each of the applications52-54and/or the SCSI driver56to use different internal identifiers to refer to the same one of the ports62.

The process manager58interacts with the SCSI driver56to facilitate migration of port metadata (state information) along with migration of corresponding data. The process manager58may also facilitate hibernation, as described in more detail elsewhere herein. That is, for example, if the host32initially performs I/O operations using the storage device36, but then switches to using the storage device37, the process manager58facilitates the switch by handling the appropriate transfer of the metadata corresponding to the data. Operation of the process manager58is described in more detail elsewhere herein.

Referring toFIG. 3, the storage device36is shown in more detail as including one or more storage units72, a disk driver74coupled to the storage units72, and a SCSI driver76coupled to the disk driver74. Although the specific storage device36is shown inFIG. 3, the discussion herein is meant to include any appropriate storage device. The storage device36may be a disk array storage device so that the storage units72are disk drives. Of course, the storage device36could be any other type of storage device. The SCSI driver76is like the SCSI driver56, discussed above in connection withFIG. 2, except that the SCSI driver76provides I/O for the storage device36rather than the host32. In an embodiment herein, the SCSI driver76acts as a target to receive I/Os while the SCSI driver56acts as an initiator to send I/Os.

The storage device36also includes SCSI metadata78(state information), coupled to the SCSI driver76, that maintains, inter alia, the state of connections to the storage device36. A process manager82is coupled to both the SCSI driver76and the SCSI metadata78. The storage device36also includes a plurality of ports84that provide logical I/O channels for the storage device36. As with the host32, each of the ports84may correspond to a separate physical connection or at least some of the ports84may correspond to the same physical connection. The SCSI driver76may maintain a connection table indicating which of the ports84is coupled to which of the storage units72and also possibly indicating the state of each of the ports84. The disk driver74may also internally maintain a similar connection table. In some embodiments, it is possible for the different tables to use different internal identifiers to refer to the same one of the ports84.

The process manager82interacts with the SCSI driver76to facilitate migration of port metadata (state information) along with migration of corresponding data. The process manager82may also facilitate hibernation, as described in more detail elsewhere herein. That is, for example, if the host32initially performs I/O operations using the storage device36, but then switches to using the storage device37, the process manager84facilitates the switch by handling the appropriate transfer of metadata. Operation of the process manager84is described in more detail elsewhere herein.

Connections between the hosts32-34and the storage devices36-38may be provided by defining a plurality of paths therebetween through the network42. Each of the paths may include a source port (initiator port), a destination port (target port), and a port state identifier (state descriptor). The source port may correspond to a port on one of the hosts32-34while the destination port may correspond to a port on one of the storage devices36-38. The defined paths may correspond to the connection tables maintained by the hosts32-34and the storage devices36-38.

In an embodiment herein, the process manager58of the host32is used to facilitate migration from one of the hosts32-34to another one of the hosts32-34while the process manager82of the storage device36is used to facilitate migration from one of the storage devices36-38to another one of the storage devices36-38. Of course, it is also possible to have other arrangements so that, for example, the process manager58of the host32may be used to facilitate migration from one of the storage devices36-38to another one of the storage devices36-38and/or the process manager82of the storage device36is used to facilitate migration from one of the hosts32-34to another one of the hosts32-34.

Referring toFIG. 4, a flow chart100illustrates steps performed in connection with migrating from using a first one of the storage devices36-38(old storage device) to using a second one of the storage devices36-38(new storage device). As used herein, “old” and “new” may be used to refer to source and target storage devices, respectively, and may not necessarily indicate a relative age of the storage devices. It is desirable to be able to provide the migration in a way that is transparent to an entity accessing the data and does not require suspension of the entities accessing the data. That is, one or more of the applications52-54on one or more of the hosts32-34operate continuously before and after migration of data from one of the storage devices36-38to another one of the storage devices36-38. As described elsewhere herein, providing a seamless migration includes properly migrating metadata (state information) associated with the data so that each new path takes on state information of a corresponding old path. Note that the processing illustrated by the flow chart100may be performed by the process manager82of the storage device36and/or by other appropriate processes/devices, such as the process manager58possibly in concert with other processing devices.

Processing for the flow chart100begins at a step102where new volumes (e.g., logical volumes) are created on the new storage device. The new volumes will contain the data that is being transferred to the new storage device. Following the step102is a step104where new paths are created from the one or more of the hosts (computing devices) to the new storage device. Following the step104is a step106where the new paths are discovered (e.g., the source entities determine the target ports and characteristics of devices corresponding thereto). In an embodiment herein, the paths to the new storage device are initiated in a frozen state, which prevents any new I/O operations being performed using those paths.

Following the step106is a step108where the user data is transferred from the volumes on the old storage device to the volumes on the new storage device using any appropriate technique. Mechanisms for transferring user data are known. In some embodiments, user data migration is initiated at the step108and is performed asynchronously and in parallel with respect to the remaining processing performed in connection with the flow chart100.

Following the step108is a step112where the paths from the old storage device are frozen. Making the paths frozen at the step112prevents any new I/O operations being performed using those paths. In some embodiments, new I/Os may be queued without being processed. Note, however, that any I/O operations initiated prior to freezing the paths are either completed or, in some embodiments, aborted. Following the step112is a step114where metadata (including state information) for the device is exported. In an embodiment herein, the metadata may be exported into a platform-independent format. In some cases, other transformations may be performed. Note that the metadata may be provided on a per volume basis.

Following the step114is a step115where the metadata is imported to the new storage device. As discussed elsewhere herein, the metadata may be exported in a platform-independent format which can be subsequently imported by (or on behalf of) a storage device. The platform-independent format may be converted to a format for a specific platform for the new storage device in connection with importing the metadata.

Following the step115is a step116where the paths to the new storage device (discussed above) are thawed to allow I/O operations therewith. Following the step116is a step118where the paths to the old storage device are dismantled. Dismantling the old paths at the step118is performed by an appropriate mechanism depending upon how the paths are implemented. Following the step118, processing is complete.

Note that, in some cases, the result of freezing the old paths at the step112may leave unprocessed I/Os in the paths prior to dismantling the paths at the step118. Of course, as discussed elsewhere herein, although freezing a path prohibits new I/Os from being provided, the path is still capable of processing I/Os that were already in process before the freeze operation (i.e., draining the path). However, it is possible for some I/Os not to drain prior to dismantling the path at the step118. In some cases, a host will realize that the outstanding I/O to those paths has not completed (timed out), in which case the host will re-issues the same I/Os through another path (i.e., one of the new paths).

Referring toFIG. 5, a volume entry130for a metadata table includes volume information131and a plurality of path entries132-134where each describes a specific path to or from the volume. In an embodiment herein, a metadata table for an application includes an entry for each of the volumes used by the application where each of the entries is like the volume entry130shown inFIG. 5. The volume information131includes volume specific metadata, such as the volume geometry, the world-wide name of the volume, etc. Of course, the particular volume metadata used for the volume information131is somewhat implementation dependent.

Each of the path entries132-134includes, an initiator port, a target port, a logical unit number (LUN), and a state descriptor. The initiator port may be the port that sends I/Os through the path while the target port receives I/Os through the path. The port identifiers may be global identifiers that distinguish particular ports from other ports. The LUNs, on the other hand, may be local to whatever entity is maintaining a copy of the table130. The state descriptor may indicate information about the path in the context of the volume metadata. In an embodiment herein, the path state information may include reservation information, for example corresponding to SCSI-2 or SCSI-3 reservations. In addition, the path state information may include key registrations and other information created by a host. In some cases, the path state information may indicate whether a path is blocked, frozen or unfrozen.

In an embodiment herein, the metadata table130may be transferred by first creating a data structure to contain the information in the table130, populating the structure with data from the table130, and then using the structure to create a new version of the table130at the new storage device. Note that the system described herein may be used in instances where data is being migrated to dissimilar types of storage devices, and the metadata table130may have a different structure at the new storage device than at the old storage device. The data structure used to store the metadata table may be platform independent. In some embodiments, other types of transformations may be provided. For example, the transformation may include adding a Unit Attention message to all the new paths, to notify the host that all the IOs that were queued in the old paths are lost and have to be retried.

Referring toFIG. 6, a flow chart140illustrates steps performed in connection with hibernating and then subsequently thawing a process using the system described herein. As with migration, it is desirable to be able to provide hibernation in a way that is transparent to an entity accessing the data and does not require suspension of the entities accessing the data. That is, one or more of the applications52-54on one or more of the hosts32-34operate continuously before and after hibernation. Note that the processing illustrated by the flow chart140may be performed by the process manager82of the storage device36and/or by other appropriate processes/devices, such as the process manager58possibly in concert with other processing devices.

Processing for the flow chart140begins at a step141where the paths to the storage device of the process are frozen. Making the paths frozen at the step141prevents any new I/O operations being performed using those paths. Note, however, that any I/O operations initiated prior to freezing the paths are completed. Following the step141is a step142where the VM corresponding to the process being hibernated is frozen (suspended). Following the step142is a step143where a snapshot is obtained of the current data, including the state of the data and any metadata corresponding to data volumes used by the virtual machine. In some embodiments, the metadata may be stored in a platform-independent format. Following the step143is a step144where the paths are thawed to allow I/O operations therewith.

After some time, it may be desirable to wake up from hibernation. Accordingly, following the step144is a step145where the paths for the VM are frozen. Note that, in some embodiments, the steps144,145may be optional. For example, if no other processes are using the data, then the step144,145may be omitted so that the paths remain frozen until the process is revived from hibernation. Following the step145is a step146where the snapshot (obtained at the step143) is restored, including any metadata corresponding to the snapshot. Following the step146is a step147where the VM is resumed. Following the step147is a step148where the paths are thawed. Following the step148, processing is complete.

Referring toFIG. 7, a diagram150illustrates an active host152and a passive host154accessing a storage device156. In the example ofFIG. 7, the active host152and the passive host154access the same data on the storage device156. The active host152performs work in the form of one or more applications that read and write data to the storage device156. The passive host154is maintained as a fallback in case the active host152fails. As described in more detail elsewhere herein, the system uses storage state information to determine when to make the passive host154active.

The diagram150also illustrates migrating data from the storage device156to another storage device158. Migrating the data includes migrating corresponding state information so that, after the migration, the active host152and the passive host154preserve the relationship that existed prior to the migration. A first path162is provided from the active host152to the storage device156while a second path164is provided from the passive host154to the storage device156. As a result of the migration, the path162is replaced by a new path166from the active host152to the new storage device158while the path164is replaced by a new path168from the passive host154to the new storage device158. As discussed elsewhere herein, it is important that the state of the paths be preserved.

Referring toFIG. 8, a flow chart200illustrates steps performed by the active host152in connection with maintaining its status. In an embodiment herein, the storage devices156,158maintain a table like that shown inFIG. 5and discussed above. The paths for the active host152are in a reserved state (allowing I/O operations between the active host152and the storage device156) while the paths for the passive host154are in a blocked state. In an example illustrated herein, a host can request that a reservation between the storage device and another host be broken. If the other host does not re-reserve the path, the host that breaks the reservation becomes the active host. This is illustrated in more detail below.

Processing for the flow chart200begins at a first step202where the active host waits for a predetermined amount of time. The amount can be any amount, such as three seconds. Following the step202is a step204where the active host152sends a reservation command to the storage device. Following the step204is a test step206where it is determined if the active host152has any pending I/O operations. If not, then control transfers back to the step202for another iteration. Otherwise, control transfers from the step206to a step208where the active host152sends the I/O to the storage device. Following the step208, control transfers back to the step202for another iteration.

Referring toFIG. 9, a flow chart220illustrates steps performed by the passive host154in connection with maintaining its status and possibly becoming active if conditions warrant. Processing begins at a first step222where the passive host154sends a reservation command to the storage device. Following the step222is a step224where the passive host154waits a predetermined amount of time. The amount of time may be any amount that is longer than the amount of time the active host152waits at the step202, discussed above. In an embodiment herein, the amount is ten seconds.

Following the step224is a step226where the passive host154attempts an I/O operation. Note that if the active host152is operational, then the active host152would have sent a reservation command while the passive host was waiting at the step224. On the other hand, if the active host152is not operational, then the reservation provided by the passive host at the step222would have been the most recent reservation command received by the storage device. Following the step226is a test step228where it is determined if the I/O attempted at the step226is successful. If not (the active host152is operational), then control transfers back to the step222for another iteration. Otherwise, control transfers from the step228to a step232where the passive host154changes its status to active. Following the step232, processing is complete.

As can be seen from the example ofFIGS. 7-9, discussed above, it is important to maintain state information when migrating data from one storage device to another. Otherwise, if state information is not maintained, then the passive host154may incorrectly change its status to active or may incorrectly maintain its status as passive when it should be active. The state of the new path to the new storage device should be the same as the state of the old path when the migration occurred.

The system described herein may be used for migrating executable images between hosts as well as migrating data on storage devices. The system may also be used to hibernate and then reactivate processes/applications on hosts. A process such as a virtual machine, an application or an entire physical server, may wish to stop execution and resume it later from the exact same point, without the need for a restart (reboot). The server can freeze its resources (such as memory, registers, application state, swap files, etc.) and can freeze the SCSI state of the data. Later, the process manager can instruct the server (or a different server) to import the state and restart the data devices from exactly the same point as when hibernation was initiated. This enables the process to resume from hibernation with the same state in the server (memory, registers, etc.), the application (swap files, etc.) and storage (data, SCSI state). In turn, this means that the process can resume and start running immediately, without the need to wait for a restart.

The system may also be used to facilitate remote access. In this case, a storage array may import the SCSI state of a logical unit in order to present a cloned path to a host. This path may have all the attributes and state of the source path. The storage array presenting the new path does not have to have storage for the logical unit. Instead, the logical unit can forward any I/O requests to a path that is connected to the storage.

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. Thus, for example, one or more storage devices having components as described herein may, alone or in combination with other devices, provide an appropriate platform that executes any of the steps described herein. The system described herein includes computer software, in a non-transitory computer readable medium, that executes any of the steps described herein.

While the invention has been disclosed in connection with various embodiments, modifications thereon will be readily apparent to those skilled in the art. Accordingly, the spirit and scope of the invention is set forth in the following claims.