STORAGE SYSTEM AND MANAGEMENT METHOD

Abstract

To provide a storage system capable of reducing operational costs of a sub-site.SOLUTION: A management server previously stops a sub-server 600, and prepares a sub-storage 500 for operating according to a request from the sub-server 600 during such a migration that business processing using data stored in a main storage 200 is executed in the sub-server 600. The management sever makes the sub-storage 500 restore the data by using restoring data stored in an object storage 400 and store it, so as to drive the sub-server 600.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a storage system and a management method. [Background technology]

[0002] Some storage systems are provided with a function that enables business processing performed at a main site, such as an on-premise system constructed in a user's data centre, to be quickly resumed using a secondary site provided separately from the main site for the purpose of disaster recovery etc. For example, Patent Literature 1 discloses a storage system that resumes business processing at a secondary site using a cloud system when a failure occurs in the resources of the on-premise system. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2018-129074 A Summary of the Invention [Problem to be solved by the invention]

[0004] In recent years, it has become common to reduce the costs associated with building a secondary site by implementing the secondary site on a public cloud. However, when building a secondary site on a public cloud, the operating costs of the secondary site may be high because the servers and storage devices that constitute the secondary site are usually charged based on the server operating time and storage capacity.

[0005] An object of the present disclosure is to provide a storage system and a management method that can reduce the operational costs of a secondary site. [Means for solving the problem]

[0006] A storage system according to one embodiment of the present disclosure has a first storage device that stores data in response to a read / write request from a first host, a restoration storage device that stores restoration data for restoring the data, and a management device that causes a second host to execute business processing using the data, wherein the second host is stopped in advance, and when the management device causes the second host to execute the business processing, the management device prepares the second storage device based on control information that specifies a second storage device that operates in accordance with a request from the second host, restores and stores the data in the second storage device using the restoration data, and starts up the second host. Effect of the Invention

[0007] According to the present invention, it is possible to reduce the operating costs of a secondary site. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating a storage system according to a first embodiment of the present disclosure. [Diagram 2] FIG. 2 illustrates an example of the configuration of a primary storage. [Diagram 3] FIG. 2 illustrates an example of the configuration of a secondary storage. [Figure 4] FIG. 1 is a diagram for explaining an overview of a backup process. [Diagram 5] FIG. 11 is a diagram illustrating an example of a method for transferring backup data. [Figure 6] FIG. 13 is a diagram illustrating an example of information stored in a memory of a primary storage. [Figure 7] 11 is a flowchart illustrating an example of a backup process. [Figure 8] FIG. 2 is a diagram showing an example of a catalog and metadata. [Figure 9] FIG. 11 is a diagram for explaining an example of a failover process. [Figure 10] 11 is a diagram showing an example of information stored in a management server of a secondary storage; FIG. [Figure 11] FIG. 11 is a diagram illustrating an example of information stored in a storage server of a secondary storage. [Figure 12] 11A and 11B are diagrams illustrating an example of a pair relationship management table and a storage correspondence table. [Figure 13] 13 is a flowchart illustrating an example of a secondary environment construction process. [Figure 14] 13 is a flowchart illustrating an example of a secondary storage deploy process. [Figure 15] 13 is a flowchart illustrating an example of a protection target addition process. [Figure 16] FIG. 11 is a diagram for explaining an example of a failover process. [Figure 17] 11 is a flowchart illustrating an example of a data restoration process. [Figure 18] 13 is a flowchart illustrating an example of a failback process. [Figure 19] 13 is a flowchart illustrating another example of a failover process. [Figure 20] 11A and 11B are diagrams illustrating an example of a protection target management table and a server / volume correspondence table. [Figure 21] FIG. 13 is a diagram showing an example of a secondary storage management table. [Figure 22] 13 is a flowchart illustrating another example of the secondary environment construction process. [Figure 23] 13 is a flowchart illustrating another example of a failover process. [Figure 24] 13 is a flowchart illustrating an example of a deployment determination process. [Diagram 25] FIG. 13 illustrates another type of storage system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0010] In the following, the processing may be described with a "program" as the operating subject, but since the program is executed by the processor unit to perform a predetermined processing while appropriately using at least one of the memory unit and the interface unit, the subject of the processing may be the processor unit (or a computer or storage system having a processor unit). The program may be installed in the computer from a program source. The program source may be, for example, a program distribution server or a storage medium readable by the computer. In the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs. At least a part of the processing realized by executing the program may be realized by a hardware circuit (for example, an ASIC (Application Specific Integrated Circuit) or an FPGA (Field-Programmable Gate Array)). EXAMPLES

[0011] Fig. 1 is a diagram showing a storage system according to a first embodiment of the present disclosure. The storage system shown in Fig. 1 includes a data center (on-premise) 1 having a primary server 100 and a primary storage 200, and a cloud 2 having an object storage 400, a secondary storage 500 and a secondary server 600, and the data center 1 and the cloud 2 are connected to each other so as to be able to communicate with each other via a network 300. There may be a plurality of these configurations.

[0012] The data center 1 functions as a primary site (primary environment) that performs business processing under normal conditions. The cloud 2 stores backup data of data related to business processing of the data center 1, and functions as a secondary site (secondary environment) that takes over business processing of the primary server 100 under specific conditions such as disasters.

[0013] The primary server 100 is a first host that executes a computer program (hereinafter referred to as an application program) for performing business processing such as an application program and middleware. The primary storage 200 is a first storage device that stores data used and generated in business processing by the primary server 100, and stores data corresponding to an I / O request (read / write request) from the primary server 100.

[0014] The object storage 400 is a storage device that stores backup data of data stored in the primary storage 200. In this embodiment, the backup data is used as restoration data for restoring data at the secondary site, and the object storage 400 functions as a restoration storage device that stores the restoration data. The object storage 400 may be a storage device with a lower cost than the primary storage 200 and the secondary storage 500, and in this embodiment, it is an object storage device that stores data on an object-by-object basis, which is generally considered to be inexpensive. The secondary storage 500 is a second storage device that stores data used and generated in business processing by the secondary server 600. The secondary server 600 is a second host that executes an application program to perform business processing. In this embodiment, the restoration storage device is described using an object storage as an example, but it may be a storage other than an object storage as long as it is lower in cost than the secondary storage configured by the storage server 503 and the cloud storage 507 shown in FIG. 3. The restoration storage device may be a file storage or the like. The restoration storage device may be a storage service provided by a storage vendor on a public cloud.

[0015] The secondary server 600 and secondary storage 500 constitute a secondary site for taking over business processing by the primary server 100, for example, in the event of an incident such as a disaster that renders the primary server 100 unusable. However, the business processing by the secondary site may be processing other than the business processing by the primary server 100 (for example, data analysis processing, development business processing, or test business processing, etc.).

[0016] Fig. 2 is a diagram showing an example of the configuration of the primary storage 200 and a maintenance terminal 270 connected to the primary storage 200. As shown in Fig. 2, the primary storage 200 has one or more controllers 210 and one or more physical drives 220. In Fig. 2, two controllers 210 and four physical drives 220 are shown.

[0017] The controller 210 is a control unit that controls I / O requests from the primary server 100, controls reading and writing of data from and to the physical drive 220, and controls processing for transferring data to the cloud. The controller 210 has a FE (Front-End) I / F 211, a BE (Back-End) I / F 212, a management I / F 213, an RC (Remote Copy) I / F 214, a memory 215, and a processor 216.

[0018] The FEI / F 211 is an interface for connecting to the primary server 100 so as to be able to communicate with it, and in this embodiment has a plurality of Fibre Channel ports. However, the FEI / F 211 may include iSCSI ports instead of Fibre Channel ports.

