WO2011121746A1 - ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム - Google Patents

ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム Download PDF

Info

Publication number
WO2011121746A1
WO2011121746A1 PCT/JP2010/055795 JP2010055795W WO2011121746A1 WO 2011121746 A1 WO2011121746 A1 WO 2011121746A1 JP 2010055795 W JP2010055795 W JP 2010055795W WO 2011121746 A1 WO2011121746 A1 WO 2011121746A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
online storage
metadata
divided
update
Prior art date
Application number
PCT/JP2010/055795
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 EP10847629.2A priority Critical patent/EP2555118B1/en
Priority to JP2011532450A priority patent/JP5400889B2/ja
Priority to PCT/JP2010/055795 priority patent/WO2011121746A1/ja
Priority to US13/257,708 priority patent/US8595440B2/en
Publication of WO2011121746A1 publication Critical patent/WO2011121746A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0611—Improving I/O performance in relation to response time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656—Data buffering arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/46—Caching storage objects of specific type in disk cache
    • G06F2212/463—File
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Definitions

  • the present invention relates to a file server device, a storage system management method, and a program, for example, a technique for acquiring a file stored in an external storage service and providing it to a user terminal.
  • STaaS Storage as a service
  • STaaS is a service that provides logical storage capacity at a low price.
  • external interfaces for using storage services are provided in the form of Web interfaces such as REST and SOAP.
  • Patent Document 1 discloses an existing technique that transparently appears to a single server from a client and hides data copy / movement.
  • Patent Document 2 discloses an existing technique related to data copying / moving.
  • an intermediate device is provided between a first server having primary storage, a second server having secondary storage, and a client.
  • a file is accessed from the client to the primary storage
  • the file to be accessed is a stub file (a file linked to the access destination)
  • the access request is changed to the corresponding file on the secondary storage.
  • the stub file is displayed as if it were an entity, and the data movement from the primary storage to the secondary storage is hidden from the client.
  • Patent Document 2 the update of the high-speed disk volume is monitored to create an update bitmap, the OR of each update bitmap is calculated to detect a segment that has not been updated for a predetermined time, and the detected segment information is Originally, data movement (movement between storage tiers) is performed from a high-speed disk volume to a low-speed disk volume.
  • Patent Document 1 and Patent Document 2 the online storage service is used as a backup external storage for file servers or an external storage for capacity expansion while avoiding the restrictions (1 and 2) of the online storage service described above. It is not possible. None of them proposes a measure for avoiding restrictions on the file size on the online storage, nor a measure for optimizing the communication cost via the WAN.
  • the present invention has been made in view of such a situation, and provides a technique for optimizing the communication cost when using an online storage service and realizing high-speed access.
  • a block file group obtained by dividing file data and meta information are stored, and a file read request from a user terminal is stored. Download and cache the block file necessary for reading from the online storage service.
  • the block file to be written is downloaded from the online storage service and cached, and the cached write data is overwritten.
  • the cached and changed block file and meta information are asynchronously reflected on the online storage service.
  • the online storage mount module refers to the meta information update flag, the file update flag, and the deletion flag recorded in the meta information, and deletes the original file in the online storage service, the file contents, and the meta information to the file server.
  • the processing is sequentially performed according to the policy information without being synchronized (asynchronously) with the above processing.
  • the online storage mount module when processing a write request from the user terminal, the online storage mount module reflects the updated block file identification information in the bitmap information recorded in the meta information, and uses the bitmap information. Only block files that need to be uploaded to the online storage service are updated asynchronously according to the policy information.
  • FIG. 10 is a diagram illustrating a GUI when a new / edit button is pressed in a setting GUI. It is a flowchart for demonstrating the process of the online storage mount module at the time of file opening. It is a flowchart for demonstrating the process of the online storage mount module at the time of READ. It is a flowchart for demonstrating the process of the online storage mount module at the time of WRITE.
  • the present invention relates to a method for eliminating the upper limit restriction on the file size stored in the external storage service and reducing the communication cost, for example.
  • each file on the online storage service is divided and managed, and only the necessary part is downloaded / uploaded according to the READ / WRITE operation of the file, thereby eliminating the file size restriction of the online storage service, and the communication cost.
  • We propose a mechanism to optimize In addition, the divided file blocks are cached locally to speed up file access, and the meta information of the files on the online storage service is also stored on the file server, so that meta data such as file listing and file name / directory structure can be stored. Provides a mechanism to realize high-speed information change and READ / WRITE.
  • FIG. 1 is a diagram showing a schematic configuration of a storage system according to an embodiment of the present invention.
  • the storage system includes a file server 106, at least one user terminal 101, a gateway server 103, and an external online storage service 105 installed in the company / organization 100.
  • the file server 106 and the gateway server 103 are connected by, for example, an intranet 102, and the gateway server 103 and the online storage service 105 are connected by a WAN 104.
  • the file access from the user terminal 101 connected to the file server 106 occurs.
  • the intranet 102 is connected to the WAN 104 via the gateway server 103, and the online storage service 105 is operating beyond that.
  • the online storage service 105 is a site that publishes and provides a storage service using a Web interface on the WAN. Examples of actual services include Amazon (registered trademark) S3 and Windows (registered trademark) Azure Storage. Is mentioned.
  • the file server 106 is a file server such as NAS (Network Attached Storage), and includes an NFS / CIFS service module 107, a management daemon 108, a file system 109, an online storage mount module 110, and a local cache 112. Including a secondary storage device 111.
  • the NFS / CIFS service module 107, the management daemon 108, the file system 109, and the online storage mount module 110 may be realized as modules, or may be configured by programs, and a processor in the file server 106 may be used for each program. Each function may be realized according to the above.
  • the local cache 112 is provided as a cache area in the secondary storage device 111, but is not limited to this form, and a cache memory is prepared separately from the secondary storage device 111. Also good.
  • the NFS / CIFS service module 107 is a basic module for receiving access from the user terminal 101 using the NFS or CIFS protocol and operating as a file server, and Samba is an example. If user authentication is required, the NFS / CIFS service module 107 processes authentication.
  • the online storage mount module 110 is a module that provides a function of mounting a logical drive on the online storage service in the file server 106.
  • the logical drive corresponds to a logical storage volume on the online storage service, and corresponds to a “bucket” in Amazon (registered trademark) S3, for example.
  • Amazon (registered trademark) S3 the OS of the file server is Linux
  • the online storage mount module 110 is a kernel module that mounts a bucket (for example, a FUSE-based file system module). This does not limit the invention.
  • the management daemon 108 is a module for setting which bucket the online storage mount module 110 mounts with which account in the file server, and a setting GUI (for example, see FIGS. 4 and 5). provide.
  • the administrator can manage the online storage mount module 110 using a setting GUI displayed on the display screen of an administrator terminal (not shown).
  • the local cache 112 is stored in the secondary storage device 111 in the file server 106.
  • the local cache 112 is a file generated and managed by the online storage mount module 110, and is a cache for speeding up access to files on the online storage service 105.
  • the outline of file access operation is as follows. For example, when an I / O request is issued for a certain file from the user terminal 101, the NFS / CIFS service module 107 provides the request to the file system 109. If the target file of the I / O request is a file stored in the secondary storage device 111, the file system 109 acquires the target file from the secondary storage device 111 and uses the NFS / CIFS service module 107 for the user. The file is provided to the terminal 101. On the other hand, when the target file is in the local cache 112 (when the file is associated with Amazon (registered trademark) S3 and cached), the file system 109 receives the target via the online storage mount module 110.
  • the file is acquired and provided to the user terminal 101 via the NFS / CIFS service module 107.
  • the target file (the file associated with Amazon (registered trademark) S3) does not exist in the local cache 112 (in the online storage service 105)
  • the online storage mount module 110 receives the target from the online storage service 105.
  • the file is acquired (mounted), stored in the local cache 112, and provided to the file system 109.
  • the file system 109 provides the file to the user terminal 101 via the NFS / CIFS service module 107.
  • FIG. 2 is a diagram showing the concept of file division management / division cache according to the embodiment of the present invention.
  • the file data 204 on the online storage service 105 is a set of divided block files (subfiles) constituting a single file, and includes meta information 200 and a divided block file group 203.
  • the meta information 200 is attribute information attached to each file, and includes information such as a file name and an update date (see FIG. 3 for details).
  • the divided block file group 203 is a set of block files obtained by dividing the file body at a fixed length size.
  • the local cache 112 in the file server has cache file data 202 corresponding to a set of cache files of a single file.
  • the cache file data 202 includes meta information 200 and a cache block file group 201.
  • the cache block file group 201 is a file downloaded by the online storage mount module 110 for high-speed processing in the divided block file group 203. In the situation where the file update process is not occurring, it becomes a subset of the divided block file group 203.
  • the corresponding update block is stored, and the online storage mount module 110 is included in the divided block file group 203 during the update process that is periodically executed (see FIGS. 10 and 11). Update the corresponding file by overwriting.
  • one directory is prepared for each cache file data 202 in the cache area in the file server 106, and the meta information 200 and the cache block file group 201 are included therein. Stored. On the online storage service 105, data is stored with the same configuration (one directory is prepared for each file).
  • FIG. 3 is a diagram illustrating a configuration example of a file attribute table stored in the meta information 200 in the present embodiment.
  • the meta information 200 includes, as configuration items, for example, an identification number 300, a file name 301, a parent node identification number 302, a meta information update flag 303, a file update flag 304, a deletion flag 305, and bitmap information 306. And an online storage size 307 and Stat information 308.
  • the identification number 300 is number information for uniquely identifying a file (corresponding to the file data 204), and is the only data that does not change even if meta information such as a file name or a file path changes.
  • the parent node identification number 302 stores the identification number of the file corresponding to the parent directory of the file when the directory structure is adopted.
  • the meta information update flag 303 and the file update flag 304 are flags that are set when the meta information and file data of each file are updated, and are referred to during periodic update processing.
  • the flag indicates whether or not it has been updated. For example, 1 or 0 is stored.
  • the deletion flag 305 is a flag that is set when a deletion process of the file (corresponding to the file data 204) occurs, and is also referred to during the update process.
  • Bitmap information 306 is data for recording a block in which update processing has occurred among block files cached locally, and is used during file update processing.
  • the online storage size 307 is an attribute that stores the data size of the original file when the data is downloaded from the online storage, and is used to delete an extra file during the update process.
  • stat information 308 stores file statistical information such as the file size, block size, and ACL of the file.
  • FIG. 4 is a diagram showing a setting / management GUI (Graphical User Interface) provided by the management daemon.
  • the GUI is displayed on the constant screen of the manager terminal when the manager requests the management daemon 108 from the manager terminal (not shown) to set and / or manage the online storage service.
  • the setting / management screen is composed of a list control and a button.
  • the list control includes a list of the set data of the bucket 400, the file path 401 on the file server 106 to be mounted in association with the bucket, and the account 402. it's shown.
  • the set data indicates the set of the Amazon (registered trademark) ⁇ S3 specified bucket name, the file path of the mount folder in the file server, and the Amazon (registered trademark) 3 S3 user account name used for mounting.
  • a usage fee is charged for the Amazon® S3 user account used for mounting.
  • a new button 403, an edit button 404, and a delete button 405 are arranged so that entry creation, editing, and deletion can be executed. Further, an OK button 406 is pressed to confirm the setting contents, and a cancel button 407 is pressed to cancel.
  • an Amazon (registered trademark) S3 contract and created in advance. Secret Access Key is encrypted and stored in the file server.
  • FIG. 5 is a diagram showing a GUI when the new / edit button is pressed in the setting / management GUI (FIG. 4).
  • An edit box for setting a bucket name, a file path, and an account is arranged, and an OK button 503 can be confirmed and a cancel button 504 can be canceled.
  • FIG. 6 is a flowchart for explaining processing executed by the online storage mount module 110 when a file is opened in the present embodiment. It can be said that this process is a process for securing resources necessary for using a file in response to a file open request.
  • the online storage mount module 110 receives a file open request (step 600), it determines whether or not the cache block file group of the file that is the object of the open request exists in the cache area in the file server 106. Check (step 601).
  • the online storage mount module 110 opens a folder for storing the cache block file group and returns its file identifier (Step 602).
  • step 601 if the corresponding cache area does not exist (No in step 601), a folder for storing the meta information and the cache block file group is generated, and the file identifier is returned.
  • FIG. 7 is a flowchart for explaining processing executed by the online storage mount module 110 when a READ request is made in the present embodiment.
  • the online storage mount module 110 calculates a necessary divided block to be accessed based on the offset information and size information of the file specified in the READ request (step 701). ).
  • the online storage mount module 110 determines whether or not all the divided block files necessary for file provision are stored in the local cache 112 (step 702).
  • the online storage mount module 110 reads a necessary area of data from the cached block file and generates a buffer to be returned by a READ request (Ste 703).
  • the online storage mount module 110 downloads the non-cached divided block file from the online storage service 105 and downloads the local cache 112. (Step 705), and a read buffer to be returned by a READ request is constructed in the same manner as when cached (step 703).
  • the online storage mount module 110 returns the configured read buffer to the host control (file system 109) and ends the processing (step 704).
  • FIG. 8 is a flowchart for explaining processing executed by the online storage mount module 110 when a WRITE request is made in the present embodiment.
  • the online storage mount module 110 When the online storage mount module 110 receives the WRITE request (step 800), it calculates a necessary divided block from the offset information and size information specified in the WRITE request (step 801).
  • the online storage mount module 110 determines whether or not all necessary divided block files covering the write area are stored in the local cache 112 (step 802).
  • the online storage mount module 110 downloads the file from the online storage service 105 and stores it in the local cache 112 (step 806).
  • step 802 If all the necessary block files are cached (Yes in step 802), or after all the necessary block files are cached by the processing in step 806, the online storage mount module 110 executes the cached block file. On the other hand, the write buffer in the WRITE request is overwritten to the required write area (step 803).
  • the online storage mount module 110 sets the corresponding bit in the bitmap information 306 to 1 corresponding to the updated block file, and updates the bitmap information 306 (step 804).
  • the online storage mount module 110 sets the file update flag 304 to ON and ends the processing (step 805).
  • FIG. 9 is a flowchart for explaining processing executed by the online storage mount module 110 during TRUNCATE in the present embodiment.
  • the TRUNCATE process is a file system process that performs a process of expanding and contracting the target file.
  • the online storage mount module 110 When the online storage mount module 110 receives the TRUNCATE request (step 900), it determines whether it is a file expansion request or a reduction request based on the specified size information (step 901).
  • the online storage mount module 110 extends the bitmap information data as much as necessary for the expanded size of the file (step 902), and updates the file size information. Perform (step 903).
  • the online storage mount module 110 reduces the bitmap information data to a size corresponding to the reduced size of the file (step 905), and updates the file size information. (Step 903).
  • the online storage mount module 110 sets the meta information update flag / file update flag to ON and ends the processing (step 904).
  • FIG. 10 is a flowchart for explaining the overall outline of the processing at the time of asynchronous update according to the present embodiment.
  • Asynchronous update processing is periodically executed by another thread, and the cycle can be set by a policy.
  • the online storage mount module 110 uses the asynchronous update thread to access the meta information of each file and check whether the deletion flag is ON (step 1000).
  • the online storage mount module 110 deletes the target file on the online storage corresponding to the identifier (Step 1005), and ends the process.
  • the online storage mount module 110 determines whether or not the file update flag is ON (Step 1001).
  • step 1001 If the file update flag is ON (Yes in step 1001), the online storage mount module 110 executes the file update process (see FIG. 11 for details) (step 1002), and if it is OFF, the file update process is skipped. Then, the process proceeds to the meta information update flag determination process (step 1003).
  • the online storage mount module 110 updates the meta information of the corresponding file on the online storage (step 1004), and if it is OFF (No in step 1003), what The process ends without doing anything.
  • FIG. 11 is a flowchart for explaining the details of the file update process (step 1002) during asynchronous update.
  • the online storage mount module 110 compares the current file size with the size of the original file on the online storage service 105 stored in the meta information attribute of the file (step 1100).
  • the online storage mount module 110 determines whether or not the current file size is reduced with respect to the original file (step 1101). If the file size is not reduced (No in step 1101), there is no extra file, and the process moves to step 1103.
  • Step 1102 If it is reduced (Yes in Step 1101), since an extra divided block file exists on the online storage service 105, the online storage mount module 110 first deletes these files from the online storage service 105. (Step 1102).
  • the online storage mount module 110 determines whether or not there is an updated block file (step 1103).
  • the online storage mount module 110 ends the file update process.
  • the online storage mount module 110 determines the update block file from the bitmap information, uploads them to the online storage service 105 (Step 1104), The process ends.
  • the online storage mount module 110 directly deletes files on the online storage, updates information, etc., but instead, the online storage mount module 110 may instruct the online storage service 105 processor (not shown) to update the file via the above-described Web interface, and the actual file update may be performed by the online storage service 105 processor. good.
  • ⁇ Summary> In the embodiment of the present invention, among N (positive integer) divided files generated by dividing an original file stored by the online storage service in the local cache of the file server, K (a positive integer with K ⁇ N). The number of split files is stored.
  • An online storage mount module (hereinafter referred to as “mount module”) acquires data from the online storage service and the local cache. Then, the mount module determines whether all of the divided blocks necessary for providing data corresponding to the I / O request exist in the local cache, and if there is a necessary divided block, starts from the corresponding divided block. Data corresponding to the file I / O request is acquired. By doing so, the upper limit restriction on the file size can be solved.
  • online storage services usually charge according to the amount of communication, but reduce the communication cost by providing a mechanism that manages files separately and downloads and caches only the parts necessary for on-demand. be able to.
  • the mount module accesses the online storage service, acquires the insufficient divided blocks, and stores them in the local cache.
  • the mount module accesses the online storage service, acquires the insufficient divided blocks, and stores them in the local cache.
  • the local cache further stores the meta information of the original file along with the divided files.
  • This meta information includes a file update flag indicating whether or not the original file has been updated, and bitmap information indicating the states of the N divided files. Then, when there is a write request from the user terminal and at least one of the K divided files stored in the local cache is updated, the mount module sets the file update flag to ON, and the updated divided file The bitmap information corresponding to is updated.
  • the meta information further includes a meta information update flag indicating whether or not the meta information has been updated, and file size information indicating the file size.
  • the mount module When the mount module is a file size change request (TRUNCATE request) and the target file is expanded or reduced by the file size change request, the mount module performs an extension process or a reduction process on the bitmap information. Then, the file size information is updated and the meta information update flag is turned ON. In this way, the original file on the online service and its meta information can be updated as appropriate (asynchronously with the processing in the file server). Meta information and files are cached on the file server, and the cache data is uploaded to the online storage side periodically and asynchronously, so that the meta information of the file can also be accessed for access to the online storage service via WAN. Speeding up access and file access can be realized.
  • TRUNCATE request file size change request
  • the mount module performs an extension process or a reduction process on the bitmap information. Then, the file size information is updated and the meta information update flag is turned ON. In this way, the original file on the online service and its meta information can be updated as appropriate (asynchronously with the processing in the file server).
  • the present invention can also be realized by a program code of software that realizes the functions of the embodiment.
  • a storage medium in which the program code is recorded is provided to the system or apparatus, and the computer (or CPU or MPU) of the system or apparatus reads the program code stored in the storage medium.
  • the program code itself read from the storage medium realizes the functions of the above-described embodiments, and the program code itself and the storage medium storing the program code constitute the present invention.
  • a storage medium for supplying such program code for example, a flexible disk, CD-ROM, DVD-ROM, hard disk, optical disk, magneto-optical disk, CD-R, magnetic tape, nonvolatile memory card, ROM Etc. are used.
  • an OS operating system
  • the computer CPU or the like performs part or all of the actual processing based on the instruction of the program code.
  • the program code is stored in a storage means such as a hard disk or memory of a system or apparatus, or a storage medium such as a CD-RW or CD-R
  • the computer (or CPU or MPU) of the system or apparatus may read and execute the program code stored in the storage means or the storage medium when used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

　ファイルサーバのストレージ容量を、オンラインストレージサービスを利用して拡張する場合、オンラインストレージサービスの制約であるファイルサイズの上限制約の解消と通信コスト低減を実現する。オンラインストレージサービス上の論理ボリュームをマウントするカーネルモジュールにおいて、ファイルを固定長のブロックファイルに分割して保存・管理することで、ファイルサイズの上限制約を回避する。また、マウントされたファイルシステムに対して、READ/WRITE要求が発生したとき、オフセット値とサイズ情報から必要なブロックファイルのみ、オンラインストレージサービスよりダウンロードして利用することで、通信の最適化を図り、通信コスト低減を実現する。（図１参照）

Description

ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム
　本発明は、ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラムに関し、例えば、外部ストレージサービスに格納するファイルを取得して利用者端末に提供するための技術に関するものである。
　近年のＩＴ潮流の大きな流れとして、クラウドコンピューティングと呼ばれる新しいＩＴ活用形態に注目が集まっている。その一つとして、インターネット経由でストレージサービスを提供するSTaaS（Storage as a service）の普及が進んでいる。STaaSでは、論理的なストレージ容量を低価格で提供するサービスであり、一般的に、ストレージサービスを利用するための外部インタフェースをRESTやSOAPといったWebインタフェース形式で提供している。STaaSについては、セキュリティやコンプライアンス等の問題は残っているものの、コストメリットが優先し、今後、個人や企業における利用が拡大していくと考えられる。
　通常、こうしたオンラインストレージサービスでは、非常に大きなスケーラビリティを特長としているが、格納可能なファイルサイズについては上限が存在する。例えば、Amazon（登録商標） S3の場合、バケット内に格納できるファイルオブジェクト数に制限はないが、ファイルオブジェクトの最大サイズは５ＧＢであり、５ＧＢ以上のサイズの単一ファイルをそのまま格納することはできない（制約条件１）。また、ファイルの読み込みについては、部分的な読込み処理を行うことは可能だが、書込みについては、部分的書込みを行うことはできず、バケット内に格納されたファイルの置き換えしかできない（制約条件２）。例えば、５ＧＢのファイルに対して、１ＭＢ分のブロックの書き換えを行う場合、５ＧＢのファイルをすべてダウンロードして、１ＭＢ分のブロックを書き換え、最後に５ＧＢのファイル全体をアップロードする必要があり、通信コストが大きくなる問題がある。したがって、Random READ・WRITE処理に対して、不必要な部分のデータ通信が発生してしまい、通信コストがかかってしまう問題がある。また、ＷＡＮ経由でデータアクセスを行うため、ローカルディスク等へのデータ通信速度に比べて、通信速度が圧倒的に遅く、同期的な通信を行った場合、ファイルのリストアップやREAD/WRITEのオーバヘッドが大きくなる問題がある。
　ところで、オンラインストレージサービスをファイルサーバのバックアップ用外部ストレージ、もしくは容量拡張用の外部ストレージとして利用する場合、クライアントからは透過的に単一のファイルサーバに見え、かつファイルサーバよりオンラインストレージサービスに接続して、データをコピー・移動する仕組みが必要になる。例えば、特許文献１には、クライアントから透過的に単一サーバに見せ、データコピー・移動を隠蔽する既存技術が開示されている。また、特許文献２には、データコピー・移動に関連する既存技術が開示されている。
　特許文献１では、１次ストレージを有する第１サーバと、２次ストレージを有する第２サーバ、およびクライアントの間に中間装置を設けている。そして、クライアントから１次ストレージへのファイルアクセスがあった場合、そのアクセス対象のファイルがスタブファイル（アクセス先にリンクさせるためのファイル）のとき、対応する２次ストレージ上のファイルにアクセス要求を変更することで、スタブファイルをあたかも実体であるかのように見せ、１次ストレージから２次ストレージへのデータ移動をクライアントに対し隠蔽するようにしている。
　また、特許文献２では、高速ディスクボリュームの更新を監視して更新ビットマップを作成し、各更新ビットマップのＯＲを演算して所定時間更新されていないセグメントを検出し、検出されたセグメント情報を元に、高速ディスクボリュームから低速ディスクボリュームにデータ移動（ストレージ階層間移動）を行うようにしている。
特開２００６－１６４２１１号公報 特開２００７－２２６５９６号公報
　しかしながら、特許文献１及び特許文献２では、前述のオンラインストレージサービスの制約条件（１及び２）を回避しつつ、オンラインストレージサービスをファイルサーバのバックアップ用外部ストレージ、または容量拡張用外部ストレージとして利用することはできない。いずれも、オンラインストレージ上のファイルサイズに関する制約を回避する方策を提案しておらず、ＷＡＮ経由の通信コストを最適化する方策についても提案していない。
　本発明はこのような状況に鑑みてなされたものであり、オンラインストレージサービス利用時における通信コストを最適化すると共に、アクセスの高速化を実現するための技術を提供するものである。
　上記課題を解決するために、本発明では、オンラインストレージサービス内にファイルを格納する際に、ファイルデータを分割したブロックファイル群とメタ情報を格納し、利用者端末からのファイル読込み要求に対して、読込みに必要なブロックファイルをオンラインストレージサービスよりダウンロードしてキャッシュする。そして、利用者端末からの書込み要求に対しては、書込み対象となるブロックファイルをオンラインストレージサービスよりダウンロードしてキャッシュし、当該キャッシュされた書込みデータに対して上書きする。また、キャッシュされ変更されたブロックファイルとメタ情報を、非同期にオンラインストレージサービス上に反映する。
　また、オンラインストレージマウントモジュールは、メタ情報に記録されたメタ情報更新フラグ、ファイル更新フラグ、及び削除フラグを参照し、オンラインストレージサービスにおけるフ元ファイルの削除、ファイル内容、及びメタ情報を、ファイルサーバの処理とは同期させず（非同期）に、ポリシ情報に従って順次実行する。
　さらに、オンラインストレージマウントモジュールは、利用者端末からの書込み要求を処理する場合、メタ情報内に記録されたビットマップ情報に更新したブロックファイルの識別情報を反映し、当該ビットマップ情報を利用して、オンラインストレージサービスにアップロードが必要なブロックファイルのみ、ポリシ情報に従って非同期に更新する。
　さらなる本発明の特徴は、以下本発明を実施するための形態および添付図面によって明らかになるものである。
　本発明によれば、オンラインストレージサービス利用時における通信コストを最適化すると共に、アクセスの高速化を実現することが可能となる。
本発明の実施形態によるストレージシステムの概略構成を示す図である。 ファイル分割管理・分割キャッシュの概念を説明するための図である。 メタ情報が格納するファイル属性テーブルの例を示す図である。 管理用デーモンが提供する設定用ＧＵＩを示す図である。 設定用ＧＵＩにおける、新規・編集ボタン押下時のＧＵＩを示す図である。 ファイルオープン時のオンラインストレージマウントモジュールの処理を説明するためのフローチャートである。 READ時のオンラインストレージマウントモジュールの処理を説明するためのフローチャートである。 WRITE時のオンラインストレージマウントモジュールの処理を説明するためのフローチャートである。 TRUNCATE時のオンラインストレージマウントモジュールの処理を説明するためのフローチャートである。 非同期更新時の全体処理を説明するためのフローチャートである。 非同期更新時のファイル更新処理の詳細を説明するためのフローチャートである。
　本発明は、例えば、外部ストレージサービスに格納するファイルサイズの上限制約を解消し、また、通信コストを低減する方式に関するものである。本発明では、オンラインストレージサービス上の個々のファイルを分割して管理し、ファイルのREAD/WRITE操作に応じて必要部分のみダウンロード・アップロードして、オンラインストレージサービスのファイルサイズ制約を解消し、通信コストを最適化する仕組みを提案する。更に、分割されたファイルブロックをローカルでキャッシュし、ファイルアクセスを高速化するとともに、オンラインストレージサービス上のファイルのメタ情報もファイルサーバ上に格納し、ファイルリストアップやファイル名・ディレクトリ構成等のメタ情報変更、及びREAD/WRITEの高速化を実現する仕組みを提供する。
　以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
　＜ストレージシステムの構成＞
　図１は、本発明の実施形態によるストレージシステムの概略構成を示す図である。当該ストレージシステムは、企業・組織１００内に設置された、ファイルサーバ１０６、少なくとも１つの利用者端末１０１、及びゲートウェイサーバ１０３と、外部のオンラインストレージサービス１０５と、を有し、利用者端末１０１とファイルサーバ１０６とゲートウェイサーバ１０３は、例えばイントラネット１０２で接続され、ゲートウェイサーバ１０３とオンラインストレージサービス１０５はＷＡＮ１０４で接続されている。
　ファイルサーバ１０６に対しては、同じく接続された利用者端末１０１よりファイルアクセスが発生する。また、イントラネット１０２は、ゲートウェイサーバ１０３を経由して、ＷＡＮ１０４に接続し、その先にオンラインストレージサービス１０５が稼動している。ここで、オンラインストレージサービス１０５とは、ＷＡＮ上にWebインタフェースによるストレージサービスを公開・提供しているサイトであり、実際のサービス例として、Amazon（登録商標） S3やWindows（登録商標） Azure Storageなどが挙げられる。
　ファイルサーバ１０６は、例えばＮＡＳ（Network Attached Storage）のようなファイルサーバであり、NFS/CIFSサービスモジュール１０７と、管理用デーモン１０８と、ファイルシステム１０９と、オンラインストレージマウントモジュール１１０と、ローカルキャッシュ１１２を含む二次記憶装置１１１と、を有している。なお、NFS/CIFSサービスモジュール１０７、管理用デーモン１０８、ファイルシステム１０９、及びオンラインストレージマウントモジュール１１０は、モジュールとして実現しても良いし、プログラムで構成され、ファイルサーバ１０６内にあるプロセッサが各プログラムに従って各機能を実現するようにしても良い。また、ローカルキャッシュ１１２は、二次記憶装置１１１内にキャッシュ用の領域として設けられているが、この形態に限られるものではなく、二次記憶装置１１１とは別にキャッシュ用メモリが用意されていても良い。
　NFS/CIFSサービスモジュール１０７は、利用者端末１０１よりNFSやCIFSプロトコルでアクセスを受け、ファイルサーバとして動作するための基本モジュールであり、Sambaがその一例である。また、ユーザの認証が必要な場合は、NFS/CIFSサービスモジュール１０７が認証を処理する。
　オンラインストレージマウントモジュール１１０は、オンラインストレージサービス上の論理ドライブをファイルサーバ１０６内にマウントする機能を提供するモジュールである。ここで、論理ドライブとはオンラインストレージサービス上の論理的な記憶ボリュームに対応するもので、例えばAmazon（登録商標） S3では「バケット」に相当する。以下、Amazon（登録商標） S3を仮定して、ファイルサーバのＯＳはLinux、更に、オンラインストレージマウントモジュール１１０はバケットをマウントするカーネルモジュール（例えば、FUSEベースのファイルシステムモジュール）として説明を進めるが、これにより発明が限定されるものではない。
　管理用デーモン１０８は、オンラインストレージマウントモジュール１１０が、どのバケットを誰のアカウントで、ファイルサーバ内のどこにマウントするかを設定するモジュールであり、設定用のＧＵＩ（例えば、図４及び５参照）を提供する。管理者は、図示しない管理者用端末に表示画面に表示された設定用ＧＵＩを利用してオンラインストレージマウントモジュール１１０を管理することができる。
　ファイルサーバ１０６内の二次記憶装置１１１にはローカルキャッシュ１１２が保存される。このローカルキャッシュ１１２は、オンラインストレージマウントモジュール１１０が、生成・管理するファイルであり、オンラインストレージサービス１０５上のファイルへのアクセスを高速化するためのキャッシュである。
　ファイルアクセスの動作概要を説明すると次のようになる。例えば、利用者端末１０１からあるファイルに対してＩ／Ｏ要求が出されると、NFS/CIFSサービスモジュール１０７がその要求をファイルシステム１０９に提供する。Ｉ／Ｏ要求の対象ファイルが二次記憶装置１１１に格納されたファイルであれば、ファイルシステム１０９は、二次記憶装置１１１から対象ファイルを取得し、NFS/CIFSサービスモジュール１０７を介して利用者端末１０１に当該ファイルを提供する。一方、対象ファイルがローカルキャッシュ１１２にある場合（Amazon（登録商標） S3に関連づけられたファイルであって、キャッシュされている場合）には、ファイルシステム１０９は、オンラインストレージマウントモジュール１１０を介して対象ファイルを取得し、NFS/CIFSサービスモジュール１０７を介して利用者端末１０１に当該ファイルを提供する。また、対象ファイル（Amazon（登録商標） S3に関連づけられたファイル）がローカルキャッシュ１１２にも無い場合（オンラインストレージサービス１０５にある場合）には、オンラインストレージマウントモジュール１１０が、オンラインストレージサービス１０５から対象ファイルを取得（マウント）し、ローカルキャッシュ１１２に格納して、ファイルシステム１０９に提供する。そして、ファイルシステム１０９が、NFS/CIFSサービスモジュール１０７を介して利用者端末１０１に当該ファイルを提供する。
　＜ファイル分割管理・分割キャッシュの概念＞
　図２は、本発明の実施形態によるファイル分割管理・分割キャッシュの概念を示す図である。オンラインストレージサービス１０５上のファイルデータ２０４は、単一ファイルを構成する分割ブロックファイル（サブファイル）の集合であり、メタ情報２００と分割ブロックファイル群２０３で構成される。
　メタ情報２００は、各ファイルに付随する属性情報であり、例えばファイル名や更新日時等の情報を含んでいる（詳細について図３を参照）。また、分割ブロックファイル群２０３は、ファイル本体を固定長サイズで分割したブロックファイルの集合である。
　一方、ファイルサーバ内のローカルキャッシュ１１２は、単一ファイルのキャッシュファイルの集合に相当する、キャッシュファイルデータ２０２を有している。キャッシュファイルデータ２０２は、メタ情報２００とキャッシュブロックファイル群２０１で構成され、キャッシュブロックファイル群２０１は、分割ブロックファイル群２０３のうち、オンラインストレージマウントモジュール１１０が高速化処理のためにダウンロードしたファイルであり、ファイル更新処理が起こっていない状況では、分割ブロックファイル群２０３の部分集合になる。また、ファイル更新処理が発生した場合、対応する更新ブロックが格納され、定期的に実行される更新処理時（図１０及び１１参照）に、オンラインストレージマウントモジュール１１０は、分割ブロックファイル群２０３のうち、対応するファイルを上書き更新する。
　実際のファイルサーバ１０６内におけるキャッシュデータ格納方法については、ファイルサーバ１０６内のキャッシュ領域に、各キャッシュファイルデータ２０２につき、１つのディレクトリが用意され、その中にメタ情報２００とキャッシュブロックファイル群２０１が格納される。オンラインストレージサービス１０５上に関しても、同様の構成（１つのファイルにつき１つのディレクトリが用意される）でデータ保存される。
　＜ファイル属性テーブル＞
　図３は、本実施形態において、メタ情報２００が格納するファイル属性テーブルの構成例を示す図である。メタ情報２００は、構成項目として、例えば、識別番号３００と、ファイル名３０１と、親ノード識別番号３０２と、メタ情報更新フラグ３０３と、ファイル更新フラグ３０４と、削除フラグ３０５と、ビットマップ情報３０６と、オンラインストレージ上サイズ３０７と、Stat情報３０８と、を含んでいる。
　識別番号３００は、ファイル（ファイルデータ２０４に相当）をユニークに識別するための番号情報であり、ファイル名やファイルパス等のメタ情報が変わっても変わらない唯一のデータである。親ノード識別番号３０２は、ディレクトリ構成を採る場合に、当該ファイルの親ディレクトリに対応するファイルの識別番号を格納している。
　メタ情報更新フラグ３０３・ファイル更新フラグ３０４は、各ファイルのメタ情報・ファイルデータが更新された場合に設定されるフラグであり、定期的な更新処理時に参照される。当該フラグは、更新されたか否かを示すのであり、例えば１又は０が格納される。ローカルキャッシュで書き込み処理が実行されると、ローカルキャッシュ１１２上のデータと、オンラインストレージサービス１０５上のデータとの間にズレが生じる。この更新によるズレをオンラインストレージ１０５上のデータに後で反映させるために、当該フラグが用いられる。
　削除フラグ３０５は、当該ファイル（ファイルデータ２０４に相当）の削除処理が発生した際に設定されるフラグであり、これも更新処理時に参照される。
　ビットマップ情報３０６は、ローカルにキャッシュされているブロックファイルのうち、更新処理の発生したブロックを記録するためのデータであり、ファイル更新処理時に利用される。
　オンラインストレージ上サイズ３０７は、当該データがオンラインストレージよりダウンロードされた場合、その元ファイルのデータサイズを格納した属性であり、更新処理時の余分ファイルの削除に利用される。
　最後に、Stat情報３０８は、当該ファイルのファイルサイズやブロックサイズ、ACL等のファイル統計情報を格納している。
　＜オンラインストレージサービス設定・管理用ＧＵＩ＞
　図４は、管理用デーモンが提供する設定・管理用ＧＵＩ（Graphical User Interface）を示す図である。当該ＧＵＩは、管理者が図示しない管理者用端末から管理用デーモン１０８に対して、オンラインストレージサービスの設定及び／又は管理を要求したときに管理者用端末の常時画面上に表示される。
　設定・管理画面はリストコントロールとボタンで構成され、リストコントロールは設定されたバケット４００と、バケットに対応づけてマウントされる、ファイルサーバ１０６上のファイルパス４０１と、アカウント４０２の組データのリストを表示している。
　当該組データは、Amazon（登録商標） S3の指定バケット名とファイルサーバ内のマウント先フォルダのファイルパス、及びマウントに利用するAmazon（登録商標） S3のユーザアカウント名の組を示しており、マウントされたフォルダに対してファイルの読み書きを実行した場合、マウントに利用したAmazon（登録商標） S3のユーザアカウントに対して、利用料金が発生する設定になる。
　設定ＧＵＩには、新規ボタン４０３、編集ボタン４０４、削除ボタン４０５が配置され、エントリの新規生成、編集、削除を実行することができるようになっている。また、設定内容を確定する場合はＯＫボタン４０６、キャンセルする場合はキャンセルボタン４０７を押す。アカウントについては、予めAmazon（登録商標） S3に契約・作成したものを利用する必要があり、各アカウントに対して発行された、Amazon（登録商標） S3サービスへのアクセスに必要なAccess ID KeyとSecret Access Keyは、ファイルサーバ内に暗号化されて保存されている。
　図５は、設定・管理用ＧＵＩ（図４）で新規・編集ボタン押下時のＧＵＩを示す図である。バケット名、ファイルパス、アカウントを設定できるエディットボックスが配置され、ＯＫボタン５０３で確定、キャンセルボタン５０４でキャンセルを行うことができる。
　＜ファイルオープン時の処理＞
　図６は、本実施形態において、ファイルオープン時のオンラインストレージマウントモジュール１１０が実行する処理を説明するためのフローチャートである。当該処理は、ファイルオープン要求に対して、ファイルを使用するときに必要なリソースを確保する処理であると言える。
　まず始めに、オンラインストレージマウントモジュール１１０は、ファイルオープン要求を受信すると（ステップ６００）、当該オープン要求対象であるファイルのキャッシュブロックファイル群が、ファイルサーバ１０６内のキャッシュ領域に存在するか否かをチェックする（ステップ６０１）。
　該当するキャッシュ領域が存在する場合（ステップ６０１でＹｅｓ）、オンラインストレージマウントモジュール１１０は、キャッシュブロックファイル群を格納するフォルダをオープンして、そのファイル識別子を返す（ステップ６０２）。
　一方、該当するキャッシュ領域が存在しない場合（ステップ６０１でＮｏ）、メタ情報、及びキャッシュブロックファイル群を格納するフォルダを生成し、そのファイル識別子を返す。
　＜ファイルREAD時の処理＞
　図７は、本実施形態において、READ要求時に、オンラインストレージマウントモジュール１１０が実行する処理を説明するためのフローチャートである。
　オンラインストレージマウントモジュール１１０は、READ要求を受信する（ステップ７００）と、READ要求内で指定されたファイルのオフセット情報とサイズ情報を基に、アクセス先となる必要な分割ブロックを計算する（ステップ７０１）。
　そして、オンラインストレージマウントモジュール１１０は、ファイル提供に必要となる分割ブロックファイルが全てローカルキャッシュ１１２に格納されているかどうかを判定する（ステップ７０２）。
　必要な分割ブロックファイルが全てキャッシュされている場合（ステップ７０２でＹｅｓ）、オンラインストレージマウントモジュール１１０は、キャッシュされたブロックファイルから、必要領域分のデータを読み取り、READ要求で返すバッファを生成する（ステップ７０３）。
　一方、必要な分割ブロックファイルのうち一部でもキャッシュされていない場合（ステップ７０２でＮｏ）、オンラインストレージマウントモジュール１１０は、オンラインストレージサービス１０５からキャッシュされていない分割ブロックファイルをダウンロードしてローカルキャッシュ１１２に格納し（ステップ７０５）、キャッシュされている場合のときと同様にREAD要求で返す読込みバッファを構成する（ステップ７０３）。
　最後に、オンラインストレージマウントモジュール１１０は、構成した読込みバッファを上位制御（ファイルシステム１０９）に返して処理を終了する（ステップ７０４）。
　＜ファイルWRITE時の処理＞
　図８は、本実施形態において、WRITE要求時に、オンラインストレージマウントモジュール１１０が実行する処理を説明するためのフローチャートである。
　オンラインストレージマウントモジュール１１０は、WRITE要求を受信する（ステップ８００）と、WRITE要求で指定されたオフセット情報とサイズ情報から、必要な分割ブロックを算出する（ステップ８０１）。
　その後、オンラインストレージマウントモジュール１１０は、書込み領域をカバーする必要な分割ブロックファイルがすべてローカルキャッシュ１１２に格納されているか否かを判別する（ステップ８０２）。
　一部キャッシュされていないブロックファイルが存在した場合（ステップ８０２でＮｏ）、オンラインストレージマウントモジュール１１０は、そのファイルをオンラインストレージサービス１０５からダウンロードしてローカルキャッシュ１１２に格納する（ステップ８０６）。
　必要ブロックファイルが全てキャッシュされている場合（ステップ８０２でＹｅｓ）、或いは、ステップ８０６の処理によって必要なブロックファイルがすべてキャッシュされた状態にした後、オンラインストレージマウントモジュール１１０は、キャッシュされたブロックファイルに対して、必要な書込み領域分にWRITE要求内の書込みバッファを上書きする（ステップ８０３）。
　そして、オンラインストレージマウントモジュール１１０は、更新したブロックファイルに対応して、ビットマップ情報３０６内の対応ビットを１にし、ビットマップ情報３０６を更新する（ステップ８０４）。
　最後に、オンラインストレージマウントモジュール１１０は、ファイル更新フラグ３０４をＯＮに設定して処理を終了する（ステップ８０５）。
　＜ファイルTRUNCATE時の処理＞
　図９は、本実施形態において、TRUNCATE時に、オンラインストレージマウントモジュール１１０が実行する処理を説明するためのフローチャートである。ここで、TRUNCATE処理とは、対象ファイルを伸縮する処理を行うファイルシステムの処理である。
　オンラインストレージマウントモジュール１１０は、TRUNCATE要求を受信する（ステップ９００）と、ファイルの拡張要求か縮小要求かを、指定サイズ情報を基に判定する（ステップ９０１）。
　拡張要求の場合（ステップ９０１でＹｅｓ）、オンラインストレージマウントモジュール１１０は、当該ファイルの拡張後のサイズに対して必要な分、ビットマップ情報データを拡張し（ステップ９０２）、ファイルサイズ情報の更新を行う（ステップ９０３）。
　一方、縮小要求の場合（ステップ９０１でＮｏ）、オンラインストレージマウントモジュール１１０は、当該ファイルの縮小後のサイズに相当するサイズに、ビットマップ情報データを縮小し（ステップ９０５）、ファイルサイズ情報の更新を行う（ステップ９０３）。
　最後に、オンラインストレージマウントモジュール１１０は、メタ情報更新フラグ・ファイル更新フラグをＯＮに設定して処理を終了する（ステップ９０４）。
　なお、ファイルサイズを縮小した場合、縮小処理に対して不要となる分割ブロックファイルが出てくるが、そのファイルを削除する処理は行わない。なぜなら縮小した後に拡大処理が発生した場合、再度分割ブロックファイルを生成するオーバヘッドを回避するためである。
　＜非同期ファイル更新処理＞
　図１０は、本実施形態による、非同期更新時の処理の全体概要を説明するためのフローチャートである。非同期更新処理は、別スレッドで定期的に実行されるものであり、その周期はポリシにより設定できる仕組みとなっている。
　まず、オンラインストレージマウントモジュール１１０は、非同期更新用スレッドを用いて、各ファイルのメタ情報にアクセスし、削除フラグがＯＮであるかをチェックする（ステップ１０００）。削除フラグがＯＮの場合（ステップ１０００でＹｅｓ）、オンラインストレージマウントモジュール１１０は、当該識別子に対応するオンラインストレージ上の対象ファイルを削除し（ステップ１００５）、処理を終了する。
　削除フラグがＯＦＦの場合（ステップ１０００でＮｏ）、オンラインストレージマウントモジュール１１０は、ファイル更新フラグがＯＮか否かを判定する（ステップ１００１）。
　ファイル更新フラグがＯＮの場合（ステップ１００１でＹｅｓ）、オンラインストレージマウントモジュール１１０は、ファイル更新処理（詳細は図１１参照）を実行し（ステップ１００２）、ＯＦＦの場合はファイル更新処理をスキップして、メタ情報更新フラグの判定処理に処理を移行させる（ステップ１００３）。
　メタ情報更新フラグがＯＮの場合（ステップ１００３でＹｅｓ）、オンラインストレージマウントモジュール１１０は、オンラインストレージ上の対応ファイルのメタ情報を更新し（ステップ１００４）、ＯＦＦの場合（ステップ１００３でＮｏ）、何もせずに処理を終了する。
　図１１は、非同期更新時のファイル更新処理（ステップ１００２）の詳細を説明するためのフローチャートである。
　まず、オンラインストレージマウントモジュール１１０は、現在のファイルサイズと、ファイルのメタ情報属性に格納された、オンラインストレージサービス１０５上の元ファイルのサイズとを比較する（ステップ１１００）。
　そして、オンラインストレージマウントモジュール１１０は、元ファイルに対して、現時点でのファイルサイズが縮小しているか否かを判別する（ステップ１１０１）。ファイルサイズが縮小していない場合（ステップ１１０１でＮｏ）、余分ファイルは存在しないため、処理はステップ１１０３に移行する。
　縮小している場合（ステップ１１０１でＹｅｓ）、余分な分割ブロックファイルがオンラインストレージサービス１０５上に存在することになるため、オンラインストレージマウントモジュール１１０は、まずそれらのファイルをオンラインストレージサービス１０５から削除する（ステップ１１０２）。
　そして、オンラインストレージマウントモジュール１１０は、更新ブロックファイルの有無について判別する（ステップ１１０３）。
　更新ブロックファイルが存在しない場合（ステップ１１０３でＮｏ）、オンラインストレージマウントモジュール１１０は、ファイル更新処理を終了する。一方、更新ブロックファイルが存在する場合（ステップ１１０３でＹｅｓ）、オンラインストレージマウントモジュール１１０は、ビットマップ情報より更新ブロックファイルを判別し、それらをオンラインストレージサービス１０５にアップロードして（ステップ１１０４）から、処理を終了する。
　なお、本実施形態では、ステップ１００４、１００５、１１０２、１１０４等において、オンラインストレージマウントモジュール１１０が直接オンラインストレージ上のファイル削除、情報更新等を行う構成としたが、それに代えて、オンラインストレージマウントモジュール１１０が、前述したWebインタフェースを介してオンラインストレージサービス１０５のプロセッサ（図示せず）にファイル更新等の指示を行い、実際のファイル更新等は、オンラインストレージサービス１０５のプロセッサが行うような構成としても良い。
　＜まとめ＞
　本発明の実施形態では、ファイルサーバのローカルキャッシュにおいて、オンラインストレージサービスが格納するオリジナルファイルを分割することにより生成されたＮ（正整数）個の分割ファイルのうちＫ（Ｋ＜Ｎの正整数）個の分割ファイルを格納している。また、オンラインストレージマウントモジュール（以下、「マウントモジュール」という）が、オンラインストレージサービス及びローカルキャッシュからデータを取得するようになっている。そして、マウントモジュールは、Ｉ／Ｏ要求に対応するデータを提供するために必要な分割ブロックの全てがローカルキャッシュに存在するか判断し、必要な分割ブロックが存在する場合には該当する分割ブロックからファイルＩ／Ｏ要求に対応するデータを取得する。このようにすることにより、ファイルサイズの上限制約について解消することができる。つまり、通常、オンラインストレージサービスでは、通信量に応じた課金を行っているが、ファイルを分割管理し、オンデマンドに必要な部分のみダウンロード・キャッシュする仕組みを提供することで、通信コストを低減することができる。
　また、必要な分割ブロックの全てがローカルキャッシュに存在しない場合には、マウントモジュールは、オンラインストレージサービスにアクセスし、不足分の分割ブロックを取得して、ローカルキャッシュに格納するようにしている。このように、クライアントからの要求に応じ、オンデマンドで必要な分割ブロックファイルのみダウンロードして処理するため、通信コストを低減することができる。
　ローカルキャッシュは、さらに、オリジナルファイルのメタ情報を分割ファイルと共に格納している。このメタ情報は、オリジナルファイルを更新したか否かを示すファイル更新フラグと、Ｎ個の分割ファイルの状態を示すビットマップ情報とを含んでいる。そして、マウントモジュールは、利用者端末から書き込み要求があって、ローカルキャッシュに格納されたＫ個の分割ファイルの少なくとも１つが更新された場合、ファイル更新フラグをＯＮに設定し、更新された分割ファイルに対応するビットマップ情報を更新する。また、メタ情報は、さらに、メタ情報を更新したか否かを示すメタ情報更新フラグと、ファイルサイズを示すファイルサイズ情報を含んでいる。そして、マウントモジュールは、ファイルサイズ変更要求（TRUNCATE要求）であって、当該ファイルサイズ変更要求によって、対象ファイルが拡張或いは縮小された場合、ビットマップ情報を拡張処理或いは縮小処理する。そして、ファイルサイズ情報を更新すると共に、メタ情報更新フラグをＯＮとする。このようにすることにより、オンラインサービス上のオリジナルファイル及びそのメタ情報を適宜（ファイルサーバ内の処理とは非同期に）更新することができる。ファイルサーバ上にメタ情報とファイルをキャッシュし、定期的に非同期で、それらのキャッシュデータをオンラインストレージ側にアップロードする仕組みにすることで、ＷＡＮ経由のオンラインストレージサービスに対するアクセスについても、ファイルのメタ情報アクセスやファイルアクセスの高速化を実現することができる。
　以上のように、ファイル・メタ情報アクセス高速化のために、オンラインストレージサービス上のファイル・メタ情報をファイルサーバにキャッシュする仕組みを提供し、また、非同期でファイルサーバ内のキャッシュされたメタ情報とファイルをオンラインストレージにアップロードすることで、ファイルサーバへの負荷を低減した形での、更新内容のオンラインストレージサービスへの確定処理も実現している。
　なお、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
　また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
　また、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ－ＲＷ、ＣＤ－Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
１００…企業・組織
１０１…利用者端末
１０２…イントラネット
１０３…ゲートウェイサーバ
１０４…ＷＡＮ
１０５…オンラインストレージサービス
１０６…ファイルサーバ
１０７…NFS/CIFSサービスモジュール
１０８…管理用デーモン
１０９…ファイルシステム
１１０…オンラインストレージマウントモジュール
１１１…二次記憶装置
１１２…ローカルキャッシュ
２００…メタ情報
２０１…キャッシュブロックファイル群
２０２…キャッシュファイルデータ
２０３…分割ブロックファイル群
２０４…ファイルデータ
３００…識別番号
３０１…ファイル名
３０２…親ノード識別番号
３０３…メタ情報更新フラグ
３０４…ファイル更新フラグ
３０５…削除フラグ
３０６…ビットマップ情報
３０７…オンラインストレージ上サイズ
３０８…Stat情報

