Computer system and method for migrating from one storage system to another

The present invention provides a method for migrating from a source storage system to a target storage system. The method comprises the steps of: defining a volume defined on a drive to be migrated in the source storage system as an external volume of the target storage system; causing the host to access the volume on the drive to be migrated through an input/output port of the drive to be migrated as the external volume of the target storage system; blocking the other input/output port of the drive to be migrated while maintaining the access to the external volume of the target storage system; reconnecting the blocked input/output port with an interface in the target storage system; blocking the input/output port through which the external volume is being accessed, and connecting it with the interface in the target storage system; and implementing the drive to be migrated in the target storage system.

CLAIMS OF PRIORITY

The present application claims prority from Japanese application serial no. 2004-208752, filed on Jul. 15, 2004, the content of which is hereby incorporated by reference into this application.

BACKGROUND

The present invention relates to a method for migrating from one storage system to another, and more particularly to a method for smoothly migrating data from one storage system to another without shutting down these systems.

Data migration techniques for moving data stored in one storage system to another storage system are important in running a computer system to which storage systems are connected. For example, when a new storage system is introduced, the data in the old storage system may need to be moved to the new storage system.

Further, data may be moved from a storage system under high load conditions to that under low load conditions while using these storage systems. Data migration may be carried out not only between storage systems but also between storage devices in a storage system.

U.S. Pat. No. 6,108,748 discloses a technique of migrating data from one storage system to another transparently to the host while maintaining access by the host. This technique connects the new storage system to which data is to be migrated between the host computer and the old storage system from which the data is to be migrated. The data to be migrated is moved from the old storage system to the new storage system while the new storage system is receiving read/write requests for the data from the host computer. When the new storage system has received a read/write request for data to be migrated which has not yet been migrated, the new storage system first issues a read request to the old storage system to migrate that data and then processes the read/write request after the data migration.

SUMMARY

When a new storage system is introduced, it may be desirable to continue to use some or all of the old storage system so as to effectively utilize all existing assets.

Further, as the capacity of storage systems has increased, the time it takes to migrate data stored in them has tended to increase.

However, the above conventional technique does not consider how to utilize the old storage system after data migration. Therefore, the old storage system may need to be abandoned or used for a different purpose, for example.

Further, even though the above conventional technique allows the system to be run without interruption while migrating data, the system load increases during the data migration since the data to be migrated is actually transferred from the old storage system to the new storage system, resulting in reduced system performance.

The present invention has been devised to solve the above problem. It is, therefore, an object of the present invention to migrate data from a source storage system (or an old storage system) to a target storage system (or a new storage system) on a drive basis while receiving read/write requests for the data from the host computer and continuously using some of the source storage system without directly transferring the data from the source storage system to the target storage system.

The present invention provides a method for migrating from one storage system (a source storage system) to another storage system (a target storage system) in a computer system in which a host computer, the source storage system, and the target storage system are connected to one another through a network. The host computer has running thereon a management program for switching between volumes of the source and target storage systems to selectively access one of the volumes. The source and target storage systems each include: a storage apparatus made up of a disk drive(s); a storage control apparatus; a storage interface unit for connecting between the storage apparatus and the storage control apparatus; and a host interface unit for connecting between the host computer and the storage control apparatus. Each storage apparatus has a plurality of input/output ports which are connected with the input/output ports of a respective storage interface unit, forming an interface pair.

The method comprises the steps of: causing the management program on the host computer to switch from a logical volume of the source storage system to a logical volume of the target storage system to access the logical volume of the target storage system; defining a logical volume defined on the storage apparatus (hereinafter referred to as “the storage apparatus to be migrated”) in the source storage system as an external volume of the target storage system, and causing the host computer to access the logical volume on the storage apparatus to be migrated through the network as the external volume of the target storage system; connecting an input/output port of the storage interface unit in the target storage system with an input/output port of the storage apparatus to be migrated; transmitting information on the disk drive and the logical volume of the storage apparatus to be migrated to the target storage system through the network; defining the logical volume on the storage apparatus to be migrated as a logical volume of the target storage system; causing the host computer to access the disk drive of the storage apparatus to be migrated through the connected input/output ports as the logical volume of the target storage system; and blocking an input/output port of the storage apparatus to be migrated, the input/output port being currently connected to an input/output port of the storage interface unit in the source storage system.

Thus, the present invention migrates a storage apparatus in the source storage system to the target storage system by causing the host computer to access the storage apparatus to be migrated as a storage apparatus of the target storage system.

The above disclosed arrangement allows the present invention to provide a method for migrating data from a source storage system to a target storage system on a drive basis while receiving read/write requests for the data from the host computer and continuously using some of the source storage system without directly transferring the data from the source storage system to the target storage system.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

First Embodiment

A description will be given of the configuration of a computer system including storage systems according to the first embodiment of the present invention with reference toFIG. 1.

FIG. 1is a diagram showing the configuration of the computer system including storage systems according to the first embodiment.

The computer system of the first embodiment is configured such that storage systems2are connected to a host computer1through a network apparatus3.

Specifically, a source storage system2afrom which data is to be migrated and a target storage system2bto which the data is to be migrated are connected to the host computer1through the network apparatus3during data migration operation, as shown inFIG. 1.

Further, the source storage system2a, the target storage system2b, the host computer1, and the network apparatus3are all connected to a management terminal4.

An application program50and a virtual management program51are loaded into and executed by the host computer1. The virtual management program51has a function to, when the application program50has issued a read/write request for a volume, switch it with another volume transparently to the application program50in order to support data migration from the source storage system2ato the target storage system2b.

A description will be given below of the internal configuration of the storage systems according to the first embodiment of the present invention with reference toFIG. 2.

FIG. 2is a diagram showing the internal configuration of the storage systems according to the first embodiment of the present invention.

