WO2017109862A1 - データファイル管理方法、データファイル管理システム、およびアーカイブサーバ - Google Patents

データファイル管理方法、データファイル管理システム、およびアーカイブサーバ Download PDF

Info

Publication number
WO2017109862A1
WO2017109862A1 PCT/JP2015/085859 JP2015085859W WO2017109862A1 WO 2017109862 A1 WO2017109862 A1 WO 2017109862A1 JP 2015085859 W JP2015085859 W JP 2015085859W WO 2017109862 A1 WO2017109862 A1 WO 2017109862A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
server
data file
archive
data
Prior art date
Application number
PCT/JP2015/085859
Other languages
English (en)
French (fr)
Inventor
山本　健太郎
信之 雜賀
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2015/085859 priority Critical patent/WO2017109862A1/ja
Publication of WO2017109862A1 publication Critical patent/WO2017109862A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures

Definitions

  • the present invention relates to a data management method and a data management system in an information processing system.
  • the present invention relates to a technique for managing data in a plurality of storage systems connected via a network.
  • a data file is stored at the edge while it is frequently used. When the frequency of use decreases, it moves to the core for archiving purposes and is stored. Data movement is called “migration”. The moved data is also called archive data.
  • archive data When the data file is archived, data for accessing the archive data is stored at the edge. This data includes, for example, a file path name indicating the location of the data file stored in the core. Such data is referred to as “stub information”, or “stub” or “stub data” (see, for example, Patent Document 1).
  • edge data is migrated to the core and archived at predetermined time intervals (for example, one day), for example.
  • Such an operation is referred to as “periodic migration”.
  • the edge data file disappears during the time interval after creation of the archive data file, there is a possibility that a part of the data may be lost even if the archive data is restored. Therefore, when data is newly created or updated, it is ideal to create archive data immediately to ensure data safety.
  • Such an operation is called “immediate migration”.
  • the migration time interval is shortened and the redundancy is increased, the overhead increases.
  • This invention is made in view of such a situation, and makes it a subject to raise the safety
  • a first step in which the first file server newly stores or updates a data file in the first file server and transmits the data file to the archive server, and the archive server includes: A second step of storing the received data file and transmitting the information for accessing the management information of the data file in the archive server to the first file server as stub information; and the first file server receiving the received stub information
  • Information for accessing file management information reverse stub information Has a fifth step of transmitting to the archive server and the archive server, a sixth step of storing the inverse stub information received, the.
  • Another aspect of the present invention is a data management system in which a first file server, a second file server, and an archive server are connected via a network.
  • the first file server stores the data file newly in the first file server or sends the data file to the archive server when updated, and the archive server sends the received data file to the archive server.
  • the information for storing and accessing the management information of the data file in the archive server is transmitted to the first file server as stub information, the first file server stores the received stub information, and the archive server receives the received data
  • the file is transmitted to the second file server, the second file server stores the received data file, and transmits information for accessing the management information of the data file in the second file server to the archive server as reverse stub information.
  • Archive server received reverse stub To store the broadcast.
  • Another aspect of the present invention is an archive server in a data management system in which a first file server, a second file server, and an archive server are connected via a network.
  • this server the data file received from the first file server is stored, an archive inode table as management information of the stored data file is created, and information for accessing the archive inode table is used as stub information as the first file server.
  • the data file received is transmitted to the second file server, and the reverse stub information for accessing the inode table, which is the management information of the data file received from the second file server, is stored in association with the stub information.
  • FIG. 1 is a block diagram showing an example software configuration of a system according to an embodiment of the present invention.
  • Conceptual diagram showing examples of inode management table and archive inode management table
  • Conceptual diagram showing additional file system parameters Flow chart explaining the processing of the example when creating a new file Flow chart explaining processing of the embodiment at the time of file update
  • Conceptual diagram explaining edge selection policy Flow chart of regular migration processing for general files
  • Flow chart showing an example of restore processing
  • Flow chart showing another example of restore processing Flow chart of reverse stub deletion process
  • notations such as “first”, “second”, and “third” are attached to identify the constituent elements, and do not necessarily limit the number or order.
  • a number for identifying a component is used for each context, and a number used in one context does not necessarily indicate the same configuration in another context. Further, it does not preclude that a component identified by a certain number also functions as a component identified by another number.
  • the archive server (referred to as “core”) stores a reverse stub for referring to the backup data.
  • the file server includes a file storage device and a RAID device attached to or included in the file storage device.
  • the archive server includes an archive device and a RAID device attached to or included in the archive device. Focusing on the function of storing file server data, in particular, it may be referred to as “file storage”. In particular, focusing on the function of storing data of the archive server, it may be referred to as “archive storage”.
  • FIG. 1 is a diagram showing a hardware configuration of an embodiment of the present invention.
  • a plurality of edges 101 ⁇ / b> A and 101 ⁇ / b> B arranged at each site and the core 105 are connected via the network 108.
  • the network 108 may be a dedicated line or may use the Internet. Since a plurality of edges 101 may be connected, when it is necessary to distinguish a plurality of edges, alphabetic suffixes such as A and B are attached to the edges and their constituent elements.
  • Each of the edges 101 includes, for example, a client device 102, a file storage device 103, and a redundant array-of-inexpensive disk (RAID) device 104.
  • the client device 102 is a so-called computer, and includes a memory 1021, a processing device (CPU) 1022, a network interface card (NIC) 1023 for communicating with other devices, a built-in disk (device) 1024, and the like.
  • an input / output device such as a keyboard or a display device, which is usually provided as a computer, is provided.
  • the file storage device 103 is a computer that mainly stores data, such as a memory 1031, a CPU 1032, a NIC 1033, an internal disk 1034, a host bus adapter (HBA) 1035 that is hardware for connecting other network devices and storage devices, and the like. Is provided.
  • HBA host bus adapter
  • the RAID device 104 is a device that mainly stores data, a channel adapter 1041 for transmitting / receiving data to / from other devices, a memory 1042 for temporarily storing data, a CPU 1043, and a controller for controlling a disk device 1044 and disk devices 1045 and 1046 are provided.
  • the memory 1042 is configured by a semiconductor memory, for example.
  • the disk devices 1045 and 1046 are configured by a magnetic disk device or a nonvolatile semiconductor memory. In FIG. 1, two disk devices 1045 and 1046 are depicted, but there may be one, or three or more.
  • the edge 101 is arranged at each base of a company, and performs necessary processing by storing necessary data in the file storage device 103 or the RAID device 104 when the client device 102 performs necessary work.
  • one core 105 is connected to a plurality of edges 101 constituting a group, and includes an archive device 106 and a RAID device 107.
  • the archive device 106 is a so-called server, and controls the RAID device 107 and transmits / receives data to / from the edge 101.
  • the archive device 106 includes a memory 1061, a CPU 1062, a NIC 1063, a built-in disk 1064, an HBA 1065, and the like.
  • an input / output device such as a keyboard and a display device, which is normally provided as a server, is provided.
  • the RAID device 107 is a device that mainly performs edge data backup and archive storage, a channel adapter 1071 for transmitting / receiving data to / from other devices, a memory 1072 for temporarily storing data, a CPU 1073, a disk A controller 1074 for controlling the device and disk devices 1075 and 1076 are provided. Other configurations may be the same as those of the RAID device 104.
  • FIG. 2 is a diagram showing a software configuration of the embodiment of the present invention.
  • the client device 102, the file storage device 103, the RAID device 104, the archive device 106, and the RAID device 107 which are hardware components, include a processing device (CPU), a memory, a built-in disk, and the like. Storage device, an input device, and an output device.
  • these hardware components are collectively referred to as an “information processing apparatus”.
  • functions such as calculation and control are realized in cooperation with other hardware by executing software (program) stored in the storage device by the CPU.
  • a program executed by the information processing apparatus, its function, or means for realizing the function may be referred to as “function”, “means”, “unit”, “unit”, “module”, or the like.
  • program may be used as the subject, but the program is executed by the CPU, and the specified processing is performed by the memory and communication port (NIC, HBA, channel adapter, etc.). Since it is performed while being used, the description may be based on the CPU. Further, the processing disclosed with the program as the subject may be processing performed by the information processing apparatus. Further, part or all of the program may be realized by dedicated hardware.
  • the various programs may be installed in each information processing apparatus by a program distribution server or a storage medium that can be read by the information processing apparatus.
  • the information processing apparatus may include an input / output device. Examples of input / output devices include a display, a keyboard, and a pointer device, but other devices may be used.
  • the client device 102 includes an application for the client to perform a desired process such as spreadsheet or data processing, and a Web browser 2021. Further, an operation system (OS) 2022 for operating these is provided. Known software can be used for these.
  • OS operation system
  • the file storage apparatus 103 includes a file sharing system 2031, a file system program 2032, a data mover program 2033, a kernel and a device driver 2034.
  • a file sharing system 2031 for example, known CIFS (Common Internet File System) or NFS (Network File System) can be used.
  • the kernel and the device driver 2034 link hardware and software, and a known configuration can be used.
  • the file system program 2032 manages data by abstracting and storing data stored in the form of binary data into a file that is easy to understand for humans, and a known configuration can be used.
  • the data mover program 2033 which will be described in detail later, is a program for managing the inode management table, performing migration, creating stubs, and controlling data exchange with the core.
  • each program is described separately for convenience, but as a configuration example, for example, the file system program 2032 and the data mover program 2033 may be integrated into the file storage apparatus 103 to have the same function. Good.
  • the function of the file storage apparatus 103 may be described as being representatively realized by the data mover program 2033 for convenience.
  • the RAID device 104 includes a RAID control program 2041 and an RTOS (Real-time operating system) 2042. For both software and hardware, the RAID device 104 can use a known configuration.
  • RTOS Real-time operating system
  • the archive device 106 includes an archive program 2061 and a file system program 2062.
  • the file system program 2062 is the same as the file system program 2032.
  • the kernel and device driver 2063 are the same as the kernel and device driver 2034.
  • the archive device 106 includes an archive program 2061.
  • the archive program 2061 is a program for managing the inode management table, performing migration, creating a reverse stub, and controlling the exchange of data with the edge.
  • the respective programs are described separately for convenience.
  • the file system program 2062 and the archive program 2061 may be integrated and the archive device 106 may have the same function.
  • the function of the archive device 106 may be described as being realized by the archive program 2061 for the sake of convenience.
  • the RAID device 107 includes a RAID control program 2071 and an RTOS 2072. For both the software and hardware, the RAID device 107 can use a known configuration.
  • FIG. 3 is a conceptual diagram showing an example of inode management tables 310A and 310B managed by the data mover programs 2033A and 2033B included in the edge 101A and the edge 101B. Also, it is a conceptual diagram showing an example of an archive inode management table 330 managed by the archive program 2061 provided in the core 105.
  • FIG. 3 is a conceptual diagram showing an example of inode management tables 310A and 310B managed by the data mover programs 2033A and 2033B included in the edge 101A and the edge 101B. Also, it is a conceptual diagram showing an example of an archive inode management table 330 managed by the archive program 2061 provided in the core 105.
  • FIG. 3 is a conceptual diagram showing an example of inode management tables 310A and 310B managed by the data mover programs 2033A and 2033B included in the edge 101A and the edge 101B. Also, it is a conceptual diagram showing an example of an archive inode management table 330 managed by the archive program 2061 provided in
  • the inode management table or the archive inode management table is created and stored in the built-in disks 1034 and 1064 included in the edge 101 and the core 105 under the control of the data mover programs 2033A and 2033B or the archive program 2061.
  • the inode management table stores attributes and management information (management data) for each data file.
  • the inode management table 310A included in the edge 101A includes an inode number 311A for uniquely specifying a data file, a file path name 312A for accessing management information of the inode number, an importance flag 313A indicating the importance of data, and data Last update time 314A.
  • the importance level flag 313A may be a flag indicating whether or not the level is important, or may be a numerical value indicating the level of importance step by step.
  • the inode management table 310A further includes a stubbing prohibition flag 315A, a stubbing flag 316A, and a storage destination URL 317A.
  • “Stubbing” is an operation of storing the actual data in the core 105 and leaving only the management information in the edge 101 to reduce the data usage.
  • the stubbing prohibition flag 315A is ON, stubbing of this data file is prohibited.
  • the stubbing flag 316A is turned ON. In the example of FIG. 3, since the stubbing prohibition flag 315A is OFF, stubbing is possible, and since the stubbing flag 316A is ON, it indicates that stubbing is performed. Then, the stubbed actual data can be called by specifying the file path name 332 (described later) of the core 105 by referring to the storage destination URL 317A.
  • the block address 318-320 of the inode management table 310 indicates an address where actual data is stored.
  • the actual data is stored in the disk devices 1045-1046 of the RAID device 104A.
  • the actual data is stubbed, and the actual data no longer exists at the edge 101A. Therefore, a NULL value is stored in the block addresses 318-320.
  • the archive inode management table 330 provided in the core 105 includes an inode number 331 for uniquely specifying a data file, a file path name 332 for accessing management information of the inode number, an importance flag 333 indicating the importance of data, It has a data last update time 334.
  • the importance flag 313 stores a copy of the importance flag 313 of the edge 101A that is the original origin of the data file.
  • the archive inode management table 330 includes reverse stub storage URLs 335-337.
  • the “reverse stub” is to store the actual data in the core 105 and further store a copy of the actual data in the other edge 101, thereby improving the safety of the data.
  • Block addresses 338 to 340 in the archive inode management table 330 indicate addresses at which stubbed actual data is stored. In this embodiment, it is assumed that the actual data is stored in the RAID device 107. Also, the edge information 341 indicates from which edge the stubbed actual data is data.
  • the format of the inode management table 310B included in the edge 101B is the same as that of the inode management table 310A of the edge 101A, a duplicate description is omitted.
  • a copy of actual data stored in the core 105 is stored in the edge 101B, and the state of the inode management table 310B in that case will be described.
  • the file path name 312B of the inode management table 310B is stored in the storage destination URL 335 of the archive inode management table 330. Therefore, the data of the corresponding inode management table 310B can be referred from the core 105. Actual data obtained from the core 105 is stored in a storage area indicated by block addresses 318B-320B. Therefore, by referring to the value of the block address 318B-320B, the actual data stored in the disk devices 1045-1046 of the RAID device 104B can be accessed.
  • the importance 313B is a copy of the importance 333.
  • the data file with the inode number “1” in the inode management table 310B is a copy of the data file stored in the core 105 itself. Therefore, it is not necessary to stub again, and erasure is impossible because it is for backup purposes. Accordingly, the stubbing prohibition flag 315B is turned ON. Since stubbing is not performed, the stubbing flag 316B is OFF, and the storage destination URL 317B is blank or an invalid value. Normally, this data file is configured as a hidden file that is invisible to the client.
  • the data destruction 360 even if the actual data held by the core 105 is destroyed, the actual data stored in the edge 101B by the reverse stub 335-337 is used. Data can be used safely.
  • FIG. 4 shows another example of the archive inode management table 330 that the core 105 has.
  • an additional parameter 402 is added to the inode information 401 by introducing a reverse stub.
  • description of the same items as in FIG. 3 is omitted, but in the configuration of FIG. 4, a backup expiration date 403 is added.
  • the backup expiration date 403 is data for managing the expiration date of the reverse stub. Since it is considered that the importance of an old data file decreases, it is possible to save the storage capacity of the storage device by deleting the data file whose expiration date has passed.
  • FIG. 5 is a diagram for explaining the flow of processing S500 when a data file is newly created and stored in the system including the edges 101A and 101B and the core 105 described with reference to FIGS.
  • the operation of the edge 101 is controlled by the data mover program 2033 of the file storage device 103, and the operation of the core 105 is performed by the archive device 106. It will be described as being controlled by the archive program 2061.
  • these programs can be separated into a plurality of programs.
  • the edge 101A accepts a data file creation request. This may be linked to a file creation request by various known applications 2021 executed by the client apparatus 102A, or may be a dedicated program.
  • the created data file is newly stored.
  • actual data is stored in the RAID device 104A.
  • the data mover program 2033A of the edge 101A creates a new entry in the inode management table 310A.
  • the inode number 311A and the file path name 312A need only be uniquely determined, for example, consecutive numbers.
  • the importance 313A of the inode management table 310A may be input by the operator when a file creation request is made, or may be determined in advance corresponding to the type of application that created the data. In this case, a table storing the correspondence between application types and importance levels may be separately prepared and referenced. Further, the block address 318A-320A stores the address of the RAID device 104A where the actual data is recorded.
  • process S503 the time when the data is created or stored is set as the last update time 314A.
  • process S504 the importance 313A of the inode management table 310A is checked to determine whether it is an important file.
  • process S505 if the determination result is not an important file, the reverse stub setting process is not performed. In this case, data is transferred to the core 105 and recorded by regular migration (for example, once a day) using a known technique.
  • process S506 if the determination result is an important file, the data file is transmitted from the edge 101A to the core 105. At this time, the importance 313A, the last update time 314A, and information for specifying the own edge are also added and transmitted as necessary.
  • the core 105 that has received the important data file stores the data file in the RAID device 107 by the archive program 2061 of the archive device 106. Further, the archive program 2061 creates an archive inode management table 330. An inode number 331 and a file path name 332 are assigned to the archive inode management table 330. In the archive inode management table 330, the received importance is stored as the importance 333, and the received last update time is stored as the last update time 334. Further, information for specifying the source edge is stored as edge information 341. Block addresses 338 to 340 store the addresses of the disk devices 1075 and 1076 of the RAID device 107 storing the data file.
  • the core 105 reports the completion of migration to the edge 101A, and notifies the file path name 332.
  • the edge 101A that has received the file path name 332 stores the received file path name 332 in the storage destination URL 317 of the inode management table 310. Further, the stubbing flag 316 is turned ON.
  • the edge 101A transmits a reverse stub creation request to the core 105.
  • a backup expiration date may be added when sending the reverse stub creation request.
  • the backup expiration date can be set by the application program that created the data file. Alternatively, the user may set from an interface provided by the data mover program 2033.
  • the backup expiration date is stored in the backup expiration date 403 of the archive inode management table 330 of the core 105.
  • the archive program 2061 of the core 105 designates the candidates of the edge 101 that are designated by reverse stubs and used for data file backup according to the policy.
  • a policy for selecting a candidate an arbitrary policy such as an order of higher specifications or an order of larger free space can be adopted. The selection of the edge will be described later with reference to FIG.
  • process S510 the archive program 2061 of the core 105 transfers the data file to the selected edge 101B.
  • the importance 333 and the last update time 334 are also added and transmitted as necessary.
  • the edge 101B receives the data file from the core 105.
  • the data mover program 2033B of the edge 101B stores the data file in the RAID device 104B.
  • the inode management table 310B is generated in the internal disk 1034B of the file storage device 103B.
  • An inode number 311B and a file path name 312B are assigned to the inode management table 310B.
  • the received importance is stored as the importance 313B
  • the received last update time is stored as the last update time 314B.
  • the stubbing prohibition flag 315B is turned on and the stubbing flag 316B is turned off.
  • the block address 318B-320B stores the address of the data file storage destination of the RAID device 104B.
  • the file path name 312B is notified to the core 105.
  • the archive program 2061 of the core 105 that has received the file path name stores the file path name of the transmission destination of the data file as the storage destination URL 335 in the archive inode management table 330.
  • process S513 the core 105 reports the completion of the reverse stub setting to the edge 101A.
  • process S5134 the edge 101B reports the reverse stub setting to the administrator.
  • FIG. 6 is a diagram for explaining the flow of processing S600 when an existing data file is updated in the system including the edges 101A and 101B and the core 105 described with reference to FIGS. Since it is basically the same as the processing of FIG. 5, the differences will be mainly described.
  • the edge 101A receives a request to update an existing data file. This can be done by specifying the inode number 311A and the file path name 312A in the inode management table 310A.
  • the data file is updated by the application 2021A of the client apparatus 102A.
  • the data file to be updated is acquired from the RAID device 104A at the edge 101A if a valid address is stored in the block address 318A-320A. If the data file is not stored in the edge 101A, or if the data is corrupted and cannot be read, the data is acquired from the core 105.
  • the acquired data file is temporarily stored in the internal disk 1024A of the client apparatus 102A and updated. A method for acquiring a data file from the core 105 will be described later with reference to FIG.
  • the data mover program 2033A of the file storage apparatus 103A changes the last update time 314A of the inode management table 310A to, for example, the time when a request to update an existing data file is received.
  • the data mover program 2033A of the file storage apparatus 103A checks the importance 313A of the inode management table 310A to determine whether it is an important file.
  • process S605 if the result of determination is that the previous important file is no longer important, immediate migration or reverse stubbing is not performed. Processing of data files that are no longer important will be described later with reference to FIG.
  • the file is not an important file in the past and becomes a new important file, new migration is performed immediately and reverse stubbing is performed in the same manner as in FIG. That is, when a new immediate migration is required, the data file is stored in the RAID device 107 of the core 105 as in the process of FIG. 5 (processes S606-607). If a new reverse stub needs to be created (process S608), a necessary edge is selected (process S609), and the data file is stored in the edge 101B in the same manner as the process of FIG. 5 (process S610-S614). ).
  • the updated data file is stored (overwritten) in the other edge 101B already specified by the storage destination URL 335-337 (process S610). -S614).
  • the same standard is used as the standard for selecting a data file for immediate migration and the standard for selecting a data file for creating a reverse stub. That is, the data file that has been migrated immediately is backed up using a reverse stub.
  • the criteria can be set separately. For example, in the inode management table 310A, a data file having an importance 313A of “5” or higher (assuming that the smaller the numerical value is, the higher the importance) is immediately migrated (processing S506), and the importance 313A is “3” or higher.
  • Different criteria may be used, such as reverse stub creation (process S508) in addition to immediate migration for only data files.
  • FIG. 7 is a conceptual diagram illustrating a method of selecting the edge 101 in which a copy of the data file stored in the core 105 is to be stored when creating the reverse stub.
  • the internal disk 1064 of the archive device 106 stores an importance / performance (SPEC) level / policy table 701, a SPEC level definition table 702, and a SPEC level / edge mapping table 703.
  • SPEC importance / performance
  • the importance / SPEC level policy table 701 defines the required performance and the number of edges to be selected according to the importance of the file. For example, in the example of FIG. 7, for the importance level 3, one unit is selected from the edge of the SPEC level C or D. Such a table is defined and created by the system administrator and is stored in the internal disk 1034 of the file storage apparatus 103.
  • the SPEC level definition table 702 defines correspondence between edge performance and SPEC level. For example, the edge of “memory capacity 96 GB, CPU number 16, hard disk capacity 128 TB, RAID level 6, with remote mirror, line speed 100 Mbps” is defined as SPEC level A.
  • the definition of FIG. 7 is an example, and each performance may be defined by a range instead of a specific value. Further, other performance not shown in FIG. 7 may be used for the definition.
  • Such a table can be defined and created by a system administrator and stored in the file storage apparatus 103.
  • the SPEC level / edge mapping table 703 associates each edge with a SPEC level based on the SPEC level definition table 702, and specifies an edge by a host name.
  • a table can be created by a system administrator by referring to the SPEC level definition table 702 and the performance value of each edge and stored in the file storage apparatus 103.
  • edge performance may be automatically benchmarked by a known method, performance data may be automatically collected, and automatically created by collating with the SPEC level definition table 702.
  • an edge suitable for storing a backup can be selected. Since the edge stored in the SPEC level / edge mapping table 703 assumes that a backup data file is stored, the edge 101 where it is not desirable to store the backup data file is excluded in advance. Also good.
  • the archive program 2061 of the core 105 selects an edge according to a policy (processing S509 and S609).
  • the archive program 2061 refers to the importance / SPEC level / policy table 701.
  • the edge selection policy corresponding to the importance “3” is one from the edge of the SPEC level “C” or “D”. Therefore, referring to the SPEC level / edge mapping table 703, for example, one unit is randomly selected from the edges classified into the SPEC level “C” or “D”. In the example of FIG. 7, one unit is selected from “eeff”, “gghh”, and “hhii”. Instead of selecting at random, it may be selected in the order of higher or lower level.
  • FIG. 8 is a flowchart of periodic migration for the data file (general data file) determined to be unimportant in the processes S505 and S605 of FIGS.
  • the data file is stored in the edge 101 and a copy is stored (migrated) in the core 105 and archived (processing S801).
  • the updated file is periodically migrated (periodic migration).
  • the regular migration is performed at intervals such as once a day, for example.
  • the immediate migration described with reference to FIGS. 5 and 6 is performed.
  • regular migration is performed. That is, for example, the data file is backed up to the core 105 at a predetermined timing such as once a day. At this time, new files and update files may be preferentially migrated, but if the data file is broken before the migration timing, there is a possibility that the latest data file cannot be recovered.
  • Process S803 is deletion and stubbing of a file that targets an unimportant file.
  • a data file that has not been updated for a certain period of time for example, a data file that is not prohibited from being stubbed, is deleted from the edge, the data is backed up to the core, and then the stub data Leave on the edge.
  • Whether it matches the policy can be determined by referring to the last update time 314 and the stubification prohibition flag 315 in the inode management table 310. For example, a data file whose stubbing prohibition flag 315 is OFF and whose last update time 314 is more than a predetermined time is stubbed.
  • the data mover program 2033 transmits the data file stored in the disk devices 1045 and 1046 of the RAID device 104A to the core 105.
  • the archive program 2061 of the core device 105 stores the received data file in the disk devices 1075 and 1076 of the RAID device 107.
  • the data file stored in the disk devices 1045 and 1046 of the RAID device 104A is deleted by the data mover program 2033, and a NULL value is stored in the block addresses 318-320 of the inode management table 310. Further, the stubbing flag 316 is turned ON, and the file / path name 332 indicating the storage destination edge is stored in the storage destination URL 317.
  • FIG. 9 is a diagram showing a processing flow when the edge 101A receives a read request for a data file.
  • the inode management tables 310A and 310B included in the edges 101A and 101B and the archive inode management table 330 included in the core 105 are readable.
  • Processing S901 is reception of a data file read request. Normally, a data file is requested by various applications 2021 of the client apparatus 102A.
  • the data mover program 2033 refers to the stubification flag 316A of the inode management table 310A and checks whether the data file is stubbed.
  • step S904 the data mover program 2033 acquires the data file held by the RAID device 104A of the edge 101A based on the block address 318A-320A of the inode management table 310A, and sends it to the request source in process S905. If the local file cannot be acquired, an error is returned to the request source and the process ends.
  • the case where the local file cannot be acquired is when the data file held by the RAID device 104A is destroyed or when the block address 318A-320A of the inode management table 310A is destroyed.
  • the data mover program 2033 refers to the storage destination URL 317A of the inode management table 310A and issues a file acquisition request to the core 105 together with the storage destination URL. Even if the data file is stubbed, if the data file is stored in the RAID device 104A, it may be read out. However, when the data file of the RAID device 104A is destroyed or erased, the file is acquired from the core 105.
  • the archive program 2061 of the archive device 106 of the core 105 searches for the file / path name 332 corresponding to the received storage destination URL 317A in the archive inode management table 330 in process S907, and refers to the block addresses 338-340. To do. Then, the data file is read from the corresponding block address of the disk devices 1075 and 1076 of the RAID device 107.
  • process S908 the presence or absence of a read error is checked. If there is no error, the data file is transmitted to the edge 101A in process S909.
  • the edge 101A checks whether there is an error (process S910). If there is no error, the received data file is stored in the internal disk 1034 of the file storage apparatus 103A (process S911), and the data file is sent to the request source (process S905). ). If necessary, the data file is stored in the internal disk 1024 of the client apparatus 102A or the disk apparatuses 1045 and 1046 of the RAID apparatus 104A accessed by the application 2021 as the request source.
  • step S908 the archive program 2061 checks whether the data file is important in step S912. For this purpose, the importance 333 of the archive inode management table 330 is referred to. If the data file is not important, the data file cannot be restored, and the core 105 transmits an error to the edge 101 (processing S913). The edge 101 that has received the error receives an error determination in step S910, and ends the process as an error (step S914).
  • the case where there is a read error in the processing S908 is a case where the data file held by the RAID device 107 is destroyed or a case where the block addresses 338A-340A of the archive inode management table 330A are destroyed.
  • step S912 If it is determined in step S912 that the data file is important, the data file that the core 105 could not read is acquired using a reverse stub.
  • the archive program 2061 refers to the reverse stub storage URL 335-337 and selects an edge according to the policy. For example, if there are a plurality of valid URLs, 1 is selected at random. Alternatively, a high-performance edge may be preferentially selected with reference to the SPEC level / edge mapping table 703.
  • the archive program 2061 transmits a file acquisition request to the edge 101B in step S914.
  • step S915 the edge 101B that has received the file acquisition request reads out the requested data file from the block address 318B-310B corresponding to the file path name 312B specified by the storage destination URL 335-337 and transmits it to the core 105. To do.
  • the data file that could not be read is restored with the received data file in step S916. That is, the data file stored at block addresses 338-340 is overwritten. In the case of a software error, it can be repaired by overwriting. However, in the case of a hardware error, after the hardware is repaired, the data file is recreated and an entry in the archive inode management table 330 is newly created. Need to create. After the data file restore, the data file is transmitted to the requesting edge 101A.
  • FIG. 10 is a diagram showing another flow of processing when the edge 101A receives a data file read request.
  • the inode management table 310B included in the edge 101B and the archive inode management table 330 included in the core 105 are readable.
  • the inode management table 310A of the edge 101A is assumed to be unreadable.
  • the data mover program 2033 of the edge 101A requests the reverse stub list from the core 105 (processing S1002).
  • the reverse stub list is a list indicating from which edge the data file was backed up by the core 105 in the past.
  • the reverse stub list can be acquired by extracting the edge information 341 in the archive inode management table 330 as a search condition (processing S1003). For example, if it is a reverse stub list request from the edge 101A, the archive program 2061 extracts data whose edge information 341 is “edgeA”. The extracted data is transmitted to the edge 101A as a reverse stub list (processing S1004).
  • the data mover program 2033 of the edge 101A that has received the reverse stub list displays the list on the operator and selects a necessary file (process S1006).
  • the reverse stub list is displayed including information such as the file / path name 332 and the importance 333 acquired from the archive inode management table 330, the operator can easily select.
  • the selected file transmits an acquisition request to the core 105 (processing S906).
  • the subsequent processing is the same as the processing after step S906 in FIG.
  • the acquisition request is transmitted to the core 105, but at the stage of the reverse stub list transmission process (S1004), the storage destination URL 335-337 is sent to the edge 101A, and the edge 101A does not go through the core 105.
  • the data file may be acquired directly from the edge 101B.
  • FIG. 11 is a flowchart of reverse stub deletion processing. Since the backup by the reverse stub consumes the storage capacity of the edge 101, it is desirable to organize the data files with small necessity as appropriate.
  • the archive program 2061 of the core 105 extracts a data file with low importance from data files for which reverse stubs are set. This may be performed periodically at regular intervals, or may be appropriately performed according to an instruction from the administrator.
  • the backup expiration date 403 (see FIG. 4) of the archive inode management table 330 is checked, and a data file whose expiration date has expired is extracted.
  • the last update time 334 is checked, and a data file in which a preset time has elapsed from the last update time is extracted.
  • a data file in which the numerical value of importance 333 is an insignificant value is extracted.
  • a plurality of the above determination methods may be combined.
  • the archive program 2061 of the core 105 instructs the edge 101B that backs up the data file to delete the backup data based on the storage URL 335-337 of the extracted data file.
  • the data mover program 2033 of the edge 101B invalidates the block addresses 318B-320B of the inode management table 310B, and invalidates the importance 313B and the last update time 314B. Further, the stubbing prohibition flag 315B is turned OFF. Then, the completion of deletion is reported to the core 105.
  • the archive program 2061 of the core 105 deletes the reverse stub of the extracted file. That is, the storage destination URL 335-337 is invalidated.
  • the archive program 2061 of the core 105 reports the deletion of the reverse stub to the edge 101A based on the edge information 341 in the archive inode management table 330.
  • functions equivalent to those configured by software can also be realized by hardware such as FPGA (Field Programmable Gate Array) and ASIC (Application Specific Integrated Circuit). Such an embodiment is also included in the scope of the present invention.
  • the present invention is not limited to the above-described embodiment, and includes various modifications.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment.
  • the backup data can be distributed not only on the core but also on the edge as needed. For this reason, redundancy can be arbitrarily set, and even when extensive damage is caused to the infrastructure in a large-scale disaster, the integrity of important data is extremely high.
  • the configuration of the present embodiment will be described using expressions such as “ ⁇ table”, “ ⁇ list”, “ ⁇ DB (Database)”, “ ⁇ queue”, “information”, and the like.
  • it may be expressed by a data structure other than a table, list, DB, queue, or the like.
  • one table may be divided into a plurality of tables, or a plurality of tables may be integrated into one.
  • “table” or the like it may indicate a part or all of the information held in the table, not the format of the table itself.
  • a reverse stub of the file is created on the core, and the data file migrated to the core is retained as a rule.
  • the backed up data file is usually stored as a hidden file at the other edge, and the latest file can be restored via the reverse stub of the core.
  • the total hidden file capacity may be confirmed on the file system at each edge.
  • a reverse stub is not newly created and the edge backup source file is overwritten.
  • stubbing is suppressed until the reverse stub disappears, and the actual data remains.
  • the migration timing is when a file is created or updated, important data files are immediately reflected in the archive without waiting for the regular migration timing, and can be referenced at any time.
  • This example not only backs up to the core, but also improves the safety of data by backing up multiple data on the edge side.
  • safety can be improved without adding equipment.
  • Stubification is used for edge-to-core references, whereas reverse stubs allow reverse references. That is, by introducing reverse stubs, edges can be accessed via the core.
  • Edge 102 Client device 103: File storage device 104: RAID device 105: Core 106: Archive device 107: RAID device

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本発明の一側面は、第１ファイルサーバ、第２ファイルサーバ、およびアーカイブサーバがネットワークで接続されたデータ管理システムにおけるデータファイル管理方法である。この方法において、第１ファイルサーバが、第１ファイルサーバでデータファイルを新規に格納し、あるいは、更新したことを契機に、データファイルをアーカイブサーバに送信する第１のステップと、アーカイブサーバが、受信したデータファイルを格納し、アーカイブサーバにおけるデータファイルの管理情報をアクセスするための情報をスタブ情報として第１ファイルサーバに送信する第２のステップと、第１ファイルサーバが、受信したスタブ情報を格納する第３のステップと、アーカイブサーバが、受信したデータファイルを第２ファイルサーバに送信する第４のステップと、第２ファイルサーバが、受信したデータファイルを格納し、第２ファイルサーバにおけるデータファイルの管理情報をアクセスするための情報を逆スタブ情報としてアーカイブサーバに送信する第５のステップと、アーカイブサーバが、受信した逆スタブ情報を格納する第６のステップと、を有する技術が開示されている。

