JP2017123040A - Server device, distribution file system, distribution file system control method, and program - Google Patents

Server device, distribution file system, distribution file system control method, and program Download PDF

Info

Publication number
JP2017123040A
JP2017123040A JP2016001571A JP2016001571A JP2017123040A JP 2017123040 A JP2017123040 A JP 2017123040A JP 2016001571 A JP2016001571 A JP 2016001571A JP 2016001571 A JP2016001571 A JP 2016001571A JP 2017123040 A JP2017123040 A JP 2017123040A
Authority
JP
Japan
Prior art keywords
file
directory
server
name
detailed information
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2016001571A
Other languages
Japanese (ja)
Other versions
JP6607044B2 (en
Inventor
大谷　敦久
Atsuhisa Otani
敦久 大谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2016001571A priority Critical patent/JP6607044B2/en
Publication of JP2017123040A publication Critical patent/JP2017123040A/en
Application granted granted Critical
Publication of JP6607044B2 publication Critical patent/JP6607044B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

PROBLEM TO BE SOLVED: To allow a client device to efficiently specify an access target server device in a system having even file data and even meta data distributedly arranged in a plurality of server devices, and enable efficient access when a lot of requests focuses on a specific server device.SOLUTION: A server device managing directories where files exist is configured to: receive a file handle of an open target file, and a request of file detail information with the file handle and request combined into one; and simultaneously process the file handle and request. In this instance, the server device is configured to cache the file detail information on a memory. When receiving the request equal to or greater than a prescribed threshold, the server device is configured to stop combining the requests into one request for processing. In this instance, the client device is configured to individually transmit the request of the file detail information to the server device managing the file.SELECTED DRAWING: Figure 2

Description

本発明は、サーバー装置、分散ファイルシステム、分散ファイルシステム制御方法、および、プログラム、特に、多数の計算ノードにより構成される並列計算機または分散処理環境において使用されるサーバー装置、分散ファイルシステム、分散ファイルシステム制御方法、および、プログラムに関する。   The present invention relates to a server device, a distributed file system, a distributed file system control method, and a program, in particular, a server device, a distributed file system, and a distributed file used in a parallel computer or a distributed processing environment configured by a large number of computing nodes. The present invention relates to a system control method and a program.

特許文献１には、ネットワークを介して接続された複数のストレージサーバー装置から構成される分散ファイル管理システムにおいて、ファイルやディレクトリを分散して管理する方法が記載されている。   Patent Document 1 describes a method for distributing and managing files and directories in a distributed file management system composed of a plurality of storage server devices connected via a network.

特許文献２には、階層ディレクトリ構造における各ディレクトリ、例えば、／，usr,bin, tmp,xxx, yyy, zzzの情報を、ディレクトリ名称(識別名)によって決定される計算機に分散して保存する分散ファイルシステムのディレクトリ管理方法が記載されている。本文献の段落００１９は、ディレクトリ情報を階層ディレクトリ構造と関係なくバラして各計算機に分散保存するから、アクセスが１つの計算機に集中せず負荷分散でき、システムの性能が低下しないとしている。   In Patent Document 2, information on each directory in a hierarchical directory structure, for example, information on /, usr, bin, tmp, xxx, yyy, zzz is distributed and stored in computers determined by directory names (identification names). A file system directory management method is described. Paragraph 0019 of this document states that directory information is distributed regardless of the hierarchical directory structure and distributed and stored in each computer, so that access is not concentrated on one computer and load can be distributed, and system performance is not deteriorated.

特許文献３には、サーバーの負荷に応じてI/O（Input / Output）処理プロセスを増減させる方法が記述されている。つまり、I/O要求が増加傾向か、減少傾向にあるかをその傾きから予測することによりプロセスの増減を実施する。   Patent Document 3 describes a method of increasing / decreasing an I / O (Input / Output) processing process according to a load on a server. In other words, the process is increased or decreased by predicting from the inclination whether the I / O request is increasing or decreasing.

非特許文献１には、メタデータサーバーを持たない分散ファイルシステムが記載されている。この分散ファイルシステムの各サーバーへの分散方法は、概ね以下のように動作する。まず、分散ハッシュテーブルのハッシュ値の範囲（例：０〜２32 −１）を各サーバーへ均等に割り当てる。次に、ファイルのオープンの際、与えられたファイルのパス名からハッシュ値を計算する。そして、そのハッシュ値を含む範囲に割り当てられたサーバーを目的のファイルが存在するサーバーであると決定する。 Non-Patent Document 1 describes a distributed file system that does not have a metadata server. The method of distributing the distributed file system to each server generally operates as follows. First, a range of hash values (for example, 0 to 2 32 −1) in the distributed hash table is equally allocated to each server. Next, when opening the file, the hash value is calculated from the path name of the given file. Then, it is determined that the server assigned to the range including the hash value is the server where the target file exists.

特許第５３６７４７０号公報Japanese Patent No. 5367470 特開平５−２３３４１号公報Japanese Patent Laid-Open No. 5-23341 特許第４０８９５０６号公報Japanese Patent No. 4089506

http://gluster.readthedocs.org/en/latest/Quick-Start-Guide/Architecture/ http://www.gluster.org/community/documentation/index.php/GlusterFS_Conceptshttp://gluster.readthedocs.org/en/latest/Quick-Start-Guide/Architecture/ http://www.gluster.org/community/documentation/index.php/GlusterFS_Concepts

特許文献１が開示するファイルやディレクトリの分散管理方法には、以下の問題がある。   The distributed management method of files and directories disclosed in Patent Document 1 has the following problems.

第１に、キャッシュ蓄積部（メタデータキャッシュ）は、ストレージサーバー装置にしか存在しない（図２２）。このため、指定されたパス名の中のすべてのディレクトリ、ファイルのメタデータがキャッシュされている場合でも、ユーザ端末装置（クライアント）とストレージサーバー装置の間で通信が最低１回は発生する。   First, the cache storage unit (metadata cache) exists only in the storage server device (FIG. 22). For this reason, even when the metadata of all directories and files in the specified path name is cached, communication occurs at least once between the user terminal device (client) and the storage server device.

第２に、各ストレージサーバー装置は、各ユーザの利用できるディレクトリ配下についてそれぞれキャッシュを持つことになると考えられる。このため、ストレージサーバー装置のキャッシュ蓄積部には、多数のユーザが同時に利用するマルチユーザ環境において、ユーザ数を考慮した大容量の記憶域が必要になる。したがって、システム価格が増加する、あるいは、キャッシュの容量不足により期待した効果が得られない可能性が考えられる。   Second, it is considered that each storage server device has a cache under a directory available to each user. For this reason, the cache storage unit of the storage server device requires a large-capacity storage area in consideration of the number of users in a multi-user environment that is used by many users simultaneously. Therefore, the system price may increase, or the expected effect may not be obtained due to insufficient cache capacity.

第３に、パス名中にディレクトリが複数ある場合、ユーザ端末装置が応答を得るまでに複数回のストレージサーバー装置間の通信が必要になり、OneHop方式（段落００２８）とは言えない。   Thirdly, when there are a plurality of directories in the path name, a plurality of times of communication between the storage server devices are required before the user terminal device obtains a response, which cannot be said to be the OneHop method (paragraph 0028).

第４に、段落００２１には、ユーザ利用ファイル名に分割されたデータファイルの番号が付加され、データファイルの番号に対応したデータファイルのファイル名を出力する旨、及び、ユーザ利用ファイルを複数のデータファイルに分割して複数のストレージサーバー装置において分散して記憶する旨が記載されている。この方法では、ユーザ利用ファイル名がユーザによって変更された場合、データファイルは各ストレージサーバー装置に分散されているため、新たな名前を反映させるために複数回のサーバー間通信が必要となると考えられる。   Fourth, in the paragraph 0021, the number of the data file divided into the user use file name is added, and the file name of the data file corresponding to the data file number is output. It is described that the data files are divided and stored in a plurality of storage server devices. In this method, when the file name used by the user is changed by the user, the data file is distributed to each storage server device. Therefore, it is considered that multiple server-to-server communications are required to reflect the new name. .

第５に、段落００８４以降の記載によると、read/writeのリクエストの処理の延長で、パス検索を行うと解釈できる。つまり、ファイルのオープンにおいて行われるパス検索の処理がread/write処理に含まれるため、その分I/O性能に影響する。また、read/writeシステムコールのインターフェースが規格と異なるため、POSIX（Portable Operating System Interface for UNIX）に準拠していないと考えられる。   Fifth, according to the description after paragraph 0084, it can be interpreted that the path search is performed by extending the processing of the read / write request. In other words, the path search process that is performed when the file is opened is included in the read / write process, which affects the I / O performance accordingly. In addition, since the interface of the read / write system call is different from the standard, it is considered that it does not conform to POSIX (Portable Operating System Interface for UNIX).

最後に、ユーザ端末装置がリクエストを送信する際、どのストレージサーバー装置へ送信するかをどのように決定するのかが不明瞭である。このため、以前に検索を実行しキャッシュが存在するストレージサーバー装置があったとしても、そのストレージサーバー装置以外のストレージサーバー装置へリクエストを送信し、最初からパス検索することが必要になる可能性があり、有効にキャッシュが機能するとは限らない。   Finally, when the user terminal device transmits a request, it is unclear how to determine which storage server device to transmit. For this reason, even if there is a storage server device that has been searched before and has a cache, it may be necessary to send a request to a storage server device other than the storage server device and perform a path search from the beginning. Yes, the cache does not always function effectively.

特許文献２が開示する分散ファイルシステムのディレクトリ管理方法は、ディレクトリ名称(識別名)によって保存先の計算機を決める。この方法では、段落００２０のようなハッシュや名前の代わりにID（Identification）を利用する方法などを加味しても、分散のされ方に偏りが出る可能性を否定できない。特に、段落００１５、００２１のような名称の最初の一文字で保存先の計算機を決める分散方法では、分散のされ方に偏りが出る可能性が高い。例えば、分散方法が、アルファベットａ〜ｍで始まる名称を有するディレクトリは計算機１１ａに配置するという場合、abc1, abc2, …, abc1000という名称に同時にアクセスされると、すべて同一の計算機１１ａに要求が集中するという不都合が起きる。   In the directory management method of the distributed file system disclosed in Patent Document 2, a storage destination computer is determined by a directory name (identification name). In this method, even if a method of using ID (Identification) instead of a hash or name as in paragraph 0020 is added, the possibility that the distribution is biased cannot be denied. In particular, in the distribution method in which the storage destination computer is determined by the first character of the name as in paragraphs 0015 and 0021, there is a high possibility that the distribution method is biased. For example, when a directory having a name beginning with alphabets a to m is arranged in the computer 11a, if the names abc1, abc2,..., Abc1000 are accessed simultaneously, the requests are concentrated on the same computer 11a. Inconvenience occurs.

また、ディレクトリ名称の変更において、不都合が生じたり、煩雑な処理が必要となったりすることが考えられる。   In addition, it is conceivable that a change in the directory name may cause inconvenience or complicated processing.

さらに、特許文献２の方法は、計算機が要求されたディレクトリ情報を記憶していない場合には、該ディレクトリ情報をサーバーに問い合わせる（段落００１３、図４）。この方法は、同一サーバーに処理が集中する可能性が有るだけではなく、ファイルシステムを構成するサーバーと計算機の合計台数が多くなりコスト高となる。   Furthermore, in the method of Patent Document 2, when the computer does not store the requested directory information, the server is inquired about the directory information (paragraph 0013, FIG. 4). This method not only has a possibility that processing is concentrated on the same server, but also increases the total number of servers and computers that constitute the file system, resulting in high costs.

非特許文献１が開示するハッシュによる分散方法は、以下のような問題点がある。   The hash distribution method disclosed in Non-Patent Document 1 has the following problems.

まず、非特許文献１には、ファイル名が変更された場合、新たな名前に基づくハッシュ値から決まるサーバーにポインターファイルを置き、実際にファイルのデータが存在するサーバーを指し示すとある。つまり、ファイル名変更後は、該ファイルへのアクセス時に通常とは異なる処理が必要となり、その分余計なオーバーヘッドが生じることになる。ファイル名の変更は、エンドユーザが通常行う操作であり、処理効率低下、処理遅延が懸念される。   First, in Non-Patent Document 1, when a file name is changed, a pointer file is placed on a server determined from a hash value based on a new name, and the server where the file data actually exists is indicated. In other words, after the file name is changed, processing different from normal is required when accessing the file, and extra overhead is generated accordingly. Changing the file name is an operation that is normally performed by an end user, and there is a concern about a decrease in processing efficiency and processing delay.

さらに、ハードリンク（異なる名前で同一ファイルにアクセスするためのリンク機構）への対応が困難であり、また多数のファイルの生成において、ある範囲のハッシュ値が多数出現する可能性もある。   Furthermore, it is difficult to cope with hard links (link mechanisms for accessing the same file with different names), and a large number of hash values in a certain range may appear in the generation of a large number of files.

特許文献３が開示するI/O処理プロセスの増減は、プロセスの生成、終了という比較的重いとされる処理を伴うため、この処理によりCPU(Central Processing Unit)資源を使用することで、本来のクライアントから要求された処理を邪魔してしまう可能性が有る。   The increase / decrease in the I / O processing process disclosed in Patent Document 3 involves a relatively heavy process of generating and ending the process. Therefore, by using a CPU (Central Processing Unit) resource for this process, There is a possibility of interrupting the processing requested by the client.

上記の問題に対処するために、本発明にかかるファイルシステムは、ファイルのデータだけではなく、ファイルの位置情報などファイルシステムを管理するメタデータも複数のサーバー配下に分散させて配置することでメタデータサーバーを用いない構成とする。そのうえで、計算ノード（ファイルシステムのクライアント）が、複数のサーバーの中からアクセス対象のファイルが存在するサーバーを特定する為の手段を備える。   In order to cope with the above-described problem, the file system according to the present invention distributes not only file data but also metadata for managing the file system such as file location information under a plurality of servers. The configuration does not use a data server. In addition, the calculation node (client of the file system) includes means for specifying a server in which a file to be accessed exists from among a plurality of servers.

ただし、このシステムにはメタデータサーバーのようなサーバーが存在しないため、クライアントは特定のサーバーに問い合わせることはできない。このため、ファイルシステムの最上位のディレクトリを管理するルートサーバーを設定する。そして、例えばファイルのオープン処理（open システムコール）に際して、指定されたパス名に基づき、クライアント主導で、パス名中の各ディレクトリを管理するサーバーを、ルートサーバーから順に辿って特定することとした。   However, since there is no server such as a metadata server in this system, the client cannot query a specific server. Therefore, a root server that manages the top directory of the file system is set. Then, for example, in the file open process (open system call), the server that manages each directory in the path name is identified by tracing from the root server in the order of the client based on the specified path name.

従って、本発明にかかるシステムにおいては、クライアントが、如何に効率的にアクセス対象のファイルやディレクトリが格納されているサーバーを特定できる手段を用意するかが最初の課題となる。特に、ディレクトリ名や、ファイル名を元にした（ハッシュなどの）方法によりサーバーを特定するのではなく、より偏りが起き難い方法で各サーバーへ分散させる場合であっても、効率的にアクセス対象のファイルやディレクトリが格納されているサーバーを特定することが課題となる。   Therefore, in the system according to the present invention, the first problem is how to prepare a means by which a client can specify a server storing a file or directory to be accessed efficiently. In particular, instead of specifying servers by a method based on directory names or file names (such as hashes), even if they are distributed to each server in a way that is less prone to bias, they can be accessed efficiently The problem is to identify the server where the files and directories are stored.

一方、多数の計算ノードがあると、ファイルオープンの処理などにおいて、ほぼ同時にディレクトリ配下のファイルにアクセスが集中することで、特定のサーバーにリクエストが集中し、クライアントへの応答が遅延してTAT（Turn Around Time）が増大する可能性がある。したがって、多数のリクエストが特定のサーバーに集中した際の効率化がさらなる課題となる。   On the other hand, when there are a large number of compute nodes, the access to the files under the directory is concentrated almost simultaneously in file open processing, etc., so that requests concentrate on a specific server, and the response to the client is delayed, causing TAT ( Turn Around Time) may increase. Therefore, the efficiency when a large number of requests are concentrated on a specific server becomes a further problem.

本発明にかかる分散ファイルシステム等は、ファイルを多数のクライアント装置がほぼ同時にオープンする場合、１）対象ファイルが存在するディレクトリを管理するサーバー装置へのオープン対象ファイルのファイルハンドルなどのリクエストと、対象ファイルを管理するサーバーへのファイル詳細情報のリクエストを１つにまとめる。これにより、サーバー装置が、両リクエストを同時に処理できるようにする。この際、２）ファイル詳細情報を対象ファイルが存在するディレクトリを管理するサーバーのメモリ上にキャッシュすることで、サーバー装置間の通信を削減する。   In the distributed file system according to the present invention, when a large number of client devices open a file almost simultaneously, 1) a request such as a file handle of an open target file to a server device that manages a directory in which the target file exists, and a target Combine requests for detailed file information from the server that manages the file into one. This allows the server device to process both requests simultaneously. At this time, 2) communication between server apparatuses is reduced by caching the detailed file information on the memory of the server that manages the directory where the target file exists.

さらに、同一ディレクトリ配下の異なるファイルのオープンの場合で、３）ほぼ同時に所定閾値以上のリクエストを受信した場合は、処理待ちが発生してＴＡＴが悪化することを防ぐため、上記１）のようにリクエストを１つにまとめて処理することを止める。この場合は、クライアント装置が、個別にファイル詳細情報のリクエストを、ファイルを管理するサーバー装置に送信することで効率化する。   Furthermore, in the case of opening different files under the same directory, 3) When requests exceeding a predetermined threshold are received almost simultaneously, in order to prevent TAT from deteriorating due to waiting for processing, as in 1) above Stop processing requests together. In this case, the efficiency is improved by the client device individually sending a request for file detailed information to the server device that manages the file.

以上、１）乃至３）を反映して、本発明の実施の形態のサーバー装置等は、以下のように構成される。   Reflecting the above 1) to 3), the server device and the like according to the embodiment of the present invention are configured as follows.