Each storage system2(the source storage system2aand the target storage system2b) comprises a drive enclosure20, an interface enclosure21, a controller enclosure22, and a maintenance terminal23.

The drive enclosure20contains one or a plurality of disk drives201, which are storage apparatuses. It should be noted that the first and second embodiments of the present invention will be described as applied to storage apparatuses made up of magnetic disk drives. However, the first and second embodiments may be applied to storage apparatuses made up of other types of recording disks such as optical disks, or other recording media such as flash memory and semiconductor disks.

Each drive201has a plurality of input/output ports. Further, each storage system2may include a plurality of drive enclosures20.

The controller enclosure22contains a CPU package220, a memory package221, and a plurality of switches222collectively constituting a storage control unit. It should be noted that the controller enclosure22may contain a plurality of CPU packages220and a plurality of memory packages221.

The CPU package220has therein a CPU, local memory, and a data transfer control unit.

A read program52, a write program53, a data migration program54, a format translation program55, etc. are loaded into the local memory and executed.

Further, the memory package221has therein cache memory223and a data transfer control unit.

The cache memory223relays data between the host computer1and each drive201so as to enhance performance.

The switches222are connected to host interfaces210, drive interfaces211, and the CPU and the memory packages220and221, and relay data to them. Further, each switch222has an expansion port224for connecting with a switch222in another controller enclosure22for data exchange, enabling a plurality of controller enclosures22to operate as a single storage control apparatus.

The interface enclosure21contains: the host interfaces210for controlling the data transfer between the host computer1and the cache memory223; and the drive interfaces211for controlling the data transfer between the cache memory223and each drive201.

The host interfaces210receive read/write requests, etc. from the host computer1, as well as issuing read/write requests to another storage system2. A pair of drive interfaces211is connected to the input/output ports of each drive201in the drive enclosure20.

Each host interface210and each drive interface211has therein input/output ports, local memory, and a data transfer control unit.

It should be noted that the storage systems2may include a plurality of interface enclosures21. Further, the host interfaces210and the drive interfaces211may be set in different enclosures.

The maintenance terminal23is used to change the configuration of the storage system2or check its internal state. Furthermore, it relays instructions from the management terminal4to the storage system2. The maintenance terminal23may be connected to the CPU package220.

A description will be given below of data structures used by the storage systems according to the present invention with reference toFIGS. 3 and 4.

FIG. 3is a diagram showing configuration management information60on each component constituting a storage system2.FIG. 4Ais a diagram showing logical volume management information.FIG. 4Bis a diagram showing drive group management information.FIG. 4Cis a diagram showing external volume management information.

The configuration management information60indicates the states of components such as drive enclosures20, drives201in each drive enclosure20, interface enclosures21, host interfaces210and drive interfaces211in each interface enclosure21, controller enclosures22, the CPU package220, memory package221, and switches222in each controller enclosure22. Specifically, the configuration management information60indicates whether each component is “implemented”, “unimplemented”, or “preliminarily implemented” which means that the component is prepared for migration. Further, configuration information on each drive201includes information for uniquely identifying the drive, for example, information which can be obtained using the SCSI (Small Computer System Interface) Inquiry command, such as a vendor name and a serial number.

Volumes in the storage systems2are managed in a hierarchical manner, and this information is stored in the cache memory223.

The logical volume management information61includes, for each logical volume, a logical volume number, a logical volume capacity, a logical volume state, a host definition information list, a drive group number, and an external volume number, as shown inFIG. 4A.

It should be noted that a logical volume is a unit of storage area which a storage system2provides to the host computer1and other storage systems2.

The logical volume number identifies the logical volume. The logical volume capacity is the capacity of the logical volume. The logical volume state is set to “normal”, “blocked”, or “not in use”. The host definition information list includes information that allows the logical volume side to identify the host computer1which issues read/write requests for the logical volume, such as the name of the host computer1and port identifying information. The host definition information list also includes information that allows the host computer1side to identify the logical volume for which the host computer1issues read/writes requests, such as port identifying information on the storage system2and the LUN. The drive group number identifies each drive201in the storage system corresponding to the storage area (the logical volume). The external volume number identifies a volume which is implemented in another storage system2and corresponds to this logical volume.

When both the drive group number and the external volume number have been set, the logical volume can be accessed as not only a drive of this storage system2but also a volume of the another storage system2if the drive group and the external volume are both in a normal state.

The drive group management information62includes, for each drive group, a drive group number, a drive group capacity, a drive group state, a logical volume number, drive group attribute information, and a drive information list, as shown inFIG. 4B.

A drive group is a group of drives201(or a collection of the areas of these drives) and is used when distributing or storing data stored in a logical volume into a plurality of drives—by means of, for example, a RAID (Redundant Array of Independent Disks) technique.

The drive group number identifies the drive group. The drive group capacity is the capacity of the drive group. The drive group state is set to “normal”, “blocked”, or “not in use”. The drive group attribute information includes the corresponding logical volume number and RAID configuration information (the RAID level, the number of data drives, the number of parity drives, the stripe size, etc.) The drive information list includes information on the area of each drive201in the drive group, such as the drive number and capacity of the drive201and the start address of its area.

The external volume management information includes, for each external volume, an external volume number, an external volume capacity, an external volume state, a logical volume number, external volume attribute information, and an external volume access path list, as shown inFIG. 4C.

It should be noted that an external volume is actually a volume created in another storage system but can be used by this storage system using an external volume number.

The external volume number identifies the external volume. The external volume capacity is the capacity of the external volume. The external volume state is set to “normal”, “blocked”, or “not in use”. The logical volume number is the number of the logical volume corresponding to the external volume. The external volume attribute information includes information for uniquely identifying the external volume, such as the serial number of the another storage system and a volume number in the another storage system. The external volume access path list includes information used to access the external volume, such as port identifying information on this storage system and the another storage system and LUNs.