[0019] The BEI / F 212 is an interface for communicatively connecting to the physical drive 220. The management I / F 213 is an interface for communicatively connecting to the maintenance terminal 270 via the management network 230. The RCI / F 214 is an interface for communicatively connecting to the object storage 400 of the cloud 2 via the network 300. The RCI / F 214 has, for example, a plurality of IP (Internet Protocol) ports. Note that the FEI / F 211 and the BEI / F 212 may share one I / F board.

[0020] The memory 215 records programs that define the operation of the processor 216, control information used by the programs, and the like. The memory 215 can also store data as a cache for data to be stored in the physical drive 220. The processor 216 executes various processes by executing the programs recorded in the memory 215.

[0021] The physical drives 220 are physical data storage devices that store data. A plurality of drives 220 may constitute one or more RAID (Redundant Array of Independent (or Inexpensive) Disks) groups. A primary volume 217 is configured across a plurality of physical drives 220 and provided to the primary server 100.

[0022] The maintenance terminal 270 is a terminal for performing maintenance and management of the primary storage 200, and has a maintenance port 271, an input / output unit 272, a memory 273, and a CPU 274. The maintenance port 271 is communicatively connected to the primary storage 200 via the management network 230. The input / output unit 272 has an input function for receiving various information from a user who uses the maintenance terminal 270, and an output function for outputting various information to the user. The memory 273 stores a maintenance program 275 that prescribes the operation of the CPU 274. The CPU 274 reads the maintenance program 275 recorded in the memory 273, and executes the maintenance program 275 that has been read, thereby executing various processes for maintaining and managing the primary storage 200.

[0023] 2 is merely an example and is not limited thereto. For example, the primary storage 200 may be a software defined storage (SDS) that realizes storage functions using a program that executes storage processing in each of a plurality of servers.

[0024] Fig. 3 is a diagram showing a configuration example of the secondary storage 500. The secondary storage 500 shown in Fig. 3 is constructed by SDS that operates on a public cloud. However, the secondary storage 500 may have hardware that performs specific processing. Examples of this type of hardware include hardware for compressing data and hardware for encrypting data.

[0025] 3, the secondary storage 500 is communicatively connected to a management server 501 via a management network 502. The secondary storage 500 also has multiple storage servers 503 and multiple cloud storages 507 that configure a capacity pool 508.

[0026] The storage server 503 is composed of a physical server, a virtual machine, a container, or the like. The storage server 503 also has a communication port 504, a memory 505, and a CPU 506. The communication port 504 is communicatively connected to the management server 501 via a network 502. The communication port 504 is communicatively connected to a cloud storage 507 and a secondary server 600.

[0027] The memory 505 records programs that define the operation of the CPU 506, and control information used by the programs. The CPU 506 is a processor that reads the programs recorded in the memory 505, executes the programs that have been read, and executes various processes. In this embodiment, the CPU 506 of each storage executes a program to realize the function of the storage. The CPU 506, for example, receives an I / O request from the secondary server 600, and writes and reads data to and from the cloud storage 507 in accordance with the I / O request.

[0028] Cloud storage 507 is a storage area of ​​storage server 503. A storage area may be created using a public cloud storage service and installed as cloud storage 507 in storage server 503. A secondary volume 509 may be configured across multiple cloud storages 507 and provided to secondary server 600. Data written to a volume may be made redundant between multiple cloud storages 507. The method of making the data redundant is not particularly limited, but may be, for example, a method using data duplication or a method using erasure coding.

[0029] The configuration of the secondary storage 500 shown in FIG. 3 is merely an example and is not limited thereto. For example, the secondary storage 500 may have the same configuration as the primary storage 200. Also, each storage server 503 may be installed across multiple areas (data centers, partitions that ensure availability, partitions that are logically divided for each purpose or user (tenants, etc.)) that can operate and be operated independently. Also, the secondary storage 500 and the secondary server 600 may be installed across multiple areas (data centers, partitions that ensure availability, partitions that are logically divided for each purpose or user (tenants, etc.)). Also, the secondary storage 500 and the secondary server 600 may be installed on different clouds, or may be on a cloud service provided by another vendor on a public cloud vendor.

[0030] The management server 501 is a management device for managing and maintaining the secondary storage 500. It also manages data copies from the primary storage 200, which will be described later, and performs failover processing and failback processing. The management server 501 may manage the primary storage, or may manage the primary server 100 and the secondary server 600. The management server 501 has a memory 501a and a CPU 501b. The memory 501a records a program that specifies the operation of the CPU 501b, and various information used by the program. The CPU 501b is a processor that reads the program recorded in the memory 501a, executes the read program, and executes various processes. The functions of the management server 501 may be realized by any of the storage servers 503.

[0031] In the storage system of this embodiment, in a steady state, business processing is performed in the data center 1, and backup processing is performed to store backup data related to the business processing in the cloud 2. Furthermore, in a specific state such as a disaster, the storage system performs failover processing to have the cloud 2 execute the business processing. After that, when the steady state is restored, the storage system performs failback processing to return the execution of the business processing to the data center 1.

[0032] First, the backup process will be described.

[0033] 4 is a diagram for explaining an overview of the backup process. The backup process is a process performed on the primary volume 217 to be protected in the primary storage 200, and is a process for storing backup data of data stored in the primary volume 217 to be protected in the object storage 400. The primary volume 217 to be protected is designated as the protection target by, for example, a user.

[0034] In the object storage 400, a bucket 401, which is a storage area used to protect the primary volume 217, is set. In the bucket 401, backup data transferred from the primary storage 200 is stored as an object 402. In the example of FIG. 4, one object 402 is configured for each backup data, and an object 402 that stores backup data transferred at 1:00 on December 16th (12 / 16 1:00) and an object 402 that stores backup data transferred at 1:00 on December 17th (12 / 17 1:00) are shown. However, when there is an upper limit on the object size, which is the data size that can be stored as one object 402, or when parallel processing is performed on the backup data, one backup data may be stored in multiple objects 402. The backup data may be divided into multiple objects 402 from the viewpoint of performance, etc., or the size may be determined based on the specifications of the object storage.

[0035] In addition, in FIG. 4, for each primary volume 217, an object group 403 consisting of objects 402 that store backup data of that primary volume 217 is shown, but the object group 403 is shown for convenience and is not managed as an actual entity in the storage system.

[0036] FIG. 5 is a diagram illustrating an example of a method for transferring backup data.

[0037] There are multiple types of transfer methods for transferring backup data to the object storage 400. For example, the transfer methods include incremental backup, differential backup, and remote copy. Incremental backup and differential backup are methods for periodically transferring backup data. Incremental backup is a method for transferring update data updated after the previous transfer of backup data as the next backup data, and differential backup is a method for transferring differential data from the initially transferred backup data as the backup data. Remote copy is a method for reflecting updates to the primary volume 217 in the object storage 400. In remote copy, there are a method for sequentially transferring data every time the data is written to the primary volume 217, and a method for periodically transferring the written data all at once. In addition, in the method for periodically transferring data, if the same address is updated multiple times, only the last updated data may be transferred. In this embodiment, the transfer method is incremental backup.

[0038] In incremental backup, a snapshot of the data stored in the primary storage 200 (more specifically, the data stored in the primary storage 200 that is stored in the primary volume 217 to be protected) is created periodically (once a day in the example of Figure 5) and transferred to the object storage 400.

[0039] For example, at the time of the first transfer on December 1st, the data stored in the primary storage 200 is transferred to and stored in the object storage 400 as objects 3000. Generally, the ratio of the number of primary volumes 217 to the number of objects 3000 is 1:N (an integer of 2 or more), but it may also be 1:1, etc.

