WO2017168653A1 - ストレージシステム - Google Patents

ストレージシステム Download PDF

Info

Publication number
WO2017168653A1
WO2017168653A1 PCT/JP2016/060498 JP2016060498W WO2017168653A1 WO 2017168653 A1 WO2017168653 A1 WO 2017168653A1 JP 2016060498 W JP2016060498 W JP 2016060498W WO 2017168653 A1 WO2017168653 A1 WO 2017168653A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
storage
information
archiver
storage system
Prior art date
Application number
PCT/JP2016/060498
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/JP2016/060498 priority Critical patent/WO2017168653A1/ja
Publication of WO2017168653A1 publication Critical patent/WO2017168653A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements

Definitions

  • the present invention relates to a storage system.
  • Japanese Patent Application Laid-Open No. 2003-228867 describes that “when the NAS device 10 detects a virus infection of a file transmitted from a client computer, a file infected with a virus may be stored in a file management module controlled by each user OS. "Stop the operation of the file management module that uses a certain directory group” is described, “It is possible to prevent secondary damage due to virus infection to other logical volumes and to reduce the loss in operation of the computer system.” Are listed.
  • Patent Document 1 If the technology described in Patent Document 1 is used, secondary damage can be prevented. However, there is no description of a technique for preventing secondary damage among a plurality of NAS devices (file storages) or a technique for making use of the progress of file scanning for detecting virus infection.
  • an object of the present invention is to provide a storage system in which a plurality of file storages cooperate to prevent virus infection.
  • a representative storage system is a storage system in which a plurality of file storages each storing a file and an archiver that archives a file are connected, and each of the plurality of file storages includes the file
  • the file stored in the storage is transmitted to the archiver, the management information of the transmitted file is retained, and in reading the file, it is determined that the file is transmitted to the archiver based on the management information, and the management information
  • the archiver receives and archives the file from the file storage, and receives the first scan from the file storage. Responding to the scan result request with the recorded first scan result, responding to the file request from the file storage with the archived file, and the second scan result from the file storage Is recorded as the first scan result.
  • FIG. 1 is a diagram illustrating an example of system hardware.
  • the system is divided into an edge A 101-1, an edge B 101-2 and a core 102, which are connected by a network 103.
  • Edge A 101-1 and Edge B 101-2 are devices that are located at the edge of the system and provide services to the user.
  • Core 102 is located at the core of the system and provides services to Edge A 101-1 and Edge B 101-2. This is a group of devices to be provided.
  • the edge A 101-1 and the edge B 101-2 include the same type of device group. In FIG. 1, two examples of the edge A 101-1 and the edge B 101-2 are shown. However, the number may be three or more.
  • the client 110 is a general computer operated by a user.
  • a CPU (Central Processing Unit) 111 executes a program stored in the memory 112, and sends data to the memory 112 or HDD (Hard Disk Drive) 113. Read / write and control communication of NIC (Network Interface Card) 114.
  • NIC Network Interface Card
  • the program and data stored in the memory 112 may be read from the HDD 113.
  • the HDD 113 may be an SSD (Solid State Drive), and the HDD 113 is not included in the client 110, so-called diskless, and a storage corresponding to the HDD 113 may be connected to a network connected to the client 110.
  • SSD Solid State Drive
  • the NIC 114 is connected to the file storage 120 via a network.
  • the CPU 111 of the client 110 executes a program stored in the memory 112, controls the NIC 114, and transmits a file read request and a write request to the file storage 120.
  • the program stored in the memory 112 will be described later with reference to FIG.
  • the file storage 120 is a computer that responds to file read requests in response to file read requests, stores file data in response to file write requests, and manages them as files.
  • the CPU 121 of the file storage 120 executes a program stored in the memory 122, reads / writes data from / to the memory 122 or the HDD 123, controls communication between the NIC 124 and the NIC 125, and communicates with the storage by the HBA (Host Bus Adapter) 126. Control communication.
  • HBA Hyper Bus Adapter
  • the program and data stored in the memory 122 may be read from the HDD 123, and the HDD 123 may be an SSD.
  • the NIC 124 is connected to the client 110 and the scan server 150 via the network in the edge A 101-1.
  • the NIC 125 is connected to the archiver 160 of the core 102 via the network 103 outside the edge A 101-1.
  • the NIC 124 may include a plurality of NICs including a NIC connected to the client 110 and a NIC connected to the scan server 150. Conversely, the NIC 124 and the NIC 125 may be one NIC. The NIC 124 and the NIC 125 may be NICs that support the same communication protocol, or may be NICs that support different communication protocols, and the supported communication protocol is TCP / IP (TransmissionTransControl Protocol / Internet Protocol). ).
  • TCP / IP TransmissionTransControl Protocol / Internet Protocol
  • the HBA 126 is an adapter that communicates with a peripheral device, and is connected to the block storage 140.
  • the HBA 126 may be an HBA that supports FC (Fibre Channel), an HBA that supports iSCSI (Internet SCSI), or an HBA that supports SATA (Serial ATA).
  • the file data to be saved may be stored in the HDD 123 or may be stored in the block storage 140 via the HBA 126.
  • the block storage 140 is a general storage that responds to a read request for block data and stores the data in response to a write request for block data.
  • the CPU 141 of the block storage 140 executes a program stored in the memory 142, and accesses the HDD 143 in response to a read request and a write request received by a CHA (Channel Adapter) 144.
  • CHA Channel Adapter
  • the program stored in the memory 142 may be read from the HDD 143, or the memory 142 may be a non-volatile memory and may continue to hold the program.
  • the HDD 143 stores data to be read and written in response to a read request and a write request.
  • the HDD 143 may be a plurality of HDDs, and the plurality of HDDs may be RAID (Redundant Arrays of Inexpensive Disks).
  • the block storage 140 may have dedicated hardware to respond to a large number of read requests and write requests in a short time and to access a large number of HDDs 143.
  • This dedicated hardware may share processing with the CPU 141 or may be controlled by the CPU 141.
  • the scan server 150 is a computer that scans a file received from the file storage 120 and detects a virus infection.
  • the CPU 151 of the scan server 150 executes a program stored in the memory 152, reads / writes data from / to the memory 152 or the HDD 153, and controls communication of the NIC 154.
  • the program stored in the memory 152 may be read from the HDD 153.
  • the HDD 153 may be an SSD, and the HDD 153 may not be included in the scan server 150.
  • the file received by the NIC 154 may be stored in the memory 152 or the HDD 153, and the scan result may be transmitted by the NIC 154.
  • the archiver 160 is a computer that receives and archives a file via the network 103 and transmits the archived file.
  • the CPU 161 of the archiver 160 executes a program stored in the memory 162, reads / writes data from / to the memory 162 or the HDD 163, controls communication of the NIC 164, and controls communication with the storage by the HBA 165.
  • the operation of the HBA 165 is the same as the operation of the HBA 126. Then, the file data to be archived may be stored in the HDD 163 or may be stored in the block storage 170 via the HBA 165.
  • the block storage 170 is a general storage that responds to a block data read request and stores the data in response to a block data write request.
  • Each of the CPU 171, the memory 172, the HDD 173, and the CHA 174 of the block storage 170 may be the same as each of the CPU 141, the memory 142, the HDD 143, and the CHA 144 of the block storage 140. Further, the number of HDDs 173 may be different from the number of HDDs 143.
  • FIG. 2 is a diagram showing an example of system software.
  • each memory of the client 110, the file storage 120, the block storage 140, the scan server 150, the archiver 160, and the block storage 170 includes a kernel and a device driver, and includes an OS (Operating System) and an RTOS (Real Time OS).
  • OS Operating System
  • RTOS Real Time OS
  • a program called a monitor program, a basic program, and the like are also stored. However, since the program is generally stored in a computer, illustration and description thereof are omitted.
  • an application 116 is stored as a program 115.
  • the application 116 is, for example, a Web browser program, and a display output by executing the Web browser program is a GUI (Graphical User Interface), and a click in a specific area is a file write, and another specific Clicking on the area reads the file.
  • an operation by clicking on a specific area may include reading or writing a file.
  • the CPU 111 uses, for example, a CIFS (Common Internet Internet File System) or NFS (Network File System, NFS is a registered trademark) protocol. Therefore, the NIC 114 is controlled to communicate with the NIC 124.
  • CIFS Common Internet Internet File System
  • NFS Network File System
  • a file sharing system 128, a file system 129, a data mover 130, and a recall control 131 are stored as programs 127.
  • the file sharing system 128 is a program that interprets the CIFS or NFS protocol and converts it into a local file read request or write request in the file storage 120.
  • the file system 129 is a program that converts a local file read request or write request in the file storage 120 into a block data read request or write request based on the file management information, and accesses the HDD 123 or the block storage 140. is there.
  • the file management information an example of inode will be described with reference to FIG.
  • the data mover 130 is a program that reads data stored in the HDD 123 or the block storage 140 as a file by executing the file system 129, and moves the read file to the archiver 160. This is a program that moves to the file storage 120.
  • the recall control 131 is a program that responds to a read request from the client 110 in cooperation with the file system 129 and the data mover 130. For this response, in particular, the virus infection of the file archived in the archiver 160 is detected. This is a program for determining using the scan server 150. A response sequence to the read request will be described with reference to FIGS.
  • a RAID control 146 is stored as a program 145.
  • the CPU 141 executes RAID control 146 to distribute and write block data to a plurality of HDDs included in the HDD 143, read the block data that has been distributed and written, and failure of some HDDs included in the HDD 143 Is complemented with other HDDs.
  • the scan engine 156 is stored in the memory 152 of the scan server 150 as the program 155.
  • the scan engine 156 is a program for detecting a virus contained in a file, and is a program manufactured and sold by a security maker.
  • the memory 152 preferably stores a plurality of types of scan engines 156 or a plurality of security manufacturers' scan engines 156.
  • the scan engine 156 stored in the memory 152 of the scan server 150 of the edge A 101-1 and the scan engine of the edge B 101-2 corresponding to the scan engine 156 are different types or scan engines of different security manufacturers. It is preferable that The CPU 151 executes the scan engine 156, scans the file received by the NIC 154, determines whether the file is infected with a virus, and transmits the determined scan result by the NIC 154.
  • an archive 167 and a file system 168 are stored as programs 166.
  • the archive 167 is a program for archiving a file moved from the file storage 120 to the HDD 163 or the block storage 170 as block data by the execution of the file system 168.
  • the archived data is read by executing the file system 168, and then the file is read. And the read file is transferred to the file storage 120.
  • the archive 167 is also a program for managing information related to virus infection. Information on virus infection will be described with reference to FIG. 5, and the movement of the CPU 161 for executing the archive 167 and the information management sequence will be described with reference to FIGS.
  • the file system 168 is a program that converts a local file read request or write request in the archiver 160 into a block data read request or write request based on the file management information, and accesses the HDD 163 or the block storage 170. .
  • file management information an example of inode will be described with reference to FIG.
  • a RAID control 176 is stored as a program 175.
  • the CPU 171 executes RAID control 176 to distribute and write block data to a plurality of HDDs included in the HDD 173, read the block data that has been distributed and written, and failure of some HDDs included in the HDD 173 Is complemented with other HDDs.
  • each of the programs 115, 127, 145, 155, 166, and 175 described with reference to FIG. 2 may be a program area of each memory.
  • the system shown in FIGS. 1 and 2 may be a storage system, and the file storage 120 may be a NAS (Network Attached Storage) or a file server.
  • File storage 120 may include block storage 140, and archiver 160 may include block storage 170.
  • FIG. 3 is a diagram showing an example of an inode of the edge A 101-1, the edge B 101-2, and the core 102.
  • inode is information that is widely known and used as file management information, but the inode shown in FIG. 3 is an example of file management information, and other management information may be included in the inode. However, it may be management information of other types of files.
  • the inode of the edge A 101-1 is information that is used when the file system 129 of the file storage 120 is executed by the CPU 121, and is stored in the HDD 123 or the block storage 140.
  • the inode of the edge A 101-1 is identified by the inode number 301-1 for identifying the inode, the file path name 302-1 for identifying the inode target file, the inode or the file path name 302-1. Includes the last update date 303-1 of the file.
  • the inode of the edge A 101-1 stores a recall prohibit flag 304-1 indicating whether or not the recall is prohibited, a stubbing flag 305-1 indicating whether or not the stubbing is performed, and storage of a file when stubbing is performed. It further includes a storage destination URL (Uniform Resource Locator) 306-1 indicating the destination, and block addresses 307-1 and 308-1 indicating the addresses of the block data constituting the file data when not stubbed.
  • URL Uniform Resource Locator
  • Recall is an operation in which the file storage 120 acquires a file archived in the archiver 160 and transmits it to the client 110.
  • “OFF” of the recall prohibition flag 304-1 means that the recall is permitted, that is, transmission to the client 110 is permitted.
  • “ON” of the recall prohibition flag 304-1 means that recall is prohibited, that is, transmission to the client 110 is not permitted.
  • the stubbing flag 305-1 When the stubbing flag 305-1 is “ON”, the data of the file identified by the file path name 302-1 is not stored in either the HDD 123 or the block storage 140, and is archived in the archiver 160. Means state. “OFF” of the stubbing flag 305-1 means that the data of the file identified by the file path name 302-1 is stored in either the HDD 123 or the block storage 140.
  • the storage destination URL 306-1 is a URL for identifying the core 102 or the archiver 160 and identifying the archived file of the archiver 160 with respect to “ON” of the stubification flag 305-1. In contrast to “OFF” of the stubbing flag 305-1, the storage destination URL 306-1 may be “NULL” or may be meaningless information because it is not referred to. .
  • Block addresses 307-1 and 308-1 are addresses at which block data obtained by dividing file data in the HDD 123 or the block storage 140 is stored in response to “OFF” of the stubification flag 305-1.
  • the block addresses 307 and 308 may be “NULL” or may be meaningless information because they are not referred to.
  • FIG. 3 shows an example of two block addresses for two block data, but there may be one or three or more.
  • the inode may have information on the number of block data constituting the data of one file. Even if the next block address of the last block data is “NULL”, the end is represented. Good. Further, the inode of the edge A 101-1 may include general inode information.
  • Edge B 101-2 inode inode number 301-1, file path name 302-2, last update date and time 303-2, recall prohibit flag 304-2, stubbing flag 305-2, storage destination URL 306-2, block address
  • Each of 307-2 and 208-2 has the same meaning as the information of the same name of the inode of the edge A 101-1. Since the file storage 120 of the edge A 101-1 and the file storage of the edge B 101-2 are physically different storages, the inodes are also stored separately, and are therefore given different reference numerals.
  • the inode of the core 102 is information that is used when the file system 168 of the archiver 160 is executed by the CPU 161 and is stored in the HDD 163 or the block storage 170.
  • the inode of the core 102 includes an inode number 311 for identifying the inode, a file path name 312 for identifying the inode target file, and the last update date and time 313 of the file identified by the inode or the file path name 312. .
  • the inode of the core 102 includes block addresses 314 and 315 indicating addresses of block data constituting archived file data, an internal link 316 that is link information to a version file not infected with a virus, and one It further includes an old version link 317 which is link information to the previous version file.
  • Block addresses 314 and 315 are addresses at which block data obtained by dividing file data in the HDD 163 or the block storage 170 is stored.
  • FIG. 3 shows an example of two block addresses for two block data, but there may be one or three or more.
  • the internal link 316 and the old version link 317 will be described with reference to FIG.
  • FIG. 3 is an example of an inode in which the file “/dir1/a.txt” is stubbed at both the edge A 101-1 and the edge B 101-2.
  • the storage destination URL 306-1 and the storage destination URL 306-2 are shown in FIG. In this example, both are “http: //hcp/dir2/a.txt” and the inode whose inode number 311 is “20” is indicated. Therefore, the file data of the file path name 302-1 of the edge A 101-1 of “/dir1/a.txt” is blocked with the file path name 312 of the core 102 of “/dir2/a.txt”. That is, “0000010” of the address 314 and “0000020” of the block address 315 are stored.
  • FIG. 4 is a diagram illustrating an example of an inode link of the core 102.
  • the same types of information as in FIG. 3 are denoted by the same reference numerals, and the positional relationships of information included in the four inodes are associated with dotted lines in order to make the figure easier to see. This positional relationship does not represent the stored address of the inode but is for explanation.
  • the inode whose inode number 311 is “20” shown in FIG. 4 is the inode of the core 102 shown in FIG. 3.
  • the file path name 302-1 of the edge A 101-1 is “/ dir1”.
  • the updated file "/a.txt” is stubbed 3 times.
  • the old version link 317 is link information to the previous version of the stubbed file.
  • the file path name 312 is “dir3”. Link to "/a.txt" inode.
  • the old version link 317 links to the inode whose file path name 312 is “dir4 / a.txt” when the file path name 312 is “/dir3/a.txt”, and the file path name 312. Is inode with “/dir4/a.txt”, the file path name 312 links to the inode with “dir5 / a.txt”.
  • the information of the old version link 317 does not need to be information corresponding to the information of the file / path name 312 and may be, for example, the information of the inode number 311 or the address where the inode is stored.
  • the internal link 316 is a link to an inode having block addresses 314 and 315 that are data of files in which virus infection is not detected among a plurality of files having the same file name “a.txt”.
  • FIG. 4 shows an example in which no virus infection is detected in the data stored in the block address 314 of “0000070” and the block address 315 of “0000080”.
  • the internal link 316 is “/dir5/a.txt”. is there. Note that the information of the internal link 316 is not necessarily information corresponding to the information of the file / path name 312.
  • the internal link 316 may be a link to an inode that has the smallest number of old version links 317. If virus infection is detected in the data of the block addresses 314 and 315 of the inode where the old version link 317 has the smallest number of links, the old version link 317 is a link to the inode that has the next smallest number of links. May be.
  • the old version link 317 may be “NULL”, and the internal link of the inode in which virus infection was not detected in the data of the block addresses 314 and 315 may be “NULL”.
  • the internal link 316 is a value indicating the detection of the infection. Good.
  • FIG. 5 is a diagram showing an example of the scan result.
  • the scan result information is information used by the archive 161 being executed by the CPU 161 of the archiver 160, and is stored in any of the memory 162, the HDD 163, and the block storage 170 of the core 102.
  • the scan result includes a file path name 511 corresponding to the file path name 312 of the inode, and a hash value 512 of the file data for determining file modification and the like.
  • the scan results include a scan engine name 513 for identifying the scan engine 156 used for detecting the virus infection, a virus definition file version 514 for identifying the virus definition of the scan engine 156, and the date and time when the scan engine 156 was executed.
  • the scan date and time 515, and the infection 516 that is the result of execution of the scan engine 156 is further included.
  • Information of the scan engine name 513, virus definition file version 514, scan date 515, and infection 516 is transmitted by the NIC 151 by the CPU 151 of the scan server 150, transferred by the NIC 124 and NIC 125 by the CPU 121 of the file storage 120, and by the CPU 161 of the archiver 160. Received by the NIC 164 and stored. The storage of information on the infection 516 will be further described with reference to FIGS.
  • the information of the file path name 511 may be stored when the inode of the core 102 shown in FIGS. 3 and 4 is generated, and the information of the hash value 512 is the file data from the NIC 125 of the file storage 120 for stubbing.
  • the data may be received and stored together, or when receiving the data of the file, it may be calculated and stored by the CPU 161 using the data of the received file.
  • FIG. 6 is a diagram showing an example of a sequence from generation of a read request in reading a file to acquisition of a scan result.
  • the CPU 111 of the client 110 executes the application 116, controls the NIC 114, and transmits a read request to the file storage 120 (step 601).
  • the NIC 124 receives a read request in the file storage 120
  • the CPU 121 executes the file sharing system 128 and analyzes the read request (step 602).
  • the analysis of the read request is, for example, an analysis of whether the request is a CIFS read request, and at least the file that is the target of the read request and the file corresponding to the file path name 302-1 is analyzed.
  • the CPU 121 executes the file system 129, searches for an inode, finds an inode of the file path name 302-1 that matches the analyzed information, and acquires other information of the found inode (step 603).
  • the CPU 121 executes the recall control 131 and determines whether or not the stubbing flag 305-1 in the acquired information is “ON” (step 604). When it is determined that the stubification flag 305-1 is not “ON”, that is, is “OFF” and is not stubbed, the CPU 121 executes the file system 129 to the block addresses 307-1 and 308-1. The stored data is read from the HDD 123 or the block storage 140. Then, the CPU 121 executes the file sharing system 128 and transmits the read data as a file to the client 110 by the NIC 124 (step 605).
  • the CPU 121 executes the recall control 131, and the recall prohibiting flag 304-1 in the acquired information is “ON”. Is determined (step 606).
  • the CPU 121 executes the recall control 131 and sends error information to the client as a response to the read request from the client 110 via the NIC 124. Transmit (step 607).
  • the CPU 121 executes the recall control 131 and stores the storage destination URL 306 in the acquired information.
  • -1 is designated as a scan target, a scan result request is transmitted to the archiver 160 by the NIC 125, and a response from the archiver 160 is received (step 608).
  • the CPU 161 executes the archive 167, searches the scan result described with reference to FIG. The file path name 511 that matches the storage location URL 306-1 specified as is found.
  • the CPU 161 executes the archive 167, acquires the infection 516 corresponding to the found file path name 511, and responds with “Yes” or “No” of the acquired infection 516 to the file storage 120 by the NIC 164. Transmit (step 609).
  • the CPU 121 of the file storage 120 executes the recall control 131 and receives a “Yes” or “No” response from the archiver 160 by the NIC 125.
  • FIG. 6 is a diagram in which the client 110 receives the file in step 605 and receives the error in step 607. However, the client 110 indicates that each file is received and does not receive both as a sequence. . A device that receives or transmits in this way is represented, and a relationship that does not represent a sequence is a broken line. Also, the inode shown in FIG. 3 is an example of information that reaches Step 608.
  • FIG. 7 is a diagram showing an example of a sequence from the determination of the scan result to the transmission of the stubbed file and the update of the scan result in reading the file.
  • the sequence example shown in FIG. 7 is a continuation of the sequence example shown in FIG.
  • the CPU 121 of the file storage 120 executes the recall control 131 and determines whether or not the scan result received in step 608 is “present” (step 610).
  • the CPU 121 determines that it is “present”, that is, it is infected, the CPU 121 executes the file system 129, sets the inode recall prohibition flag 304-1 to “ON” (step 611), and reads from the client 110. As a response to the request, error information is transmitted to the client by the NIC 124 (step 612).
  • the CPU 121 executes the data mover 130 and requests the archiver 160 to perform a recall with the NIC 125 (step 613).
  • the CPU 121 designates the same storage location URL 306-1 as in step 608 as the recall target.
  • the CPU 161 executes the file system 168 and acquires data of a file designated as a recall target. That is, the CPU 161 searches the inode of the core 102 described with reference to FIGS. 3 and 4, and finds the file path name 312 that matches the storage destination URL 306-1 designated as the recall target.
  • the CPU 161 determines whether or not a link is set to the internal link 316 of the inode of the found file / path name 312 and determines that the link is not set, that is, for example, “NULL” is set.
  • the data stored in the block addresses 314 and 315 of the inode where the link is not set is acquired, and the acquired file data is transmitted as a response to the file storage 120 by the NIC 164 (step 614).
  • the CPU 161 When determining that the link is set, the CPU 161 acquires the data stored in the block addresses 314 and 315 of the link destination inode of the internal link 316, and sends the acquired file data to the file storage 120 as a response. Transmit by NIC164.
  • the internal link 316 is “/dir5/a.txt”
  • an inode block having a file path name 312 of “/dir5/a.txt” and an inode number 311 of “50”.
  • Data stored in addresses “31470” and “0000070” and “0000080” are transmitted.
  • step 614 the execution of the file system 168 by the CPU 161 has been described.
  • the CPU 161 may further execute the archive 167 for some file management as an archive.
  • the CPU 121 executes the data mover 130 and transmits the received file data and a scan request to the scan server 150 via the NIC 124 ( Step 615).
  • the file data received from the archiver 160 may be stored in the memory 122 or the HDD 123.
  • the CPU 151 executes the scan engine 156 and scans the received file data to detect the presence or absence of virus infection.
  • the CPU 151 transmits the detected result as a response to the file storage 120 via the NIC 154 (step 616).
  • the result to be transmitted may include each information of the scan result described with reference to FIG.
  • the CPU 121 executes the recall control 131 and determines whether the virus infection information included in the received result is “None”. If the CPU 121 determines that it is “No”, that is, it is not infected, the CPU 121 executes the file sharing system 128 and transmits the data of the file received in Step 613 to the client 110 via the NIC 124 (Step 621), and stubs are created.
  • the flag 305-1 is set to “OFF” (step 622).
  • the CPU 121 executes the file system 129 and sets the inode recall prohibition flag 304-1 to “ON” (step 617). Then, the CPU 121 executes the recall control 131 and transmits error information to the client via the NIC 124 as a response to the read request from the client 110 (step 618). In step 618, the CPU 121 may notify the system administrator by email or the like.
  • the CPU 121 executes the recall control 131 and transmits the result received in step 613 to the archiver 160 by the NIC 125 (step 619).
  • the CPU 161 executes the archive 167 and stores the received result in the scan result described with reference to FIG. 5 (step 620).
  • the storage of the scan result if the same information as the received result has already been stored in the file path name 511 and the hash value 512 of the scan result, the information from the already stored scan engine name 513 to the infection 516 is stored. The information may be overwritten with the received result information.
  • the stubbed file is returned to the client 110 based on the newly scanned result in addition to the past scanned result.
  • the result of the new detection can also be used.
  • the scan result can be used in the recall of the file storage of the edge other than the edge where the new detection is performed.
  • the scan result is not requested to the archiver 160, and the file storage of the edge other than the edge that has newly detected is detected. However, since the scan result is acquired once and the recall is prohibited by the recall prohibit flag, the scan result request to the archiver 160 is not repeated.
  • FIG. 8 is a diagram showing an example of a sequence for stubbing a file from the file storage 120 to the archiver 160.
  • the CPU 121 of the file storage 120 executes the data mover 130 periodically at a preset time interval to acquire preset stubification conditions (step 701).
  • the stubbing condition includes, for example, a total capacity of data stored in the HDD 123 or the block storage 140, a threshold for the total capacity of the file managed by the file system 129, and a reference date / time for the file update date / time. included.
  • the reference date and time may be the date and time of the previous execution in periodic execution at a preset time interval.
  • the stubbing condition may include other conditions.
  • the CPU 121 executes the file system 129, acquires the total capacity of the file, and determines whether the acquired total capacity is larger than the threshold value of the stubbing condition. For obtaining the total file capacity, for example, the total data capacity of each of a plurality of files managed by executing the file system 129 may be calculated. When it is determined that the acquired total capacity is not larger than the threshold value of the stubbing condition, the stubbing sequence is terminated.
  • the CPU 121 executes the data mover 130 to select one of the files, and the CPU 121 executes the file system 129 to check the selected file.
  • Inode information is acquired (step 703).
  • the acquired inode information includes the last update date 303-1 and block addresses 307-1 and 308-1.
  • the CPU 121 executes the data mover 130, compares the reference date / time included in the stubification condition with the last update date / time 303-1, and determines whether the last update date / time 303-1 is a later date / time (step 704). ). If it is determined that the last update date 303-1 is not a later date, the CPU 121 proceeds to step 708.
  • the CPU 121 executes the data mover 130 and sets the file path name 302-1 and the block addresses 307-1 and 308-1.
  • the stored data is transmitted to the archiver 160 as a file to be stubbed by the NIC 125, and a response is received from the archiver 160 (step 705).
  • the CPU 161 executes the archive 167 and the file system 168 to generate the inode of the core 102 described with reference to FIGS.
  • the received data is stored and the address of the stored data is set to the block addresses 314 and 315, and the file path name 312 of the generated inode and the file path name 302-1 transmitted in step 705 are stored.
  • the CPU 121 executes the file system 129, and based on the received file path name 302-1,
  • the received file path name 312 is set in the storage URL 306-1 of the inode, “ON” is set in the stubbing flag 305-1, and the inode is updated (step 707).
  • the file storage of the edge B 101-2 may perform the same operation.
  • the CPU 121 executes the data mover 130 to determine whether to end the stubbing (step 708). When it is determined to end the stubbing, the sequence of the stubbing is ended, and when it is determined not to end the stubbing, the step is performed. Returning to 703, one other file is selected.
  • the determination of the end of stubbing may be, for example, a determination that the total capacity reduced by stubbing is not larger than the threshold value of the stubbing condition, or whether a preset date has passed. Alternatively, it may be determined whether a file in a preset range has been selected.
  • the file can be stubbed and information related to the stub can be set in the inode.
  • FIG. 9 is a diagram showing an example of a sequence for recovering an archived file to a file in which no virus infection is detected, and updating a scan result and a recall prohibition flag.
  • the inode of the core 102 holds information on each update. For this reason, if there is a file for which no virus infection is detected, the file can be recovered.
  • the CPU 161 of the archiver 160 periodically executes the archive 167 at a preset time interval, acquires the scan result described with reference to FIG. 5 (step 801), and the acquired scan result infection 516 A “present” file is selected (step 802).
  • the CPU 161 executes the file system 168 and obtains an inode of the file path name 312 that matches the file path name 511 of the selected file (step 803).
  • the CPU 161 executes the file system 168 and follows the old version link of the acquired inode.
  • the file path name 312 of the reached inode is acquired. Change the internal link 316 of the inode.
  • the file path name 312 of the acquired inode is “/dir2/a.txt”, and “/dir3/a.txt”, “/dir4/a.txt” of the old version link 317, This is an example in which the internal link 316 is changed to “/dir5/a.txt” because the internal link 316 is “NULL” in the case of “/dir5/a.txt”.
  • the CPU 161 executes the archive 167, notifies the system administrator of the change of the internal link 316 by e-mail or the like (step 806), and updates the scan result infection 516 described with reference to FIG. 807), the file path name 312 of the acquired inode is specified, and a request to change the recall prohibition flag is transmitted to the file storage 120 by the NIC 164 (step 808). This transmission may be broadcast or multicast.
  • the CPU 121 executes the file system 129, and the inode of the file path name 302-1 that matches the specified file path name 312.
  • the recall prohibit flag 304-1 is changed to “OFF”.
  • the file storage of the edge B 101-2 may perform the same operation.
  • virus infection information detected at any one of a plurality of edges can be used as a core scan result. Since the recall of each edge is prohibited by the scan result of the core, the result detected at one edge can be used at another edge. Furthermore, it is possible to recover to a file in which no virus was detected, and once the file is recovered in the core, each edge does not prohibit recall based on the recovery and the archived file becomes available.
  • Block storage 110 Client 120 File storage 128 File sharing system 129 File system 130 Data mover 131 Recall control 140 Block storage 150 Scan server 160 Archiver 167 Archive 168 File system 170 Block storage