A description will be given below of a first method for migrating data from one storage system (a source storage system) to another storage system (a target storage system) according to the first embodiment of the present invention with reference toFIGS. 5 to 7.

FIG. 5is a flowchart of a first process of the first method for migrating data from a source storage system2ato a target storage system2b, wherein a drive enclosure20containing a drive201to be migrated is migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20.

FIGS. 6A and 6Bare flowcharts of a second process of the first method for migrating data from the source storage system2ato the target storage system2b, wherein the drive enclosure20containing the drive201to be migrated is migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20.

FIGS. 7A and 7Bare schematic diagrams of the first method for migrating data from the source storage system2ato the target storage system2b, wherein the drive enclosure20containing the drive201to be migrated is migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20.

In the first process of the first method in which the drive enclosure20containing the drive201to be migrated is migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20, first a logical volume defined on the drive201to be migrated in the source storage system2ais defined as an external volume of the target storage system2b, as shown inFIG. 5. Then, access by the host computer1to the logical volume on the drive201to be migrated in the source storage system2ais replaced by access to the external volume of the target storage system2b; that is, the host computer1accesses the logical volume on the drive201to be migrated as the external volume of the target storage system2b, as shown in FIG.7A(a).

Each step inFIG. 5is executed from the management terminal4, and the source storage system2aand the target storage system2beach have a data migration program54running thereon.

First, the target storage system2bis connected to the network apparatus3in step501.

Then, in step502, a setting is made in the source storage system2aso as to allow the target storage system2bto access the source storage system2a. It should be noted that when access by the target storage system2bto the source storage system2ais restricted by the network apparatus3, the setting of the network apparatus3also need to be changed.

Then, the logical volume on the drive to be migrated in the source storage system2ais defined as an external volume of the target storage system2bin step503.

Specifically, the management terminal4sends port identifying information on the source storage system2a, the LUN, etc. (which are used by the host computer1to access the source storage system2a) to the target storage system2bas information on the logical volume of the drive to be migrated. The target storage system2breserves a space for holding new external volume management information63and registers the information received from the management terminal4with the external volume access path list. Furthermore, the target storage system2bissues a request for information for identifying the volume to the LUN of the port of the source storage system2aaccessed by the host computer1, and registers the obtained information as external volume attribute information. The target storage system2balso makes an inquiry to the source storage system2aabout the capacity of the volume and registers it as an external volume capacity. Then, the target storage system2bsets the external volume state to “blocked”.

Then, in the target storage system2b, an empty logical volume is assigned to the logical volume on the drive to be migrated (which has been defined as the external volume), and a path from the host computer1is defined so as to allow the host computer1to access the volume, in step504.

Specifically, Step504reserves a space for holding new logical volume management information61, sets the logical volume capacity and the external volume number, and stores information for identifying the host computer1, port identifying information for accessing the logical volume, the LUN, etc. with the host definition information list in order to allow the host computer1to access the logical volume of the target storage system2b(the host computer1currently accesses the logical volume on the drive to be migrated in the source storage system2a). Furthermore, the states of the logical volume of the target storage system2band the external volume to which the logical volume is assigned are set to “normal”.

Then, the virtual management program51switches the volume to be accessed by the host computer1from the logical volume on the drive to be migrated in the source storage system2ato the newly assigned logical volume of the target storage system2bin step505.

The virtual management program51switches these volumes transparently to the application program50. When the application program50has issued a request using the path at the time of switching the volumes, the request is processed according to the function of the virtual management program51and the conditions under which the input/output command from the application program50has been executed, as follows:

(1) Each request currently being processed is handled by the source storage system2a, and a newly received request which has not yet been processed is transferred to the target storage system2b.

(2) Each request currently being processed is handled by the source storage system2a, and a newly received request which has not yet been processed is held within the virtual management program51. Then, after all previous requests have been processed, the virtual management program51switches the volumes to be accessed and transfers the held new request to the target storage system2b.

(3) The virtual management program51terminates all requests with an error and then switches the paths so that the retried requests will be issued to the path to the target storage system2b.

Lastly, Step506invalidates the path definition from the host computer1to the logical volume on the drive201to be migrated in the source storage system2aand further invalidates the path definition to the other volumes (which are not targeted for data migration) on the drive(s)201to be migrated, and then processing ends.

In the second process of the first method in which the drive enclosure20containing the drive201to be migrated is migrated from the source storage system2ato the target storage system together with all the drives201in the drive enclosure, the drives201in the drive enclosure20are disconnected from input/output ports of the drive interface in the source storage system2aand then connected to input/output ports of the drive interface in the target storage system2bone after another. Then, after the above step, the drive enclosure20is reimplemented in the target storage system2b.

The present embodiment assumes that each drive in the drive enclosures and each drive interface has a plurality of input/output ports. The reason that each drive in the drive enclosures and each drive interface has a plurality of input/output ports is to employ a multiplexed path so as to enhance reliability.

Each step inFIGS. 6A and 6Bis executed from the management terminal4, and the source storage system2aand the target storage system2beach have a data migration program54running thereon.

First, the drive enclosure20containing the drive201to be migrated is preliminarily implemented in the target storage system2bin step601, as shown in FIGS.6A and7A(b). Specifically, step601reserves a space for holding new drive enclosure configuration information and sets the value “preliminarily implemented”. It should be noted that when a plurality of drive enclosures20are connected to the input/output ports of the drive interface211through which the drive to be migrated is accessed, the above preliminary implementation operation is performed on each of the plurality of drive enclosures20in order to migrate these drive enclosures20to the target storage system2bat the same time.