[0040] At the time of the next transfer timing on December 2nd, the snapshot holds only the differential data generated between December 1st and December 2nd, and this snapshot is transferred to and stored in the object storage 400. Similarly, at the time of the further next transfer timing on December 3rd, the snapshot holds only the differential data generated between December 2nd and December 3rd, and this snapshot is transferred to and stored in the object storage 400.

[0041] The frequency at which snapshots are generated and the frequency at which snapshots are transferred to the object storage 400 may be different from each other. For example, a snapshot that has not been referenced for a certain period of time in the primary storage 200 may be transferred to the object storage 400. Transfer of data identical to data stored in the object storage 400 may be avoided. In this case, instead of transferring data, management information indicating the identical data may be transferred. In this case, it is possible to reduce the amount of data transferred and the amount of data stored in the object storage 400.

[0042] Fig. 6 is a diagram showing an example of information stored in the memory 215 of the primary storage 200. As shown in Fig. 6, the memory 215 stores control information 221 and a program 222 as information related to backup processing. The memory 215 also has a cache unit 223 that temporarily stores data.

[0043] The control information 221 has a transfer destination management table 2210, a primary volume table 2211, and a generation management table 2212. The transfer destination management table 2210 is information for managing the transfer destination of backup data, and indicates the object storage 400 and bucket of the transfer destination. The primary volume table 2211 is information for managing the primary volume 217 to be protected and the bucket in which the data of the primary volume is stored. The generation management table 2212 is information for managing the primary volume 217 and the generation number of the snapshot in the primary volume 217. The generation number is a number indicating the creation order of the snapshot for the primary volume 217. Note that the generation number is not limited to a table, and may be managed in another format such as a bitmap.

[0044] The program 222 includes a difference extraction program 2221 and a data transfer program 2222. The difference extraction program 2221 is a program for creating a snapshot, and the data transfer program 2222 is a program for transferring the snapshot created by the difference extraction program 2221 to the object storage 400.

[0045] FIG. 7 is a flowchart illustrating an example of the backup process.

[0046] In the backup process, when it is time to obtain a snapshot, the differential extraction program 2221 obtains a snapshot of the primary volume 217 as the current snapshot for each primary volume 217 to be protected (Step S100).

[0047] The difference extraction program 2221 determines the generation number of the current snapshot acquired in step S100 (step S101). For example, if the generation number is a consecutive number, the difference extraction program 2221 determines the current generation number by incrementing the previous generation number.

[0048] The difference extraction program 2221 extracts the difference between the previous snapshot and the current snapshot (step S102). The extraction of the difference can be realized, for example, by holding the write address of the data written to the primary volume 217 after the snapshot was acquired, or by comparing the snapshot metadata of the previous snapshot and the current snapshot. The snapshot metadata is information indicating the address where the snapshot data is physically stored. If it is the same as the data of the protected volume, the capacity consumption by the snapshot can be reduced by storing the address indicating the physical location where the data of the protected volume is stored.

[0049] The difference extraction program 2221 refers to the transfer destination management table 2210, identifies the cloud 2 and bucket to which the backup data, which is the difference between the snapshot, is to be transferred, and further determines the format, which is the data transfer method (step S103). For example, the difference extraction program 2221 determines, as the format, which data should be grouped together into one object according to the upper limit value of the object size.

[0050] The differential extraction program 2221 creates a catalog, which is management information for managing the backup process, and metadata for managing the backup data (Step S104). A more detailed explanation of the catalog and metadata will be given later with reference to FIG.

[0051] Thereafter, the data transfer program 2222 transfers the backup data as an object to the object storage 400 of the cloud 2 in accordance with the format determined in step S103 (step S105). At this time, the data transfer program 2222 may appropriately perform processing related to the transfer of the backup data, such as a process of adding a header to the object.

[0052] The data transfer program 2222 transfers the catalog and metadata created in step S104 (step S106). For example, the data transfer program 2222 may transfer the catalog and metadata as objects to the object storage 400, or may transfer them to another storage means such as a database on the cloud 2. The information may be stored in the object key of the object. For example, if the number of the volume to be protected is used as the object key name, there is no need to store the volume number to be protected in the object.

[0053] Then, the differential extraction program 2221 deletes the previous snapshot in the primary storage 200 (step S107) and ends the process. Note that the current snapshot is not deleted because it will be used in step S101 of the next backup process.

[0054] It is not necessary to delete all previous snapshots. If snapshots are left in the primary storage 200, the capacity consumed in the primary storage 200 increases, but the time required to restore data can be reduced. For example, when restoring a snapshot taken at 11:00 from the cloud 2, if the primary storage 200 has a snapshot at 9:00, the difference between 9:00 and 11:00 is acquired from the cloud 2. On the other hand, if the primary storage has a snapshot at 10:00, only the difference between 10:00 and 11:00 is acquired from the cloud 2, which reduces the amount of data transfer and reduces the time required for restoration. In addition, the process of transferring data in the primary storage 200 has been described using an example in which a program stored in the memory 215 executes the process. However, the RCI / F 214 may be the main body in transferring data stored in the primary volume to the cloud 2. In that case, the transfer destination management table 2210, the primary volume table 2211, the generation management table 2212, and the data transfer program 2222 are stored in the memory in the RC / F. Other divisions of roles are also possible, but the present invention is applicable regardless of these methods.

[0055] FIG. 8 is a diagram showing an example of the catalog and metadata.

[0056] The catalog 701 shown in FIG. 8 has a previous generation catalog access key 711 , a snapshot generation number 712 , a primary volume number 713 , a primary storage number 714 , a snapshot time 715 , a type 716 , and a head meta access key 717 .

[0057] The previous generation catalog access key 711 is key information for identifying the previous generation catalog 701B, which is the catalog related to the previous snapshot. The snapshot generation number is the generation number of the current snapshot. The primary volume number 713 is an identification number that identifies the primary volume 217 to be protected. The primary storage number 714 is an identification number that identifies the storage device having the primary volume 217 to be protected. The snapshot time 715 is the time when the current snapshot was acquired. The type 716 is the type of backup process, and indicates, for example, any one of "full backup", "incremental backup" and "differential backup".

[0058] The first meta access key 717 is key information for identifying the metadata 702 that manages the data to be transferred as backup data. Note that metadata 702 is created for each object, and the first meta access key 717 identifies one of the metadata 702. In addition, in the first backup process, all of the data stored in the primary volume 217 to be protected is transferred. At this time, the metadata 702 may not be necessary, in which case the value of the first meta access key is a null value (Null).

[0059] Incidentally, the catalog 701 is usually created for each primary volume 217, but it may also be one for managing a plurality of primary volumes 217 collectively.

[0060] The metadata 702 includes a data access key 721 , LBA (Logical Block Addressing) information 722 , and a metadata access key 723 .

[0061] The data access key 721 is key information for accessing data included in the object 703. The LBA information 722 indicates the address (LBA) on the primary volume of the data stored in the object 703. There is LBA information 722 for each data stored in the object 703. The metadata access key 723 is an access key for identifying the next metadata 702. Note that the value of the metadata access key 723 in the last metadata 702 is a null value.

[0062] Object 703 stores the data body. In the example of Fig. 8, m pieces of data are stored in one object 703. The size of each piece of data included in object 703 is fixed length. By providing data size information in metadata 702, object 703 can also store variable length data.

[0063] Next, the failover process will be described.