本発明の１実施の形態のサーバー装置は、
ファイルを記憶するファイルデータ記憶装置と、ディレクトリ階層における直下のディレクトリ、または、ファイルの、ａ）識別子であって、当該ディレクトリ、または、当該ファイルを管理するサーバー装置の識別情報であるサーバーIDを含むファイルハンドル（以降、ＦＨと略記）、ｂ）名前、および、ｃ）ファイルまたはディレクトリの区別を示すファイルタイプを関連付けて記憶するディレクトリ、および、前記ファイルデータ記憶装置に記憶されているファイルのファイル詳細情報を記憶するメタデータ記憶装置と、に接続され、
ファイル詳細情報のキャッシュ用メモリ領域であるファイル詳細情報表と、
クライアント装置、若しくは、他の前記サーバー装置から処理リクエストを受信、または、他の前記サーバー装置にリクエストを送信するとともに、処理中または送信中のリクエスト数をカウントする通信部と、
ファイルのＦＨを入力されると、ＦＨが包含するサーバーIDの前記サーバー装置にファイル詳細情報を要求するリクエストを送信して、ファイル詳細情報を受信するファイル詳細情報問い合わせ部と、
クライアント装置から、ディレクトリ階層における直下のファイルの名前を含む、１）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、２）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストが受信されたとき、ａ）前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のファイルのＦＨとファイルタイプを取得し、ｂ１）前記通信部がカウントしたリクエスト数が所定閾値を超えておらず、ｃ１）受信された名前のファイルのファイル詳細情報が前記ファイル詳細情報表にキャッシュされていれば、キャッシュされているファイル詳細情報を取得し、ｃ２）前記ファイル詳細情報表にキャッシュされていなければ、取得したファイルのＦＨを前記ファイル詳細情報問い合わせ部に入力してファイル詳細情報を取得して、前記ファイル詳細情報表にキャッシュし、取得したファイルのＦＨ、ファイルタイプとファイル詳細情報とを前記クライアント装置に返信し、ｂ２）前記通信部がカウントしたリクエスト数が所定閾値を超えている場合は、入力されたリクエストを変更してファイル詳細情報の出力を中止し、取得したファイルのＦＨ、ファイルタイプを前記クライアント装置に返信し、
また、前記サーバー装置から返信されたファイルのＦＨを、改めてファイルを管理する前記サーバー装置に送信する前記クライアント装置から、または、他の前記サーバー装置の前記ファイル詳細情報問い合わせ部から、前記ファイルデータ記憶装置に記憶されているファイル、のＦＨを含むリクエストが受信されると、前記メタデータ記憶装置から、入力されたＦＨを識別子とするファイルのファイル詳細情報を取得して返信するディレクトリエントリ参照／更新部と、を備える。 A server device according to an embodiment of the present invention includes:
A) an identifier of a file data storage device for storing a file and a directory or file immediately below in the directory hierarchy, including a server ID that is identification information of the directory or server device that manages the file File handle (hereinafter abbreviated as FH), b) name, and c) directory storing the file type indicating the distinction between the file or directory in association with each other, and the file details of the file stored in the file data storage device A metadata storage device for storing information, and
A file detailed information table that is a memory area for caching file detailed information;
A communication unit that receives a processing request from a client device or another server device or transmits a request to another server device, and counts the number of requests being processed or being transmitted;
When an FH of a file is input, a file detailed information inquiry unit that transmits a request for requesting file detailed information to the server device having a server ID included in the FH and receives the file detailed information;
When a request is received from the client device that includes the name of the file immediately below in the directory hierarchy, 1) a request for the FH and file type of the file, and 2) a request that combines the requests for the file detailed information. A) obtaining the FH and file type of the file with the input name from the directory stored in the metadata storage device; b1) the number of requests counted by the communication unit does not exceed a predetermined threshold; c1) If the file detailed information of the file with the received name is cached in the file detailed information table, the cached file detailed information is obtained. c2) If the file detailed information is not cached in the file detailed information table, The FH of the acquired file is the file detailed information inquiry section. Input and acquire file detailed information, cache it in the file detailed information table, return the FH, file type and file detailed information of the acquired file to the client device, b2) Requests counted by the communication unit If the number exceeds the predetermined threshold, the input request is changed to stop outputting the file detailed information, and the FH and file type of the acquired file are returned to the client device.
Further, the file data storage is sent from the client device that transmits the FH of the file returned from the server device to the server device that manages the file again or from the file detailed information inquiry unit of another server device. When a request including the FH of the file stored in the device is received, the detailed file information of the file having the input FH as an identifier is obtained from the metadata storage device and returned, and the directory entry is referred / updated. A section.

また、本発明の１実施の形態の分散ファイルシステムの制御方法は、
ファイルを記憶するファイルデータ記憶装置と、
ディレクトリ階層における直下のディレクトリ、または、ファイルの、ａ）識別子であって、当該ディレクトリ、または、当該ファイルを管理するサーバー装置の識別情報であるサーバーIDを含むファイルハンドル（以降、ＦＨと略記）、ｂ）名前、および、ｃ）ファイルまたはディレクトリの区別を示すファイルタイプを関連付けて記憶するディレクトリ、および、前記ファイルデータ記憶装置に記憶されているファイルのファイル詳細情報を記憶するメタデータ記憶装置と、に接続され、ファイル詳細情報のキャッシュ用メモリ領域であるファイル詳細情報表を備える前記サーバー装置が、
クライアント装置、若しくは、他の前記サーバー装置から処理リクエストを受信、または、他の前記サーバー装置にリクエストを送信するとともに、処理中または送信中のリクエスト数をカウントし、
クライアント装置から、ディレクトリ階層における直下のファイルの名前を含む、１）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、２）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストを受信すると、ａ）前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のファイルのＦＨとファイルタイプを取得し、ｂ１）カウントしたリクエスト数が所定閾値を超えておらず、ｃ１）受信された名前のファイルのファイル詳細情報が前記ファイル詳細情報表にキャッシュされていれば、キャッシュされているファイル詳細情報を取得し、ｃ２）前記ファイル詳細情報表にキャッシュされていなければ、取得したファイルのＦＨを含むリクエストを、当該ＦＨが包含するサーバーIDの前記サーバー装置に送信してファイル詳細情報を取得して、前記ファイル詳細情報表にキャッシュし、取得したファイルのＦＨ、ファイルタイプとファイル詳細情報とを前記クライアント装置に返信し、ｂ２）カウントしたリクエスト数が所定閾値を超えている場合は、入力されたリクエストを変更してファイル詳細情報の出力を中止し、取得したファイルのＦＨ、ファイルタイプを前記クライアント装置に返信し、
また、ファイルのＦＨを、改めてファイルを管理する前記サーバー装置に送信する前記クライアント装置から、または、他の前記サーバー装置から、前記ファイルデータ記憶装置に記憶されているファイル、のＦＨを含むリクエストを受信すると、前記メタデータ記憶装置から、入力されたＦＨを識別子とするファイルのファイル詳細情報を取得して返信する。 The control method of the distributed file system according to the embodiment of the present invention is as follows:
A file data storage device for storing files;
A) a file handle (hereinafter abbreviated as FH) including a server ID which is an identifier of a directory or file immediately below in the directory hierarchy and is an identification information of the server device managing the directory or the file; a metadata storage device for storing b) a name and c) a directory for storing a file type indicating a distinction between files or directories in association with each other, and a file detailed information of the file stored in the file data storage device; And the server device comprising a file detailed information table that is a memory area for caching file detailed information,
Receive processing requests from client devices or other server devices, or send requests to other server devices, and count the number of requests being processed or being transmitted,
When a request including the name of the file immediately below in the directory hierarchy is received from the client device, 1) a request for the FH and file type of the file, and 2) a request for the file detailed information, ) Obtain the FH and file type of the file with the input name from the directory stored in the metadata storage device, b1) The number of requests counted does not exceed the predetermined threshold, and c1) the received name If the file detailed information of the file is cached in the file detailed information table, the cached file detailed information is acquired. C2) If the file detailed information is not cached in the file detailed information table, the FH of the acquired file is obtained. The server ID included in the FH The file detailed information is acquired by transmitting to the server device, cached in the file detailed information table, the FH, file type and file detailed information of the acquired file are returned to the client device, and b2) the counted requests If the number exceeds the predetermined threshold, the input request is changed to stop outputting the file detailed information, and the FH and file type of the acquired file are returned to the client device.
Further, a request including the FH of the file stored in the file data storage device is sent from the client device that transmits the FH of the file to the server device that manages the file again or from another server device. Upon receipt, the detailed file information of the file having the input FH as an identifier is obtained from the metadata storage device and returned.

また、本発明の１実施の形態のプログラムは、
ファイルを記憶するファイルデータ記憶装置と、
ディレクトリ階層における直下のディレクトリ、または、ファイルの、ａ）識別子であって、当該ディレクトリ、または、当該ファイルを管理するコンピュータの識別情報であるサーバーIDを含むファイルハンドル（以降、ＦＨと略記）、ｂ）名前、および、ｃ）ファイルまたはディレクトリの区別を示すファイルタイプを関連付けて記憶するディレクトリ、および、前記ファイルデータ記憶装置に記憶されているファイルのファイル詳細情報を記憶するメタデータ記憶装置と、に接続され、ファイル詳細情報のキャッシュ用メモリ領域であるファイル詳細情報表を備える前記コンピュータに、
クライアント装置、若しくは、他の前記コンピュータから処理リクエストを受信、または、他の前記コンピュータにリクエストを送信するとともに、処理中または送信中のリクエスト数をカウントし、
クライアント装置から、ディレクトリ階層における直下のファイルの名前を含む、１）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、２）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストを受信すると、ａ）前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のファイルのＦＨとファイルタイプを取得し、ｂ１）カウントしたリクエスト数が所定閾値を超えておらず、ｃ１）受信された名前のファイルのファイル詳細情報が前記ファイル詳細情報表にキャッシュされていれば、キャッシュされているファイル詳細情報を取得し、ｃ２）前記ファイル詳細情報表にキャッシュされていなければ、取得したファイルのＦＨを含むリクエストを、当該ＦＨが包含するサーバーIDの前記コンピュータに送信してファイル詳細情報を取得して、前記ファイル詳細情報表にキャッシュし、取得したファイルのＦＨ、ファイルタイプとファイル詳細情報とを前記クライアント装置に返信し、ｂ２）カウントしたリクエスト数が所定閾値を超えている場合は、入力されたリクエストを変更してファイル詳細情報の出力を中止し、取得したファイルのＦＨ、ファイルタイプを前記クライアント装置に返信し、
また、ファイルのＦＨを、改めてファイルを管理する前記コンピュータに送信する前記クライアント装置から、または、他の前記コンピュータから、前記ファイルデータ記憶装置に記憶されているファイル、のＦＨを含むリクエストを受信すると、前記メタデータ記憶装置から、入力されたＦＨを識別子とするファイルのファイル詳細情報を取得して返信する、処理を実行させる。 The program according to the embodiment of the present invention is
A file data storage device for storing files;
A) a file handle (hereinafter abbreviated as FH) that includes a server ID, which is an identifier of a directory or file immediately under the directory hierarchy, and is identification information of the directory or computer that manages the file, b A) a name, and c) a directory that associates and stores a file type indicating a distinction between a file or a directory, and a metadata storage device that stores file detailed information of the file stored in the file data storage device. Connected to the computer comprising a file detailed information table that is a memory area for caching file detailed information;
Receive a processing request from a client device or another computer, or send a request to the other computer, and count the number of requests being processed or transmitted,
When a request including the name of the file immediately below in the directory hierarchy is received from the client device, 1) a request for the FH and file type of the file, and 2) a request for the file detailed information, ) Obtain the FH and file type of the file with the input name from the directory stored in the metadata storage device, b1) The number of requests counted does not exceed the predetermined threshold, and c1) the received name If the file detailed information of the file is cached in the file detailed information table, the cached file detailed information is acquired. C2) If the file detailed information is not cached in the file detailed information table, the FH of the acquired file is obtained. The server ID included in the FH The file detailed information is acquired by transmitting to the computer, cached in the file detailed information table, the FH, file type and file detailed information of the acquired file are returned to the client device, b2) the number of requests counted Is over the predetermined threshold, the input request is changed, the output of the file detailed information is stopped, the FH and file type of the acquired file are returned to the client device,
When a request including the FH of the file stored in the file data storage device is received from the client device that transmits the FH of the file to the computer that manages the file again or from another computer. Then, the process of acquiring and returning the file detailed information of the file having the input FH as an identifier from the metadata storage device is executed.

本発明にかかるサーバー装置は、メタデータも複数のサーバー装置に分散配置されている分散ファイルシステムにおいて、クライアント装置による効率的なアクセス対象サーバー装置の特定、および、多数のリクエストが特定のサーバー装置に集中した際の効率的なアクセスを可能とする。   The server device according to the present invention is a distributed file system in which metadata is also distributed and distributed to a plurality of server devices. The client device efficiently specifies a server device to be accessed and a large number of requests are assigned to a specific server device. Enables efficient access when concentrated.

図１は、第１の実施の形態にかかる分散ファイルシステム５の概要を示す構成図である。FIG. 1 is a configuration diagram showing an overview of a distributed file system 5 according to the first embodiment. 図２は、第１の実施の形態にかかるクライアント装置、サーバー装置、および、外部記憶装置の内部構成を示す図である。FIG. 2 is a diagram illustrating an internal configuration of the client device, the server device, and the external storage device according to the first embodiment. 図３は、メタデータとサーバー装置との階層関係を表す概念図である。FIG. 3 is a conceptual diagram showing a hierarchical relationship between the metadata and the server device. 図４は、ファイルのオープン、リードにおけるディレクトリ探索、リード要求の送信／応答の様子を示す図である（その１）。FIG. 4 is a diagram showing a state of file open, directory search in read, and read request transmission / response (part 1). 図５は、ファイルのオープン、リードにおけるディレクトリ探索、リード要求の送信／応答の様子を示す図である（その２）。FIG. 5 is a diagram showing the state of file open, directory search in read, and read request transmission / response (part 2). 図６は、ファイルのオープン、リードにおけるディレクトリ探索、リード要求の送信／応答の様子を示す図である（その３）。FIG. 6 is a diagram showing a state of file opening, directory search in reading, and transmission / response of a read request (part 3). 図７は、クライアント装置側のファイルオープン処理の動作例のフローチャートである（その１）。FIG. 7 is a flowchart of an operation example of file open processing on the client device side (No. 1). 図８は、クライアント装置側のファイルオープン処理の動作例のフローチャートである（その２）。FIG. 8 is a flowchart of an operation example of file open processing on the client device side (No. 2). 図９は、サーバー装置側のファイルオープン処理の動作例のフローチャートである（その１）。FIG. 9 is a flowchart of an operation example of file open processing on the server device side (No. 1). 図１０は、サーバー装置側のファイルオープン処理の動作例のフローチャートである（その２）。FIG. 10 is a flowchart of an operation example of file open processing on the server device side (No. 2). 図１１は、サーバー装置側のファイルオープン処理の動作例のフローチャートである（その３）。FIG. 11 is a flowchart of an operation example of file open processing on the server device side (No. 3). 図１３は、上位ディレクトリ管理サーバー装置側のファイル、ディレクトリ生成処理の動作例のフローチャートである。FIG. 13 is a flowchart of an operation example of file and directory generation processing on the upper directory management server apparatus side. 図１３は、生成サーバー装置側のファイル、ディレクトリ生成処理の動作例のフローチャートである。FIG. 13 is a flowchart of an operation example of file and directory generation processing on the generation server device side. 図１４は、クライアント装置側のマウント処理の動作例のフローチャートである。FIG. 14 is a flowchart of an operation example of mount processing on the client device side. 図１５は、サーバー装置側のマウント処理の動作例のフローチャートである。FIG. 15 is a flowchart of an operation example of mount processing on the server device side. 図１６は、コンピュータ装置の構成図である。FIG. 16 is a configuration diagram of the computer apparatus.

＜第１の実施の形態＞
＜概要＞
図１は、本実施の形態にかかる分散ファイルシステム５の概要を示す構成図である。分散ファイルシステム５においては、図１が示すように、例えば複数の計算ノードであるクライアント装置１（以降、クライアント１と略記）が相互結合ネットワーク３に接続されており、ユーザのジョブを実行する。また、例えば複数のサーバー装置２（以降、サーバー２と略記）も同じ相互結合ネットワーク３に接続されており、任意のクライアント１とサーバー２の間、及び、任意のサーバー２同士間の通信が可能となっている。各サーバー２の配下には少なくとも１台の外部記憶装置４が接続される。 <First Embodiment>
<Overview>
FIG. 1 is a configuration diagram showing an overview of a distributed file system 5 according to the present embodiment. In the distributed file system 5, as shown in FIG. 1, for example, a client device 1 (hereinafter abbreviated as a client 1), which is a plurality of computing nodes, is connected to the interconnection network 3, and executes a user job. Further, for example, a plurality of server apparatuses 2 (hereinafter abbreviated as “server 2”) are also connected to the same interconnection network 3, and communication between any client 1 and server 2 and between any server 2 is possible. It has become. Under each server 2, at least one external storage device 4 is connected.

分散ファイルシステム５は、システム内のファイルを管理する為に、階層的なファイルディレクトリを用いる。   The distributed file system 5 uses a hierarchical file directory to manage files in the system.

仮に、分散ファイルシステム５に、メタデータサーバーと呼ばれるような、システム全体のメタデータを管理するサーバー２があると、メタデータを更新する処理、例えばファイルやディレクトリの生成や削除、が同時に多数発生した場合、メタデータサーバーにアクセスが集中し、分散ファイルシステム５のボトルネックになる可能性がある。この問題を避けるため、分散ファイルシステム５は、ファイルのデータだけではなく、ファイルの位置情報などファイルを管理するメタデータも複数のサーバー２に分散させて配置する。すなわち、分散ファイルシステム５は、メタデータサーバーを用いない構成を採用している。   If the distributed file system 5 includes a server 2 that manages metadata of the entire system, such as a metadata server, a large number of processes for updating metadata, such as creation and deletion of files and directories, occur simultaneously. In such a case, access concentrates on the metadata server, which may become a bottleneck of the distributed file system 5. In order to avoid this problem, the distributed file system 5 distributes not only file data but also metadata for managing files, such as file location information, to be distributed to a plurality of servers 2. That is, the distributed file system 5 employs a configuration that does not use a metadata server.

分散ファイルシステム５は、メタデータサーバーは用いないが、ファイルシステムのルートディレクトリを管理するサーバー２（ルートサーバーと呼称）を用いる。ルートディレクトリとは、マウント対象のファイルシステムの先頭のディレクトリを指す。分散ファイルシステム５のシステム構築時にシステム管理者が、ルートサーバーを決めておく。   The distributed file system 5 does not use a metadata server, but uses a server 2 (referred to as a root server) that manages the root directory of the file system. The root directory refers to the first directory of the file system to be mounted. A system administrator determines a root server when the distributed file system 5 is constructed.

なお、以降の説明において、あるディレクトリを管理するサーバー２は、当該ディレクトリを記憶し、クライアント１や他のサーバー２の要求に応じて当該ディレクトリに格納されている下位のディレクトリやファイルに関するデータを出力するサーバー２を指す。また、あるファイルを管理するサーバー２とは、当該ファイルおよび当該ファイルに関する詳細情報を記憶し、クライアント１や他のサーバー２の要求に応じて当該ファイルのデータを出力するサーバー２を指す。一台のサーバー２が、あるディレクトリを管理すると同時に、あるファイルを管理することも有る。   In the following description, the server 2 that manages a directory stores the directory, and outputs data on lower directories and files stored in the directory in response to a request from the client 1 or another server 2. Refers to server 2 The server 2 that manages a file refers to the server 2 that stores the file and detailed information about the file and outputs data of the file in response to a request from the client 1 or another server 2. One server 2 may manage a certain directory and at the same time manage a certain file.

ファイル、ディレクトリの生成の際に、上位ディレクトリを管理するサーバー２が、新たに生成するファイル、ディレクトリを管理するサーバー２を、後述するサーバー情報表２１１に登録されているサーバー２から選定する。この際のサーバー２の選定は、ファイルやディレクトリの名前、またはそれらに付される一意のID（IDentification）などに依存しない方法を用いて行われる。この方法は、例えば、ラウンドロビンや一様乱数に基づく選定方法である。   When generating files and directories, the server 2 that manages the upper directory selects the server 2 that manages the newly generated file and directory from the servers 2 registered in the server information table 211 described later. In this case, the server 2 is selected using a method that does not depend on the name of a file or directory, or a unique ID (IDentification) attached to the name. This method is, for example, a selection method based on round robin or uniform random numbers.

選定されたサーバー２の識別子であるサーバーIDは、選定されたサーバー２から選定元のサーバー２に返されるFH（File handle）に含まれる。FHは、生成されたファイル、ディレクトリの名称、ファイルタイプと共にメタデータとして、上位ディレクトリ毎に選定元のサーバー２が保持する。   The server ID that is the identifier of the selected server 2 is included in an FH (File handle) returned from the selected server 2 to the selection source server 2. The FH is stored in the selection source server 2 for each upper directory as metadata together with the generated file, directory name, and file type.

ここで、FHは、ファイル、ディレクトリを分散ファイルシステム５内で一意に識別するための識別子であり、サーバーIDの他にサーバー２内で一意の数値も含む。また、ファイルタイプは、ファイルかディレクトリかの区別情報である。   Here, FH is an identifier for uniquely identifying a file and a directory within the distributed file system 5, and includes a numerical value unique within the server 2 in addition to the server ID. The file type is information for distinguishing between a file and a directory.