Then, in step602, dirty data in the cache memory223is destaged to a volume(s) defined on each drive201in the drive enclosure20to be migrated. It should be noted that dirty data is data in a cache memory which has not yet been saved, or written back, to the drive side; that is, the data has not yet been reflected in the drive side. After the above destaging process, the source storage system2ais instructed to switch to “cache-through” operation (in which a data change is always reflected in both the cache memory and a target drive).

The above step is performed to ensure the consistency of the data on the drive to be migrated in steps608and609after read/write requests from the host computer1are processed.

Then, in the source storage system2a, one of the input/outputs port of the drive interface211connected to the drive enclosure20to be migrated is blocked and thereby deimplemented in step603, as shown in FIG.7A(c).

The volume on the drive to be migrated can still be accessed through the other input/output port of the drive interface211which has not been blocked.

Then, in step604, one of the input/output ports of the drive interface211of the target storage system2bis connected to the blocked input/output port of the drive enclosure20to be migrated, forming a path through which the drive enclosure20can be accessed from the drive interface211, as shown in FIG.7B(a). In the example shown inFIGS. 7A and 7B, the drive interface211in the target storage system2bis prepared beforehand.

Then, each drive201in the drive enclosure20to be migrated is preliminarily implemented in the target storage system2bin step605, as shown in FIG.7B(a). Specifically, step605reserves a space for holding new drive configuration information for each drive201to be preliminarily implemented, obtains information for identifying the drive201, such as its manufacturer and serial number, and stores the obtained information in a drive configuration information table. At this point, each drive201in the drive enclosure20to be migrated is fully implemented in the source storage system2aand preliminarily implemented in the target storage system2b.

Then, the source storage system2atransmits drive configuration information, logical volume management information61, and drive group management information62on each drive201in the drive enclosure20to be migrated to the management terminal4in step606, as shown in FIG.7B(a).

The management terminal4, in turn, transmits the received drive configuration information, logical volume management information61, and drive group management information62on each drive201to the target storage system2b.

Then, in step607, the target storage system2breceives the drive configuration information, logical volume management information61, and drive group management information62on each drive201sent from the management terminal4.

Then, in step608, the target storage system2bassociates each preliminarily implemented drive201with the drive configuration information transmitted from the source storage system2athrough the management terminal (identifies each preliminarily implemented drive201), reserves a space for holding new drive group management information62, and creates the new drive group management information62based on the drive group management information62obtained from the source storage system2a. Specifically, the target storage system2bdetermines the drive group capacity, the drive group attribute information, and each start address and capacity in the drive information list based on the drive group management information62obtained from the source storage system2a. Further, the target storage system2bsets the drive group state to “blocked”.

Further, in step609, the target storage system2bassociates the logical volume of the target storage system2bcorresponding to the logical volume on the drive to be migrated with the corresponding logical volume management information61obtained from the source storage system2a(identifies the logical volume of the target storage system2b) and newly sets the drive group number in the logical volume management information. The target storage system2bthen sets the drive group state in the drive group management information62to “normal”.

At this point, the source storage system2ahas already started cache-through operation on the volume defined on each drive201in the drive enclosure20to be migrated. Therefore, even though the logical volume on the drive to be migrated in the source storage system2ais redefined as both an external volume and a volume on a preliminarily implemented drive group on the target storage system2bside and read/write operations are performed according to these two definitions, the data on the drive to be migrated can be made consistent with the corresponding data in the cache memory in the target storage system2bby operating the data exclusively in the cache memory at the storage system2b, allowing the processing to be carried out without interruption.

Referring now toFIG. 6B, in step610, the target storage system2binvalidates the external volume definition of the logical volume defined on the drive201to be migrated (the external volume is associated with a logical volume of the target storage system2b), as shown in FIG.7B(b). Specifically, the target storage system2bdeletes the external volume number from the logical volume management information61and sets the (external volume) state in the external volume management information63corresponding to the external volume number to “not in use”.

Then, in step611, the source storage system2ablocks and thereby deimplements the logical volume defined on each drive201in the drive enclosure20to be migrated. At this point, the drive to be migrated is accessed based on the new drive group management information62set in the target storage system2b.

Then, in step612, the source storage system2ablocks and thereby deimplements the other one of the input/output ports of the drive interface211connected to the drive enclosure20to be migrated.

Then, in step613, the other input/output port of the drive interface211in the target storage system2bis connected to the other input/output port (the blocked input/output port) of the drive enclosure20to be migrated, forming a path through which the drive enclosure20can be accessed from the drive interface211, as shown in FIG.7B(c).

Then, each drive201in the drive enclosure20to be migrated is fully implemented in the target storage system2bin step614, as shown in FIG.7B(d).

Then, the drive enclosure20to be migrated is deimplemented from the source storage system2ain step615, as shown in FIG.7B(d).

Lastly, the drive enclosure20to be migrated is fully implemented in the target storage system2bin step616, as shown in FIG.7B(d), and processing ends.

A description will be given below of a second method for migrating data from one storage system (a source storage system) to another storage system (a target storage system) according to the first embodiment of the present invention with reference toFIGS. 8A and 8B.

FIGS. 8A and 8Bare schematic diagrams of the second method for migrating data from the source storage system2ato the target storage system2b, wherein the drive enclosure20containing a drive201to be migrated and a drive interface211connected to the drive enclosure20are migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20.

It should be noted that the first method connects the drive enclosure20to be migrated with the drive interface211prepared in the target storage system2bbeforehand. The second method, on the other hand, migrates not only the drive enclosure20to be migrated but also the drive interface211connected to the drive enclosure20to the target storage system2b; they are reimplemented and used in the target storage system2b.

It should be noted that the second method will be described below focusing on the differences from the first method and on important steps for migrating from the source storage system2ato the target storage system2b.