Claims (15)

  1. 　ネットワーク経由で接続されたオンラインストレージサービスからファイルを取得して利用者端末に前記ファイルを提供するファイルサーバ装置であって、
    　前記オンラインストレージサービスが格納するオリジナルファイルを分割することにより生成されたＮ（正整数）個の分割ファイルのうちＫ（Ｋ＜Ｎの正整数）個の分割ファイルを格納するローカルキャッシュと、
    　前記オンラインストレージサービス及び前記ローカルキャッシュからデータを取得するマウントモジュールと、を有し、
    　前記マウントモジュールは、Ｉ／Ｏ要求に対応するデータを提供するために必要な分割ブロックの全てが前記ローカルキャッシュに存在するか判断し、前記必要な分割ブロックが存在する場合には該当する分割ブロックから前記ファイルＩ／Ｏ要求に対応するデータを取得することを特徴とするファイルサーバ装置。
  2. 　請求項１において、
    　前記マウントモジュールは、前記必要な分割ブロックの全てが前記ローカルキャッシュに存在しない場合には、前記オンラインストレージサービスにアクセスし、不足分の分割ブロックを取得して、前記ローカルキャッシュに格納することを特徴とするファイルサーバ装置。
  3. 　請求項１において、
    　前記ローカルキャッシュは、さらに、前記オリジナルファイルのメタデータであって、前記オリジナルファイルを更新したか否かを示すファイル更新情報と、前記Ｎ個の分割ファイルの状態を示すビットマップ情報とを含むメタデータを格納し、
    　前記マウントモジュールは、前記Ｉ／Ｏ要求が書き込み要求であって、前記ローカルキャッシュに格納された前記Ｋ個の分割ファイルの少なくとも１つが更新された場合、前記ファイル更新情報及び前記更新された分割ファイルに対応する前記ビットマップ情報の両方を、更新したことを示す情報に設定することを特徴とするファイルサーバ装置。
  4. 　請求項３において、
    　前記メタデータは、さらに、前記メタデータを更新したか否かを示すメタデータ更新情報と、ファイルサイズを示すファイルサイズ情報を含み、
    　前記マウントモジュールは、前記Ｉ／Ｏ要求がファイルサイズ変更要求である場合、当該ファイルサイズ変更要求が対象ファイルの拡張要求か否か判断し、当該判断結果に基づいて前記ビットマップ情報を拡張処理或いは縮小処理し、前記ファイルサイズ情報を更新すると共に、前記メタデータ更新情報を、更新したことを示す情報に設定することを特徴とするファイルサーバ装置。
  5. 　請求項１において、
    　前記ローカルキャッシュは、さらに、前記オリジナルファイルのメタデータを格納し、
    　前記マウントモジュールは、前記ローカルキャッシュに格納された前記分割データが更新された場合、更新処理のタイミングを定めたポリシ情報に従って、前記オンラインサービス上の前記オリジナルファイルと前記メタデータを更新することを特徴とするファイルサーバ装置。
  6. 　請求項５において、
    　前記メタデータは、メタ情報更新フラグ、ファイル更新フラグ、及び削除フラグを含み、
    　前記マウントモジュールは、前記ポリシ情報に従って、前記メタデータを参照し、前記オンラインストレージサービスにおける前記オリジナルファイルの削除、前記オリジナルファイルの内容の更新、前記メタデータを更新することを特徴とするファイルサーバ装置。
  7. 　請求項３において、
    　前記マウントモジュールは、更新処理のタイミングを定めたポリシ情報に従って、前記メタデータを参照し、前記更新された分割ファイルのみ前記オンラインストレージサービスにアップロードして、前記オリジナルファイルを更新することを特徴とするファイルサーバ装置。
  8. 　オリジナルファイルを格納するオンラインストレージサービスと、ネットワークを介して前記オンラインストレージサービスに接続され、前記オンラインストレージサービスからファイルを取得して利用者端末に提供するファイルサーバ装置と、を含むストレージシステムを管理する方法であって、
    　前記ファイルサーバ装置は、前記オリジナルファイルを分割することにより生成されたＮ（正整数）個の分割ファイルのうちＫ（Ｋ＜Ｎの正整数）個の分割ファイルを格納するローカルキャッシュと、前記オンラインストレージサービス及び前記ローカルキャッシュからデータを取得するマウントモジュールと、を有し、
    　前記方法は、
    　　前記マウントモジュールが、Ｉ／Ｏ要求に対応するデータを提供するために必要な分割ブロックの全てが前記ローカルキャッシュに存在するか判断し、前記必要な分割ブロックが存在する場合には該当する分割ブロックから前記ファイルＩ／Ｏ要求に対応するデータを取得するステップを含むことを特徴とする方法。
  9. 　請求項８において、さらに、前記マウントモジュールが、前記必要な分割ブロックの全てが前記ローカルキャッシュに存在しない場合には、前記オンラインストレージサービスにアクセスし、不足分の分割ブロックを取得して、前記ローカルキャッシュに格納するステップを含むことを特徴とする方法。
  10. 　請求項９において、
    　前記ローカルキャッシュは、さらに、前記オリジナルファイルのメタデータであって、前記オリジナルファイルを更新したか否かを示すファイル更新情報と、前記Ｎ個の分割ファイルの状態を示すビットマップ情報とを含むメタデータを格納し、
    　前記方法は、さらに、前記マウントモジュールが、前記Ｉ／Ｏ要求が書き込み要求であって、前記ローカルキャッシュに格納された前記Ｋ個の分割ファイルの少なくとも１つが更新された場合、前記ファイル更新情報及び前記更新された分割ファイルに対応する前記ビットマップ情報の両方を、更新したことを示す情報に設定するステップを含むことを特徴とする方法。
  11. 　請求項１０において、
    　前記メタデータは、さらに、前記メタデータを更新したか否かを示すメタデータ更新情報と、ファイルサイズを示すファイルサイズ情報を含み、
    　前記方法は、さらに、前記マウントモジュールが、前記Ｉ／Ｏ要求がファイルサイズ変更要求である場合、当該ファイルサイズ変更要求が対象ファイルの拡張要求か否か判断し、当該判断結果に基づいて前記ビットマップ情報を拡張処理或いは縮小処理し、前記ファイルサイズ情報を更新すると共に、前記メタデータ更新情報を、更新したことを示す情報に設定するステップを含むことを特徴とする方法。
  12. 　請求項８において、
    　前記ローカルキャッシュは、さらに、前記オリジナルファイルのメタデータを格納し、
    　前記方法は、さらに、前記マウントモジュールが、前記ローカルキャッシュに格納された前記分割データが更新された場合、更新処理のタイミングを定めたポリシ情報に従って、前記オンラインサービス上の前記オリジナルファイルと前記メタデータを更新するステップを含むことを特徴とする方法。
  13. 　請求項１２において、
    　前記メタデータは、メタ情報更新フラグ、ファイル更新フラグ、及び削除フラグを含み、
    　前記方法は、さらに、前記マウントモジュールが、前記ポリシ情報に従って、前記メタデータを参照し、前記オンラインストレージサービスにおける前記オリジナルファイルの削除、前記オリジナルファイルの内容の更新、前記メタデータを更新するステップを含むことを特徴とする方法。
  14. 　請求項１０において、
    　さらに、前記マウントモジュールが、更新処理のタイミングを定めたポリシ情報に従って、前記メタデータを参照し、前記更新された分割ファイルのみ前記オンラインストレージサービスにアップロードして、前記オリジナルファイルを更新するステップを含むことを特徴とする方法。
  15. 　コンピュータを請求項１に記載のファイルサーバ装置として機能させるためのプログラム。