[0064] Since the secondary environment having the secondary storage 500 and the secondary server 600 is used when a disaster occurs, it is preferable from the viewpoint of cost to suppress the charge for the secondary environment in a steady state. In this embodiment, the secondary storage 500 constituting the secondary environment is composed of a storage server 503 and a cloud storage 507 as shown in FIG. 3. The storage server 503 which performs storage-related processing is constructed by a virtual machine of the cloud 2. And the cloud storage which provides the capacity is constructed by a storage service provided by the cloud 2. The secondary server 600 is constructed by a virtual machine of the cloud 2. Since the virtual machine is usually charged according to the time when the power is on (running), the power of the virtual machine is turned off. Also, since the cloud storage 507 is charged according to the capacity, the secondary storage 500 is set to an initial state in which the capacity (storage capacity) is a predetermined minimum value (minimum capacity). Incidentally, the secondary storage 500 is not used unless the failover process is executed and the secondary environment is in a state where business processing is performed, so there is no problem even if the secondary storage 500 capacity is the minimum value. The minimum value of the capacity is set, for example, by the vendor providing the cloud 2. The minimum capacity may be zero. Even if the charge is not applied to a virtual machine or cloud storage 507 but to the secondary storage 500, the charge can be minimized by turning off the power or minimizing the capacity.

[0065] FIG. 9 is a diagram for explaining the failover process.

[0066] 9, in state A which is a steady state, the power supply of the secondary server 600 and the power supply of the storage server 503 constituting the secondary storage 500 are turned off, and the capacity allocated to the cloud storage 507 constituting the secondary storage 500 is set to a minimum value. Also, in state A, as described using Figs. 4 to 8, a backup of the data stored in the primary storage 200 is appropriately saved in the object storage 400.

[0067] Furthermore, when an incident such as a disaster occurs, the secondary server 600 is powered on, the storage server 503 constituting the secondary storage 500 is powered on, and the capacity of the cloud storage 507 is added and registered in the capacity pool. This transitions the storage system to state B, which is a specific state in which business processing can be executed in the secondary environment.

[0068] Fig. 10 is a diagram showing an example of information stored in a memory 501a of the management server 501 of the secondary storage 500. As shown in Fig. 10, the memory 501a stores control information 5010 and a program 5020 as information related to the failover process and the failback process.

[0069] The control information 5010 is information for specifying the secondary storage 500 to which data is restored in order to execute business processing at the secondary site. Specifically, the control information 5010 has a pair relationship management table 5011, a storage correspondence table 5012, a protection target management table 5013, a server / volume correspondence table 5014, and a secondary storage management table 5015. The protection target management table 5013, the server / volume correspondence table 5014, and the secondary storage management table 5015 are used in the second embodiment.

[0070] The program 5020 includes a secondary environment construction program 5021, a storage deployment program 5022, a protection target addition program 5023, a failover program 5024, a storage expansion program 5025, a failback program 5026, and a secondary storage specification program 5027. The secondary storage specification program 5027 is used in the second embodiment.

[0071] Fig. 11 is a diagram showing an example of programs stored in memory 505 of a storage server 503 of the secondary storage 500. As shown in Fig. 11, the memory 505 has a data recovery program 5051 and a copy program 5052 as programs 5050 related to failover processing and failback processing.

[0072] FIG. 12 is a diagram showing an example of the pair relationship management table 5011 and the storage correspondence table 5012.

[0073] In FIG. 12, a pair relationship management table 5011 is information for managing the corresponding relationship between the primary volume 217 and the secondary volume 509, and includes fields 801 to 805.

[0074] Field 801 stores a primary storage number for identifying the primary storage 200 having the primary volume 217 to be protected. Field 802 stores a primary volume number for identifying the primary volume 217 to be protected. Field 803 stores a secondary storage number for identifying the secondary storage 500 as the restoration destination to which the primary volume 217 to be protected is restored. Field 804 stores a secondary volume number for identifying the secondary volume 509 as the restoration destination to which the primary volume 217 to be protected is restored. Field 805 stores an object bucket number for identifying a bucket in the object storage 400 that stores the data to be restored.

[0075] The example of FIG. 12 shows that data of primary volume "1" in primary storage "1-1" is restored to volume "1" of secondary storage "2-1". The data to be restored is stored in bucket "A" of object storage 400. Unlike conventional disaster recovery, in this disclosure, the recovery destination of primary volume "1" is volume "1" of secondary storage "2-1", but data of primary volume "1" is not copied to volume "1" of secondary storage "2-1", but is copied to bucket "A" of object storage 400.

[0076] The storage correspondence table 5012 is storage correspondence information for managing the correspondence between the primary storage 200 and the secondary storage 500 , and includes fields 811 and 812 .

[0077] Field 811 stores a primary storage number for identifying the primary storage 200 including the primary volume 217 to be protected. Field 812 stores secondary storage information regarding the secondary storage 500 corresponding to the primary storage 200 including the primary volume 217 to be protected. Specifically, field 812 includes fields 813 to 815. Field 813 stores the number of storage servers which is the number of storage servers 503 constituting the secondary storage 500, field 814 stores an instance type which is the type of the storage server 503, and field 815 stores the capacity of the storage server 503.

[0078] The operation record (number of I / Os, capacity, etc.) of the primary storage 200 may be notified to the cloud 2, and the scale of the required secondary storage may be calculated from the operation record. In this case, only the operation record may be stored in the pair relationship management table 5011, or not only the operation record but also the number of nodes, instance type, capacity, etc. may be stored. The operation record may be generated for each primary storage as described above, but may also be generated for each volume or failover group. A typical feature of a cloud is that it is possible to add required resources when necessary. For this reason, after a failover, resources may be added to the storage 500 depending on the load on the secondary storage 500. In that case, the storage correspondence table 5012 is not necessary.

[0079] 13 is a flowchart for explaining an example of a secondary environment construction process for constructing a secondary environment. The secondary environment construction process is a preparatory process for executing a failover process when an incident occurs, and is executed by the secondary environment construction program 5021.

[0080] It is assumed that the secondary environment construction program 5021 has received primary volume information (for example, primary storage number, primary volume number, and primary server number) relating to the primary volume 217 to be protected from the primary server 100 or the like.

[0081] First, the secondary environment construction program 5021 deploys the secondary server 600 based on the received primary volume information (step S200). Then, the secondary environment construction program 5021 creates a storage correspondence table 5012 (step S201). For example, the secondary environment construction program 5021 obtains the operation record (number of I / Os, capacity, etc.) of the primary storage and calculates the scale of the secondary storage 500 to create the storage correspondence table 5012. In this case, the storage correspondence table 5012 may store only the operation record as secondary storage information, or the operation record may be added.

[0082] Thereafter, the secondary environment construction program 5021 calls the storage deployment program 5022 to execute the secondary storage deployment process (see FIG. 14) for deploying the secondary storage 500 (step S202). At this time, the secondary environment construction program 5021 calls the storage deployment program 5022, specifying the capacity of the capacity pool as the minimum value.

[0083] Then, the secondary environment construction program 5021 creates a secondary volume 509 (step S203), and further creates a pair relationship management table 5011 (step S204). At this time, the secondary environment construction program 5021 deploys the required number of secondary storages 500 and secondary servers 600 based on the received primary volume information. Also, the secondary environment construction program 5021 creates the secondary volume 509 in the secondary storage 500 so that the relationship between the secondary storage 500 and the secondary volume 509 is similar to the relationship between the primary storage 200 and the primary volume 217.

[0084] The secondary environment construction program 5021 defines the relationship between the port and the volume as a path (step S205). The secondary environment construction program 5021 allocates the secondary volume 509 to the secondary storage 500 (step S206) so that the relationship is the same as that between the primary volume 217 and the primary server 100. The secondary environment construction program 5021 installs an application program in the secondary server 600 (step S207) and sets up a storage area for the application program (step S208).

