WO2014203397A1

WO2014203397A1 - Computer system, metadata management method, and program

Info

Publication number: WO2014203397A1
Application number: PCT/JP2013/067099
Authority: WO
Inventors: 陽介石井; 児玉　昇司
Original assignee: 株式会社日立製作所
Priority date: 2013-06-21
Filing date: 2013-06-21
Publication date: 2014-12-24

Abstract

A computer system provided with a plurality of computers, each of which comprises a buffer for temporarily storing a file received from an external device and a data storage area for storing the file and further comprises a file management unit, a file access control unit, and a metadata generation unit, wherein the metadata generation unit obtains operation information indicating the operation state of a computer when the computer received a file, determines, on the basis of the operation information, whether to generate a metadata file, and if it is determined that a metadata file should be generated, then the metadata generation unit obtains metadata from the file, stored in the buffer, generates a metadata file on the basis of the obtained metadata, stores the metadata file in the data storage area, and adds information for accessing the file to the metadata file stored in the data storage area.

Description

Computer system, metadata management method and program

The present invention relates to a computer system using hierarchical storage.

In recent years, the number of data stored in computer systems has increased. When managing a large amount of data, there is a problem that the location where the data requested by the user is stored is unknown. Search services such as full-text search and metadata search are used to solve the above-described problems.

In full text search, the search server analyzes the text of the data stored in the computer system and generates a search index in advance. The user can transmit a search query for searching the acquisition target data to the search server and access the acquisition target data based on the search result output from the search server.

In the metadata search, the search server extracts data including a combination of the metadata name and metadata value included in the search target data, and generates a search index for the data extracted in advance. A user can acquire a search result by designating search conditions regarding the metadata name and metadata value to the search server.

In the future, the number of data stored in the computer system may increase further, making it difficult for the user himself to grasp the type, contents, storage location, etc. of the file stored. For this reason, the search service as described above is an important service for the user, and its use is considered to be further expanded. In particular, the metadata search can be used not only for simple data search but also for data analysis by executing statistical processing or the like on data that matches the search condition.

Generally, management cost increases as the number and size of stored data increases. As a method for reducing the management cost, for example, a technique described in Patent Document 1 is known. Patent Document 1 discloses a storage system that virtually reduces the management cost per capacity by combining an expensive and high-performance upper tier storage and an inexpensive and low-performance lower tier storage. That is, a hierarchical storage technology is described.

In hierarchical storage, the hierarchical control server stores files in appropriate storage based on the usage status of the stored files. In the tiered storage, it is possible to construct a system configuration in which the upper tier storage is installed at each site used by the user and the lower tier storage is installed in the data center. By constructing the system having the above-described system configuration, it is possible to collect data generated at each site on the data center side using the function of the hierarchical storage.

In addition, by introducing a search server that indexes data aggregated on the data center side, integrated search of data generated at each site becomes possible. When performing an integrated search, it is necessary to reliably transfer data to the data center side even in a system environment where a large amount of search target data is generated. For example, in Patent Document 2, when data requested to be transferred is temporarily stored in a buffer, stop and restart of data transfer are stopped by making a determination using a threshold value. A method is disclosed.

US Pat. No. 5,764,972 US Pat. No. 6,101,575

In a system environment that aggregates data to the data center side using tiered storage and provides a search service for the data, there is a problem with data transfer. In other words, when the amount of data generated at each site becomes enormous, there is a problem that it is difficult to transfer the data to the data center side so that the data is not lost and the data transfer is not delayed. .

For example, consider a case where, in the upper tier storage at each base, metadata of the data is generated for the stored data, the data and metadata are associated, and transferred to the lower tier storage on the data center side. . At this time, if the number and size of data to be transferred is enormous, before the data is transferred from the upper tier storage to the lower tier storage, the buffer for temporarily storing the data overflows and a new Data may not be accepted. In particular, when the network bandwidth connecting the upper tier storage and the lower tier storage is narrow, the above-described problem becomes apparent.

When comparing the size of the data to be transferred and the size of the metadata generated from the data, the size of the metadata is relatively small. In particular, when the data is high-resolution moving image data or the like, since the size of the data itself is large, the tendency of the metadata size to become smaller than the data size becomes significant. On the other hand, when providing an integrated search service on the data center side, it is beneficial to be able to provide a metadata search service.

However, if the buffer usage increases from a plurality of data, the data reception process is stopped, so that the data necessary for the metadata search service cannot be acquired. In addition, the control for preferentially transferring metadata to the lower-level storage on the data center side has been difficult to realize with the above-described conventional technology. For this reason, the realization of the control for reliably transferring the data corresponding to the metadata from the transfer target data becomes an issue.

A typical example of the invention disclosed in the present application is as follows. That is, a computer system comprising a plurality of computers, each of the plurality of computers having a processor, a main storage device, a secondary storage device, and an interface for communicating with other computers, and at least one or more The computer includes a buffer for temporarily storing a file received from an external device connected via the interface, a data storage area for storing the file, a file management unit for managing the file, and access to the file A file access control unit that controls the metadata, and a metadata generation unit that acquires metadata by analyzing the file and generates a metadata file using the acquired metadata. The generation unit acquires operating information indicating an operating state of the computer that has received the file, Whether to generate the metadata file is determined based on the acquired operation information, and if it is determined to generate the metadata file, the metadata is acquired from the file stored in the buffer And generating the metadata file based on the acquired metadata, storing the generated metadata file in the data storage area, and storing the generated metadata file in the metadata storage area. Information for accessing the file is added.

According to one aspect of the present invention, file metadata can be retained according to the operation information of the computer that has received the file. Further, since information for accessing the file is added to the metadata file, the file and the metadata file can be managed in association with each other.

Issues, configurations, and effects other than those described above will be clarified by the following description of the embodiments.

It is explanatory drawing which shows the outline | summary of a process of the computer system of Example 1 of this invention. It is a block diagram explaining the structural example of the computer system of Example 1 of this invention. It is explanatory drawing which shows the structural example of the hierarchical storage structure management table in Example 1 of this invention. It is explanatory drawing which shows the structural example of the movement condition management table | surface in Example 1 of this invention. It is explanatory drawing which shows the structural example of the file corresponding | compatible management table in Example 1 of this invention. It is explanatory drawing which shows the structural example of the operation management table | surface in Example 1 of this invention. It is explanatory drawing which shows the structural example of the storage file management table in Example 1 of this invention. It is explanatory drawing which shows the structural example of the file movement management table | surface in Example 1 of this invention. It is explanatory drawing which shows the structural example of the back end storage file management table in Example 1 of this invention. It is a flowchart explaining the metadata extraction process in the Example of this invention. It is a flowchart explaining the metadata extraction process in the Example of this invention. It is a flowchart explaining the selection process of the movement candidate file of Example 1 of this invention. It is a flowchart explaining the file movement process of Example 1 of this invention. It is a flowchart explaining the file access process of Example 1 of this invention. It is explanatory drawing which shows an example of the data structure of the metadata file of Example 1 of this invention. It is explanatory drawing which shows an example of the file list screen used in Example 1 of this invention. It is a block diagram explaining the structural example of the computer system of Example 2 of this invention. It is explanatory drawing which shows the structural example of the name space management table in Example 2 of this invention. It is a flowchart explaining the file movement process of Example 2 of this invention. It is a flowchart explaining the file movement process of Example 2 of this invention. It is a flowchart explaining the file access process of Example 2 of this invention. It is explanatory drawing which shows the structural example of the operation management table | surface in Example 3 of this invention. It is explanatory drawing which shows the structural example of the movement condition management table | surface in Example 3 of this invention. It is explanatory drawing which shows the structural example of the movement condition management table | surface in Example 3 of this invention. It is a flowchart explaining the selection process of the movement candidate file in Example 3 of this invention. It is a flowchart explaining the selection process of the movement candidate file in Example 3 of this invention.

Hereinafter, details of an embodiment for carrying out the present invention will be described with reference to the drawings.

[Example 1]

First, the outline of the processing of the computer system to which the present invention is applied will be described with reference to FIG.

FIG. 1 is an explanatory diagram showing an outline of processing of the computer system according to the first embodiment of this invention.

The computer system according to the first embodiment includes a front-end file server 1, a back-end file server A (2-1), a back-end file server B (2-2), a data source 4, and a client 5. Each device is connected via a network 6 so that data communication is possible. In the following description, when the back-end file server A (2-1) and the back-end file server B (2-2) are not distinguished, they are also referred to as the back-end file server 2. Further, when the front-end file server 1 and the back-end file server 2 are not distinguished, they are also described as file servers.

The front-end file server 1 provides a file storage service and a file sharing service.

The front end file server 1, the back end file server A (2-1), and the back end file server B (2-2) constitute a hierarchical storage. In this embodiment, the front-end file server 1 is a higher-level storage and provides a virtual large-capacity file server to the user. The back-end file server 2 is a lower-level storage, and stores a part of data stored in the front-end file server 1.

In this embodiment, “Tier0” is set as the management hierarchy of the front-end file server 1, “Tier1” is set as the management hierarchy of the back-end file server A (2-1), and the back-end file server B (2- It is assumed that “Tier2” is set as the management hierarchy of 2).

When the capacity of the storage area is insufficient, the front-end file server 1 determines that the back-end file server A (2-1) is based on a predetermined policy such as file access frequency or elapsed time after file update. Move the file. When a file access request for the file is received from the user after the file is moved, the front-end file server 1 acquires the file from the back-end file server A (2-1), and responds with the file acquired by the user. Send as.

Note that the hierarchical storage configuration may be a multi-stage configuration. For example, the back end file server B (2-2) may be included. When the front-end file server 1 moves the file to the back-end file server A (2-1), if the storage capacity of the back-end file server A (2-1) is insufficient, the back-end file server A (2 It may be controlled to move a part of the file stored in -1) to the back-end file server B (2-2). When the back-end file server A (2-1) is overloaded, the front-end file server 1 controls to select the back-end file server B (2-2) as the file transfer destination. May be.

Data source 4 is a device that generates data to be stored. As the data source 4, for example, an electronic medical record server that registers electronic medical record information and manages the electronic medical record information, and a monitoring server that accumulates video data for monitoring recorded using a monitoring camera can be considered.

The front-end file server 1 stores various data generated by the data source 4 as file format data. The front-end file server 1 manages data so that a plurality of clients 5 can access the data and share the data.

The front-end file server 1 also stores metadata extracted from stored data and manages it as sharable data. Examples of metadata include a patient ID for patient identification included in the electronic medical record data, identification information of a person shown in the moving image specified based on a person image included in the moving image data, and the like.

Further, the computer system of this embodiment may include a search server (not shown). In this case, the search server generates a search index by indexing the file and metadata in order to search for data and metadata extracted from the data. The function of the search server may be realized using the front-end file server 1 or the back-end file server 2, or may be realized using another server (not shown).

In the computer system, the front end file server 1 and the data source 4 may be constructed in the user side base, and the back end file server 2 may be constructed in the data center. In the configuration described above, data and metadata extracted from the data can be managed using a hierarchical storage.

In order to efficiently use the data generated by the data source 4 on the user side, it is necessary to be able to search for data using the extracted metadata. In particular, when there are a plurality of user sides, enabling search processing using metadata on each user side contributes to improving the convenience of data utilization. Therefore, it is desirable to store the metadata in the back-end file server 2 on the data center side accessible from each user side.

The present invention implements control so that metadata can be reliably transferred between file servers for the reasons described above. The present invention is not limited to file storage but can be applied to block storage. Further, the present invention is not limited to a file server, but can be applied to a storage system that stores files.

Although the storage system configuration is not shown, the storage system includes a controller having a CPU and a memory, an I / F, and an auxiliary storage device.

Hereinafter, the operation of the present invention will be described according to the processing procedure.

In this embodiment, it is assumed that the front-end file server 1 receives a file to be stored from the data source 4. In the following description, the file to be stored is also referred to as an actual data file 180.

The front end file server 1 temporarily stores the actual data file 180 in the data reception buffer 160 on the memory. The front-end file server 1 is not limited to a mode of receiving a file from an external device, but may be a mode of acquiring the actual data file 180 by transmitting a file acquisition request to the external device.

In step S1, the metadata generation unit 120 (see FIG. 2) of the front-end file server 1 extracts metadata from the actual data file 180 stored in the data reception buffer 160. The metadata generation unit 120 stores the extracted metadata in the data storage area 170 on the auxiliary storage device 13 as file format data. At this time, the metadata generation unit 120 also stores the actual data file 180 in the data storage area 170.

In the following description, file format metadata is also referred to as a metadata file 181. In this embodiment, data including at least one of the actual data file 180 and the metadata file 181 is described as a file.

