Computer system and data management method in storage system

Abstract

To reduce cost of the cloud in retaining data at an on-premise side and cloud side.SOLUTION: A first storage system 100 stores data related to execution of a first server in a logical volume, and transmits the data stored in the logical volume to a second storage system 300. The second storage system 300 provides a virtual volume to the second server, and stores the data received from the first storage system 100 in the virtual volume. The second storage system 300 executes a process by using data stored in the virtual volume at each execution timing. Then, the second storage system 300 determines whether the data stored in the virtual volume is left in the virtual volume or is discarded based on the presence or absence of an access and the type of access, which are access statuses to the data at each execution timing, and discards the data determined to be discarded from the virtual volume.SELECTED DRAWING: Figure 21

Description

[Technical Field]

[0001] The present invention relates to a data management method in a computer system and a storage system. [Background technology]

[0002] In recent years, in addition to online transactions that run on-premise, there has been a growing need for secondary use, such as batch processing and data utilization, that uses the results of online transaction processing.

[0003] Consider the case where processing using the results of online transaction processing is performed on-premises. In this case, in addition to the compute and storage resources required to prevent a deterioration in the responsiveness of the online transaction, compute and storage resources for batch processing and secondary use are also required. As a result, these resources must be sufficient to operate stably even under maximum load, which results in high costs.

[0004] To address this high cost issue, hybrid clouds are sometimes used, which reduce the amount of resources used on-premises by offloading the compute and storage resources related to batch processing and secondary use to the cloud for distributed processing. In a hybrid cloud environment, this can be achieved by transferring data generated by online transaction processing executed on-premises to the cloud. In this type of usage, it is necessary to replicate and store this data on both the on-premises and cloud sides.

[0005] Regarding such a method for retaining replicated data, for example, Patent Document 1 employs a method in which all data is retained on the cloud side and data that is infrequently accessed on the on-premises side is discarded from the on-premises side in order to reduce the amount of data retained on the on-premises side. This reduces costs on the on-premises side. In addition, this method improves data responsiveness on the on-premises side by sending data from the cloud side to the on-premises side when the access frequency of data that has already been discarded on the on-premises side increases. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Patent No. 6317524 Summary of the Invention [Problem to be solved by the invention]

[0007] To store data on the cloud, you must allocate storage space on the cloud (hereafter referred to as cloud storage). Cloud storage charges are calculated based on the allocated capacity and time. Therefore, if the cloud storage capacity is large or if data is to be stored for a long period of time, the cloud cost will be high.

[0008] In addition, if the frequency of access to data that has already been discarded on the on-premises side increases, the data will be sent from the cloud to the on-premises side. In general cloud usage, there is no charge for inputting data from an external source to the cloud, but there is a charge for outputting data from the cloud, which also contributes to high costs.

[0009] Thus, the method disclosed in Patent Document 1 has the problem of high costs.

[0010] The present invention has been made in consideration of the above circumstances, and aims to reduce cloud costs when storing data on the on-premise side and the cloud side. [Means for solving the problem]

[0011] In one aspect of the present invention, a computer system has a first storage system located at a first base and providing a logical volume to a first server, and a second storage system located at a second base and connected to the first storage system via a network, wherein the first storage system has a first processor and memory, and the second storage system has a second processor and memory, the first processor stores data related to the execution of the first server in the logical volume and transmits the data stored in the logical volume to the second storage system, the second processor provides a virtual volume to the second server via the second storage system, stores the data received from the first processor in the virtual volume, and executes processing using the data stored in the virtual volume at each execution timing, and determines whether to leave the data stored in the virtual volume in the virtual volume or discard it based on the access status of the data at each execution timing, which is the presence or absence of access and the type of access, and discards the data determined to be discarded from the virtual volume. [Effects of the Invention]

[0012] According to the present invention, cloud costs can be reduced when data is held on the on-premise side and the cloud side. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of a hybrid cloud system according to an embodiment. [Figure 2]FIG. 2 is a block diagram showing an example of the hardware configuration of a first storage system and a second storage system according to the embodiment. [Figure 3] FIG. 2 is a diagram for explaining storage functions of a first storage system and a second storage system according to the embodiment. [Figure 4] FIG. 10 is a diagram for explaining an example of a transaction program executed on the on-premise side according to the embodiment. [Figure 5] FIG. 2 is a diagram for explaining a logical image and a physical image in a transaction program according to the embodiment. [Figure 6] FIG. 2 is a diagram for explaining characteristics of data referenced by a transaction program according to the embodiment. [Figure 7] 5A and 5B are diagrams for explaining characteristics of data referenced by a molding program according to an embodiment. [Figure 8] FIG. 2 is an image diagram for explaining data contents according to the embodiment. [Figure 9] FIG. 10 is a diagram showing access characteristics of history data and master data according to the embodiment. [Figure 10] FIG. 4 is a diagram for explaining a time chart of execution of a transaction program and a molding program according to the embodiment. [Figure 11] FIG. 2 is a diagram for explaining data held in a memory in the first storage system according to the embodiment. [Figure 12] FIG. 4 is a diagram for explaining a storage volume management table according to the embodiment. [Figure 13] FIG. 4 is a diagram for explaining a logical-to-physical conversion table according to the embodiment. [Figure 14] FIG. 10 is a diagram for explaining data held in a memory in a second storage system according to the embodiment. [Figure 15] FIG. 4 is a diagram for explaining an access history table according to the embodiment. [Figure 16] FIG. 4 is a diagram for explaining state transitions of an access history table according to the embodiment. [Figure 17]FIG. 10 is a diagram showing an example of the operation of a virtual volume discard entry estimation program according to the embodiment. [Figure 18] FIG. 2 is a diagram for explaining a processing function of continuous / random estimation according to the embodiment. [Figure 19] FIG. 2 is a diagram for explaining a processing function of historical data / master data estimation according to the embodiment. [Figure 20] 10 is a flowchart showing a virtual volume data discarding process according to the embodiment. [Figure 21] FIG. 4 is a diagram for explaining a sequence relating to the execution of a molding program according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that the following description and drawings are examples for explaining the present invention, and appropriate omissions and simplifications have been made for clarity of explanation. Furthermore, not all combinations of features described in the embodiments are necessarily essential to the solution of the invention. The present invention is not limited to the embodiments, and all application examples consistent with the concept of the present invention are included within the technical scope of the present invention. Those skilled in the art can make various additions and modifications to the present invention within the scope of the present invention. The present invention can also be implemented in various other forms. Unless otherwise specified, each component may be plural or singular. In the following description, a "CPU (Central Processing Unit)" is an example of one or more processor devices. The at least one processor device is typically not limited to a CPU, but may be another type of processor device such as a GPU (Graphics Processing Unit). The at least one processor device may be a single-core or multi-core. The at least one processor device may be a processor core.

[0015] At least one processor device may be a circuit that is a collection of gate arrays written in a hardware description language that performs some or all of the processing. The circuit is a processor device in the broad sense, such as a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), or an application-specific integrated circuit (ASIC).

[0016] In the following explanation, the processing may be mainly explained using the "yyy program." In this case, the program is executed by a CPU to realize a processing function called the "yyy functional unit," and is the main executing entity of the processing. The processing function may be realized by one or more computer programs being executed by a processor, or may be realized by one or more hardware circuits (e.g., FPGA or ASIC), or a combination thereof.

[0017] When a function is realized by executing a program by a processor, the specified processing is performed using a storage device and / or an interface device, etc., so the function may be considered to be at least a part of the processor. Processing described using a functional unit as the subject may also be processing performed by a processor or a device having that processor.

[0018] The program may be installed from a program source. The program source may be, for example, a program distribution computer or a computer-readable recording medium (e.g., a non-transitory recording medium). The description of each function is an example, and multiple functions may be combined into one function, or one function may be divided into multiple functions. A "yyy function unit" may be called a "yyy unit."

[0019] In the following description, various information may be described in table format, but the data format of the information may be a format other than a table format (for example, CSV (Comma Separated Values) format, etc.) Furthermore, various information may be stored as a table in a storage unit, or may be embedded as logic in a program.

[0020] In addition, in the following description, when describing elements of the same type without distinguishing between them, common reference symbols will be used, and when describing elements of the same type with distinction between them, reference symbols will be used.

[0021] (Configuration of hybrid cloud system S according to the embodiment) FIG. 1 is a block diagram showing an example of the configuration of a hybrid cloud system S according to an embodiment.

[0022] In the hybrid cloud system S, on-premise resources 1, cloud-side resources 3, and a management server 20 that manages them are connected via a network 21 and a network 40. The on-premise side is a first base. The cloud side is a second base. The cloud-side resources 3 are assumed to be a public cloud environment, but are not limited to this. Hereinafter, "on-premise" may be abbreviated as "on-premise."

[0023] In the on-premise resource 1, an APP / DB server 10 and a first storage system 100 are connected via a network 11. The APP / DB server 10 is a server that executes a transaction program 12 that processes online transactions. The first storage system 100 stores on-premise data and controls I / O issued by the APP / DB server 10. The APP / DB server 10 is an example of a first server. The transaction program 12 is an example of a first program executed on the first server.

[0024] Similarly, in the cloud-side resource 3, an APP / DB server 30 and a second storage system 300 are connected via a network 31. The APP / DB server 30 is a server that processes batch processing and secondary use processing. The second storage system 300 stores data on the cloud side and controls I / O issued by the APP / DB server 30. The APP / DB server 30 is an example of a second server.

[0025] The batch processing and secondary use processing use data generated by the online program processing as input and perform database processing and data formation, and are collectively referred to as the forming program 32. The forming program 32 is an example of a second program executed on the second server.

[0026] The management server 20 is connected to the APP / DB server 10, the first storage system 100, the APP / DB server 30, and the second storage system 300 via a network 21. The management server 20 performs initial configuration and management of the connected servers and storage systems. These configuration and management functions are now sometimes substituted by infrastructure management functions and deployment automation functions such as Kubernetes.

[0027] The management server 20 is placed on either the on-premise side or the cloud side, or both. This means that the connected resources are managed in an integrated manner, and the location of the placement is not limited in this embodiment.

[0028] Furthermore, the first storage system 100 and the second storage system 300 are interconnected via a network 40, which serves as a path for data transfer between the first storage system 100 and the second storage system 300. A system including at least the first storage system 100 and the second storage system 300 connected via the network 40 is an example of a computer system.

[0029] (Configuration of the first storage system 100 and the second storage system 300) 2 is a block diagram showing an example of the hardware configuration of the first storage system 100 and the second storage system 300 according to the embodiment. For ease of explanation, a general configuration is disclosed here, but the present invention is not limited to this.

[0030] The first storage system 100 and the second storage system 300 are configured to include a storage controller 110 and multiple SSDs 120. The storage controller 110 is configured to include multiple processors 114, a memory 115, a front-end I / F 111, and a back-end I / F 116. The front-end I / F 111 is an interface for I / O issued by the APP / DB server 10. The back-end I / F 116 is a connection interface with the SSDs 120. The first storage system 100 and the second storage system 300 use these resources to execute storage functions such as general I / O processing.

[0031] The management I / F 112 is an interface with the management server 20. The inter-system I / F 113 is connected to the other storage system via the network 40, and serves as a data transfer path between the first storage system 100 and the second storage system 300.

[0032] In this embodiment, the first storage system 100 and the second storage system 300 are described as having the same hardware configuration, but this is for ease of explanation and the present invention is not limited to this configuration.

[0033] (Functions of the first storage system 100 and the second storage system 300) FIG. 3 is a diagram illustrating the storage functions of the first storage system 100 and the second storage system 300 according to the embodiment.

[0034] A logical volume 130 and a physical pool 132 are arranged in the first storage system 100. The logical volume 130 is a volume provided to the APP / DB server 10. A mapping unit 131 maps the logical volume 130 and the physical pool 132.

[0035] The SSD 120 is mapped to the physical pool 132. For example, a specific block of the SSD 120 in the physical pool 132 is allocated to the logical block A in the logical volume 130 by the mapping unit 131. This physically holds the logical block A, and enables access to the actual data in the physical pool 132 by this mapping in response to an access from the APP / DB server 10. The logical volume 130 has a configuration in which all data of the defined volumes is allocated.

[0036] The first storage system 100 is also configured to be able to hold snapshots of the physical pool and mapping information at a specified time. For example, the first storage system 100 is configured to be able to hold multiple snapshots, such as a snapshot (generation 1) 133 at a specified time (generation 1) and a snapshot (generation 2) 134 at a specified time (generation 2).

[0037] For example, consider the case where logical block B is written to the logical volume 130 after the specified time (generation 1), and then a snapshot is created at the specified time (generation 2). In this case, snapshot (generation 2) 134 is a snapshot in which only logical block B has been updated.

[0038] The second storage system 300 is provided with a virtual volume 330, a mapping unit 131, and a physical pool 132. The virtual volume 330 is a volume to which part of the data of volumes defined in the first storage system 100, such as the logical volume 130 and snapshot 133, is allocated. The virtual volume 330 is provided as virtual storage to the APP / DB server 30. The mapping unit 131 and the physical pool 132 have the same functions as those in the first storage system 100.

[0039] The first storage system 100 and the second storage system 300 transfer data via a network 40 .

[0040] Here, the logical volume 130 of the first storage system 100 is a volume whose volume type 1414, which will be described later, is defined as a standard volume. Also, the virtual volume 330 is a volume whose volume type 1414 is defined as a virtual volume.

[0041] In this embodiment, resources with the same name in the first storage system 100 and the second storage system 300 are assumed to have equivalent functions. This is to facilitate the explanation of the concept of this embodiment and does not limit the differences in detailed functions. Furthermore, although the snapshot function of the storage function of the second storage system 300 is not mentioned, this is also to facilitate the explanation and does not limit whether the second storage system 300 has a snapshot function.