Abstract

　複数のファイルストレージと、ファイルをアーカイブするアーカイバとが接続されたストレージシステムであって、複数の前記ファイルストレージのそれぞれは、前記ファイルストレージが記憶したファイルを前記アーカイバへ送信して、送信されたファイルの管理情報を保持し、ファイルのリードにおいて、前記管理情報に基づきファイルが前記アーカイバへ送信されたことを判定し、前記管理情報に基づきファイルの前記アーカイバからの受信が禁止されていないことを判定し、ファイルに対する第１のスキャン結果を前記アーカイバへ要求して取得し、取得された第１のスキャン結果に基づきファイルを前記アーカイバへ要求して取得し、取得されたファイルに対する第２のスキャン結果を取得し、取得された第２のスキャン結果を前記アーカイバへ送信し、前記アーカイバは、前記ファイルストレージからの要求に対して応答し、前記ファイルストレージからの第２のスキャン結果を第１のスキャン結果として記録する。

Description

ストレージシステム
　本発明は、ストレージシステムに関するものである。
　ネットワークを介したウイルスの感染による被害は年々増加の傾向にある。近年では、メールやホームページによるウイルスの感染のみならず、情報（ファイル）の共有においてもウイルスの感染が拡大している。
　特許文献１には「ＮＡＳ装置１０は、クライアントコンピュータから送信されたファイルのウイルス感染検知時、各ユーザＯＳが制御するファイル管理モジュールのうち、ウイルスに感染しているファイルが格納される可能性のあるディレクトリグループを利用するファイル管理モジュールの運用を停止」すると記載され、「他の論理ボリュームへのウイルス感染による二次被害の防止および計算機システムの運用上の損失の抑制を図ることができる」と記載されている。
特開２００８－０９０７０２号公報
　特許文献１に記載された技術を用いれば、二次被害の防止などが可能となる。しかしながら、複数のＮＡＳ装置（ファイルストレージ）間での二次被害を防止に関する技術や、ウイルスの感染を検出するためのファイルのスキャンの進歩を活かす技術の記載は見当たらない。
　そこで、本発明の目的は、複数のファイルストレージが協調してウイルスの感染を防止するストレージシステムを提供することにある。
　本発明に係る代表的なストレージシステムは、それぞれがファイルを記憶する複数のファイルストレージと、ファイルをアーカイブするアーカイバとが接続されたストレージシステムであって、複数の前記ファイルストレージのそれぞれは、前記ファイルストレージが記憶したファイルを前記アーカイバへ送信して、送信されたファイルの管理情報を保持し、ファイルのリードにおいて、前記管理情報に基づきファイルが前記アーカイバへ送信されたことを判定し、前記管理情報に基づきファイルの前記アーカイバからの受信が禁止されていないことを判定し、ファイルに対する第１のスキャン結果を前記アーカイバへ要求して取得し、取得された第１のスキャン結果に基づきファイルを前記アーカイバへ要求して取得し、取得されたファイルに対する第２のスキャン結果を取得し、取得された第２のスキャン結果を前記アーカイバへ送信し、前記アーカイバは、前記ファイルストレージからファイルを受信してアーカイブし、前記ファイルストレージからの第１のスキャン結果の要求に対して、記録された第１のスキャン結果を応答し、前記ファイルストレージからのファイルの要求に対して、アーカイブされたファイルを応答し、前記ファイルストレージからの第２のスキャン結果を第１のスキャン結果として記録することを特徴とする。
　本発明によれば、複数のファイルストレージが協調してウイルスの感染を防止するストレージシステムを提供することができる。
システムのハードウェアの例を示す図である。 システムのソフトウェアの例を示す図である。 エッジとコアのinodeの例を示す図である。 コアのinodeのリンクの例を示す図である。 スキャン結果の例を示す図である。 リードでのスキャン結果を取得するまでのシーケンスの例を示す図である。 リードでのスキャン結果に基づくシーケンスの例を示す図である。 エッジからコアへのスタブ化のシーケンスの例を示す図である。 スキャン結果とリコール禁止フラグの更新シーケンスの例を示す図である。
　以下、図面を用いて実施の形態を説明する。
　図１は、システムのハードウェアの例を示す図である。システムは、エッジＡ１０１－１、エッジＢ１０１－２とコア１０２とに分けられ、これらはネットワーク１０３により接続される。エッジＡ１０１－１、エッジＢ１０１－２はシステムのエッジに位置し、ユーザへサービスを提供する装置群であり、コア１０２はシステムのコアに位置し、エッジＡ１０１－１、エッジＢ１０１－２へサービスを提供する装置群である。
　エッジＡ１０１－１とエッジＢ１０１－２は同じタイプの装置群を含み、図１では、エッジＡ１０１－１とエッジＢ１０１－２の２つの例を示したが、３つ以上であってもよい。クライアント１１０は、ユーザにより操作される一般的なコンピュータであり、ＣＰＵ（Central Processing Unit）１１１がメモリ１１２に格納されたプログラムを実行し、メモリ１１２あるいはＨＤＤ（Hard Disk Drive）１１３に対してデータを読み書きし、ＮＩＣ（Network Interface Card）１１４の通信を制御する。
　メモリ１１２に格納されるプログラムとデータはＨＤＤ１１３から読み出されてもよい。ＨＤＤ１１３はＳＳＤ（Solid State Drive）であってもよく、ＨＤＤ１１３はクライアント１１０に含まれない、いわゆるディスクレスであって、クライアント１１０に接続されたネットワークへＨＤＤ１１３に相当するストレージが接続されてもよい。
　ＮＩＣ１１４はネットワークを介してファイルストレージ１２０と接続される。クライアント１１０のＣＰＵ１１１はメモリ１１２に格納されたプログラムを実行し、ＮＩＣ１１４を制御して、ファイルストレージ１２０へファイルのリード要求やライト要求を送信する。メモリ１１２に格納されるプログラムは、図２を用いて後で説明する。
　ファイルストレージ１２０は、ファイルのリード要求に対してファイルのデータを応答し、ファイルのライト要求に対してファイルのデータを保存してファイルとして管理するコンピュータである。ファイルストレージ１２０のＣＰＵ１２１は、メモリ１２２に格納されたプログラムを実行し、メモリ１２２あるいはＨＤＤ１２３に対してデータを読み書きし、ＮＩＣ１２４、ＮＩＣ１２５の通信を制御し、ＨＢＡ（Host Bus Adapter）１２６によるストレージとの通信を制御する。
　メモリ１２２に格納されるプログラムとデータはＨＤＤ１２３から読み出されてもよく、ＨＤＤ１２３はＳＳＤであってもよい。ＮＩＣ１２４は、エッジＡ１０１－１内のネットワークを介してクライアント１１０およびスキャンサーバ１５０と接続される。ＮＩＣ１２５は、エッジＡ１０１－１外のネットワーク１０３を介してコア１０２のアーカイバ１６０と接続される。
　ＮＩＣ１２４は、クライアント１１０と接続されるＮＩＣと、スキャンサーバ１５０と接続されるＮＩＣとの複数のＮＩＣを含んでもよい。逆に、ＮＩＣ１２４とＮＩＣ１２５は１つのＮＩＣであってもよい。また、ＮＩＣ１２４とＮＩＣ１２５は、同じ通信プロトコルをサポートするＮＩＣであってもよいし、異なる通信プロトコルをサポートするＮＩＣであってもよく、サポートされる通信プロトコルがＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）であってもよい。
　ＨＢＡ１２６は、周辺装置と通信するアダプタであり、ブロックストレージ１４０と接続される。ＨＢＡ１２６はＦＣ（Fibre Channel）をサポートするＨＢＡであってもよいし、ｉＳＣＳＩ（internet SCSI）をサポートするＨＢＡであってもよいし、ＳＡＴＡ（Serial ATA）をサポートするＨＢＡであってもよい。保存されるファイルのデータは、ＨＤＤ１２３に格納されてもよいし、ＨＢＡ１２６を介してブロックストレージ１４０に格納されてもよい。
　ブロックストレージ１４０は、ブロックデータのリード要求に対してデータを応答し、ブロックデータのライト要求に対してデータを保存する一般的なストレージである。ブロックストレージ１４０のＣＰＵ１４１はメモリ１４２に格納されたプログラムを実行し、ＣＨＡ（Channel Adapter）１４４で受信したリード要求とライト要求に応じてＨＤＤ１４３へアクセスする。
　メモリ１４２に格納されるプログラムは、ＨＤＤ１４３から読み出されてもよいし、メモリ１４２が不揮発性メモリであって、プログラムを保持し続けてもよい。ＨＤＤ１４３はリード要求とライト要求に応じてリードとライトされるデータが格納される。ＨＤＤ１４３は複数のＨＤＤであってもよく、複数のＨＤＤはＲＡＩＤ（Redundant Arrays of Inexpensive Disks）であってもよい。
　ブロックストレージ１４０は、短時間に多数のリード要求とライト要求に応答し、多数のＨＤＤ１４３へアクセスするために、専用のハードウェアを有してもよい。この専用のハードウェアは、ＣＰＵ１４１と処理を分担してもよいし、ＣＰＵ１４１から制御されてもよい。
　スキャンサーバ１５０は、ファイルストレージ１２０から受信したファイルをスキャンし、ウイルスの感染を検出するコンピュータである。スキャンサーバ１５０のＣＰＵ１５１はメモリ１５２に格納されたプログラムを実行し、メモリ１５２あるいはＨＤＤ１５３に対してデータを読み書きし、ＮＩＣ１５４の通信を制御する。
　メモリ１５２に格納されるプログラムはＨＤＤ１５３から読み出されてもよい。ＨＤＤ１５３はＳＳＤであってもよく、ＨＤＤ１５３はスキャンサーバ１５０に含まれなくてもよい。ＮＩＣ１５４により受信されたファイルはメモリ１５２あるいはＨＤＤ１５３に格納されてもよく、ＮＩＣ１５４によりスキャンの結果が送信されてもよい。
　アーカイバ１６０は、ネットワーク１０３経由で、ファイルを受信してアーカイブし、アーカイブされたファイルを送信するコンピュータである。アーカイバ１６０のＣＰＵ１６１は、メモリ１６２に格納されたプログラムを実行し、メモリ１６２あるいはＨＤＤ１６３に対してデータを読み書きし、ＮＩＣ１６４の通信を制御し、ＨＢＡ１６５によるストレージとの通信を制御する。
　接続するストレージは異なるが、ＨＢＡ１６５の動作は、ＨＢＡ１２６の動作と同じである。そして、アーカイブされるファイルのデータは、ＨＤＤ１６３に格納されてもよいし、ＨＢＡ１６５を介してブロックストレージ１７０に格納されてもよい。
　ブロックストレージ１７０は、ブロックデータのリード要求に対してデータを応答し、ブロックデータのライト要求に対してデータを保存する一般的なストレージである。ブロックストレージ１７０のＣＰＵ１７１、メモリ１７２、ＨＤＤ１７３、ＣＨＡ１７４のそれぞれは、ブロックストレージ１４０のＣＰＵ１４１、メモリ１４２、ＨＤＤ１４３、ＣＨＡ１４４のそれぞれと同じであってもよい。また、ＨＤＤ１７３の個数は、ＨＤＤ１４３の個数と異なってもよい。
　図２は、システムのソフトウェアの例を示す図である。図１と同じものには同じ符号を付して説明を省略する。また、クライアント１１０、ファイルストレージ１２０、ブロックストレージ１４０、スキャンサーバ１５０、アーカイバ１６０、ブロックストレージ１７０のそれぞれのメモリには、カーネルとデバイスドライバを含めて、ＯＳ（Operating System）、ＲＴＯＳ（Real Time OS）、モニタプログラム、基本プログラムなどと呼ばれるプログラムも格納されるが、コンピュータ一般に格納されるプログラムであるので、図示と説明を省略する。
　クライアント１１０のメモリ１１２には、プログラム１１５としてアプリケーション１１６が格納される。アプリケーション１１６は例えばＷｅｂブラウザプログラムであり、Ｗｅｂブラウザプログラムが実行されることにより出力される表示は、ＧＵＩ（Graphical User Interface）であって、特定の領域のクリックがファイルのライトであり、別の特定の領域のクリックがファイルのリードである。あるいは、特定の領域のクリックによる動作が、ファイルのリードかライトを含んでもよい。
　ＣＰＵ１１１は、アプリケーション１１６の実行により取得した、少なくともファイルの名称とリード要求かライト要求かの情報に基づき、例えばＣＩＦＳ（Common Internet File System）かＮＦＳ（Network File System、ＮＦＳは登録商標）のプロトコルにしたがって、ＮＩＣ１１４がＮＩＣ１２４と通信するように制御する。
　ファイルストレージ１２０のメモリ１２２には、プログラム１２７としてファイル共有システム１２８、ファイルシステム１２９、データムーバ１３０、リコール制御１３１が格納される。ファイル共有システム１２８は、ＣＩＦＳかＮＦＳのプロトコルを解釈し、ファイルストレージ１２０内でローカルなファイルのリード要求かライト要求に変換するプログラムである。
　ファイルシステム１２９は、ファイルストレージ１２０内でローカルなファイルのリード要求かライト要求を、ファイルの管理情報に基づいてブロックデータのリード要求かライト要求へ変換し、ＨＤＤ１２３あるいはブロックストレージ１４０へアクセスするプログラムである。ファイルの管理情報については、図３を用いて、inodeの例を説明する。
　データムーバ１３０は、ＨＤＤ１２３あるいはブロックストレージ１４０に格納されたデータを、ファイルシステム１２９の実行によりリードしてファイルとし、リードしたファイルをアーカイバ１６０へ移動するプログラムであり、アーカイバ１６０にアーカイブされたファイルをファイルストレージ１２０へ移動するプログラムである。
　ＣＰＵ１２１はデータムーバ１３０を実行し、データをアーカイバ１６０へ移動すると、ＨＤＤ１２３あるいはブロックストレージ１４０に格納されたデータをスタブ化する。スタブ化とデータの移動のシーケンスについては、図３と図８をそれぞれ用いて説明する。また、スタブ化されているか否かに応じた、リードのシーケンスについては、図６を用いて説明する。
　リコール制御１３１は、ファイルシステム１２９およびデータムーバ１３０と連携して、クライアント１１０からのリード要求に応答するプログラムであり、この応答のために、特に、アーカイバ１６０にアーカイブされたファイルのウイルス感染を、スキャンサーバ１５０を利用して判定するプログラムである。リード要求への応答のシーケンスについては、図８と図９を用いて説明する。
　ブロックストレージ１４０のメモリ１４２には、プログラム１４５としてＲＡＩＤ制御１４６が格納される。ＣＰＵ１４１は、ＲＡＩＤ制御１４６を実行して、ＨＤＤ１４３に含まれる複数のＨＤＤへブロックデータを分散してライトし、分散してライトされたブロックデータをリードし、ＨＤＤ１４３に含まれる一部のＨＤＤの障害を他のＨＤＤで補完する。
　スキャンサーバ１５０のメモリ１５２には、プログラム１５５としてスキャンエンジン１５６が格納される。スキャンエンジン１５６は、ファイルに含まれるウイルスを検出するためのプログラムであり、セキュリティメーカによって製造、販売されているプログラムである。メモリ１５２には、複数種類のスキャンエンジン１５６あるいは複数のセキュリティメーカのスキャンエンジン１５６が格納されることが好ましい。
　また、エッジＡ１０１－１のスキャンサーバ１５０のメモリ１５２に格納されるスキャンエンジン１５６と、このスキャンエンジン１５６に相当するエッジＢ１０１－２のスキャンエンジンとは、別の種類あるいは別のセキュリティメーカのスキャンエンジンであることが好ましい。ＣＰＵ１５１は、スキャンエンジン１５６を実行して、ＮＩＣ１５４で受信したファイルをスキャンし、ファイルがウイルスに感染しているか否かを判定し、判定したスキャン結果をＮＩＣ１５４で送信する。
　アーカイバ１６０のメモリ１６２には、プログラム１６６としてアーカイブ１６７とファイルシステム１６８が格納される。アーカイブ１６７は、ファイルストレージ１２０から移動されるファイルを、ファイルシステム１６８の実行によりブロックデータとしてＨＤＤ１６３あるいはブロックストレージ１７０へアーカイブするプログラムであり、アーカイブされたデータをファイルシステム１６８の実行によりリードしてファイルとし、リードしたファイルをファイルストレージ１２０へ移動するプログラムである。
　アーカイブ一般の動作は、アーカイブという技術用語で表されるデータ管理技術分野の技術常識であるため、説明を省略する。また、アーカイブ１６７は、ウイルス感染に関する情報を管理するプログラムでもある。ウイルス感染に関する情報は、図５を用いて説明し、アーカイブ１６７を実行するＣＰＵ１６１の移動と情報管理のシーケンスは、図６－９を用いて説明する。
　ファイルシステム１６８は、アーカイバ１６０内でローカルなファイルのリード要求かライト要求を、ファイルの管理情報に基づいてブロックデータのリード要求かライト要求へ変換し、ＨＤＤ１６３あるいはブロックストレージ１７０へアクセスするプログラムである。ファイルの管理情報については、図３を用いて、inodeの例を説明する。
　ブロックストレージ１７０のメモリ１７２には、プログラム１７５としてＲＡＩＤ制御１７６が格納される。ＣＰＵ１７１は、ＲＡＩＤ制御１７６を実行して、ＨＤＤ１７３に含まれる複数のＨＤＤへブロックデータを分散してライトし、分散してライトされたブロックデータをリードし、ＨＤＤ１７３に含まれる一部のＨＤＤの障害を他のＨＤＤで補完する。
　なお、図２を用いて説明したプログラム１１５、１２７、１４５、１５５、１６６、１７５のそれぞれは、各メモリのプログラム領域であってもよい。また、図１、２に示したシステムはストレージシステムであってもよく、ファイルストレージ１２０はＮＡＳ（Network Attached Storage）であってもよいし、ファイルサーバであってもよい。ファイルストレージ１２０はブロックストレージ１４０を含んでもよく、アーカイバ１６０はブロックストレージ１７０を含んでもよい。
　図３は、エッジＡ１０１－１とエッジＢ１０１－２とコア１０２のinodeの例を示す図である。なお、inodeはファイルの管理情報として広く知られ使用されている情報であるが、図３に示したinodeはファイルの管理情報の例であって、inodeに他の管理情報が含まれてもよいし、他の種類のファイルの管理情報であってもよい。
　エッジＡ１０１－１のinodeは、ファイルストレージ１２０のファイルシステム１２９がＣＰＵ１２１により実行されて使用される情報であり、ＨＤＤ１２３あるいはブロックストレージ１４０に格納される。エッジＡ１０１－１のinodeは、inodeを識別するためのinode番号３０１－１、inodeの対象ファイルを識別するためのファイル・パス名３０２－１、inodeあるいはファイル・パス名３０２－１で識別されるファイルの最終更新日時３０３－１を含む。
　また、エッジＡ１０１－１のinodeは、リコールを禁止するか否かを示すリコール禁止フラグ３０４－１、スタブ化されたか否かを示すスタブ化フラグ３０５－１、スタブ化された場合のファイルの格納先を示す格納先ＵＲＬ（Uniform Resource Locator）３０６－１、スタブ化されていない場合のファイルのデータを構成するブロックデータのアドレスを示すブロックアドレス３０７－１、３０８－１をさらに含む。
　リコールは、アーカイバ１６０にアーカイブされたファイルを、ファイルストレージ１２０が取得してクライアント１１０へ送信する動作である。リコール禁止フラグ３０４－１の「ＯＦＦ」は、リコールが許可、すなわちクライアント１１０への送信が許可されていることを意味する。リコール禁止フラグ３０４－１の「ＯＮ」は、リコールが禁止、すなわちクライアント１１０への送信が許可されていないことを意味する。
　スタブ化フラグ３０５－１の「ＯＮ」は、ファイル・パス名３０２－１で識別されるファイルのデータが、ＨＤＤ１２３かブロックストレージ１４０のいずれかに格納されておらず、アーカイバ１６０にアーカイブされている状態を意味する。スタブ化フラグ３０５－１の「ＯＦＦ」は、ファイル・パス名３０２－１で識別されるファイルのデータが、ＨＤＤ１２３かブロックストレージ１４０のいずれかに格納されている状態を意味する。
　格納先ＵＲＬ３０６－１は、スタブ化フラグ３０５－１の「ＯＮ」に対して、コア１０２あるいはアーカイバ１６０を識別し、アーカイバ１６０のアーカイブされたファイルを識別するＵＲＬである。また、スタブ化フラグ３０５－１の「ＯＦＦ」に対して、格納先ＵＲＬ３０６－１は、「ＮＵＬＬ」であってもよいし、あるいは参照されることがないため無意味な情報であってもよい。
　ブロックアドレス３０７－１、３０８－１は、スタブ化フラグ３０５－１の「ＯＦＦ」に対し、ＨＤＤ１２３あるいはブロックストレージ１４０における、ファイルのデータが分割されたブロックデータの格納されるアドレスそれぞれである。また、スタブ化フラグ３０５－１の「ＯＮ」に対し、ブロックアドレス３０７、３０８は、「ＮＵＬＬ」であってもよいし、あるいは参照されることがないため無意味な情報であってもよい。
　図３では、２つのブロックデータに対する２つのブロックアドレスの例を示すが、１つでもよく、３つ以上であってもよい。このためにinodeは、１つのファイルのデータを構成するブロックデータの個数の情報を有してもよく、最後のブロックデータの次のブロックアドレスが「ＮＵＬＬ」となって、終端が表されてもよい。さらにエッジＡ１０１－１のinodeは、一般的なinodeの情報を含んでもよい。
　エッジＢ１０１－２のinodeのinode番号３０１－１、ファイル・パス名３０２－２、最終更新日時３０３－２、リコール禁止フラグ３０４－２、スタブ化フラグ３０５－２、格納先ＵＲＬ３０６－２、ブロックアドレス３０７－２、２０８－２のそれぞれは、エッジＡ１０１－１のinodeの同じ名称の情報と同じ意味である。エッジＡ１０１－１のファイルストレージ１２０とエッジＢ１０１－２のファイルストレージとは物理的に別のストレージであるので、inodeも別に格納されるため、別の符号を付してある。
　コア１０２のinodeは、アーカイバ１６０のファイルシステム１６８がＣＰＵ１６１により実行されて使用される情報であり、ＨＤＤ１６３あるいはブロックストレージ１７０に格納される。コア１０２のinodeは、inodeを識別するためのinode番号３１１、inodeの対象ファイルを識別するためのファイル・パス名３１２、inodeあるいはファイル・パス名３１２で識別されるファイルの最終更新日時３１３を含む。
　また、コア１０２のinodeは、アーカイブされたファイルのデータを構成するブロックデータのアドレスを示すブロックアドレス３１４、３１５、ウイルスに感染していないバージョンのファイルへのリンク情報である内部リンク３１６、１つ前のバージョンのファイルへのリンク情報である旧バージョンリンク３１７をさらに含む。
　ブロックアドレス３１４、３１５は、ＨＤＤ１６３あるいはブロックストレージ１７０における、ファイルのデータが分割されたブロックデータの格納されるアドレスそれぞれである。図３では、２つのブロックデータに対する２つのブロックアドレスの例を示すが、１つでもよく、３つ以上であってもよい。内部リンク３１６と旧バージョンリンク３１７に関しては、図４を用いて説明する。
　図３は、エッジＡ１０１－１とエッジＢ１０１－２の両方でファイル「/dir1/a.txt」がスタブ化された状態のinodeの例であり、格納先ＵＲＬ３０６－１と格納先ＵＲＬ３０６－２の両方が「http://hcp/dir2/a.txt」であって、inode番号３１１が「２０」のinodeが指し示される例である。このため、エッジＡ１０１－１のファイル・パス名３０２－１が「/dir1/a.txt」のファイルのデータは、コア１０２におけるファイル・パス名３１２が「/dir2/a.txt」として、ブロックアドレス３１４の「0000010」とブロックアドレス３１５の「0000020」に格納されていることになる。
　図４は、コア１０２のinodeのリンクの例を示す図である。図３と同じ種類の情報には同じ符号を付し、図を見やすくするために、４つのinodeに含まれる情報の位置関係を点線で対応させている。この位置関係は、inodeの格納されたアドレスを表すものではなく、説明のためのものである。エッジＡ１０１－１においてファイルが更新、すなわち既存のファイルにデータがライトされると、そのライトされた後のファイルがスタブ化されたコア１０２におけるファイルに対し、ライトされる前のファイルも保持される。
　図４に示したinode番号３１１が「２０」のinodeは、図３に示したコア１０２のinodeであり、図４の例では、エッジＡ１０１－１のファイル・パス名３０２－１が「/dir1/a.txt」の更新されたファイルが３回スタブ化されている。旧バージョンリンク３１７は、スタブ化された１つ前のバージョンのファイルへのリンク情報であり、ファイル・パス名３１２が「/dir2/a.txt」のinodeでは、ファイル・パス名３１２が「dir3/a.txt」のinodeへリンクする。
　そして、旧バージョンリンク３１７は、ファイル・パス名３１２が「/dir3/a.txt」のinodeでは、ファイル・パス名３１２が「dir4/a.txt」のinodeへリンクし、ファイル・パス名３１２が「/dir4/a.txt」のinodeでは、ファイル・パス名３１２が「dir5/a.txt」のinodeへリンクする。なお、旧バージョンリンク３１７の情報は、ファイル・パス名３１２の情報に対応する情報である必要はなく、例えばinode番号３１１の情報やinodeの格納されるアドレスであってもよい。
　内部リンク３１６は、ファイル名が同じ「a.txt」である複数のファイルの中で、ウイルスの感染が検出されなかったファイルのデータをブロックアドレス３１４、３１５とするinodeへのリンクである。図４では、ブロックアドレス３１４が「0000070」とブロックアドレス３１５が「0000080」に格納されたデータにウイルスの感染が検出されなかった例であり、内部リンク３１６は「/dir5/a.txt」である。なお、内部リンク３１６の情報も、ファイル・パス名３１２の情報に対応する情報である必要はない。
　ウイルスの感染が検出されなかったデータのファイルが複数存在する場合、内部リンク３１６は、旧バージョンリンク３１７が最も少ないリンク数で至るinodeへのリンクであってもよい。そして、旧バージョンリンク３１７が最も少ないリンク数で至るinodeのブロックアドレス３１４、３１５のデータにウイルスの感染が検出された場合、旧バージョンリンク３１７が次に少ないリンク数で至るinodeへのリンクであってもよい。
　最初のスタブ化では、旧バージョンリンク３１７が「ＮＵＬＬ」であり、ブロックアドレス３１４、３１５のデータにウイルスの感染が検出されなかったinodeの内部リンクは「ＮＵＬＬ」であってもよい。Inode番号３１１が「５０」のinodeのように最初のスタブ化されたブロックアドレス３１４、３１５のデータにウイルスの感染が検出された場合、内部リンク３１６はその感染の検出を示す値であってもよい。
　図５は、スキャン結果の例を示す図である。スキャン結果の情報は、アーカイバ１６０のＣＰＵ１６１によりアーカイブ１６７が実行されて使用される情報であり、コア１０２のメモリ１６２、ＨＤＤ１６３、ブロックストレージ１７０のいずれかに格納される。スキャン結果は、inodeのファイル・パス名３１２に対応するファイル・パス名５１１、ファイルの改変などを判定するためのファイルのデータのハッシュ値５１２を含む。
　また、スキャン結果は、ウイルス感染の検出に使用されたスキャンエンジン１５６を識別するためのスキャンエンジン名５１３、スキャンエンジン１５６のウイルス定義を識別するウイルス定義ファイルバージョン５１４、スキャンエンジン１５６が実行された日時であるスキャン日時５１５、スキャンエンジン１５６の実行された結果である感染５１６をさらに含む。
　スキャンエンジン名５１３、ウイルス定義ファイルバージョン５１４、スキャン日時５１５、感染５１６の情報は、スキャンサーバ１５０のＣＰＵ１５１によりＮＩＣ１５４で送信され、ファイルストレージ１２０のＣＰＵ１２１によりＮＩＣ１２４とＮＩＣ１２５で転送され、アーカイバ１６０のＣＰＵ１６１によりＮＩＣ１６４で受信されて格納される。感染５１６の情報の格納については、図７、９を用いてさらに説明する。
　ファイル・パス名５１１の情報は、図３、４に示したコア１０２のinode生成時に格納されてもよく、ハッシュ値５１２の情報は、スタブ化のためにファイルストレージ１２０のＮＩＣ１２５からファイルのデータを受信する際に、一緒に受信されて格納されてもよいし、ファイルのデータを受信する際に、受信したファイルのデータを使用して、ＣＰＵ１６１により計算されて格納されてもよい。
　図６は、ファイルのリードでのリード要求の発生からスキャン結果の取得までのシーケンスの例を示す図である。まず、クライアント１１０のＣＰＵ１１１が、アプリケーション１１６を実行し、ＮＩＣ１１４を制御してリード要求をファイルストレージ１２０へ送信する（ステップ６０１）。ファイルストレージ１２０においてＮＩＣ１２４がリード要求を受信すると、ＣＰＵ１２１はファイル共有システム１２８を実行し、リード要求を解析する（ステップ６０２）。
　このリード要求の解析は、例えばＣＩＦＳのリード要求であるかの解析であり、少なくともリード要求の対象となるファイルであって、ファイル・パス名３０２－１に対応するファイルの情報を解析する。ＣＰＵ１２１はファイルシステム１２９を実行してinodeを検索し、解析された情報と一致するファイル・パス名３０２－１のinodeを発見し、発見されたinodeの他の情報を取得する（ステップ６０３）。
　ＣＰＵ１２１はリコール制御１３１を実行し、取得された情報の中のスタブ化フラグ３０５－１が「ＯＮ」であるかを判定する（ステップ６０４）。スタブ化フラグ３０５－１が「ＯＮ」ではない、すなわち「ＯＦＦ」であってスタブ化されていないと判定した場合、ＣＰＵ１２１はファイルシステム１２９を実行して、ブロックアドレス３０７－１、３０８－１に格納されたデータを、ＨＤＤ１２３あるいはブロックストレージ１４０からリードする。そして、ＣＰＵ１２１はファイル共有システム１２８を実行し、リードされたデータをファイルとしてＮＩＣ１２４でクライアント１１０へ送信する（ステップ６０５）。
　スタブ化フラグ３０５－１が「ＯＮ」である、すなわちスタブ化されていると判定した場合、ＣＰＵ１２１はリコール制御１３１を実行し、取得された情報の中のリコール禁止フラグ３０４－１が「ＯＮ」であるかを判定する（ステップ６０６）。リコール禁止フラグ３０４－１が「ＯＮ」である、すなわちリコール禁止であると判定した場合、ＣＰＵ１２１はリコール制御１３１を実行し、クライアント１１０からのリード要求への応答としてエラーの情報をクライアントへＮＩＣ１２４で送信する（ステップ６０７）。
　リコール禁止フラグ３０４－１が「ＯＮ」ではない、すなわち「ＯＦＦ」であってリコールが禁止されていないと判定した場合、ＣＰＵ１２１はリコール制御１３１を実行し、取得された情報の中の格納先ＵＲＬ３０６－１をスキャン対象として指定し、スキャン結果の要求をアーカイバ１６０へＮＩＣ１２５で送信し、アーカイバ１６０からの応答を受信する（ステップ６０８）。
　アーカイバ１６０のＮＩＣ１６４がネットワーク１０３を介してファイルストレージ１２０からスキャン結果の要求を受信すると、ＣＰＵ１６１はアーカイブ１６７を実行し、図５を用いて説明したスキャン結果を検索し、スキャン結果の要求でスキャン対象として指定された格納先ＵＲＬ３０６－１と一致するファイル・パス名５１１を発見する。
　そして、ＣＰＵ１６１はアーカイブ１６７を実行し、発見されたファイル・パス名５１１に対応する感染５１６を取得して、取得された感染５１６の「有」か「無」を応答としてファイルストレージ１２０へＮＩＣ１６４で送信する（ステップ６０９）。ファイルストレージ１２０のＣＰＵ１２１はリコール制御１３１を実行し、「有」か「無」の応答をアーカイバ１６０からＮＩＣ１２５で受信する。
　以上で説明したシーケンスにより、クライアント１１０からのリード要求に対して、リード要求の対象となるファイルがスタブ化されていなければ、そのファイルを応答し、スタブ化されていてリコールが禁止されていれば、エラーを応答し、スタブ化されていてリコールが禁止されていなければ、そのファイルのスキャン結果を取得できる。
　なお、図６は、クライアント１１０はステップ６０５のファイルを受信し、ステップ６０７のエラーを受信する図となっているが、クライアント１１０はそれぞれ受信することを表し、シーケンスとして両方を受信するものではない。このように受信あるいは送信する装置を表し、シーケンスを表さない関係を破線としている。また、図３に示したinodeは、ステップ６０８に到達する情報の例である。
　次に、取得したスキャン結果すなわち過去にスキャンした結果と、さらに新たにスキャンした結果に基づき、スタブ化されたファイルをクライアント１１０へ応答し、スキャン結果を更新するシーケンスを説明する。
　図７は、ファイルのリードでの、スキャン結果の判定から、スタブ化されたファイルの送信とスキャン結果の更新までのシーケンスの例を示す図である。図７に示したシーケンスの例は、図６に示したシーケンスの例の続きである。ファイルストレージ１２０のＣＰＵ１２１はリコール制御１３１を実行し、ステップ６０８で受信したスキャン結果が「有」であるかを判定する（ステップ６１０）。
　「有」である、すなわち感染していると判定した場合、ＣＰＵ１２１はファイルシステム１２９を実行し、inodeのリコール禁止フラグ３０４－１を「ＯＮ」に設定し（ステップ６１１）、クライアント１１０からのリード要求への応答としてエラーの情報をクライアントへＮＩＣ１２４で送信する（ステップ６１２）。
　「有」ではない、すなわち「無」であって感染していないと判定した場合、ＣＰＵ１２１はデータムーバ１３０を実行し、アーカイバ１６０へＮＩＣ１２５でリコールを要求する（ステップ６１３）。ＣＰＵ１２１は、リコールの要求でステップ６０８と同じ格納先ＵＲＬ３０６－１をリコール対象として指定する。
　アーカイバ１６０のＮＩＣ１６４がネットワーク１０３を介してファイルストレージ１２０からリコールの要求を受信すると、ＣＰＵ１６１はファイルシステム１６８を実行し、リコール対象として指定されたファイルのデータを取得する。すなわち、ＣＰＵ１６１は図３、４を用いて説明したコア１０２のinodeを検索し、リコール対象として指定された格納先ＵＲＬ３０６－１と一致するファイル・パス名３１２を発見する。
　そして、ＣＰＵ１６１は、発見されたファイル・パス名３１２のinodeの内部リンク３１６にリンクが設定されているかを判定し、リンクが設定されていない、すなわち例えば「ＮＵＬＬ」が設定されていると判定した場合、リンクが設定されていないinodeのブロックアドレス３１４、３１５に格納されたデータを取得し、取得されたファイルのデータを応答としてファイルストレージ１２０へＮＩＣ１６４で送信する（ステップ６１４）。
　リンクが設定されていると判定した場合、ＣＰＵ１６１は、内部リンク３１６のリンク先のinodeのブロックアドレス３１４、３１５に格納されたデータを取得し、取得されたファイルのデータを応答としてファイルストレージ１２０へＮＩＣ１６４で送信する。図４に示した例では、内部リンク３１６が「/dir5/a.txt」であるため、ファイル・パス名３１２が「/dir5/a.txt」かつinode番号３１１が「５０」のinodeのブロックアドレス３１４、３１５である「0000070」と「0000080」に格納されたデータが送信される。
　ステップ６１４において、ＣＰＵ１６１によるファイルシステム１６８の実行を説明したが、アーカイブとしての何らかのファイル管理のために、ＣＰＵ１６１はアーカイブ１６７をさらに実行してもよい。
　ファイルストレージ１２０のＮＩＣ１２５がネットワーク１０３を介してアーカイバ１６０からファイルのデータを受信すると、ＣＰＵ１２１はデータムーバ１３０を実行し、受信されたファイルのデータとスキャンの要求をスキャンサーバ１５０へＮＩＣ１２４で送信する（ステップ６１５）。ここで、アーカイバ１６０から受信されたファイルのデータは、メモリ１２２あるいはＨＤＤ１２３に格納されてもよい。
　スキャンサーバ１５０のＮＩＣ１５４がファイルストレージ１２０からファイルのデータを受信すると、ＣＰＵ１５１はスキャンエンジン１５６を実行し、受信されたファイルのデータをスキャンしてウイルスの感染の有無を検出する。そして、ＣＰＵ１５１は検出された結果を応答としてファイルストレージ１２０へＮＩＣ１５４で送信する（ステップ６１６）。送信される結果は、図５を用いて説明したスキャン結果の各情報を含んでもよい。
　ファイルストレージ１２０のＮＩＣ１２４がスキャンサーバ１５０から結果を受信すると、ＣＰＵ１２１はリコール制御１３１を実行し、受信された結果に含まれるウイルスの感染の情報が「無」であるかを判定する。「無」である、すなわち感染していないと判定した場合、ＣＰＵ１２１はファイル共有システム１２８を実行し、ステップ６１３で受信されたファイルのデータをＮＩＣ１２４でクライアント１１０へ送信し（ステップ６２１）、スタブ化フラグ３０５－１を「ＯＦＦ」に設定する（ステップ６２２）。
　「無」ではない、すなわち「有」であり感染していると判定した場合、ＣＰＵ１２１はファイルシステム１２９を実行し、inodeのリコール禁止フラグ３０４－１を「ＯＮ」に設定する（ステップ６１７）。そして、ＣＰＵ１２１はリコール制御１３１を実行し、クライアント１１０からのリード要求への応答としてエラーの情報をクライアントへＮＩＣ１２４で送信する（ステップ６１８）。なお、ステップ６１８において、ＣＰＵ１２１はウイルスの感染をシステムの管理者へメールなどにより通知してもよい。
　ＣＰＵ１２１はリコール制御１３１を実行し、ステップ６１３で受信された結果をＮＩＣ１２５でアーカイバ１６０へ送信する（ステップ６１９）。アーカイバ１６０のＮＩＣ１６４が結果を受信すると、ＣＰＵ１６１はアーカイブ１６７を実行し、図５を用いて説明したスキャン結果へ、受信された結果を格納する（ステップ６２０）。
　このスキャン結果の格納において、受信された結果と同一の情報がスキャン結果のファイル・パス名５１１とハッシュ値５１２へ既に格納されていた場合、既に格納されているスキャンエンジン名５１３から感染５１６までの情報は、受信された結果の情報で上書きされてもよい。
　以上で説明したシーケンスにより、過去のスキャンした結果に加えて新たにスキャンした結果に基づき、スタブ化されたファイルはクライアント１１０へ応答される。これにより、スキャンエンジン１５６のウイルス定義ファイルバージョンが新しくなって、新たなウイルスの感染を検出できるようになった場合、その新たな検出の結果も利用できる。
　また、新たな検出の結果は、コア１０２のアーカイバ１６０にスキャン結果として格納されるため、新たな検出を行ったエッジ以外のエッジのファイルストレージのリコールにおいても、そのスキャン結果を利用できる。
　さらに、新たな検出を行ったエッジのファイルストレージは、リコール禁止フラグによりリコールを禁止するため、アーカイバ１６０へスキャン結果を要求することがなく、新たな検出を行ったエッジ以外のエッジのファイルストレージにおいても、スキャン結果を一度取得してリコール禁止フラグによりリコールを禁止するため、アーカイバ１６０へのスキャン結果の要求を繰り返すことがない。
　図８は、ファイルストレージ１２０からアーカイバ１６０へファイルをスタブ化するシーケンスの例を示す図である。ファイルストレージ１２０のＣＰＵ１２１は、予め設定された時間間隔で定期的に、データムーバ１３０を実行し、予め設定されたスタブ化条件を取得する（ステップ７０１）。
　スタブ化条件には、例えばＨＤＤ１２３あるいはブロックストレージ１４０に格納されるデータの総容量であって、ファイルシステム１２９が実行されて管理されるファイルの総容量に対する閾値、およびファイルの更新日時に対する基準日時が含まれる。基準日時は、予め設定された時間間隔での定期的な実行における前回の実行の日時であってもよい。また、スタブ化条件は、これら以外の条件が含まれてもよい。
　ＣＰＵ１２１はファイルシステム１２９を実行し、ファイルの総容量を取得し、取得された総容量が、スタブ化条件の閾値より大きいかを判定する。ファイルの総容量の取得は、例えばファイルシステム１２９が実行されて管理される複数のファイルそれぞれのデータの容量の合計が算出されてもよい。取得された総容量が、スタブ化条件の閾値より大きくないと判定した場合、スタブ化のシーケンスを終了する。
　取得された総容量が、スタブ化条件の閾値より大きいと判定した場合、ＣＰＵ１２１はデータムーバ１３０を実行してファイルの１つを選択し、ＣＰＵ１２１はファイルシステム１２９を実行して選択されたファイルのinodeの情報を取得する（ステップ７０３）。ここで、取得されるinodeの情報は、最終更新日時３０３－１とブロックアドレス３０７－１、３０８－１を含む。
　ＣＰＵ１２１はデータムーバ１３０を実行し、スタブ化条件に含まれる基準日時と最終更新日時３０３－１とを比較し、最終更新日時３０３－１の方が後の日時であるかを判定する（ステップ７０４）。最終更新日時３０３－１の方が後の日時ではないと判定した場合、ＣＰＵ１２１はステップ７０８へ進む。
　最終更新日時３０３－１の方が後の日時である、すなわち更新ありと判定した場合、ＣＰＵ１２１はデータムーバ１３０を実行し、ファイル・パス名３０２－１とブロックアドレス３０７－１、３０８－１に格納されているデータを、スタブ化されるファイルとしてアーカイバ１６０へＮＩＣ１２５で送信し、アーカイバ１６０から応答を受信する（ステップ７０５）。
　アーカイバ１６０のＮＩＣ１６４がネットワーク１０３を介してスタブ化されるファイルのデータを受信すると、ＣＰＵ１６１はアーカイブ１６７とファイルシステム１６８を実行し、図３、４を用いて説明したコア１０２のinodeを生成して、受信されたデータを格納するとともに格納されたデータのアドレスをブロックアドレス３１４、３１５に設定し、生成されたinodeのファイル・パス名３１２と、ステップ７０５で送信されたファイル・パス名３０２－１をＮＩＣ１６４でファイルストレージ１２０へ送信する（ステップ７０６）。この送信はブロードキャストあるいはマルチキャストであってもよい。
　ファイルストレージ１２０のＮＩＣ１２５がネットワーク１０３を介してファイル・パス名３１２とファイル・パス名３０２－１を受信すると、ＣＰＵ１２１はファイルシステム１２９を実行し、受信されたファイル・パス名３０２－１に基づき、inodeの格納先ＵＲＬ３０６－１へ受信されたファイル・パス名３１２を設定し、スタブ化フラグ３０５－１に「ＯＮ」を設定して、inodeを更新する（ステップ７０７）。ここで、エッジＢ１０１－２のファイルストレージも同じ動作をしてよい。
　ＣＰＵ１２１はデータムーバ１３０を実行し、スタブ化を終了するか判定し（ステップ７０８）、スタブ化を終了すると判定した場合はスタブ化のシーケンスを終了し、スタブ化を終了しないと判定した場合はステップ７０３へ戻って、他のファイルを１つ選択する。スタブ化の終了の判定は、例えば、スタブ化により減少した総容量がスタブ化条件の閾値より大きくないとの判定であってもよいし、予め設定された日時が経過したかの判定であってもよいし、予め設定された範囲のファイルを選択し終えたかの判定であってもよい。
　図８を用いて説明したシーケンスにより、ファイルをスタブ化し、スタブ化に関する情報をinodeに設定できる。
　図９は、アーカイブされたファイルを、ウイルスの感染が検出されていないファイルへ回復し、スキャン結果とリコール禁止フラグを更新するシーケンスの例を示す図である。図４を用いて説明したように、ファイルのデータが更新されても、コア１０２のinodeは各更新の情報を保持する。このため、ウイルスの感染が検出されていないファイルが存在すれば、そのファイルへ回復することができる。
　アーカイバ１６０のＣＰＵ１６１は、予め設定された時間間隔で定期的に、アーカイブ１６７を実行し、図５を用いて説明したスキャン結果を取得して（ステップ８０１）、取得されたスキャン結果の感染５１６が「有」のファイルを選択する（ステップ８０２）。ＣＰＵ１６１はファイルシステム１６８を実行し、選択されたファイルのファイル・パス名５１１と一致するファイル・パス名３１２のinodeを取得する（ステップ８０３）。
　そして、ＣＰＵ１６１はファイルシステム１６８を実行し、取得されたinodeの旧バージョンリンクをたどり、内部リンク３１６が「ＮＵＬＬ」のinodeへ到達すると、その到達されたinodeのファイル・パス名３１２に、取得されたinodeの内部リンク３１６を変更する。図４は、例えば取得されたinodeのファイル・パス名３１２が「/dir2/a.txt」であり、旧バージョンリンク３１７の「/dir3/a.txt」、「/dir4/a.txt」、「/dir5/a.txt」とたとり、内部リンク３１６が「ＮＵＬＬ」であるから、「/dir5/a.txt」に内部リンク３１６が変更される例である。
　ＣＰＵ１６１はアーカイブ１６７を実行し、内部リンク３１６の変更をシステムの管理者へメールなどで通知し（ステップ８０６）、図５を用いて説明したスキャン結果の感染５１６を「無」に更新し（ステップ８０７）、取得されたinodeのファイル・パス名３１２を指定してリコール禁止フラグの変更要求をＮＩＣ１６４でファイルストレージ１２０へ送信する（ステップ８０８）。この送信はブロードキャストあるいはマルチキャストであってもよい。
　ファイルストレージ１２０のＮＩＣ１２５がネットワーク１０３を介してリコール禁止フラグの変更要求を受信すると、ＣＰＵ１２１はファイルシステム１２９を実行し、指定されたファイル・パス名３１２と一致するファイル・パス名３０２－１のinodeのリコール禁止フラグ３０４－１を「ＯＦＦ」に変更する。ここで、エッジＢ１０１－２のファイルストレージも同じ動作をしてよい。
　図９を用いて説明したシーケンスにより、アーカイブされたファイルであって、ウイルスの感染が検出されたファイルであっても、ウイルスの感染が検出されなかったファイルへ回復することができる。
　以上で説明したように、複数のエッジのいずれかで検出されたウイルス感染の情報は、コアのスキャン結果とすることができる。そして、コアのスキャン結果により各エッジのリコールは禁止されるため、１つのエッジでの検出した結果を他のエッジでも利用できる。さらに、ウイルスの検出されなかったファイルへ回復することができ、コアにおいてファイルが回復されると、その回復に基づいて各エッジはリコールを禁止せず、アーカイブされたファイルが利用可能となる。
　１１０　クライアント
　１２０　ファイルストレージ
　１２８　ファイル共有システム
　１２９　ファイルシステム
　１３０　データムーバ
　１３１　リコール制御
　１４０　ブロックストレージ
　１５０　スキャンサーバ
　１６０　アーカイバ
　１６７　アーカイブ
　１６８　ファイルシステム
　１７０　ブロックストレージ