The metadata generation unit 120 stores the correspondence between the actual data file 180 and the metadata file 181 in the file correspondence management table 152, and stores information on the storage locations of the actual data file 180 and the metadata file 181 in the storage file management table 154. To store. In addition, the metadata generation unit 120 stores, in the operation management table 153, information related to the remaining capacity of the data storage area 170 that has changed with the storage of the file in the data storage area 170.

In step S2, the file movement control unit 130 (see FIG. 2) of the front-end file server 1 selects a movement candidate file from the files stored in the data storage area 170. Specifically, the following processing is executed.

The file movement control unit 130 acquires the operation information of the front end file server 1 from the operation management table 153. The file movement control unit 130 refers to the movement condition management table 151, collates the acquired operation information with the registered movement condition, and determines the processing content of the movement process.

Thereafter, the file movement control unit 130 refers to the storage file management table 154 based on the determined processing contents of the movement process, and selects a file to be moved from among the files stored in the data storage area 170. The file movement control unit 130 stores the information of the selected file in the file movement management table 155.

At this time, the file migration control unit 130 refers to the file correspondence management table 152 in order to distinguish whether the migration target file is the actual data file 180 or the metadata file 181. In addition, the file migration control unit 130 acquires the identification information of the file server to which the file is migrated from the hierarchical storage configuration management table 150.

Next, in step S3, the file movement control unit 130 of the front end file server 1 executes a file movement process. Specifically, the file migration control unit 130 refers to the file migration management table 155 and sequentially migrates the migration target file to the migration destination file server.

The file movement control unit 130 may delete the actual data file 180 and the metadata file 181 stored in the data storage area 170 after moving the file, or store the actual data file 180 and the metadata file 181. It may be replaced with a stub file containing link information regarding the destination.

The file movement control unit 130 reflects information related to file movement in the stored file management table 154. In addition, the file movement control unit 130 reflects information on the remaining capacity of the data storage area 170 associated with file deletion or replacement with a stub file in the operation management table 153.

The example shown in FIG. 1 shows the state after the file is moved.

The file 280-1 indicates that the actual data file 180 and the metadata file 181 are stored in the backend file server A (2-1) as one file.

The file 280-2 is stored in the backend file server A (2-1) as a file including only the metadata file 181. The file 280-3 is stored as a file including only actual data in the backend file server B (2- 2) indicates that it is stored. That is, the actual data file 180 and the metadata file 181 are stored in different back-end file servers 2.

The metadata file 181 included in the file 280-2 includes storage location information indicating the storage location of actual data. For example, information on the file 280-3 including the corresponding actual data file 180 is included.

The above is the outline of the processing of the computer system in the first embodiment.

Next, the specific configuration of the computer system will be described.

FIG. 2 is a block diagram illustrating a configuration example of the computer system according to the first embodiment of this invention.

The computer system includes a front-end file server 1, a plurality of back-end file servers 2, a data source 4, and a client 5, and is connected to each other via a network 6 so that data communication is possible.

The network 6 may be a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, or the like. Moreover, it is not limited to the network connection type, and may be either wired or wireless. Moreover, the structure which connects via several different networks as needed may be sufficient.

For example, the front-end file server 1, the data source 4, and the client 5 are connected to each other via a LAN, and each of the plurality of back-end file servers 2 is connected to another LAN having a different subnet, etc. A configuration in which two LANs are connected via a LAN is conceivable.

Depending on the system configuration, various buses such as PCI may be applied in part. Here, each file server can be applied with cascade connection or ring connection, and data stored in the front-end file server 1 and the plurality of back-end file servers 2 can be accessed using one file path. It has become. The present invention is not limited to this, and an independent file path may be used for each file server.

The front end file server 1 provides the client 5 with a file storage service and a file sharing service. The plurality of back-end file servers 2 store files stored in the front-end file server 1. The data source 4 is a device that generates a file to be stored. The client 5 is a computer that the user operates to acquire data or search for data.

The front end file server 1 stores the file generated by the data source 4 in its own storage area or the back end file server 2. Further, the front-end file server 1 responds with a file including at least one of the actual data file 180 and the metadata file 181 in response to the file access request transmitted from the client 5.

In this embodiment, an example in which each component is one is described for simplicity, but a plurality of components may exist. In addition, the front-end file server 1 and the plurality of back-end file servers 2 constituting the tiered storage can add another file storage or file server in a hierarchy, and a plurality of file storages or It is also possible to set up a file server.

Further, although the front-end file server 1 is intended for storing data generated by the data source 4, the present invention is not limited to this. The front-end file server 1 may store data generated by another device or may store data generated in the front-end file server 1.

First, the front end file server 1 will be described.

The front-end file server 1 uses a general-purpose computer and includes a CPU 10, a memory 11, an I / F 12, and an auxiliary storage device 13.

CPU 10 executes a program stored in the memory 11. The functions of the front-end file server 1 can be realized by the CPU 10 executing the program. In the following description, when a process is described with a program as the subject, it indicates that the CPU 10 is executing the program.

The memory 11 stores a program executed by the CPU 10 and information necessary for executing the program. The program and information stored in the memory 11 will be described later.

The I / F 12 controls data communication with an external device. The auxiliary storage device 13 is a device that provides a large-capacity storage area. As the auxiliary storage device 13, for example, an HDD (Hard Disk Drive), an SSD (Solid State Drive), or the like can be considered. Note that a RAID may be configured using a plurality of auxiliary storage devices 13. In this embodiment, the auxiliary storage device 13 is used as the data storage area 170.

Here, the program and information stored in the memory 11 will be described. In the present embodiment, the memory 11 stores programs for realizing the file management unit 100, the file access control unit 110, the metadata generation unit 120, and the file movement control unit 130. The memory 11 also stores a tiered storage configuration management table 150, a migration condition management table 151, a file correspondence management table 152, an operation management table 153, a storage file management table 154, and a file migration management table 155. The memory 11 also has a storage area for realizing the data reception buffer 160.

Hierarchical storage configuration management table 150, migration condition management table 151, file correspondence management table 152, operation management table 153, storage file management table 154, and file migration management table 155 will be described later with reference to FIGS.

The file management unit 100 provides a file system used for managing files. Note that the file management unit 100 may provide a database instead of the file system.

The file access control unit 110 receives a file access request transmitted from an external device such as the client 5 and controls access to the file.

For example, when the file requested from the client 5 is stored in the back-end file server 2, the file access control unit 110 reads the file from the back-end file server 2 and returns the read file to the client 5. . When the file requested from the client 5 is moved from the back-end file server 2 to another storage device such as a tape device, the file access control unit 110 is read from the storage device to the back-end file server 2. The file is returned to the client 5.

The metadata generation unit 120 executes a metadata extraction process for generating the metadata file 181 from the actual data file 180. Details of the metadata extraction processing will be described later with reference to FIG. The metadata generation unit 120 includes a plurality of functional units such as an actual data acquisition unit 121, a metadata extraction unit 122, and a metadata file generation unit 123.

The actual data acquisition unit 121 reads the actual data file 180 temporarily stored in the data reception buffer 160 as appropriate. In addition, the actual data acquisition unit 121 executes a filtering process for acquiring a file for extracting metadata from the actual data file 180 based on the conditions and processing contents registered in the movement condition management table 151. Details of the filtering process will be described later with reference to FIG.

The metadata extraction unit 122 extracts metadata from the acquired actual data file 180. Specifically, the metadata extraction unit 122 specifies the data type of the actual data file 180, and executes a metadata extraction process to extract metadata based on the specified data type.

For example, the metadata extraction unit 122 may specify the data type of the actual data file 180 based on the extension name given to the file name of the actual data file 180. Further, the metadata extraction unit 122 may analyze the actual data file 180 and specify the data type of the actual data file 180 based on the analysis result. Therefore, the metadata extraction unit 122 holds a data type and a metadata extraction module (not shown) corresponding to the data type.

Here, the data content of the metadata extracted by the metadata extraction unit 122 will be described using an image file as an example. The metadata extraction unit 122 mainly extracts the following two types of information as file metadata.

First, the metadata extraction unit 122 extracts information given as file attribute information from the file. Specifically, the file size, file owner, file creation date and time, file last update date and time, and the like are extracted.

Second, the metadata extraction unit 122 analyzes the contents of the file and extracts information acquired as a result of the analysis. Specifically, when a building is reflected in the image of the image file, feature information such as the shape and color of the building is extracted. When the location of the building is identifiable, the metadata extraction unit 122 also extracts feature information such as the name of the building and the location.

The metadata file generation unit 123 generates file format data, that is, a metadata file 181 from the extracted metadata. Specifically, the following processing is executed.

The metadata file generation unit 123 newly generates a metadata file 181 including the extracted metadata, and stores the corresponding actual data file 180 and metadata file 181 in the data storage area 170. At this time, the metadata file generation unit 123 stores the correspondence relationship between the actual data file 180 and the metadata file 181 in the file correspondence management table 152.

Further, the metadata file generation unit 123 stores information regarding the storage locations of the actual data file 180 and the metadata file 181 in the storage file management table 154. The metadata file generation unit 123 stores, in the operation management table 153, the remaining capacity of the data storage area 170 that has changed along with the storage of the file in the data storage area 170, that is, information on the remaining capacity of the auxiliary storage device 13, and the like.

The file movement control unit 130 selects a movement candidate file from the files stored in the data storage area 170, and controls the movement of the selected file. The file movement control unit 130 includes a plurality of functional units such as an information acquisition unit 131, a determination unit 132, and a file movement unit 133.

The information acquisition unit 131 acquires information from each management table used for selecting a movement candidate file. Specifically, the information acquisition unit 131 acquires information from the hierarchical storage configuration management table 150, the migration condition management table 151, the file correspondence management table 152, the operation management table 153, the storage file management table 154, and the file migration management table 155. To do.

<The determination part 132 determines the processing content of a movement process based on the information acquired from each management table. Specifically, the following processing is executed.

The determination unit 132 compares the condition registered in the movement condition management table 151 with the information acquired from the operation management table 153, and searches for a matching condition. The determination unit 132 specifies an action corresponding to the matched condition, and determines the specified action as the processing content of the movement process.

Further, the determination unit 132 selects a movement candidate file based on the processing content of the determined movement process, and stores information on the selected file in the file movement management table 155.

More specifically, the determination unit 132 refers to the storage file management table 154 based on the processing content of the determined transfer process, and selects a transfer candidate file from the files stored in the data storage area 170. The determination unit 132 stores information on the selected movement candidate file in the file movement management table 155.

At this time, the determination unit 132 refers to the file correspondence management table 152 in order to distinguish whether the migration candidate file is the actual data file 180 or the metadata file 181. In addition, the determination unit 132 appropriately acquires the identification information of the file server that is the migration destination file from the hierarchical storage configuration management table 150.

The file mover 133 moves the move candidate file to a predetermined move destination file server. Specifically, the file mover 133 refers to the file move management table 155 and sequentially moves the move candidate files to the move destination file server.

Next, the back-end file server 2 will be described.

The back-end file server 2 is a general-purpose computer and includes a CPU 20, a memory 21, an I / F 22, and an auxiliary storage device 23.

CPU 20 executes a program stored in memory 21. The functions of the back-end file server 2 can be realized by the CPU 20 executing the program. In the following description, when a process is described with a program as a subject, it indicates that the CPU 20 is executing the program.

The memory 21 stores a program executed by the CPU 20 and information necessary for executing the program. The program and information stored in the memory 21 will be described later.

The I / F 22 controls data communication with an external device. The auxiliary storage device 23 is a device that provides a large-capacity storage area. The auxiliary storage device 23 may be, for example, an HDD or an SSD. A RAID may be configured using a plurality of auxiliary storage devices 23.

Here, the program and information stored in the memory 21 will be described. In the present embodiment, the memory 21 stores programs for realizing the file management unit 201 and the file access control unit 202. The memory 21 also stores a back-end storage file management table 250.

Since the file management unit 201 and the file access control unit 202 are the same as the file management unit 100 and the file access control unit 110 included in the front-end file server 1, description thereof is omitted. The back end storage file management table 250 will be described later.

Note that the CPU type, the type and capacity of the auxiliary storage device 23, the capacity of the memory 21, and the like included in each back-end file server 2 may be different.

Next, the data source 4 will be described.

The data source 4 is a general-purpose computer and includes a CPU 40, a memory 41, an I / F 42, and an auxiliary storage device 43.

CPU 40 executes a program stored in memory 41. The function of the data source 4 can be realized by the CPU 40 executing the program. In the following description, when a process is described with a program as a subject, it indicates that the CPU 40 is executing the program.

The memory 41 stores a program executed by the CPU 40 and information necessary for executing the program. The program and information stored in the memory 41 will be described later.

The I / F 42 controls data communication with an external device. The auxiliary storage device 43 is a device that provides a large-capacity storage area. As the auxiliary storage device 43, for example, an HDD and an SSD can be considered.