Description

データファイル管理方法、データファイル管理システム、およびアーカイブサーバ
　本発明は、情報処理システムにおけるデータの管理方法、および、データの管理システムに関する。例えば、ネットワークで接続された複数のストレージシステムにおいて、データを管理するための技術に関する。
　近年、文書や画像等のデジタルデータ、特にデータファイルのデータ量は急速に増大している。デジタルデータは、各種の要求に対応する為に、長期間に亘って保存する必要がある。一般的に、現用データはそれが使われている限り記憶装置に保存され、利用される。このため、データの意図しない破壊に対応するために、データのコピーを保存すること（バックアップ）が行われる。このようなデータ管理技術について、例えば特許文献１、特許文献２に開示がある。
特表2013-524358号公報 特開2005-301857号公報
　企業の複数拠点・部門(エッジ)にファイルストレージを設置し、それらのデータファイルを、データセンター内のバックアップあるいはアーカイブストレージであるコアに集約し、クラウドを介してデータの一元的な管理を行う方式が着目されている。
　一般的に、データファイルはそれ頻繁に使われている間は、エッジに保存される。そして、使用頻度が小さくなると、アーカイブ目的でコアに移動し格納される。データの移動を「マイグレーション」という。移動されたデータは、アーカイブデータとも呼ばれる。データファイルがアーカイブされると、エッジにはアーカイブデータをアクセスするためのデータが保存される。このデータには、例えば、コアに格納されたデータファイルの場所を示すファイル・パス名が含まれる。このようなデータを「スタブ情報」、あるいは、「スタブ」、「スタブデータ」という（例えば特許文献１参照）。
　一度アーカイブ化されると、アーカイブされたデータファイルがエッジから削除されたり、破壊されたりしても、そのデータファイルはアーカイブデータから再構成（リストア）することができる。
　バックアップ目的によるマイグレーションでは、例えば所定時間間隔(例えば１日）でエッジのデータをコアにマイグレーションし、アーカイブ化していくことが考えられる。このような操作を、「定期的マイグレーション」と呼ぶことにする。しかし、アーカイブデータのファイル作成後、上記時間間隔の間にエッジのデータファイルが消滅した場合には、アーカイブデータからリストアしたとしても、一部のデータを失ってしまう可能性がある。よって、データを新規に作成したり、更新したりした場合には、即時にアーカイブデータを作成し、データの安全性を確保する事が理想的である。このような操作を「即時マイグレーション」と呼ぶことにする。しかし、マイグレーションの時間間隔を短くし、冗長性を高めればオーバヘッドが増大する。
　また、アーカイブデータをコアに記録し、冗長性を高めてデータファイルを保全したとしても、広域的な災害によりコアを構成するインフラそのものがダメージを受けた場合には、アーカイブデータが使用できなくなる可能性もある。重要なデータファイルについては、このような危険性を可能な限り排除する必要がある。
　本発明はこのような状況に鑑みてなされたものであり、重要なデータファイルについての安全性をできるだけ高めることを課題とする。
　上記課題を解決するための、本発明の一側面は、第１ファイルサーバ、第２ファイルサーバ、およびアーカイブサーバがネットワークで接続されたデータ管理システムにおけるデータファイル管理方法である。この方法では、第１ファイルサーバが、第１ファイルサーバでデータファイルを新規に格納し、あるいは、更新したことを契機に、データファイルをアーカイブサーバに送信する第１のステップと、アーカイブサーバが、受信したデータファイルを格納し、アーカイブサーバにおけるデータファイルの管理情報をアクセスするための情報をスタブ情報として第１ファイルサーバに送信する第２のステップと、第１ファイルサーバが、受信したスタブ情報を格納する第３のステップと、アーカイブサーバが、受信したデータファイルを第２ファイルサーバに送信する第４のステップと、第２ファイルサーバが、受信したデータファイルを格納し、第２ファイルサーバにおけるデータファイルの管理情報をアクセスするための情報を逆スタブ情報としてアーカイブサーバに送信する第５のステップと、アーカイブサーバが、受信した逆スタブ情報を格納する第６のステップと、を有する。
　本発明の他の一側面は、第１ファイルサーバ、第２ファイルサーバ、およびアーカイブサーバがネットワークで接続されたデータ管理システムである。このシステムでは、第１ファイルサーバは、第１ファイルサーバでデータファイルを新規に格納し、あるいは、更新したことを契機に、データファイルをアーカイブサーバに送信し、アーカイブサーバは、受信したデータファイルを格納し、アーカイブサーバにおけるデータファイルの管理情報をアクセスするための情報をスタブ情報として第１ファイルサーバに送信し、第１ファイルサーバは、受信したスタブ情報を格納し、アーカイブサーバは、受信したデータファイルを第２ファイルサーバに送信し、第２ファイルサーバは、受信したデータファイルを格納し、第２ファイルサーバにおけるデータファイルの管理情報をアクセスするための情報を逆スタブ情報としてアーカイブサーバに送信し、アーカイブサーバは、受信した逆スタブ情報を格納する。
　本発明の他の一側面は、第１ファイルサーバ、第２ファイルサーバ、およびアーカイブサーバがネットワークで接続されたデータ管理システムにおけるアーカイブサーバである。このサーバでは、第１ファイルサーバから受信したデータファイルを格納し、格納したデータファイルの管理情報であるアーカイブinodeテーブルを作成し、アーカイブinodeテーブルをアクセスするための情報をスタブ情報として第１ファイルサーバに送信し、受信したデータファイルを第２ファイルサーバに送信し、第２ファイルサーバから受信したデータファイルの管理情報であるinodeテーブルをアクセスするための逆スタブ情報を、スタブ情報と関連付けて格納する。
　データファイルの安全性が向上する。
本発明の実施例のシステムのハードウェア構成例を示すブロック図 本発明の実施例のシステムのソフトウェア構成例を示すブロック図 inode管理テーブルとアーカイブinode管理テーブルの例を示す概念図 ファイルシステム追加パラメータを示す概念図 ファイル新規作成時の実施例の処理を説明する流れ図 ファイル更新時の実施例の処理を説明する流れ図 エッジ選択ポリシーを説明する概念図 一般のファイルを対象とする定期的マイグレーション処理の流れ図 リストア処理の例を示す流れ図 リストア処理の他の例を示す流れ図 逆スタブの削除処理の流れ図
　実施の形態について、図面を用いて詳細に説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。
　以下に説明する発明の構成において、同一部分又は同様な機能を有する部分には同一の符号を異なる図面間で共通して用い、重複する説明は省略することがある。
　本明細書等における「第１」、「第２」、「第３」などの表記は、構成要素を識別するために付するものであり、必ずしも、数または順序を限定するものではない。また、構成要素の識別のための番号は文脈毎に用いられ、一つの文脈で用いた番号が、他の文脈で必ずしも同一の構成を示すとは限らない。また、ある番号で識別された構成要素が、他の番号で識別された構成要素の機能を兼ねることを妨げるものではない。
　図面等において示す各構成の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面等に開示された位置、大きさ、形状、範囲などに限定されない。
　以下で説明する実施例では、コア－エッジ型の階層型ファイルストレージシステムにおいて、各拠点に配置された複数のファイルサーバ（「エッジ」という）をグループ化し、重要なデータはエッジ間で隠蔽コピーによりバックアップする。アーカイブサーバ（「コア」という）には、当該バックアップデータを参照する為の逆スタブを格納し、リストア要求時には逆スタブの情報を用いて対象エッジからバックアップデータを読み出し、要求元に転送する。ファイルサーバは、ファイルストレージ装置及びそれに付随あるいは内包されるRAID装置を含む。アーカイブサーバは、アーカイブ装置及びそれに付随あるいは内包されるRAID装置を含む。ファイルサーバのデータを記憶する機能に着目して特に、「ファイルストレージ」と称することがある。また、アーカイブサーバのデータを記憶する機能に着目して特に、「アーカイブストレージ」と称することがある。
　図１は、本発明の実施例のハードウェア構成を示す図である。ネットワーク１０８を介して各拠点に配置された複数のエッジ１０１Ａ，１０１Ｂとコア１０５が接続されている。図１ではエッジ１０１は２つ描かれているが、３つ以上あってもよい。また、コア１０５は１つ描かれているが、２つ以上あってもよい。ネットワーク１０８は、専用回線であってもよいし、インターネットなどを利用してもよい。なお、エッジ１０１は複数接続されている場合があるので、複数のエッジを区別する必要がある場合には、エッジおよびその構成要素に、Ａ，Ｂのようなアルファベットの添字を付すことにする。
　エッジ１０１の其々は、例えば、クライアント装置１０２、ファイルストレージ装置１０３、Redundant Arrays of Inexpensive Disks（RAID）装置１０４を備える。クライアント装置１０２はいわゆるコンピュータであり、メモリ１０２１、処理装置（CPU)１０２２、他の装置と通信するためのネットワークインターフェースカード（NIC）１０２３、内蔵ディスク（装置）１０２４等を備える。また、コンピュータとして通常備える、キーボードや表示装置などの入出力装置を備える。
　ファイルストレージ装置１０３は、主にデータの格納を行うコンピュータであり、メモリ１０３１、CPU１０３２、NIC１０３３、内蔵ディスク１０３４、他のネットワーク機器やストレージ機器を接続するハードウェアであるホストバスアダプタ（HBA）１０３５等を備える。
　RAID装置１０４は、主にデータの保存を行う装置であり、他の装置とデータの送受信を行うためのチャネルアダプタ１０４１、一時的にデータ等を格納するメモリ１０４２、CPU１０４３、ディスク装置を制御するコントローラ１０４４、ディスク装置１０４５，１０４６を備える。メモリ１０４２は、例えば半導体メモリで構成される。ディスク装置１０４５，１０４６は、磁気ディスク装置や不揮発性の半導体メモリで構成される。図１ではディスク装置１０４５，１０４６は２つ描かれているが、１つであってもよいし、３つ以上あってもよい。
　エッジ１０１は例えば、企業の各拠点に配置され、必要な業務をクライアント装置１０２で行うに当たり、必要なデータをファイルストレージ装置１０３あるいはRAID装置１０４に格納して処理を行う。
　コア１０５は、例えばグループを構成する複数のエッジ１０１に対して１つ接続され、アーカイブ装置１０６とRAID装置１０７を備える。アーカイブ装置１０６はいわゆるサーバであり、RAID装置１０７の制御やエッジ１０１とのデータの送受信を行う。アーカイブ装置１０６は、メモリ１０６１、CPU１０６２、NIC１０６３、内蔵ディスク１０６４、HBA１０６５等を備える。また、サーバとして通常備える、キーボードや表示装置などの入出力装置を備える。
　RAID装置１０７は、主にエッジのデータのバックアップやアーカイブの保存を行う装置であり、他の装置とデータの送受信を行うためのチャネルアダプタ１０７１、一時的にデータを格納するメモリ１０７２、CPU１０７３、ディスク装置を制御するコントローラ１０７４、ディスク装置１０７５，１０７６を備える。その他の構成はRAID装置１０４と同様でよい。
　図２は、本発明の実施例のソフトウェア構成を示す図である。図１で説明したように、ハードウェアの各構成要素である、クライアント装置１０２、ファイルストレージ装置１０３、RAID装置１０４、アーカイブ装置１０６、RAID装置１０７は、処理装置（CPU)とメモリや内蔵ディスク等の記憶装置、および、入力装置、出力装置を備えている。以下、これらハードウェアの各構成要素を総括して「情報処理装置」と呼ぶ。本実施例では計算や制御等の機能は、記憶装置に格納されたソフトウェア（プログラム）がCPUによって実行されることで、定められた処理を他のハードウェアと協働して実現される。情報処理装置が実行するプログラム、その機能、あるいはその機能を実現する手段を、「機能」、「手段」、「部」、「ユニット」、「モジュール」等と呼ぶ場合がある。
　また、以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムは、CPUによって実行されることで、定められた処理をメモリ及び通信ポート（NIC,HBA,チャネルアダプタ等）を用いながら行うため、CPUを主語とした説明としてもよい。また、プログラムを主語として開示された処理は情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。
　また、各種プログラムは、プログラム配布サーバや、情報処理装置が読み取り可能な記憶メディアによって各情報処理装置にインストールされてもよい。また、情報処理装置は入出力デバイスを備えてもよい。入出力デバイスの例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。
　クライアント装置１０２は、クライアントが表計算やデータ処理など所望の処理を行うためのアプリケーションや、Webブラウザ２０２１を備える。また、これらを動作させるためのオペレーションシステム（OS)２０２２を備える。これらは公知のソフトウェアを用いることができる。
　ファイルストレージ装置１０３は、ファイル共有システム２０３１、ファイルシステムプログラム２０３２、データムーバプログラム２０３３、カーネルおよびデバイスドライバ２０３４を備える。ファイル共有システム２０３１は、例えば公知のCIFS (Common Internet File System)やNFS （Network File System）を用いることができる。カーネルやデバイスドライバ２０３４はハードウェアとソウトウェアを結び付けるものであり、公知の構成を利用することができる。
　ファイルシステムプログラム２０３２は、二進数のデータの形で記憶されたデータを、人間にわかりやすいファイルというものに抽象化、可視化し、データを管理するものであり、公知の構成を使用可能である。データムーバプログラム２０３３については、後に詳述するが、inode管理テーブルの管理や、マイグレーション、スタブの作成、コアとのデータのやり取りの制御を行うプログラムである。この例では、便宜上各プログラムを分けて説明しているが、構成例としては、例えばファイルシステムプログラム２０３２とデータムーバプログラム２０３３を一体のプログラムとして、ファイルストレージ装置１０３に同様の機能を持たせてもよい。以降の説明では、ファイルストレージ装置１０３の機能を、便宜上データムーバプログラム２０３３が代表して実現するように説明する場合がある。
　RAID装置１０４は、RAID制御プログラム２０４１、RTOS（Real-time operating system）２０４２を備える。ソフトウェアおよびハードウェアともに、RAID装置１０４は公知の構成を利用することができる。
　アーカイブ装置１０６は、アーカイブプログラム２０６１、ファイルシステムプログラム２０６２を備える。ファイルシステムプログラム２０６２については、ファイルシステムプログラム２０３２と同様である。また、カーネルおよびデバイスドライバ２０６３については、カーネルおよびデバイスドライバ２０３４と同様である。また、アーカイブ装置１０６は、アーカイブプログラム２０６１を備える。アーカイブプログラム２０６１については、後に詳述するが、inode管理テーブルの管理や、マイグレーション、逆スタブの作成、エッジとのデータのやり取りの制御を行うプログラムである。この例では、便宜上各プログラムを分けて説明しているが、構成例としては、例えばファイルシステムプログラム２０６２とアーカイブプログラム２０６１を一体のプログラムとして、アーカイブ装置１０６に同様の機能を持たせてもよい。以降の説明では、アーカイブ装置１０６の機能を、便宜上アーカイブプログラム２０６１が代表して実現するように説明する場合がある。
　RAID装置１０７は、RAID制御プログラム２０７１、RTOS２０７２を備える。ソフトウェアおよびハードウェアともに、RAID装置１０７は公知の構成を利用することができる。
　図３は、エッジ１０１Ａ、エッジ１０１Ｂが備える、データムーバプログラム２０３３Ａ、２０３３Ｂによって管理される、inode管理テーブル３１０Ａ，３１０Ｂの例を示す概念図である。また、コア１０５が備える、アーカイブプログラム２０６１によって管理される、アーカイブinode管理テーブル３３０の例を示す概念図である。
　inode管理テーブルあるいはアーカイブinode管理テーブルは、データムーバプログラム２０３３Ａ、２０３３Ｂあるいは、アーカイブプログラム２０６１の制御により、エッジ１０１、コア１０５が備える内蔵ディスク１０３４，１０６４等に作成、格納される。inode管理テーブルは、各データファイルごとに属性や管理情報（管理データ）を格納している。
　エッジ１０１Ａが備えるinode管理テーブル３１０Ａは、データファイルを一意に特定するinode番号３１１Ａ、当該inode番号の管理情報をアクセスするためのファイル・パス名３１２Ａ、データの重要度を示す重要度フラグ３１３Ａ、データの最終更新時間３１４Ａを有する。重要度フラグ３１３Ａは、重要か否かを示すフラグでもよいし、重要度を段階的に示す数値でもよい。
　inode管理テーブル３１０Ａは、さらにスタブ化禁止フラグ３１５Ａ、スタブ化フラグ３１６Ａ、格納先URL３１７Ａを備える。「スタブ化」とは、実体データをコア１０５に保管し、管理情報だけをエッジ１０１に残しデータ使用量を縮小する操作である。スタブ化禁止フラグ３１５ＡがＯＮの場合は、このデータファイルのスタブ化を禁止する。また、スタブ化が実行された場合には、スタブ化フラグ３１６ＡがＯＮとなる。図３の例では、スタブ化禁止フラグ３１５ＡがＯＦＦなので、スタブ化が可能であり、スタブ化フラグ３１６ＡがＯＮなので、スタブ化がされていることを示す。そして、スタブ化された実データは、格納先URL３１７Ａを参照することにより、コア１０５のファイル・パス名３３２（後述）を指定して呼び出しが可能となる。
　inode管理テーブル３１０のブロックアドレス３１８－３２０は、実データが格納されているアドレスを示す。この実施例では、実データはRAID装置１０４Ａのディスク装置１０４５－１０４６に記憶されているものとする。図３の例では、実データはスタブ化されており、エッジ１０１Ａには既に実データがなくなっている。このため、ブロックアドレス３１８－３２０には、NULL値が格納されている。図３の例ではブロックアドレスは３つあるが、数はそれより多くても少なくてもかまわない。
　コア１０５が備えるアーカイブinode管理テーブル３３０は、データファイルを一意に特定するinode番号３３１、当該inode番号の管理情報をアクセスするためのファイル・パス名３３２、データの重要度を示す重要度フラグ３３３、データの最終更新時間３３４を有する。重要度フラグ３１３には、データファイルのオリジナルの起源となっている、エッジ１０１Ａの重要度フラグ３１３のコピーが格納される。
　また、アーカイブinode管理テーブル３３０は、逆スタブの格納先URL３３５－３３７を備える。「逆スタブ」とは、実体データをコア１０５に保管しつつ、さらにそのコピーを他のエッジ１０１に格納することであり、データの安全性を高める。図３の例では逆スタブの格納先URLは３つあるが、数はそれより少なくても多くてもかまわない。数を増やせば、バックアップデータの冗長度を高めることができ、データの安全性が高まるが、リソースを消費する。
　アーカイブinode管理テーブル３３０のブロックアドレス３３８－３４０は、スタブ化された実データが格納されているアドレスを示す。この実施例では、実データはRAID装置１０７に記憶されているものとする。また、エッジ情報３４１は、スタブ化された実データがどのエッジからのデータであるかを示している。
　エッジ１０１Ｂが備えるinode管理テーブル３１０Ｂのフォーマットは、エッジ１０１Ａのinode管理テーブル３１０Ａと同様であるので、重複する説明は省略する。ここでは、コア１０５が格納する実データのコピーがエッジ１０１Ｂに格納された場合を想定し、その場合のinode管理テーブル３１０Ｂの状態について説明する。
　inode管理テーブル３１０Ｂのファイル・パス名３１２Ｂは、アーカイブinode管理テーブル３３０の格納先URL３３５に格納されている。よって、コア１０５から対応するinode管理テーブル３１０Ｂのデータの参照が可能である。コア１０５から得られた実データは、ブロックアドレス３１８Ｂ－３２０Ｂで示される記憶領域に格納されている。よって、ブロックアドレス３１８Ｂ－３２０Ｂの値を参照することにより、RAID装置１０４Ｂのディスク装置１０４５－１０４６に記憶されている実データにアクセスすることができる。重要度３１３Ｂは重要度３３３のコピーである。
　inode管理テーブル３１０Ｂのinode番号「１」のデータファイルは、それ自体がコア１０５に格納されたデータファイルのコピーである。よって、再度スタブ化をする必要はなく、またバックアップ目的であるため消去は不可である。したがって、スタブ化禁止フラグ３１５ＢがＯＮとなる。また、スタブ化は行われていないため、スタブ化フラグ３１６ＢはＯＦＦであり、格納先URL３１７Ｂは空欄または無効値となる。通常、このデータファイルは、クライアントからは見えない隠しファイルとして構成される。
　以上のような構成によると、データ破壊３６０に示すように、コア１０５の保持する実データが破壊された場合であっても、逆スタブ３３５－３３７によりエッジ１０１Ｂに保存されている実データを利用することができるため、データを安全に利用することが可能となる。
　図４にコア１０５の有するアーカイブinode管理テーブル３３０の他の例を示す。この例では、inode情報４０１に対して、逆スタブの導入による追加パラメータ４０２を追加した形式となっている。図４で図３と同様の項目の説明は省略するが、図４の構成では、バックアップ有効期限４０３が追加されている。バックアップ有効期限４０３は、逆スタブの有効期限を管理するデータである。古くなったデータファイルは重要度が下がると考えられるため、有効期限を過ぎたデータファイルは削除することにより、記憶装置の記憶容量を節約することができる。
　図５は、図１～図３で説明したエッジ１０１Ａ、１０１Ｂおよびコア１０５からなるシステムにおいて、新規にデータファイルを作成、格納する際の処理Ｓ５００の流れを説明する図である。説明を単純化するため、以降では特に説明がない場合には、エッジ１０１の動作は、ファイルストレージ装置１０３のデータムーバブログラム２０３３によって制御されることとし、コア１０５の動作は、アーカイブ装置１０６のアーカイブプログラム２０６１によって制御されることとして説明する。もちろん、これらのプログラムは複数のプログラムに分離して構成することもできる。
　処理Ｓ５０１ではエッジ１０１Ａは、データファイルの作成要求を受け付ける。これはクライアント装置１０２Ａが実行する、公知の種々のアプリケーション２０２１によるファイルの作成要求と連動するものでもよいし、専用のプログラムによるものでもよい。
　処理Ｓ５０２では、作成したデータファイルを新たに格納する。この例ではRAID装置１０４Ａに実データを格納するものとする。実データの格納に際しては、エッジ１０１Ａのデータムーバプログラム２０３３Ａは、inode管理テーブル３１０Ａに新たなエントリを作成する。inode番号３１１Ａやファイル・パス名３１２Ａは、例えば連続する番号のように一意に定まるものであればよい。
　inode管理テーブル３１０Ａの重要度３１３Ａはオペレータがファイルの作成要求時に入力するようしてもよいし、データを作成したアプリケーションの種類に対応して、予め定めておいてもよい。この場合には、アプリケーションの種類と重要度の対応を記憶したテーブルを別途準備して参照すればよい。また、ブロックアドレス３１８Ａ－３２０Ａには、実データを記録したRAID装置１０４Ａのアドレスを格納する。
　処理Ｓ５０３では、データを作成あるいは格納した時刻を、最終更新時間３１４Ａに設定する。
　処理Ｓ５０４では、inode管理テーブル３１０Ａの重要度３１３Ａをチェックし、重要ファイルかどうかを判定する。
　処理Ｓ５０５では、判定結果が重要ファイルでなかった場合には、逆スタブの設定処理は行わない。この場合には、公知の技術による定期的な（例えば１日１回）マイグレーションによりコア１０５へデータを転送し、記録する。
　処理Ｓ５０６では、判定結果が重要ファイルであった場合に、データファイルをエッジ１０１Ａからコア１０５へ送信する。このとき、必要に応じて重要度３１３Ａ、最終更新時間３１４Ａ、自エッジを特定する情報も付加して送信する。
　処理Ｓ５０７では、重要データファイルを受信したコア１０５は、アーカイブ装置１０６のアーカイブプログラム２０６１により、データファイルをRAID装置１０７に格納する。また、アーカイブプログラム２０６１は、アーカイブinode管理テーブル３３０を作成する。アーカイブinode管理テーブル３３０には、inode番号３３１やファイル・パス名３３２を割り当てる。アーカイブinode管理テーブル３３０には、受信した重要度を重要度３３３として格納し、受信した最終更新時間を最終更新時間３３４として格納する。また送信元のエッジを特定する情報をエッジ情報３４１として格納する。ブロックアドレス３３８－３４０には、データファイルを格納したRAID装置１０７のディスク装置１０７５，１０７６のアドレスを格納する。データファイルの格納が完了すると、コア１０５はエッジ１０１Ａにマイグレーションの完了を報告し、ファイル・パス名３３２を通知する。ファイル・パス名３３２を受信したエッジ１０１Ａは、inode管理テーブル３１０の格納先URL３１７に、受信したファイル・パス名３３２を格納する。また、スタブ化フラグ３１６をＯＮにする。
　以上のように、本実施例では重要なデータファイルについては、作成時に直ちにマイグレーションを行う。このようなマイグレーションを本明細書では便宜上「即時マイグレーション」と呼ぶ。よって、定期的なマイグレーション処理（図８で説明する）の間にデータの破壊があった場合でも、最新のデータを呼び出すことが可能となる。
　処理Ｓ５０８では、エッジ１０１Ａは、コア１０５へ逆スタブ作成要求を送信する。逆スタブ作成要求を送信する際に、バックアップ有効期限を付加してもよい。バックアップ有効期限は、データファイルを作成したアプリケーションプログラムにより設定することができる。あるいは、データムーバプログラム２０３３が提供するインターフェースから、利用者が設定してもよい。バックアップ有効期限は、コア１０５のアーカイブinode管理テーブル３３０のバックアップ有効期限４０３に格納される。
　処理Ｓ５０９では、コア１０５のアーカイブプログラム２０６１は、ポリシーに従い、逆スタブで指定し、データファイルのバックアップに用いるエッジ１０１の候補を順位付して選択する。候補を選択するポリシーとしては、スペックの高い順、空き容量の多い順など、任意のポリシーを採用することができる。エッジの選択については、後に図７により説明する。
　処理Ｓ５１０では、コア１０５のアーカイブプログラム２０６１は、選択したエッジ１０１Ｂに対して、データファイルを転送する。このとき、必要に応じて重要度３３３、最終更新時間３３４も付加して送信する。
　処理Ｓ５１１では、エッジ１０１Ｂは、コア１０５からデータファイルを受信する。
　処理Ｓ５１２では、エッジ１０１Ｂのデータムーバプログラム２０３３Ｂは、RAID装置１０４Ｂにデータファイルを格納する。また、ファイルストレージ装置１０３Ｂの内蔵ディスク１０３４Ｂにinode管理テーブル３１０Ｂを生成する。inode管理テーブル３１０Ｂには、inode番号３１１Ｂやファイル・パス名３１２Ｂを割り当てる。そして、受信した重要度を重要度３１３Ｂとして格納し、受信した最終更新時間を最終更新時間３１４Ｂとして格納する。さらに、スタブ化禁止フラグ３１５ＢをＯＮとし、スタブ化フラグ３１６ＢをＯＦＦとする。ブロックアドレス３１８Ｂ－３２０Ｂには、RAID装置１０４Ｂのデータファイル格納先のアドレスを格納する。また、コア１０５にファイル・パス名３１２Ｂを通知する。
　ファイル・パス名を受信したコア１０５のアーカイブプログラム２０６１は、アーカイブinode管理テーブル３３０にデータファイルの送信先のファイル・パス名を格納先URL３３５として格納する。
　処理Ｓ５１３では、コア１０５はエッジ１０１Ａに、逆スタブの設定完了を報告する。
　処理Ｓ５１４では、エッジ１０１Ｂは、管理者に逆スタブの設定を報告する。
　図６は、図１～図３で説明したエッジ１０１Ａ、１０１Ｂおよびコア１０５からなるシステムにおいて、既存データファイルを更新する際の処理Ｓ６００の流れを説明する図である。基本的には、図５の処理と同様であるので、異なる点を中心に説明する。
　処理Ｓ６０１では、エッジ１０１Ａで、既存データファイルを更新する要求を受け付ける。これは、inode管理テーブル３１０Ａのinode番号３１１Ａやファイル・パス名３１２Ａを指定することで可能となる。
　処理Ｓ６０２では、クライアント装置１０２Ａのアプリケーション２０２１Ａにより、データファイルを更新する。更新処理時には、更新対象となるデータファイルは、ブロックアドレス３１８Ａ－３２０Ａに有効なアドレスが格納されていれば、エッジ１０１ＡのRAID装置１０４Ａから取得する。エッジ１０１Ａにデータファイルが格納されていない場合、あるいは、データが破壊されていて読めない場合は、コア１０５から取得する。取得したデータファイルは、クライアント装置１０２Ａの内蔵ディスク１０２４Ａに一時格納して更新処理を行う。コア１０５からのデータファイルの取得方法については、後に図９で説明する。
　処理Ｓ６０３では、ファイルストレージ装置１０３Ａのデータムーバプログラム２０３３Ａにより、inode管理テーブル３１０Ａの最終更新時間３１４Ａを、例えば、既存データファイルを更新する要求を受け付けた時刻に変更する。
　処理Ｓ６０４では、ファイルストレージ装置１０３Ａのデータムーバプログラム２０３３Ａにより、inode管理テーブル３１０Ａの重要度３１３Ａをチェックし、重要ファイルかどうかを判定する。
　処理Ｓ６０５では、判定の結果、前回重要ファイルであったものでも、重要でなくなっている場合には、即時マイグレーションや逆スタブ化は行わない。重要でなくなったデータファイルの処理については、後に図１１で説明する。
　過去に重要ファイルでなかったもので、新規に重要ファイルとなったものは、図５と同様の処理により、新たに即時マイグレーションや逆スタブ化を行う。すなわち、新規に即時マイグレーションが必要な場合には、図５の処理と同様に、データファイルを、コア１０５のRAID装置１０７に格納する（処理Ｓ６０６－６０７）。また、新規に逆スタブの作成が必要な場合には（処理Ｓ６０８）、必要なエッジを選択し（処理Ｓ６０９）、図５の処理と同様にエッジ１０１Ｂにデータファイルを格納する（処理Ｓ６１０－Ｓ６１４）。
　また、既に逆スタブが作成済のデータファイルの場合には（処理Ｓ６０８）、既に格納先URL３３５－３３７で指定している他のエッジ１０１Ｂに、更新したデータファイルを格納（上書き）する（処理Ｓ６１０－Ｓ６１４）。
　以上の図５、図６の処理では、即時マイグレーションを行うデータファイルの選択の基準と、逆スタブを作成するデータファイルの選択の基準は同じ基準を用いている。すなわち、即時マイグレーションされたデータファイルは、逆スタブを用いたバックアップが行われる。ただし、基準を別々に設けることもできる。例えばinode管理テーブル３１０Ａで、重要度３１３Ａが「５」以上（数値が小さいほど重要性が高いとする）のデータファイルは即時マイグレーション（処理Ｓ５０６）することとし、重要度３１３Ａが「３」以上のデータファイルのみ、即時マイグレーションに加えて逆スタブ作成（処理Ｓ５０８）するというように、異なる基準を用いてもよい。
　図７は、逆スタブの作成の際に、コア１０５に格納されたデータファイルのコピーを格納すべきエッジ１０１の選択方法を説明する概念図である。アーカイブ装置１０６の内蔵ディスク１０６４は、重要度/性能（SPEC）レベル・ポリシーテーブル７０１、SPECレベル定義テーブル７０２、SPECレベル/エッジマッピングテーブル７０３を格納している。
　重要度/SPECレベル・ポリシーテーブル７０１は、ファイルの重要度に応じて、選択されるエッジの要求性能と台数を定義したものである。例えば、図７の例では、重要度レベル３に対して、SPECレベルCまたはDのエッジから１台が選択されることを示している。このようなテーブルはシステムの管理者が定義して作成し、ファイルストレージ装置１０３の内蔵ディスク１０３４に格納しておくものとする。
　SPECレベル定義テーブル７０２は、エッジの性能とSPECレベルの対応付けを定義するものである。例えば、「メモリ容量９６GB、CPU数１６、ハードディスク容量１２８TB、RAIDレベル６、リモートミラーあり、回線スピード１００Mbps」のエッジはSPECレベルAと定義される。図７の定義は一例であり、各性能は特定の値でなく範囲で定義してもよい。また、図７にない他の性能を定義に用いてもよい。このようなテーブルはシステムの管理者が定義して作成し、ファイルストレージ装置１０３に格納することができる。
　SPECレベル/エッジマッピングテーブル７０３は、SPECレベル定義テーブル７０２に基づいて、各エッジをSPECレベルに対応付けたものであり、ホスト名によってエッジを特定している。このようなテーブルは、システムの管理者がSPECレベル定義テーブル７０２と各エッジの性能値を参照して作成し、ファイルストレージ装置１０３に格納することができる。あるいは、エッジの性能を公知の方法で自動的にベンチマーキングし、性能データを自動的に収集し、SPECレベル定義テーブル７０２と照合して自動作成してもよい。
　以上のポリシーを用いることにより、バックアップを格納するのに適したエッジを選択することができる。SPECレベル/エッジマッピングテーブル７０３に格納されるエッジは、バックアップのデータファイルが格納されることを想定しているため、バックアップのデータファイルが格納されることが望ましくないエッジ１０１は予め除いておいてもよい。
　図３～図６を再度参照して、逆スタブの作成およびその際のエッジ１０１の選択方法を具体例で説明する。例えば、inode管理テーブル３１０の重要度３１３が「３」だった場合、データムーバプログラム２０３３は、コア１０５へ逆スタブ作成要求を行う（処理Ｓ５０８、Ｓ６０８）。
　コア１０５のアーカイブプログラム２０６１は、ポリシーに従いエッジを選択する（処理Ｓ５０９、Ｓ６０９）。処理Ｓ５０９、Ｓ６０９において、アーカイブプログラム２０６１は、重要度/SPECレベル・ポリシーテーブル７０１を参照する。この結果、重要度「３」に対応するエッジの選択ポリシーが、SPECレベル「Ｃ」または「Ｄ」のエッジから１台であることが分かる。そこで、SPECレベル/エッジマッピングテーブル７０３を参照し、SPECレベル「Ｃ」または「Ｄ」に分類されるエッジから、例えば１台をランダムに選択する。図７の例では、「eeff」「gghh」「hhii」から１台を選択することになる。なお、ランダムに選択するのではなく、レベルの高いもしくは低い順に選択してもよい。
　図８は、図５、図６の処理Ｓ５０５、Ｓ６０５で重要でないと判定されたデータファイル（一般のデータファイル）に対する、定期的マイグレーションの流れ図である。データファイルについては、新規に作成された場合には、エッジ１０１にデータファイルを格納するとともに、コア１０５にコピーを格納（マイグレーション）しアーカイブ化する（処理Ｓ８０１）。また、前回マイグレーション以降にデータファイルが更新された場合には、更新されたファイルを定期的にマイグーションする（定期的マイグレーション）。定期的マイグレーションは例えば、１日１回などの間隔で行われる。
　重要と判定されたデータファイルについては、図５、図６で説明した即時マイグレーションを行うが、重要と判定されなかったデータファイルについては、定期的マイグレーションのみが行われる。すなわち、例えば１日に１回のように所定のタイミングで、データファイルのバックアップがコア１０５に対して行われる。このとき、新規ファイルや更新ファイルは優先的にマイグレーションしてもよいが、マイグレーションのタイミングの前にデータファイルが壊れると、最新のデータファイルは回復できなくなる可能性がある。
　処理Ｓ８０３は、重要でないファイルを対象とするファイルの削除とスタブ化である。この処理では、所定のポリシー、例えば、一定期間更新されていないデータファイルであって、スタブ化が禁止されていないデータファイルを、エッジから削除し、データはコアにバックアップをしたうえで、スタブデータをエッジに残す。
　ポリシーに合致するかどうかは、inode管理テーブル３１０の最終更新時間３１４とスタブ化禁止フラグ３１５を参照することにより可能である。例えば、スタブ化禁止フラグ３１５がＯＦＦであって、最終更新時間３１４が所定以上前のデータファイルをスタブ化する。
　例えばエッジ１０１Ａのデータファイルをスタブ化する場合には、データムーバプログラム２０３３は、RAID装置１０４Ａのディスク装置１０４５，１０４６に格納されているデータファイルを、コア１０５に送信する。コア装置１０５のアーカイブプログラム２０６１は、受信したデータファイルをRAID装置１０７のディスク装置１０７５，１０７６に格納する。
　エッジ１０１Ａでは、データムーバプログラム２０３３により、RAID装置１０４Ａのディスク装置１０４５，１０４６に格納されているデータファイルを削除し、inode管理テーブル３１０のブロックアドレス３１８－３２０にNULL値を格納する。また、スタブ化フラグ３１６をＯＮとして、格納先URL３１７には格納先のエッジを示すファイル・パス名３３２を格納する。
　図９は、エッジ１０１Ａで、データファイルのRead要求を受付けた場合の処理の流れを示す図である。図９の例では、エッジ１０１Ａ、エッジ１０１Ｂが備える、inode管理テーブル３１０Ａ，３１０Ｂと、コア１０５が備える、アーカイブinode管理テーブル３３０は読み出し可能とする。
　処理Ｓ９０１は、データファイルのRead要求の受付けである。通常は、クライアント装置１０２Ａの各種のアプリケーション２０２１により、データファイルが要求される。
　処理Ｓ９０２では、データムーバプログラム２０３３は、inode管理テーブル３１０Ａのスタブ化フラグ３１６Ａを参照し、当該データファイルがスタブ化されているかどうかをチェックする。
　処理Ｓ９０３でスタブ化されていない場合は、処理Ｓ９０４において、ローカルファイルを取得する。すなわち、処理Ｓ９０４で、データムーバプログラム２０３３は、inode管理テーブル３１０Ａのブロックアドレス３１８Ａ－３２０Ａに基づいて、エッジ１０１ＡのRAID装置１０４Ａが保有するデータファイルを取得し、処理Ｓ９０５で要求元へ送る。また、ローカルファイルが取得できない場合、要求元へエラーを返して終了する。ローカルファイルが取得できない場合とは、RAID装置１０４Ａが保有するデータファイルが破壊されている場合や、inode管理テーブル３１０Ａのブロックアドレス３１８Ａ－３２０Ａが破壊されている場合である。
　処理Ｓ９０３でスタブ化されている場合は、処理Ｓ９０６において、データムーバプログラム２０３３は、inode管理テーブル３１０Ａの格納先URL３１７Ａを参照し、格納先URLとともにコア１０５にファイル取得要求を発行する。なお、スタブ化されている場合であっても、RAID装置１０４Ａにデータファイルが格納されている場合には、それを読みだしてもよい。ただし、RAID装置１０４Ａのデータファイルが破壊または消去されている場合には、コア１０５からファイルを取得することになる。
　処理Ｓ９０７では、コア１０５のアーカイブ装置１０６のアーカイブプログラム２０６１は、処理Ｓ９０７で、アーカイブinode管理テーブル３３０の受信した格納先URL３１７Ａに対応するファイル・パス名３３２を検索し、ブロックアドレス３３８－３４０を参照する。そして、RAID装置１０７のディスク装置１０７５，１０７６の該当ブロックアドレスからデータファイルを読み出す。
　処理Ｓ９０８で読み出しエラーの有無をチェックし、エラーがなければ処理Ｓ９０９でデータファイルをエッジ１０１Ａに送信する。
　エッジ１０１Ａでは、エラーの有無をチェックし（処理Ｓ９１０）、エラーがなければ受信したデータファイルをファイルストレージ装置１０３Ａの内蔵ディスク１０３４に格納し（処理Ｓ９１１）、データファイルを要求元に送る（処理Ｓ９０５）。また必要により、要求元であるアプリケーション２０２１がアクセスするクライアント装置１０２Ａの内蔵ディスク１０２４やRAID装置１０４Ａのディスク装置１０４５，１０４６にデータファイルを格納する。
　一方、処理Ｓ９０８で読み出しエラーがあれば、アーカイブプログラム２０６１は、処理Ｓ９１２でデータファイルが重要かどうかを確認する。そのために、アーカイブinode管理テーブル３３０の重要度３３３を参照する。データファイルが重要でなかった場合には、データファイルはリストアできないため、コア１０５はエッジ１０１にエラーを送信する（処理Ｓ９１３）。エラーを受信したエッジ１０１は、処理Ｓ９１０でエラー判定を受け、エラーとして処理を終了する（処理Ｓ９１４）。
　処理Ｓ９０８で読み出しエラーがある場合とは、RAID装置１０７が保有するデータファイルが破壊されている場合や、アーカイブinode管理テーブル３３０Ａのブロックアドレス３３８Ａ－３４０Ａが破壊されている場合である。
　処理Ｓ９１２でデータファイルが重要と判定された場合には、逆スタブを用いてコア１０５が読み出せなかったデータファイルを取得する。アーカイブプログラム２０６１は、処理Ｓ９１３で、逆スタブの格納先URL３３５－３３７を参照し、ポリシーに従ってエッジを選択する。例えば、有効なURLが複数ある場合には、ランダムに１を選択する。あるいは、SPECレベル/エッジマッピングテーブル７０３を参照して、性能の高いエッジを優先的に選択してもよい。
　エッジ１０１を１つ選択したら、アーカイブプログラム２０６１は、処理Ｓ９１４で、そのエッジ１０１Ｂに対してファイル取得要求を送信する。
　処理Ｓ９１５で、ファイル取得要求を受信したエッジ１０１Ｂは、格納先URL３３５－３３７で指定されるファイル・パス名３１２Ｂに対応するブロックアドレス３１８Ｂ－３１０Ｂから、要求されたデータファイルを読み出し、コア１０５へ送信する。
　データファイルを受信したコア１０５では、処理Ｓ９１６により、読み出せなかったデータファイルを受信したデータファイルでリストアする。すなわち、ブロックアドレス３３８－３４０に格納されているデータファイルを上書きする。なお、ソフト的なエラーの場合は上書きで修復が可能であるが、ハードウェアによるエラーの場合には、ハードウェアの修復の後に、データファイルを再作成しアーカイブinode管理テーブル３３０のエントリを新規に作成する必要がある。データファイルリストア後、要求元であるエッジ１０１Ａにデータファイルを送信する。
　図１０は、エッジ１０１Ａで、データファイルのRead要求を受付けた場合の処理の他の流れを示す図である。図１０の例では、エッジ１０１Ｂが備えるinode管理テーブル３１０Ｂと、コア１０５が備えるアーカイブinode管理テーブル３３０は読み出し可能とする。一方、エッジ１０１Ａのinode管理テーブル３１０Ａは読み出し不可の状態を想定する。
　この状況で、エッジ１０１Ａがデータファイルを持っていない、または読み出せない場合（処理Ｓ１００１）には、エッジ１０１Ａのデータムーバプログラム２０３３は、コア１０５に逆スタブリストを要求する（処理Ｓ１００２）。逆スタブリストは、コア１０５が過去にどのエッジからのデータファイルをバックアップしたかを示すリストである。逆スタブリストは、アーカイブinode管理テーブル３３０のエッジ情報３４１を検索条件として抽出し取得することができる（処理Ｓ１００３）。例えば、エッジ１０１Ａからの逆スタブリスト要求であれば、アーカイブプログラム２０６１は、エッジ情報３４１が「edgeA」のデータを抽出する。抽出したデータを逆スタブリストとしてエッジ１０１Ａに送信する（処理Ｓ１００４）。
　逆スタブリストを受信（処理Ｓ１００５）したエッジ１０１Ａのデータムーバプログラム２０３３は、当該リストをオペレータに表示し、必要なファイルを選択させる（処理Ｓ１００６）。このとき、逆スタブリストに、アーカイブinode管理テーブル３３０から取得した、ファイル・パス名３３２、重要度３３３等の情報を含めて表示すると、オペレータの選択が容易となる。選択したファイルは、コア１０５へ取得要求を送信する（処理Ｓ９０６）。この後の処理は、図９の処理Ｓ９０６以降と同様である。
　なお、図１０ではコア１０５へ取得要求を送信しているが、逆スタブリスト送信処理（Ｓ１００４）の段階で、格納先URL３３５－３３７をエッジ１０１Ａに送付し、エッジ１０１Ａからコア１０５を介さずに、エッジ１０１Ｂから直接データファイルを取得してもよい。
　図１１は逆スタブの削除処理の流れ図である。逆スタブによるバックアップはエッジ１０１の記憶容量を消費しているため、必要性の小さいデータファイルは適宜整理することが望ましい。
　処理Ｓ１１０１では、コア１０５のアーカイブプログラム２０６１は、逆スタブが設定されているデータファイルのうち、重要度が低いデータファイルを抽出する。これは定期的に一定期間ごとに行ってもよいし、管理者の指示により適宜行ってもよい。
　抽出にあたっては、アーカイブinode管理テーブル３３０のバックアップ有効期限４０３（図４参照）をチェックし、有効期限が切れているデータファイルを抽出する。あるいは、最終更新時間３３４をチェックし、最終更新時間からあらかじめ設定された時間が経過しているデータファイルを抽出する。あるいは、重要度３３３の数値が重要でない値になっているデータファイルを抽出する。あるいは、上記の判定方法を複数組み合わせてもよい。
　処理Ｓ１１０２では、コア１０５のアーカイブプログラム２０６１は、抽出したデータファイルの格納先URL３３５－３３７に基づいて、データファイルをバックアップしているエッジ１０１Ｂに対して、バックアップデータの削除を指示する。
　処理Ｓ１１０３では、エッジ１０１Ｂのデータムーバプログラム２０３３は、inode管理テーブル３１０Ｂのブロックアドレス３１８Ｂ－３２０Ｂを無効化するとともに、重要度３１３Ｂ、最終更新時間３１４Ｂを無効化する。また、スタブ化禁止フラグ３１５ＢをＯＦＦにする。そして、コア１０５に削除完了を報告する。
　処理Ｓ１１０４では、コア１０５のアーカイブプログラム２０６１は、抽出したファイルの逆スタブを削除する。すなわち格納先URL３３５－３３７を無効化する。
　処理Ｓ１１０５では、コア１０５のアーカイブプログラム２０６１は、アーカイブinode管理テーブル３３０のエッジ情報３４１に基づいて、エッジ１０１Ａに逆スタブの削除を報告する。
　処理Ｓ１１０６では、報告を受信し、完了する。
　本実施例中、ソフトウエアで構成した機能と同等の機能は、FPGA（Field Programmable Gate Array）、ASIC（Application Specific Integrated Circuit）などのハードウエアでも実現できる。そのような態様も本願発明の範囲に含まれる。
　本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。
　また、本実施例で説明した処理の流れは、必ずしも説明した流れ図の順序である必要はなく、処理に矛盾が生じない限り順序を変更することができる。
　以上のように本実施例のシステムでは、バックアップのデータはコアに集中させるだけではなく、必要に応じてエッジに分散することができる。このために、冗長性を任意に設定が可能であり、大規模な災害においてインフラに広範囲な被害が生じた場合でも、重要なデータの保全性がきわめて高いという特徴がある。
　上記の説明では「～テーブル」、「～リスト」、「～ＤＢ（Ｄａｔａｂａｓｅ）」、「～キュー」、「情報」等の表現にて本実施例の構成を説明するが、これらは等価な情報である限り、テーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。また、データ相互の関連性が保たれる限り、一つのテーブルが複数に分かれていてもよいし、複数のテーブルが一つに統合されていてもよい。また、「テーブル」等といった場合には、テーブルのフォーマット自体ではなく、テーブルが持つ情報の一部または全部を指すことがある。
　以上で説明した実施例では、定期的なマイグレーションを行うとともに、重要と判断されるデータファイルのみ即座にコアへマイグレーションを行う。さらに、コアから他エッジへ規定したバックアップポリシーを基に、データファイルのバックアップを行う。
　また、データファイルがマイグレーションされたタイミングで、コア上にファイルの逆スタブを作成し、コアにマイグレーションされたデータファイルは原則そのまま保持する。バックアップされたデータファイルは、通常は隠しファイルとして他エッジへ格納されており、コアの逆スタブを介して最新ファイルをリストアすることができる。
　全体の隠しファイル容量は各エッジのファイルシステム上で確認できるようにしてもよい。データファイル更新時は、逆スタブは新たに作成されずエッジのバックアップ元ファイルを上書きする。一方エッジ側にあるバックアップファイルは、リストア要求に応えるため、逆スタブが消滅するまでスタブ化は抑制され、実データを残す。
　本実施例ではマイグレーションタイミングがファイル作成あるいは更新時であるため、重要なデータファイルについては定期的マイグレーションタイミングを待たずアーカイブに即時反映され、いつでも参照することができる。
　本実施例はコアにバックアップをとるだけでなく、エッジ側にも複数データをバックアップすることでデータの安全性を高めることができる。コア－エッジ構成という既存の枠組みの中で、機器の増設をすることなく安全性の向上を実現することができる。また、全てのデータファイルをバックアップ対象とするのではなく、重要データのみとすることで、ネットワーク帯域を過度に逼迫させることを防ぐことができる。
　スタブ化はエッジからコアへの参照で用いられるのに対し、逆スタブは逆の参照を可能にする。すなわち、逆スタブを導入することで、コアを経由してエッジ同士のアクセスが可能となる。
　データファイルシステムの関連分野に適用することが可能である。
１０１：エッジ
１０２：クライアント装置
１０３：ファイルストレージ装置
１０４：RAID装置
１０５：コア
１０６：アーカイブ装置
１０７：RAID装置