[0085] Then, the secondary environment construction program 5021 turns off the power of the secondary server 600 (step S209), and further turns off the power of the secondary storage 500 (step S210), and ends the process.

[0086] Fig. 14 is a flowchart for explaining an example of the secondary storage deployment process in step S202 in Fig. 13. Deploying a secondary server may be achieved by copying the primary server to the secondary server. For example, this can be achieved by using a function or service that copies a virtual machine from on-premise to the cloud.

[0087] In the secondary storage deployment process, the storage deployment program 5022 prepares the cloud storage 507 (step S300). Then, the storage deployment program 5022 creates a virtual server for the storage server 503 (step S301). The storage deployment program 5022 allocates the cloud storage 507 to the virtual server (step S302). The storage deployment program 5022 adds the capacity of the cloud storage 507 to the storage capacity pool (step S303) and ends the process.

[0088] In the secondary storage deployment process, information such as the number of storage servers 503 required to configure the secondary storage 500, the instance type, and the capacity is updated. This information may be received from an administrator or the like. The capacity of the storage server 503 may be determined based on the capacity of the primary volume. Since the contents equivalent to the storage correspondence table 5012 can be received from outside, the storage correspondence table 5012 does not need to be saved.

[0089] 15 is a flow chart for explaining an example of a protection target addition process for adding a protection target primary volume 217. The protection target addition process is executed by the protection target addition program 5023.

[0090] The protection target addition program 5023 judges whether an existing secondary storage 500 is specified as the secondary volume 509 to restore the primary volume 217 to be added (step S400). If an existing secondary storage 500 is specified, the protection target addition program 5023 turns on the power of the existing secondary storage 500 (step S401). At this time, the protection target addition program 5023 may turn on the power of only a part of the secondary storage 500. For example, if the secondary storage 500 corresponding to the primary volume is fixed, only the power of that secondary storage server may be turned on. On the other hand, if an existing secondary storage 500 is not specified, the secondary storage deployment process of the above-mentioned step S202 is executed.

[0091] Thereafter, the processing of steps S203 to S210 explained using Fig. 13 is executed. However, between the processing of steps S205 and S206, the protection target addition program 5023 performs the following processing (step S402). That is, the protection target addition program 5023 turns on the power of the secondary server 600 when an already deployed secondary server 600 accesses the secondary volume (secondary volume 509 that restores the primary volume 217 to be added), and deploys the secondary server 600 when an undeployed secondary server 600 accesses the secondary volume.

[0092] 16 is a flowchart for explaining an example of failover processing. The failover processing is executed by the failover program 5024 and the storage expansion program 5025 of the management server 501. The failover processing is executed when an instruction to execute the processing is given from a higher level, such as a person or a fault detection program.

[0093] In the failover process, first, the failover program 5024 identifies the secondary storage 500 and secondary volume 509 that will be the failover destination of the primary volume 217 to be protected (step S500) based on the pair relationship management table 5011. Note that in cases where the primary volume 217 to be protected and the secondary volume 509 always correspond one-to-one, the process of step S500 may be omitted.

[0094] Next, the failover program 5024 turns on the power of the identified secondary storage 500 (step S501).

[0095] Thereafter, the storage expansion program 5025 executes processes equivalent to the processes of steps S300, S302, and S303 described using Fig. 11. However, in the process of step S303, since the capacity of the capacity pool is currently at the minimum value, the storage expansion program 5025 adds capacity to the capacity pool based on the storage correspondence table 5012. For example, the storage expansion program 5025 creates cloud storage 507 using a cloud service, and assigns the created cloud storage 507 to the powered-on storage server 503, thereby adding capacity to the capacity pool.

[0096] Thereafter, the failover program 5024 executes a data restoration process (see FIG. 17) for restoring the data stored in the bucket in the object storage 400 to the secondary volume (step S502). Then, the failover program 5024 turns on the power of the secondary server (step S503) and ends the process.

[0097] In the failover process, in addition to the processes described in each step of FIG. 14, other processes such as a process of starting an application program and a process of taking over an IP address may be performed as appropriate. In the example of FIG. 14, an example of the failover process of a disaster recovery system is described, but another business process using the data stored in the object 402 may be performed at the secondary site. The other business process is, for example, an analysis process for analyzing data, a development process for performing various developments using data, or a test process for performing various tests using data. In this case, each program that performs the failover process may be read as a program that starts another business process. This is the same for the second embodiment and the like.

[0098] Fig. 17 is a flowchart for explaining an example of the data restoration process of step S502 in Fig. 16. The data restoration process is executed by the data restoration program 5051. In this embodiment, data is stored in the object storage 400 by incremental backup.

[0099] In the data restoration process, the data restoration program 5051 identifies the secondary volume 509 from which data is to be restored (step S600). If there are multiple secondary volumes 509, the following process is carried out for each secondary volume 509.

[0100] The data restoration program 5051 acquires a catalog of data to be restored (step S601). The access key for accessing the catalog may be managed separately, or may be configured to be specified from the primary volume 217 to be restored. For example, the "primary volume number + generation number" corresponding to the primary volume to be restored may be managed as the access key.

[0101] The data restoration program 5051 identifies all generations of snapshots necessary for restoring data as necessary generations (step S602).

[0102] The data restoration program 5051 selects one of the necessary generations as the target generation (step S603).

[0103] The data restoration program 5051 selects one of the target data objects, which is an object that stores a snapshot of the target generation, based on the metadata 702 corresponding to the catalog 701 of the target generation (step S604). The data restoration program 5051 reads data from the target data object, and stores the data in the secondary volume 509 having an LBA corresponding to the LBA information of the metadata 702 (step S605). The data restoration program 5051 determines whether all of the target data objects have been selected (step S606).

[0104] If all of the target data objects have not been selected (step S606: No), the data restoration program 5051 returns to the process of step S604. On the other hand, if all of the target data objects have been selected (step S606: Yes), the data restoration program 5051 checks whether all of the data of the target generation has been restored to the secondary volume (step S607).

[0105] If the data restoration program 5051 has not restored all the data (step S607: No), it returns to the process of step S604, and if all the data has been restored (step S607: Yes), it ends the process.

[0106] Note that a plurality of data restoration processes may be executed in parallel by executing a plurality of data restoration programs 5051 in parallel. The data restoration program 5051 may be executed by the storage server 503, or another server that executes the data restoration program 5051 may be dynamically allocated. The number of other servers may be determined according to the data restoration request time. A public cloud computing service (e.g., a serverless service) may be utilized as the data restoration program 5051.

[0107] Next, the failback process will be described.

[0108] 18 is a flowchart for explaining an example of failback processing. The failback processing is executed by the failback program 5026, the copy program 5052, and the business process startup program. The business process startup program is a program that operates as management software in the data center 1, and starts application programs, changes the state of the primary storage 200, and the like. The business process startup program is not shown in the figure.

[0109] In the failback process, first, the failback program 5026 stops the application program of the secondary server 600 (step S700). The failback program 5026 instructs the primary storage 200 to copy data (step S701).

[0110] When the copy program 5052 of the primary storage 200 receives the above instruction, it starts copying data from the secondary volume 509 where the data has been restored to the primary volume 217 corresponding to that secondary volume 509 (step S702). After that, when the data copying is completed, the copy program 5052 notifies the failback program 5026 to that effect (step S703).

[0111] The failback program 5026 instructs the business process startup program to switch to the primary host (step S704). Upon receiving the instruction, the business process startup program changes the primary volume 217 to a writable state (step S705), and further starts the application program of the primary server 100 (step S706), and ends the process.