Here, the program and information stored in the memory 41 will be described. In this embodiment, the memory 11 stores programs for realizing the data management unit 401 and the data providing unit 402.

The data management unit 401 manages data generated and held in the data source 4. Specifically, a file system function or a database function is provided, and control is performed so that the function can be used.

The data providing unit 402 provides various data managed by the data management unit 401 to the outside of the data source 4. In the present embodiment, processing for storing data stored in the data source 4 as a file in the front-end file server 1 or processing for providing the file is executed in response to a request from the front-end file server 1 or the like.

Note that the data source 4 may be realized by a device other than a general-purpose computer. For example, an apparatus in which a function for managing the recording data is incorporated into a camera apparatus that records a moving image can be considered.

Next, the client 5 will be described.

The client 5 is a general-purpose computer and includes a CPU 50, a memory 51, an I / F 52, and an auxiliary storage device 53.

CPU 50 executes a program stored in memory 51. The functions of the client 5 can be realized by the CPU 50 executing the program. In the following description, when a process is described with a program as a subject, it indicates that the CPU 50 is executing the program.

The memory 51 stores a program executed by the CPU 50 and information necessary for executing the program. The program and information stored in the memory 51 will be described later.

The I / F 52 controls data communication with an external device. The auxiliary storage device 53 is a device that provides a large-capacity storage area. As the auxiliary storage device 53, for example, an HDD and an SSD can be considered.

Here, the program and information stored in the memory 51 will be described. In this embodiment, the memory 51 stores programs for realizing the file management unit 501, the file access client control unit 502, and the file share management unit 503.

Since the file management unit 201 is the same as the file management unit 100 included in the front-end file server 1, description thereof is omitted.

The file access client control unit 502 transmits a file access request to the front-end file server 1 based on the file access request input from the user or the like, and provides the acquired file to the request source. In the present embodiment, the file access client control unit 502 acquires the actual data file 180 and the metadata file 181. The transmission destination of the file access request is not limited to the front end file server 1, and the access request may be transmitted to the back end file server 2.

The file sharing management unit 503 provides a file sharing function used for accessing a file shared by each file server from the client 5.

FIG. 3 is an explanatory diagram illustrating a configuration example of the hierarchical storage configuration management table 150 according to the first embodiment of this invention.

The hierarchical storage configuration management table 150 manages information related to the configuration of the file server that configures the hierarchical storage. In this embodiment, information about the front-end file server 1 and the back-end file server 2 is stored. Specifically, the tier storage configuration management table 150 includes a tier name 1501, storage identification information 1502, media type information 1503, and access protocol 1504. The columns included in the hierarchical storage configuration management table 150 are not limited to those described above.

The tier name 1501 stores information indicating the management tier of the file server in the tier storage. For example, “Tier0” is stored in the record corresponding to the front-end file server 1, and “Tier1” is stored in the record corresponding to the back-end file server A (2-1).

Storage identification information 1502 stores file server identification information. For example, the storage identification information 1502 stores the IP address or host name of the file server.

The media type information 1503 stores information indicating the type of recording medium used by the file server for storing data. For example, information such as “SSD”, “HDD”, or “magnetic tape” is stored.

Note that the media type information 1503 may store more detailed information. For example, when data is stored in the HDD, information regarding a storage interface such as a serial number, SAS or SATA, or a vendor name may be stored. When data is stored in the tape device, tape cartridge identification information, device vendor name, and the like may be stored.

The access protocol 1504 stores information related to the access protocol used when outputting an access request to the file server. For example, identification information such as HTTP (Hyper Text Transfer Protocol), NFS (Network File System), or LTFS (Linear Tape File System) is stored.

Note that the access protocol 1504 may store more detailed information. For example, when an authentication process is required when accessing the file server, information for identifying an authentication method in the authentication process may be stored.

Note that since the file is also stored in the data source 4, information related to the data source 4 is also stored in the hierarchical storage configuration management table 150. In this case, “Data Source” is stored in the hierarchy name 1501.

FIG. 4 is an explanatory diagram illustrating a configuration example of the movement condition management table 151 according to the first embodiment of this invention.

The movement condition management table 151 manages the selection condition of the movement candidate file and the action for the movement candidate file in association with each other. Specifically, the movement condition management table 151 includes a condition management number 1511, a determination order 1512, a condition 1513, and an action 1514. The columns included in the movement condition management table 151 are not limited to those described above.

The condition management number 1511 stores a number for managing an algorithm for selecting a migration candidate file. Records having the same number stored in the condition management number 1511 indicate the same algorithm. Further, when a different number is stored in the condition management number 1511, it indicates a different algorithm. As described above, in this embodiment, a plurality of algorithms can be registered.

The determination order 1512 stores the determination order in the same algorithm. In this embodiment, the determination unit 132 determines the conditions in ascending order of the determination order 1512 values.

The condition 1513 stores a conditional expression for determination. In this embodiment, a conditional expression that can be determined by using information acquired from an operation management table 153 described later is stored. The condition 1513 may store a conditional expression obtained by combining a plurality of conditional expressions using an AND condition or an OR condition. A conditional expression using information not included in the operation management table 153 may be stored.

The action 1514 stores the content of the process executed when the condition 1513 is met. Specifically, information about the movement destination of the actual data file 180 or the movement destination of the metadata file 181 can be set. In addition, the processing contents considering the system state can be stored as follows.

The following processing contents are stored in case the remaining capacity of the data reception buffer 160 decreases.

The filtering process is executed on the data stored in the data reception buffer 160, and then the metadata extraction process is executed.

Even if the trigger for executing the metadata extraction process is not clear, such as when additional data is stored in the log file and movie file by executing the process described above, it is compulsory when the specified conditions are met. The actual data can be extracted as a file and the metadata extraction process can be executed.

The following processing contents are stored in case the storage capacity of the front-end file server 1 is not enough.

Execute the process to move or delete the actual data file 180 to the lower tier storage. In addition, when the storage capacity of the front-end file server 1 is sufficient after the move process or the delete process is executed, the process of moving the moved real data file 180 to the front-end file server 1 or the deleted real data A process of acquiring the file 180 from the data source 4 is executed. Specifically, the condition 1513 stores the condition “HDD usage rate” <30% ”, and the action 1514 records the processing content“ set “front-end file server” as “actual data transfer destination” ”. May be registered in the movement condition management table 151.

Also, if the storage capacity of the front-end file server 1 is not sufficient, the following processing contents are registered.

When the size occupied by the actual data file 180 with respect to the total capacity of the HDD in the data storage area 170 is larger than a predetermined threshold, the actual data file 180 is transferred to a file server different from the transfer destination of the metadata file 181.

Specifically, the condition 1513 “HDD usage rate” ≧ 80% AND “actual data file total size ratio” ≧ 75% ”is stored, and action 1514 is“ backend to “metadata transfer destination”. It is only necessary to register in the migration condition management table 151 the processing contents of “setting file server A” and “setting“ back-end file server B ”as“ actual data transfer destination ””.

The above-described process is a process for quickly securing a storage area for storing the metadata file 181 stored in the data storage area 170.

Here, “actual data file total size ratio” indicates the ratio of the total size of all actual data files 180 stored in the data storage area 170 to the total capacity of the HDD. For example, if the total capacity of the HDD is 10 GB and the total size of the actual data files 180 is 8 GB, the actual data file total size ratio is 80%.

In addition, in order to calculate the actual data file total size ratio, the total size of the actual data file 180 may be managed as management information. In this embodiment, as will be described later, the operation management table 153 includes the actual data file total size 1533.

FIG. 5 is an explanatory diagram showing a configuration example of the file correspondence management table 152 according to the first embodiment of the present invention.

The file correspondence management table 152 manages the correspondence between the actual data file 180 stored in the data storage area 170 and the metadata file 181. Specifically, the file correspondence management table 152 includes an actual data file name 1521, a metadata file name 1522, an actual data file last update date / time 1523, and a metadata file last update date / time 1524. The columns included in the file correspondence management table 152 are not limited to those described above.

The actual data file name 1521 stores the file name of the actual data file 180. The actual data file name 1521 stores the file name when the actual data file 180 is stored in the front end file server 1.

The metadata file name 1522 stores the file name of the metadata file 181. The metadata file name 1522 stores a file name given to the metadata file 181 when the metadata file 181 is generated. Here, the file name of the metadata file 181 given by the metadata generation unit 120 is converted based on a predetermined rule. The file name conversion rule may be registered by a system administrator or the like.

The actual data file last update date and time 1523 stores the last update date and time held as the file attribute of the actual data file 180. Similarly, the metadata file last update date and time 1524 stores the last update date and time held as the file attribute of the metadata file 181.

Here, the date and time stored in the metadata file last update date and time 1524 is the date and time when the metadata generation unit 120 extracts the metadata from the actual data file 180 and generates the metadata file 181 from the extracted metadata. .

FIG. 6 is an explanatory diagram illustrating a configuration example of the operation management table 153 according to the first embodiment of this invention.

The operation management table 153 manages information indicating the operation state of each component in the front-end file server 1. Information indicating the operating state is collected periodically or when necessary, and the collected information is stored in the operation management table 153.

The operation management table 153 includes a storage area usage rate 1531, a storage area total capacity 1532, a real data file total size 1533, a metadata file total size 1534, a data reception buffer memory usage size 1535, and a last update date 1536.

The storage area usage rate 1531 stores the usage rate value of the storage medium used as the data storage area 170. The value stored in the storage area usage rate 1531 is calculated by dividing the size of all files stored in the data storage area 170 by the size of the data storage area 170.

The storage area total capacity 1532 stores a value indicating the overall size of the storage medium used as the data storage area 170.

The real data file total size 1533 stores the total size of all real data files 180 stored in the data storage area 170. The metadata file total size 1534 stores the total size of all metadata files 181 stored in the data storage area 170.

By using the total storage area capacity 1532, the actual data file total size 1533, and the metadata file total size 1534, the ratio of the actual data file 180 or the ratio of the metadata file 181 to all the files stored in the data storage area 170 can be determined. Can be calculated.

The data reception buffer memory use size 1535 stores the total size of all actual data files 180 stored in the data reception buffer 160. Since the actual data file 180 stored in the data reception buffer 160 is stored in the data storage area 170 after a predetermined process is executed, it is useful information for grasping the operation status of the data storage area 170. Become one.

The last update date / time 1536 stores the date / time when the record was registered or the value of the record was last updated.

Note that the columns included in the operation management table 153 are not limited to those described above. For example, the CPU usage rate, network performance (throughput or response time), HDD I / O performance (throughput or response time), cache hit rate, and the like may be managed.

Further, the front-end file server 1 does not need to hold the operation management table 153 itself, and may acquire each information individually at a predetermined timing. For example, regarding the storage area usage rate 1531, the front-end file server 1 does not periodically execute a command for acquiring information, but executes the command when necessary to acquire information. May be.

FIG. 7 is an explanatory diagram illustrating a configuration example of the storage file management table 154 according to the first embodiment of this invention.

The stored file management table 154 manages information related to files stored in the file server constituting the hierarchical storage. Specifically, the storage file management table 154 includes a file name 1541, a file storage hierarchy 1542, a file path 1543, and a last update date / time 1544. The columns included in the storage file management table 154 are not limited to those described above.

The file name 1541 stores the access path name of the file stored in the tiered storage. The access path name is used when accessing a file stored in the hierarchical storage. For example, when the user requests access to a file stored in the tiered storage, the access path name stored in the file name 1541 is used.

The file storage hierarchy 1542 stores the identification information of the file server where the file is actually stored. In this embodiment, the information stored in the file storage tier 1542 is the same information as the tier name 1501 in the tier storage configuration management table 150.

When a file is stored in a plurality of file servers, the file storage hierarchy 1542 may store identification information of each file server that stores the file.

When the actual data file 180 is deleted from the tiered storage, the identification information of the data source 4 that is the generation source of the actual data file is stored in the file storage hierarchy 1542 of the record corresponding to the actual data file 180. The When the identification information of the data source 4 is stored in the file storage hierarchy 1542, the front-end file server 1 transmits an acquisition request for the actual data file to the data source 4, and requests the acquired actual data file. Provide to the original.

The file path 1543 stores the path name of the file in the file server. When the file is stored in a plurality of file servers, the file path 1543 may store the path name of each file server that stores the file. When the file is stored in an external device such as the data source 4, the path name in the device may be stored.

The last update date / time 1544 stores the date / time when the record was registered or the date / time when the value of the record was last updated.

When the front-end file server 1 receives the file access request, the front-end file server 1 can specify the file server to which the file access request is transferred based on the stored file management table 154.

FIG. 8 is an explanatory diagram illustrating a configuration example of the file movement management table 155 according to the first embodiment of this invention.