In this case, a pair of drive interfaces211(a drive interface pair) are connected to the drive enclosure20to be migrated, as in the configuration shown inFIG. 2. Further, each drive interface211is connected to two switches222, as shown inFIG. 8A.

As shown inFIG. 8A, the second method blocks an input/output port of one of the pair of drive interfaces211(the input/output port being currently connected to the drive enclosure20) in step603shown inFIG. 6A. The second method also disconnects the drive interface211from the switches222.

Then, the disconnected drive interface211is removed from the source storage system2aand implemented in the target storage system2b. After that, as shown in FIG.8B(b), an input/output port of the implemented drive interface211is reconnected to the blocked (unconnected) input/output port of the drive enclosure to be migrated, forming a path. Furthermore, the implemented drive interface211is connected to two switches222in the target storage system2b. Then, the second method performs steps similar to step605and later steps of the first method shown inFIG. 6A.

Thus, when the source storage system2aincludes a plurality of drive interfaces211, one of them may be removed from the source storage system2aand reused in the target storage system2b.

A description will be given below of a third method for migrating data from one storage system (a source storage system) to another storage system (a target storage system) according to the first embodiment of the present invention with reference toFIGS. 9 and 10Ato10C.

FIG. 9is a flowchart of the third method for migrating data from the source storage system2ato the target storage system2b, wherein the drive enclosure20containing the drive201to be migrated and the interface enclosure21connected to the drive enclosure20are migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20and all the drive interfaces in the interface enclosure21.

FIGS. 10A to 10Care schematic diagrams of the third method for migrating data from the source storage system2ato the target storage system2b, wherein the drive enclosure20containing the drive201to be migrated and the interface enclosure21connected to the drive enclosure20are migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20and all the drive interfaces in the interface enclosure21.

It should be noted that to migrate data from the source storage system2ato the target storage system2b, the second method migrates the drive enclosure20to be migrated and a drive interface211connected to the drive enclosure20to the target storage system2btogether with all the drives in the drive enclosure20. The third method, on the other hand, migrates the interface enclosure21containing the drive interface211connected to the drive enclosure20together with all the drive interfaces therein, instead of only the target drive interface211.

It should be further noted that the third method will be described below focusing on the differences from the first and second methods and on important steps for migrating from the source storage system2ato the target storage system2b.

As shown inFIG. 10A, the third method blocks an input/output port of one of the pair of drive interfaces211(the input/output port being currently connected to the drive enclosure20to be migrated) in step603shown inFIG. 6A. The third method also disconnects the drive interfaces211from the switches222. These steps are the same as the corresponding steps of the second method.

However, unlike the second method, the third method does not remove the disconnected drive interface211from the source storage system2a. Instead, the third method reconnects the blocked (disconnected) input/output port of the drive interface211to the blocked (disconnected) input/output port of the drive enclosure to be migrated and further connects the drive interface211to two switches222in the target storage system2b, forming a path, as shown inFIG. 10B.

Then, the interface enclosure21may be migrated to the target storage system2bafter migrating the drive enclosure and each drive therein.

Thus, when the interface enclosure21in the source storage system2aconnected to the drive enclosure to be migrated contains a plurality of drive interfaces211, some of them may be used to form a path through which each drive in the drive enclosure to be migrated can be accessed from the target storage system2b. Then, the interface enclosure21may be migrated to the target storage system2bafter migrating each drive.

Each step inFIGS. 10A to 10Cis executed from the management terminal4, and the source storage system2aand the target storage system2beach have a data migration program54running thereon.

First, the interface enclosure21to be migrated is preliminarily implemented in the target storage system2bin step701.

Step702determines whether all drive interfaces211in the interface enclosure21to be migrated have been migrated from the source storage system2ato the target storage system2b.

If no (the NO branch from step702), then a pair of drive interfaces211, the drive enclosure20connected the pair of drive interfaces211, and each drive201in the drive enclosure20are migrated from the source storage system2ato the target storage system2bin step703.

The processing in step703is almost the same as that shown inFIGS. 6A and 6Bwith the difference that in step703, the drive interface211deimplemented from the source storage system2ais used in the target storage system2b. Further, step703is different from the corresponding step of the second method in that step703connects the drive interface211to switches222in the target storage system2bwithout removing it from the interface enclosure21.

That is, in the source storage system2a, an input/output port of one of the pair of drive interfaces211is blocked (the input/output port being currently connected to the drive enclosure20to be migrated) and furthermore the drive interface211is also disconnected from the switches222, as shown inFIG. 10A. Then, the drive interface211deimplemented from the source storage system2ais connected to the drive enclosure to be migrated again and further connected to switches222in the target storage system2bwithout removing it from the interface enclosure21, as shown inFIG. 10B.

After that, the other drive interface211is disconnected from the drive enclosure to be migrated and switches in the source storage system2a, as shown inFIG. 10C.

It should be noted that the drive interface211deimplemented from the source storage system2amay be connected to the target storage system2busing the expansion ports of switches222in the controller enclosure22of the target storage system2b. Processing then proceeds to step704.

On the other hand, if all the drive interfaces211in the interface enclosure21to be migrated have been migrated from the source storage system2ato the target storage system2b(the YES branch from step702), then processing proceeds directly to step704.

Then, in the source storage system2a, the host interfaces210in the interface enclosure21to be migrated are blocked and thereby deimplemented in step704.

After that, the interface enclosure21to be migrated is deimplemented from the source storage system2ain step705.

Lastly, the interface enclosure21to be migrated is fully implemented in the target storage system2bin step706, and processing ends.

A description will be given below of a fourth method for migrating data from one storage system (a source storage system) to another storage system (a target storage system) according to the first embodiment of the present invention with reference toFIGS. 11 and 12Ato12C.