[0042] Next, an example of the transaction program 12 executed on the on-premise side and the forming program 32 executed on the cloud side in this embodiment will be described. The programs assumed in this embodiment are a transaction program on the on-premise side and a forming program on the cloud side, but are not limited to this.

[0043] (Transaction program according to an embodiment) FIG. 4 is a diagram illustrating an example of a transaction program executed on the on-premise side according to the embodiment.

[0044] Typical transaction programs use databases. For example, consider a standard accounting program shown in Figure 4, in which a customer with customer ID A0 places an order with a supplier with supplier ID C0. In this case, the data consists of master data, which stores a large amount of customer and supplier information, and history data, which adds and stores transactions for each order. The history data is accessed continuously, while the master data is accessed randomly.

[0045] As shown in Figure 4, each row of history data is expressed with columns such as order date, customer ID, supplier ID, and status (such as the status of each order, such as order completed, delivery completed, or payment completed). The data structure of a transaction program is a model that uses the customer ID or supplier ID to reference the target row of master data linked to history data. In this type of data structure for a transaction program, the master data is determined in advance, and history data is added for each daily transaction.

[0046] Here, the master data is structured so that data for each discretely allocated customer ID is referenced for linking references. In addition, a logical division called a partition is used for historical data. A partition is a division of a single table based on defined criteria; for example, historical data can be divided in monthly units. Using partitions improves data portability, allowing backups to be performed on a partition-by-partition basis. Furthermore, by referencing data divided into monthly partitions in monthly batch processing, for example, it is possible to minimize the total number of searches in database processing, thereby improving processing performance.

[0047] (Logical and physical images in transaction programs) FIG. 5 is a diagram illustrating a logical image and a physical image in a transaction program according to an embodiment. As shown in the left diagram of FIG. 5, history data in a transaction program is added for each transaction. When adding data to a database, physical space within a volume is not allocated for each row, but rather an engine within the database allocates physical space in advance in allocation units that are sufficiently larger than the row data size. The allocation units in this pre-allocation are tables or partitions. Therefore, in each transaction, data is added sequentially within the allocation unit, and in tables or partitions, the same table or partition data is arranged contiguously, at least within the allocation unit.

[0048] So far, we have been talking about newly added historical data. However, in a typical database, updates are also performed on each row. For example, in historical data, status information such as order completed, delivery completed, and payment completed, as shown in Figure 5, is updated. Database updates can be done by updating the target row, or by invalidating the target row and re-adding the corrected data.

[0049] Furthermore, master data, such as customer information, may also be updated. In addition, databases undergo a process called defragmentation, which involves cleaning invalid data areas and rearranging data. As a result, updates to each table may occur frequently.

[0050] (Characteristics of data referenced by transaction programs according to embodiments) FIG. 6 is a diagram for explaining the characteristics of data referenced by a transaction program according to the embodiment.

[0051] In a typical data processing program, such as a monthly batch, the data flow typically processes each added transaction, such as issuing an invoice, and outputs the resulting data. In this case, the transaction program references the added historical data and the master data linked to the historical data. In particular, in the case of historical data partitioned by month, the monthly data divided by the target partition is referenced. Therefore, sequential access is performed on a partition-by-partition basis.

[0052] (Characteristics of data referenced by molding program according to embodiment) FIG. 7 is a diagram for explaining the characteristics of data referenced by the molding program according to the embodiment.

[0053] When the forming program references master information linked to historical data, it logically accesses only the data rows linked by the target ID. However, it is necessary to consider indexes in the database. An index is a technology that reduces access time by directly referencing only specific rows in a table. This index requires that the index table be generated in advance. On the other hand, if an index is not used, it is not possible to directly reference specific rows of master data. In this case, the flow is to perform a full search of the master data in advance. Therefore, when it comes to master data, there can be a mixture of discrete random access and sequential access using a full search.

[0054] (Data content according to the embodiment) FIG. 8 is an image diagram for explaining the data content according to the embodiment.

[0055] 8(a) shows the data contents of the entire database including the historical data and master data. The historical data consists of data for (N+1) months (N is an integer of 2 or more).

[0056] The latest historical data for this month is data newly stored by the transaction program 12 during this month. Similarly, historical data from one month ago is historical data stored during the previous month. This historical data consists of data from multiple months. Master data is mostly static data, with the exception of some updates. The data in this entire database is stored in the first storage system 100 in the on-premise resource 1.

[0057] FIG. 8(b) is a diagram for explaining the data referenced by the forming program 32 (shown by hatching in FIG. 8(b)). With regard to historical data, only data newly stored by the transaction program 12 during the current month is referenced. In other words, historical data from one month ago or earlier is not referenced. With regard to master data, as explained in FIG. 7, if an index is present, only a portion of the data linked from the historical data is referenced. In this way, when referencing this month's data, the forming program 32 references only a portion of the database rather than the entire database. According to the operation of this forming program 32, there is no need to store the entire database data in the second storage system 300.

[0058] Therefore, by actively discarding data that is not referenced in the second storage system 300, it is possible to reduce the SSD capacity allocated to the cloud side and reduce cloud storage charges. Therefore, in this embodiment, unnecessary data is discarded from the virtual volume 330.

[0059] FIG. 8(c) is a diagram for explaining data to be discarded from the cloud-side virtual volume 330 (shown by hatching in FIG. 8(c)). With regard to historical data, all historical data will become unnecessary once the molding program 32 finishes storing data for this month, so it is desirable to discard all of this data. With regard to master data, data that the molding program 32 has not referenced during this month is likely not to be referenced in the future, so it is desirable to discard this data as well. In this way, the characteristics of data to be discarded differ between historical data and master data.

[0060] Here, the forming program 32 operates via an RDBS (relational database system), and the forming program 32 and RDBS can grasp the logical block positions of the history data and master data. However, because this information can only be accessed with kernel authority, the second storage system 300 cannot grasp the logical block positions of the history data and master data without cooperation with the forming program 32 and RDBS.

[0061] (Access characteristics of history data and master data according to the embodiment) Fig. 9 is a diagram showing the access characteristics of history data and master data according to the embodiment. Fig. 9 shows the areas referenced by the molding program 32 at each point in time: three months ago, two months ago, one month ago, and this month.

[0062] First, (a) the historical data will be shown. (Condition A) The molding program 32 continuously accessed the area corresponding to the first row of the area illustrated in the 4x4 matrix three months ago. (Condition B) The molding program 32 continuously accessed the area corresponding to the second row of the area illustrated in the 4x4 matrix two months ago. (Condition C) The molding program 32 continuously accessed the area corresponding to the third row of the area illustrated in the 4x4 matrix one month ago. (Condition D) The molding program 32 continuously accessed the area corresponding to the fourth row of the area illustrated in the 4x4 matrix this month.

[0063] In this way, the history data is accessed continuously, but has the characteristic that it is accessed exclusively each month by the shaping program 32. Also, while it was accessed one month ago, it may not have been accessed this month. This behavior is a characteristic that differs from the general LRU (Least Recently Used) behavior.