Claims (13)

  1. 　それぞれがファイルを記憶する複数のファイルストレージと、ファイルをアーカイブするアーカイバとが接続されたストレージシステムであって、
    　複数の前記ファイルストレージのそれぞれは、
    　前記ファイルストレージが記憶したファイルを前記アーカイバへ送信して、送信されたファイルの管理情報を保持し、
    　ファイルのリードにおいて、前記管理情報に基づきファイルが前記アーカイバへ送信されたことを判定し、前記管理情報に基づきファイルの前記アーカイバからの受信が禁止されていないことを判定し、ファイルに対する第１のスキャン結果を前記アーカイバへ要求して取得し、取得された第１のスキャン結果に基づきファイルを前記アーカイバへ要求して取得し、取得されたファイルに対する第２のスキャン結果を取得し、取得された第２のスキャン結果を前記アーカイバへ送信し、
    　前記アーカイバは、
    　前記ファイルストレージからファイルを受信してアーカイブし、
    　前記ファイルストレージからの第１のスキャン結果の要求に対して、記録された第１のスキャン結果を応答し、
    　前記ファイルストレージからのファイルの要求に対して、アーカイブされたファイルを応答し、
    　前記ファイルストレージからの第２のスキャン結果を第１のスキャン結果として記録すること
    を特徴とするストレージシステム。
  2. 　請求項１に記載のストレージシステムであって、
    　複数の前記ファイルストレージのそれぞれは、
    　取得された第１のスキャン結果が第１の情報を含むと判定すると、ファイルの前記アーカイバからの受信を禁止する情報を前記管理情報に記録し、
    　取得された第１のスキャン結果が第２の情報を含むと判定すると、ファイルを前記アーカイバへ要求して取得すること
    を特徴とするストレージシステム。
  3. 　請求項２に記載のストレージシステムであって、
    　前記ストレージシステムは、さらに複数の前記ファイルストレージそれぞれに、スキャンサーバがそれぞれ接続され、
    　複数の前記ファイルストレージのそれぞれは、
    　取得されたファイルを、接続された前記スキャンサーバへ送信してスキャンを要求し、接続された前記スキャンサーバから第２のスキャン結果を受信して取得し、
    　前記スキャンサーバのそれぞれは、
    　接続された前記ファイルストレージからファイルを受信してスキャンを要求されると、受信されたファイルをスキャンして第２のスキャン結果を取得し、接続された前記ファイルストレージへ第２のスキャン結果を送信すること
    を特徴とするストレージシステム。
  4. 　請求項３に記載のストレージシステムであって、
    　複数の前記ファイルストレージのそれぞれは、
    　取得された第２のスキャン結果が第１の情報を含むと判定すると、ファイルの前記アーカイバからの受信を禁止する情報を前記管理情報に記録し、取得された第２のスキャン結果を第１の情報を含めて前記アーカイバへ送信し、
    　取得された第２のスキャン結果が第２の情報を含むと判定すると、取得された第２のスキャン結果を第２の情報を含めて前記アーカイバへ送信すること
    を特徴とするストレージシステム。
  5. 　請求項４に記載のストレージシステムであって、
    　前記ストレージシステムは、さらに複数の前記ファイルストレージそれぞれに、クライアントがそれぞれ接続され、
    　前記クライアントのそれぞれは、
    　接続された前記ファイルストレージへファイルのリードを要求し、
    　複数の前記ファイルストレージのそれぞれは、
    　接続された前記クライアントからの要求に応じるファイルのリードにおいて、
    　前記管理情報に基づきファイルが前記アーカイバへ送信されていないと判定すると、前記ファイルストレージに記憶されたファイルを前記クライアントへ送信し、
    　取得された第２のスキャン結果が第２の情報を含むと判定すると、前記アーカイバから取得されたファイルを前記クライアントへ送信すること
    を特徴とするストレージシステム。
  6. 　請求項５に記載のストレージシステムであって、
    　前記スキャンサーバのそれぞれは、
    　受信されたファイルがウイルスに感染しているかを検出するスキャンをして、
    　ウイルスに感染しているという第１の情報を含む第２のスキャン結果、あるいはウイルスに感染していないという第２の情報を含む第２のスキャン結果を取得すること
    を特徴とするストレージシステム。
  7. 　請求項６に記載のストレージシステムであって、
    　ファイルの前記管理情報は、inodeであること
    を特徴とするストレージシステム。
  8. 　請求項７に記載のストレージシステムであって、
    　複数の前記ファイルストレージのそれぞれは、
    　前記ファイルストレージに記憶された複数のファイルの容量の合計値が、予め設定された閾値より大きいことを判定し、
    　前記管理情報に基づきファイルが更新されたことを判定し、
    　記憶されたファイルを前記アーカイバへ送信し、
    　前記管理情報にファイルの送信されたことを記録すること
    を特徴とするストレージシステム。
  9. 　請求項８に記載のストレージシステムであって、
    　前記アーカイバは、
    　受信されたファイルのノード情報を生成して、ファイルをアーカイブし、
    　アーカイブされたファイルのノード情報の格納先を前記ファイルストレージへ送信し、
    　複数の前記ファイルストレージのそれぞれは、
    　前記アーカイバから受信したノード情報の格納先を前記管理情報に記録し、
    　前記管理情報に記録されたノード情報の格納先を指定して、ファイルを前記アーカイバへ要求し、
    　前記管理情報に記録されたノード情報の格納先を指定して、記憶されたファイルを前記アーカイバへ送信すること
    を特徴とするストレージシステム。
  10. 　請求項９に記載のストレージシステムであって、
    　前記アーカイバは、
    　前記ファイルストレージの記憶されたファイルの送信で指定されたノード情報の格納先を、生成されたノード情報へ旧バージョンリンクとして記録し、送信されたファイルのアーカイブされたアドレスを、生成されたノード情報へ記録すること
    を特徴とするストレージシステム。
  11. 　請求項１０に記載のストレージシステムであって、
    　前記アーカイバは、
    　記録された第１のスキャン結果に含まれる第１の情報に応じて第１のノード情報の旧バージョンリンクをたどり、
    　たどられた先の第２のノード情報の格納先を第１のノード情報へ内部リンクとして記録し、
    　記録された第１のスキャン結果に含まれる第１の情報を第２の情報へ更新し、
    　前記管理情報に記録された、ファイルの前記アーカイバからの受信を禁止する情報の変更を、複数の前記ファイルストレージへ要求すること
    を特徴とするストレージシステム。
  12. 　請求項１１に記載のストレージシステムであって、
    　前記アーカイバは、
    　第１のノード情報の旧バージョンリンクをたどり、たどられた先の第３のノード情報の内部リンクに格納先が記録されていると、第３のノード情報の旧バージョンリンクをたどり、たどられた先の第４のノード情報の内部リンクに格納先が記録されていないと、第４のノード情報と第２のノード情報として、第２のノード情報の格納先を第１のノード情報へ内部リンクとして記録すること
    を特徴とするストレージシステム。
  13. 　請求項１２に記載のストレージシステムであって、
    　前記アーカイバは、
    　前記管理情報に記録されたノード情報の格納先が指定されて、前記ファイルストレージからファイルを要求され、
    　指定された格納先のノード情報の内部リンクに格納先が記録されていないと判定すると、指定された格納先のノード情報のアドレスにしたがってファイルを応答し、
    　指定された格納先のノード情報の内部リンクに格納先が記録されていると判定すると、指定された格納先のノード情報の内部リンクをたどり、たどられた先のノード情報のアドレスにしたがってファイルを応答すること
    を特徴とするストレージシステム。
PCT/JP2016/060498 2016-03-30 2016-03-30 ストレージシステム WO2017168653A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/060498 WO2017168653A1 (ja) 2016-03-30 2016-03-30 ストレージシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/060498 WO2017168653A1 (ja) 2016-03-30 2016-03-30 ストレージシステム

Publications (1)

Publication Number Publication Date
WO2017168653A1 true WO2017168653A1 (ja) 2017-10-05

Family

ID=59963712

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/060498 WO2017168653A1 (ja) 2016-03-30 2016-03-30 ストレージシステム

Country Status (1)

Country Link
WO (1) WO2017168653A1 (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 (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003509784A (ja) * 1999-09-13 2003-03-11 ドキュタッチ 文書管理システム
JP2004199213A (ja) * 2002-12-17 2004-07-15 Hitachi Ltd 情報処理システム
US20080195676A1 (en) * 2007-02-14 2008-08-14 Microsoft Corporation Scanning of backup data for malicious software
US8813222B1 (en) * 2009-01-21 2014-08-19 Bitdefender IPR Management Ltd. Collaborative malware scanning

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003509784A (ja) * 1999-09-13 2003-03-11 ドキュタッチ 文書管理システム
JP2004199213A (ja) * 2002-12-17 2004-07-15 Hitachi Ltd 情報処理システム
US20080195676A1 (en) * 2007-02-14 2008-08-14 Microsoft Corporation Scanning of backup data for malicious software
US8813222B1 (en) * 2009-01-21 2014-08-19 Bitdefender IPR Management Ltd. Collaborative malware scanning

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
CN110603524B (zh) 用于编排的工作负载的依赖性分析的方法和系统
US9830231B2 (en) Processes and methods for client-side fingerprint caching to improve deduplication system backup performance
EP3989092A1 (en) Malicious activity detection and remediation in virtualized file servers
US20190108231A1 (en) Application Aware Snapshots
JP6521462B2 (ja) バックアップシステムの性能の改善
US8584244B2 (en) Computer system and method for scanning computer virus
US20090319736A1 (en) Method and apparatus for integrated nas and cas data backup
US20150113010A1 (en) Distributed file system gateway
US9792436B1 (en) Techniques for remediating an infected file
JP2005182683A (ja) データ転送方法及びシステム並びにプログラム
US20220342866A1 (en) File analytics systems and methods including receiving and processing file system event data in order
US20220318099A1 (en) File analytics systems and methods including retrieving metadata from file system snapshots
WO2014054065A1 (en) Backup and restore system for a deduplicated file system and corresponding server and method
US9817834B1 (en) Techniques for performing an incremental backup
US20220318204A1 (en) File analytics systems and methods
WO2017168653A1 (ja) ストレージシステム
US20230289443A1 (en) Malicious activity detection, validation, and remediation in virtualized file servers
US20220318208A1 (en) Virtualized file servers and methods to persistently store file system event data
US20220318203A1 (en) File analytics systems including examples providing metrics adjusted for application operation
US9436697B1 (en) Techniques for managing deduplication of data
US8997124B2 (en) Method for updating data in a distributed data storage system
US9858418B2 (en) Reducing delays associated with restoring quarantined files
JP2013161383A (ja) 情報処理装置、情報処理方法、プログラム及び情報処理システム
CA3025225A1 (en) Application aware snapshots
JP4818396B2 (ja) オーバーレイネットワークシステム及び同システムにおけるオブジェクト登録方法

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 16896872

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 16896872

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP