(57)【要約】【課題】サーバの側に専用の特別なハードウェアおよびソフトウェアを必要とせずに複数のサーバの共有リソースを多重化することのできる分散ファイルシステムを提供する。【解決手段】本発明に係るクライアント装置１１は、各々が共有リソースを含む記憶装置を有する複数のサーバ１３ａ〜１３ｄとネットワークによって相互に接続され、分散ファイルシステムに対する第１の操作命令を発行するアプリケーションソフト３１と、分散ファイルシステム上の識別子を各々のサーバの共有リソース上の識別子に対応づけるファイル識別子管理テーブル５０と、ファイル識別子管理テーブルの内容に基づいて、第１の操作命令から各々の共有サーバに対する第２の操作命令を生成するメタ情報管理機構４２とを有する。【選択図】図２
2009251756.tif 000002
【特許請求の範囲】
【請求項１】
各々が共有リソースを含む記憶装置を有する複数のサーバとネットワークによって相互に接続されて分散ファイルシステムを構成するクライアント装置であって、
前記分散ファイルシステムに対する第１の操作命令を発行するアプリケーションソフトと、
前記分散ファイルシステム上の識別子を各々の前記サーバの前記共有リソース上の識別子に対応づけるファイル識別子管理テーブルと、
前記ファイル識別子管理テーブルの内容に基づいて、前記第１の操作命令から各々の前記共有サーバに対する第２の操作命令を生成するファイル識別子管理機構と
を有することを特徴とするクライアント装置。
【請求項２】
前記第２の操作命令を前記各々のサーバに実行させ、該操作命令に対する返答を前記アプリケーションソフトに返す同期機構を有することを特徴とする、請求項１に記載のクライアント装置。
【請求項３】
前記同期機構が、前記第１の操作命令が書き込み命令である場合、前記第２の操作命令を発行した全ての前記共有サーバから該操作命令に対する返答があったことを確認するまで前記アプリケーションソフトに返答を返さないことを特徴とする、請求項２に記載のクライアント装置。
【請求項４】
前記同期機構が、前記第２の操作命令を発行した前記共有サーバの中に該操作命令に対する返答がないサーバが存在する場合に該サーバに対して予め定められた回数だけ該操作命令を再送し、前記操作命令の再送を行っても該操作命令に対する返答がないサーバを前記分散ファイルシステムの構成から除外することを特徴とする、請求項３に記載のクライアント装置。
【請求項５】
前記分散ファイルシステムの構成から除外されたサーバに対して定期的にテスト命令を送信し、前記テスト命令に対して正常な返答があったサーバを再び前記分散ファイルシステムの構成に加えるリカバリ機構を有することを特徴とする、請求項４に記載のクライアント装置。
【請求項６】
前記同期機構が、前記第１の操作命令が読み出し命令である場合、前記ファイル識別子管理テーブルに含まれるマスタハンドル情報によって決定されるマスタサーバにのみ前記第２の操作命令を発行することを特徴とする、請求項３に記載のクライアント装置。
【請求項７】
前記同期機構が、前記マスタサーバから前記第２の操作命令に対する返答がない場合に該マスタサーバに対して予め定められた回数だけ該操作命令を再送し、前記操作命令の再送を行っても該操作命令に対する返答がない場合に前記マスタサーバと前記分散ファイルシステムを構成する他のサーバに対して前記第２の操作命令を発行することを特徴とする、請求項６に記載のクライアント装置。
【請求項８】
前記アプリケーションソフトが主記憶装置のユーザ領域に記憶され、前記メタ情報管理機構および前記同期機構が主記憶装置のカーネル領域に記憶されていることを特徴とする、請求項２に記載のクライアント装置。
【請求項９】
クライアント装置と、各々が共有リソースを含む記憶装置を有する複数のサーバがネットワークによって相互に接続されて構成される分散ファイルシステムであって、
前記クライアント装置が請求項１ないし請求項８のうちいずれか１項に記載のクライアント装置であることを特徴とする分散ファイルシステム。
【請求項１０】
アプリケーションソフトを実行するクライアント装置と、各々が共有リソースを含む記憶装置を有する複数のサーバが相互に接続して分散ファイルシステムを構成するネットワークにあって、前記共有リソースを多重化する方法であって、
前記アプリケーションソフトが第１の操作命令を発行する第１の命令発行工程と、
前記分散ファイルシステム上の識別子を各々の前記サーバの前記共有リソース上の識別子に対応づけるファイル識別子管理工程と、
前記ファイル識別子管理工程によって対応づけられた識別子に基づいて、前記第１の操作命令から各々の前記共有サーバに対する第２の操作命令を生成する命令生成工程と
を有することを特徴とする共有リソース多重化方法。
【請求項１１】
前記第２の操作命令を前記各々のサーバに対して発行する第２の命令発行工程と、
該操作命令に対する返答を前記アプリケーションソフトに返す返答工程とを有することを特徴とする、請求項１０に記載の共有リソース多重化方法。
【請求項１２】
アプリケーションソフトを実行するクライアント装置と、各々が共有リソースを含む記憶装置を有する複数のサーバが相互に接続して分散ファイルシステムを構成するネットワークにあって、前記クライアント装置に、
前記アプリケーションソフトが第１の操作命令を発行する第１の命令発行処理と、
前記分散ファイルシステム上の識別子を各々の前記サーバの前記共有リソース上の識別子に対応づけるファイル識別子管理処理と、
前記ファイル識別子管理処理によって対応づけられた識別子に基づいて、前記第１の操作命令から各々の前記共有サーバに対する第２の操作命令を生成する命令生成処理と
を実行させることを特徴とする共有リソース多重化プログラム。
【請求項１３】
前記第２の操作命令を前記各々のサーバに対して発行する第２の命令発行処理と、
該操作命令に対する返答を前記アプリケーションソフトに返す返答処理とを実行させることを特徴とする、請求項１２に記載の共有リソース多重化プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークで相互に接続されたクライアントおよびサーバによって構成される分散ファイルシステムに関し、特に該分散ファイルシステムにおける共有リソースの多重化に関する。
【背景技術】
【０００２】
分散ファイルシステムとは、単一のファイルシステムが複数の物理コンピュータノードに分散して存在する形態のネットワークファイルシステムであり、分散システムもしくはイントラネット上の機器群に分散して配置されたクライアント、サーバ、記憶装置から構成される。
【０００３】
分散ファイルシステムの信頼性を向上するには、主に次のような方法がある。一つは、共有リソースを提供するサーバに対して、クラスタ化ソフトウェアを適用するなどして、該共有リソースの多重化を行うという方法である。他には、それらのサーバ間で共有できるディスク装置の機能によって、データを保持する記憶領域をハードウェア的に多重化するという方法もある。さらに、そのディスク装置内の別々の領域に対してソフトウェアによる多重化を行なうこともできる。
【０００４】
これらの方法で多重化された共有リソースは、クライアント側からみれば仮想的な単一のサーバとして扱われる。クライアントが仮想的な単一のサーバに対して発行したＩ／Ｏ命令から、サーバもしくはディスク装置の側が多重化の対象となっている各々の装置に対するＩ／Ｏ命令を生成してそれぞれ実行させる。クライアントで動作するアプリケーションソフトは通常、多重化の対象の装置のそれぞれに対してＩ／Ｏ命令を発行する機能を備えないからである。
【０００５】
なお、分散ファイルシステムにおけるサーバの多重化については、次のような従来技術がある。特許文献１には、クライアントからジョブの依頼を受けたマスタサーバが、スレーブサーバにも同じジョブを依頼する仕組みの分散ファイルシステムが記載されている。特許文献２には、複数のファイルサーバのファイルシステムを端末からみて仮想的に一つのファイルシステムとして提供するスイッチ装置を備え、該スイッチ装置が複数のファイルサーバにスナップショット作成を指示するという分散ファイルシステムが記載されている。特許文献３には、複数のファイルサーバのファイルシステムを、統合ディレクトリ上の統合ファイルとして管理することができる分散ファイルシステムが記載されている。
【０００６】
【特許文献１】特開平０９−２１８８４０号公報
【特許文献２】特開２００６−０９９４０６号公報
【特許文献３】特開平１１−２８２７４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
前述した従来の方式では、多重化の対象となるサーバもしくはディスク装置を仮想的に単一のサーバとして扱うことを可能とするために、たとえば専用のクラスタ化ソフトウェア、もしくはハードウェア的に多重化を実現するディスク装置などを導入する必要がある。これは、サーバの側に専用の特別なハードウェアもしくはソフトウェアが必要であるので、コストがかかるばかりか、設定および構築が煩雑である。多重化するサーバの台数が多くなるほど、このコストはさらに膨れ上がる。
【０００８】
特許文献１〜３の技術も、複数の装置を仮想的に単一のサーバとして扱うことのできる分散ファイルシステムを提供するものである。しかしながら、特許文献１の技術では、「マスタサーバ」に「スレーブサーバ」と連携するための仕組みを導入する必要がある。特許文献２の技術では多重化のために「スイッチ装置」が必要であり、特許文献３の技術でも「統合ディレクトリ」を管理する装置が必要である。つまり、これらの技術はいずれも、サーバの側に専用の特別なハードウェアもしくはソフトウェアが必要であるという問題点を解決するものではない。
【０００９】
本発明の目的は、サーバの側に専用の特別なハードウェアおよびソフトウェアを必要とせずに複数のサーバの共有リソースを多重化することのできる、クライアント装置、分散ファイルシステム、共有リソースの多重化方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明に係るクライアント装置は、各々が共有リソースを含む記憶装置を有する複数のサーバとネットワークによって相互に接続されて分散ファイルシステムを構成するクライアント装置であって、分散ファイルシステムに対する第１の操作命令を発行するアプリケーションソフトと、分散ファイルシステム上の識別子を各々のサーバの共有リソース上の識別子に対応づけるファイル識別子管理テーブルと、ファイル識別子管理テーブルの内容に基づいて、第１の操作命令から各々の共有サーバに対する第２の操作命令を生成するメタ情報管理機構とを有することを特徴とする。
【００１１】
上記目的を達成するため、本発明に係る分散ファイルシステムは、クライアント装置と、各々が共有リソースを含む記憶装置を有する複数のサーバがネットワークによって相互に接続されて構成される分散ファイルシステムであって、クライアント装置が請求項１ないし請求項８のうちいずれか１項に記載のクライアント装置であることを特徴とする。
【００１２】
上記目的を達成するため、本発明に係る共有リソース多重化方法は、アプリケーションソフトを実行するクライアント装置と、各々が共有リソースを含む記憶装置を有する複数のサーバが相互に接続して分散ファイルシステムを構成するネットワークにあって、共有リソースを多重化する方法であって、アプリケーションソフトが第１の操作命令を発行する第１の命令発行工程と、分散ファイルシステム上の識別子を各々のサーバの共有リソース上の識別子に対応づけるファイル識別子管理工程と、ファイル識別子管理工程によって対応づけられた識別子に基づいて、第１の操作命令から各々の共有サーバに対する第２の操作命令を生成する命令生成工程とを有することを特徴とする。
【００１３】
上記目的を達成するため、本発明に係る共有リソース多重化プログラムは、アプリケーションソフトを実行するクライアント装置と、各々が共有リソースを含む記憶装置を有する複数のサーバが相互に接続して分散ファイルシステムを構成するネットワークにあって、クライアント装置に、アプリケーションソフトが第１の操作命令を発行する第１の命令発行処理と、分散ファイルシステム上の識別子を各々のサーバの共有リソース上の識別子に対応づけるファイル識別子管理処理と、ファイル識別子管理処理によって対応づけられた識別子に基づいて、第１の操作命令から各々の共有サーバに対する第２の操作命令を生成する命令生成処理とを実行させることを特徴とする。
【発明の効果】
【００１４】
本発明は、クライアント装置が分散ファイルシステム上の識別子を各々のサーバの共有リソース上の識別子に対応づけて管理するように構成したので、アプリケーションソフトが分散ファイルシステムに対して発行する第１の操作命令に対応して、各々の共有サーバに対する第２の操作命令をクライアント装置が発行することができる。これによって、サーバの側に専用の特別なハードウェアおよびソフトウェアを必要とせずに複数のサーバの共有リソースを多重化することのできるという、従来にない優れたクライアント装置、分散ファイルシステム、共有リソースの多重化方法およびプログラムを提供することができる。
【発明を実施するための最良の形態】
【００１５】
図１は、本発明の実施の形態に係るネットワーク１の構成を示すブロック図である。ネットワーク１において、クライアントコンピュータ１１（以後単にクライアント１１という）は、ＬＡＮ１２を介して複数のサーバ１３ａ〜１３ｄに接続する。サーバ１３ａ〜１３ｄは、各々ストレージ（外部記憶装置）１４ａ〜１４ｄを備える。また、サーバ１３ａ〜１３ｃはＬＡＮ１２に直接接続されるが、サーバ１３ｄはルータ１５を介してＬＡＮ１２に接続している。
【００１６】
サーバ１３ａ〜１３ｄは、各々のストレージ１４ａ〜１４ｄ内の記憶スペースの全部もしくは一部を共有リソースとして、ＬＡＮ１２に接続された他の機器（クライアント１１を初めとする）に公開している。なお、クライアント１１とサーバ１３ａ〜１３ｄがＬＡＮ１２を介して通信する仕組み、またサーバ１３ａ〜１３ｄがストレージ１４ａ〜１４ｄのリソースをＬＡＮ１２に接続された他の機器と共有する仕組みはすでに公知であり、また各々の機器が標準的に装備しているものである。クライアント１１は、サーバ１３ａ〜１３ｄの全てを同格とみなして、以後に説明する動作を行う。
【００１７】
図２は、図１で示したクライアント１１の構成をより詳しく示すブロック図である。クライアント１１は２台以上の複数のサーバに対して同じ動作を行うことができるが、ここでは２台のサーバ１３ａおよび１３ｂで構成される場合について説明する。
【００１８】
クライアント１１の主記憶装置２０はユーザ空間２１とカーネル空間２２とを有し、ユーザ空間２１にはアプリケーション３１が存在する。また、カーネル空間２２には、分散ファイルシステム３２と、ＲＰＣ３３と、ＴＣＰ／ＩＰ３４と、デバイスドライバ３５とが存在する。
【００１９】
アプリケーション３１は、クライアント１１において実行される、ごく一般的なアプリケーションソフトである。ＲＰＣ３３（Remote Procedure Call）は、プログラムから別のアドレス空間にあるサブルーチンや手続きを実行することを可能にする技術である。ＴＣＰ／ＩＰ３４は、ネットワークにおけるごく標準的なプロトコルであり、ここでは２台のサーバ１３ａおよび１３ｂと通信するために使われる。デバイスドライバ３５は、クライアント１１が備える通信デバイス（図示せず）を駆動する。
【００２０】
そして分散ファイルシステム３２に、仮想化レイヤ４０が設けられている。仮想化レイヤ４０は、アプリケーション３１に対してあたかも１台のサーバ上のリソースを扱っているかのように見せつつ、実際にはサーバ１３ａおよび１３ｂの各々の共有リソースに対して同時にデータの読み書きを行うというものである。
【００２１】
図３は、図２で示した仮想化レイヤ４０の構成をより詳しく示すブロック図である。仮想化レイヤ４０は、多重化許可機構４１、メタ情報管理機構４２、ファイル識別子管理機構４３、および多重通信同期処理機構４４からなる。ここでいうクライアント上の仮想化とは、クライアント１１上においてサーバのリソースを示す識別子を仮の識別子として割り当て、そこに複数のサーバの共有リソースにおける実際の識別子を関連付けることによって行なう。以後、クライアント１１上で割り当てられる識別子を仮想ファイルハンドル、また該サーバの実際の識別子を実ファイルハンドルという。
【００２２】
多重化許可機構４１は、多重化したい複数のサーバの共有リソースを、クライアントの同一のマウントポイントにマウントすることを可能にする。メタ情報管理機構４２は、仮想ファイルハンドル５１を、クライアント１１で利用可能な情報に変換するための処理を行う。
【００２３】
ファイル識別子管理機構４３は、仮想ファイルハンドルと実ファイルハンドルとの間の対応関係をファイル識別子管理テーブル５０に記録し、その管理を行う。また、アプリケーション３１から発行された仮想ファイルハンドルに対する操作命令から、実ファイルハンドルに対する操作命令を生成する。以後、この実ファイルハンドルに対する操作命令を、メタ情報ということがある。
【００２４】
多重通信同期処理機構４４は、同期機構４５、リカバリ機構４６、およびタイマ４７からなる。同期機構４５は、実ファイルハンドルに対する操作命令を各サーバに実行させ、それに対する各サーバからの返答をアプリケーション３１に返す。リカバリ機構４６については後述する。タイマ４７は、所定の間隔でリカバリ機構４６を動作させる。
【００２５】
図４は、図３で示したファイル識別子管理テーブル５０に記録されるデータの構成を示す概念図である。ファイル識別子管理テーブル５０には、仮想ファイルハンドル５１、サーバアドレス５２、実ファイルハンドル５３、状態５４、マスタハンドル５５、資源ハンドル５６の各データが主に記録される。これら以外のデータを適宜含むようにしてもよい。
【００２６】
図４の例では、仮想ファイルハンドル５１「abcd1234」に対して、サーバアドレス５２「sv1.office1」というサーバの実ファイルハンドル５３「xyz9876」、およびサーバアドレス５２「sv2.office1」というサーバの実ファイルハンドル５３「uvw5432」とが対応することが示されている。状態５４は各々の実ファイルハンドル５３ごとの状態を示すものであり、後述する「sync」「down」「recover」という３通りの状態がある。マスタハンドル５５、資源ハンドル５６については後述する。
【００２７】
図３に戻って、同期機構４５は、メタ情報管理機構４２で生成された実ファイルハンドル５３に対する操作命令を、各サーバへのＩ／Ｏ命令として発行する。そして、該操作命令がREAD（読み出し）要求でない場合は、各サーバに対する書き込み操作の全てが完了するまでは、アプリケーション３１に返答を返さない。これによって、各サーバに同じデータが記録されることを保証する。READ要求である場合の処理は後述する。
【００２８】
また、同期機構４５では、各サーバからの応答を所定の時間だけ待っても応答がなく、さらに所定の回数だけリトライしてもやはり応答がない場合は、該サーバがダウンしているものとして扱う。この場合、ファイル識別子管理機構４３は該当する実ファイルハンドル５３の状態５４に「down」を記録し、該サーバを多重化対象から除外する。
【００２９】
さらにこの場合、ファイル識別子管理機構４３は、同じ仮想ファイルハンドル５１に関連付けられた他の実ファイルハンドル５３の状態５４を「recover」とする。これは、該当サーバが復旧した際に、反映させなければならないデータであることを示すものである。なお、同一の仮想ファイルハンドル５１に関連付けられたすべての実ファイルハンドル５３が正しく応答している場合は、ファイル識別子管理機構４３は該当するすべての実ファイルハンドル５３の状態５４に「sync」と記録する。
【００３０】
リカバリ機構４６は、タイマ４７によって所定の間隔で起動され、状態５４に「down」が記録されたサーバを、多重化の対象に再度組み込む処理を行う。より具体的には、他のサーバとの差分を該当サーバに反映させる処理を行う。リカバリ機構では、「down」の状態のサーバに対して定期的にテストＩ／Ｏを発行して、正常な応答があるか否かをチェックすることによって復旧確認を行う。正常な応答があった場合は、差分情報の反映を実施する。すべて反映が完了した時点で、状態５４を「down」から「sync」に変更し、多重化対象として再び組み込む。
【００３１】
同期機構４５がファイルを読み込む時、すべてのサーバから同時にデータを読み出すのではなく、多重化されているサーバのうちのひとつをマスタサーバとして、その１台のサーバから読み込むようにする。ファイル識別子管理機構４３は、マスタとして扱うかどうかを判断するためのマスタハンドル５５をファイル識別子管理テーブル５０内に保持する。マスタハンドル５５が「１」であるサーバがマスタサーバであり、「０」であるサーバはマスタサーバではない。
【００３２】
仮にマスタサーバが「down」の状態となった場合、ファイル識別子管理機構４３は現在マスタハンドル５５が「０」であるサーバを、該ハンドルを「１」に変更して、マスタサーバとして再割り当てする。
【００３３】
以後のフローチャートで説明する動作を実施するための前提条件として、全ての分散ファイルシステムサーバが提供する初期状態は同じで、時刻も一致しているものとする。
【００３４】
図５は、図１〜４で示したネットワーク１で多重化許可機構４１が行う処理を示すフローチャートである。多重化許可機構４１は、分散ファイルシステムサーバとして多重化する対象であるサーバ１３ａおよび１３ｂを、サーバリソースとしてクライアント１１上の同じマウントポイントにすべてマウントする（ステップＳ１０１）。このマウントの動作が失敗すれば「エラー」として処理を打ち切る（ステップＳ１０２：ＮＯ）。
【００３５】
マウントの動作が成功すれば（ステップＳ１０２：ＹＥＳ）、マウントされた各サーバの使用可能領域をチェックして書き込み可能サイズを決定する（ステップＳ１０３）。その際、利用可能領域（ファイルシステムサイズ）に違いがある場合は、その中で最も少ないファイルシステムサイズを全ての多重化サーバの書き込み可能サイズとする。
【００３６】
そして、ファイル識別子管理機構４３に、このマウントポイントに対する仮想ファイルハンドルの登録を依頼して（ステップＳ１０４）、多重化許可機構４１の処理を完了する。その際、多重化許可機構４１はREAD要求に対するデータ読み込み先とするマスタサーバを明示的に指定し、ファイル識別子管理機構４３はそれに応じてマスタサーバに該当するサーバのマスタハンドル５５を「１」として登録する。
【００３７】
また、ファイルシステムサイズなどのような資源情報は、ステップＳ１０３で判明した書き込み可能サイズが一番小さいサーバから取り出すようにする。すべてのサーバで利用可能なファイルシステムサイズが同じ場合は、マスタサーバのものを採用し、資源情報を取り出す対象であることを示す資源ハンドル５６に「１」をセットする。資源取り出し対象でないものは、資源ハンドル５６を「０」とする。
【００３８】
図６は、図１〜４で示したネットワーク１でファイル識別子管理機構４３が外部から要求を受けた場合に行う処理を示すフローチャートである。ファイル識別子管理機構４３は、外部から受けた要求がＩ／Ｏ要求であるかそれ以外の要求であるかをまず識別する（ステップＳ２０１）。Ｉ／Ｏ要求でなかった場合、その要求がマウント要求であるかそれ以外の要求であるかを識別する（ステップＳ２０２）。なお、ここでいうＩ／Ｏ要求とは、READ要求、WRITE（書き込み）要求、ファイル新規作成要求、およびファイル削除要求のうちのいずれかである。
【００３９】
Ｉ／Ｏ要求でもマウント要求でもない場合、ファイル識別子管理機構４３は該要求に対応して、ファイル識別子管理テーブル５０に記録された内容を更新して（ステップＳ２０６）図７に後述するメタ情報管理に進んで（ステップＳ２１３）終了する。
【００４０】
マウント要求を受けた場合、ファイル識別子管理機構４３は、仮想ファイルハンドル５１を管理するための管理テーブルをマウントポイント毎に作成して（ステップＳ２０４）、その後、マウントポイントに対する仮想ファイルハンドル５１をファイル識別子管理テーブル５０に登録して（ステップＳ２０７）、図７に後述するメタ情報管理に進んで（ステップＳ２１３）終了する。
【００４１】
Ｉ／Ｏ要求を受けた場合、ファイル識別子管理機構４３は、このＩ／Ｏ要求に該当する仮想ファイルハンドル５１に対する実ファイルハンドル５３をファイル識別子管理テーブル５０から取得し（ステップＳ２０３）、Ｉ／Ｏ要求と取得された実ファイルハンドル５３とを同期機構４５に渡す（ステップＳ２０７）。このステップＳ２０７の同期機構４５による処理は図８〜９に後述する。
【００４２】
そしてファイル識別子管理機構４３は、該Ｉ／Ｏ要求がファイルの新規作成要求かそれ以外のＩ／Ｏ要求であるかを識別する（ステップＳ２０８）。ファイルの新規作成要求であれば、ファイル識別子管理テーブル５０に、作成された新規ファイルに対応する仮想ファイルハンドル５１を追加して（ステップＳ２０９）、図７に後述するメタ情報管理に進んで（ステップＳ２１３）終了する。
【００４３】
該Ｉ／Ｏ要求がファイルの新規作成要求でなかった場合、さらにそれがファイル削除要求かそれ以外のＩ／Ｏ要求であるかを識別する（ステップＳ２０８）。ファイル削除要求であれば、ファイル識別子管理テーブル５０から、削除されたファイルに対応する仮想ファイルハンドル５１を削除して（ステップＳ２１１）、図７に後述するメタ情報管理に進んで（ステップＳ２１３）終了する。
【００４４】
該Ｉ／Ｏ要求がファイルの新規作成要求でもファイル削除要求でもなかった場合、ファイル識別子管理機構４３は該要求に対応して、ファイル識別子管理テーブル５０に記録された既存の仮想ファイルハンドル５１に関する状態を更新して（ステップＳ２１２）図７に後述するメタ情報管理に進んで（ステップＳ２１３）終了する。
【００４５】
図７は、図６のステップＳ２１３として示された、メタ情報管理機構４２による処理を示すフローチャートである。この処理は、図６に示された処理によって新しく生成された仮想ファイルハンドル５１を、クライアント１１で利用可能なようにファイル識別子管理テーブル５０に反映するための処理である。なお、ここでいうメタ情報とは、各々のファイルのサイズ、作成日時、更新日時、属性、オーナー、グループ、アクセス権限などのような、ＯＳで必要とする管理情報のことをいう。
【００４６】
ファイル識別子管理機構４３から渡された仮想ファイルハンドル５１に対応して、まずはマスタサーバ（マスタハンドル５５が「１」であるサーバ）の仮想ファイルハンドル５１に対応する情報をファイル識別子管理テーブル５０から抽出して（ステップＳ３０１）、正常に抽出できたら（ステップＳ３０２：ＹＥＳ）該サーバに対するメタ情報を生成してファイル識別子管理テーブル５０に記録する（ステップＳ３０５）。
【００４７】
マスタサーバが切り離されたなどのような理由で、マスタサーバの仮想ファイルハンドル５１に対応する情報が正常に抽出できなかったら（ステップＳ３０２：ＮＯ）、マスタサーバではない他のサーバの情報をファイル識別子管理テーブル５０から抽出して（ステップＳ３０３：ＹＥＳ〜Ｓ３０４）、そのサーバについてメタ情報を生成してファイル識別子管理テーブル５０に記録する（ステップＳ３０５）。他のサーバの情報も抽出できなかったら（ステップＳ３０３：ＮＯ）、「エラー」として処理を打ち切る。
【００４８】
図８〜９は、図６のステップＳ２０７として示された、同期機構４５による処理を示すフローチャートである。このフローチャートはやや複雑であるので、図面の錯綜を回避するため、２枚の図に分けて表示している。
【００４９】
同期機構４５はまず、自らの受けたＩ／Ｏ要求がREAD要求であるかそれ以外のＩ／Ｏ要求であるかを識別する（ステップＳ４０１）。READ要求であれば、マスタサーバにのみ該READ要求を発行して（ステップＳ４０３）、該要求が正常に完了したか否かを確認する（ステップＳ４０５）。
【００５０】
ステップＳ４０５で正常に完了したことが確認されればそのまま終了するが、そうでなければ所定の回数だけリトライして（ステップＳ４０６、４１１）、正常に完了したか否かをさらに確認して（ステップＳ４１３）、それで正常に完了したことが確認されればそのまま終了する。
【００５１】
所定の回数だけリトライしてもまだ正常に完了しないなら、該サーバと多重化されている他のサーバに切り替えて（ステップＳ４０８）、同じ要求を送信する（ステップＳ４１０）。以後、ステップＳ４０５、４０６、４１１、４１３と同様の処理を繰り返す（ステップＳ４１４、４１６、４１８、４２０）。ステップＳ４０８で切り替え可能なサーバが存在しないなら、「エラー」として処理を打ち切る。
【００５２】
ステップＳ４０１で、自らの受けたＩ／Ｏ要求がREAD要求以外である場合は、同期機構４５は全てのサーバに該要求を発行して（ステップＳ４０２）、全てのサーバにおいて該要求が正常に完了したか否かを確認する（ステップＳ４０４）。ステップＳ４０４で正常に完了したことが確認されればそのまま終了する。
【００５３】
ステップＳ４０４で正常に完了したことが確認されない場合は、該要求が完了していないサーバが存在するということである。その場合、同期機構４５は、該当する未完了サーバに要求を再送し（ステップＳ４０７）、該要求が正常に完了したか否かを確認する（ステップＳ４０９）。正常に完了したことが確認されればそのまま終了するが、そうでなければ所定の回数だけリトライして（ステップＳ４１２）、正常に完了したサーバが１台以上存在するか否かをさらに確認する（ステップＳ４１５）。全てのサーバが正常に完了していなければ、「エラー」として処理を打ち切る。
【００５４】
ステップＳ４１５で、正常に完了したサーバが１台以上存在すれば、同期機構４５は未完了のサーバの状態５４を「down」とマークして、多重化の対象から切り離す（ステップＳ４１８）。そしてリカバリ機構４６に、切り離したサーバが再組み込み可能か否かの確認を依頼する（ステップＳ４１９）。
【００５５】
図１０は、図１〜４で示したネットワーク１でリカバリ機構４６が定期的に行う処理を示すフローチャートである。リカバリ機構４６は、タイマ４７からの信号によって所定の間隔で起動されると（ステップＳ５０１）、状態５４を「down」となっているサーバに対して、定期的にテストＩ／Ｏを発行する（ステップＳ５０２）。テストＩ／Ｏに対して正常な応答があれば（ステップＳ５０３：ＹＥＳ）、状態５４が「recover」となっている実ファイルハンドル５３の内容を、「down」状態のサーバに反映する（ステップＳ５０４）。
【００５６】
ステップＳ５０４のリカバリ処理が成功したか否かを判断し、成功すれば（ステップＳ５０５：ＹＥＳ）、ファイル識別子管理テーブル５０を更新して状態５４を「sync」とする（ステップＳ５０６）。これによって、「down」状態だったサーバが、同期処理の対象として復活したことになる。なお、ステップＳ５０３および５０５で成功していないと判断されたサーバについては、ステップＳ５０１に戻って上記の処理を繰り返す。
【００５７】
以上で述べたように、本実施の形態ではクライアント１１内に仮想化レイヤ４０を持つだけで、サーバ１３ａ〜ｂについて記憶装置の多重化を実現することができる。その際、クライアント１１はソフトウェアの変更だけで済み、特別なハードウェアは不要である。またサーバ１３ａ〜ｂの側は特別なハードウェアもソフトウェアも不要である。従って、簡易かつ低コストで、記憶装置の多重化が実現されるのである。さらに、多重化している複数のサーバのうちいずれかがダウンした場合の構成の切替も瞬時に可能である。
【００５８】
なお、ここまで２台のサーバ１３ａ〜ｂにおける例について説明してきたが、３台以上のサーバについても以上で説明したものと全く同じように記憶装置の多重化を実現することができる。１台のクライアントが多重化できるサーバの台数について、特に制限はない。また、多重化するサーバの台数が増えても、クライアント側のソフトウェアの変更だけで済み、各々のサーバには特別なハードウェアおよびソフトウェアは不要であるので、クライアント側にはコストの上昇はほとんどなく、サーバ側のコストも低く抑えることができる。
【００５９】
これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることは言うまでもないことである。
【産業上の利用可能性】
【００６０】
クライアントおよびサーバが相互に接続され、共有リソースを有するネットワーク環境において、本発明を適用して共有リソースを多重化した分散ファイルシステムを構築することができる。
【図面の簡単な説明】
【００６１】
【図１】本発明の実施の形態に係るネットワークの構成を示すブロック図である。
【図２】図１で示したクライアントの構成をより詳しく示すブロック図である。
【図３】図２で示した仮想化レイヤの構成をより詳しく示すブロック図である。
【図４】図３で示したファイル識別子管理テーブルに記録されるデータの構成を示す概念図である。
【図５】図１〜４で示したネットワークで多重化許可機構が行う処理を示すフローチャートである。
【図６】図１〜４で示したネットワークでファイル識別子管理機構が外部から要求を受けた場合に行う処理を示すフローチャートである。
【図７】図６のステップＳ２１３として示された、メタ情報管理機構による処理を示すフローチャートである。
【図８】図６のステップＳ２０７として示された、同期機構による処理を示すフローチャートである。
【図９】図８の続きである。
【図１０】図１〜４で示したネットワークでリカバリ機構が定期的に行う処理を示すフローチャートである。
【符号の説明】
【００６２】
１  ネットワーク
１１  クライアント
１２  ＬＡＮ
１３ａ、１３ｂ、１３ｃ、１３ｄ  サーバ
１４ａ、１４ｂ、１４ｃ、１４ｄ  ストレージ
１５  ルータ
２０  主記憶装置
２１  ユーザ空間
２２  カーネル空間
３１  アプリケーション
３２  分散ファイルシステム
３３  ＲＰＣ
３４  ＴＣＰ／ＩＰ
３５  デバイスドライバ
４０  仮想化レイヤ
４１  多重化許可機構
４２  メタ情報管理機構
４３  ファイル識別子管理機構
４４  多重通信同期処理機構
４５  同期機構
４６  リカバリ機構
４７  タイマ
５０  ファイル識別子管理テーブル
５１  仮想ファイルハンドル
５２  サーバアドレス
５３  実ファイルハンドル
５４  状態
５５  マスタハンドル
５６  資源ハンドル
【図１】
2009251756.tif 000003
【図２】
2009251756.tif 000004
【図３】
2009251756.tif 000005
【図４】
2009251756.tif 000006
【図５】
2009251756.tif 000007
【図６】
2009251756.tif 000008
【図７】
2009251756.tif 000009
【図８】
2009251756.tif 000010
【図９】
2009251756.tif 000011
【図１０】
2009251756.tif 000012