[0112] Meanwhile, the failback program 5026 removes the secondary volume from the secondary server 600 (step S707). The failback program 5026 deletes (detaches) the secondary volume (step S708), and reduces the capacity of the deleted secondary volume from the capacity pool (step S709). Then, the failback program 5026 deletes the secondary storage 500 for the reduced capacity from the secondary site (step S710). This makes it possible to prevent charges for cloud services and the like being used in the secondary environment.

[0113] Thereafter, the failback program 5026 executes the same processes as steps S201 to S210 in FIG. 13 to create another secondary volume 509 (initialize the secondary volume) (step S711), and ends the process.

[0114] In step S711, the failback program 5026 changes the number of the secondary volume 509 in the pair relationship management table 5011 to a secondary volume number for identifying the other secondary volume 509. In step S711, if the application program has not been changed, the process corresponding to step S207 for installing the application program can be omitted.

[0115] The failback process described above is merely an example, and is not limited to this. For example, in the failback process, instead of performing the process after step S708, the following process may be executed. That is, the failback program 5026 releases the capacity of the secondary volume and subtracts the released capacity from the capacity pool. After that, the failback program 5026 deletes the secondary storage 500 of the reduced capacity from the secondary site. Then, the failback program 5026 turns off the power of the secondary server 600, and further turns off the power of the secondary storage 500. In this case, since the secondary volume is not deleted, the secondary volume number that identifies the secondary volume does not change. This makes it possible to eliminate the need to update the pair relationship management table 5011, define paths, and redo the setting of the storage area for the application program. The release of the capacity of the secondary volume can be realized by performing a capacity reclaim process, which is a general technique, by issuing a capacity release instruction to the business process startup program.

[0116] Furthermore, in the failback process described with reference to FIG. 18, data is copied from the secondary storage 500 to the primary storage 200, but data may also be moved in the following manner.

[0117] Specifically, the failback program 5026 maps the secondary volume 509 of the secondary storage 500 to the primary volume 217 of the primary storage 200. The failback program 5026 provides the mapped primary volume 217 to the primary host and resumes the operation of the primary host. After that, the failback program 5026 reads the secondary volume 509 to which the primary storage 200 is mapped, and writes to the primary volume 217 of the copy destination in the primary storage 200. At this time, the copied area is processed in the primary volume of the copy destination, and the copy incomplete area is processed in the secondary storage 500 by transferring a read / write request to the secondary storage 500. Then, after the copy is completed, the failback program 5026 changes the IO destination of the primary host to the primary volume of the copy destination. Note that there are multiple methods for read and write processing during copying, and any method may be used. For example, a method of transferring data from the secondary storage 500 to the primary storage 200 at the same time as the read request can be given.

[0118] As explained above, in this embodiment, the management server 501 stops the secondary server 600 in advance, and prepares the secondary storage 500 that operates in accordance with a request from the secondary server 600 at the time of migration when the secondary server 600 executes business processing using data stored in the primary storage 200. Then, the management server 501 restores and stores data in the secondary storage 500 using the restoration data stored in the object storage 400, and starts the secondary server 600. Therefore, it is possible to reduce the costs associated with operating the secondary site before the migration, and therefore the operating costs of the secondary site can be reduced.

[0119] Furthermore, in this embodiment, the secondary storage 500 is stopped in a pre-deployed state so that the capacity of the secondary storage 500 is at a minimum value, which makes it possible to quickly migrate to the secondary site while suppressing charges based on the capacity of the secondary storage 500.

[0120] Moreover, in this embodiment, the restoration data is stored in the object storage 400. Since the object storage 400 is generally low cost, it is possible to reduce the cost associated with storing the restoration data.

[0121] Furthermore, in this embodiment, since the secondary storage 500 is prepared using an SDS that operates in a public cloud, the secondary storage 500 can be easily prepared.

[0122] The primary storage 200 generates backup data of the stored data and stores it in the object storage 400 as restoration data, so there is no need to prepare restoration data separately, which makes it possible to further reduce costs.

[0123] Furthermore, in this embodiment, when business processing is returned to the primary site, the secondary server 600 is stopped, and the data stored in the secondary storage 500 is copied to the primary storage 200, restoring the secondary storage 500 to the state it was in before preparation. Therefore, when business processing at the secondary site is completed, it becomes possible to reduce the associated operational costs thereafter. EXAMPLES

[0124] In the first embodiment, the secondary storage 500 is deployed in a steady state, but in this embodiment, the secondary storage 500 is deployed upon failover.

[0125] FIG. 19 is a diagram for explaining the failover process of this embodiment.

[0126] As shown in Fig. 19, in state A which is a steady state, the object storage 400 is in the same state as in the first embodiment shown in Fig. 9, that is, it stores a backup of the data stored in the primary storage 200. Also, the power of the secondary server 600 is off, and the secondary storage 500 is not constructed.

[0127] When an incident such as a disaster occurs, the secondary server 600 is powered on, and the secondary storage 500 and the secondary volume 509 accessed by the secondary server 600 are created. Then, data is restored from the object storage 400 to the secondary volume 509. In the example of Fig. 19, the secondary server 600 is powered off in state A, but the secondary server 600 may not have been created yet. In that case, the secondary server 600 is also created when transitioning to state B occurs.

[0128] FIG. 20 is a diagram showing an example of the protection target management table 5013 and the server / volume correspondence table 5014. As shown in FIG.

[0129] The protection target management table 5013 shown in FIG. 20 includes fields 901 to 905. Field 901 stores a primary storage number for identifying the primary storage 200 having the primary volume 217 to be protected. Field 902 stores a group number indicating a failover group that manages the unit of volumes to be switched when performing a failover. Field 903 stores a primary volume number for identifying the primary volume 217 to be protected. Field 904 stores the capacity of the primary volume to be protected. Field 905 stores bucket information indicating a bucket for storing backup data of the primary volume 217 to be protected.

[0130] The protection target management table 5013 is used to identify the bucket in which data is stored when restoring the data to the secondary volume. In addition, when the capacity of the primary volume 217 is updated in the primary storage 200, the protection target management table 5013 is also updated. For example, when the capacity of the primary volume 217 is expanded, this may be notified from the primary storage 200 to the public cloud, and the protection target management table 5013 may be updated on the public cloud side.

[0131] Moreover, the server / volume correspondence table 5014 shown in FIG.

[0132] A field 911 stores a primary volume number for identifying the primary volume 217 to be protected. A field 912 stores primary server information for identifying the primary server 100 to which the primary volume 217 to be protected is assigned. Note that one primary volume 217 may be assigned to multiple primary servers 100. A field 913 stores a secondary server number for identifying the secondary server 600 that takes over business processing by the primary server 100. The secondary server number is determined when the secondary server 600 is deployed by the secondary environment construction program 5021, and is stored in the server-volume correspondence table 5014.

[0133] Fig. 21 is a diagram showing an example of the secondary storage management table 5015. The secondary storage management table 5015 shown in Fig. 21 includes fields 921-925.

[0134] Field 921 stores a secondary storage number. Field 922 stores a primary storage number. Field 923 stores a failover group number. Field 924 stores sharability information indicating whether the secondary storage 500 identified by the secondary storage number can be shared with other failover groups. Field 925 stores the availability rate of the secondary storage 500 identified by the secondary storage number.

[0135] Fig. 22 is a flowchart for explaining an example of the secondary environment construction process of this embodiment. In this embodiment, since the deployment of the secondary storage 500 is not executed in the preparation stage, a part of the secondary environment construction process of the embodiment 1 described with reference to Fig. 13 is executed.