Specifically, the fourth method migrates data from the source storage system2ato the target storage system2bin such a way that the drive enclosure20containing the drive201to be migrated and the interface enclosure21and the switches222in the controller enclosure which are connected to the drive enclosure20are migrated from the source storage system2ato the target storage system2btogether with all the drive201in the drive enclosure20and all the drive interfaces in the interface enclosure21.

FIG. 11is a flowchart of the fourth method for migrating data from the source storage system2ato the target storage system2b, wherein the drive enclosure20containing the drive201to be migrated and the interface enclosure21and the switches222in the controller enclosure22which are connected to the drive enclosure20are migrated from the source storage system2ato the target storage system2btogether with all the drive201in the drive enclosure20and all the drive interfaces in the interface enclosure21.

FIGS. 12A to 12Care schematic diagrams of the fourth method for migrating data from the source storage system2ato the target storage system2b, wherein the drive enclosure20containing the drive201to be migrated and the interface enclosure21and the switches222in the controller enclosure22which are connected to the drive enclosure20are migrated from the source storage system2ato the target storage system2btogether with all the drives201in the drive enclosure20and all the drive interfaces in the interface enclosure21.

Each step inFIG. 11is executed from the management terminal4, and the source storage system2aand the target storage system2beach have a data migration program54running thereon.

First, the controller enclosure22to be migrated is preliminarily implemented in the target storage system2bin step801.

Then, in the source storage system2a, one of the pair of switches222in the controller enclosure22is blocked and thereby deimplemented in step802, as shown in FIG.12A(a). Since two switches are originally implemented in the controller enclosure22in each storage system2, the system can continue to operate even after one of them is blocked.

Then, the blocked switch222is implemented in the target storage system2bby connecting between the blocked switch222and a switch222of the target storage system2bthrough their expansion ports224in step803, as shown in FIG.12A(b).

Step804determines whether all interface enclosures21implemented for the controller enclosure22to be migrated have been migrated from the source storage system2ato the target storage system2b.

If no (the NO branch from step804), then a pair of drive interfaces211in each interface enclosure21, the drive enclosure20connected to the pair of drive interfaces211, and each drive201in the drive enclosure20are migrated from the source storage system2ato the target storage system2bin step805, as shown in FIG.12B(a).

The processing in step805is almost the same as that shown inFIGS. 6A and 6Bwith the difference that in step805, the drive interface211deimplemented from the source storage system2ais used in the target storage system2b, as in step703shown inFIGS. 8A and 8B.

It should be noted that the drive interface211deimplemented from the source storage system2amay be connected to the target storage system2busing the expansion ports224of switches222in the controller enclosure22of the source storage system2a. Processing then proceeds to step806.

On the other hand, if all interface enclosures21have been migrated from the source storage system2ato the target storage system2b(the YES branch from step804), then processing proceeds directly to step806.

Then, as shown in FIG.12B(b), all CPU packages220, all memory packages221, and the other one of the pair of switches222in the controller enclosure in the source storage system2aare blocked and thereby deimplemented in step806, causing the source storage system2ato cease to operate.

Then, the other one of the pair of switches222in the controller enclosure22to be migrated is implemented in the target storage system2bin step807, as shown in FIG.12C(a).

Lastly, the controller enclosure22to be migrated is fully implemented in the target storage system2bin step808, as shown in FIG.12C(a). Then, the drive to be migrated is connected to a drive interface211in the target storage system2b, and processing ends.

A description will be given below of the input/output operation of each storage system with reference toFIGS. 13 and 14.

Data stored in a storage system is read out by the read program52loaded into the local memory in its CPU package. The read program52is executed by the CPU in the CPU package220.

FIG. 13is a flowchart of the processing procedure performed by the read program52executed in the source storage system2aor the target storage system2b.

First, the read program52receives a read request from the host computer1or another storage system in step901and identifies the logical volume targeted for the read operation in step902.

Then, the read program52determines whether all read data is present in the cache memory223in step903.

If yes (the YES branch from step903), then processing proceeds directly to step911.

If no (the NO branch from step903), then in step904the read program52determines whether the cache memory223space allocated to the read data is too small to store all read data.

If the cache memory223space allocated to the read data is large enough (the NO branch from step904), then processing proceeds directly to step906.

If, on the other hand, the cache memory223space allocated to the read data is too small (the YES branch from step904), then in step905an additional memory space is allocated to the cache memory223to store all read data.

Then, in step906, the read program52determines whether the logical volume targeted for the read operation has been defined as an external volume which is currently in a normal state. That is, it is determined whether the logical volume management information61on the logical volume includes an external volume number and furthermore the external volume state in the external volume management information63including the same external volume number is set to “normal”.

If the logical volume targeted for the read operation has not been defined as an external volume which is currently in a normal state (the NO branch from step906), then the read program52identifies the corresponding drive201based on the drive information list in the drive group management information62(on the drive group) corresponding to the logical volume, and reads out the read data from it in step907. The read program52then stores the read data in the cache memory223in step908. Processing then proceeds to step911.

If the logical volume targeted for the read operation has been defined as an external volume which is currently in a normal state (the YES branch from step906), then the read program52transfers the read request to the external volume specified by the external volume management information63associated with the logical volume in step909. The read program52then receives the read data from the another storage system2for which the external volume has been defined, and stores the read data in the cache memory223in step910. Processing then proceeds to step911.

It should be noted that if the logical volume has been associated with both an external volume and a drive group which are currently in a normal state, the drive group may be accessed in preference to the external volume, which is not the case in steps906to911. Further, the load on each access route may be measured when the read request has been received and the access route under lower load conditions may be selected.

Then, the read data is transferred from the cache memory223to the requester for the read operation in step911. Lastly, the read program52sends a read request processing completion notification to the requester for the read operation in step912, and then processing ends.