The file movement management table 155 manages the movement candidate files extracted by the file movement control unit 130 and the progress status of the movement process. Specifically, the file move management table 155 includes an actual data file name 1551, a metadata file name 1552, an actual data file move state 1553, a metadata file move state 1554, an actual data file move destination 1555, and a metadata file move destination. 1556 and last update date and time 1557. The columns included in the storage file management table 154 are not limited to those described above.

The real data file name 1551 stores the access path name of the migration candidate real data file 180. The information stored in the actual data file name 1551 may be the same as the actual data file name 1521 in the file correspondence management table 152.

The metadata file name 1552 stores the access path name of the migration candidate metadata file 181. The information stored in the metadata file name 1552 may be the same as the metadata file name 1522 of the file correspondence management table 152.

The real data file movement status 1553 stores information indicating the progress status of the migration processing of the migration candidate real data file 180. For example, when “not moved” is stored in the actual data file movement state 1553, this indicates that the actual data file 180 has not been moved, and when “moved” is stored in the actual data file movement state 1553, Indicates that the data file 180 has been stored.

The metadata file movement status 1554 stores information indicating the progress status of the migration processing of the migration candidate metadata file 181. The information stored in the metadata file move state 1554 is the same as that stored in the actual data file move state 1553.

The real data file migration destination 1555 stores identification information of the file server that is the migration destination of the migration candidate real data file 180. The information stored in the actual data file migration destination 1555 may be the same information as the tier name 1501 of the tier storage configuration management table 150.

The metadata file migration destination 1556 stores identification information of the file server that is the migration destination of the migration candidate metadata file 181. The information stored in the metadata file migration destination 1556 may be the same information as the tier name 1501 of the tier storage configuration management table 150.

The last update date and time 1557 stores the date and time when the record was registered or the date and time when the value of the record was last updated.

As shown in FIG. 8, by managing the actual data file name 1551 and the metadata file name 1552 in association with each other as one record, when moving the migration candidate file, the actual data file 180 and the metadata file 181 are changed. Can be associated.

If only the metadata file 181 is a migration candidate file, the actual data file 180 associated with the metadata file 181 does not need to be migrated, so the actual data file migration state 1553 and the actual data file migration destination 1555 are displayed. Stores the value of “Null”. Thus, it can be seen that the actual data file 180 is not a movement candidate.

In addition, a record in which both the actual data file movement state 1553 and the metadata file movement state 1554 are “moved” may be deleted as appropriate.

FIG. 9 is an explanatory diagram illustrating a configuration example of the back-end storage file management table 250 according to the first embodiment of this invention.

The backend storage file management table 250 manages files moved from the frontend file server 1 to the backend file server 2 in the hierarchical storage. Specifically, the back-end storage file management table 250 includes a file path 2501, a metadata file storage hierarchy 2502, an actual data file storage hierarchy 2503, a metadata file last update date and time 2504, and an actual data file last update date and time 2505. . The columns included in the back-end storage file management table 250 are not limited to those described above.

The file path 2501 stores identification information for specifying the file moved to the back-end file server 2. The file path 2501 stores a file path that can be uniquely identified in the hierarchical storage. For example, the same information as the file path 1543 is stored.

The metadata file storage hierarchy 2502 stores information for specifying a file server in which the metadata file is stored.

In this embodiment, in the case of the metadata file 181 stored in the back-end file server 2 itself, “Local” is stored in the metadata file storage hierarchy 2502. In the case of the metadata file 181 stored in another file server, the metadata file storage hierarchy 2502 stores information indicating the management hierarchy of the file server. For example, the same information as the hierarchy name 1501 is stored.

The actual data file storage hierarchy 2503 stores information for specifying a file server in which the actual data file is stored. Specifically, the same information as the metadata file storage hierarchy 2502 is stored.

The metadata file last update date and time 2504 stores a new value in the metadata file storage hierarchy 2502 of the record or the date and time when the value was updated.

The actual data file last update date and time 2505 stores a new value in the actual data file storage hierarchy 2503 of the record or the date and time when the value was updated.

The back-end file server 2 uses the back-end storage file management table 250, so that after the file is moved to the back-end file server 2, the actual data file 180 or the metadata file 181 included in the file is further stored. When the file is moved to the back-end file server 2, the movement destination of the actual data file 180 or the metadata file 181 can be specified.

Note that the back-end storage file management table 250 is not always necessary, and the storage location of the file may be specified using only the storage file management table 154 held by the front-end file server 1. In this case, when a file is moved between the back-end file servers 2, the back-end file server 2 notifies the front-end file server 1 of information regarding the movement destination of the file. The front-end file server 1 reflects the notified information on the storage file management table 154.

The above is the description of the configuration of the computer system.

Next, the processing flow of the computer system will be described. In the following description, the metadata extraction process will be described with reference to FIGS. 10A and 10B, the movement candidate file selection process will be described with reference to FIG. 11, the file movement process will be described with reference to FIG. The file access process will be described using

First, the metadata extraction process will be described.

10A and 10B are flowcharts for explaining the metadata extraction processing in the embodiment of the present invention.

In the metadata extraction process, the front-end file server 1 extracts metadata from the actual data file 180, and generates a metadata file 181 using the extracted metadata. Further, the front end file server 1 stores the generated metadata file 181 in the data storage area 170. Further, the front-end file server 1 determines whether to store the actual data file 180 in the data storage area 170 according to the operating state.

The metadata generation unit 120 starts the metadata extraction process periodically when the actual data file 180 is received or when an instruction from a system administrator or the like is received.

The metadata generation unit 120 acquires information from the operation management table 153 and the movement condition management table 151 (step S101).

Note that the metadata generation unit 120 acquires the operation information from the operation management table 153 in order to grasp the operation state of the front-end file server 1, but the present invention is not limited to this. For example, the metadata generation unit 120 executes management commands and the like provided by the file system used by the front-end file server 1 to operate the total storage area capacity, the storage area usage rate, the memory usage size, and the like. Information may be acquired.

The metadata generation unit 120 determines whether or not the condition 1513 of the movement condition management table 151 is satisfied based on the acquired information (step S103). Specifically, the following processing is executed.

The metadata generation unit 120 compares the operation information acquired from the operation management table 153 with the conditions of the movement condition management table 151, and searches for a condition 1513 that matches the acquired operation state. At this time, the metadata generation unit 120 searches all the conditions 1513 that match the acquired operating state.

At this time, the metadata generation unit 120 executes processing in ascending order of the condition management number 1511. In addition, when there are a plurality of determination items for one determination algorithm, the metadata generation unit 120 further performs processing in ascending order of the determination order 1512.

If there is a condition 1513 that matches the operating state, the metadata generation unit 120 determines that the condition 1513 of the movement condition management table 151 is satisfied.

Note that the metadata generation unit 120 refers to the action 1514 of the record corresponding to the condition 1513 that matches the operating condition, and temporarily holds the processing content of the process to be executed. The metadata generation unit 120 may delete the retained processing content after the metadata extraction processing is completed.

The above is the description of the processing in step S103.

If it is determined that the condition 1513 is not satisfied (No in step S103), the metadata generation unit 120 ends the process.

When it is determined that the condition 1513 is satisfied (step S103 is Yes), the metadata generation unit 120 determines whether to move the file stored in the data storage area 170 (step S105).

Specifically, the metadata generation unit 120 determines whether or not the processing content that is temporarily stored includes processing content that instructs execution of the file move processing.

If it is determined not to move the file stored in the data storage area 170 (No in step S105), the metadata generation unit 120 proceeds to step S109.

When it is determined that the file stored in the data storage area 170 is to be moved (Yes in step S105), the metadata generation unit 120 instructs the file movement control unit 130 to execute the movement candidate file selection process (step S107). ), The process proceeds to step S109.

At this time, the metadata generation unit 120 includes the processing content related to the file move processing from the temporarily stored processing content in the execution instruction. Receiving the instruction, the file movement control unit 130 executes a movement candidate file selection process described later.

After execution of the process of step S105 or step S107, the metadata generation unit 120 determines whether to generate the metadata file 181 (step S109).

Specifically, the metadata generation unit 120 determines whether or not the processing content that is temporarily stored includes processing content that instructs generation of the metadata file 181.

If it is determined not to extract metadata (No in step S109), the metadata generation unit 120 ends the process.

When it is determined that the metadata is to be extracted (Yes in step S109), the metadata generation unit 120 determines whether the processing has been completed for all the actual data files 180 stored in the data reception buffer 160. (Step S111).

Specifically, the metadata generation unit 120 instructs the actual data acquisition unit 121 to acquire the actual data file 180, and determines whether or not the actual data file 180 has been acquired. When the actual data file 180 is not acquired, the metadata generation unit 120 determines that the processing has been completed for all the actual data files 180 stored in the data reception buffer 160.

If it is determined that the processing has been completed for all actual data files 180 (Yes in step S111), the metadata generation unit 120 ends the processing.

When it is determined that the processing has not been completed for all the actual data files 180 (No in step S111), the metadata generation unit 120 selects one arbitrary actual data file 180 from the data reception buffer 160. (Step S113).

Specifically, the metadata generation unit 120 instructs the actual data acquisition unit 121 to select the actual data file 180. When receiving the instruction, the actual data acquisition unit 121 selects one arbitrary actual data file 180 from the data reception buffer 160.

The metadata generation unit 120 determines whether or not the selected actual data file 180 is closed (step S115).

Specifically, the actual data acquisition unit 121 determines whether or not the selected actual data file 180 is in a closed state in the file system used by the front-end file server 1. Here, the closed state indicates a state in which all data requested to be written are reflected in the file.

If it is determined that the selected actual data file 180 is closed (step S115 is Yes), the metadata generation unit 120 proceeds to step S123.

When it is determined that the selected actual data file 180 is not closed (No in step S115), the metadata generation unit 120 determines whether the size of the selected actual data file 180 is larger than a predetermined threshold value. Is determined (step S117).

Specifically, the actual data acquisition unit 121 determines whether the size of the selected actual data file 180 is larger than a predetermined threshold value. The size of the actual data file 180 can be obtained from attribute information provided by the file system. Note that the predetermined threshold value is set in advance by the system administrator. The system administrator can change the predetermined threshold value as appropriate.

By the process of step S117, the actual data file 180 having a size larger than a predetermined threshold is selected from the actual data files stored in the data reception buffer 160, and the filtering process is executed on the actual data file 180. it can. Further, this reduces the amount of use of the data reception buffer 160, so that the data reception buffer 160 can be used effectively.

If it is determined that the size of the selected actual data file 180 is larger than the predetermined threshold value (Yes in step S117), the metadata generation unit 120 proceeds to step S121.

If it is determined that the size of the selected actual data file 180 is equal to or smaller than the predetermined threshold (No in step S117), the metadata generation unit 120 determines the predetermined size after the selected actual data file 180 is generated. It is determined whether or not the period has elapsed (step S119).

Specifically, the actual data acquisition unit 121 determines whether or not a predetermined period has elapsed since the selected actual data file 180 was generated. The generation date and time of the actual data file 180 can be obtained from attribute information provided by the file system. The predetermined period is set in advance by the system administrator. The system administrator can change the predetermined period as appropriate.

By the process of step S119, the actual data file 180 that has been generated for a predetermined period is selected from the actual data files 180 stored in the data reception buffer 160, and the actual data file 180 is filtered. Processing can be executed. Further, this reduces the amount of use of the data reception buffer 160, so that the data reception buffer 160 can be used effectively.

When it is determined that the predetermined period has not elapsed since the generation of the selected actual data file 180 (No in step S119), the metadata generation unit 120 returns to step S111 and executes the same processing. . This is because the selected actual data file 180 is not a metadata extraction target. Therefore, at the present time, the processing after step S121 is not executed on the selected actual data file 180.

When it is determined that a predetermined period has elapsed since the selected actual data file 180 was generated (Yes in step S119), the metadata generation unit 120 proceeds to step S121.

If Step S117 is Yes or Step S119 is Yes, the metadata generation unit 120 performs a filtering process on the selected actual data file 180 (Step S121). Specifically, the following processing is executed.

The actual data acquisition unit 121 instructs the file access control unit 110 to suspend the file access request for the selected actual data file 180. Next, the actual data acquisition unit 121 instructs the file access control unit 110 to execute an update process on the selected actual data file 180. As a result, data that has not been updated is reflected in the selected actual data file 180.

The actual data acquisition unit 121 changes (renames) the file name of the selected actual data file 180 to the file name for metadata extraction. Furthermore, the actual data acquisition unit 121 newly generates a file with the file name before renaming. At this time, data is not included in the generated file.

The actual data acquisition unit 121 instructs the file access control unit 110 to resume the file access request for the selected actual data file 180.