[0136] Specifically, the secondary environment creation program 5021 executes the processes of steps S200, S201, S207, and S209. In this embodiment, since the secondary storage number and secondary volume number in the storage correspondence table 5012 are determined at the time of failover, the secondary environment creation program 5021 only needs to set the primary storage number, primary volume number, and object bucket in the process of step S201.

[0137] When the processing of step S209 is completed, the secondary environment construction program 5021 adds information about the primary volume 217 set as the protection target to the protection target management table 5013 (step S800). Then, the secondary environment construction program 5021 updates the server / volume correspondence table 5014 to manage the relationship between the primary server 100 and the primary volume 217 and the secondary server 600 deployed in step S200 (step S801), and terminates the processing.

[0138] FIG. 23 is a flowchart illustrating an example of the failover process of this embodiment.

[0139] In the failover process, first, the failover program 5024 identifies the primary volume 217 to be the target of the failover and the primary storage 200 to which the primary volume 217 is allocated (step S900). For example, at the time of failover, the primary volume 217 to be the target of the failover or the failover group is specified. Based on this specification, the failover program 5024 can obtain the primary storage number of the primary storage 200 to which the primary volume 217 is allocated from the protection target management table 5013.

[0140] The failover program 5024 uses the server volume correspondence table 5014 to identify the secondary server 600 to be started based on the secondary server number corresponding to the primary volume number of the primary volume 217 that is the target of failover (step S901). The secondary server 600 may be deployed at this time to introduce an application.

[0141] The failover program 5024 calls the secondary storage specification program 5027, and has the secondary storage specification program 5027 determine whether or not it is necessary to deploy the secondary storage 500 corresponding to the specified secondary server 600, using the secondary storage management table 5015 (step S902). Note that if there are multiple failover groups in the primary storage 200, there is a possibility that the secondary storage 500 targeted in this process has already been deployed in the failover process of another failover group. For this reason, this process is executed.

[0142] If deployment is required (step S902: Yes), the failover program 5024 deploys the secondary storage 500 (step S903). At this time, the failover program 5024 searches the storage correspondence table 5012 with the primary storage number to determine the deployment contents of the secondary storage 500 (the number of servers constituting the secondary storage 500, the capacity of the secondary storage, etc.). On the other hand, if deployment is not required (step S902: No), the process of step S903 is skipped.

[0143] Thereafter, the failover program 5024 creates a secondary volume 509 (step S203), and executes a data restoration process to restore the data stored in the bucket in the object storage 400 to the secondary volume (step S904).

[0144] The failover program 5024 updates the secondary storage management table 5015 (step S905). Specifically, if the secondary storage 500 was deployed in step S903, the failover program 5024 adds a record relating to the secondary storage 500 to the secondary storage management table 5015, and if step S903 was skipped, the failover program 5024 updates the failover group information.

[0145] Thereafter, the processes of steps S205, S206 and S208 are executed, and the process ends.

[0146] Fig. 24 is a flowchart for explaining an example of the deployment judgment process which is the process of step S902 in Fig. 23. The deployment judgment process is executed by the secondary storage specification program 5027.

[0147] In the deployment judgment process, the secondary storage specification program 5027 uses the secondary storage management table 5015 to judge whether or not the same failover group as the specified primary storage 200 has already been failed over (step S907).

[0148] If failover has already occurred, the secondary storage specification program 5027 uses the sharability information in the secondary storage management table 5015 to determine whether or not a sharable secondary storage 500 exists (step S908).

[0149] If there is no sharable secondary storage 500 (step S908: No), the secondary storage specification program 5027 reports the deployment of the secondary storage 500 to the failover program 5024 (step S909), and ends the process.

[0150] On the other hand, if a sharable secondary storage 500 exists (step S908: Yes), the secondary storage specification program 5027 judges whether or not it is necessary to scale out or scale up the secondary storage 500 based on the operation rate of the secondary storage 500 in the secondary storage management table 5015 (step S910). For example, the secondary storage specification program 5027 determines additional resources by scaling out or up the secondary storage 500 so that the operation rate becomes a predetermined value (for example, 50%) or less.

[0151] If scale-out and scale-up are necessary (step S910: Yes), the secondary storage specification program 5027 increases the capacity by adding a storage server or creating cloud storage and adding it to the capacity pool (step S911). Also, the instance type may be changed to a higher performance one to reduce the operation rate of the secondary storage. On the other hand, if scale-out and scale-up are not necessary (step S910: NO), step S911 is skipped.

[0152] Thereafter, the secondary storage specification program 5027 reports the specified deployed secondary storage 500 to the failover program 5024 (step S911) and ends the process. Also, if a secondary storage 500 having resources required by all failover groups sharing the secondary storage 500 is created in step S903, only the step of determining whether the secondary storage 500 is deployed or not may be executed in step S907. If it is deployed, a failover is performed to the deployed secondary storage 500, and if it is not deployed, a new secondary storage 500 is deployed. Also, a general feature of cloud computing is that it is possible to add necessary resources when necessary. Therefore, after failover, resources may be added to the storage 500 according to the load on the secondary storage 500. In that case, steps S910 and S911 are unnecessary.

[0153] In step S902, the secondary storage specification program 5027 judges whether or not the secondary storage 500 needs to be deployed by judging whether or not the failover group that shared the primary storage has already deployed the secondary storage 500. However, the secondary storage specification program 5027 may select a deployed secondary storage 500 with a low load as the failover destination using the operation rate in the secondary storage management table 5015. A secondary storage 500 that can be shared by a plurality of primary storages 200 or failover groups may be prepared in advance. In this case, the sharable secondary storage 500 can be distinguished from other secondary storages 500 using the sharability information in the secondary storage management table 5015.

[0154] As described above, in this embodiment, the secondary storage 500 is deployed at the time of migration, making it possible to reduce the operating costs of the secondary site.

[0155] Furthermore, in this embodiment, if it is possible to share the secondary storage 500 that has already been deployed, the existing secondary storage 500 is used without deploying a new secondary storage 500, thereby making it possible to reduce the operating costs of the secondary site. EXAMPLES

[0156] In the first and second embodiments, the primary storage 200 periodically acquires snapshots and transfers the incremental data to the object storage 400, but the present disclosure can also be applied to other configurations. Fig. 25 is a diagram showing a storage system of another configuration.

[0157] (Other form 1) In this embodiment shown in FIG. 25(a), the primary server 100 and the object storage 400 are connected to each other via a storage gateway 700. The storage gateway 700 provides the primary server 100 with a volume 700A as a primary volume. The entity of the data is stored as an object 402 in the object storage 400. The object 402 in this embodiment is not backup data as described in the first and second embodiments, but stores the latest data used in the application program (App) of the primary server 100. Note that, although one piece of data is shown as one object 402 in FIG. 25, it may be distributed to multiple objects 402. Also, the object storage 400 may be configured with multiple physical servers.

[0158] A snapshot 700B of the data entity stored in the object storage 400 is periodically acquired on the cloud side (for example, the management server 501). In the example shown in the figure, a snapshot 700B of the volume 700A on December 1st (12 / 1) and a snapshot 700B of the primary volume 217 on December 2nd (12 / 2) are acquired. In the failover process, the failover program 5024 restores data to the secondary volume 509 based on the snapshot 700B in the object storage 400.

[0159] In this embodiment, it is possible to share the storage device that stores data and the object storage 400 that stores restoration data, which makes it possible to reduce costs.

[0160] (Other Form 2) In this embodiment shown in Fig. 25(b), in addition to the configuration shown in Fig. 25(a), a primary storage 200 is provided. In this embodiment, a volume 700A provided by a storage gateway 700 is mapped to a primary volume 217 provided by the primary storage 200. The primary storage 200 provides the primary volume 217 to which the volume 700A is mapped to the primary server 100. In this case, it is possible to utilize the large-capacity cache and high performance and high functionality characteristics of the primary storage 200 while reducing costs.