この結果、各サーバー２は、自装置が管理する各ディレクトリ配下にあるファイル、ディレクトリの名とそれらの位置情報であるサーバーIDの一覧をディレクトリエントリとして持つことができる。   As a result, each server 2 can have a list of files and directory names under the directories managed by its own device and a list of server IDs as their location information as directory entries.

分散ファイルシステム５においては、各サーバー２がクライアント１からのリクエスト毎にそれぞれ独立してこのファイル、ディレクトリの生成処理を行うので、システム全体としての排他制御などは不要である。さらに、各サーバー２が、サーバー２の選定に際してラウンドロビンや一様乱数に基づく方法で行うので、ファイル、ディレクトリの名前、及びディレクトリ構造とは関係なく、ディレクトリ、ファイルをシステム内でほぼ均等に配置できる。例えば、サーバー２が３台ある場合、１番目のサーバー２は２、３、１番目、２番目のサーバー２は３、１、２番目、３番目のサーバー２は１、２、３番目のサーバー２の順で割り当てる方法により、ディレクトリ、ファイルをシステム内でほぼ均等に配置できる。   In the distributed file system 5, since each server 2 performs the file and directory generation processing independently for each request from the client 1, exclusive control or the like as the entire system is unnecessary. Furthermore, since each server 2 performs selection based on round robin or uniform random numbers when selecting the server 2, the directories and files are arranged almost evenly in the system regardless of the file and directory names and the directory structure. it can. For example, if there are three servers 2, the first server 2 is 2, 3, 1st, 2nd server 2 is 3, 1, 2nd, 3rd server 2 is 1, 2 and 3rd server By assigning in the order of 2, directories and files can be arranged almost evenly in the system.

ファイル名を変更する場合は、その上位ディレクトリのディレクトリエントリ内の名前を書き換えるだけでよい。さらに、ハードリンクは、例えばディレクトリエントリ内に名前は異なるが同一のFH、ファイルタイプを持つエントリを作り、対象となるファイルを管理するサーバー２で該ファイルのファイル詳細情報のリンク数に１を加算することで実現可能となる。   When changing the file name, it is only necessary to rewrite the name in the directory entry of the upper directory. Furthermore, for example, a hard link is created in the directory entry with the same name but the same FH and file type, and the server 2 managing the target file adds 1 to the number of links of the file detailed information of the file. This is possible.

運用中に新たに、分散ファイルシステム５にサーバー２を追加した場合でも、既存のファイル、ディレクトリの配置は変わらないので、特別な処理は不要である。   Even when a server 2 is newly added to the distributed file system 5 during operation, the arrangement of existing files and directories does not change, so no special processing is required.

なお、ルートサーバーは、ファイルシステムの先頭のディレクトリのみを管理するのではなく、他のサーバー２同様にサーバー２選定の対象にもなるため、データ、メタデータの管理に関して他のサーバー２との違いはない。   Note that the root server does not manage only the first directory of the file system, but is also subject to selection of the server 2 in the same manner as the other servers 2, so that it differs from other servers 2 in terms of data and metadata management. There is no.

ファイル、ディレクトリの生成に際して選定されたサーバー２は、生成したファイル、ディレクトリのFH毎のディレクトリエントリを設け、更新／参照時刻、パーミッションなどの詳細情報を保持する。さらにファイルを生成した場合は、ファイルのサイズ、チャンクサイズ、並列数などをファイル詳細情報に含めて記憶する。   The server 2 selected when generating the file and directory provides a directory entry for each FH of the generated file and directory, and holds detailed information such as update / reference time and permission. Further, when a file is generated, the file size, chunk size, parallel number, etc. are included in the file detailed information and stored.

これにより、分散ファイルシステム５の各サーバー２は、ルートサーバーを頂点とした、例えば、図３に示すような階層的なツリー構造を作る。
ａ）ファイルシステムの最上位のディレクトリを管理するルートサーバーは、自装置が記憶するルートディレクトリの中に、そのディレクトリ配下にある「子ディレクトリ」を管理するサーバー２を特定できる情報を記憶している。
ｂ）子ディレクトリを管理するサーバー２は、自装置が記憶する子ディレクトリの中に、そのディレクトリ配下にある「孫ディレクトリ」を管理するサーバー２を特定できる情報を記憶している。
ｃ）孫ディレクトリを管理するサーバー２は、自装置が記憶する孫ディレクトリの中に、そのディレクトリ配下にあるアクセス対象のファイルを管理するサーバー２を特定できる情報を記憶している。 As a result, each server 2 of the distributed file system 5 creates a hierarchical tree structure as shown in FIG.
a) The root server that manages the top directory of the file system stores information that can identify the server 2 that manages the “child directory” under the directory in the root directory stored in the device itself. .
b) The server 2 that manages the child directory stores information that can identify the server 2 that manages the “grandchild directory” under the directory in the child directory stored by the self-device.
c) The server 2 that manages the grandchild directory stores information that can identify the server 2 that manages the file to be accessed under the directory in the grandchild directory stored in the local apparatus.

上記構造に基づき、クライアント１は、ファイルシステムをマウントする際、そのマウント先としてルートサーバーを指定し、ルートサーバーからルートディレクトリのFHとファイルシステムを構成している全サーバー２のサーバーIDとIPアドレスの対応表を受け取る。   Based on the above structure, when the client 1 mounts the file system, the root server is specified as the mount destination, and the FH of the root directory from the root server and the server IDs and IP addresses of all the servers 2 constituting the file system. Receive the correspondence table.

次に、クライアント１は、ファイルのオープン処理などにおいてディレクトリ探索を行う。すなわち、クライアント１は、指定されたパス名の中の最上位ディレクトリの直下にあるディレクトリを管理するサーバー２をルートサーバーに問い合わせ、さらにその下のディレクトリを管理するサーバー２を問い合わせることを繰り返す。クライアント１は、このディレクトリ探索により、指定されたパス名のファイルを管理するサーバー２のサーバーIDを取得する。   Next, the client 1 performs a directory search in a file open process or the like. That is, the client 1 repeatedly inquires of the root server about the server 2 that manages the directory immediately below the top directory in the specified path name, and further inquires about the server 2 that manages the directory below the server. The client 1 acquires the server ID of the server 2 that manages the file with the specified path name by this directory search.

図４乃至図６は、ファイルのオープン、リードにおけるディレクトリ探索、リード要求の送信／応答の様子を示す。   4 to 6 show a state of file opening, directory search in reading, and transmission / response of a read request.

図４において、ユーザがクライアント１で実行するAP（Application Program）が、マウントポイントが“/mnt”であって、パスが“/mnt/home/user1/file1”であるファイルをオープンするシステムコールを発行したとする。クライアント１は、ルートサーバーにマウント時に受け取ったルートディレクトリのFHと共に配下のディレクトリ“home”を「名前」として送信して問い合わせ、ディレクトリ“home” のFHを受け取る（図４中のａ）。さらに、クライアント１は、受け取ったFHに含まれるサーバーIDから“home”を管理するサーバー２を特定してそのサーバー２にディレクトリ“user1”を「名前」として送信して問い合わせ、ディレクトリ“user1” のFHを受け取る（図中のｂ）。最後に クライアント１は、同様に“file1” を問い合わせ、ファイル“file1”のFHを受け取る（図４中のｃ）。   In FIG. 4, the AP (Application Program) executed by the user on the client 1 makes a system call to open a file whose mount point is “/ mnt” and whose path is “/ mnt / home / user1 / file1”. Suppose that it was issued. The client 1 sends an inquiry by sending the subordinate directory “home” as “name” together with the FH of the root directory received at the time of mounting on the root server, and receives the FH of the directory “home” (a in FIG. 4). Further, the client 1 identifies the server 2 that manages “home” from the server ID included in the received FH, sends an inquiry to the server 2 by sending the directory “user1” as “name”, and inquires the directory “user1”. FH is received (b in the figure). Finally, the client 1 similarly queries “file1” and receives the FH of the file “file1” (c in FIG. 4).

この結果、クライアント１は、APが発行したファイル“file1”に対するリード要求を、当該ファイルを管理するサーバー＃４に送信することが出来る（図５中のｄ）。   As a result, the client 1 can transmit a read request for the file “file1” issued by the AP to the server # 4 that manages the file (d in FIG. 5).

なお、この操作は、漸化式ai+1 = f(g(ai), ai, 名前)で表すことができる。ここで、ai はパス名中のi番目の名前に対応するFH、初期値a0 はマウント時にルートサーバーから返されたルートディレクトリのFHである。さらに、gはFHに対応するディレクトリを管理するサーバー２のサーバーIDを返す関数、fはサーバーID、FH、名前から、その名前に対応するFHを返す関数である。また、iはi = 0,…,n-1 (nは、パス名中の名前の数)の整数である。 This operation can be expressed by a recurrence formula a i + 1 = f (g (a i ), a i , name). Here, a i is the FH corresponding to the i-th name in the path name, and the initial value a 0 is the FH of the root directory returned from the root server at the time of mounting. Further, g is a function that returns the server ID of the server 2 that manages the directory corresponding to FH, and f is a function that returns FH corresponding to the name from the server ID, FH, and name. I is an integer of i = 0,..., N-1 (n is the number of names in the path name).

また、この過程において、クライアント１は、途中で受信したディレクトリを管理するサーバー２の情報をメタデータキャッシュ（図４乃至図６のクライアント１を参照）に保持する。このメタデータキャッシュは、後述するクライアント１のメタデータ記憶部１１０に格納される。そして後刻、上記のディレクトリ“user1”配下の他のファイル、例えば“file2”、のオープン処理において、既に問い合わせ済みのディレクトリ名がパス名中に含まれる場合は、このメタデータキャッシュを参照することでサーバー２との通信回数を削減する。すなわちクライアント１は、サーバー＃１、＃２との通信を省略し、サーバー＃３からファイル“file2”のFHを受け取ることが出来る（図６中のａ）。   Further, in this process, the client 1 holds the information of the server 2 that manages the directory received on the way in the metadata cache (see the client 1 in FIGS. 4 to 6). This metadata cache is stored in the metadata storage unit 110 of the client 1 described later. Later, in the open processing of other files under the above-mentioned directory “user1”, for example, “file2”, if the directory name already inquired is included in the path name, refer to this metadata cache. Reduce the number of communications with server 2. That is, the client 1 can omit the communication with the servers # 1 and # 2, and can receive the FH of the file “file2” from the server # 3 (a in FIG. 6).

なお、特許文献２は、頻繁にディレクトリ内容が書き換えられる場合、上記メタデータキャッシュについての不都合を指摘している（段落０００７、０００８）。しかし、ファイルシステムの上位のディレクトリは、システム管理者でなければ書き換えはできないことが通常であり、またエンドユーザが書き換え可能なディレクトリであっても、上位のディレクトリほど書き換えの頻度は少ない。このため、少なくとも上位のディレクトリについてはメタデータキャッシュが有効に機能する。   Note that Patent Document 2 points out the inconvenience of the metadata cache when the directory contents are frequently rewritten (paragraphs 0007 and 0008). However, it is normal that the upper directory of the file system can only be rewritten by a system administrator, and even if the directory can be rewritten by the end user, the upper directory is less frequently rewritten. Therefore, the metadata cache functions effectively for at least the upper directory.

また、ディレクトリ探索を実施する場合でも、その探索は比較的下位のディレクトリのみを対象とするため、ルートサーバーなどへ探索要求が集中することはなく、各サーバー２へ適度に負荷分散できる。   Even when directory search is performed, since the search targets only a relatively low-level directory, search requests are not concentrated on the root server or the like, and the load can be distributed appropriately to each server 2.

次に、多数のクライアント１が同一ディレクトリ配下のファイルをオープンする場合の２つのケースについて、分散ファイルシステム５におけるI/Oの効率化方法を示す。   Next, I / O efficiency improvement methods in the distributed file system 5 will be described for two cases where a large number of clients 1 open files under the same directory.

ケース１：
同一ファイルへの並列I/Oなどの目的で、多数のクライアント１が同一ファイルをオープンする場合
ケース２：
多数のクライアント１が同一ディレクトリ配下の異なるファイルをオープンする場合
ここで、効率化の前提となる事項について説明する。 Case 1:
When many clients 1 open the same file for the purpose of parallel I / O to the same file Case 2:
When many clients 1 open different files under the same directory Here, the preconditions for efficiency will be described.

ファイルのオープン処理において、ディレクトリ探索の最後の処理が、オープン対象のファイルのメタデータを取得することである。この際、クライアント１は、該ファイルのファイル詳細情報も必要としている。このファイル詳細情報は、例えば、ファイルのサイズ、更新／参照時刻、ファイルのチャンクサイズ、使用するサーバー数である。クライアント１は、この問い合わせを、該ファイルが存在するディレクトリを管理するサーバー２に対して行うが、これらファイル詳細情報は、もともと該ファイルを管理するサーバー２が保持している。   In the file open process, the final process of the directory search is to acquire the metadata of the file to be opened. At this time, the client 1 also needs detailed file information of the file. The detailed file information includes, for example, the file size, update / reference time, file chunk size, and the number of servers to be used. The client 1 makes this inquiry to the server 2 that manages the directory in which the file exists. The detailed file information is originally held by the server 2 that manages the file.

このため、ファイル詳細情報をクライアント１が得る手段として下記２つの方法がある。   Therefore, there are the following two methods for obtaining detailed file information by the client 1.

(ア)該ファイルが存在するディレクトリを管理するサーバー２は、FHとファイルタイプのみをクライアント１へ返却する。その後、クライアント１は、返却されたFHから該ファイルを管理するサーバー２を特定し、そのサーバー２へファイル詳細情報を要求する。   (A) The server 2 that manages the directory in which the file exists returns only the FH and file type to the client 1. Thereafter, the client 1 specifies the server 2 that manages the file from the returned FH, and requests file detailed information from the server 2.

(イ)該ファイルが存在するディレクトリを管理するサーバー２が、該ファイルを管理するサーバー２へファイル詳細情報を問い合わせるサーバー２間通信（例えば、図６のａ’）を実施し、その結果をファイルのFHなどと共にクライアント１へ返す。つまり、本来は（ア）のように２つの要求であるものを１つの要求にまとめる。   (A) The server 2 that manages the directory in which the file exists performs communication between the servers 2 that inquires the server 2 that manages the file about file detailed information (for example, a ′ in FIG. 6), and the result is the file Return to client 1 with FH etc. In other words, the two requests as originally (a) are combined into one request.

ここで、上述した２つのケースについて、I/Oの効率化方法を説明する。   Here, an I / O efficiency improving method will be described for the two cases described above.

ケース１：
多数のクライアント１がほぼ同時期に上記（ア）によりファイル詳細情報を得る場合、クライアント１がサーバー２と通信する回数が、クライアント１毎に１回増える。クライアント１が５１２台あれば、クライアント１がサーバー２と通信する回数が５１２回となる。さらに、該ファイルを管理するサーバー２にもファイル詳細情報の要求が集中する可能性がある。ファイル詳細情報はデータ量が多少多くなるので、通信回数だけではなくサーバー２のI/OやCPU等の負荷の面からも好ましくない。 Case 1:
When a large number of clients 1 obtain detailed file information by (a) almost at the same time, the number of times the client 1 communicates with the server 2 is increased once for each client 1. If there are 512 clients 1, the client 1 communicates with the server 2 512 times. Furthermore, there is a possibility that requests for file detailed information may be concentrated on the server 2 that manages the file. Since the file detailed information has a somewhat large amount of data, it is not preferable not only from the number of communications but also from the load of the I / O of the server 2 and the CPU.