Through the above processing, the size of the selected actual data file 180 in the data reception buffer 160 becomes zero, and the data stored in the actual data file 180 can be acquired as a separate file.

Furthermore, the actual data acquisition unit 121 outputs the acquired file to the metadata extraction unit 122 and instructs the extraction of metadata.

The above is the description of the processing in step S121.

The front-end file server 1 can extract metadata even when data is continuously added to an open file by executing the filtering process as described above. As a usage mode in which data is continuously added to an open file, there are a case where log data is sequentially stored in a log file, a case where recorded data is stored sequentially, and the like.

Next, after step S115 is Yes or the processing of step S121 is executed, the metadata generation unit 120 determines a metadata extraction method (step S123).

Specifically, the metadata extraction unit 122 determines the data type of the selected actual data file 180, and determines a metadata extraction method based on the determination result. For example, the metadata extraction unit 122 determines a metadata extraction module (not shown) for extracting metadata. In this case, the metadata extraction unit 122 executes the following processing using the determined metadata extraction module.

As a method for determining the data type, for example, a method for determining the data type based on the extension name given to the file name of the selected actual data file 180, the contents of the actual data file 180 are read and read. A method of determining the data type based on the content that has been performed is conceivable.

The metadata generation unit 120 extracts metadata of the selected actual data file 180, generates a metadata file 181 using the extracted metadata, and stores the generated metadata file 181 in the data storage area 170. Store (step S125). Specifically, the following processing is executed.

The metadata extraction unit 122 extracts metadata from the selected actual data file 180 using the metadata extraction module determined in step S113. The metadata extraction unit 122 outputs the extracted metadata to the metadata file generation unit 123.

The metadata file generation unit 123 generates a metadata file 181 from the input metadata, and stores the generated metadata file 181 in the data storage area 170.

The above is the description of the processing in step S115.

Next, the metadata generation unit 120 determines whether or not the selected actual data file 180 is stored in the data storage area 170 (step S127).

Specifically, the metadata generation unit 120 determines whether or not the processing content that is temporarily stored includes processing content that instructs to store the actual data file 180 in the data storage area.

When it is determined that the selected actual data file 180 is stored in the data storage area 170 (Yes in step S127), the metadata generation unit 120 stores the selected actual data file 180 in the data storage area 170. (Step S129), the process proceeds to Step S133.

When it is determined that the selected actual data file 180 is not stored in the data storage area 170 (No in step S127), the metadata generation unit 120 stores the storage location information of the actual data file 180 selected as the metadata file 181. Is added (step S131), and the process proceeds to step S133.

Here, the storage location information of the actual data file 180 includes information on the data source 4 from which the actual data file 180 can be acquired or a file server in which the actual data file 180 is stored. That is, information for accessing the actual data file 180 is added to the metadata file 181. The storage location information of the actual data file 180 may be designated in advance by the system administrator. The metadata file to which the storage destination information is added will be described later with reference to FIG.

After execution of the process of step S129 or step S131, the metadata generation unit 120 updates each management table (step S133), and then returns to step S111. Specifically, the following processing is executed.

First, the metadata generation unit 120 stores information on the selected actual data file 180 and the generated metadata file 181 in the file correspondence management table 152. Here, a record in which the file name of the actual data file 180 and the file name of the metadata file 181 are associated with each other is stored.

Next, the metadata generation unit 120 updates the storage file management table 154. Specifically, the metadata generation unit 120 stores the file name of the file in the file name 1541 of the file stored in the data storage area 170, and the identification information of the front-end file server 1 in the file storage hierarchy 1542. Store. Also, the metadata generation unit 120 stores “Null” in the file path 1543 because the file has not been moved to another file server at this time.

Next, the metadata generation unit 120 updates the operation management table 153. Specifically, the metadata generation unit 120 acquires the memory size of the data reception buffer 160, the usage rate of the data storage area 170, and the like, and stores the acquired various types of information in the operation management table 153.

In the present embodiment, the metadata generation unit 120 specifies the process to be executed based on the operating state of the front-end file server 1, but the present invention is not limited to this.

For example, the metadata generation unit 120 may instruct the determination unit 132 to execute the determination process. In this case, the determination unit 132 executes a determination process described later, and outputs a determination result to the metadata generation unit 120. Therefore, the process of step S101 and step S103 can be omitted.

Further, the metadata generation unit 120 may determine whether or not the record of the selected actual data file 180 is registered with reference to the file movement management table 155. When the record of the selected actual data file 180 is registered in the file movement management table 155, the metadata generation unit 120 determines that the selected actual data file 180 is not stored in the data storage area 170.

In this embodiment, the metadata file 181 is generated when there is no room in the data reception buffer 160, but the present invention is not limited to this. For example, the metadata file 181 may be always generated without depending on the operating state of the front-end file server 1.

In this embodiment, the metadata generation unit 120 adds the storage location information to the metadata file 181 when the actual data file 180 is deleted, but the present invention is not limited to this. For example, the storage location information may be added to all the metadata files 181. In this case, the process of step S109, step S127, and step S129 is abbreviate | omitted, and the process of step S131 is performed after execution of the process of step S125.

Next, the process for selecting a migration candidate file will be described.

FIG. 11 is a flowchart for explaining the selection process of the movement candidate file according to the first embodiment of the present invention.

In the move candidate file selection process, the front end file server 1 selects a move candidate file to be moved to the back end file server 2 from the actual data file 180 and the metadata file 181 stored in the data storage area 170. Further, the front-end file server 1 stores information on the file selected as the migration candidate file in the file migration management table 155.

The file movement control unit 130 executes the movement candidate file selection process periodically when an execution instruction is received from the metadata generation unit 120 or when an instruction from a system administrator or the like is received.

The file migration control unit 130 acquires information from the hierarchical storage configuration management table 150, the operation management table 153, and the migration condition management table 151 (step S201).

Specifically, the file movement control unit 130 instructs the information acquisition unit 131 to acquire information. The information acquisition unit 131 acquires necessary information from the hierarchical storage configuration management table 150, the operation management table 153, and the migration condition management table 151.

The information acquisition unit 131 acquires the operation information from the operation management table 153 in order to grasp the operation state of the front end file server 1, but the present invention is not limited to this. For example, the information acquisition unit 131 executes a management command or the like provided by the file system used by the front-end file server 1, and operates information such as the total capacity of the storage area, the storage area usage rate, and the memory usage size May be obtained.

The file movement control unit 130 determines the content of the movement process based on the acquired information (step S203). Specifically, the following processing is executed.

The file movement control unit 130 instructs the determination unit 132 to determine the processing content of the movement process. The determination unit 132 compares the operation information acquired from the operation management table 153 with the conditions of the movement condition management table 151 and determines whether or not the operation state matches the condition 1513 of the movement condition management table 151.

At this time, the determination unit 132 executes processing in ascending order of the condition management number 1511. When there are a plurality of determination items for one determination algorithm, the determination unit 132 further performs processing in ascending order of the determination order 1512.

When the operating state matches the condition 1513, that is, when there is a condition 1513 that matches the acquired operating information, the determination unit 132 changes the action 1514 of the record corresponding to the matching condition 1513 to the processing content of the movement process. Determine as.

The above is the description of the processing in step S203.

When execution is instructed from the metadata generation unit 120, the execution instruction includes the processing contents of the movement process, and thus the processing in step S201 and step S203 may be omitted.

Next, the file movement control unit 130 instructs the metadata generation unit 120 to execute filtering processing and metadata extraction processing (step S205). At this time, if the actual data file 180 to be processed is specified in the action 1514, the file movement control unit 130 instructs the metadata generation unit 120 to execute the process on the actual data file 180 to be processed. If the actual data file 180 to be processed is not specified in the action 1514, the file movement control unit 130 instructs the metadata generation unit 120 to execute processing for all the actual data files 180.

The metadata generation unit 120 executes the processing from step S115 to step S121 on the specified actual data file 180.

Note that the process of step S205 is executed when the action 1514 stores information indicating that the filtering process and the metadata extraction process are to be executed. Therefore, when the above-described information is not stored in the action 1514, the process of step S205 is omitted.

The file movement control unit 130 determines whether or not the movement candidate file selection process has been completed (step S207).

Specifically, the file movement control unit 130 determines whether or not the processing has been completed for all of the movement contents determined in step S203. When it is determined that the processing has been completed for all the movement processing contents, the file movement control unit 130 determines that the movement candidate file selection processing has been completed.

When it is determined that the movement candidate file selection process has not been completed, the file movement control unit 130 selects a movement candidate file based on the processing content of the determined movement process. When there are a plurality of processing contents of the determined migration process, the file migration control unit 130 selects a migration candidate file for each migration process content. That is, the processing from step S211 to step S219 is executed sequentially.

In addition, when a movement candidate file can be selected in parallel for processing contents of a plurality of movement processes, the movement candidate file may be selected in parallel.

If it is determined that the migration candidate file selection process has been completed (Yes in step S207), the file migration control unit 130 ends the process.

When it is determined that the movement candidate file selection process has not been completed (No in step S207), the file movement control unit 130 selects a movement candidate file based on the determined content of the movement process (step S207). S209 to step S219).

Here, when there are a plurality of processing contents of the determined migration process, the file migration control unit 130 selects a migration candidate file for each process content of the migration process. That is, the processing from step S209 to step S219 is sequentially executed.

Note that the file movement control unit 130 may select a movement candidate file in parallel for the processing contents of a plurality of movement processes.

Hereinafter, the processing from step S209 to step S219 will be described.

First, the file movement control unit 130 acquires information from the stored file management table 154 (step S209).

Specifically, the file movement control unit 130 instructs the information acquisition unit 131 to acquire information. The information acquisition unit 131 acquires information from the stored file management table 154. At this time, the information acquisition unit 131 may acquire information on all files stored in the storage file management table 154, or may acquire only information on files stored in the front-end file server 1. . The file movement control unit 130 executes the following processing for the acquired file.

In the following description, a file corresponding to the information acquired from the stored file management table 154 in step S209 is also described as a target file.

The file movement control unit 130 determines whether or not processing for all target files has been completed (step S211).

If it is determined that the processing for all the target files has been completed (Yes in step S211), the file movement control unit 130 returns to step S204 and executes the same processing.

When it is determined that the processing has not been completed for all target files (No in step S211), the file movement control unit 130 selects one arbitrary target file from the plurality of target files (step S213). .

The file movement control unit 130 identifies the type of the selected target file (step S215). That is, it is determined whether the selected target file is the actual data file 180 or the metadata file 181.

Specifically, the file movement control unit 130 instructs the information acquisition unit 131 to acquire information from the file correspondence management table 152. The file movement control unit 130 refers to the actual data file name 1521 and the metadata file name 1522 in the file correspondence management table 152 and searches for a file name that matches the file name of the selected target file.

If the selected file name matches the file name stored in the actual data file name 1521, the file movement control unit 130 determines that the selected target file is the actual data file 180. If the selected file name matches the file name stored in the metadata file name 1522, the file movement control unit 130 determines that the selected target file is the metadata file 181.

When the selected target file is the actual data file 180, the file movement control unit 130 acquires the file name of the related metadata file 181 from the metadata file name 1522 of the corresponding record in the file correspondence management table 152. To do. On the other hand, when the selected target file is the metadata file 181, the file movement control unit 130 acquires the file name of the related actual data file 180 from the actual data file name 1521 of the corresponding record in the file correspondence management table 152. To do.

The file movement control unit 130 determines whether or not the target file matches the movement condition (step S217).

Specifically, the file movement control unit 130 instructs the determination unit 132 to execute processing. The determination unit 132 further narrows down the target file based on the processing content of the movement processing determined in step S203, that is, the action 1514.

For example, in the action 1514 of the movement condition management table 151, as a process for narrowing down movement candidate files, a file having a specific extension in the file name or a file owned by a specific user is excluded from the movement candidates. Is stored.

The determination unit 132 executes a movement candidate file narrowing process based on the information stored in the action 1514.

When it is determined that the target file does not match the movement condition (No in step S217), the file movement control unit 130 returns to step S211 and executes the same processing.

When it is determined that the target file matches the movement condition (Yes in step S217), the file movement control unit 130 stores the information of the target file in the file movement management table 155 (step S219), and returns to step S211. Specifically, the following processing is executed.

The file movement control unit 130 adds a new record to the file movement management table 155. The file movement control unit 130 stores the access path name in each of the actual data file name 1551 and the metadata file name 1552 of the added record.

Further, the file movement control unit 130 stores “not moved” in the actual data file movement state 1553 and the metadata file movement state 1554 of the added record. The file movement control unit 130 stores information on the migration destination in the actual data file migration destination 1555 and the metadata file migration destination 1556 based on the processing content of the migration processing determined in step S203. If the actual data file 180 is not a migration candidate file, “Null” is stored in the actual data file migration state 1553 and the actual data file migration destination 1555.