[0161] (Other forms 3): In this embodiment shown in Fig. 26(b), the primary storage 200 has a local copy function that multiplexes volume data within the device. The primary storage 200 uses the primary volume 217 provided to the primary server 100 as the source of local copy, and the volume 700A provided by the storage gateway 700 as the destination of local copy. As a result, data of the primary volume 217 as the source is stored in the primary storage 200, and data of the volume 700A as the destination is stored in the object storage 400. In this case, since the application program of the primary server 100 does not need to access the object storage 400, it is possible to achieve high performance.

[0162] Furthermore, by periodically applying the data of the copy source primary volume 217 to the copy destination volume 700A, the data stored in the object storage 400 can be kept up to date.

[0163] For example, by repeating a first process in which the primary storage 200 copies data from the source primary volume 217 to the destination volume 700A, and a second process in which the object storage 400 acquires a snapshot after the copy is complete, the data stored in the object storage 400 can be kept up to date.

[0164] The first process includes a resynchronization process and a split process for local copy. The split process is a process for temporarily stopping the copy of data from the source primary volume 217 to the destination volume 700A. If a write request to the source primary volume 217 occurs while the copy is stopped, the write address is recorded. The resynchronization process is a process for copying data from the source primary volume 217 to the destination volume 700A, and the data written only to the source primary volume 217 is copied to the destination volume 700A using the write address recorded in the split process. Note that even if a write request occurs during copying, the write address is recorded, and copying is repeated until the split process is executed.

[0165] In this embodiment, as in the first and second embodiments, it is possible to reduce the operating costs of the secondary site.

[0166] The above-mentioned embodiments of the present disclosure are illustrative examples of the present disclosure, and are not intended to limit the scope of the present disclosure to only those embodiments. A person skilled in the art can implement the present disclosure in various other forms without departing from the scope of the present disclosure. [Explanation of symbols]

[0167] 1: Data center 2: Cloud 100: Primary server 200: Primary storage 210: Controller 211: Interface 212: Interface 213: Management interface 214: Interface 215: Memory 216: Processor 217: Primary volume 220: Physical drive 221: Control information 222: Program 223: Cache unit 230: Management network 270: Maintenance terminal 271: Maintenance port 272: Input / output unit 273: Memory 274: CPU 275: Maintenance program 300: Network 400: Object storage 401: Bucket 402: Object 403: Object group 500: Secondary storage 501: Management server 501a: Memory 501b: CPU 502: Network 503: Storage server 504: Communication port 505: Memory 506: CPU 507: Cloud storage 508: Capacity pool 509: Secondary volume 600: Secondary server 700: Storage gateway 700A: Volume 700B: Snapshot

Claims

1. a first storage device that stores data corresponding to a read / write request from a first host; A storage system having a restoration storage device that stores restoration data for restoring the data, and a management device that causes a second host to execute a business process using the data, the second host is previously stopped; When the management device causes the second host to execute the business process, the management device prepares the second storage device based on control information specifying a second storage device that operates in accordance with a request from the second host, restores the data in the second storage device using the restoration data, stores the data, and starts up the second host; The restoration storage device is an object storage or a file storage, and is lower in cost than the second storage device; the second storage device is stopped in an initial state in which the storage capacity is pre-deployed to a predetermined small capacity, The management device prepares the second storage device based on the control information by increasing the storage capacity so that the data can be stored.

2. A first storage device that stores data in response to a read / write request from a first host; A storage system having a restoration storage device that stores restoration data for restoring the data, and a management device that causes a second host to execute a business process using the data, the second host is previously stopped; When the management device causes the second host to execute the business process, the management device performs the following steps based on control information that specifies a second storage device that operates in accordance with a request from the second host: preparing the second storage device, restoring the data using the restoration data in the second storage device and storing the data in the second storage device, and booting the second host; The restoration storage device is an object storage or a file storage, and is lower in cost than the second storage device; the management device prepares the second storage device by deploying it so that the second storage device has a storage capacity capable of storing the data based on the control information; the management device prepares the second storage device in units of a primary volume provided by the first host in order to store the data in the first storage device or a group including one or a plurality of the primary volumes; The management device, when preparing the second storage device, determines based on the control information whether or not to restore the data relating to the primary volume or the group to the already prepared second storage device, and if restoring to the already prepared second storage device, increases the capacity of the second storage device based on the control information, and if restoring to the already prepared second storage device is not to be performed, deploys the second storage device anew.

3. The storage system according to claim 1 , wherein the management device prepares the second storage device by using a software-defined storage that operates in a public cloud.

4. A first storage device that stores data in response to a read / write request from a first host; A storage system having a restoration storage device that stores restoration data for restoring the data, and a management device that causes a second host to execute a business process using the data, the second host is previously stopped; When the management device causes the second host to execute the business process, the management device performs the following steps based on control information that specifies a second storage device that operates in accordance with a request from the second host: preparing the second storage device, restoring the data using the restoration data in the second storage device and storing the data in the second storage device, and booting the second host; The restoration storage device is an object storage or a file storage, and is lower in cost than the second storage device; Mapping a storage area of ​​the restoration storage device to a volume of the first storage device; A storage system, wherein the first storage device copies data of a primary volume provided to the first host to the volume, and stores a snapshot of the copied data in the restoration storage device as the restoration data.

5. A first storage device that stores data in response to a read / write request from a first host; A storage system having a restoration storage device that stores restoration data for restoring the data, and a management device that causes a second host to execute a business process using the data, the second host is previously stopped; When the management device causes the second host to execute the business process, the management device performs the following steps based on control information that specifies a second storage device that operates in accordance with a request from the second host: preparing the second storage device, restoring the data using the restoration data in the second storage device and storing the data in the second storage device, and booting the second host; The restoration storage device is an object storage or a file storage, and is lower in cost than the second storage device; A storage system, wherein the first storage device is a storage gateway that stores the data in the restoration storage device as the restoration data by providing a volume to which the memory area of ​​the restoration storage device is mapped to the first host.

6. A first storage device that stores data in response to a read / write request from a first host; A storage system having a restoration storage device that stores restoration data for restoring the data, and a management device that causes a second host to execute a business process using the data, the second host is previously stopped; When the management device causes the second host to execute the business process, the management device performs the following steps based on control information that specifies a second storage device that operates in accordance with a request from the second host: preparing the second storage device, restoring the data using the restoration data in the second storage device and storing the data in the second storage device, and booting the second host; The restoration storage device is an object storage or a file storage, and is lower in cost than the second storage device; The first storage device is a storage gateway that stores the data in the restoration storage device as the restoration data by providing the first host with a primary volume that is mapped to a volume to which the memory area of ​​the restoration storage device provided from the storage gateway is assigned.

7. 1. A management method for a storage system having a first storage device that stores data corresponding to a read / write request from a first host, a restoration storage device that stores restoration data for restoring the data, and a management device that causes a second host to execute a business process using the data, comprising: the second host is previously stopped; When the management device causes the second host to execute the business process, the management device prepares the second storage device based on control information specifying a second storage device that operates in accordance with a request from the second host, restores the data in the second storage device using the restoration data, stores the data, and starts up the second host; The restoration storage device is an object storage or a file storage, and is lower in cost than the second storage device; the second storage device is stopped in an initial state in which the storage capacity is pre-deployed to a predetermined small capacity, A management method, in which, in preparing the second storage device, the management device prepares the second storage device based on the control information by increasing the memory capacity so that the data can be stored.

Images