このため、サーバー２間通信を行う（イ）の方法を基にして、該ファイルを管理するサーバー２から受け取った（例えば、図６中のａ‘）ファイル詳細情報を、該ファイルが存在するディレクトリを管理するサーバー２にキャッシュする。つまり、当該サーバー２は、該ファイルのFHと紐づくファイル詳細情報表２１２をキャッシュとしてメモリ上に持ち、ディレクトリエントリから参照可能とする。そして、当該サーバー２は、ファイル詳細情報表２１２にFHに対応するエントリがあれば、それを参照することで、ファイル詳細情報をクライアント１に出力する（例えば、図６中のａ）。これにより、分散ファイルシステム５は、サーバー２間の通信回数（例えば、図６中のサーバー＃３と＃５の間）を削減し、さらに該ファイルを管理するサーバー２（例えば、図６中のサーバー＃５）へのI/OやCPU等の負荷を減らす。   Therefore, based on the method (a) for performing communication between the servers 2, the file detailed information received from the server 2 that manages the file (for example, a 'in FIG. 6) is stored in the directory where the file exists. Is cached in the server 2 that manages That is, the server 2 has a file detailed information table 212 associated with the FH of the file on the memory as a cache, and can be referred to from the directory entry. Then, if there is an entry corresponding to FH in the file detailed information table 212, the server 2 refers to it and outputs the file detailed information to the client 1 (for example, a in FIG. 6). As a result, the distributed file system 5 reduces the number of communications between the servers 2 (for example, between the servers # 3 and # 5 in FIG. 6), and further manages the file 2 (for example, in FIG. 6). Reduce I / O and CPU load on server # 5).

ケース２
対象ファイルがクライアント１毎にそれぞれ異なるため、（イ）の場合、サーバー２間通信は対象ファイルごとに必要になる。ただ、サーバー２ではケース１かケース２かの判別はできない。すなわち、次に来るリクエストが何であるかはそれを受け取るまでわからない。このため、サーバー２は、次に述べるデーモン数の範囲内では、ケース１と同様に（イ）の方法を選択する。 Case 2
Since the target file is different for each client 1, in the case of (a), communication between servers 2 is required for each target file. However, the server 2 cannot discriminate between case 1 and case 2. That is, you do not know what the next request is until you receive it. For this reason, the server 2 selects the method (A) within the range of the number of daemons described below, as in the case 1.

（イ）の方法を使った場合、サーバー２間通信の間、ファイルが存在するディレクトリを管理するサーバー２上（例えば、図６中のサーバー＃３）のデーモンが対象ファイルごとに１つブロックされる。ここで、デーモンとは、クライアント１からのリクエストを処理するプロセスである。   When the method (a) is used, during communication between the servers 2, one daemon on the server 2 (for example, server # 3 in FIG. 6) that manages the directory where the file exists is blocked for each target file. The Here, the daemon is a process for processing a request from the client 1.

多数のクライアント１からのアクセスが集中し、デーモン数よりもクライアント１からのリクエスト数が多い場合は、デーモンが空くまでキューイングされて待たされることになり、その分TAT（Turn Around Time）が悪化することになる。ある特定のクライアント１のTATの悪化は、そのクライアント１を含むマルチノードジョブ全体のTATの悪化につながる。   If access from a large number of clients 1 is concentrated and the number of requests from client 1 is greater than the number of daemons, it will be queued and waited until daemons are free, and the TAT (Turn Around Time) will deteriorate accordingly. Will do. Deterioration of TAT of a specific client 1 leads to deterioration of TAT of the entire multi-node job including the client 1.

このため、サーバー２がリクエストを受信した際、デーモンがすべて処理中である場合は、サーバー２は、クライアント１のファイル詳細情報取得方法を、（イ）から（ア）の方法に切り替える。つまり、ファイルが存在するディレクトリを管理するサーバー２は、自装置が保持しているディレクトリエントリ内の情報であるFH、ファイルタイプのみをクライアント１に返す。クライアント１は、返されたFHから、オープン対象のファイルを管理するサーバー２を特定し、特定したサーバー２へ直接ファイル詳細情報を要求する。オープン対象の各ファイルは、それぞれ各サーバー２に分散配置されているため、このリクエストの送信先もクライアント１毎に分散されることになる。これにより、TATの悪化を軽減することが可能となる。   For this reason, when all the daemons are processing when the server 2 receives the request, the server 2 switches the file detailed information acquisition method of the client 1 from the method (A) to the method (A). That is, the server 2 that manages the directory in which the file exists returns only the FH and file type, which are information in the directory entry held by itself, to the client 1. The client 1 specifies the server 2 that manages the file to be opened from the returned FH, and requests the file detailed information directly from the specified server 2. Since each file to be opened is distributed to each server 2, the transmission destination of this request is also distributed for each client 1. Thereby, it becomes possible to reduce the deterioration of TAT.

＜構成＞
図２は、本実施の形態にかかるクライアント１、サーバー２、および、外部記憶装置４の内部構成を示す図である。 <Configuration>
FIG. 2 is a diagram showing an internal configuration of the client 1, the server 2, and the external storage device 4 according to the present embodiment.

クライアント１は、通信部１０１、マウント要求部１０２、メタデータ参照／更新部１０３、サーバー情報表更新部１０４、メタデータ問い合わせ部１０５、パス名解析部１０６、ファイル／ディレクトリ生成要求部１０７、ファイル詳細情報要求部１０８、サーバー情報表１０９、および、メタデータ記憶部１１０を包含する。通信部１０１は、リクエスト作成部１０１−１、および、サーバー特定部１０１−２を包含する。   The client 1 includes a communication unit 101, a mount request unit 102, a metadata reference / update unit 103, a server information table update unit 104, a metadata inquiry unit 105, a path name analysis unit 106, a file / directory generation request unit 107, and file details. An information request unit 108, a server information table 109, and a metadata storage unit 110 are included. The communication unit 101 includes a request creation unit 101-1 and a server identification unit 101-2.

サーバー２は、通信部２０１、マウント応答部２０２、サーバー選定部２０３、ファイル／ディレクトリ生成要求部２０４、ディレクトリエントリ参照／更新部２０５、ファイル／ディレクトリ生成部２０６、ＦＨ生成部２０７、サーバー内ＦＨ検索部２０８、ファイル詳細情報問い合わせ部２０９、Ｉ／Ｏ発行部２１０、サーバー情報表２１１、ファイル詳細情報表２１２、および、メタデータ一時記憶表２１３を包含する。通信部２０１は、リクエスト作成部２０１−１、リクエスト応答部２０１−２、リクエスト受信部２０１−３、リクエスト内容変更部２０１−４、リクエスト処理デーモン数判別／更新部２０１−５、リクエスト処理デーモン数カウンタ２０１−６、リクエスト内容判別部２０１−７、および、サーバー特定部２０１−８を包含する。   The server 2 includes a communication unit 201, a mount response unit 202, a server selection unit 203, a file / directory generation request unit 204, a directory entry reference / update unit 205, a file / directory generation unit 206, an FH generation unit 207, and an in-server FH search. Section 208, file detailed information inquiry section 209, I / O issuing section 210, server information table 211, file detailed information table 212, and metadata temporary storage table 213. The communication unit 201 includes a request creation unit 201-1, a request response unit 201-2, a request reception unit 201-3, a request content change unit 201-4, a request processing daemon number determination / update unit 201-5, and a request processing daemon number. It includes a counter 201-6, a request content determining unit 201-7, and a server specifying unit 201-8.

外部記憶装置４は、メタデータ記憶装置４０１、および、ファイルデータ記憶装置４０２を包含する。   The external storage device 4 includes a metadata storage device 401 and a file data storage device 402.

なお、図２中で各部を結ぶ矢印は、結ばれる両者間の主要な指示／情報の流れを示すものであるが、各部間の指示／情報の流れは、これらに限られるものではない。   In FIG. 2, the arrows connecting the parts indicate the main instruction / information flow between the two parts, but the instruction / information flow between the parts is not limited thereto.

図２中の各部は、それぞれ概略次のように動作する。最初に、クライアント１に含まれる各部の概略動作について説明する。   Each part in FIG. 2 generally operates as follows. First, the schematic operation of each unit included in the client 1 will be described.

通信部１０１は、送信デーモン、受信デーモンを包含する。そして、通信部１０１は、サーバー２に対してリクエストを送信する際は、例えば、メタデータ問い合わせ部１０５から渡された要求を通信プロトコルにあった形式に変換して、リクエスト作成部１０１−１を用いてリクエストを作成する。また、この際に、通信部１０１は、FHを基に、サーバー特定部１０１−２を用いて宛先のサーバー２のIPアドレスを得る。   The communication unit 101 includes a transmission daemon and a reception daemon. And when the communication part 101 transmits a request with respect to the server 2, for example, the request passed from the metadata inquiry part 105 is converted into a format suitable for the communication protocol, and the request creation part 101-1 is changed. To create a request. At this time, the communication unit 101 obtains the IP address of the destination server 2 using the server specifying unit 101-2 based on the FH.

リクエスト作成部１０１−１は、TCP/IPなど使用する通信プロトコルに沿った形式のパケットを作成する。   The request creation unit 101-1 creates a packet in a format according to a communication protocol used such as TCP / IP.

FHにはこれに対応するファイル、ディレクトリを管理するサーバー２のサーバーIDが含まれている。サーバー特定部１０１−２は、FHを基にサーバーIDを抽出し、サーバー情報表１０９を参照して、宛先サーバー２のIPアドレスを得る。   The FH includes the server ID of the server 2 that manages the corresponding file and directory. The server specifying unit 101-2 extracts the server ID based on the FH, refers to the server information table 109, and obtains the IP address of the destination server 2.

マウント要求部１０２は、クライアント１がファイルシステムを利用可能にするための処理を行う。マウントに際して、あらかじめシステム管理者が、ルートサーバーのIPアドレス若しくはマシン名、及び、マウントポイントを指定しておく必要がある。   The mount request unit 102 performs processing for making the file system available to the client 1. When mounting, the system administrator needs to specify the IP address or machine name of the root server and the mount point in advance.

mountコマンドなどによりマウント処理が開始されると、クライアント１からルートサーバーにマウント要求が通信部１０１を介して送信される。その応答として、サーバー情報、および、ファイルシステムの先頭のディレクトリのFHがルートサーバーからクライアント１に返される。ここで、サーバー情報は、ファイルシステムを構成している全サーバー２のサーバーIDとそのIPアドレスの対応表、および、各サーバー２配下のデバイス情報を包含する。   When mount processing is started by a mount command or the like, a mount request is transmitted from the client 1 to the root server via the communication unit 101. As a response, server information and FH of the first directory of the file system are returned from the root server to the client 1. Here, the server information includes a correspondence table of server IDs and IP addresses of all the servers 2 constituting the file system, and device information under each server 2.

サーバー情報は、クライアント１において、サーバー情報更新部１０４によりサーバー情報表１０９に記録され、FHはルートディレクトリのFHとして、メタデータ参照／更新部１０３によりメタデータ記憶部１１０に記録される。   Server information is recorded in the server information table 109 by the server information update unit 104 in the client 1, and FH is recorded in the metadata storage unit 110 by the metadata reference / update unit 103 as FH of the root directory.

メタデータ参照／更新部１０３は、メタデータ記憶部１１０の参照と更新を行う。   The metadata reference / update unit 103 refers to and updates the metadata storage unit 110.

サーバー情報表更新部１０４は、サーバー情報表１０９更新を行う。   The server information table update unit 104 updates the server information table 109.

メタデータ問い合わせ部１０５は、最初に、パス名解析部１０６により、指定されたパス名中のより上位の名前を１つ抽出する。例えば、マウントポイントが “/mnt”、パス名が “/mnt/home/user1/file1” である場合、まず “home” が抽出される。メタデータ問い合わせ部１０５は、それをメタデータ参照／更新部１０３により、ルートディレクトリ配下にこの名前がメタデータ記憶部１１０に既に登録されているかどうかを調べる。   First, the metadata inquiry unit 105 causes the path name analysis unit 106 to extract one higher level name from the specified path name. For example, if the mount point is “/ mnt” and the path name is “/ mnt / home / user1 / file1”, “home” is extracted first. The metadata inquiry unit 105 checks whether the name is already registered in the metadata storage unit 110 under the root directory by the metadata reference / update unit 103.

記憶されていない場合、メタデータ問い合わせ部１０５は、マウント時にルートサーバーから取得したルートディレクトリのFHとその配下の名前（“home”）の組み合わせをルートサーバーに送信して、送信した名前に対応するFHを要求する。応答として、指定した名前に対応するFHとファイルタイプが返される。メタデータ問い合わせ部１０５は、これをメタデータ参照／更新部１０３により、メタデータ記憶部１１０に登録する。   If not stored, the metadata inquiry unit 105 transmits the combination of the FH of the root directory acquired from the root server at the time of mounting and the name (“home”) under the root directory to the root server, and corresponds to the transmitted name. Request FH. In response, the FH and file type corresponding to the specified name are returned. The metadata inquiry unit 105 registers this in the metadata storage unit 110 by the metadata reference / update unit 103.

その後、メタデータ問い合わせ部１０５は、パス名解析部１０６により、パス名中からその１つ下の名前（“user1”）を抽出し、その上位のディレクトリ（“home”）のFHからそれを管理するサーバー２を特定し、上記と同様にそのFHと名前（“user1”）に対応するFHを要求する。メタデータ問い合わせ部１０５は、応答として返された名前に対応するFHとファイルタイプをメタデータ参照／更新部１０３により、メタデータ記憶部１１０に登録する。メタデータ問い合わせ部１０５は、同様に処理を繰り返す。   Thereafter, the metadata inquiry unit 105 extracts a name (“user1”) immediately below from the path name by the path name analysis unit 106 and manages it from the FH of the upper directory (“home”). The server 2 is identified, and the FH corresponding to the FH and name (“user1”) is requested in the same manner as described above. The metadata inquiry unit 105 registers the FH and file type corresponding to the name returned as a response in the metadata storage unit 110 by the metadata reference / update unit 103. The metadata inquiry unit 105 repeats the process in the same manner.

なお、パス名の末端の名前（“file1”）は、オープンシステムコールから呼ばれている場合、ファイル名であるので、サーバー２からは名前に対応するFHと共にファイル詳細情報が返される（図４中のｃ）。   Since the name (“file1”) at the end of the path name is a file name when called from an open system call, the server 2 returns file detailed information together with the FH corresponding to the name (FIG. 4). C).

前述の図４は、メタデータ問い合わせ部１０５が関連モジュールを用いながら、ディレクトリ探索を経て、パス名に対応するファイルのFHとファイル詳細情報を取得する流れを示す。   FIG. 4 described above shows a flow in which the metadata inquiry unit 105 acquires the FH and file detailed information of the file corresponding to the path name through the directory search while using the related module.

パス名解析部１０６は、与えられたパス名から文字列操作により、名前を１つ抽出する。   The path name analysis unit 106 extracts one name from the given path name by a character string operation.

ファイル／ディレクトリ生成要求部１０７は、与えられたパス名の最後の名前で、ファイルまたはディレクトリの作成を該当するサーバー２に要求する。与えられたパス名の最後の名前は、例えば、パス名が“/mnt/home/user1/file1”なら、名前“file1”である。ただし、作成するファイル、ディレクトリの上位ディレクトリのFHがメタデータ記憶部１１０に登録されていない場合は、先にメタデータ問い合わせ部１０５により上位ディレクトリのFHの問い合わせを行う。   The file / directory generation request unit 107 requests the corresponding server 2 to create a file or directory with the last name of the given path name. For example, if the path name is “/ mnt / home / user1 / file1”, the last name of the given path name is the name “file1”. However, when the FH of the upper directory of the file to be created and the directory is not registered in the metadata storage unit 110, the metadata inquiry unit 105 first inquires about the FH of the upper directory.

メタデータ問い合わせ部１０５の処理において、オープンシステムコールによりファイルをオープンする際、与えられたパス名の末端の名前に対応したFHの問い合わせでファイル詳細情報が返されず、FHとファイルタイプのみが返される場合が有る。すなわち、図４中のｃにおいて、ファイル詳細情報が返されない場合が有る。   In the processing of the metadata inquiry unit 105, when a file is opened by an open system call, the file detailed information is not returned by the FH inquiry corresponding to the end name of the given path name, and only the FH and the file type are returned. There is a case. That is, the file detailed information may not be returned at c in FIG.

ファイル詳細情報要求部１０８は、この場合、このFHに基づいて該当するサーバー２、例えば、図４のサーバー＃４、へ直接ファイル詳細情報を要求し、それをメタデータ参照／更新部１０３によりメタデータ記憶部１１０に登録する。   In this case, the file detailed information requesting unit 108 requests the file detailed information directly from the corresponding server 2, for example, the server # 4 in FIG. Register in the data storage unit 110.

サーバー情報表１０９は、ファイルシステムを構成している全サーバー２のサーバーIDとそのIPアドレスの対応表と各サーバー２配下のデバイス情報をクライアント１に記憶するメモリ領域である。   The server information table 109 is a memory area for storing in the client 1 a correspondence table of server IDs and IP addresses of all servers 2 constituting the file system and device information under each server 2.

メタデータ記憶部１１０は、メタデータをクライアント１にキャッシュするためのメモリ領域である。メタデータ記憶部１１０は、オープンシステムコールなどで指定されるパス名中の各ディレクトリ名、またはファイル名をファイルディレクトリの上位から順に記憶し、それに対応するディレクトリ、ファイルのFHとファイルタイプを記憶する。さらに、ファイルの場合は、メタデータ記憶部１１０はファイル詳細情報も記憶する。   The metadata storage unit 110 is a memory area for caching metadata in the client 1. The metadata storage unit 110 stores each directory name or file name in the path name specified by an open system call or the like in order from the top of the file directory, and stores the corresponding directory, file FH and file type. . Further, in the case of a file, the metadata storage unit 110 also stores detailed file information.

クライアント装置１内の各部の機能分担は、適宜変更して実装しても良い。例えば、メタデータ問い合わせ部１０５は、パス名解析部１０６、および、メタデータ参照／更新部１０３の機能を包含しても良い。   The function sharing of each unit in the client device 1 may be appropriately changed and implemented. For example, the metadata inquiry unit 105 may include the functions of the path name analysis unit 106 and the metadata reference / update unit 103.

次に、サーバー２に含まれる各部の概略動作について説明する。   Next, a schematic operation of each unit included in the server 2 will be described.

通信部２０１は、受信デーモンと送信デーモンとして動作し、リクエストの受信とその応答及びサーバー２間通信の際のリクエストの作成を行う。   The communication unit 201 operates as a reception daemon and a transmission daemon, and generates a request when receiving a request, responding to the request, and communicating between the servers 2.

さらに、通信部２０１は、動作中／待ち状態のリクエスト処理デーモンの数を管理している。クライアント１からファイル詳細情報を要求された際、待ち状態のリクエスト処理デーモン数が１個以下の場合、通信部２０１はファイル詳細情報を返却せずに、当該ファイルのFHとファイルタイプを返却するようにリクエストの内容を変更する。なお、通信部２０１は、動作中／待ち状態のリクエスト処理デーモンの数を管理する代わりに、ファイル詳細情報取得のため入出力について、現在進行中の入出力数と発行可能な最大多重度と現在進行中の入出力数との差分、を管理しても良い。   Further, the communication unit 201 manages the number of operating / waiting request processing daemons. When requesting detailed file information from the client 1, if the number of waiting request processing daemons is 1 or less, the communication unit 201 returns the FH and file type of the file without returning the detailed file information. Change the content of the request. Note that the communication unit 201 does not manage the number of operating / waiting request processing daemons, but for the input / output for file detailed information acquisition, the number of input / output currently in progress, the maximum multiplicity that can be issued, and the current You may manage the difference with the number of input / output in progress.

リクエスト作成部２０１−１は、サーバー２間通信の際に宛先のサーバー２を指定し、必要なパラメータの設定などをしてリクエストを作成し、送信デーモンに渡す。   The request creation unit 201-1 designates the destination server 2 during communication between the servers 2, creates a request by setting necessary parameters, and passes the request to the transmission daemon.

リクエスト応答部２０１−２は、クライアント１、またはサーバー２間通信でのリクエストに対する応答に必要なデータを設定し、送信デーモンに渡す。   The request response unit 201-2 sets data necessary for a response to the request in the communication between the client 1 or the server 2 and passes it to the transmission daemon.

リクエスト受信部２０１−３は、受信デーモンが受信したリクエストをリクエスト処理デーモンに渡す。なお、この際、リクエストがFH、ファイルタイプ、ファイル詳細情報を要求し、かつ、待ち状態のリクエスト処理デーモン数が１個以下であれば、リクエスト内容変更部２０１−４によりリクエストをFHとファイルタイプのみのリクエストに置き換える。   The request reception unit 201-3 passes the request received by the reception daemon to the request processing daemon. At this time, if the request requests FH, file type, and file detailed information, and the number of waiting request processing daemons is 1 or less, the request content changing unit 201-4 sends the request to FH and file type. Replace with only requests.

リクエスト内容変更部２０１−４は、リクエスト内容の書き換えを行う。   The request content changing unit 201-4 rewrites the request content.

リクエスト処理デーモン数判別／更新部２０１−５は、処理中のリクエスト処理デーモンの数をリクエスト処理デーモン数カウンタ２０１−６に保持する。すなわち、リクエスト処理デーモン数判別／更新部２０１−５は、リクエスト処理デーモンの処理の開始／終了時に、リクエスト処理デーモン数カウンタ２０１−６のカウント値に１を加算／減算する。また、リクエスト処理デーモン数判別／更新部２０１−５は、受信デーモンがファイル詳細情報のリクエストを受信した際にリクエスト処理デーモン数カウンタ２０１−６のカウント値を参照する。   The request processing daemon number discrimination / update unit 201-5 holds the number of request processing daemons being processed in the request processing daemon number counter 201-6. That is, the request processing daemon number discriminating / updating unit 201-5 adds / subtracts 1 to the count value of the request processing daemon number counter 201-6 at the start / end of the processing of the request processing daemon. Further, the request processing daemon number discriminating / updating unit 201-5 refers to the count value of the request processing daemon number counter 201-6 when the receiving daemon receives a request for file detailed information.

リクエスト処理デーモン数カウンタ２０１−６は、処理中のリクエスト処理デーモンの数を持つカウンタであり、メモリ上にその領域を確保される。   The request processing daemon number counter 201-6 is a counter having the number of request processing daemons being processed, and its area is secured on the memory.

リクエスト内容判別部２０１−７は、クライアント１または他のサーバー２から受信したリクエストの種別を調べる。   The request content determination unit 201-7 checks the type of request received from the client 1 or another server 2.

FHには、これに対応するファイル、ディレクトリを管理するサーバー２のサーバーIDが含まれている。サーバー特定部２０１−８は、FHからサーバーIDを抽出し、サーバー情報表２１１を参照して宛先サーバー２のIPアドレスを特定する。   The FH includes the server ID of the server 2 that manages the corresponding file and directory. The server specifying unit 201-8 extracts the server ID from the FH, and specifies the IP address of the destination server 2 with reference to the server information table 211.

マウント応答部２０２は、クライアント１から、ファイルシステムのマウントを要求するリクエストを受信する。そして、マウント応答部２０２は、同クライアント１に対し、サーバー情報表２１１に記録されている該ファイルシステムのルートディレクトリのFHと、該ファイルシステムを構成するサーバー２のサーバーIDとIPアドレスを返却する。さらに、マウント応答部２０２は、各サーバー２配下のデバイスに関する情報を返す。なお、同リクエストを受信したサーバー２がルートサーバーではない場合は、マウント応答部２０２は、同クライアント１へエラーを返す。   The mount response unit 202 receives a request for mounting a file system from the client 1. Then, the mount response unit 202 returns the FH of the root directory of the file system recorded in the server information table 211 and the server ID and IP address of the server 2 constituting the file system to the client 1. . Further, the mount response unit 202 returns information regarding devices under each server 2. If the server 2 that received the request is not the root server, the mount response unit 202 returns an error to the client 1.

サーバー選定部２０３は、ファイル、ディレクトリの生成を要求された際、サーバー情報表２１１を参照して、ファイル、ディレクトリの名前に依存しない方法、例えば、ラウンドロビンや一様乱数に基づき、サーバー２を一つ選定する。   When the server selection unit 203 is requested to generate a file and a directory, the server selection unit 203 refers to the server information table 211 and determines the server 2 based on a method that does not depend on the name of the file or directory, for example, round robin or uniform random number. Select one.

ファイル／ディレクトリ生成要求部２０４は、サーバー選定部２０３が選定したサーバー２に対してファイル、ディレクトリの生成を要求する。   The file / directory generation request unit 204 requests the server 2 selected by the server selection unit 203 to generate a file and a directory.

ディレクトリエントリ参照／更新部２０５は、ファイル、ディレクトリを生成した際、その上位ディレクトリを管理するサーバー２において、メタデータ記憶装置４０１内の上位ディレクトリのディレクトリエントリに、生成されたファイル、ディレクトリのエントリを追加する。また、ディレクトリエントリ参照／更新部２０５は、参照要求を受けて、ディレクトリエントリ内の指定された名前に一致するエントリ、あるいはディレクトリエントリの各エントリのFHとファイルタイプを返す。   When the directory entry reference / update unit 205 generates a file or directory, the server 2 that manages the upper directory stores the generated file or directory entry in the upper directory entry in the metadata storage device 401. to add. Also, the directory entry reference / update unit 205 receives the reference request and returns an entry that matches the specified name in the directory entry or the FH and file type of each entry of the directory entry.

ファイル／ディレクトリ生成部２０６は、ファイル、ディレクトリの生成要求をサーバー２間通信により受け取って、メタデータ記憶装置４０１内に該当するエントリが有るかどうかをチェックする。無ければ、ファイル／ディレクトリ生成部２０６は、ＦＨ生成部２０７によりFHを新たに生成し、ファイルの場合はファイルの構成情報や、ファイルタイプと共に新たなエントリを記録する。   The file / directory generation unit 206 receives a file / directory generation request through inter-server 2 communication, and checks whether there is a corresponding entry in the metadata storage device 401. If not, the file / directory generation unit 206 newly generates an FH by the FH generation unit 207, and in the case of a file, records a new entry together with the file configuration information and the file type.

ＦＨ生成部２０７は、ファイル、ディレクトリを生成する際に起動されて、当該サーバー２のサーバーIDとサーバー２内でユニークな数値を組み合わせて、ファイルシステム全体でユニークなFHを生成する。   The FH generation unit 207 is activated when generating a file and a directory, and generates a unique FH for the entire file system by combining the server ID of the server 2 and a numerical value unique within the server 2.

サーバー内ＦＨ検索部２０８は、Ｉ／Ｏ発行部２１０を介して、メタデータ記憶装置４０１内を検索し、指定されたFHを検索する。   The in-server FH search unit 208 searches the metadata storage device 401 via the I / O issuing unit 210 and searches for the designated FH.

ファイル詳細情報問い合わせ部２０９は、クライアント１がオープンしようとする、自装置が管理するディレクトリ配下のファイルのファイル詳細情報を、当該ファイルを管理するサーバー２に問い合わせる。   The file detailed information inquiring unit 209 inquires of the server 2 that manages the file about the file detailed information of the file under the directory managed by the own device that the client 1 intends to open.

Ｉ／Ｏ発行部２１０は、メタデータ記憶装置４０１、及びファイルデータ記憶装置４０２に対して、指定されたメモリ上のデータを書き込む、あるいは、指定されたデータをメモリ上に読み込む。この際、Ｉ／Ｏ発行部２１０は、メタデータの場合は同時にメタデータ一時記憶表２１３にも登録し、さらに読み込みに際してはメタデータ一時記憶表２１３に当該メタデータがあればその値を返す。   The I / O issuing unit 210 writes data on the specified memory to the metadata storage device 401 and the file data storage device 402, or reads the specified data onto the memory. At this time, the I / O issuing unit 210 registers the metadata in the metadata temporary storage table 213 at the same time, and further returns the value if the metadata exists in the metadata temporary storage table 213 at the time of reading.

サーバー情報表２１１は、ファイルシステムを構成するサーバー２のサーバーIDとIPアドレスの対応、及びルートディレクトリのFHを格納するメモリ上に確保された領域である。また、メタデータ記憶装置４０１には、サーバー情報表２１１と同じデータが格納されており、サーバー２を起動させた際にサーバー情報表２１１に読み込まれる。   The server information table 211 is an area secured on a memory for storing the correspondence between the server ID and the IP address of the server 2 constituting the file system and the FH of the root directory. The metadata storage device 401 stores the same data as the server information table 211 and is read into the server information table 211 when the server 2 is activated.

ファイル詳細情報表２１２は、ファイル詳細情報を格納するためのメモリ上に確保された領域である。   The file detailed information table 212 is an area secured on a memory for storing file detailed information.

メタデータ一時記憶表２１３は、メタデータをキャッシュするためのメモリ上に確保された領域である。   The metadata temporary storage table 213 is an area secured on a memory for caching metadata.

サーバー装置１内の各部の機能分担は、適宜変更して実装しても良い。例えば、ディレクトリエントリ参照／更新部２０５は、サーバー内ＦＨ検索部２０８の機能を包含しても良いし、ファイル／ディレクトリ生成部２０６は、ＦＨ生成部２０７の機能を包含しても良い。   The function sharing of each part in the server device 1 may be appropriately changed and implemented. For example, the directory entry reference / update unit 205 may include the function of the in-server FH search unit 208, and the file / directory generation unit 206 may include the function of the FH generation unit 207.

最後に、外部記憶装置４に含まれる各部が記憶する情報について説明する。   Finally, information stored in each unit included in the external storage device 4 will be described.

メタデータ記憶装置４０１は、ディレクトリエントリ、ファイル、ディレクトリの詳細情報、及びサーバー情報表２１１と同じサーバー２の構成情報などのファイルシステムの管理情報、いわゆるメタデータを記憶する記憶媒体である。   The metadata storage device 401 is a storage medium that stores directory entry, file, detailed directory information, and file system management information such as configuration information of the server 2 that is the same as the server information table 211, so-called metadata.

ファイルデータ記憶装置４０２は、ファイルのデータを記憶する記憶媒体である。なお、ファイルデータ記憶装置４０２とメタデータ記憶装置４０１は、物理的に別の媒体でも同一の媒体でも良い。   The file data storage device 402 is a storage medium that stores file data. Note that the file data storage device 402 and the metadata storage device 401 may be physically different media or the same media.

なお、クライアント１やサーバー２は、ファイル、ディレクトリの削除、属性情報の取得などのファイルシステムが通常持っている他の機能も備えているが、他の処理から容易に想到し得るため、ここでは説明を割愛する。   The client 1 and the server 2 also have other functions that the file system normally has such as deletion of files and directories, and acquisition of attribute information. I will omit the explanation.

ここで、クライアント１における、通信部１０１、マウント要求部１０２、メタデータ参照／更新部１０３、サーバー情報表更新部１０４、メタデータ問い合わせ部１０５、パス名解析部１０６、ファイル／ディレクトリ生成要求部１０７、および、ファイル詳細情報要求部１０８は、論理回路で構成される。各部は、適宜、クライアント１が備える図示されない半導体メモリにアクセスする。サーバー情報表１０９、およびメタデータ記憶部１１０は、クライアント１が備える図示されない半導体メモリ上に設けられる。   Here, in the client 1, the communication unit 101, the mount request unit 102, the metadata reference / update unit 103, the server information table update unit 104, the metadata inquiry unit 105, the path name analysis unit 106, and the file / directory generation request unit 107. The file detailed information requesting unit 108 is configured with a logic circuit. Each unit accesses a semiconductor memory (not shown) included in the client 1 as appropriate. The server information table 109 and the metadata storage unit 110 are provided on a semiconductor memory (not shown) provided in the client 1.

また、サーバー２における、通信部２０１、マウント応答部２０２、サーバー選定部２０３、ファイル／ディレクトリ生成要求部２０４、ディレクトリエントリ参照／更新部２０５、ファイル／ディレクトリ生成部２０６、ＦＨ生成部２０７、サーバー内ＦＨ検索部２０８、ファイル詳細情報問い合わせ部２０９、および、Ｉ／Ｏ発行部２１０は、論理回路で構成される。各部は、適宜、サーバー２が備える図示されない半導体メモリにアクセスする。サーバー情報表２１１、ファイル詳細情報表２１２、およびメタデータ一時記憶表２１３は、サーバー２が備える図示されない半導体メモリに記憶される。   In the server 2, the communication unit 201, mount response unit 202, server selection unit 203, file / directory generation request unit 204, directory entry reference / update unit 205, file / directory generation unit 206, FH generation unit 207, in the server The FH search unit 208, the file detailed information inquiry unit 209, and the I / O issue unit 210 are configured with logic circuits. Each unit accesses a semiconductor memory (not shown) included in the server 2 as appropriate. The server information table 211, the file detailed information table 212, and the metadata temporary storage table 213 are stored in a semiconductor memory (not shown) provided in the server 2.

外部記憶装置４は、例えば、ＨＤＤ（Hard-Disk Drive）やＳＳＤ(Solid State Drive)である。   The external storage device 4 is, for example, an HDD (Hard-Disk Drive) or an SSD (Solid State Drive).

また、クライアント１、およびサーバー２は、それぞれ、プログラム４３を備えるコンピュータ装置４０で実現することも出来る。   Further, the client 1 and the server 2 can each be realized by a computer device 40 that includes the program 43.

図１６は、コンピュータ装置４０の構成図である。コンピュータ装置４０は、バス４５で相互に接続されたプロセッサ４１、主記憶部４２、外部記憶装置４４を備える。ここで、例えば、主記憶部４２は半導体記憶装置、外部記憶装置４４はＨＤＤやＳＤＤである。主記憶部４２はプログラム４３を記憶している。   FIG. 16 is a configuration diagram of the computer device 40. The computer device 40 includes a processor 41, a main storage unit 42, and an external storage device 44 that are connected to each other via a bus 45. Here, for example, the main storage unit 42 is a semiconductor storage device, and the external storage device 44 is an HDD or an SDD. The main storage unit 42 stores a program 43.

クライアント１が記憶しているプログラム４３は、クライアント１として用いられるコンピュータ装置４０において、プロセッサ４１で実行されることにより、プロセッサ４１を通信部１０１、マウント要求部１０２、メタデータ参照／更新部１０３、サーバー情報表更新部１０４、メタデータ問い合わせ部１０５、パス名解析部１０６、ファイル／ディレクトリ生成要求部１０７、および、ファイル詳細情報要求部１０８として機能させる。主記憶部４２は、サーバー情報表１０９、および、メタデータ記憶部１１０を格納する。   The program 43 stored in the client 1 is executed by the processor 41 in the computer device 40 used as the client 1, thereby causing the processor 41 to communicate with the communication unit 101, the mount request unit 102, the metadata reference / update unit 103, The server information table update unit 104, the metadata inquiry unit 105, the path name analysis unit 106, the file / directory generation request unit 107, and the file detailed information request unit 108 are caused to function. The main storage unit 42 stores a server information table 109 and a metadata storage unit 110.

さらに、サーバー２が記憶しているプログラム４３は、サーバー２として用いられるコンピュータ装置４０において、プロセッサ４１で実行されることにより、プロセッサ４１を通信部２０１、マウント応答部２０２、サーバー選定部２０３、ファイル／ディレクトリ生成要求部２０４、ディレクトリエントリ参照／更新部２０５、ファイル／ディレクトリ生成部２０６、ＦＨ生成部２０７、サーバー内ＦＨ検索部２０８、ファイル詳細情報問い合わせ部２０９、および、Ｉ／Ｏ発行部２１０として機能させる。主記憶部４２は、サーバー情報表２１１、ファイル詳細情報表２１２、およびメタデータ一時記憶表２１３を格納する。   Further, the program 43 stored in the server 2 is executed by the processor 41 in the computer device 40 used as the server 2, thereby causing the processor 41 to communicate with the communication unit 201, mount response unit 202, server selection unit 203, file / Directory generation request unit 204, directory entry reference / update unit 205, file / directory generation unit 206, FH generation unit 207, in-server FH search unit 208, file detailed information inquiry unit 209, and I / O issue unit 210 Make it work. The main storage unit 42 stores a server information table 211, a file detailed information table 212, and a metadata temporary storage table 213.

サーバー２において、外部記憶装置４４または主記憶部４２は、メタデータ記憶装置４０１、および、ファイルデータ記憶装置４０２として機能する。   In the server 2, the external storage device 44 or the main storage unit 42 functions as a metadata storage device 401 and a file data storage device 402.

＜動作＞
次に、本発明の実施例の動作について詳細に説明する。なお、説明にあたって、クライアント１、サーバー２は、コンピュータ装置４０を用いて実現されていると仮定する。クライアント１、サーバー２のオペレーティングシステムは、UNIX（登録商標）や Linux（登録商標）であると仮定する。また、クライアント１、サーバー２は、EtherNet（登録商標）、InfiniBand（登録商標）など一般に利用可能なネットワークインターフェースを持ち、相互結合ネットワーク３を介して接続される。これにより、クライアント１は任意のサーバー２と通信可能であり、サーバー２はそのサーバー２以外の任意のサーバー２と通信可能である。 <Operation>
Next, the operation of the embodiment of the present invention will be described in detail. In the description, it is assumed that the client 1 and the server 2 are realized by using the computer device 40. It is assumed that the operating systems of the client 1 and the server 2 are UNIX (registered trademark) or Linux (registered trademark). The client 1 and the server 2 have generally available network interfaces such as EtherNet (registered trademark) and InfiniBand (registered trademark), and are connected via an interconnection network 3. Thereby, the client 1 can communicate with an arbitrary server 2, and the server 2 can communicate with an arbitrary server 2 other than the server 2.

１.ファイルのオープン処理
図７乃至図１１は、ファイルオープン処理の動作例のフローチャートである。図７及び図８はクライアント１側、図９乃至図１１はサーバー２側の動作フローチャートである。なお、これらのフローチャートは、クライアント１が、ファイルディレクトリを検索して、オープン対象のファイルのFHとファイル詳細情報を取得するまでの流れを示しており、その後のオープン処理については割愛されている。その後のオープン処理は、公知技術で実現できる。 1. File Open Process FIGS. 7 to 11 are flowcharts of an operation example of the file open process. 7 and 8 are operational flowcharts on the client 1 side, and FIGS. 9 to 11 are operational flowcharts on the server 2 side. These flowcharts show the flow from when the client 1 searches the file directory to acquire the FH and file detailed information of the file to be opened, and the subsequent open processing is omitted. Subsequent open processing can be realized by a known technique.

１．ａ.ファイルのオープン処理（クライアント１側）
クライアント１の動作は、メタデータ問い合わせ部１０５が中心となる。クライアント１上で動作するＡＰから、分散ファイルシステム５内のファイルに対してオープンシステムコールが呼び出されると、オペレーシングシステムのカーネルからメタデータ問い合わせ部１０５が起動されて、図７の処理が開始される。 1. a. File open processing (client 1 side)
The operation of the client 1 is centered on the metadata inquiry unit 105. When an open system call is called from the AP operating on the client 1 to a file in the distributed file system 5, the metadata inquiry unit 105 is activated from the kernel of the operating system, and the processing of FIG. 7 is started. The

最初に、メタデータ問い合わせ部１０５は、パス名解析部１０６により、指定されたパス名中の上位の名前を１つ抽出する（ステップ１）。パス名の末端、すなわち文字列としての終端、もしくは、作成対象の名前を検出した場合（ステップ２でＹＥＳ）、メタデータ問い合わせ部１０５は、図８の処理に進む。   First, the metadata inquiry unit 105 causes the path name analysis unit 106 to extract one upper name from the designated path name (step 1). When the end of the path name, that is, the end as a character string, or the name to be created is detected (YES in step 2), the metadata inquiry unit 105 proceeds to the process of FIG.

パス名の末端、もしくは作成対象の名前以外を検出した場合（ステップ２のＮＯ）、メタデータ問い合わせ部１０５は、抽出した名前がメタデータ記憶部１１０に既に登録されているかどうかを、メタデータ参照／更新部１０３により調べる（ステップ３）。登録されている場合は（ステップ４でＹＥＳ）、メタデータ問い合わせ部１０５はステップ１に戻る。   When the end of the path name or a name other than the name to be created is detected (NO in step 2), the metadata inquiry unit 105 refers to the metadata whether or not the extracted name is already registered in the metadata storage unit 110. / Check by the update unit 103 (step 3). If registered (YES in step 4), the metadata inquiry unit 105 returns to step 1.

登録されていない場合は（ステップ４でＮＯ）、メタデータ問い合わせ部１０５は、まず、上位ディレクトリのFHから問い合わせ先のサーバー２を特定し（ステップ５）、該サーバー２へ上位ディレクトリのFH、問い合わせ対象の名前を送信する（ステップ６）。メタデータ問い合わせ部１０５は、問い合わせ先のサーバー２からFHとファイルタイプを受信すると、それらを名前と共にメタデータ参照／更新部１０３によりメタデータ記憶部１１０に登録する（ステップ７）。   If it is not registered (NO in step 4), the metadata inquiry unit 105 first identifies the server 2 to be inquired from the FH of the upper directory (step 5), and asks the server 2 for the FH of the upper directory and the inquiry. The target name is transmitted (step 6). When the metadata inquiry unit 105 receives the FH and file type from the inquired server 2, the metadata inquiry unit 105 registers them together with the name in the metadata storage unit 110 by the metadata reference / update unit 103 (step 7).

図７のステップ２でＹＥＳとなり、図８の処理に進んだ場合、メタデータ問い合わせ部１０５は、ファイル詳細情報要求部１０８により、オープン対象のファイルの名前のファイル詳細情報、及びFHを、そのファイルの上位ディレクトリを管理するサーバー２へ問い合わせる。   When the result of step 2 in FIG. 7 is YES and the processing proceeds to the processing in FIG. 8, the metadata inquiry unit 105 uses the file detailed information request unit 108 to specify the file detailed information and the FH of the name of the file to be opened. An inquiry is made to the server 2 that manages the upper directory of.

図８において、メタデータ問い合わせ部１０５は、メタデータ参照／更新部１０３により、オープン対象のファイルの名前が既にメタデータ記憶部１１０に登録されているかを調べ（ステップ１１）、既に登録されている場合（ステップ１２でＹＥＳ）、動作を終了する。登録されていない場合（ステップ１２でＮＯ）、メタデータ問い合わせ部１０５は、上位ディレクトリのFHより問い合わせ先のサーバー２を特定し（ステップ１３）、オープン対象ファイルの名前に相当するFH、及びファイル詳細情報を含む問い合わせを該サーバー２へ送信する（ステップ１４）。なお、この問い合わせは、１）上位ディレクトリを管理するサーバー２が保持するオープン対象ファイルの名前に相当するFH、及び、ファイルタイプの問い合わせと、２）オープン対象ファイルを管理するサーバー２が保持するファイル詳細情報の問い合わせの２つの問い合わせをまとめた問い合わせである。   In FIG. 8, the metadata inquiry unit 105 uses the metadata reference / update unit 103 to check whether the name of the file to be opened has already been registered in the metadata storage unit 110 (step 11), and has already been registered. If so (YES in step 12), the operation is terminated. If not registered (NO in step 12), the metadata inquiry unit 105 identifies the server 2 to be inquired from the FH in the upper directory (step 13), the FH corresponding to the name of the file to be opened, and the file details An inquiry including information is transmitted to the server 2 (step 14). This inquiry includes 1) an inquiry of the FH corresponding to the name of the file to be opened held by the server 2 that manages the upper directory and a file type, and 2) a file that is held by the server 2 that manages the file to be opened. This is a query that combines two queries for detailed information.