Next, the file move process will be described.

FIG. 12 is a flowchart for explaining the file move process according to the first embodiment of the present invention.

In the file movement process, the front-end file server 1 moves the movement candidate file based on the file movement management table 155.

The file movement control unit 130 starts the file movement process periodically or when receiving an instruction from a system administrator or the like. Further, the file movement control unit 130 may start the file movement process after the movement candidate file selection process is completed. The execution cycle is preferably longer than the move candidate file selection process.

The file movement control unit 130 acquires information from the file movement management table 155 (step S301).

Specifically, the file movement control unit 130 instructs the information acquisition unit 131 to acquire information from the file movement management table 155. The information acquisition unit 131 acquires a record from the file movement management table 155. At this time, the information acquisition unit 131 may acquire all the records included in the file movement management table 155 or may acquire a predetermined number of records.

The file movement control unit 130 determines whether or not processing has been completed for all the records acquired from the file movement management table 155 (step S303).

If it is determined that the processing has been completed for all the records acquired from the file movement management table 155 (Yes in step S303), the file movement control unit 130 ends the processing.

When it is determined that the processing has not been completed for all the records acquired from the file movement management table 155 (No in step S303), the file movement control unit 130 selects any record from the plurality of acquired records. Is selected (step S305).

The file movement control unit 130 instructs the file movement unit 133 to execute processing described below. In the following description, the selected record is also described as a target record.

The file moving unit 133 determines whether or not the metadata file 181 corresponding to the target record has been moved (step S307).

Specifically, the file mover 133 determines whether or not the metadata file move state 1554 of the target record is “not moved”. When it is determined that the metadata file movement state 1554 of the target record is “not moved”, the file moving unit 133 determines that the metadata file 181 corresponding to the target record has not been moved.

When it is determined that the metadata file 181 corresponding to the target record has been moved (Yes in step S307), the file moving unit 133 proceeds to step S319.

When it is determined that the metadata file 181 corresponding to the target record has not been moved (No in step S307), the file moving unit 133 determines whether or not the actual data file 180 corresponding to the target record is a movement candidate file. Is determined (step S309).

Specifically, the file moving unit 133 determines whether or not the actual data file name 1551 of the target record is “Null”. If the actual data file name 1551 of the target record is “Null”, the file migration unit 133 determines that the actual data file 180 corresponding to the target record is not a migration candidate file.

When it is determined that the actual data file 180 corresponding to the target record is a movement candidate file (Yes in step S309), the file moving unit 133 proceeds to step S317.

When it is determined that the actual data file 180 corresponding to the target record is not a movement candidate file (No in step S309), the file moving unit 133 stores the actual data file 180 in the metadata file 181 corresponding to the target record. Previous information is added (step S311).

Here, as the storage destination information of the actual data file 180, information stored in the actual data file name 1551 of the file movement management table 155 can be considered. Further, if necessary, information regarding the storage location in the external device such as the data source 4 may be added. The metadata file to which the storage destination information is added will be described later with reference to FIG.

The file moving unit 133 determines whether or not to delete the actual data file 180 corresponding to the target record from the data storage area 170 (step S313).

Specifically, the file moving unit 133 determines whether or not the processing content for deleting the actual data file 180 is included in the processing content of the moving processing determined in step S202.

If it is determined not to delete the actual data file 180 corresponding to the target record (No in step S313), the file moving unit 133 proceeds to step S317.

When it is determined that the actual data file 180 corresponding to the target record is to be deleted (Yes in step S313), the file moving unit 133 deletes the actual data file 180 from the data storage area 170 (step S315). The file moving unit 133 may delete the actual data files 180 sequentially, or may list the actual data files 180 to be deleted and delete them at the end of this process.

After step S309 is Yes, step S313 is No, or the process of step S315 is executed, the file moving unit 133 moves the metadata file 181 corresponding to the target record to a predetermined file server (step S319).

Specifically, the file moving unit 133 moves the metadata file 181 to the file server corresponding to the metadata file moving destination 1556 of the target record. Note that the metadata file 181 stored in the data storage area 170 may be deleted or replaced with a stub file as it moves.

The file moving unit 133 determines whether or not the actual data file 180 corresponding to the target record has been moved (step S319).

Specifically, the file moving unit 133 determines whether or not the actual data file moving state 1553 of the target record is “not moved”. When the actual data file movement state 1553 of the target record is “not moved”, the file moving unit 133 determines that the actual data file 180 corresponding to the target record has not been moved.

When it is determined that the actual data file 180 corresponding to the target record has been moved (Yes in Step S319), the file moving unit 133 proceeds to Step S323.

When it is determined that the actual data file 180 corresponding to the target record has not been moved (No in step S319), the file moving unit 133 moves the actual data file 180 to a predetermined file server (step S321).

Specifically, the file moving unit 133 moves the actual data file 180 to the file server corresponding to the actual data file destination 1555 of the target record. Note that the actual data file 180 stored in the data storage area 170 may be deleted or replaced with a stub file as it moves.

The file moving unit 133 updates the storage file management table 154 and the operation management table 153 (step S323), and then returns to step S303. Specifically, the following processing is executed.

The file moving unit 133 stores the information on the moved destination of the moved metadata file 181 and the moved actual data file 180 in the file storage hierarchy 1542 and the file path 1543 of the corresponding record in the stored file management table 154.

The file moving unit 133 updates the operation management table 153 with the updated contents such as the storage area usage rate that have changed with the deletion of the actual data file 180 and the metadata file 181 from the data storage area 170 or the replacement with the stub file. Store.

Next, file access processing will be described.

FIG. 13 is a flowchart for explaining file access processing according to the first embodiment of the present invention.

In the file access process, the front-end file server 1 provides a file designated by the client 5 operated by the user or the like.

The file access control unit 110 receives a file access request (step S401). The file access request has a format conforming to the file access protocol provided by the front-end file server 1 and includes the following two pieces of information.

The first information is information for specifying a file to be accessed. Specifically, this is information specifying the file name of the actual data file 180. For example, the same information as the file name 1541 of the stored file management table 154 is included.

The second information is information that specifies the actual file to be accessed. For example, information specifying whether the file to be accessed is only the actual data file 180, only the metadata file 181, or the actual data file 180 and the metadata file 181 is included. Hereinafter, this information is also referred to as access designation information.

Note that information other than the information described above may be included in the file access request. Further, the number of files to be accessed in the file access request may be plural.

The file access control unit 110 determines whether the metadata file 181 is included in the access target file (step S403).

Specifically, the file access control unit 110 refers to the access designation information included in the file access request, and determines whether or not the metadata file 181 is designated as an access target file. For example, when the access specification information includes only the metadata file 181 or information specifying either the actual data file 180 or the metadata file 181 as the access target file, the file access control unit 110 may It is determined that the metadata file 181 is included in this file.

If it is determined that the metadata file 181 is not included in the access target file (No in step S403), the file access control unit 110 proceeds to step S409.

When it is determined that the metadata file 181 is included in the access target file (Yes in step S403), the file access control unit 110 determines the access target meta data based on the file correspondence management table 152 and the stored file management table 154. Information indicating the storage location of the data file 181 is acquired (step S405). Specifically, the following processing is executed.

The file access control unit 110 refers to the file correspondence management table 152 and searches for a record in which the actual data file name 1521 matches the file name of the actual data file 180 included in the file access request. The file access control unit 110 acquires the value of the metadata file name 1522 of the retrieved record as the file name of the metadata file 181 to be accessed.

The file access control unit 110 refers to the stored file management table 154 and searches for a record that matches the file name of the metadata file 181 from which the file name 1541 is acquired. The file access control unit 110 acquires the values of the file storage hierarchy 1542 and the file path 1543 of the retrieved record.

The above is the description of the processing in step S405.

The file access control unit 110 acquires the access target metadata file 181 based on the acquired information (step S407). Specifically, the following processing is executed.

The file access control unit 110 determines whether the metadata file 181 is stored in the front-end file server 1 based on the value of the file storage hierarchy 1542. When it is determined that the metadata file 181 is stored in the front-end file server 1, the file access control unit 110 acquires the metadata file 181 based on the value information of the file path 1543.

When it is determined that the metadata file 181 is stored in the back-end file server 2, the file access control unit 110 acquires the metadata file 181 from the back-end file server 2. For example, the file access control unit 110 transmits a read request including the value of the file path 1543 to the back-end file server 2.

The above is the description of the processing in step S407.

Next, the file access control unit 110 determines whether or not the actual data file 180 is included in the file to be accessed (step S409).

Specifically, the file access control unit 110 refers to the access designation information included in the file access request and determines whether or not the actual data file 180 is designated as an access target file. For example, when the access designation information includes only the actual data file 180 or information designating either the actual data file 180 or the metadata file 181 as the access target file, the file access control unit 110 may It is determined that the actual data file 180 is included in this file.

When it is determined that the actual data file 180 is not included in the access target file (No in step S409), the file access control unit 110 proceeds to step S415.

When it is determined that the actual data file 180 is included in the file to be accessed (Yes in step S409), the file access control unit 110 indicates the storage destination of the actual data file 180 to be accessed from the storage file management table 154. Is acquired (step S411).

Specifically, the file access control unit 110 searches for a record in which the file name 1541 matches the file name of the actual data file 180 included in the file access request. The file access control unit 110 acquires the values of the file storage hierarchy 1542 and the file path 1543 of the retrieved record.

The file access control unit 110 acquires the actual data file 180 to be accessed based on the acquired information (step S413). Specifically, the following processing is executed.

The file access control unit 110 determines whether or not the actual data file 180 is stored in the front-end file server 1 based on the value of the file storage hierarchy 1542. When it is determined that the actual data file 180 is stored in the front-end file server 1, the file access control unit 110 acquires the actual data file 180 to be accessed based on the value of the file storage hierarchy 1542.

When it is determined that the actual data file 180 is stored in the back-end file server 2, the file access control unit 110 acquires the actual data file 180 from the back-end file server 2. For example, the file access control unit 110 transmits a read request including the value of the file path 1543 to the back-end file server 2.

The above is the description of step S413.

Next, the file access control unit 110 transmits the acquired file to the requesting client 5 (step S415), and ends the process. Here, when there is no file to be acquired or when the requested file does not exist, the file access control unit 110 responds to the requesting client 5 to that effect.

FIG. 14 is an explanatory diagram illustrating an example of a data configuration of the metadata file 181 according to the first embodiment of this invention.

FIG. 14 shows a data structure 156 that is the content of the metadata included in the metadata file 181. The data structure 156 includes a metadata type 1561, a metadata name 1562, and a metadata value 1563. Note that the columns included in the data structure 156 are not limited to those described above.

The metadata type 1561 stores information indicating the type of metadata stored in the metadata file 181. FIG. 14 shows three types of metadata as an example.

“Metadata derived from file attribute information” corresponds to the metadata acquired from the attribute information of the actual data file 180. “Metadata derived from actual data” corresponds to metadata extracted by the metadata extraction unit 122 analyzing the actual data file 180. Further, “metadata derived from hierarchical storage” corresponds to metadata for managing the actual data file 180 corresponding to the metadata file 181 in the hierarchical storage. Here, as metadata for managing the actual data file 180 corresponding to the metadata file 181 in the hierarchical storage, for example, the identification information of the file server in which the actual data file 180 is stored, Information such as file path can be considered.

“Metadata derived from tiered storage” corresponds to the storage location information of the actual data file added in step S131 or step S311.

The metadata name 1562 stores metadata identification information. As the identification information of the metadata, for example, an identification name or an identification number for specifying the metadata can be considered.

The metadata value 1563 stores a metadata value. One or more values are stored for the metadata name 1562. In this embodiment, the metadata value 1563 corresponding to the storage destination information of the actual data file stores a URL for accessing the actual data file 180.

In the example shown in FIG. 14, the data structure 156 of the metadata file 181 has been described as tabular data. However, the present invention is not limited to this, for example, the CSV (Comma Separated Values) format or the XML format. It may be used.

FIG. 15 is an explanatory diagram showing an example of the file list screen 190 used in the first embodiment of the present invention.

The file list screen 190 is a GUI used to refer to file storage information in the tiered storage. When the system administrator or the like operates the client 5 or the like to access the front-end file server 1, the storage location of the file stored in the tiered storage and the storage information of the moved file are displayed on the file list screen 190. Is done.

In the file list screen 190, a file list display field 191, a filter condition input field 192, a sort condition input field 193, and a refresh button 194 are displayed.

The file list display field 191 displays information on files stored in the tiered storage. The file list display column 191 includes an actual data file name 1911, a metadata file name 1912, an actual data file storage state 1913, a metadata file storage state 1914, an actual data file storage destination URL 1915, and a metadata file storage destination URL 1916. .

In the actual data file name 1911, the file name of the actual data file 180 stored in the hierarchical storage is displayed.

In the metadata file name 1912, the file name of the metadata file 181 stored in the hierarchical storage is displayed.

In the actual data file storage state 1913, the storage state of the actual data file 180 is displayed. For example, when the actual data file 180 is stored in the hierarchical storage, the actual data file storage state 1913 is displayed as “stored”, and when the actual data file 180 is deleted from the hierarchical storage, the actual data file storage state 1913 is “Deleted” is displayed.

In the metadata file storage state 1914, the storage state of the metadata file 181 is displayed. The information displayed in the metadata file storage state 1914 is the same as that in the actual data file storage state 1913.

In the actual data file storage destination URL 1915, information for accessing the actual data file 180 is displayed. For example, information combining the tier name in the tier storage and the file path of the file server corresponding to the tier is displayed.

In the metadata file storage destination URL 1916, information for accessing the metadata file 181 is displayed. The information displayed in the metadata file storage location URL 1916 is the same as the actual data file storage location URL 1915.

The filter condition input field 192 is a display field for inputting a condition for filtering a file to be displayed. The sort condition input field 193 is a display field for inputting a condition for designating the order of records to be displayed. The refresh button 194 is an operation button for updating the display contents of the file list display field 191 and the like to the latest state.

Although the storage information of the file in the tiered storage is displayed as the GUI screen, the present invention is not limited to this. For example, a command or a program method for acquiring file storage information may be provided, and a CLI or API may be provided.

As described above, according to the first embodiment, the file server configuring the hierarchical storage can reliably hold the metadata (metadata file 181) of the actual data file 180 in the hierarchical storage. For example, even if the free space of the data storage area 170 is small and it is difficult for the front-end file server 1 to store a new file, the metadata of the file can be reliably acquired.

Further, according to the first embodiment, it is possible to reliably move the metadata from the upper tier storage (file server) to the lower tier storage (file server). In particular, a large amount of data is stored at one time, or a large amount of data is moved between file servers, etc. The selection of the movement candidate file and the movement of the file can be controlled.

This makes it possible to reliably hold and transfer metadata while ensuring the performance and convenience of hierarchical storage. Therefore, the convenience of the data search and analysis service using metadata is improved.

In the first embodiment, a system that handles data in units of files has been described. However, the present invention can also be applied to a system that handles data in units of blocks. In this case, instead of the file path 1543, the physical storage location of the block may be specified using the block address, block length, and the like.

[Example 2]

In the first embodiment, when a file is moved between file servers that constitute a hierarchical storage, the front-end file server 1 that is the movement source of the file designates the file path of the file server that is the movement destination. Further, after the file is moved, the front-end file server 1 manages the file and the file path in the destination file server in association with each other. Thus, when a file access request for the file is received after the file is moved, the front-end file server 1 can read the file from the destination file server and respond to the read file to the request source.

The entire computer system in which the file storage locations are managed centrally need not be configured as described above. For example, a form of a computer system in which an identification number and an identification name unique to the entire computer system are assigned to a file to be managed and the file is accessed using the assigned information can be considered. In the computer system described above, an arbitrary file server or dedicated server assigns and manages an identification number and an identification name.

Example 2 describes an example in which the present invention is applied to a computer system in which file identification numbers and identification names are managed in a unified manner. The second embodiment will be described with reference to FIGS. 16 to 18 focusing on differences from the first embodiment.

FIG. 16 is a block diagram illustrating a configuration example of the computer system according to the second embodiment of this invention.

In the second embodiment, a name space management server 7 is newly included in the computer system. The namespace management server 7 performs data communication with other devices via the network 6.

Note that the configurations of the front-end file server 1, the back-end file server 2, the data source 4, and the client 5 are the same as those in the first embodiment, and thus detailed configurations are omitted.

The namespace management server 7 centrally manages the identification numbers and identification names of files stored in the tiered storage. In the second embodiment, the file path is determined based on the file identification number and the identification name assigned by the namespace management server 7.

The name space management server 7 uses a general-purpose computer and includes a CPU 70, a memory 71, an I / F 72, and an auxiliary storage device 73.

CPU 70 executes a program stored in memory 71. The functions of the namespace management server 7 can be realized by the CPU 70 executing the program. In the following description, when a process is described with a program as the subject, it indicates that the CPU 70 is executing the program.

The memory 71 stores a program executed by the CPU 70 and information necessary for executing the program. The program and information stored in the memory 71 will be described later.

The I / F 72 controls data communication with an external device. The auxiliary storage device 73 is a device used to provide a large capacity storage area. As the auxiliary storage device 73, for example, an HDD and an SSD can be considered. Note that a RAID may be configured using a plurality of auxiliary storage devices 73.

Here, the program and information stored in the memory 71 will be described. In this embodiment, the memory 71 stores a program for realizing the namespace management unit 701 and a namespace management table 750.

The name space management table 750 will be described later with reference to FIG.

The name space management unit 701 assigns a unique identification number and identification name to a file stored in the tier storage. Information about the assigned identification number and identification name is stored in a namespace management table 750 described later. In the following description, a unique identification number and identification name assigned to a file are also referred to as a global name.

When assigning a global name to a file, the namespace management unit 701 also assigns identification information of the file server in which the file is stored and a file path indicating a storage location in the file server.

The front-end file server 1 may specify identification information of a file server that is a file storage destination candidate and a file path candidate when requesting the assignment of a global name. In this case, the namespace management unit 701 determines whether or not duplication or inconsistency with an existing file occurs based on the designated content, and if no duplication or inconsistency occurs, the designated content is Used to give file server identification information and file path.

Also, the namespace management unit 701 receives a name resolution request including the assigned global name, and responds with a file storage location or access path associated with the global name. Note that the name space management unit 701 also receives an update request for information regarding the storage location and access path of the file.

In the example shown in FIG. 16, the namespace management server 7 has been described as a configuration independent of the file server, but the present invention is not limited to this. One file server may have a function of the namespace management server 7. Moreover, the structure which implement | achieves the function which the name space management server 7 has cooperated by a some file server may be sufficient.

Since the tiered storage configuration management table 150, the migration condition management table 151, the file correspondence management table 152, the operation management table 153, the storage file management table 154, and the file migration management table 155 are the same as those in the first embodiment, a description will be given. Omitted. Further, the metadata extraction process is the same as that of the first embodiment, and thus the description thereof is omitted.

FIG. 17 is an explanatory diagram showing a configuration example of the name space management table 750 according to the second embodiment of the present invention.

The namespace management table 750 manages the correspondence between the global name managed by the namespace management unit 701 and information related to the file to which the global name is assigned. Specifically, the namespace management table 750 includes a global name 7501, a local host name 7502, and a local path name 7503. Note that the columns included in the namespace management table 750 are not limited to those described above.

The global name 7501 stores the global name assigned by the namespace management unit 701. The global name is assigned so as not to be duplicated with other global names.

The local host name 7502 stores identification information of a file server that stores a file to which a global name corresponding to the global name 7501 is assigned. For example, the local host name 7502 stores the host name or IP address of the file server.

The local path name 7503 stores a file path indicating the storage location of the file assigned the global name in the file server.

Note that the global name 7501 and the local path name 7503 may include a wild card representing an arbitrary character string. As a result, information on all files existing in a specific hierarchy can be managed by one record.

FIG. 18A and FIG. 18B are flowcharts for explaining file movement processing according to the second embodiment of the present invention.

Here, differences from the file movement process of the first embodiment shown in FIG. 12 will be described.

If the determination result of step S307 is Yes, the process of step S351 is newly executed.

The file movement control unit 130 requests the namespace management server 7 to add the storage location information of the metadata file 181 (step S351).

Specifically, the file moving unit 133 requests the namespace management server 7 to add storage destination information including identification information of the back-end file server 2 that is a candidate for the storage destination of the metadata file 181. The file moving unit 133 acquires a global name, a local host name, and a local path name as a response from the namespace management server 7. The local host name and local path name correspond to the storage location information. Thereafter, the file moving unit 133 proceeds to step S309.

Further, when the determination result of step S319 is No, the process of step S353 is newly executed.

The file movement control unit 130 requests the namespace management server 7 to allocate storage location information of the actual data file 180 (step S353).

Specifically, the file moving unit 133 requests the namespace management server 7 to allocate storage location information including identification information of the back-end file server 2 that is a candidate for the storage location of the actual data file 180. . The file moving unit 133 acquires a global name, a local host name, and a local path name as a response from the namespace management server 7. Thereafter, the file moving unit 133 proceeds to step S321.

The information acquired in step S351 and step S353 is used when the file is moved, and is stored in the storage file management table 154.

FIG. 19 is a flowchart illustrating file access processing according to the second embodiment of the present invention.

Here, differences from the file access process of the first embodiment shown in FIG. 13 will be described.

After the process of step S401 is executed, the process of step S451 is newly executed.

The file access control unit 110 requests the name space management server 7 for name resolution (step S451). Specifically, the following processing is executed.

The file access control unit 110 analyzes the access path included in the received file access request and determines whether name resolution is necessary.

For example, the file access control unit 110 determines whether or not the access path included in the request is a global name given by the namespace management server 7.

When it is determined that the access path is a global name, the file access control unit 110 determines that name resolution is necessary.

If it is determined that name resolution is not necessary, the file access control unit 110 does not make a request for name resolution and proceeds to step S403.

When it is determined that name resolution is necessary, the file access control unit 110 determines that name resolution is necessary because it is necessary to specify the storage destination of the file to be accessed. Further, the file access control unit 110 requests the name space management server 7 to perform name resolution including the access path included in the received file access request, that is, the global name.

The namespace management server 7 acquires the values of the local host name 7502 and local path name 7503 associated with the global name included in the request from the namespace management table 750, and uses the acquired values as the local host name and the local host name. Reply as a path name.

The file access control unit 110 receives the local host name and local path name, and then proceeds to step S402.

The information acquired in step S451 is used when acquiring the access target file.

As described above, according to the second embodiment, the present invention can be applied to a computer system in which files stored in a tiered storage are managed in an integrated manner.

Especially, in a computer system that handles a large amount of data, it is necessary to grasp the contents of the file and the location of the core of the file, and the computer system as described above is necessary. Therefore, it is possible to expand the system within the applicable range.

[Example 3]

In the first embodiment, the migration candidate file is selected based on the operation information of the front-end file server 1. That is, the operation information of the file server from which the file is moved is used.

A more appropriate transfer candidate file can be selected by considering the operation information of the back-end file server 2 to which the file is moved and the operation information of other components included in the computer system. As a result, the computer resources available in the computer system can be used more effectively.

The third embodiment is different from the first embodiment in that the migration candidate file is selected based on the operation information of each file server constituting the tiered storage. Hereinafter, the third embodiment will be described with a focus on differences from the first embodiment, with reference to FIGS. 20 to 22.

Since the configuration of the computer system of the third embodiment is the same as that of the first embodiment, description thereof is omitted. Since the hierarchical storage configuration management table 150, the file correspondence management table 152, the stored file management table 154, and the file migration management table 155 are the same as those in the first embodiment, the description thereof is omitted.

FIG. 20 is an explanatory diagram showing a configuration example of the operation management table 153 according to the third embodiment of the present invention.

Here, the difference from the operation management table 153 in the first embodiment shown in FIG. 6 will be mainly described. As illustrated in FIG. 20, the operation management table 153 according to the third embodiment includes a machine name 1537.

The machine name 1537 stores identification information of a machine from which operation information is acquired. The same machine name 1537 as the tier name 1501 and storage identification information 1502 of the tier storage configuration management table 150 may be used.

Here, the machine for which the operation information is acquired may be a component that is included in the computer system such as a file server or a storage system and that can acquire the operation information.

By adding the machine name 1537, the operation information for each machine can be grasped by associating and managing the operation information of a plurality of machines.

It should be noted that information indicating that the front end file server 1 itself is stored in the machine name 1537 of the record of the front end file server 1 may be stored. In FIG. 20, “Local” is stored as an example of the information described above.

21A and 21B are explanatory diagrams illustrating a configuration example of the movement condition management table 151 according to the third embodiment of the present invention.

Here, the description will focus on differences from the movement condition management table 151 in the first embodiment shown in FIG. In the third embodiment, the contents stored in the condition 1513 and the action 1514 are different.

In condition 1513, information for specifying a machine that is a target of an index used for determination is added. In the example illustrated in FIG. 21A, the condition “Local HDD usage rate is 80% or more” is stored in the condition 1513 of the record whose condition management number 1511 is “1” and the determination order 1512 is “1”. That is, the front-end file server 1 is designated as an index target used for determination.

The same applies to other record conditions. Thereby, it is possible to realize the determination of the condition using the operation information of a plurality of machines.

An example of determination conditions using operation information obtained from other than the front-end file server 1 will be described. Here, description will be made using a record in which the condition management number 1511 is “1” and the determination order 1512 is “2”, and a record in which the condition management number 1511 is “1” and the determination order 1512 is “3”.

The condition 1513 of the record with the condition management number 1511 being “1” and the determination order 1512 being “2” is set with the conditions “Local HDD usage rate is 80% or more” and “Tier2 HDD usage rate is 80% or more”. Is done. Further, the condition 1513 of the record with the condition management number 1511 being “1” and the determination order 1512 being “3” is “Local HDD usage rate is 80% or more” and “Tier2 HDD usage rate is less than 80%”. A condition is set.

The content of the action 1514 of the record in which the condition management number 1511 is “1” and the determination order 1512 is “3” is the same as that in the first embodiment.

The contents different from those in the first embodiment are also stored in the action 1514 of the record in which the condition management number 1511 is “1” and the determination order 1512 is “2”. Specifically, an action “move a plurality of files stored in the back-end file server B to the back-end file server C until the HDD usage rate of the server becomes less than 60% as pre-file move processing” 1514 is added.

In the third embodiment, the movement candidate file selection process is changed to realize the action 1514 described above. Specific changes will be described later.

By executing “file move pre-processing”, it becomes possible to move files that make the most of the computer resources of the computer system in consideration of the operation information of machines (file servers) other than the front-end file server 1.

Specifically, if the HDD capacity of the destination file server is not sufficient, the HDD capacity of the destination file server can be increased by moving the file stored in the file server to another file server. You can move the file at a later stage.

Note that the back-end file server C has the same configuration as the back-end file server 2 and is a lower-level file than the back-end file server B (2-2).

FIGS. 22A and 22B are flowcharts for explaining the movement candidate file selection processing according to the third embodiment of the present invention.

Here, differences from the migration candidate file selection process of the first embodiment shown in FIG. 11 will be described.

After the process of step S205, the process of step S251 is newly executed.

The file movement control unit 130 determines whether or not to execute the file movement pre-processing (step S251).

Specifically, the determination unit 132 determines whether to execute the file movement pre-processing based on the processing content of the movement processing determined in step S203.

If it is determined not to execute the file move pre-processing, the file move control unit 130 proceeds to step S205.

When it is determined that the file movement pre-processing is to be executed, the file movement control unit 130 executes the file movement pre-processing (step S253).

Specifically, the file movement control unit 130 refers to the processing contents of the movement processing determined in step S203, confirms the processing contents of the file movement pre-processing, and executes the file movement pre-processing according to the processing contents. .

Note that the front-end file server 1 may perform the file movement pre-processing as the main body, or may request the back-end file server 2 to be processed to execute the process.

For example, consider a process of moving a file stored in the back-end file server B (2-2) to the back-end file server C as a file pre-migration process. In this case, the front-end file server 1 reads the file from the back-end file server B (2-2), and stores the read file in the back-end file server C. Further, the front-end file server 1 deletes the file read from the back-end file server B (2-2). Further, the front-end file server 1 stores the file movement result in each management table.

After the process of step S253 is complete | finished, the file movement control part 130 progresses to step S207.

As described above, according to the third embodiment, a migration candidate file can be selected in consideration of operation information of components other than the front-end file server 1. Further, by utilizing various operation information such as a file server at the destination, metadata transfer control can be further enhanced.

Especially, according to the operating status of the file server to which the file is to be moved, it is possible to change the destination and to perform file movement pre-processing for reducing the load on the destination file server. As a result, the computer resources of the entire computer system can be used effectively and efficiently.

The various software illustrated in the present embodiment can be stored in various recording media (for example, non-temporary storage media) such as electromagnetic, electronic, and optical, and through a communication network such as the Internet. It can be downloaded to a computer.

Furthermore, in this embodiment, an example using control by software has been described, but part of it can also be realized by hardware.

Although the present invention has been described in detail with reference to the accompanying drawings, the present invention is not limited to such specific configurations, and various modifications and equivalents within the spirit of the appended claims Includes configuration.

Claims

A computer system comprising a plurality of computers,
Each of the plurality of computers has a processor, a main storage device, a secondary storage device, and an interface for communicating with other computers,
At least one calculator
A buffer for temporarily storing a file received from an external device connected via the interface;
A data storage area for storing the file;
A file management unit for managing the file;
A file access control unit for controlling access to the file;
A metadata generation unit that acquires metadata by analyzing the file, and generates a metadata file using the acquired metadata;
Have
The metadata generation unit
Obtain operational information indicating the operational state of the computer that received the file, and determine whether to generate the metadata file based on the obtained operational information,
If it is determined to generate the metadata file, the metadata is obtained from the file stored in the buffer;
Generating the metadata file based on the acquired metadata;
Storing the generated metadata file in the data storage area;
A computer system, wherein information for accessing the file is added to a metadata file stored in the data storage area.
The computer system according to claim 1,
The at least one computer is:
A file movement control unit is provided that selects a candidate file to be moved to another computer from the file and the metadata file stored in the data storage area, and moves the selected candidate file to the other computer. And
Operation condition management information including information associated with the operating condition of the computer that has received the file and the processing content of the file movement process;
The file migration management information including information associated with the identification information of the candidate file, the migration state of the candidate file, and the identification information of the computer that is the migration destination of the candidate file,
The file movement control unit
Obtain the operating information of the computer that received the file,
Based on the movement condition management information and the acquired operation information, determine the file movement processing applicable in the computer that has received the file,
Select the candidate file from the file or the metadata file stored in the data storage area,
Update the file movement management information based on the identification information of the selected candidate file and the processing content of the determined file movement process,
A computer system that executes file migration processing on the candidate file based on the file migration management information.
The computer system according to claim 2,
The metadata generation unit
Based on the movement condition management information and the acquired operation information, determine whether to store the file stored in the buffer in the data storage area,
If it is determined not to store the file stored in the buffer, information for accessing the file stored in at least one of the external device and the other computer is added to the metadata file,
Delete the file stored in the buffer;
The file movement control unit
When the determined file movement process is a process of moving only the metadata file and deleting the file, information for accessing a file stored in at least one of the external device and the computer Add to the metadata file,
A computer system for deleting a file stored in the data storage area.
The computer system according to claim 3,
The metadata generation unit
Select a file to be processed from a plurality of files stored in the buffer,
Determining whether the selected file is closed;
If it is determined that the selected file is in a closed state, the metadata is obtained by analyzing the selected file;
When it is determined that the selected file is not closed, the identification information of the selected file is changed,
Generating a new file with the same identification information as the selected file identification information;
A computer system, wherein the metadata is obtained by analyzing the selected file.
The computer system according to claim 3,
The computer system characterized in that the information for accessing the file added to the metadata file is a URL for accessing a file stored in the external device or the other computer.
The computer system according to claim 2,
The movement condition management information further includes information associating operation condition of the plurality of computers and processing contents of the file movement process,
The file movement control unit
Obtaining the operation information of the plurality of computers;
A computer system, wherein the file movement process is determined based on the movement condition management information and the acquired operation information.
A metadata management method in a computer system including a plurality of computers,
Each of the plurality of computers has a processor, a main storage device, a secondary storage device, and an interface for communicating with other computers,
At least one calculator
A buffer for temporarily storing a file received from an external device connected via the interface;
A data storage area for storing the file;
A file management unit for managing the file;
A file access control unit for controlling access to the file;
A metadata generation unit that acquires metadata by analyzing the file, and generates a metadata file using the acquired metadata;
Have
The method
The metadata generation unit acquires operating information indicating an operating state of a computer that has received the file, and determines whether to generate the metadata file based on the acquired operating information Steps,
A second step of acquiring the metadata from the file stored in the buffer when the metadata generation unit determines to generate the metadata file;
A third step in which the metadata generation unit generates the metadata file based on the acquired metadata;
A fourth step in which the metadata generation unit stores the generated metadata file in the data storage area;
A metadata management method comprising: a fifth step in which the metadata generation unit adds information for accessing the file to a metadata file stored in the data storage area.
The metadata management method according to claim 7, wherein
The at least one computer is:
A file movement control unit is provided that selects a candidate file to be moved to another computer from the file and the metadata file stored in the data storage area, and moves the selected candidate file to the other computer. And
Operation condition management information including information associated with the operating condition of the computer that has received the file and the processing content of the file movement process;
The file migration management information including information associated with the identification information of the candidate file, the migration state of the candidate file, and the identification information of the computer that is the migration destination of the candidate file,
The method
A sixth step in which the file movement control unit acquires the operation information of the computer that has received the file;
A seventh step in which the file movement control unit determines the file movement process applicable in the computer that has received the file, based on the movement condition management information and the acquired operation information;
An eighth step in which the file movement control unit selects the candidate file from the file or the metadata file stored in the data storage area;
A ninth step in which the file movement control unit updates the file movement management information based on the identification information of the selected candidate file and the processing content of the determined file movement process;
A metadata management method comprising: a tenth step in which the file movement control unit executes a file movement process on the candidate file based on the file movement management information.
The metadata management method according to claim 8, wherein
The method
After the fifth step, the metadata generation unit
Determining whether to store the file stored in the buffer in the data storage area based on the movement condition management information and the acquired operation information;
When it is determined that the metadata generation unit does not store the file stored in the buffer, information for accessing the file stored in at least one of the external device and the other computer is stored in the metadata. Adding to the data file;
The metadata generation unit deleting the file stored in the buffer,
The tenth step includes
In order to access a file stored in at least one of the external device and the computer when the processing content of the determined file moving process is a process of moving only the metadata file and deleting the file Adding information to the metadata file;
Deleting the file stored in the data storage area. A metadata management method comprising:
The metadata management method according to claim 9, comprising:
The second step includes
Selecting a file to be processed from a plurality of files stored in the buffer;
Determining whether the selected file is closed;
Obtaining the metadata by analyzing the selected file if it is determined that the selected file is closed; and
If it is determined that the selected file is not in a closed state, changing the identification information of the selected file;
Generating a new file with the same identification information as the identification information of the selected file;
Obtaining the metadata by analyzing the selected file. A metadata management method comprising:
The metadata management method according to claim 9, comprising:
The metadata management method characterized in that the information for accessing the file added to the metadata file is a URL for accessing a file stored in the external device or the other computer.
The metadata management method according to claim 8, wherein
The movement condition management information further includes information associating operation condition of the plurality of computers and processing contents of the file movement process,
The file movement control unit
In the sixth step, the operation information of the plurality of computers is acquired,
In the seventh step, the file movement process is determined based on the movement condition management information and the acquired operation information.
A program executed by a computer that manages a plurality of files,
The computer has a processor, a main storage device, a secondary storage device, and an interface for communicating with other computers,
On the main storage device, there is a buffer for temporarily storing a file received from an external device connected via the interface,
The secondary storage device has a data storage area for storing the file,
The program is
Determine whether or not to generate a metadata file generated from metadata acquired by analyzing the file based on the acquired operating information and acquiring operating information indicating an operating state of the computer A first procedure to:
A second procedure for obtaining the metadata from the file stored in the buffer when it is determined to generate the metadata file;
A third procedure for generating the metadata file based on the acquired metadata;
A fourth procedure for storing the generated metadata file in the data storage area;
A program that causes the computer to execute a fifth procedure of adding information for accessing the file to a metadata file stored in the data storage area.
The program according to claim 13,
The calculator is
Operation condition management information including information associated with the operating condition of the computer that has received the file and the processing content of the file movement process;
Identification information of candidate files to be moved from the file and the metadata stored in the data storage area to another computer, a movement state of the candidate file, and identification information of the computer to which the candidate file is moved And file movement management information including information associated with
The program is
A sixth procedure for acquiring the operation information of the computer that has received the file;
A seventh procedure for determining the file movement process applicable in the computer that has received the file, based on the movement condition management information and the acquired operation information;
An eighth procedure for selecting the candidate file from the file or the metadata file stored in the data storage area;
A ninth procedure for updating the file movement management information based on the identification information of the selected candidate file and the processing content of the determined file movement process;
And a tenth procedure for executing a file move process on the candidate file based on the file move management information.
The program according to claim 14, wherein
A step of determining whether to store the file stored in the buffer in the data storage area based on the movement condition management information and the acquired operation information after the fifth procedure;
A procedure for adding information for accessing the file stored in at least one of the external device and the other computer to the metadata file when it is determined not to store the file stored in the buffer; ,
Deleting the file stored in the buffer,
The tenth procedure includes
In order to access a file stored in at least one of the external device and the computer when the processing content of the determined file moving process is a process of moving only the metadata file and deleting the file Adding information to the metadata file;
And a procedure for deleting a file stored in the data storage area.