PCT/JP2010/055795 2010-03-31 2010-03-31 ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム WO2011121746A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP10847629.2A EP2555118B1 (en) 2010-03-31 2010-03-31 File server apparatus, method of controlling storage system, and program
JP2011532450A JP5400889B2 (ja) 2010-03-31 2010-03-31 ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム
PCT/JP2010/055795 WO2011121746A1 (ja) 2010-03-31 2010-03-31 ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム
US13/257,708 US8595440B2 (en) 2010-03-31 2010-03-31 File server apparatus, management method of storage system, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/055795 WO2011121746A1 (ja) 2010-03-31 2010-03-31 ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム

Publications (1)

Publication Number Publication Date
WO2011121746A1 true WO2011121746A1 (ja) 2011-10-06

Family

ID=44711534

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/055795 WO2011121746A1 (ja) 2010-03-31 2010-03-31 ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム

Country Status (4)

Country Link
US (1) US8595440B2 (ja)
EP (1) EP2555118B1 (ja)
JP (1) JP5400889B2 (ja)
WO (1) WO2011121746A1 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016505964A (ja) * 2012-12-19 2016-02-25 ドロップボックス， インコーポレイテッド オンラインストレージシステムでのデータ同期化に関するアプリケーションプログラミングインタフェース
JP2016534607A (ja) * 2013-07-22 2016-11-04 インテリヴィジョン テクノロジーズ コーポレーション 拡張可能なビデオクラウドサービスのためのシステムおよび方法
KR20180016488A (ko) * 2015-06-08 2018-02-14 알리바바 그룹 홀딩 리미티드 액세스 방법 및 장치
CN110213643A (zh) * 2019-06-11 2019-09-06 北京奇艺世纪科技有限公司 一种流媒体缓存方法、装置及终端设备
CN110825703A (zh) * 2019-11-01 2020-02-21 浪潮云信息技术有限公司 一种基于定时任务实现文件***弹性伸缩的方法
US10979674B2 (en) 2013-07-22 2021-04-13 Intellivision Cloud-based segregated video storage and retrieval for improved network scalability and throughput
US11601620B2 (en) 2013-07-22 2023-03-07 Intellivision Technologies Corp. Cloud-based segregated video storage and retrieval for improved network scalability and throughput
WO2024075860A1 (ko) * 2022-10-05 2024-04-11 라쿠텐 심포니 코리아 주식회사 동영상 협업 서비스를 운용하기 위한 기술

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102999728B (zh) * 2012-11-27 2016-01-20 深圳市深信服电子科技有限公司 基于安全桌面的数据存储方法及装置
US9934241B2 (en) * 2013-03-05 2018-04-03 Hightail, Inc. System and method for cloud-based read-only folder synchronization
CN103135944B (zh) * 2013-03-12 2016-06-29 飞依诺科技(苏州)有限公司 扩充最大超声图像数据存储量的方法及***
CN104123385A (zh) * 2014-08-07 2014-10-29 肖龙旭 一种文件存储与管理方法
WO2016088237A1 (ja) * 2014-12-04 2016-06-09 富士通株式会社 配信方法、装置、及びプログラム
CN105183366B (zh) * 2015-07-08 2018-04-17 北京师范大学 基于预读缓写的数据分析处理方法及***
CN105426522A (zh) * 2015-12-07 2016-03-23 浪潮(北京)电子信息产业有限公司 一种文件***性能统计方法与***
US9870367B2 (en) * 2016-01-04 2018-01-16 Acronis International Gmbh System and method of using data blocks to optimize file storage

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07319750A (ja) * 1994-05-25 1995-12-08 Hitachi Ltd 分散ファイルシステムのキャッシュ管理方法
JPH1115720A (ja) * 1997-06-26 1999-01-22 Hitachi Ltd 高速ファイル入出力制御方法
JP2001318902A (ja) * 2000-05-09 2001-11-16 Matsushita Electric Ind Co Ltd キャッシュ装置
JP2006164211A (ja) 2004-11-12 2006-06-22 Nec Corp ストレージ管理システムと方法並びにプログラム
JP2007226596A (ja) 2006-02-24 2007-09-06 Hitachi Ltd 記憶制御装置及び記憶制御装置を用いたデータマイグレーション方法
JP2009110401A (ja) * 2007-10-31 2009-05-21 Hitachi Ltd ファイル共有システム及びファイル共有方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6842770B1 (en) * 2000-08-18 2005-01-11 Apple Computer, Inc. Method and system for seamlessly accessing remotely stored files
US20030061352A1 (en) 2001-09-27 2003-03-27 International Business Machines Corporation Optimized file cache organization in a network server
US8219752B1 (en) * 2008-03-31 2012-07-10 Amazon Technologies, Inc. System for caching data
US20100179973A1 (en) * 2008-12-31 2010-07-15 Herve Carruzzo Systems, methods, and computer programs for delivering content via a communications network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07319750A (ja) * 1994-05-25 1995-12-08 Hitachi Ltd 分散ファイルシステムのキャッシュ管理方法
JPH1115720A (ja) * 1997-06-26 1999-01-22 Hitachi Ltd 高速ファイル入出力制御方法
JP2001318902A (ja) * 2000-05-09 2001-11-16 Matsushita Electric Ind Co Ltd キャッシュ装置
JP2006164211A (ja) 2004-11-12 2006-06-22 Nec Corp ストレージ管理システムと方法並びにプログラム
JP2007226596A (ja) 2006-02-24 2007-09-06 Hitachi Ltd 記憶制御装置及び記憶制御装置を用いたデータマイグレーション方法
JP2009110401A (ja) * 2007-10-31 2009-05-21 Hitachi Ltd ファイル共有システム及びファイル共有方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GREGORY R. GANGER ET AL.: "Soft Updates: A Solution to the Metadata Update Problem in File Systems", ACM TRANSACTIONS ON COMPUTER SYSTEMS, vol. 18, no. 2, May 2000 (2000-05-01), pages 127 - 153, XP008150869 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016505964A (ja) * 2012-12-19 2016-02-25 ドロップボックス， インコーポレイテッド オンラインストレージシステムでのデータ同期化に関するアプリケーションプログラミングインタフェース
JP2016534607A (ja) * 2013-07-22 2016-11-04 インテリヴィジョン テクノロジーズ コーポレーション 拡張可能なビデオクラウドサービスのためのシステムおよび方法
US10979674B2 (en) 2013-07-22 2021-04-13 Intellivision Cloud-based segregated video storage and retrieval for improved network scalability and throughput
US11601620B2 (en) 2013-07-22 2023-03-07 Intellivision Technologies Corp. Cloud-based segregated video storage and retrieval for improved network scalability and throughput
KR20180016488A (ko) * 2015-06-08 2018-02-14 알리바바 그룹 홀딩 리미티드 액세스 방법 및 장치
KR102256890B1 (ko) 2015-06-08 2021-05-31 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 액세스 방법 및 장치
US11221997B2 (en) 2015-06-08 2022-01-11 Advanced New Technologies Co., Ltd. On-demand creation and access of a virtual file system
CN110213643A (zh) * 2019-06-11 2019-09-06 北京奇艺世纪科技有限公司 一种流媒体缓存方法、装置及终端设备
CN110825703A (zh) * 2019-11-01 2020-02-21 浪潮云信息技术有限公司 一种基于定时任务实现文件***弹性伸缩的方法
CN110825703B (zh) * 2019-11-01 2023-04-11 浪潮云信息技术股份公司 一种基于定时任务实现文件***弹性伸缩的方法
WO2024075860A1 (ko) * 2022-10-05 2024-04-11 라쿠텐 심포니 코리아 주식회사 동영상 협업 서비스를 운용하기 위한 기술