On the other hand, the read request transferred in step909is received by the source storage system2afor which the external volume has been defined. The received read request is processed in the same manner as in the above steps shown inFIG. 13. However, in the source storage system2a, the drive group is selected to be accessed (the NO branch from step906), and the read data is read out from it in steps907and908.

Data is written to a storage system by the write program53loaded into the local memory in its CPU package. The write program53is executed by the CPU in the CPU package220.

FIG. 14is a flowchart of the processing procedure performed by the write program53executed in the source storage system2aor the target storage system2b.

First, the write program53receives a write request from the host computer1or another storage system2in step1001and identifies the logical volume targeted for the write operation in step1002.

Then, in step1003, the write program53determines whether the cache memory223space allocated to the read data is too small to store all write data.

If the cache memory223space allocated to the read data is large enough (the NO branch from step1003), then processing proceeds directly to step1005.

If, on the other hand, the cache memory223space allocated to the read data is too small (the YES branch from step1003), then in step1004an additional memory space is allocated to the cache memory223to store all write data.

Then, the requester for the write operation transfers the write data to the cache memory223in step1005.

Then, in step1006, the write program53determines whether a cache-through operation is performed on the logical volume targeted for the write operation.

If no (the NO branch from step1006), then the write program53issues a write request processing completion notification to the requester for the write operation in step1007.

If yes (the YES branch from step1006), then processing proceeds to step1008.

Then, in step1008, the write program53determines whether the logical volume targeted for the write operation has been defined as an external volume which is currently in a normal state. That is, it is determined whether the logical volume management information61on the logical volume includes an external volume number and furthermore the external volume state in the external volume management information63including the same external volume number is set to “normal”.

If the logical volume targeted for the write operation has not been defined as an external volume which is currently in a normal state (the NO branch from step1008), then the write program53identifies the corresponding drive201based on the drive information list in the drive group management information62(on the drive group) corresponding to the logical volume, and writes the write data to it in step1009. Processing then proceeds to step1011.

If, on the other hand, the logical volume targeted for the write operation has been defined as an external volume which is currently in a normal state (the YES branch from step1008), then in step1010the write program53writes the write data to the external volume specified by the external volume management information63associated with the logical volume. Processing then proceeds to step1011.

It should be noted that if the logical volume has been associated with both an external volume and a drive group which are currently in a normal state, the drive group may be accessed in preference to the external volume, which is not the case in steps1008to1010. Further, the load on each access route may be measured when the write request has been received, and the access route under lower load conditions may be selected.

Lastly, in step1011, the write program53determines whether a cache-through operation is performed on the logical volume targeted for the write operation in step1011.

If no (the NO branch from step1011), the write program53issues a write request processing completion notification to the requester for the write operation in step1012, and then processing ends.

If yes (the YES branch from step1011), then processing ends.

On the other hand (on the another storage system side, that is, the source storage system2aside), the write request transferred in step1010is received by the source storage system2afor which the external volume has been defined. The received write request is processed in the same manner as in the above steps shown inFIG. 14. However, in the source storage system2a, the drive group is selected to be accessed (the NO branch from step1008), and the write data is written to it in step1009. Further, the write request processing completion notification is issued to the target storage system2bin step1012.

A description will be given below of a method for converting redundant data exchanged between the source storage system2aand the target storage system2bin such a way that data can be verified and corrected using the redundant data even during a data migration process regardless of the progress of conversion of the redundant data.

FIG. 15is a flowchart of the processing performed by the format translation program55executed in the target storage system2b.

Redundant data is data added to each unit of data to be written to or read from a drive for data verification and correction purposes.

When the source storage system2aand the target storage system2bstore redundant data in different formats with real data, if the drive201storing data to be migrated has been migrated from the source storage system2ato the target storage system2b, the present embodiment converts the format of the redundant data while receiving read/write requests for the data from the host computer1.

The redundant data formats used by the source storage system2aand the target storage system2bmay be different from each other, for example, when they employ different methods of calculating redundant data, or redundant data includes logical volume information on the source storage system2a.

The target storage system2bincludes a format translation program55which translates a redundant data format into another redundant data format and supports the redundant data format of the source storage system2a. Further, the drive group attribute information in the drive group management information62on each drive group includes: a redundant data format attribute for identifying a redundant data format; a “redundant data format translation in progress” flag for indicating whether or not the redundant data format is currently being translated; and a redundant data format translation pointer for indicating the progress of translation of the redundant data format.

When, in step608shown inFIG. 6A, the target storage system2bcreates the new drive group management information62based on the drive group management information received from the source storage system2ain step607, if the redundant data format attribute of the source storage system2ais different from that of the target storage system2b, the target storage system2bperforms the following operations: setting the redundant data format attribute in the new drive group management information to that of the source storage system2a; setting the “redundant data format translation in progress” flag to “ON”; initializing the redundant data format translation pointer (setting the start address of the first drive in the drive information list); and activating the format translation program55. The format translation program55is executed by the CPU in the CPU package220.

First of all, the format translation program55determines whether there are any drive groups (management information62) whose “redundant data format translation in progress” flag is set to “ON”, in step1101.

If there are no drive groups whose “redundant data format translation in progress” flag is set to “ON” (the NO branch from step1101), then processing ends.

If there are such drive groups (the YES branch from step1101), the format translation program55(selects one of them and) determines whether the redundant data format of all drives listed in the drive information list (on the drive group) has been translated by comparing the redundant data format translation pointer and the drive information list in step1102.

If the data format of all drives has not yet been translated (the NO branch from step1102), in step1003the format translation program55reads out a certain amount of data from the location on a drive201indicated by the redundant data format translation pointer and stores it in the cache memory223after verifying its validity according to the redundant data format of the source storage system2a.

Then, the format translation program55generates redundant data in the redundant data format of the target storage system2bfrom the read data in step1104.

After that, the format translation program55writes the data and the generated redundant data from the cache memory223to the drive201in step1105.

Then, in step1106, the redundant data format translation pointer is updated by the amount of read data. If the redundant data format translation operation has reached the end of the (current) drive region (specified by the drive number, start address, and capacity of the drive indicated in the drive information list), then the format translation program55sets the redundant data format translation pointer at the start address of the next drive in the drive information list and proceeds to step1102.

If, on the other hand, the redundant data format of all the drives has been translated (the YES branch from step1102), in step1107the format translation program55updates the redundant data format attribute in the drive group attribute information from the redundant data format attribute of the source storage system2ato that of the target storage system2b. The data format translation program55then sets the “redundant data format translation in progress” flag of the current drive group to “OFF” in step1108and returns to step1101.

This completes the description of the redundant data format translation process. In writing or reading data, the redundant data is used as follows.

The read program52and the write program53perform the following operations in step907shown inFIG. 13and in step1009shown inFIG. 14, respectively. When the “redundant data format translation in progress” flag in the drive group management information62on the drive group targeted for the read/write operation is set to “ON”, these programs check the redundant data format translation pointer to see if the redundant data format translation has already been completed on the drive group targeted for the read/write operation. If so, they reads out the redundant data according to the redundant data format of the target storage system2b. If not, they reads out the redundant data according to the redundant data format of the source storage system2a. After that, these programs verify and correct the data using the redundant data.

Second Embodiment

A second embodiment of the present invention will be described below with reference toFIGS. 16 and 17.

First, a description will be given of the configuration of a computer system including storage systems according to the second embodiment of the present invention with reference toFIG. 16.

FIG. 16is a diagram showing the configuration of the computer system including storage systems according to the second embodiment of the present invention.

FIG. 17is a diagram showing the configuration of a virtual management network apparatus.

According to the first embodiment, the host computer1has the virtual management program51running thereon for switching between volumes to selectively access one of them.

According to the present embodiment, a virtual management network apparatus31corresponding to the network apparatus3of the first embodiment has a virtual management function to switch between a volume on the virtual management network31side or the host side and a volume on the storage system side.

The virtual management network apparatus31comprises a plurality of interfaces32, a control module33, control information memory34, and a switch35. The switch35connects all the other components together. These components may be connected by any connecting method such as a switch connection or bus connection. It should be noted that the control information memory34is duplicated to ensure availability.

The interfaces32are connected to the host computer1and the storage systems2. The memory of each interface32stores input/output management information for managing read/write requests, data, status information, etc., and transfer control information (inside and outside of the virtual management network apparatus) for identifying their transfer destinations, etc.

The control module33is used to change the configuration of the virtual management network apparatus31and monitor the internal conditions. It should be noted that the virtual management network31may be connected to the management terminal4, etc. and may operate according to instructions from the management terminal4or another external device.

The control memory34stores exclusion information, storage system volume information, “virtual volume to storage system volume” mapping information, “host side volume to virtual volume” mapping information, etc.

The exclusion information is used to update the data stored in the control memory34in an exclusive manner. The storage system volume information is information on volumes of the storage systems2detected by the virtual management network apparatus31. The storage system volume information includes information specific to the storage systems2, address information, volume numbers, etc.

The “virtual volume to storage system volume” mapping information lists each detected storage system volume and the corresponding virtual volume.

The “host side volume to virtual volume” mapping information is used to control how each virtual volume appears to the host computer1(that is, how the host computer1accesses each virtual volume).

The host computer1can access each virtual volume associated with it by the “host side volume to virtual volume” mapping information. To access a virtual volume, first the host computer1transmits an access request including host side volume identification information. Receiving this access request, the virtual management network apparatus31checks the “host side volume to virtual volume” mapping information to determine the virtual volume and then checks “virtual volume to storage system volume” mapping information to determine the storage system2and the volume number (of the storage system volume) based on the identification information included in the access request.

Then, the virtual management network apparatus31converts the access request received from the host computer1into an access request including the determined volume number (or identification information on the determined volume) and transmits it to the determined storage system2.

When it is necessary to switch volumes to be accessed by the host computer1, the virtual management network apparatus31rewrites the “virtual volume to storage system volume” mapping information according to a volume switch instruction from the management terminal4. That is, the virtual management network apparatus31changes the storage system volume associated with the virtual volume corresponding to the host side volume indicated by the virtual management network apparatus31to the host computer1when the virtual management network apparatus31causes the host computer1to access the logical volume on the drive to be migrated. Specifically, the virtual management network apparatus31switches from the logical volume on the drive to be migrated in the source storage system2ato the logical volume of the target storage system2bwhich has been defined as an external volume for the logical volume on the drive to be migrated. With this arrangement, the virtual management network apparatus31can cause the host computer1to access the logical volume on the drive to be migrated using the same host side volume identification information and the same virtual volume identification information even after switching from the source storage system2ato the target storage system2b. It should be noted that the rewriting of the “virtual volume to storage system volume” mapping information and the transmission of an access request based on the mapping information are carried out by programs in the memory of the virtual management network apparatus31which are executed by the CPU within the virtual management network apparatus31.

According to the present embodiment, step504inFIG. 5registers the logical volume of the target storage system2bwhich has been defined as an external volume for the logical volume on the drive to be migrated, as storage system volume information. Further, step505rewrites the “virtual volume to storage system volume” mapping information such that the storage system volume associated with the virtual volume (corresponding to the host side volume indicated by the virtual management network apparatus31to the host computer1when the virtual management network apparatus31causes the host computer1to access the logical volume on the drive to be migrated) is changed from the logical volume on the drive to be migrated in the source storage system2ato the logical volume of the target storage system2bwhich has been defined as an external volume for the logical volume on the drive to be migrated.