[0064] Next, we will look at master data. If a database index has been set up in advance, data from three months ago, two months ago, one month ago, and this month will all be randomly accessed. On the other hand, if no index has been set up, data from three months ago, two months ago, one month ago, and this month will all be accessed consecutively. However, due to old data or garbage collection by the database, data from three months ago, two months ago, one month ago, and this month may not be accessed at all.

[0065] Thus, it can be seen that the reference characteristics of the historical data and the master data are different.

[0066] (Time chart of program execution according to the embodiment) FIG. 10 is a diagram for explaining a time chart of the execution of the transaction program 12 and the molding program 32 according to the embodiment.

[0067] First, in step S11, the CPU of the APP / DB server 10 of the on-premise resource 1 executes the transaction program 12 for two months prior. Next, at the end of the current month two months prior, the CPU of the APP / DB server 10 acquires and saves a snapshot of the database (for the two months prior) accumulated by executing the transaction program 12 for the two months prior. Next, the cloud-side resource 3 uses this saved snapshot (for the two months prior) to execute the building program 32 for the two months prior.

[0068] After the snapshot is saved in step S11, in step S12, the transaction program 12 for one month ago is executed in the same way as in step S11, and a snapshot (for one month ago) at the end of the current month one month ago is acquired. Then, the molding program 32 using the snapshot (for one month ago) is executed.

[0069] After saving the snapshot in step S12, in step S13, the same processing as in steps S11 and S12 is executed for the current month. In this manner, the transaction program 12 and snapshot acquisition in the on-premise resource 1 and the forming program 32 in the cloud resource are executed sequentially and in parallel in monthly units from (N+1) months ago to the current month.

[0070] (Data held in the first storage system 100 according to the embodiment) 11 is a diagram illustrating data held in the memory 115 in the first storage system 100 according to the embodiment. The memory 115 includes a control information unit 140, a program unit 150, and a cache unit 160.

[0071] The control information section 140 includes flags and addresses for performing storage control. The program section 150 stores storage control contents as software. The program section 150 includes a volume management program 151, a read / write program 152, a snapshot program 153, and a first prefetch program 154, the details of which will be described later.

[0072] The cache unit 160 improves I / O performance by temporarily storing I / O data from a host (not shown) to the first storage system 100. The cache unit 160 is a cache memory of a general storage system.

[0073] The pool management table 143 in the control information unit 140 is a table that uses physical addresses as indexes and is made up of data with a width of 1 bit or more, and for example, if the target physical address is unallocated, it is set to "0", and if it is allocated, it is set to "1". By referring to the pool management table 143, it can be determined whether a physical address in the SSD 120 has been allocated or not.

[0074] (Volume Management Table 141 According to the Embodiment) Fig. 12 is a diagram illustrating a volume management table 141 according to an embodiment. The volume management table 141 has columns for a volume ID 1411, a logical capacity 1412, an allocation amount 1413, a volume type 1414, and an allocation threshold 1415. The volume ID 1411 is information for identifying a volume in the first storage system 100. The logical capacity 1412 is the logical capacity of the volume identified by the volume ID 1411. The allocation amount 1413 is the amount of data actually allocated to the volume identified by the volume ID 1411. The volume type 1414 indicates the type of volume identified by the volume ID 1411. The allocation threshold 1415 will be described later.

[0075] The volume type 1414 indicates at least three types of volume. The first volume type is a "standard volume" which is a normal volume and means a logical volume 130 (FIG. 3). A standard volume is a normal volume whose creation is instructed by the APP / DB server 10 or the management server 20. The second volume type is a "snapshot volume" which is a snapshot 133, 134 (FIG. 3). The third volume type is a "virtual volume" which is a virtual volume 330 (FIG. 3).

[0076] In this way, multiple different volumes are formed within the storage according to the volume type 1414. In addition, the allocation threshold 1415 is defined only when the volume type is a virtual volume. This is the data capacity actually allocated within the volume. For example, if the logical capacity 1412 is 300 GB and the allocation threshold 1415 is 100 GB, this means that only 100 GB of the 300 GB logical capacity is allocated to the virtual volume 330.

[0077] In this embodiment, these three volume types will be described, but other volume types may also exist.

[0078] (Logical-Physical Conversion Table 142 According to the Embodiment) 13 is a diagram illustrating a logical-physical conversion table 142 according to an embodiment. The logical-physical conversion table 142 includes a logical address 1421 and a physical address 1422. The logical-physical conversion table 142 is used for mapping by the mapping unit 131, and links logical blocks with physical blocks. The logical-physical conversion table 142 is created for each of the volume IDs 1411 (FIG. 13) described above. Note that holding an unallocated state (INVALID), such as FFFFFFFF, in the physical address indicates that the target logical address is unallocated.

[0079] The pool management table 143 will now be described. The pool management table 143 is a table that uses physical addresses as indexes and is made up of data with a width of 1 bit or more. The pool management table 143 is a table that can determine whether a physical address in the SSD 120 has been allocated or not, for example, by setting "0" if the target physical address is unallocated and "1" if it has been allocated.

[0080] Next, a description will be given of the program section 150. The program section 150, in which storage control contents are written as software, is configured to include a plurality of programs.

[0081] When the management server 20 instructs the volume management program 151 to create a new volume, the volume management program 151 adds the new volume to the volume management table 141. When adding a new volume, the volume management program 151 sets the instructed logical capacity in the logical capacity 1412, sets "0" in the allocation amount 1413, and sets the instructed volume type 1414.

[0082] The read / write program 152 performs I / O control in accordance with read and write I / Os issued by the APP / DB servers 10 and 30 .

[0083] When a write command is issued to a logical block in the initial state (when the physical address 1422 of the logical-physical conversion table 142 is in an invalid state), the read / write program 152 first refers to the pool management table 143. Then, the read / write program 152 selects an unallocated physical block in the SSD 120 and links the logical block number to the physical block using the logical-physical conversion table 142 (validating the physical block).

[0084] Next, the read / write program 152 stores data in the target physical block. When a read command is issued to a logical block, if the target physical block is valid, the read / write program 152 returns the data stored in the target physical block to the APP / DB server 10 or APP / DB server 30.

[0085] If the target physical block is invalid (no data is stored), the read / write program 152 executes processing that differs depending on the volume type. If the volume type is a standard volume or snapshot volume, the read / write program 152 returns an error response to the APP / DB server 10, 30 because the access block is originally invalid data.

[0086] On the other hand, if the volume type is a virtual volume, the read / write program 152 fetches data from the first storage system 100 and stores the data in the virtual volume 330. At the same time, the read / write program 152 returns the target data to the APP / DB server 10 or APP / DB server 30. In this way, the read / write program 152 controls standard I / O processing.

[0087] When instructed by the APP / DB server 10 or the management server 20 to create a snapshot of a specified volume, the snapshot program 153 adds a snapshot volume to the volume management table 141. There are two methods for creating a snapshot: one is to copy the data itself and the logical-physical conversion table 142, and the other is to copy only the logical-physical conversion table 142, but either method may be used.