Claims (15)

  1. 　第１ファイルサーバ、第２ファイルサーバ、およびアーカイブサーバがネットワークで接続されたデータ管理システムにおけるデータファイル管理方法において、
    　前記第１ファイルサーバが、前記第１ファイルサーバでデータファイルを新規に格納し、あるいは、更新したことを契機に、前記データファイルを前記アーカイブサーバに送信する第１のステップと、
    　前記アーカイブサーバが、受信した前記データファイルを格納し、前記アーカイブサーバにおける前記データファイルの管理情報をアクセスするための情報をスタブ情報として前記第１ファイルサーバに送信する第２のステップと、
    　前記第１ファイルサーバが、受信した前記スタブ情報を格納する第３のステップと、
    　前記アーカイブサーバが、受信した前記データファイルを前記第２ファイルサーバに送信する第４のステップと、
    　前記第２ファイルサーバが、受信した前記データファイルを格納し、前記第２ファイルサーバにおける前記データファイルの管理情報をアクセスするための情報を逆スタブ情報として前記アーカイブサーバに送信する第５のステップと、
    　前記アーカイブサーバが、受信した前記逆スタブ情報を格納する第６のステップと、
    　を有するデータファイル管理方法。
  2. 　前記第１ファイルサーバが、自らが格納する全ての前記データファイルを、所定時間間隔で前記アーカイブサーバに送信する第７のステップを有し、
    　前記第１のステップにおいて、
    　前記第１ファイルサーバが、前記第１ファイルサーバでデータファイルを新規に格納し、あるいは、更新したときに、前記データファイルが重要と判定された場合のみ、前記データファイルを新規に作成し、あるいは、更新したことを契機に、前記データファイルを前記アーカイブサーバに送信する第１のステップを実行する、
    　請求項１記載のデータファイル管理方法。
  3. 　前記第４のステップにおいて、
    　前記アーカイブサーバが、予め定められたポリシーに従って、複数のファイルサーバの中から、前記第２ファイルサーバを選択する、
    　請求項１記載のデータファイル管理方法。
  4. 　前記第１ファイルサーバが、自らが格納する前記データファイルにアクセスできない場合、前記スタブ情報を用いて前記アーカイブサーバからデータファイルを取得する第８のステップと、
    　前記アーカイブサーバが、自らが格納する前記データファイルにアクセスできない場合、前記逆スタブ情報を用いて前記第２ファイルサーバからデータファイルを取得する第９のステップと、
    　を有する請求項１記載のデータファイル管理方法。
  5. 　第１ファイルサーバは、inode管理テーブルを格納し、
    　前記inode管理テーブルは、前記スタブ情報と、前記スタブ情報に対応する前記データファイルの重要度を示す重要度情報と、を格納し、
    　前記アーカイブサーバは、アーカイブinode管理テーブルを格納し、
    　前記アーカイブinode管理テーブルは、前記逆スタブ情報と、前記逆スタブ情報に対応する前記データファイルの重要度を示す重要度情報と、を格納する、
    　を有する請求項１記載のデータファイル管理方法。
  6. 　第１ファイルサーバ、第２ファイルサーバ、およびアーカイブサーバがネットワークで接続されたデータ管理システムにおいて、
    　前記第１ファイルサーバは、前記第１ファイルサーバでデータファイルを新規に格納し、あるいは、更新したことを契機に、前記データファイルを前記アーカイブサーバに送信し、
    　前記アーカイブサーバは、受信した前記データファイルを格納し、前記アーカイブサーバにおける前記データファイルの管理情報をアクセスするための情報をスタブ情報として前記第１ファイルサーバに送信し、
    　前記第１ファイルサーバは、受信した前記スタブ情報を格納し、
    　前記アーカイブサーバは、受信した前記データファイルを前記第２ファイルサーバに送信し、
    　前記第２ファイルサーバは、受信した前記データファイルを格納し、前記第２ファイルサーバにおける前記データファイルの管理情報をアクセスするための情報を逆スタブ情報として前記アーカイブサーバに送信し、
    　前記アーカイブサーバは、受信した前記逆スタブ情報を格納する、
    　データファイル管理システム。
  7. 　前記第１ファイルサーバは、自らが格納する全ての前記データファイルを、所定時間間隔で前記アーカイブサーバに送信し、
    　前記第１ファイルサーバは、前記第１ファイルサーバでデータファイルを新規に格納し、あるいは、更新したときに、前記データファイルが重要と判定された場合のみ、前記データファイルを新規に作成し、あるいは、更新したことを契機に、前記データファイルを前記アーカイブサーバに送信する、
    　請求項６記載のデータファイル管理システム。
  8. 　前記アーカイブサーバは、予め定められたポリシーに従って、複数のファイルサーバの中から、前記第２ファイルサーバを選択する、
    　請求項６記載のデータファイル管理システム。
  9. 　前記第１ファイルサーバは、自らが格納する前記データファイルにアクセスできない場合、前記スタブ情報を用いて前記アーカイブサーバからデータファイルを取得し、
    　前記アーカイブサーバは、自らが格納する前記データファイルにアクセスできない場合、前記逆スタブ情報を用いて前記第２ファイルサーバからデータファイルを取得する、
    　請求項６記載のデータファイル管理システム。
  10. 　第１ファイルサーバは、inode管理テーブルを格納し、
    　前記inode管理テーブルは、前記スタブ情報と、前記スタブ情報に対応する前記データファイルの重要度を示す重要度情報と、を格納し、
    　前記アーカイブサーバは、アーカイブinode管理テーブルを格納し、
    　前記アーカイブinode管理テーブルは、前記逆スタブ情報と、前記逆スタブ情報に対応する前記データファイルの重要度を示す重要度情報と、を格納する、
    　請求項６記載のデータファイル管理システム。
  11. 　第１ファイルサーバ、第２ファイルサーバ、およびアーカイブサーバがネットワークで接続されたデータ管理システムにおける前記アーカイブサーバにおいて、
    　前記第１ファイルサーバから受信したデータファイルを格納し、格納した前記データファイルの管理情報であるアーカイブinodeテーブルを作成し、前記アーカイブinodeテーブルをアクセスするための情報をスタブ情報として前記第１ファイルサーバに送信し、
    　受信した前記データファイルを前記第２ファイルサーバに送信し、前記第２ファイルサーバから受信した前記データファイルの管理情報であるinodeテーブルをアクセスするための逆スタブ情報を、前記スタブ情報と関連付けて格納する、
    　アーカイブサーバ。
  12. 　受信した前記データファイルを前記第２ファイルサーバに送信する際に、
    　予め格納されたポリシーに基づいて、複数のファイルサーバから前記第２のファイルサーバを選択する、
    　請求項１１記載のアーカイブサーバ。
  13. 　前記アーカイブinodeテーブルは、
    　前記データファイルを特定するinode番号、前記スタブ情報、前記逆スタブ情報、および前記データファイルの重要度を示す重要度情報を関連付けて格納する、
    　請求項１１記載のアーカイブサーバ。
  14. 　前記アーカイブinodeテーブルは、
    　前記データファイルを特定するinode番号、前記スタブ情報、前記逆スタブ情報、および前記データファイルの送信元である前記第１ファイルサーバを特定するエッジ情報を関連付けて格納する、
    　請求項１１記載のアーカイブサーバ。
  15. 　前記アーカイブinodeテーブルは、
    　前記データファイルを特定するinode番号、前記スタブ情報、複数の前記逆スタブ情報を関連付けて格納する、
    　請求項１１記載のアーカイブサーバ。