FH、ファイルタイプと共にファイル詳細情報を受信した場合（ステップ１５でＹＥＳ）、メタデータ問い合わせ部１０５は、ステップ９の実施後動作を終了する。ファイル詳細情報は返されず、FHとファイルタイプが返された場合（ステップ１５でＮＯ）、メタデータ問い合わせ部１０５は、返されたFHとファイルタイプをメタデータ参照／更新部１０３により一旦メタデータ記憶部１１０に登録する（ステップ１６）。さらに、メタデータ問い合わせ部１０５は、ファイル詳細情報要求部１０８により、返されたFHを基にオープン対象ファイルを管理するサーバー２を特定し（ステップ１７）、該サーバー２へFHを指定してオープン対象のファイルのファイル詳細情報を問い合わせる（ステップ１８）。その後、メタデータ問い合わせ部１０５は、ファイル詳細情報要求部１０８が受信した該ファイル詳細情報を、FH、名前と共にメタデータ参照／更新部１０３によりメタデータ記憶部１１０に登録する（ステップ１９）。   When the file detailed information is received together with the FH and file type (YES in step 15), the metadata inquiry unit 105 ends the operation after the execution of step 9. If the file detailed information is not returned and FH and file type are returned (NO in step 15), the metadata inquiry unit 105 uses the metadata reference / update unit 103 to convert the returned FH and file type into metadata once. Register in the storage unit 110 (step 16). Further, the metadata inquiry unit 105 specifies the server 2 that manages the file to be opened based on the returned FH by the file detailed information request unit 108 (step 17), and specifies the FH to the server 2 and opens it. The file detailed information of the target file is inquired (step 18). Thereafter, the metadata inquiry unit 105 registers the file detailed information received by the file detailed information request unit 108 in the metadata storage unit 110 by the metadata reference / update unit 103 together with the FH and name (step 19).

メタデータ問い合わせ部１０５による図８の動作が終了すると、クライアント１上では、メタデータ記憶部１１０上のファイルの名前、FH、ファイル詳細情報を用いて、オープンシステムコールの処理が続行される。   When the operation of FIG. 8 by the metadata inquiry unit 105 is completed, the open system call processing is continued on the client 1 using the file name, FH, and file detailed information on the metadata storage unit 110.

１．ｂ.ファイルのオープン処理（サーバー２側）
図９乃至１１は、図７のステップ６、図８のステップ１４、およびステップ１８においてサーバー２への問い合わせをクライアント１が行った際のサーバー２側の処理の例を示す。クライアント１からの当合わせはサーバー２において、通信部２０１により受信される。 1. b. File open processing (Server 2 side)
9 to 11 show examples of processing on the server 2 side when the client 1 makes an inquiry to the server 2 in step 6, FIG. 7, step 14, and step 18 in FIG. Matching from the client 1 is received by the communication unit 201 in the server 2.

図９において、通信部２０１は、受信されたクライアント１からのリクエスト（問い合わせ）を、リクエスト内容判別部２０１−７により何のリクエストかを調べる。そのリクエストがFHで示されたディレクトリ配下のファイルのファイル詳細情報とFH、ファイルタイプを要求するものであった場合（ステップ２１でＹＥＳ）、通信部２０１は、リクエスト処理デーモン数判別／更新部２０１−５によりリクエスト処理デーモン数カウンタ２０１−６を参照し、待ち状態の同デーモンの数を確認する（ステップ２２）。   In FIG. 9, the communication unit 201 checks the request (inquiry) from the received client 1 by the request content determination unit 201-7. When the request is for requesting the file detailed information, FH, and file type of the file under the directory indicated by FH (YES in step 21), the communication unit 201 determines the number of request processing daemons / update unit 201. The request processing daemon number counter 201-6 is referred to by -5, and the number of the waiting daemons is confirmed (step 22).

同デーモン数が２個以上である場合（ステップ２３でＮＯ）、通信部２０１は、図１１のファイルのFH、ファイルタイプ、及び、ファイル詳細情報取得処理に進む。１個以下である場合（ステップ２３でＹＥＳ）、通信部２０１は、リクエスト内容変更部２０１−４により、リクエストの内容を該ファイルのFHとファイルタイプの問い合わせのみに書き換える（ステップ２４）。次に、通信部２０１は、そのリクエストをリクエスト処理デーモンに渡し（ステップ２５）、図１０のファイルのFHとファイルタイプ取得処理に進む。   When the number of daemons is two or more (NO in step 23), the communication unit 201 proceeds to the process of acquiring the file FH, file type, and file detailed information in FIG. If the number is one or less (YES in step 23), the communication unit 201 rewrites the request content to only the FH and file type inquiry of the file by the request content change unit 201-4 (step 24). Next, the communication unit 201 passes the request to the request processing daemon (step 25), and proceeds to the file FH and file type acquisition processing in FIG.

なお、受信したリクエストがFHで示されたディレクトリ配下のファイルのFHとファイルタイプを要求するものであった場合（ステップ２１でＮＯ）、通信部２０１は、そのリクエストをリクエスト処理デーモンに渡し（ステップ２５）、図１０のファイルのFHとファイルタイプ取得処理に進む。   If the received request is a request for the FH and file type of a file under the directory indicated by FH (NO in step 21), the communication unit 201 passes the request to the request processing daemon (step 25), the process proceeds to FH and file type acquisition processing of the file in FIG.

図９でステップ２５を実施した場合は、図１０において、ディレクトリエントリ参照／更新部２０５は、サーバー内ＦＨ検索部２０８により、受信したFHをキーとして該当するディレクトリを特定する（ステップ３１）。ディレクトリエントリ参照／更新部２０５は、さらにそのディレクトリから、名前をキーとして該当するエントリを特定することで、名前に対応するFHとファイルタイプを抽出し、要求元のクライアント１へ送信し（ステップ３２）、処理を終了する。   When step 25 is performed in FIG. 9, in FIG. 10, the directory entry reference / update unit 205 identifies the corresponding directory by using the received FH as a key by the intra-server FH search unit 208 (step 31). The directory entry reference / update unit 205 further extracts the FH and file type corresponding to the name from the directory by specifying the corresponding entry using the name as a key, and transmits it to the requesting client 1 (step 32). ), The process is terminated.

図９で、リクエスト処理デーモン数が２個以上である場合（ステップ２３でＮＯ）、図１１において、ディレクトリエントリ参照／更新部２０５は、サーバー内ＦＨ検索部２０８により、受信したFHをキーとして該当するディレクトリを特定する（ステップ４１）。ディレクトリエントリ参照／更新部２０５は、さらにそのディレクトリから、名前をキーとして該当するエントリを特定することで、名前に対応するFHとファイルタイプを抽出する（ステップ４２）。   In FIG. 9, when the number of request processing daemons is two or more (NO in step 23), in FIG. 11, the directory entry reference / update unit 205 uses the received FH as a key by the in-server FH search unit 208. The directory to be executed is specified (step 41). The directory entry reference / update unit 205 further extracts the FH and file type corresponding to the name by specifying the corresponding entry using the name as a key from the directory (step 42).

続いてディレクトリエントリ参照／更新部２０５は、ファイル詳細情報表２１２を検索し、該ファイルのファイル詳細情報が登録されているかどうかを確認する（ステップ４３）。   Subsequently, the directory entry reference / update unit 205 searches the file detailed information table 212 and confirms whether the file detailed information of the file is registered (step 43).

登録されていた場合（ステップ４３でＹＥＳ）、ディレクトリエントリ参照／更新部２０５は、FHとファイルタイプと共に該ファイル詳細情報を要求元のクライアント１へ返却し（ステップ４４）、処理を終了する。登録されていない場合（ステップ４３でＮＯ）、該ファイルのファイル詳細情報をファイル詳細情報問い合わせ部２０９が、該ファイルを管理するサーバー２へ問い合わせる（ステップ４５）。このとき、サーバー特定部２０１−８が、該ファイルのFHからサーバー２を特定する。   If registered (YES in step 43), the directory entry reference / update unit 205 returns the file detailed information together with the FH and the file type to the requesting client 1 (step 44), and ends the process. If not registered (NO in step 43), the file detailed information inquiry unit 209 inquires of the server 2 that manages the file about the file detailed information of the file (step 45). At this time, the server identification unit 201-8 identifies the server 2 from the FH of the file.

問い合わせ先の該サーバー２、すなわち、該ファイルを管理するサーバー２からファイル詳細情報を受信すると、ディレクトリエントリ参照／更新部２０５は、これをファイル詳細情報表２１２へ登録し（ステップ４６）、要求元のクライアント１へFH、ファイルタイプと共に該ファイル詳細情報を送信し（ステップ４７）、処理を終了する。   Upon receiving the file detailed information from the server 2 that is the inquiry destination, that is, the server 2 that manages the file, the directory entry reference / update unit 205 registers this in the file detailed information table 212 (step 46), and the request source The detailed file information is transmitted together with the FH and file type to the client 1 (step 47), and the process is terminated.

なお、問い合わせ先のサーバー２では、ディレクトリエントリ参照／更新部２０５が問い合わせ元のサーバー２（該ファイルが存在するディレクトリを管理するサーバー２）が送信したFH受信する。そして、ディレクトリエントリ参照／更新部２０５が、サーバー内ＦＨ検索部２０８により、メタデータ一時記憶表２１３またはメタデータ記憶装置４０１を検索し、受信したFHに対応するファイル詳細情報を読み出して、問い合わせ元のサーバー２へ返却する。   In the inquiry destination server 2, the directory entry reference / update unit 205 receives the FH transmitted from the inquiry origin server 2 (the server 2 that manages the directory in which the file exists). Then, the directory entry reference / update unit 205 searches the metadata temporary storage table 213 or the metadata storage device 401 by the in-server FH search unit 208, reads out the file detailed information corresponding to the received FH, and sends the inquiry source Return to server 2.

２. ファイル、ディレクトリの生成処理
図１２および図１３は、サーバー２におけるファイル、ディレクトリ生成処理の動作例のフローチャートである。 2. File and Directory Generation Processing FIGS. 12 and 13 are flowcharts of operation examples of file and directory generation processing in the server 2.

クライアント１上で動作するＡＰから、create/openシステムコール、または、mkdirシステムコールが呼び出されると、オペレーシングシステムのカーネルからメタデータ問い合わせ部１０５が起動されて、当該システムコールにおいて指定されたパス名を基に、生成するファイル、ディレクトリを作成するディレクトリのFHを取得する。その後、ファイル／ディレクトリ生成要求部１０７が起動され、該当するサーバー２へその生成を要求する。   When the create / open system call or the mkdir system call is called from the AP operating on the client 1, the metadata inquiry unit 105 is activated from the kernel of the operating system, and the path name specified in the system call. Based on, get FH of directory to create file and directory. Thereafter, the file / directory generation request unit 107 is activated to request the corresponding server 2 to generate it.

図１２は、ファイル、ディレクトリを作成するディレクトリを管理するサーバー２側、図１３は、ファイル、ディレクトリを生成するサーバー２側の動作フローチャートである。ここで、ファイル、ディレクトリを作成するディレクトリとは、新たに生成されたファイル、ディレクトリの上位ディレクトリとなるディレクトリである。   FIG. 12 is an operation flowchart on the server 2 side for managing a directory for creating files and directories, and FIG. 13 is an operation flowchart on the server 2 side for generating files and directories. Here, the directory in which the file and directory are created is a directory that is an upper directory of the newly generated file and directory.

２．ａ.ファイル、ディレクトリの生成処理（上位ディレクトリを管理するサーバー２側）
図１２において、クライアント１から生成要求を受信すると、ファイル／ディレクトリ生成要求部２０４が起動される。ファイル／ディレクトリ生成要求部２０４は、サーバー選定部２０３により新たに生成するファイル、ディレクトリを管理するサーバー２を選定し（ステップ５１）、選定したサーバー２へファイル、ディレクトリの作成要求としてファイルタイプと名前、ファイル、ディレクトリのパーミッションに関する情報を送信する（ステップ５２）。 2. a. File and directory generation processing (server 2 side managing the upper directory)
In FIG. 12, when a generation request is received from the client 1, the file / directory generation request unit 204 is activated. The file / directory creation request unit 204 selects the server 2 that manages the file and directory newly generated by the server selection unit 203 (step 51), and sends the file type and name to the selected server 2 as a file / directory creation request. , Information on file and directory permissions is transmitted (step 52).

ファイル／ディレクトリ生成要求部２０４は、作成要求先のサーバー２から、生成したファイル、ディレクトリのFHを、ファイルの場合はファイル詳細情報も、受信する。ディレクトリエントリ参照／更新部２０５は、受信したFHとファイルタイプ及び名前をＩ／Ｏ発行部２１０を経てメタデータ一時記憶表２１３、及びメタデータ記憶装置４０１へ新たなディレクトリエントリとして登録する（ステップ５３）。   The file / directory generation request unit 204 also receives the generated file and directory FH from the creation request destination server 2 and, in the case of a file, file detailed information. The directory entry reference / update unit 205 registers the received FH, file type, and name as a new directory entry in the metadata temporary storage table 213 and the metadata storage device 401 via the I / O issuing unit 210 (step 53). ).

また、ファイルを生成した場合は（ステップ５４でＹＥＳ）、ディレクトリエントリ参照／更新部２０５は、さらに、受信したファイル詳細情報をファイル詳細情報表２１２に登録する（ステップ５５）。この後、通信部２０１が、受信したファイル、ディレクトリのFHを、ファイルを生成した場合はそのファイルのファイル詳細情報も、要求元のクライアント１へ送信して（ステップ５６）、処理を終了する。   When a file is generated (YES in step 54), the directory entry reference / update unit 205 further registers the received file detailed information in the file detailed information table 212 (step 55). Thereafter, when the communication unit 201 generates the FH of the received file or directory, the file detailed information of the file is also transmitted to the requesting client 1 (step 56), and the process is terminated.

２．ｂ.ファイル、ディレクトリの生成処理（作成するサーバー２側）
図１２のステップ５２でファイル、ディレクトリの生成要求を受信したサーバー２は、図１３のフローチャートのように動作する。 2. b. File and directory generation processing (server 2 side to be created)
The server 2 that has received the file / directory generation request in step 52 of FIG. 12 operates as shown in the flowchart of FIG.

生成要求を受信したファイル／ディレクトリ生成部２０６は、ＦＨ生成部２０７により自サーバー２のサーバーIDと自サーバー２内で一意な番号を組み合わせることで、ファイルシステム内で一意なFHを生成する（ステップ６１）。次に、ファイル／ディレクトリ生成部２０６は、このFHと共にファイル、ディレクトリの詳細情報としてファイルのパーミッション、生成時刻などをＩ／Ｏ発行部２１０を経て、メタデータ一時記憶表２１３及びメタデータ記憶装置４０１に登録する（ステップ６２）。   The file / directory generation unit 206 that has received the generation request generates a unique FH in the file system by combining the server ID of the server 2 and a number unique in the server 2 by the FH generation unit 207 (step S1). 61). Next, the file / directory generation unit 206 sends the file permission, generation time, and the like as detailed information of the file and directory together with the FH through the I / O issuing unit 210, the metadata temporary storage table 213, and the metadata storage device 401. (Step 62).

この後、ファイル／ディレクトリ生成部２０６は、要求元のサーバー２へこれら情報を返して（ステップ６３）、処理を終了する。   Thereafter, the file / directory generation unit 206 returns these pieces of information to the requesting server 2 (step 63), and ends the process.

３. マウント処理
図１４および図１５は、マウント処理の動作例のフローチャートである。図１４はクライアント１側、図１５はサーバー２側の動作フローチャートである。 3. Mount Processing FIG. 14 and FIG. 15 are flowcharts of an operation example of the mount processing. FIG. 14 is an operation flowchart on the client 1 side, and FIG. 15 is an operation flowchart on the server 2 side.

３．ａ.マウント処理（クライアント１側）
図１４において、クライアント１のユーザがmountコマンドを入力、または、クライアント１上のＡＰがマウントシステムコールを呼び出すと、マウント要求部１０２がオペレーティングシステムから起動される。mountコマンド、または、mountシステムコールは、ルートサーバーであるサーバー２を指定しており、マウント要求部１０２は、指定されているサーバー２へマウント要求を送信する（ステップ７１）。 3. a. Mount processing (client 1 side)
In FIG. 14, when the user of the client 1 inputs a mount command or the AP on the client 1 calls a mount system call, the mount request unit 102 is activated from the operating system. The mount command or mount system call specifies the server 2 that is the root server, and the mount request unit 102 transmits a mount request to the specified server 2 (step 71).

マウント要求部１０２は、該サーバー２から、ルートディレクトリのFH、ファイルシステムを構成する全サーバー２のサーバーIDとIPアドレスの対応表を含む応答を受信し（ステップ７２）、同対応表を、サーバー情報更新部１０４によりサーバー情報表１０９に登録する（ステップ７３）。マウント要求部１０２は、ルートディレクトリのFHをメタデータ参照／更新部１０３によりメタデータ記憶部１１０に登録して（ステップ７４）、処理を終了する。   The mount request unit 102 receives from the server 2 a response including the FH of the root directory and the server ID and IP address correspondence table of all servers 2 constituting the file system (step 72). Information is registered in the server information table 109 by the information updating unit 104 (step 73). The mount request unit 102 registers the FH of the root directory in the metadata storage unit 110 by the metadata reference / update unit 103 (step 74), and ends the process.

３．ｂ.マウント処理（サーバ２側）
図１５において、マウント応答部２０２は、サーバー情報表２１１を参照し、ファイルシステムを構成する全サーバー２のサーバーIDとIPアドレスの対応表、及びルートディレクトリのFHの値を読み出し（ステップ８１）、要求元のクライアント１へ送信して（ステップ８２）、処理を終了する。 3. b. Mount processing (server 2 side)
In FIG. 15, the mount response unit 202 reads the server ID and IP address correspondence table of all the servers 2 constituting the file system and the FH value of the root directory with reference to the server information table 211 (step 81). The data is transmitted to the requesting client 1 (step 82), and the process is terminated.

なお、サーバー２での各リクエストの処理において、リクエスト処理デーモン数判別／更新部２０１−５は、リクエスト処理デーモン数カウンタ２０１−６の値をリクエストの処理開始時に１増加させ、リクエストの処理終了時に１減少させる。   In the processing of each request in the server 2, the request processing daemon number discrimination / update unit 201-5 increments the value of the request processing daemon number counter 201-6 by 1 at the start of request processing, and at the end of request processing. Decrease by 1.

＜効果＞
本実施の形態にかかるファイル分散システム５の効果は以下の通りである。 <Effect>
The effects of the file distribution system 5 according to the present embodiment are as follows.

第１の効果は、多数のクライアント１での同一ファイルへのオープン処理により、そのリクエストが対象ファイルを管理するサーバー２とその上位ディレクトリを管理するサーバー２に集中した場合において、サーバー２間の通信回数を削減できることである。   The first effect is that communication between the servers 2 when the requests are concentrated on the server 2 that manages the target file and the server 2 that manages the upper directory by the open processing to the same file in many clients 1. The number of times can be reduced.

その理由は、上位ディレクトリを管理するサーバー２が、当該ファイルの詳細情報を、ファイルを管理するサーバー２から最初に取得した際に、ファイル詳細情報表２１２に保持するからである。このため、２度目以降のリクエストにおいては、上位ディレクトリを管理するサーバー２とファイルを管理するサーバー２との間の通信が不要となる。   The reason is that the server 2 that manages the upper directory holds the detailed information of the file in the file detailed information table 212 when it first acquires the detailed information of the file from the server 2 that manages the file. For this reason, in the second and subsequent requests, communication between the server 2 that manages the upper directory and the server 2 that manages the file becomes unnecessary.

第２の効果は、多数のクライアント１での同一ディレクトリ配下の異なるファイルへのオープン処理により、そのリクエストが当該ディレクトリを管理するサーバー２に集中した場合において、当該サーバー２がボトルネックになるのを防止できることである。   The second effect is that when the requests are concentrated on the server 2 that manages the directory by the open processing to different files under the same directory in many clients 1, the server 2 becomes a bottleneck. It can be prevented.

その理由は、当該ディレクトリを管理するサーバー２のI/O多重度が高くなり、デーモンがすべて使用中になった場合、該サーバー２がディレクトリエントリ内に保持しているFH、及びファイルタイプのみをクライアント１へ返すからである。その後そのFHを基にクライアント１が、オープン対象のファイルを管理するサーバー２を特定し、そのサーバー２に問い合わせを行う。オープン対象の各ファイルは、それぞれ各サーバー２に分散配置されているため、このリクエストの送信先もクライアント１毎に分散されることになる。このため、アクセスが集中するディレクトリを管理するサーバー２のデーモンがすべて使用中であったとしても待ちが発生せず、クライアント１に対するTATが悪化しない。   The reason is that when the I / O multiplicity of the server 2 managing the directory becomes high and all the daemons are in use, only the FH and file type that the server 2 holds in the directory entry are displayed. This is because it is returned to the client 1. Thereafter, based on the FH, the client 1 specifies a server 2 that manages the file to be opened, and makes an inquiry to the server 2. Since each file to be opened is distributed to each server 2, the transmission destination of this request is also distributed for each client 1. For this reason, even if all the daemons of the server 2 managing the directory where access is concentrated are in use, no waiting occurs and the TAT for the client 1 does not deteriorate.

第３の効果は、ファイルへのread/write処理だけではなく、ファイルのオープン処理などのメタデータアクセス処理も複数のサーバー２で分散処理できることである。つまり、多数のクライアント１が同一ファイルシステムにアクセスする場合でも、read/write処理、メタデータ処理の両面において負荷分散できる。   The third effect is that not only read / write processing to a file but also metadata access processing such as file opening processing can be distributed by a plurality of servers 2. That is, even when many clients 1 access the same file system, the load can be distributed in both the read / write process and the metadata process.

その理由は、ファイルのデータだけではなく、ファイル／ディレクトリの詳細情報やディレクトリエントリ等のメタデータもファイル、ディレクトリ毎に複数のサーバー２に分散して配置することが可能だからである。   The reason is that not only file data but also metadata such as detailed information of files / directories and directory entries can be distributed and arranged in a plurality of servers 2 for each file and directory.

第４の効果は、ファイル、ディレクトリの生成の際に行われる、生成対象ファイル、ディレクトリを管理するサーバー２の選定において、システム全体として管理する情報の更新や排他制御により、システム全体のスループットを妨げないことである。   The fourth effect is that when the server 2 that manages the generation target file and directory is selected when generating the file and directory, the throughput of the entire system is hindered by updating the information managed as the entire system and exclusive control. It is not.

その理由は、その上位ディレクトリを管理するサーバー２が、生成対象ファイル、ディレクトリを管理するサーバー２を、サーバー情報表２１１から選定するからである。このため、サーバー２の選定に際して、システム全体として管理する情報の更新や排他制御が不要となる。   The reason is that the server 2 that manages the upper directory selects from the server information table 211 the server 2 that manages the generation target file and directory. For this reason, when selecting the server 2, it is not necessary to update or exclusively control information managed as the entire system.

第５の効果は、同一ディレクトリ配下に多数のファイル、ディレクトリを生成しても、特定のサーバー２配下にこれらファイルデータ、メタデータが偏って配置されることはなく、容量、負荷の両面において適正に分散させることが可能なことである。   The fifth effect is that even if a large number of files and directories are generated under the same directory, these file data and metadata are not unevenly distributed under the specific server 2 and are appropriate in both capacity and load. It is possible to be dispersed.

その理由は、上位ディレクトリを管理するサーバー２が、新たに生成するファイル、ディレクトリを管理するサーバー２をサーバー情報表２１１から選定する際、名前に依存しない、例えば、ラウンドロビンや一様乱数などに基づく方法を取るからである。   The reason is that when the server 2 that manages the upper directory selects the newly generated file or server 2 that manages the directory from the server information table 211, it does not depend on the name, for example, round robin or uniform random number. Because it takes a method based on.

第６の効果は、クライアント１が、２度目以降の同一ディレクトリ配下へのファイルのオープン処理などメタデータアクセスを伴う処理において、サーバー２との通信回数を削減できることである。   The sixth effect is that the client 1 can reduce the number of times of communication with the server 2 in the process involving the metadata access such as the file open process under the same directory for the second time or later.

その理由は、ファイルを管理するサーバー２を特定する際、クライアント１上にメタデータをキャッシュするからである。例えば、オープン処理で同じディレクトリ配下の複数のファイルを同一クライアント１が続けてアクセスすることは、決して少なくない。メタデータのキャッシュにより、ファイルアクセスの都度、ルートサーバーからファイルを管理するサーバー２を辿る処理は不要になる。このため、処理効率が大幅に向上する。   This is because the metadata is cached on the client 1 when the server 2 that manages the file is specified. For example, the same client 1 often accesses a plurality of files under the same directory in open processing. The metadata cache eliminates the need to trace the server 2 that manages the file from the root server every time the file is accessed. For this reason, the processing efficiency is greatly improved.

第７の効果は、名前に関する問題が軽減され、エンドユーザが通常行うファイル名変更やハードリンク利用の操作の処理が煩雑にならないことである。   The seventh effect is that the problem relating to the name is reduced, and the file name change and hard link use operations normally performed by the end user are not complicated.

その理由は、ファイル名を変更する場合は、その上位ディレクトリのディレクトリエントリ内の名前を書き換えるだけでよいからである。また、ハードリンクは、例えばディレクトリエントリ内に名前は異なるが同一のFH、ファイルタイプを持つエントリを作り、対象となるファイルを管理するサーバー２で該ファイルのファイル詳細情報のリンク数をカウントアップすることで実現可能となる。このため、本実施の形態にかかるファイル分散システム５は、特許文献１、２、または、非特許文献１のシステム等において発生するような問題を生じない。   The reason is that when the file name is changed, it is only necessary to rewrite the name in the directory entry of the upper directory. Hard links are created, for example, in the directory entry with different names but the same FH and file type, and the server 2 that manages the target file counts up the number of links of the file detailed information of the file. This is possible. For this reason, the file distribution system 5 according to the present embodiment does not cause a problem that occurs in the systems of Patent Documents 1 and 2, or Non-Patent Document 1.

以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。   While the present invention has been described with reference to the embodiments, the present invention is not limited to the above embodiments. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

本発明は、HPC (High Performance Computing) やビッグデータ解析のような分野において利用できる。特に、単一のノード、単一のCPUでは現実的な時間での計算や解析が不可能な多量のデータや計算量の処理を、多数のノードに分割して行うような並列計算機システムまたは分散処理基盤におけるデータストアに利用できる。   The present invention can be used in fields such as HPC (High Performance Computing) and big data analysis. In particular, a parallel computer system or distributed system that divides a large number of nodes and processes a large amount of data that cannot be calculated and analyzed in a realistic time with a single node and single CPU. It can be used as a data store in the processing infrastructure.

１ クライアント
１ クライアント装置
２ サーバー
２ サーバー装置
３ 相互結合ネットワーク
４ 外部記憶装置
５ 分散ファイルシステム
４０ コンピュータ装置
４１ プロセッサ
４２ 主記憶部
４３ プログラム
４４ 外部記憶装置
４５ バス
１０１ 通信部
１０１−１ リクエスト作成部
１０１−２ サーバー特定部
１０２ マウント要求部
１０３ メタデータ参照／更新部
１０４ サーバー情報表更新部
１０５ メタデータ問い合わせ部
１０６ パス名解析部
１０７ ファイル／ディレクトリ生成要求部
１０８ ファイル詳細情報要求部
１０９ サーバー情報表
１１０ メタデータ記憶部
２０１ 通信部
２０１−１ リクエスト作成部
２０１−２ リクエスト応答部
２０１−３ リクエスト受信部
２０１−４ リクエスト内容変更部
２０１−５ リクエスト処理デーモン数判別／更新部
２０１−６ リクエスト処理デーモン数カウンタ
２０１−７ リクエスト内容判別部
２０１−８ サーバー特定部
２０２ マウント応答部
２０３ サーバー選定部
２０４ ファイル／ディレクトリ生成要求部
２０５ ディレクトリエントリ参照／更新部
２０６ ファイル／ディレクトリ生成部
２０７ ＦＨ生成部
２０８ サーバー内ＦＨ検索部
２０９ ファイル詳細情報問い合わせ部
２１０ Ｉ／Ｏ発行部
２１１ サーバー情報表
２１２ ファイル詳細情報表
２１３ メタデータ一時記憶表
４０１ メタデータ記憶装置
４０２ ファイルデータ記憶装置 DESCRIPTION OF SYMBOLS 1 Client 1 Client apparatus 2 Server 2 Server apparatus 3 Interconnection network 4 External storage device 5 Distributed file system 40 Computer apparatus 41 Processor 42 Main storage part 43 Program 44 External storage apparatus 45 Bus 101 Communication part 101-1 Request preparation part 101- 2 Server identification unit 102 Mount request unit 103 Metadata reference / update unit 104 Server information table update unit 105 Metadata inquiry unit 106 Path name analysis unit 107 File / directory generation request unit 108 File detailed information request unit 109 Server information table 110 Meta Data storage unit 201 Communication unit 201-1 Request creation unit 201-2 Request response unit 201-3 Request reception unit 201-4 Request content change unit 201-5 Request Processing daemon number determination / update unit 201-6 request processing daemon number counter 201-7 request content determination unit 201-8 server identification unit 202 mount response unit 203 server selection unit 204 file / directory generation request unit 205 directory entry reference / update Unit 206 File / directory generation unit 207 FH generation unit 208 In-server FH search unit 209 File detailed information inquiry unit 210 I / O issue unit 211 Server information table 212 File detailed information table 213 Metadata temporary storage table 401 Metadata storage device 402 File data storage device

Claims (10)

ファイルを記憶するファイルデータ記憶装置と、
ディレクトリ階層における直下のディレクトリ、または、ファイルの、ａ）識別子であって、当該ディレクトリ、または、当該ファイルを管理するサーバー装置の識別情報であるサーバーIDを含むファイルハンドル（以降、ＦＨと略記）、ｂ）名前、および、ｃ）ファイルまたはディレクトリの区別を示すファイルタイプを関連付けて記憶するディレクトリ、および、前記ファイルデータ記憶装置に記憶されているファイルのファイル詳細情報を記憶するメタデータ記憶装置と、に接続され、
ファイル詳細情報のキャッシュ用メモリ領域であるファイル詳細情報表と、
クライアント装置、若しくは、他の前記サーバー装置から処理リクエストを受信、または、他の前記サーバー装置にリクエストを送信するとともに、処理中または送信中のリクエスト数をカウントする通信部と、
ファイルのＦＨを入力されると、ＦＨが包含するサーバーIDの前記サーバー装置にファイル詳細情報を要求するリクエストを送信して、ファイル詳細情報を受信するファイル詳細情報問い合わせ部と、
クライアント装置から、ディレクトリ階層における直下のファイルの名前を含む、１）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、２）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストが受信されたとき、ａ）前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のファイルのＦＨとファイルタイプを取得し、ｂ１）前記通信部がカウントしたリクエスト数が所定閾値を超えておらず、ｃ１）受信された名前のファイルのファイル詳細情報が前記ファイル詳細情報表にキャッシュされていれば、キャッシュされているファイル詳細情報を取得し、ｃ２）前記ファイル詳細情報表にキャッシュされていなければ、取得したファイルのＦＨを前記ファイル詳細情報問い合わせ部に入力してファイル詳細情報を取得して、前記ファイル詳細情報表にキャッシュし、取得したファイルのＦＨ、ファイルタイプとファイル詳細情報とを前記クライアント装置に返信し、ｂ２）前記通信部がカウントしたリクエスト数が所定閾値を超えている場合は、入力されたリクエストを変更してファイル詳細情報の出力を中止し、取得したファイルのＦＨ、ファイルタイプを前記クライアント装置に返信し、
また、前記サーバー装置から返信されたファイルのＦＨを、改めてファイルを管理する前記サーバー装置に送信する前記クライアント装置から、または、他の前記サーバー装置の前記ファイル詳細情報問い合わせ部から、前記ファイルデータ記憶装置に記憶されているファイル、のＦＨを含むリクエストが受信されると、前記メタデータ記憶装置から、入力されたＦＨを識別子とするファイルのファイル詳細情報を取得して返信するディレクトリエントリ参照／更新部と、を備えたサーバー装置。 A file data storage device for storing files;
A) a file handle (hereinafter abbreviated as FH) including a server ID which is an identifier of a directory or file immediately below in the directory hierarchy and is an identification information of the server device managing the directory or the file; a metadata storage device for storing b) a name and c) a directory for storing a file type indicating a distinction between files or directories in association with each other, and a file detailed information of the file stored in the file data storage device; Connected to
A file detailed information table that is a memory area for caching file detailed information;
A communication unit that receives a processing request from a client device or another server device or transmits a request to another server device, and counts the number of requests being processed or being transmitted;
When an FH of a file is input, a file detailed information inquiry unit that transmits a request for requesting file detailed information to the server device having a server ID included in the FH and receives the file detailed information;
When a request is received from the client device that includes the name of the file immediately below in the directory hierarchy, 1) a request for the FH and file type of the file, and 2) a request that combines the requests for the file detailed information. A) obtaining the FH and file type of the file with the input name from the directory stored in the metadata storage device; b1) the number of requests counted by the communication unit does not exceed a predetermined threshold; c1) If the file detailed information of the file with the received name is cached in the file detailed information table, the cached file detailed information is obtained. c2) If the file detailed information is not cached in the file detailed information table, The FH of the acquired file is the file detailed information inquiry section. Input and acquire file detailed information, cache it in the file detailed information table, return the FH, file type and file detailed information of the acquired file to the client device, b2) Requests counted by the communication unit If the number exceeds the predetermined threshold, the input request is changed to stop outputting the file detailed information, and the FH and file type of the acquired file are returned to the client device.
Further, the file data storage is sent from the client device that transmits the FH of the file returned from the server device to the server device that manages the file again or from the file detailed information inquiry unit of another server device. When a request including the FH of the file stored in the device is received, the detailed file information of the file having the input FH as an identifier is obtained from the metadata storage device and returned, and the directory entry is referred / updated. And a server device. 前記サーバー装置は、さらに、
前記クライアント装置から、新たなディレクトリ、または、ファイルの第１の生成要求が送信されたとき、前記第１の生成要求に含まれる名前に依存しない方法で新たなディレクトリ、または、ファイルを管理する前記サーバー装置を選択するサーバー選定部と、
前記サーバー選定部が選択した前記サーバー装置に新たなディレクトリ、または、ファイルの第２の生成要求を送信して、生成された新たなディレクトリ、または、ファイルのＦＨを受信し、さらに、新たなファイルを生成した時はファイル詳細情報も受信する、ファイル／ディレクトリ生成要求部と、
前記第２の生成要求を受信すると、ａ）ディレクトリを生成して前記メタデータ記憶装置に格納、または、ｂ）ファイル詳細情報を生成して前記メタデータ記憶装置に格納すると共に前記第２の生成要求送信元に返信し、さらに、自装置のサーバーＩＤ及び自装置内一意の値から新たなディレクトリ、または、ファイルのＦＨを作成して、作成したＦＨを前記メタデータ記憶装置に格納すると共に前記第２の生成要求送信元に返信するファイル／ディレクトリ生成部とを、備え、
前記ディレクトリエントリ参照／更新部は、ファイル／ディレクトリ生成要求部が受信したＦＨ、並びに、前記第１の生成要求に含まれる名前、および、ファイルタイプを前記メタデータ記憶装置に格納されているディレクトリに記憶し、さらに、受信した場合はファイル詳細情報を前記ファイル詳細情報表に記憶する、請求項１のサーバー装置。 The server device further includes:
When a first generation request for a new directory or file is transmitted from the client device, the new directory or file is managed in a method independent of the name included in the first generation request. A server selection unit for selecting a server device;
A second directory or file second generation request is transmitted to the server device selected by the server selection unit, the generated new directory or file FH is received, and a new file is further received. A file / directory generation request part that receives file detailed information when generating
Upon receiving the second generation request, a) a directory is generated and stored in the metadata storage device, or b) detailed file information is generated and stored in the metadata storage device, and the second generation is generated. A new directory or file FH is created from the server ID of the own device and a unique value in the own device, and the created FH is stored in the metadata storage device. A file / directory generation unit that replies to the second generation request transmission source,
The directory entry reference / update unit stores the FH received by the file / directory generation request unit, the name included in the first generation request, and the file type in the directory stored in the metadata storage device. The server device according to claim 1, further storing file detailed information in the file detailed information table when received. 前記ディレクトリエントリ参照／更新部は、前記クライアント装置から、ディレクトリ階層における直下のディレクトリの名前を入力されると、前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のＦＨとファイルタイプを取得して出力する、請求項１乃至請求項２の何れか１項のサーバー装置と、
まず、１）上位のディレクトリを管理する前記サーバー装置の前記ディレクトリエントリ参照／更新部に、直下のディレクトリの名前を入力して、直下のディレクトリのＦＨとファイルタイプを取得することを、前記パス名に名前が含まれるディレクトリについて、ルートディレクトリを管理する予め定められた前記サーバー装置を起点に、上位から順に繰り返すディレクトリ探索を実行して、パス名中の最下位ディレクトリのＦＨとファイルタイプを取得し、次に、２）最下位ディレクトリのＦＨが包含するサーバーIDの前記サーバー装置の前記ディレクトリエントリ参照／更新部に、2-1）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、2-2）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストを送信して、ａ）前記パス名のファイルのＦＨ、ファイルタイプ、および、ファイル詳細情報を取得する、または、ｂ）前記パス名のファイルのＦＨ、および、ファイルタイプを取得するメタデータ問い合わせ部と、
前記メタデータ問い合わせ部がファイル詳細情報を取得できなかったとき、前記メタデータ問い合わせ部が取得した前記パス名のファイルのＦＨを、改めてファイルを管理する前記サーバー装置に送信して、ファイル詳細情報を取得するファイル詳細情報要求部と、を備える前記クライアント装置と、を包含する分散ファイルシステム。 When the directory entry reference / update unit receives the name of a directory immediately under the directory hierarchy from the client device, the directory entry reference / update unit inputs the FH and file type of the input name from the directory stored in the metadata storage device. The server device according to any one of claims 1 to 2, which acquires and outputs
First, the path name is obtained by inputting the name of the directory directly under the directory entry reference / update unit of the server device that manages the upper directory to obtain the FH and file type of the directory under the directory. For the directory including the name, the directory search is repeated in order from the top, starting from the predetermined server device that manages the root directory, and the FH and file type of the lowest directory in the path name are obtained. Next, 2) Request to the directory entry reference / update unit of the server device of the server ID included in the FH of the lowest directory, 2-1) Request for the FH and file type of the file, and 2-2 ) Send a request that combines two requests for detailed file information Te, a) FH file of the path name, file type, and acquires the file details, or, b) FH file of the path name, and a metadata inquiry unit that acquires the file type,
When the metadata inquiry unit cannot acquire the file detailed information, the FH of the file having the path name acquired by the metadata inquiry unit is transmitted again to the server device that manages the file, and the file detailed information is transmitted. A distributed file system comprising: the client device comprising: a file detailed information requesting unit to obtain. 前記クライアント装置は、
ディレクトリの、名前、ＦＨ，及び、ファイルタイプを関連付けてキャッシュするメタデータ記憶部を、さらに、備え、
前記メタデータ問い合わせ部は、前記ディレクトリ探索の過程で前記パス名から、ディレクトリの名前を取り出すと、ａ１）取り出した名前（以降、取得ディレクトリ名）が前記メタデータ記憶部にキャッシュされていなければ、前記取得ディレクトリ名のディレクトリの上位のディレクトリを管理する前記サーバー装置の前記ディレクトリエントリ参照／更新部に前記取得ディレクトリ名を送信して、前記取得ディレクトリ名のディレクトリのＦＨとファイルタイプを得るとともに、前記メタデータ記憶部に、前記取得ディレクトリ名、並びに、前記サーバー装置から取得したＦＨとファイルタイプをキャッシュし、ａ２）キャッシュされていれば前記メタデータ記憶部から前記取得ディレクトリ名のディレクトリのＦＨとファイルタイプを取得する、請求項２乃至請求項３の何れか１項の分散ファイルシステム。 The client device is
A metadata storage unit that caches the name, FH, and file type in association with each other;
When the metadata inquiry unit extracts a directory name from the path name in the directory search process, a1) if the extracted name (hereinafter, acquired directory name) is not cached in the metadata storage unit, The acquisition directory name is transmitted to the directory entry reference / update unit of the server device that manages a directory higher than the directory of the acquisition directory name to obtain the FH and file type of the directory of the acquisition directory name, and Cache the acquired directory name and the FH and file type acquired from the server device in the metadata storage unit. A2) If cached, the FH and file of the directory with the acquired directory name from the metadata storage unit type Obtaining, according to claim 2 or distributed file system of any one of claims 3. 前記メタデータ記憶部は、ファイルの、名前、ＦＨ、ファイルタイプ、及び、ファイル詳細情報を関連付けて、さらに、キャッシュし、
前記メタデータ問い合わせ部は、前記パス名から、ファイルの名前を取り出すと、ａ１）取り出した名前（以降、取得ファイル名）が前記メタデータ記憶部にキャッシュされていなければ、前記サーバー装置から、前記取得ファイル名のファイルの、ＦＨ、ファイルタイプ、及び、ファイル詳細情報を得るとともに、前記メタデータ記憶部に、前記取得ファイル名、並びに、前記サーバー装置から取得したＦＨ、ファイルタイプ、及び、ファイル詳細情報をキャッシュし、ａ２）キャッシュされていれば前記メタデータ記憶部から前記取得ファイル名のファイルのＦＨ、ファイルタイプ、及び、ファイル詳細情報を取得する、請求項４の分散ファイルシステム。 The metadata storage unit associates the file name, FH, file type, and file detailed information, and further caches the file.
When the metadata inquiry unit extracts the name of the file from the path name, a1) If the extracted name (hereinafter, acquired file name) is not cached in the metadata storage unit, The FH, file type, and file detailed information of the file having the acquired file name are obtained, and the acquired file name, the FH, the file type, and the file details acquired from the server device are stored in the metadata storage unit. 5. The distributed file system according to claim 4, wherein the information is cached, and a2) if it is cached, FH, file type, and file detailed information of the file having the acquired file name are acquired from the metadata storage unit. ファイルを記憶するファイルデータ記憶装置と、
ディレクトリ階層における直下のディレクトリ、または、ファイルの、ａ）識別子であって、当該ディレクトリ、または、当該ファイルを管理するサーバー装置の識別情報であるサーバーIDを含むファイルハンドル（以降、ＦＨと略記）、ｂ）名前、および、ｃ）ファイルまたはディレクトリの区別を示すファイルタイプを関連付けて記憶するディレクトリ、および、前記ファイルデータ記憶装置に記憶されているファイルのファイル詳細情報を記憶するメタデータ記憶装置と、に接続され、ファイル詳細情報のキャッシュ用メモリ領域であるファイル詳細情報表を備える前記サーバー装置が、
クライアント装置、若しくは、他の前記サーバー装置から処理リクエストを受信、または、他の前記サーバー装置にリクエストを送信するとともに、処理中または送信中のリクエスト数をカウントし、
クライアント装置から、ディレクトリ階層における直下のファイルの名前を含む、１）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、２）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストを受信すると、ａ）前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のファイルのＦＨとファイルタイプを取得し、ｂ１）カウントしたリクエスト数が所定閾値を超えておらず、ｃ１）受信された名前のファイルのファイル詳細情報が前記ファイル詳細情報表にキャッシュされていれば、キャッシュされているファイル詳細情報を取得し、ｃ２）前記ファイル詳細情報表にキャッシュされていなければ、取得したファイルのＦＨを含むリクエストを、当該ＦＨが包含するサーバーIDの前記サーバー装置に送信してファイル詳細情報を取得して、前記ファイル詳細情報表にキャッシュし、取得したファイルのＦＨ、ファイルタイプとファイル詳細情報とを前記クライアント装置に返信し、ｂ２）カウントしたリクエスト数が所定閾値を超えている場合は、入力されたリクエストを変更してファイル詳細情報の出力を中止し、取得したファイルのＦＨ、ファイルタイプを前記クライアント装置に返信し、
また、ファイルのＦＨを、改めてファイルを管理する前記サーバー装置に送信する前記クライアント装置から、または、他の前記サーバー装置から、前記ファイルデータ記憶装置に記憶されているファイル、のＦＨを含むリクエストを受信すると、前記メタデータ記憶装置から、入力されたＦＨを識別子とするファイルのファイル詳細情報を取得して返信する、分散ファイルシステム制御方法。 A file data storage device for storing files;
A) a file handle (hereinafter abbreviated as FH) including a server ID which is an identifier of a directory or file immediately below in the directory hierarchy and is an identification information of the server device managing the directory or the file; a metadata storage device for storing b) a name and c) a directory for storing a file type indicating a distinction between files or directories in association with each other, and a file detailed information of the file stored in the file data storage device; And the server device comprising a file detailed information table that is a memory area for caching file detailed information,
Receive processing requests from client devices or other server devices, or send requests to other server devices, and count the number of requests being processed or being transmitted,
When a request including the name of the file immediately below in the directory hierarchy is received from the client device, 1) a request for the FH and file type of the file, and 2) a request for the file detailed information, ) Obtain the FH and file type of the file with the input name from the directory stored in the metadata storage device, b1) The number of requests counted does not exceed the predetermined threshold, and c1) the received name If the file detailed information of the file is cached in the file detailed information table, the cached file detailed information is acquired. C2) If the file detailed information is not cached in the file detailed information table, the FH of the acquired file is obtained. The server ID included in the FH The file detailed information is acquired by transmitting to the server device, cached in the file detailed information table, the FH, file type and file detailed information of the acquired file are returned to the client device, and b2) the counted requests If the number exceeds the predetermined threshold, the input request is changed to stop outputting the file detailed information, and the FH and file type of the acquired file are returned to the client device.
Further, a request including the FH of the file stored in the file data storage device is sent from the client device that transmits the FH of the file to the server device that manages the file again or from another server device. A distributed file system control method that, upon receiving, obtains and returns from the metadata storage device file detailed information of a file having the input FH as an identifier. 前記サーバー装置が、さらに、
前記クライアント装置から、新たなディレクトリ、または、ファイルの第１の生成要求を受信すると、前記第１の生成要求に含まれる名前に依存しない方法で新たなディレクトリ、または、ファイルを管理する前記サーバー装置を選択し、
選択した前記サーバー装置に新たなディレクトリ、または、ファイルの第２の生成要求を送信して、生成された新たなディレクトリ、または、ファイルのＦＨを受信し、さらに、新たなファイルを生成した時はファイル詳細情報も受信し、
受信したＦＨ、並びに、前記第１の生成要求に含まれる名前、および、ファイルタイプを前記メタデータ記憶装置に格納されているディレクトリに記憶し、さらに、受信した場合はファイル詳細情報を前記ファイル詳細情報表に記憶し、
また、他の前記サーバー装置から前記第２の生成要求を受信すると、ａ）ディレクトリを生成して前記メタデータ記憶装置に格納、または、ｂ）ファイル詳細情報を生成して前記メタデータ記憶装置に格納すると共に前記第２の生成要求送信元に返信し、さらに、自装置のサーバーＩＤ及び自装置内一意の値から新たなディレクトリ、または、ファイルのＦＨを作成して、作成したＦＨを前記メタデータ記憶装置に格納すると共に前記第２の生成要求送信元に返信する、請求項６の分散ファイルシステム制御方法。 The server device further comprises:
When receiving a first generation request for a new directory or file from the client device, the server device manages the new directory or file in a manner independent of the name included in the first generation request. Select
When a second directory or file generation request is transmitted to the selected server device, the generated new directory or file FH is received, and a new file is generated Receive file details,
The received FH, the name included in the first generation request, and the file type are stored in a directory stored in the metadata storage device, and if received, detailed file information is stored in the file details. Memorize it in the information table,
When the second generation request is received from another server device, a) a directory is generated and stored in the metadata storage device, or b) detailed file information is generated and stored in the metadata storage device. In addition to storing and returning to the second generation request transmission source, an FH of a new directory or file is created from the server ID of the own device and a unique value in the own device, and the created FH is added to the meta 7. The distributed file system control method according to claim 6, wherein the distributed file system is stored in a data storage device and returned to the second generation request transmission source. 前記サーバー装置が、前記クライアント装置から、ディレクトリ階層における直下のディレクトリの名前を受信すると、前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のＦＨとファイルタイプを取得して出力し、
前記クライアント装置が、まず、１）上位のディレクトリを管理する前記サーバー装置に、直下のディレクトリの名前を入力して、直下のディレクトリのＦＨとファイルタイプを取得することを、前記パス名に名前が含まれるディレクトリについて、ルートディレクトリを管理する予め定められた前記サーバー装置を起点に、上位から順に繰り返すディレクトリ探索を実行して、パス名中の最下位ディレクトリのＦＨとファイルタイプを取得し、次に、２）最下位ディレクトリのＦＨが包含するサーバーIDの前記サーバー装置に、2-1）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、2-2）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストを送信して、ａ）前記パス名のファイルのＦＨ、ファイルタイプ、および、ファイル詳細情報を取得し、または、ｂ）前記パス名のファイルのＦＨ、および、ファイルタイプを取得し、
最下位ディレクトリのＦＨが包含するサーバーIDの前記サーバー装置から、ファイル詳細情報を取得できなかったとき、当該サーバー装置から取得した前記パス名のファイルのＦＨを、改めてファイルを管理する前記サーバー装置に送信して、ファイル詳細情報を取得する、請求項６乃至請求項７の何れか１項の分散ファイルシステム制御方法。 When the server device receives the name of the directory immediately under the directory hierarchy from the client device, the server device acquires and outputs the input name FH and file type from the directory stored in the metadata storage device. ,
First, the client device inputs 1) the name of the directory immediately below to the server device that manages the upper directory, and acquires the FH and file type of the directory immediately below. For the included directories, starting with the predetermined server device that manages the root directory, the directory search is repeated in order from the top to obtain the FH and file type of the lowest directory in the path name, and then 2) Two requests, 2-1) request for file FH and file type, and 2-2) request for file detailed information are sent to the server device of the server ID included in the FH of the lowest directory. Send a summary request and a) FH and file type of the file with the path name And acquires the file details, or, b) FH file of the path name, and acquires the file type,
When the file detailed information cannot be acquired from the server device of the server ID included in the FH of the lowest directory, the FH of the file with the path name acquired from the server device is newly transmitted to the server device that manages the file. The distributed file system control method according to any one of claims 6 to 7, wherein the file detailed information is acquired by transmission. 前記クライアント装置が、
ディレクトリの、名前、ＦＨ，及び、ファイルタイプを関連付けてキャッシュするメタデータ記憶部を、さらに、備え、
前記ディレクトリ探索の過程で前記パス名から、ディレクトリの名前を取り出すと、ａ１）取り出した名前（以降、取得ディレクトリ名）が前記メタデータ記憶部にキャッシュされていなければ、前記取得ディレクトリ名のディレクトリの上位のディレクトリを管理する前記サーバー装置に前記取得ディレクトリ名を送信して、前記取得ディレクトリ名のディレクトリのＦＨとファイルタイプを得るとともに、前記メタデータ記憶部に、前記取得ディレクトリ名、並びに、前記サーバー装置から取得したＦＨとファイルタイプをキャッシュし、ａ２）キャッシュされていれば前記メタデータ記憶部から前記取得ディレクトリ名のディレクトリのＦＨとファイルタイプを取得する、請求項７乃至請求項８の何れか１項の分散ファイルシステム制御方法。 The client device is
A metadata storage unit that caches the name, FH, and file type in association with each other;
When the directory name is extracted from the path name in the directory search process, a1) if the extracted name (hereinafter, acquired directory name) is not cached in the metadata storage unit, the directory name of the acquired directory name is The acquisition directory name is transmitted to the server device that manages the upper directory to obtain the FH and file type of the directory of the acquisition directory name, and the acquisition directory name and the server are stored in the metadata storage unit. The FH and file type acquired from the device are cached, and a2) if cached, the FH and file type of the directory having the acquired directory name are acquired from the metadata storage unit. 1 Distributed file system system Method. ファイルを記憶するファイルデータ記憶装置と、
ディレクトリ階層における直下のディレクトリ、または、ファイルの、ａ）識別子であって、当該ディレクトリ、または、当該ファイルを管理するコンピュータの識別情報であるサーバーIDを含むファイルハンドル（以降、ＦＨと略記）、ｂ）名前、および、ｃ）ファイルまたはディレクトリの区別を示すファイルタイプを関連付けて記憶するディレクトリ、および、前記ファイルデータ記憶装置に記憶されているファイルのファイル詳細情報を記憶するメタデータ記憶装置と、に接続され、ファイル詳細情報のキャッシュ用メモリ領域であるファイル詳細情報表を備える前記コンピュータに、
クライアント装置、若しくは、他の前記コンピュータから処理リクエストを受信、または、他の前記コンピュータにリクエストを送信するとともに、処理中または送信中のリクエスト数をカウントし、
クライアント装置から、ディレクトリ階層における直下のファイルの名前を含む、１）ファイルのＦＨ、および、ファイルタイプにたいする要求、並びに、２）ファイル詳細情報にたいする要求の２つの要求をまとめたリクエストを受信すると、ａ）前記メタデータ記憶装置に格納されているディレクトリから、入力された名前のファイルのＦＨとファイルタイプを取得し、ｂ１）カウントしたリクエスト数が所定閾値を超えておらず、ｃ１）受信された名前のファイルのファイル詳細情報が前記ファイル詳細情報表にキャッシュされていれば、キャッシュされているファイル詳細情報を取得し、ｃ２）前記ファイル詳細情報表にキャッシュされていなければ、取得したファイルのＦＨを含むリクエストを、当該ＦＨが包含するサーバーIDの前記コンピュータに送信してファイル詳細情報を取得して、前記ファイル詳細情報表にキャッシュし、取得したファイルのＦＨ、ファイルタイプとファイル詳細情報とを前記クライアント装置に返信し、ｂ２）カウントしたリクエスト数が所定閾値を超えている場合は、入力されたリクエストを変更してファイル詳細情報の出力を中止し、取得したファイルのＦＨ、ファイルタイプを前記クライアント装置に返信し、
また、ファイルのＦＨを、改めてファイルを管理する前記コンピュータに送信する前記クライアント装置から、または、他の前記コンピュータから、前記ファイルデータ記憶装置に記憶されているファイル、のＦＨを含むリクエストを受信すると、前記メタデータ記憶装置から、入力されたＦＨを識別子とするファイルのファイル詳細情報を取得して返信する、処理を実行させるプログラム。 A file data storage device for storing files;
A) a file handle (hereinafter abbreviated as FH) that includes a server ID, which is an identifier of a directory or file immediately under the directory hierarchy, and is identification information of the directory or computer that manages the file, b A) a name, and c) a directory that associates and stores a file type indicating a distinction between a file or a directory, and a metadata storage device that stores file detailed information of the file stored in the file data storage device. Connected to the computer comprising a file detailed information table that is a memory area for caching file detailed information;
Receive a processing request from a client device or another computer, or send a request to the other computer, and count the number of requests being processed or transmitted,
When a request is received from the client device that includes the name of the file immediately below in the directory hierarchy, 1) a request for the FH and file type of the file, and 2) a request that summarizes the request for the file detailed information, a ) Obtain the FH and file type of the file with the input name from the directory stored in the metadata storage device, b1) The number of requests counted does not exceed the predetermined threshold, and c1) the received name If the file detailed information of the file is cached in the file detailed information table, the cached file detailed information is acquired. C2) If the file detailed information is not cached in the file detailed information table, the FH of the acquired file is obtained. The server ID included in the FH The file detailed information is acquired by transmitting to the computer, cached in the file detailed information table, the FH, file type and file detailed information of the acquired file are returned to the client device, b2) the number of requests counted Is over the predetermined threshold, the input request is changed, the output of the file detailed information is stopped, the FH and file type of the acquired file are returned to the client device,
When a request including the FH of the file stored in the file data storage device is received from the client device that transmits the FH of the file to the computer that manages the file again or from another computer. A program for executing processing for acquiring and returning file detailed information of a file having the input FH as an identifier from the metadata storage device.
JP2016001571A 2016-01-07 2016-01-07 Server device, distributed file system, distributed file system control method, and program Active JP6607044B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2016001571A JP6607044B2 (en) 2016-01-07 2016-01-07 Server device, distributed file system, distributed file system control method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016001571A JP6607044B2 (en) 2016-01-07 2016-01-07 Server device, distributed file system, distributed file system control method, and program

Publications (2)

Publication Number Publication Date
JP2017123040A true JP2017123040A (en) 2017-07-13
JP6607044B2 JP6607044B2 (en) 2019-11-20

Family

ID=59306773

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016001571A Active JP6607044B2 (en) 2016-01-07 2016-01-07 Server device, distributed file system, distributed file system control method, and program

Country Status (1)

Country Link
JP (1) JP6607044B2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190143521A (en) * 2018-06-08 2019-12-31 삼성에스디에스 주식회사 Apparatus and method for managing storage
CN117453643A (en) * 2023-12-22 2024-01-26 柏科数据技术（深圳）股份有限公司 File caching method, device, terminal and medium based on distributed file system

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190143521A (en) * 2018-06-08 2019-12-31 삼성에스디에스 주식회사 Apparatus and method for managing storage
KR102622183B1 (en) 2018-06-08 2024-01-08 삼성에스디에스 주식회사 Apparatus and method for managing storage
CN117453643A (en) * 2023-12-22 2024-01-26 柏科数据技术（深圳）股份有限公司 File caching method, device, terminal and medium based on distributed file system
CN117453643B (en) * 2023-12-22 2024-04-02 柏科数据技术（深圳）股份有限公司 File caching method, device, terminal and medium based on distributed file system

Also Published As

Publication number Publication date
JP6607044B2 (en) 2019-11-20

Similar Documents

Publication Publication Date Title
US11836135B1 (en) Method and system for transparent database query caching
US11775569B2 (en) Object-backed block-based distributed storage
US10795817B2 (en) Cache coherence for file system interfaces
US9971823B2 (en) Dynamic replica failure detection and healing
US7640247B2 (en) Distributed namespace aggregation
JP5375972B2 (en) Distributed file system, data selection method thereof, and program
WO2015118865A1 (en) Information processing device, information processing system, and data access method
US10635650B1 (en) Auto-partitioning secondary index for database tables
US11082494B2 (en) Cross storage protocol access response for object data stores
US9483523B2 (en) Information processing apparatus, distributed processing system, and distributed processing method
CN108540510B (en) Cloud host creation method and device and cloud service system
US8250176B2 (en) File sharing method and file sharing system
US20210248107A1 (en) Kv storage device and method of using kv storage device to provide file system
US11132367B1 (en) Automatic creation of indexes for database tables
CN109302448A (en) A kind of data processing method and device
JP6951846B2 (en) Computer system and task allocation method
JP6607044B2 (en) Server device, distributed file system, distributed file system control method, and program
US20220342888A1 (en) Object tagging
JP5481669B2 (en) Cache control method, node device, manager device, and computer system
US10205679B2 (en) Resource object resolution management
JP2009289161A (en) Clustered storage system, node device thereof, and method and program for controlling data read/write
US11064020B2 (en) Connection load distribution in distributed object storage systems
JP7173165B2 (en) History management device, history management method and program
JP6568232B2 (en) Computer system and device management method
US10621148B1 (en) Maintaining multiple object stores in a distributed file system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20181214

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190924

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190927

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20191007

R150 Certificate of patent or registration of utility model

Ref document number: 6607044

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150