[0088] The first prefetch program 154 is a program that detects the difference between two snapshots and transfers the difference to the second storage system 300. For example, the difference between snapshot (generation 1) 133 and snapshot (generation 2) 134 in Fig. 3 is logical block B. The first prefetch program 154 transfers logical block B to the second storage system 300 as difference data.

[0089] Here, differential data will be explained using Figures 3 and 4. In Figure 3, snapshot (generation 1) 133 stores a snapshot as of the end of last month, and snapshot (generation 2) 134 stores a snapshot as of the end of this month. In Figure 4, differential data in this case refers to the history data added over the course of one month (history data for this month's order dates of 2 / 1, 2 / 2, and 2 / 3) and the updated parts of the history data and master data (customer information A0 and A4, supplier information C1 and C4).

[0090] (Data held in the second storage system 300 according to the embodiment) FIG. 14 is a diagram illustrating data held in the memory 115 in the second storage system 300 according to the embodiment.

[0091] In addition to the tables in the control information unit 140 of the first storage system described above, the control information unit 170 includes an access history table 174 (FIG. 15) described below, and a discard entry list 178 which is a list of data entries to be discarded from the virtual volume.

[0092] The program unit 180 is a processing program for the second storage system 300. The program unit 180 stores a volume management program 151, a read / write program 152, and a second prefetch program 184, which will be described later. The program unit 180 also stores an access history acquisition program 185, a virtual volume discard entry estimation program 186, and a data discard program 187.

[0093] The cache unit 160 has the same functions as the cache unit 160 of the first storage system 100 .

[0094] (Access History Table 174 according to the embodiment) FIG. 15 is a diagram illustrating the access history table 174 according to the embodiment.

[0095] The access history table 174 is a table indicating whether or not the APP / DB server 30 has accessed a specific area of the virtual volume 330. It is time-series data in units of batch processing executed by the APP / DB server 30 for a predetermined period (for example, one month).

[0096] In this embodiment, for ease of explanation, the unit of access area is assumed to be the logical block size (8 KB in Linux (registered trademark) and the like). As shown in Fig. 15, the access history table 174 is set to "0" by default, indicating that no access has been made, and when the target block has been accessed, "1" is set, indicating that access has been made. The access history table 174 has multiple sets.

[0097] (State transition of the access history table 174 according to the embodiment) FIG. 16 is a diagram for explaining the state transition of the access history table 174 according to the embodiment.

[0098] First, when the management server 20 issues an instruction to generate an access history table 174 in the IDLE state (S1850), the access history acquisition program 185 transitions to an access history table generation state (S1851). In the access history table generation state, the access history acquisition program 185 generates a new access history table 174 to which a unique table identifier has been assigned. The new access history table 174 is set to "0", indicating the initial state (unaccessed). The access history acquisition program 185 also returns the table identifier assigned to the new access history table 174 to the management server 20. Thereafter, the access history acquisition program 185 transitions to an access history acquisition state (S1853).

[0099] Alternatively, when the access history acquisition program 185 is in the IDLE state (S1850), and an instruction to load the access history table 174 (with a table identifier assigned) is issued from the management server 20, the access history acquisition program 185 transitions to an access history table loaded state (S1852). In the access history table loaded state, the access history acquisition program 185 loads the access history table 174 corresponding to the table identifier, and transitions to an access history acquisition state (S1853).

[0100] In the access history acquisition state (S1853), each time the virtual volume 330 is accessed by the APP / DB server 30, the access history acquisition program 185 sets a table value of "1" to the corresponding logical block in the access history table 174. Here, the access history table 174 to which the table value "1" is set is the one generated in S1851 or loaded in S1852.

[0101] In the access history acquisition state (S1853), the access history acquisition program 185 transitions to an access history table save state (S1854) when a save instruction is issued from the management server 20. In the access history table save state (S1854), the access history acquisition program 185 saves the pair of the current table identifier and the access history table 174, and transitions to an end state (S1855).

[0102] In this manner, this embodiment is a method that can store multiple sets of access history for a specific period in response to an instruction from the management server 20. The function related to the multiple sets of access history table 174 is processed by the access history acquisition program 185 in the program unit 180.

[0103] Next, we will explain the other programs of the second storage system 300. The second prefetch program 184 executes processing that is paired with the first prefetch program 154 processed in the first storage system 100. The second prefetch program 184 allocates transfer data transferred by the first prefetch program 154 to the virtual volume 330.

[0104] As mentioned in the explanation of the first prefetch program 154, the transfer data is differential data, which is history data added during one month and updated portions of the history data and master data.

[0105] (Operation of the virtual volume discard entry estimation program 186 according to the embodiment) FIG. 17 is a diagram showing an example of the operation of the virtual volume discard entry estimation program 186 related to the embodiment.

[0106] As shown in the explanation of the access history table 174 in Figures 15 and 16, the access history table 174 can store multiple sets acquired at multiple execution timings (for example, in the case of a monthly batch, three execution timings: two months ago, one month ago, and this month). Therefore, the virtual volume discard entry estimation program 186 executes sequential / random estimation 175 on the access history table (for two months ago) 174A, the access history table (for one month ago) 174B, and the access history table (for this month) 174C. The virtual volume discard entry estimation program 186 then generates estimation results 176A, 176B, and 176C of the sequential / random estimation 175. The sequential / random estimation 175 will be described in detail later.

[0107] The access history table (for two months ago) 174A is an example of a third access history. The access history table (for one month ago) 174B is an example of a second access history. The access history table (for this month) 174C is an example of a first access history.

[0108] Here, the access history table (two months ago) 174A was acquired two months ago. The access history table (one month ago) 174B was acquired one month ago. The access history table (this month) 174C was acquired after the latest molding program 32 for this month was executed.

[0109] The virtual volume discard entry estimation program 186 receives the estimation results 176A, 176B, and 176C as input, executes history data / master data estimation 177, which will be described later, and generates a discard entry list 178, which is a list of data entries to be discarded from the virtual volume.

[0110] Finally, the virtual volume discard entry estimation program 186 discards the data listed in the discard entry list 178 from the virtual volume 330 in the virtual volume data discard process 179 and deletes the entry of the discarded data from the discard entry list 178.

[0111] (Continuous / Random Estimation 175 according to an embodiment) FIG. 18 is a diagram for explaining the processing function of the continuous / random estimation 175 (FIG. 17) according to the embodiment.

[0112] Table 175T in FIG. 18 is information for estimating the state of logical block N based on the access status of logical block N (logical block N) and logical block N+1 (logical block N+1).

[0113] Logical block N and logical block N+1 in table 175T indicate the values (unaccessed or accessed) of logical block N and logical block N+1 stored in access history table 174. The combination of these values indicates the state of logical block N. For example, if the values of logical block N and logical block N+1 are both "unaccessed," this indicates that at least logical block N is estimated to be an "unaccessed block." In this case, the estimation result of continuous / random estimation 175 is that the access type is an unaccessed block (no access). "Unaccessed block" indicates that the area type is an unaccessed area.

[0114] Furthermore, if logical block N is "unaccessed" and logical block N+1 is "accessed," logical block N is a block that has not been accessed even though it is in a random access area, and as a result is estimated to be a "random block." Similarly, if logical block N is "accessed" and logical block N+1 is "unaccessed," it is also estimated to be a "random block." In this case, the estimation result of continuous / random estimation 175 is that the access type is a random block (random access). "Random block" indicates that the area type is a random access area.

[0115] Furthermore, if both logical block N and logical block N+1 are "accessed," it is estimated that at least logical block N was accessed as a "contiguous block." In this case, the estimation result of contiguous / random estimation 175 is that the access type is "contiguous block (contiguous access)." "Contiguous block" indicates that the area type is a contiguous access area.

[0116] The virtual volume discard entry estimation program 186 performs these estimations for all the access areas in the access history table 174 and outputs the estimation results 176 .

[0117] (Historical data / master data estimation 177 according to the embodiment) FIG. 19 is a diagram for explaining the function of the history data / master data estimation 177 according to the embodiment.

[0118] Table 177T shown in Fig. 19 is information for estimating whether the target block is history data or master data in the database for the input combination of estimation results 176A, 176B, and 176C. Note that the input combination that is the basis for estimation takes into account the access characteristics of the history data and master data shown in Fig. 9.

[0119] There are a total of 27 input combinations for the estimation results 176A, 176B, and 176C. For example, if the estimation results 176A, 176B, and 176C are all "random blocks," referring to FIG. 9, it can be seen that this is a characteristic of master data with an index (master data (b) in FIG. 9). Therefore, it is determined to be "master data."

[0120] For example, if the estimation results 176A, 176B, and 176C are all "continuous blocks," referring to Figure 9, it can be seen that this is a feature of master data without an index (master data (c) in Figure 9). Therefore, it is determined to be "master data."

[0121] In this way, most of the combinations can be estimated as master data.

[0122] On the other hand, a case where the data cannot be determined as master data will be described.

[0123] If the estimation results 176A, 176B, and 176C are all "unaccessed blocks," it can be determined that they are "history data from three months ago" (corresponding to (condition A) in (a) of Figure 9) or "old master data" (corresponding to (d) in Figure 9). Therefore, it can be determined that they were at least "unaccessed," but it is not possible to determine whether they are history data or master data. Here, both "history data from three months ago" and "old master data" are data that are unlikely to be referenced in the molding program 32 for the next month.

[0124] Next, suppose that the estimation result 176A from two months ago was "continuous block," the estimation result 176B from one month ago was "unaccessed," and the estimation result 176C from this month was "unaccessed." In this case, there is a possibility that it is "history data from two months ago" (corresponding to (condition B) of (a) in Figure 9) or "master data" (corresponding to (c) in Figure 9 for two months ago, and (d) for one month ago and this month).

[0125] Also, suppose that the estimated result 176A from two months ago was "not accessed," the estimated result 176B from one month ago was "continuously accessed," and the estimated result 176C from this month was "not accessed." In this case, there is a possibility that the data is "history data from one month ago" (corresponding to (a) (condition C) in Figure 9) or "master data" (corresponding to (d) in Figure 9 for two months ago and this month, and (c) for one month ago).

[0126] Also, suppose that the estimation result 176A from two months ago and the estimation result 176B from one month ago were "not accessed," and the estimation result 176C from this month was "continuously accessed." In this case, it is possible that the data is "this month's history data" (corresponding to (a) (condition D) in Figure 9) or "master data added this month" (corresponding to (d) in Figure 9 for two months ago and one month ago, and (c) for this month).

[0127] Finally, if any one of the estimation result 176A from two months ago, the estimation result 176B from one month ago, and the estimation result 176C of the current month is random access, it may be consecutive access or no access in other months. Therefore, if there is even one random access, it can be classified as master data (b) in Figure 9.

[0128] In this embodiment, the data to be discarded from the virtual volume 330 are (Condition A) historical data from three months ago, (Condition B) historical data from two months ago, (Condition C) historical data from one month ago, and (Condition D) unreferenced master data (random data with no access). Historical data from one month ago is past data corresponding to the period one chronologically before the historical data of this month, which is the latest data. Historical data from two months ago is past data corresponding to the period one chronologically before the historical data of one month ago, and corresponding to the period two chronologically before the historical data of this month. Historical data from three months ago is past data corresponding to the period one chronologically before the historical data of two months ago, corresponding to the period two chronologically before the historical data of one month ago, and corresponding to the period three chronologically before the historical data of this month.

[0129] Therefore, if the estimation results of the historical data and master data contain data that meets any of these conditions, it will be discarded even if there is a possibility that it is other data. In other words, data that may meet (Condition A), (Condition B), (Condition C), or (Condition D) will be discarded.

[0130] When discarded data is estimated to possibly fall under (condition A), (condition B), (condition C), or (condition D), the logical block numbers that fall under each condition are listed and saved as a discard entry list 178.

[0131] (Virtual Volume Data Discarding Process According to the Embodiment) FIG. 20 is a flowchart showing the virtual volume data discarding process according to the embodiment.

[0132] First, in step S1870, the data discarding program 187 calculates the free space in the virtual volume 330. In the virtual volume data discarding process, the data discarding program 187 can calculate this by comparing the allocation threshold 1415 shown in the volume management table 141 with the actual allocation amount 1413.

[0133] Next, in step S1871, the data discarding program 187 determines whether further free space needs to be secured based on the actual virtual volume allocation amount 1413 and free space. If free space needs to be secured (step S1871 Yes), the data discarding program 187 moves the process to step S1872. On the other hand, if free space does not need to be secured (step S1871 No), the data discarding program 187 ends the virtual volume data discarding process.

[0134] In step S1872, the data discarding program 187 selects a discarding entry in descending order of priority when there are multiple discarding entries (discarded data) in the discarding entry list 178. That is, in step S1872, the data discarding program 187 searches the discarding entry list 178 and first selects a discarding entry in the order of priority, with (condition A) being the highest priority, followed by (condition B), (condition C), and (condition D).

[0135] Next, in step S1873, the data discarding program 187 discards the discard entry selected in step S1872 from the virtual volume 330, and deletes it from the discard entry list 178. When step S1873 ends, the data discarding program 187 returns the process to step S1870. The data discarding program 187 repeats the processes of steps S1870 to S1873 until sufficient free space is created in the virtual volume 330 (step S1871 No).

[0136] Regarding the priority of (Condition A), (Condition B), (Condition C), and (Condition D), the above explanation has been given with fixed priorities, but the priorities may be changed according to the user's needs or may be dynamic.

[0137] (Sequence related to execution of molding program 32 according to the embodiment) 21 is a diagram illustrating a sequence related to the execution of the forming program 32 according to the embodiment. As shown in FIG. 10, when the execution of the forming program 32 starts, the snapshot for the current month is confirmed in the on-premise resource 1.

[0138] First, in step S1901, the management server 20 sends a prefetch command to the first storage system 100. Next, in step S1902, the first storage system 100 uses the first prefetch program 154 to send to the second storage system 300 the history data added during the month and the update data of the history data and master data.

[0139] Next, in step S1903, the second storage system 300 executes the second prefetch program 184 and allocates the data transferred from the first storage system 100 in step S1902 to the virtual volume 330. Next, in step S1904, the first storage system 100 notifies the management server 20 that the prefetch process has ended, once the transmission of the update data to the second storage system 300 has been completed and the first prefetch program 154 has been completed.

[0140] Next, in step S1905, the management server 20 instructs the second storage system 300 to generate an access history table 174 (transition to steps S1851 and S1853 in FIG. 16). This determines the current access history table 174. Next, in step S1906, the second storage system 300 notifies the management server 20 that the current access history table 174 has been prepared.

[0141] Next, in step S1907, the management server 20 instructs the APP / DB server 30 to start the forming program 32. The APP / DB server 30 starts the forming program 32 in response to the instruction in step S1907. Next, in step S1908, the second storage system 300 acquires the access history to be stored in the access history table 174 while controlling I / O with the read / write program 152 and the access history acquisition program 185. Note that, for example, if step S1908 is batch processing, the access history stored in the access history table 174 will be time-series data in units of execution of batch processing.

[0142] Here, if the data targeted by the I / O issued by the APP / DB server 30 is not in the virtual volume 330 (if the data is invalid), the read / write program 152 fetches the targeted data from the first storage system 100. Then, the read / write program 152 stores it in the virtual volume 330. At this time, if the allocation capacity 1413 of the virtual volume 330 (the amount of data stored in the virtual volume 330) exceeds the allocation threshold 1415 and the virtual volume 330 is depleted, a discard entry is selected from the discard entry list 178 saved in the past. Then, the targeted entry is discarded. When the targeted entry is discarded, steps S1910 to S1913 are executed following step S1909, which will be described later.

[0143] In step S1909, when the molding program 32 ends, the APP / DB server 30 notifies the management server 20 of the end of the molding program 32.

[0144] Next, in step S1910, the management server 20 instructs the second storage system 300 to discard data in the virtual volume 330. Next, in step S1911, the second storage system 300 executes the virtual volume discard entry inference program 186 to infer data entries to be discarded from the virtual volume 330.

[0145] Next, in step S1912, the second storage system 300 executes the data discarding program 187, and discards the data entries that were estimated to be discarded in step S1911 from the virtual volume 330. Next, in step S1913, the second storage system 300 notifies the management server 20 that the discarding of the data entries in the virtual volume 330 has been completed.

[0146] In the above explanation, the access history acquisition program 185 acquires the access history to be stored in the access history table 174 in synchronization with I / O issued from the APP / DB server 30. This acquisition of the access history only needs to be completed before the virtual volume discard entry estimation program 186 is started. Therefore, the access history acquisition program 185 does not need to be completely synchronized with I / O, and can be executed asynchronously. In this case, the virtual volume discard entry estimation program 186 is started after the access history acquisition program 185 has finished.

[0147] (Modification of the embodiment) In the virtual volume discard entry estimation program 186 explained so far, random blocks and consecutive blocks are selected based on the logical block size in 8 KB units. Regarding the logical block size of 8 KB, by using a value larger than 8 KB, the capacity of the access history table 174 can be reduced. Therefore, a size at a level at which random blocks, consecutive blocks, etc. can be selected may be used as the management unit of the access history table 174.

[0148] In the embodiment, a method for estimating discard entries has been described using three months' worth of access history tables 174. The technical idea of this method is to generate an access history table 174 for each molding program 32 executed on a monthly basis, for example, and estimate discard entries from multiple access history tables 174.

[0149] For example, although last month's historical data is unlikely to be accessed this month, if typical access history management is used, it will be recognized as MRU (Most Recently Used), and will not be selected as a discarded entry in typical LRU-style management.

[0150] Therefore, in this embodiment, there are multiple access history tables 174 separated in chronological order, and there is a means for estimating discarded entries using the multiple access history tables 174. Here, if the goal is to achieve more accurate estimation, four or more sets (four months) of access history tables 174 may be used. In other words, there is no limit to the number of sets of access history tables 174 that are used.

[0151] Furthermore, in this embodiment, the data discarding program 187 is executed after the formation program 32 has finished (after step S1909 (FIG. 21)). For example, virtual volume data discarding may also be executed when the virtual volume 330 becomes depleted before or during execution of the second prefetch program 184 or the formation program 32. In this case, a previously created access history table 174 (for example, the latest access history table 174 created in the past or the access history table 174 currently being created) may be used to estimate and discard discard entries (discard data) for the virtual volume 330. The timing for estimating and discarding discard entries is set appropriately by the user.

[0152] In the above embodiment, the virtual volume discard entry estimation program 186 estimates discard entries (discard data) using the fixed determination means shown in the explanations of Figures 18 and 19. This fixed determination means differs depending on the application. Therefore, depending on the purpose of use of the virtual storage, an estimation algorithm may be used that inputs multiple access history tables 174 and outputs a discard entry estimation result different from that of this embodiment.

[0153] Furthermore, the processor 114 of the second storage system 300 may perform machine learning using a plurality of access history tables 174 and discarded entries (discarded data) as learning data. The processor 114 may then use this machine learning to generate a discarded entry estimation model that takes a plurality of access history tables 174 as input and outputs discarded entries. The processor 114 estimates discarded entries using this discarded entry estimation model. Furthermore, the processor 114 may update the discarded entry estimation model as needed as learning data accumulates.

[0154] (Effects of the embodiment) In this embodiment, by using the virtual volume 330 of the cloud-side resource 3, which has a smaller capacity than the logical volume 130 of the on-premise resource 1, it is possible to reduce the cloud storage capacity of the cloud-side resource 3 and reduce capacity charges. Furthermore, according to this embodiment, data transfer from the cloud-side resource 3 to the on-premise resource 1 is not required, which reduces network costs.

[0155] In this embodiment, the multiple access histories (access history tables 174A, 174B, 174C) are time-series data in units of, for example, batch execution. Therefore, when the secondary use of data on the APP / DB server 30 side is batch processing, data is discarded for each processing unit, so that data capacity can be managed efficiently according to the form of secondary use of data.

[0156] Furthermore, in this embodiment, it is determined that data in an access area that corresponds to an unaccessed area at a predetermined number of execution timings is to be discarded from the virtual volume. Furthermore, even if there is a history of access in the access history at the execution timings, it is determined that data in an access area that corresponds to an unaccessed area at a predetermined number of execution timings is to be discarded from the virtual volume. This predetermined number changes depending on the type of access when there is access. Furthermore, when the type of access is random access, this predetermined number for determining that data in an access area that corresponds to an unaccessed area at a predetermined number of execution timings is a larger value than when it is continuous access. In other words, the number of execution timings required to determine that an area is an unaccessed area is large. Therefore, data in an access area for random access can be controlled to be less likely to be discarded from the virtual volume compared to data in an access area for continuous access.

[0157] Furthermore, in this embodiment, priorities are set for discarded data in the order of (Condition A), (Condition B), (Condition C), and (Condition D), with data with higher priorities being discarded first. This minimizes the discarding of data with higher necessity, thereby reducing the waste of re-acquiring data and re-storing it in the virtual volume. Furthermore, data can be discarded appropriately according to user needs.

[0158] Furthermore, in this embodiment, necessary data that does not exist in the virtual volume 330 is acquired by transparently accessing the on-premises first storage system 100. Therefore, even if data necessary for processing related to secondary use of the APP / DB server 30 is discarded from the virtual volume 330, it can be reacquired and processing can be continued.

[0159] Furthermore, in this embodiment, when the data capacity of the virtual volume 330 exceeds a threshold, data to be discarded is estimated and discarded at any timing before, during, or after execution of processing related to secondary use of the APP / DB server 30. Therefore, an increase in the data capacity of the virtual volume 330 can be appropriately suppressed according to the needs of the user.

[0160] Furthermore, in this embodiment, differential data between snapshots is sent as update data from the on-premises first storage system 100 to the virtual volume 330 of the second storage system 300. Therefore, snapshots are used to efficiently send update data to the virtual volume 330, reducing pressure on the data capacity of the virtual volume 330.

[0161] In this embodiment, discarded data is estimated using a discard entry estimation model that is machine-learned from a plurality of access histories and discard entries. Therefore, a rule-based discard entry estimation based on Fig. 9, Fig. 18, and Fig. 19 is modeled, and discard entry estimation can be performed efficiently using the discard entry estimation model.

[0162] Although the embodiments of the present disclosure have been described above in detail, the present disclosure is not limited to the above-described embodiments and can be modified in various ways without departing from the spirit of the present disclosure. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present disclosure is not necessarily limited to those having all of the described configurations. Furthermore, some of the configurations of the above-described embodiments can be added to, deleted from, or replaced with other configurations.

[0163] Furthermore, the above-described configurations, functional units, processing units, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described configurations, functions, etc. may also be implemented in software by a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in memory, storage devices such as HDDs and SSDs, or recording media such as IC cards, SD cards, and DVDs.

[0164] In addition, in the above-mentioned drawings, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily show all the control lines and information lines that are actually implemented. For example, it may be considered that almost all components are actually connected to each other.

[0165] The above-described arrangement of the processing functions and data is merely an example, and the arrangement of the processing functions and data can be changed to an optimal arrangement in terms of the performance of the hardware and software, processing efficiency, communication efficiency, etc. [Explanation of symbols]

[0166] 1: On-premise resources, 3: Cloud resources, 10, 30: APP / DB servers, 11, 21, 31, 40: Network, 12: Transaction program, 20: Management server, 32: Forming program, 100: First storage system, 300: Second storage system, 130: Logical volume, 330: Virtual volume.

Claims

1. A computer system having a first storage system located at a first base and providing a logical volume to a first server, and a second storage system located at a second base and connected to the first storage system via a network, the first storage system includes a first processor and a memory; the second storage system has a second processor and a memory; The first processor storing data relating to the execution of the first server in the logical volume; transmitting the data stored in the logical volume to the second storage system; The second processor providing a virtual volume to a second server by the second storage system; storing the data received from the first processor in the virtual volume; Executes a process using the data stored in the virtual volume at each execution timing; determining whether to leave the data stored in the virtual volume in the virtual volume or discard it based on the presence or absence of access and the type of access, which are the access status of the data at each execution timing; The data determined to be discarded is discarded from the virtual volume. A computer system comprising:

2. 2. The computer system of claim 1, The second processor A determination is made as to whether the data is to be left in the virtual volume or discarded based on the presence or absence of access to the data at each of the plurality of execution timings and the type of access. A computer system comprising:

3. 3. The computer system according to claim 2, the data is stored for each access area of the virtual volume, The second processor determining whether the type of access corresponds to a sequential access or a random access for each of the access areas; Based on the presence or absence of the access for each of the access areas and the type of the access, it is determined whether the data should be left in the virtual volume or discarded. A computer system comprising:

4. 4. The computer system according to claim 3, The processing is a batch processing for each execution timing. A computer system comprising:

5. 5. The computer system of claim 4, The second processor recording, as an access history, access states for each access area of the data when the batch processing is executed at each of the plurality of execution timings; Based on the access history at a plurality of execution timings in succession in time series, it is determined whether the data should be left in the virtual volume or discarded. A computer system comprising:

6. 6. The computer system according to claim 5, The second processor It is determined that the data in the access area that corresponds to an unaccessed area for a predetermined number of the execution timings is to be discarded from the virtual volume. A computer system comprising:

7. 7. The computer system of claim 6, The second processor determining that the data in the access area corresponding to the unaccessed area at the predetermined number of execution times is to be discarded from the virtual volume even if there is an access history in the access history at the execution times; the predetermined number varies depending on the type of access when the access occurs, When the type of access is the random access, the predetermined number for determining that the data in the access area corresponding to the unaccessed area is to be discarded from the virtual volume at the predetermined number of execution timings is a larger value than when the type of access is the consecutive access. A computer system comprising:

8. 2. The computer system of claim 1, The second processor When the target data requested for access by the second server is determined to be discarded and is discarded from the virtual volume and does not exist, the target data is acquired from the logical volume of the first storage system and stored in the virtual volume. A computer system comprising:

9. 2. The computer system of claim 1, The second processor When the amount of data stored in the virtual volume exceeds a threshold, it is determined whether the data stored in the virtual volume should be left in the virtual volume or discarded. A computer system comprising:

10. 2. The computer system of claim 1, The first processor generating snapshots of the data at predetermined intervals; The second processor The differential data between successive snapshots taken for each predetermined period is acquired as the data for each predetermined period. A computer system comprising:

11. 6. The computer system according to claim 5, The second processor generating a discard entry estimation model that uses the access history for each of the plurality of execution timings and the data determined to be discarded based on the access history as learning data, and that inputs the access history for each of the plurality of execution timings and outputs the data to be discarded; The data to be discarded is determined based on the output of the discard entry estimation model obtained by inputting the access history for each of the plurality of execution timings into the discard entry estimation model. A computer system comprising:

12. A data management method for a storage system executed by a computer system having a first storage system arranged at a first base and providing a logical volume to a first server, and a second storage system arranged at a second base and connected to the first storage system via a network, the method comprising: the first storage system includes a first processor and a memory; the second storage system has a second processor and a memory; The first processor: storing data relating to the execution of the first server in the logical volume; transmitting the data stored in the logical volume to the second storage system; The second processor: providing a virtual volume to a second server by the second storage system; storing the data received from the first processor in the virtual volume; Executes a process using the data stored in the virtual volume at each execution timing; determining whether to leave the data stored in the virtual volume in the virtual volume or discard it based on the presence or absence of access and the type of access, which are the access status of the data at each execution timing; The data determined to be discarded is discarded from the virtual volume. A data management method characterized by comprising each process.

Images