PCT/JP2015/085859 2015-12-22 2015-12-22 データファイル管理方法、データファイル管理システム、およびアーカイブサーバ WO2017109862A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/085859 WO2017109862A1 (ja) 2015-12-22 2015-12-22 データファイル管理方法、データファイル管理システム、およびアーカイブサーバ

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2015/085859 WO2017109862A1 (ja) 2015-12-22 2015-12-22 データファイル管理方法、データファイル管理システム、およびアーカイブサーバ

Publications (1)

Publication Number Publication Date
WO2017109862A1 true WO2017109862A1 (ja) 2017-06-29

Family

ID=59089728

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/085859 WO2017109862A1 (ja) 2015-12-22 2015-12-22 データファイル管理方法、データファイル管理システム、およびアーカイブサーバ

Country Status (1)

Country Link
WO (1) WO2017109862A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7465301B2 (ja) 2022-05-20 2024-04-10 株式会社日立製作所 データ管理システム、データ管理方法、およびプログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06250902A (ja) * 1993-02-24 1994-09-09 Hitachi Ltd 分散システムのファイルバックアップ方法
JPH08212142A (ja) * 1995-02-08 1996-08-20 Nec Corp データベースのデータバックアップシステム
JPH09160818A (ja) * 1995-12-06 1997-06-20 Kokusai Electric Co Ltd ファイルの自動バックアップ方法
JP2002278816A (ja) * 2001-03-19 2002-09-27 Toshiba Corp バックアップシステム及びプログラム
WO2013065151A1 (ja) * 2011-11-02 2013-05-10 株式会社日立製作所 計算機システム、データ転送方法、および、データ転送プログラム
JP2014503086A (ja) * 2011-04-08 2014-02-06 株式会社日立製作所 ファイルシステム及びデータ処理方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06250902A (ja) * 1993-02-24 1994-09-09 Hitachi Ltd 分散システムのファイルバックアップ方法
JPH08212142A (ja) * 1995-02-08 1996-08-20 Nec Corp データベースのデータバックアップシステム
JPH09160818A (ja) * 1995-12-06 1997-06-20 Kokusai Electric Co Ltd ファイルの自動バックアップ方法
JP2002278816A (ja) * 2001-03-19 2002-09-27 Toshiba Corp バックアップシステム及びプログラム
JP2014503086A (ja) * 2011-04-08 2014-02-06 株式会社日立製作所 ファイルシステム及びデータ処理方法
WO2013065151A1 (ja) * 2011-11-02 2013-05-10 株式会社日立製作所 計算機システム、データ転送方法、および、データ転送プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7465301B2 (ja) 2022-05-20 2024-04-10 株式会社日立製作所 データ管理システム、データ管理方法、およびプログラム