Also Published As

Publication number Publication date
EP2555118B1 (en) 2018-05-09
EP2555118A4 (en) 2013-09-18
JP5400889B2 (ja) 2014-01-29
US8595440B2 (en) 2013-11-26
US20120226869A1 (en) 2012-09-06
JPWO2011121746A1 (ja) 2013-07-04
EP2555118A1 (en) 2013-02-06

Similar Documents

Publication Publication Date Title
JP5400889B2 (ja) ファイルサーバ装置、及びストレージシステムの管理方法、並びにプログラム
US11593319B2 (en) Virtualized data storage system architecture
JP5485866B2 (ja) 情報管理方法、及び情報提供用計算機
US9875029B2 (en) Network-attached storage enhancement appliance
CN102667772B (zh) 文件级分级存储管理***、方法和设备
US8799414B2 (en) Archiving data for a distributed filesystem
JP4349301B2 (ja) ストレージ管理システムと方法並びにプログラム
US8799413B2 (en) Distributing data for a distributed filesystem across multiple cloud storage systems
US8805968B2 (en) Accessing cached data from a peer cloud controller in a distributed filesystem
US8135677B2 (en) File management system and method
US8805967B2 (en) Providing disaster recovery for a distributed filesystem
CN106021381A (zh) 一种云存储服务***的数据访问/存储方法及装置
JP5445463B2 (ja) 計算機システム、データ保存方法およびプログラム
US20120042130A1 (en) Data Storage System
JP2013524358A (ja) 情報処理システムの管理方法、及びデータ管理計算機システム
JP2008090378A (ja) ハイブリッドファイルシステム、オペレーティングシステム、キャッシュ制御方法および記録媒体
CN109983452A (zh) 用于连续可用的网络文件***(nfs)状态数据的***和方法
US20230006814A1 (en) Method and apparatus for implementing changes to a file system that is emulated with an object storage system
US11269735B2 (en) Methods and systems for performing data backups
JP5428455B2 (ja) 仮想マシンサーバ、仮想マシン制御方法及び仮想マシン制御プログラム
KR100952599B1 (ko) 로컬디스크를 캐쉬로 이용하는 사용자 컴퓨터, 그를이용하는 방법 및 하이브리드 네트워크 스토리지 시스템
Hwang et al. Analysis of NDN repository architecture and its improvement for I/O intensive applications
JP2018173768A (ja) ネットワークストレージシステム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2011532450

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 13257708

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2010847629

Country of ref document: EP

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

Ref document number: 10847629

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE