JP4271967B2

JP4271967B2 - 分散ファイルシステム及び分散ファイルシステムの運用方法

Info

Publication number: JP4271967B2
Application number: JP2003063569A
Authority: JP
Inventors: 隆喜中村; 和成小山
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2003-03-10
Filing date: 2003-03-10
Publication date: 2009-06-03
Anticipated expiration: 2023-03-10
Also published as: US7613786B2; US20040205202A1; JP2004272668A

Description

【０００１】
【発明の属する技術分野】
本発明は、分散ファイルシステム及び分散ファイルシステムの運用方法に係り、特に、複数のクライアント（ノード）によってファイルの共有が可能なトークン方式の分散ファイルシステム及び分散ファイルシステムの運用方法に関する。
【０００２】
【従来の技術】
従来の分散ファイルシステムは、トークンを利用してデータのコンシステンシ（一貫性）を保つのもが知られている。このトークンには、データ、属性、サイズ、名前等の種類があり、それぞれのトークンについてリードとライトという状態（ステート）がある。例えば、データリードトークンを保持しているノードは、トークンに対応するファイルへの読み込みが許され、データライトトークンを保持しているノードは、トークンに対応するファイルへの書き込みが許される。また、リードトークンは複数のノードが同時に保持することができるが、ライトトークンはあるひとつのノードのみ保持できる。したがって、同一のファイルは複数のノードが同時に読み込むことができるが、複数のノードが同時に書き込むことができない。
【０００３】
さらにデータトークンに関しては、ファイル全体に対して権限を与えるトークンを発行する方式と、データの中のある部分（例えば、ファイルの先頭何バイト目から何バイト目）に限定した範囲に対する権限を与えるトークンを発行する方式がある。
【０００４】
このトークンは、例えば、図５のようなフォーマットで構成されている。ファイルＩＤフォールド３１は、どのファイルに対してなされたトークンであるかを示す。リボークトークン種フィールド３２は、トークンの種類（データ、属性、サイズ、名前等）を示す。範囲指定フィールド３３は、データの中の範囲を指定する。
【０００５】
この従来のトークン方式の分散ファイルシステムでは、
（１）複数のノードが読み込み専用で同じファイルを参照する、
（２）あるファイルに対してひとつのノードが読み込み、書き込みを行う、
ようなケースでは非常に効率的なファイルアクセスが行える。一方、
（３）複数のノードが同じファイルに対して読み込み、書き込みを行う、
ようなケースでは、パフォーマンスが極端に低下する。
【０００６】
上記（３）のケースの従来の処理の流れを図６のフローチャートを参照して説明する。ここで前提条件として、クライアントＡがファイルＸのライトデータトークンを保持しており、ファイルＸの最新更新データをディスクに未反映（書込前）の状態であるとし、前提条件における処理の流れを太線の矢印で示す。
【０００７】
まず、クライアントＢがファイルＸに対してＩ／Ｏ処理（書込処理又は読出処理）を行った場合（処理１０１）、クライアントＢはファイルＸに対して適切なトークン（リード処理ではリードトークン、ライト処理ではライトトークン）を保持しているか否かを、自身のトークン保持テーブルを参照して判定する（処理１０２）。ファイルＸに対する適切なトークンを保持していると判定された場合は処理１１０に移行する。
【０００８】
一方、クライアントＢはファイルＸに対する適切なトークンを保持していない場合は、サーバＣに対して適切なトークンを要求する。サーバＣは、トークンの要求を受けると、ファイルＸのライトトークンを保持しているクライアント（計算機）があるか否かを、自身のトークン管理テーブルを参照して判定する（処理１０３）。ファイルＸのライトトークンを保持しているクライアントがなければ処理１０８に移行する。一方、クライアントＡがファイルＸに対するライトトークンを保持しているため、サーバＣはクライアントＡに対しトークンリボーク（返却）を要求する。
【０００９】
クライアントＡはサーバＣからのリボーク要求を受けると、自身のキャッシュ内に、ファイルＸのデータであってディスクに未反映の（未だ書き込んでいない）ダーティーデータがあるか否かを判定する（処理１０４）。ダーティーデータがない場合は処理１０６に移行する。一方、クライアントＡにダーティーデータが存在するため、クライアントＡはファイルＸのダーティーデータをディスク（又はサーバ）に書き戻す（処理１０５）。次に、クライアントＡは自身のトークン保持テーブルからファイルＸのライトトークンを削除し、サーバＣに対してトークンの返却を通知する（処理１０６）。サーバＣはトークンの返却通知を受けると、トークンの返却を自身のトークン管理テーブルに反映する（処理１０７）。次に、サーバＣは、クライアントＢに対して要求トークンの付与をトークン管理テーブルに反映し（処理１０８）、クライアントＢに対し要求トークンを付与する旨のメッセージを送る。クライアントＢはメッセージを受け取ると、自身のトークン保持テーブルにトークンの保持を反映する（処理１０９）。クライアントＢのトークンの反映が完了するとディスク（又はサーバ）に対してＩ／Ｏ処理を行ことができる（処理１１０）。
【００１０】
すなわち、あるノードがあるファイルに対してライトデータトークンを保持している状態で、同じファイルに対して別のノードがアクセスしたときに、４回のノード間通信と、２回のディスクＩ／Ｏが発生していた。
【００１１】
【特許文献１】
特開２０００−３２２３０６号公報
【非特許文献１】
日本ＳＧＩ株式会社、“ＣＸＦＳ：クラスタファイルシステム”、［online］、２００１年１１月５日、インターネット＜URL:http://www.sgi.co.jp/products/pdf/sancxfswp.pdf＞
【００１２】
【発明が解決しようとする課題】
従来の分散ファイルシステムでは、あるノードがトークンを保有しているファイルに対して、他のノードがＩ／Ｏ処理をする場合に、２回のディスクＩ／Ｏ処理と４回のノード間通信が発生し、しかもこの処理は順番に実行しなければならないので、ディスクのＩ／Ｏ処理に時間を必要とし、システムの性能が低下していた。
【００１３】
本発明は、上記の不具合を鑑みてなされたものであり、ディスクのＩ／Ｏ処理を減らした分散ファイルシステムを提供することを目的とする。
【００１４】
【課題を解決するための手段】
本発明は、サーバがトークンを保持しているノードに対してリボーク要求を発行する際に、トークンを要求しているノードの情報を付加したリボーク要求を発行することにより、同じファイルをストレージに書き戻さず、ダーティーな状態のままのファイルを渡すので、ストレージへのＩ／Ｏ処理回数を可能な限り減らし、処理を並列化する。
【００１５】
【発明の作用と効果】
本発明は、あるノードがあるファイルに対してライトデータトークンを保持している状態で、同じファイルに対して別のノードがアクセスしたときに、ファイルをストレージに書き戻さず、ダーティーな状態のままのファイルを渡すので、ストレージへのアクセス回数を減らすことができ、理想的なケースでは４回のノード間通信のみ（ディスクＩ／Ｏなし）でファイルへのアクセスが可能となり、システム全体としてのスループットを向上することができる。
【００１６】
例えば、ノード間で共有しているログファイルの処理では、複数のノード間で短いデータの追記書きが発生するため、ディスクのＩ／Ｏ回数を軽減させ、スループット性能の性能向上が期待できる。
【００１７】
【発明の実施の形態】
以下に、本発明の実施の形態を図面を参照して説明する。
【００１８】
図１は、本発明の第１の実施の形態の分散ファイルシステムの構成を表したブロック図である。
【００１９】
クライアント１０、１１は分散ファイルシステムのノードとして機能する計算機である。このクライアント１０、１１とストレージシステム１６とがＬＡＮ１４によって接続されている。
【００２０】
クライアント１０、１１の各々には、トークン保持テーブル１０ｂ、１１ｂ、キャッシュ１０ｃ、１１ｃが備えられている。トークン保持テーブル１０ｂ、１１ｂは、クライアントが保持しているトークンの内容を記憶する。キャッシュ１０ｃ、１１ｃは、ストレージシステム１６から読み込んだデータを一時的に保管するためのメモリ装置である。このキャッシュ１０ｃ、１１ｃには、キャッシュに保持されているデータがダーティーである（ストレージ装置に未だ書き込まれていない未反映のデータがある）か否かを示すダーティーフラグが備えられている。
【００２１】
ストレージシステム１６には、サーバ１２、ストレージ装置１３が備えられており、Network Attached Storage（ＮＡＳ）として機能している。サーバ１２とストレージ装置１３とはStorage Area Network（ＳＡＮ）１５によって接続されている。このストレージ装置１３は、ハードディスク等の記憶装置で構成されている。よって、クライアント１０、１１は、ＬＡＮ１４を経由してストレージシステム１６に備えられたストレージ装置１３に記憶されたデータの読み出し及び書き込みができる。
【００２２】
サーバ１２には、トークン管理テーブル１２ａ、トークン保持テーブル１２ｂ、キャッシュ１２ｃが備えられている。トークン管理テーブル１２ａは、全てのクライアントが、それぞれどのような内容（例えばリード、ライト等）のトークンを保持しているかを該当するデータに対応付けて記憶する。トークン保持テーブル１２ｂは、サーバが保持しているトークンの内容を記録する。キャッシュ１２ｃは、データを一時的に保管するためのメモリである。
【００２３】
次に、以上のように構成された本発明の第１の実施の形態の動作について説明する。
【００２４】
各クライアント１０、１１はサーバ１２からトークンを付与されることによってファイルへのアクセスが許され、トークンを管理しているサーバ１２は、トークン管理テーブル１２ｃを参照することによって、現在、どのクライアントによって、どのファイルに対してどのような処理が行われているのかを知ることができる。
【００２５】
例えば、クライアント１０にファイルＡに対するライトデータトークンが付与されると、クライアント１０は、ストレージ装置１３からファイルＡを読み込んだり、ファイルＡを書き込みモードでキャッシュ１０ｃに保持することが可能になる。続いて、クライアント１１がファイルＡに対するリードデータトークンを要求した場合、サーバ１２が、クライアント１１からのリードデータトークン要求を受け取ると、トークン管理テーブル１２ｃを参照することで、ファイルＡがクライアント１０が保有するライトデータトークンによって書き込みモードで保持されていることがわかる。そのため、サーバ１２はクライアント１０に対してトークンのリボーク（返却）要求を行う。リボーク処理が完了すると、クライアント１１にファイルＡに対するリードデータトークンが付与され、クライアント１１によるファイルＡの読み込みが可能となる。
【００２６】
図２は、第１の実施の形態のクライアント１０、１１とサーバ１２のファイルのＩ／Ｏ処理（ファイルの読み込み、書き込み等）のフローチャートを示す。
【００２７】
なお、このフローチャートの処理の前提条件として、クライアント１０がファイルＸに対するライトデータトークンを保持しており、ファイルＸの最新更新データがディスクに未反映の状態、すなわちファイルＸにダーティーデータを含んでいる状態を前提し、前提条件における処理の流れを太線の矢印で示す。
【００２８】
まず、クライアント１１において、ファイルＸを読み込む必要が生じ、分散ファイルシステム上のファイルＸに対するＩ／Ｏ要求を発行する（処理２０１）。
【００２９】
クライアント１１は、このＩ／Ｏ要求を受けて、まず、自身のトークン保持テーブル１１ｂがファイルＸの適切なトークンを保持しているか否かを判定する（処理２０２）。適切なトークンを保持している、すなわち、ファイルＸに対する読み込み処理ならばリードデータトークン、ファイルに対する書き込み処理ならばライトデータトークンを保持していると判定した場合には、サーバ１２に対してＩ／Ｏ処理を実行し、ストレージ装置１３よりファイルを読み込む（処理２１８）。
【００３０】
処理２０２において適切なトークンを保持していないと判定した場合には、サーバ１２に対してトークンを要求するトークン要求メッセージを送る。サーバ１２はトークン要求メッセージを受け取ると、ファイルＸのライトデータトークンを保持するクライアントがトークン管理テーブル１２ａに登録されているか否かを判定する（処理２０３）。ライトデータトークンを保持しているクライアントが無い場合は、直ちにトークンを付与することが可能であるので、トークン管理テーブル１２ａにファイルＸに対するクライアント１１のライトデータトークンの付与を反映し（処理２１６）、クライアント１１にライトデータトークンを付与した旨を通知する。
【００３１】
クライアント１１は通知を受け取ると、トークン保持テーブル１１ｂに、処理２０２で要求したトークンの種類（ライト／リード等）を登録し（処理２１７）、サーバ１２に対してＩ／Ｏ処理を実行し、ストレージ装置１３よりファイルを読み込む（処理２１８）。
【００３２】
処理２０３において、ライトデータトークンを保持しているクライアントが既に存在すると判定した場合には、ライトデータトークンを保持しているクライアント（クライアント１０）に対してリボーク要求メッセージを送る（処理２０４）。このリボーク要求メッセージには、図３にて後述するように、トークンを要求しているノード（クライアント１１）、要求しているトークンのステート（クライアント１１が要求しているステート（リード又はライト））の情報が含まれている。
【００３３】
クライアント１０は、リボーク要求メッセージを受け取ると、ライトデータトークンのリボーク処理（ライトデータトークンの返却とファイルの受け渡し）を行う。まず、トークン保持テーブル１０ｂからファイルＸに対するライトデータトークンを削除する（処理２０５）。次に、クライアント１０のキャッシュ１０ｃにあるファイルＸのデータがサーバ１２に反映されているかどうか、すなわちファイルＸにダーティーデータが存在するか否かを判定する（処理２０６）。ダーティーデータが存在すると判定した場合には、ダーティーデータを含んだファイルＸをトークン要求元（クライアント１１）に対して送信する（処理２０７）。このトークン要求元はトークン要求メッセージに含まれているトークン要求ノードより得る。ファイルＸを送ると処理２０８に移行する。
【００３４】
一方、処理２０６においてダーティーデータが存在しないと判定した場合には、処理２０８に移行する。
【００３５】
次に、ファイルＸを受け取ったトークン要求元（クライアント１１）は、受信したデータを自身のキャッシュ１１ｃに取り込む（処理２１１）。このとき、クライアント１１が処理２０２において要求したトークンの種類がリードデータトークンである場合には（処理２１２）、直ちにファイルＸをサーバ１２に書き出す処理（ファイルの同期処理）を行う（処理２１３）。これは、リードデータトークンのみを保有しているクライアントがダーティーデータを含むファイルを持つと、ファイルの一貫性（コンシステンシ）が失われるためである。すなわち、複数のクライアントが同時にファイルを読み出すことができるので、ディスクに未反映のデータがあるとファイルの一貫性が保てないためである。
【００３６】
このとき、クライアント１０は、処理２０５で受け取ったリボーク要求メッセージからトークン要求元の要求トークンステートフィールドを参照して、要求トークンの種類（要求トークンがリードであるかライトであるか）を判定する（処理２０８）。トークン要求元がライトデータトークンを要求していると判定した場合には、自身の持つキャッシュ１０ｃにあるファイルＸのダーティーデータを全て破棄する（処理２０９）。これは、同一のファイルに対して複数のクライアントにライトトークンを付与することはできないため、他のノードがライトデータトークンを要求した場合には、リボーク処理によってファイルの所有権を新たにライトデータトークンを保有するクライアントに完全に移行するためである。処理が完了すると、トークン要求元（クライアント１１）に対して自身のトークンステートの変化を通知する。
【００３７】
一方、処理２０８でトークン要求元がリードデータトークンを要求していると判定した場合には、キャッシュ内にあるファイルＸのダーティーデータに対応するダーティー状態を示すダーティーフラグをクリアし、データ自体は破棄せず読み込み専用データに変更してキャッシュ１０ｃに保存しておく。次に、自身のトークン保持テーブルにファイルＸのリードデータトークンを登録する（処理２１０）。これは同一のファイルに対してリードデータトークンは複数のクライアントが持つことができるためであり、ファイルＸの中のダーティーデータは処理２１３によってディスクに反映されるからである。処理が完了すると、トークン要求元（クライアント１１）に対して自身のトークンステートの変化を通知する。
【００３８】
ここで、クライアント１１は、処理２０９又は処理２１０によって、クライアント１０からトークンステートの変化の通知を受け、さらに処理２１３が完了すると、クライアント１０（トークンリボーク要求先）と自身（トークン要求元であるクライアント１１）のトークンステートの変化をサーバ１２に送信する（処理２１４）。なお、このクライアント１０のトークンステートの変化を、クライアント１１を経由することなく、クライアント１０からサーバ１２に直接送信するようにしてもよい。
【００３９】
サーバ１２はこの変化をトークン管理テーブル１２ａに反映する（処理２１５）。
【００４０】
次に、クライアント１１は、自身のトークン保持テーブル１１ｃに、処理２０２で要求したトークンの登録を行う（処理２１７）。そして、必要ならばサーバ１２に対してＩ／Ｏ処理を実行し、ストレージ装置１３よりファイルを読み込む（処理２１８）。
【００４１】
以上の処理によって、クライアント１０に対するトークンのリボーク処理が完了し、ダーティーデータを含んだデータＸがクライアント１０からクライアント１１へ渡される。
【００４２】
なお、上記の処理では、クライアント１０からクライアント１１に対してダーティーデータを含んだファイルＸの送信（処理２０７→処理２１１）とトークン状態変化通知の送信（処理２０９、２１０→処理２１４）は別に行っているが、ひとつのメッセージにまとめて一度に送信することも可能である。
【００４３】
また、図２の処理２０７おいて、クライアント１１に送る代わりにストレージ装置１３に書き出した方が性能上有利である場合、すなわちクライアント（またはサーバ１２）が、ＬＡＮのスループット性能やストレージ装置のＩ／Ｏのスループット性能等から予め設定しておいた性能予測式に基づいて、ディスクのＩ／Ｏスループット性能がＬＡＮのスループット性能より高いと判断した場合には、要求クライアントに対してファイルを送らずに、ストレージ装置１３に書き出す処理を行いダーティー状態でなくなったファイルを、要求クライアントが読み出すようにしてもよい。こうすることで、スループットの高い処理手段を優先でき、分断ファイルシステム全体としてのスループットが向上する。
【００４４】
図３に、図２に処理２０４において送信されるトークン要求メッセージの詳細を示す。
【００４５】
トークン要求メッセージは、ファイルＩＤフィールド４１、リボークトークン種フィールド４２、範囲指定フィールド４３、要求トークンステートフィールド４４、トークン要求ノードＩＤフィールド４５から構成される。
【００４６】
ファイルＩＤフィールド４１は、トークンの要求を行うファイルの情報を示している。リボークトークン種フィールド４２は、トークンの種別（例えばデータ、属性、サイズ、ファイル名等）を示す。範囲指定フィールド４３は、ファイルの範囲を示す。これはトークンによってファイルの範囲指定が可能な分散ファイルシステムにおいて、この範囲指定フィールド４３で指定した範囲内のみでクライアントが処理を行うことができるものである。要求トークンステートフィールド４４は、トークンのステート（リード／ライト）を示す。トークン要求ノードＩＤフィールド４５は、トークンを要求している要求元のクライアントの情報を示す。
【００４７】
以上のように構成された本発明の第１の実施の形態の分散ファイルシステムでは、あるクライアントが持っているダーティーデータを含んだファイルを他のクライアントが要求した場合に、ファイルをストレージに書き戻さず、ダーティーな状態のままのファイルを他のクライアントに渡すので、ストレージへのアクセス回数を減らすことができ、分散ファイルシステム全体のスループットを向上することができる。
【００４８】
次に、本発明の第２の実施の形態の分散ファイルシステムについて説明する。第２の実施の形態では、第１の実施の形態と比較すると、各クライアントが直接ストレージとＳＡＮによって接続されており、サーバを経由することなくストレージ上のデータを読み書きできる点が相違する。なお、第１の実施例と同一の動作をする構成には同一の符号を付し、その説明は省略する。
【００４９】
図４は第２の実施の形態の分散ファイルシステムの構成を表したブロック図である。
【００５０】
クライアント１０、１１とストレージシステム２６（サーバ２２）とがＬＡＮ２４によって接続されている。
【００５１】
ストレージシステム２６には、サーバ２２、ストレージ装置１３が備えられており、サーバ２２とストレージ装置１３とはＳＡＮ２５によって接続されている。
【００５２】
また、クライアント１０、１１も、ストレージ装置１３とＳＡＮ２５によって接続されている。そのため、クライアント１０、１１はサーバ２２を介することなくストレージ装置１３にあるファイルを読み込み、ストレージ装置２３に対してファイルを書き込むことができる。すなわち、クライアント１０、１１、サーバ２２、ストレージ装置１３がＳＡＮを構成している。
【００５３】
サーバ２２には、トークン管理テーブル２２ａ、トークン保持テーブル２２ｂ、キャッシュ２２ｃが備えられている。トークン管理テーブル２２ａは、各クライアントから発行されたトークンを受け取り、受け取ったトークンは、どのクライアントから、どのような内容（例えばリード、ライト等）のトークンであるかを該当するデータに対応付けて記憶する。トークン保持テーブル２２ｂは、クライアントが要求したトークンの内容を保持する。キャッシュ２２ｃは、データを一時的に保管するためのメモリである。
【００５４】
次に、上記のように構成された第２の実施の形態の分散ファイルシステムについて、次に動作を説明する。
【００５５】
本実施の形態の処理の流れは、第１の実施の形態（図２）と基本的には同一であるが、クライアント１０、１１は、ストレージ装置１３に対するＩ／Ｏをサーバを介することなく行うことができる。図２の処理２１３では、ファイルＸをサーバ１２に対して送った後にストレージ装置１３に書き込まれるが、第２の実施の形態では、クライアント１１が直接ストレージ装置１３に対してＩ／Ｏを行いファイルＸを書き込む。同様に、処理２１８では、クライアント１１が直接ストレージ装置１３に対してファイルＸに対するＩ／Ｏを発行する。
【００５６】
以上のように構成された第２の実施の形態では、第１の実施の形態の効果に加え、クライアントがサーバ１２を介すことなくストレージ装置にＩ／Ｏが行えるので、サーバ１２の処理が軽減され、結果として分散ストレージシステム全体としてのスループットを向上することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態の分散ファイルシステムの構成を示すブロック図である。
【図２】同じく分散ファイルシステムの処理を示すフローチャートである。
【図３】同じくリボーク要求トークンの内容を示すフォーマット図である。
【図４】本発明の第２の実施形態の分散ファイルのシステムの構成を示すブロック図である。
【図５】従来のトークンリボーク要求の内容を示すフォーマット図である。
【図６】従来の分散ファイルシステムの処理を示すフローチャートである。
【符号の説明】
１０、１１クライアント
１０ｂ、１１ｂトークン保持テーブル
１０ｃ、１１ｃキャッシュ
１２サーバ
１２ａトークン管理テーブル
１２ｂトークン保持テーブル
１２ｃキャッシュ
１３ストレージ装置
１４ＬＡＮ
１５ＳＡＮ
１６ストレージシステム
２０クライアント
２２サーバ
２２ａトークン管理テーブル
２２ｂトークン保持テーブル
２２ｃキャッシュ
２３ストレージ装置
２５ＳＡＮ
２６ストレージシステム

Claims

ファイルを保持するストレージ装置と、前記ストレージ装置に対してファイルの操作を行う複数のクライアントと、前記複数のクライアントによるファイルに対する書き込み及び読み込み操作権限を管理するサーバと、がネットワークを介して通信可能に接続された分散ファイルシステムであって、
第１のクライアントは、
前記ファイルに対する書き込み又は読み込み要求を生成する手段と、
前記ファイルに対して、自身が書き込み又は読込み操作権限を有するか否かを示す操作権限情報を保持する手段と、
前記書き込み又は読み込み要求が生成された前記ファイルについて、自身が書き込み又は読み込み操作権限を有するか否かを前記操作権限情報に基づいて判断する手段と、
前記判断の結果、前記ファイルについて書き込み又は読み込み操作権限が無い場合、前記ファイルに対する書き込み又は読み込み操作権限の付与の要求、該ファイルのＩＤ及び前記第１のクライアントのＩＤを含む操作権限付与要求を前記サーバに送信する手段と、を有し、
前記サーバは、
前記複数のクライアント毎に、クライアントのＩＤ、前記ファイルのＩＤ及び現在の書き込み又は読み込み操作権限の状態を示す情報を対応付けて管理する手段と、
前記第１のクライアントから前記操作権限付与要求を受け、当該ファイルに対する書き込み操作権限を有するクライアントを、前記対応付けられた情報に基づいて検索する手段と、
前記検索の結果、前記書き込み操作権限を有する第２のクライアントがある場合、前記第１のクライアントのＩＤ及び前記ファイルのＩＤを含む書き込み操作権限返還要求を前記第２のクライアントに送信する手段と、を有し、
前記第２のクライアントは、
自身に設けられた記憶部に記憶された、前記ファイルのＩＤに対応するファイルが前記ストレージ装置に反映済みであるか否かを示す情報を保持する手段と、
前記サーバから書き込み操作権限返還要求を受信し、前記ストレージ装置に反映済みであるか否かを示す情報に基づいて、当該書き込み操作権限返還要求に対応するファイルが、前記ストレージ装置に反映済みであるか否かを判断する手段と、
該判断結果が未反映の場合、前記書き込み操作権限返還要求に含まれた前記第１のクライアントのＩＤに基づいて、前記第１クライアントに前記ファイルを送信する手段と、
を有することを特徴とする分散ファイルシステム。
請求項１に記載の分散ファイルシステムであって、
前記第２クライアントは、前記第１クライアントに前記ファイルを送信した後、自身に設けられた記憶部に記憶した前記ストレージ装置に未反映のファイルを削除する手段を備えることを特徴とする分散ファイルシステム。
請求項１又は請求項２に記載の分散ファイルシステムであって、
前記第１クライアントは、前記第２クライアントから送信された前記ストレージ装置に未反映のファイルを受信した後、前記サーバに送信した前記操作権限要求が、読み込み操作権限である場合、該ファイルを前記ストレージ装置に反映することを特徴とする分散ファイルシステム。
ファイルを保持するストレージ装置と、前記ストレージ装置に対してファイルの操作を行う複数のクライアントと、前記複数のクライアントによるファイルに対する書き込み及び読み込み操作権限を管理するサーバと、がネットワークを介して通信可能に接続された分散ファイルシステムの運用方法であって、
第１のクライアントが、
前記ファイルに対する書き込み又は読み込み要求を生成するステップと、
前記ストレージ装置に格納されたファイルのＩＤと、前記ファイルに自身が書き込み又は読込み操作権限を有するか否かを示す操作権限情報とを保持するステップと、
前記書き込み又は読み込み要求が生成された前記ファイルについて、自身が書き込み又は読み込み操作権限を有するか否かを前記操作権限情報に基づいて判断するステップと、
前記判断の結果、前記ファイルについて書き込み又は読み込み操作権限が無い場合、前記ファイルに対する書き込み又は読み込み操作権限の付与の要求、該ファイルのＩＤ及び前記第１のクライアントのＩＤを含む操作権限付与要求を前記サーバに送信するステップと、を含み、
前記サーバが、
前記複数のクライアント毎に、クライアントのＩＤ、前記ファイルのＩＤ及び現在の書き込み又は読み込み操作権限の状態を示す情報を対応付けて管理するステップと、
前記第１のクライアントから前記操作権限付与要求を受け、当該ファイルに対する書き込み操作権限を有するクライアントを、前記対応付けられた情報に基づいて検索するステップと、
前記検索の結果、前記書き込み操作権限を有する第２のクライアントがある場合、前記第１のクライアントのＩＤ及び前記ファイルのＩＤを含む書き込み操作権限返還要求を前記第２のクライアントに送信するステップと、を含み、
前記第２のクライアントが、
自身に設けられた記憶部に記憶された、前記ファイルのＩＤに対応するファイルが前記ストレージ装置に反映済みであるか否かを示す情報を保持するステップと、
前記サーバから書き込み操作権限返還要求を受信し、前記ストレージ装置に反映済みであるか否かを示す情報に基づいて、当該書き込み操作権限返還要求に対応するファイルが、前記ストレージ装置に反映済みであるか否かを判断するステップと、
該判断結果が未反映の場合、前記書き込み操作権限返還要求に含まれたクライアントのＩＤに基づいて、前記第１クライアントに前記ファイルを送信するステップと、
を含むことを特徴とする分散ファイルシステムの運用方法。
請求項４に記載の分散ファイルシステムの運用方法であって、
前記第２クライアントが、前記第１クライアントに前記ファイルを送信した後、自身に設けられた記憶部に記憶した前記ストレージ装置に未反映のファイルを削除するステップを更に含むことを特徴とする分散ファイルシステムの運用方法。
請求項４又は請求項５に記載の分散ファイルシステムの運用方法であって、
前記第１クライアントが、前記第２クライアントから送信された前記ストレージ装置に未反映のファイルを受信した後、前記サーバに送信した前記操作権限要求が読み込み操作権限である場合、該ファイルを前記ストレージ装置に反映するステップを更に含むことを特徴とする分散ファイルシステムの運用方法。