Similar Documents

Publication Publication Date Title
US11593319B2 (en) Virtualized data storage system architecture
JP5343166B2 (ja) 通信ネットワークを介してリモートのファイルサーバにファイルを転送するローカルのファイルサーバ、及び、それらのファイルサーバを有するストレージシステム
JP4741371B2 (ja) システム、サーバ装置及びスナップショットの形式変換方法
JP4749266B2 (ja) 情報資源の重複を省いたバックアップ制御装置及び方法
JP5608811B2 (ja) 情報処理システムの管理方法、及びデータ管理計算機システム
JP5697754B2 (ja) 計算機システム、ファイル管理方法及びメタデータサーバ
US8135677B2 (en) File management system and method
US9116913B2 (en) File storage system and file cloning method
WO2012137262A1 (en) Information processing system and data processing method
JP2008033912A (ja) Ｎａｓ向けのｃｄｐの方法および装置
JP2004005289A (ja) 記憶装置システム
JP2007079774A (ja) ファイルシステムの構築方法
JP2007086843A (ja) ディスクの回転を制御するシステム
US9811534B2 (en) File server, information system, and control method thereof
JP2011034525A (ja) 階層化ストレージシステム及び階層化ストレージシステムにおけるファイルのコピー制御方法
JP2007241486A (ja) 記憶装置システム
JP6298903B2 (ja) 計算機システム、分散オブジェクト共有方法、エッジノード
US10805394B2 (en) File server apparatus having shared file system with file and directory operation processing
US20150046394A1 (en) Storage system, storage control device, and storage medium storing control program
WO2014054065A1 (en) Backup and restore system for a deduplicated file system and corresponding server and method
JP4937863B2 (ja) 計算機システム、管理計算機及びデータ管理方法
JP2009064160A (ja) 計算機システム、管理計算機及びデータ管理方法
WO2014064740A1 (en) Computer system and file server migration method
US9135116B1 (en) Cloud enabled filesystems provided by an agent which interfaces with a file system on a data source device
WO2017109862A1 (ja) データファイル管理方法、データファイル管理システム、およびアーカイブサーバ

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15911300

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15911300

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP