JP2004318743A - ファイル移送装置 - Google Patents
ファイル移送装置 Download PDFInfo
- Publication number
- JP2004318743A JP2004318743A JP2003115183A JP2003115183A JP2004318743A JP 2004318743 A JP2004318743 A JP 2004318743A JP 2003115183 A JP2003115183 A JP 2003115183A JP 2003115183 A JP2003115183 A JP 2003115183A JP 2004318743 A JP2004318743 A JP 2004318743A
- Authority
- JP
- Japan
- Prior art keywords
- file
- computer
- transfer
- network
- packet
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99956—File allocation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Abstract
【課題】クライアントおよびファイルサーバがネットワークにより接続され、クライアントがネットワークを介してファイルサーバに接続されたディスク記憶装置内のファイルをアクセスするシステムにおいて、クライアントから遠隔地のファイルサーバ内のファイルへのアクセス性能が低下する。
【解決手段】ファイルサーバがクライアント付近のファイルサーバを検索し、発見したファイルサーバへファイルを移送する。クライアントは移送先ファイルサーバへ当該ファイルをアクセスする。
【選択図】 図１
【解決手段】ファイルサーバがクライアント付近のファイルサーバを検索し、発見したファイルサーバへファイルを移送する。クライアントは移送先ファイルサーバへ当該ファイルをアクセスする。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークを介して複数の計算機（コンピュータ）が接続されたシステム（以下「ネットワークシステム」）において、あるコンピュータがネットワークを介して他のコンピュータに接続された記憶装置内のデータにアクセスする技術に関する。
【０００２】
【従来の技術】
従来のネットワークシステムにおいて、他のコンピュータの記憶装置内のファイルに対してアクセス（読み出し（ｒｅａｄ）および書き込み（ｗｒｉｔｅ））を要求するコンピュータを、クライアントコンピュータ（以下、単にクライアント）と呼び、クライアントからの要求に応じて自ディスク装置内のファイルをアクセスし、その結果（ｒｅａｄデータや、正常にｗｒｉｔｅが行われたかどうかなど）を応答するコンピュータをファイルサーバコンピュータ（以下、単にファイルサーバもしくはサーバ）と呼ぶ。
【０００３】
クライアントがネットワークを介してファイルサーバが管理するファイルにアクセスする技術として、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）がある。以下、他のコンピュータが管理するファイルの読み出し又は書き込み（以下まとめて「アクセス」）を要求するコンピュータをクライアントと称する。また、クライアントからの要求に応じて、記憶装置に格納されたファイルをアクセスし、その結果（読み出したデータ、データの書き込みの完了報告等）をクライアントに応答するコンピュータをファイルサーバ又はサーバと称する。更に、ファイルとは、ユーザやコンピュータで実行されるアプリケーションプログラムが使用するデータの纏まりを指す。
【０００４】
ＮＦＳでは、クライアントはサーバに対してＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ：遠隔手続き呼び出し）要求メッセージパケットを送信してアクセスを要求する。一方、サーバは、ＲＰＣ応答メッセージパケットを返送してクライアントからの要求に応答する。
【０００５】
ＮＦＳのプロトコル設計は基本的にステートレス（サーバ・クライアント内に状態を保持しない）の方針に基づいているので、クライアントは、サーバから読み出したファイルをクライアントが有する記憶装置に一時的に保存（以下「キャッシュ」）しない。このため、クライアントが、サーバが管理するファイルをアクセスする場合には、かならずファイルサーバとの交信が発生する。
【０００６】
一方、ファイルサーバが管理するファイルをクライアント自身又はクライアント付近のサーバにキャッシュする技術として、分散ファイルシステム（ＤＦＳ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ）及びプロキシ（ｐｒｏｘｙ：代理）サーバがある。
【０００７】
ＤＦＳでは、クライアントが、サーバから読み出したファイルのデータを自身の記憶装置にキャッシュする。
【０００８】
また、プロキシサーバは、クライアントとサーバの間（多くはクライアントと同一のネットワーク上）に設置される。クライアントはサーバへファイルのアクセスを要求する際に、プロキシサーバへアクセス要求を送信する。プロキシサーバはクライアントに成り代わってサーバからファイルを読み出し、そのファイルをクライアントへ送信する。この際、プロキシサーバは取得したファイルをプロキシサーバ内にキャッシュする。
【０００９】
これ以降、クライアントから再び同一ファイルのアクセス要求がプロキシサーバへ送信された場合、プロキシサーバはサーバへアクセスすることなく、プロキシサーバ内にキャッシュされたファイルをクライアントに送信する。
【００１０】
更に、主となるファイルサーバと副となるファイルサーバを備え、主ファイルサーバの記憶容量が不足したとき、主ファイルサーバのファイルを副ファイルサーバへ移動し、移動されたファイルに対してクライアントからアクセス要求があった場合には、主ファイルサーバが副ファイルサーバからファイルを転送してもらうシステムが特許文献１に開示されている。
【００１１】
【特許文献１】
特開平６−２４３０７４号公報
【００１２】
【発明が解決しようとする課題】
ＮＦＳでは、クライアントがサーバのファイルをキャッシュしないため、クライアントが、サーバが管理するファイルへアクセスする時には、常にクライアント・サーバ間で要求パケットおよび応答パケットが往復する。このため、遠隔地にあるファイルサーバが管理するファイルをクライアントがアクセスする場合、サーバからのパケットがクライアントに到着するまでの遅延時間（レイテンシ）が増大し、クライアントのユーザに対するレスポンス性能が低下する。
【００１３】
一方、ＤＦＳ又はプロキシサーバのように、クライアント又はその近隣サーバにファイルをキャッシュすれば、パケット到着までのレイテンシの増加を抑えることができる。しかし、この「キャッシュ方式」には、以下の問題がある。
【００１４】
「キャッシュ方式」では、サーバ内にあるファイル（元ファイル）に加え、元ファイルの複製がクライアント等に複数個作成されるので、両者の同期を取る、即ち、データの内容を一致させる処理（「一貫性制御処理」）が必要となる。特に元ファイルと複製とが保存されているコンピュータとの間の距離が長いほど本処理の実行に時間がかかる。更に、ファイルが頻繁にクライアントによって更新される場合は、頻繁に本処理を行う必要があり、「キャッシュ方式」を導入したことによるレイテンシの増加抑制の効果が減少してしまう。
【００１５】
また、プロキシサーバでは、上述の一貫性制御は行われない。したがって、最新のファイルを得たい場合には、クライアントは、再度プロキシサーバにファイルのアクセス要求を指示しなければならず、レイテンシの増大は抑制できない。
【００１６】
一方、特許文献１に記載された「移送（ｍｉｇｒａｔｉｏｎ）方式」では、一貫性制御が不要である。しかし、ファイルの格納場所が移送前後で変化するので、移送されたファイルに対するクライアントのアクセス性能が移送元よりも移送先の方が悪ければ、ネットワークシステムの性能は低下してしまう。特に、特許文献１はファイルサーバの容量不足を解消することを目的としており、アクセス性能を向上させることは考慮されていない。したがって、特許文献１では、クライアントから主ファイルサーバまでの距離よりも副ファイルサーバまでの距離のほうが遠くなって、レイテンシが増大する可能性について考慮されていない。
【００１７】
特に、複数のクライアントから頻繁にアクセスされるファイルがどのファイルサーバに移送されるべきか否かは、そのファイルをアクセスする複数のクライアントがネットワークにどのように分布しているかの情報に基づいて行われることが重要であるが、従来技術では、この点について全く考慮されていない。
【００１８】
本発明の目的は、クライアントが遠隔地にあるファイルサーバが管理するファイルへアクセスする際に、ファイルの一貫性を保ちつつ一貫性制御のオーバヘッドをなくし、さらに、ネットワークのトラフィックを削減することである。
【００１９】
【課題を解決するための手段】
上記課題を解決するために、第一のサーバが、自ディスク装置内のファイルに対するアクセスを行うクライアントが属するネットワークの位置情報を検査し、ファイルの移送先となるサーバの候補を決定する。そして、アクセスを行うクライアントのネットワーク、もしくは、その周辺のネットワーク上の、不特定多数のサーバへ、ファイルを移送するサーバを調べるための移送先検索パケットを送信する。移送先検索パケットを受信した第二のサーバは、ファイルの移送の受け入れに関する移送許可パケットを第一のサーバに対して送信する。第一のサーバは、移送許可パケットの内容を検査し、第二のサーバがファイルを移送するのに適していることが分かれば、第二のサーバに対してファイルを移送する。
【００２０】
更に、第一のサーバは、ファイルを移送したことを示す移送通知パケットを、アクセスを行うクライアントのネットワーク、もしくは、その周辺のネットワークに送信するため、クライアントは、移送したファイルに対するアクセスを、第二のサーバに対して行う。
【００２１】
【発明の実施の形態】
図１は、本発明を適用したネットワークシステムの一実施形態を示す図である。本ネットワークシステムは、３台のファイルサーバ１０５、具体的には、ファイルサーバ１０５Ａ、１０５Ｂ及び１０５Ｃ、並びに３台のクライアント１０３、具体的には、クライアント１０３Ａ、１０３Ｂ及び１０３Ｃを有する。ファイルサーバ１０５Ａ、ファイルサーバ１０５Ｂ、クライアント１０３Ａ及びクライアント１０３Ｂは、通信線（ここではローカルエリアネットワーク。以下「ＬＡＮ」）１０１Ａ（以下「ＬＡＮ１」）を介して相互に接続されている。ファイルサーバ１０５Ｃ及びクライアント１０３Ｃは、ＬＡＮ１０１Ｂ（以下「ＬＡＮ２」）を介して相互に接続されている。
【００２２】
また、本例では、ＬＡＮ１及びＬＡＮ２は、インターネットやＷＡＮといった広域ネットワーク１０４により相互に接続されている。更に、ＬＡＮ１にはネットワークマスク１００．０．０．０／２４が、ＬＡＮ２には、ネットワークマスク２００．０．０．０／２４が与えられている。尚、本実施形態では通信線１０１としてＬＡＮを一例としてあげたが、他の通信線を用いても構わない。
【００２３】
また、本明細書では、インターネットプロトコルバージョン４（以下ＩＰｖ４）技術で用いられるアドレス表記をネットワークマスク等の表記に用いる。ここで、本実施形態のネットワークに接続されるコンピュータ等の機器には、それぞれ固有の３２ｂｉｔのＩＰアドレス（例えば”１００．０．０．１”）が割り振られる。また、ネットワークマスクの表記、例えばＬＡＮ１に割り振られたネットワークマスク”１００．０．０．０／２４”の表記は、ＬＡＮ１に接続されたコンピュータに、いずれも上位２４ｂｉｔ共通のＩＰアドレスが割り振られている、すなわち、ＬＡＮ１に接続されるコンピュータに、”１００．０．０．０”〜”１００．０．０．２５５”の範囲のＩＰアドレスが割り振られることを示している。したがって、ＬＡＮ１に接続される機器は、ＬＡＮ１に割り振られたネットワークマスクによって一つのグループ（以下「ネットワークグループ」）として識別されることになる。
【００２４】
各ファイルサーバ１０５は計算機であり、ＣＰＵ１１７、メモリ１０１、ネットワークインターフェイス１１７、ディスクＩＯインターフェイス１１８、及びディスク装置１１９を有する。ＣＰＵ１１７、メモリ１０１、ネットワークインターフェイス１１７及びディスクＩＯインターフェイス１１８は、接続線を介して相互に接続されている。また、ディスク装置１１９は、ディスクＩＯインターフェイス１１８を介してＣＰＵ１１７等と接続されている。更に、ファイルサーバ１０５は、ネットワークインターフェイス１１７を介してＬＡＮ１０１と接続される。
【００２５】
尚、ファイルサーバ１０５自身はディスク装置１１９を有さない構成としても良い。この場合、ファイルサーバ１０５はディスクＩＯインターフェース１１８の替わりにネットワークインターフェイスを有し、ファイルサーバ１０５は、このインターフェース及びネットワークを介して別筐体の記憶装置システムに接続されている構成とする。ここで使用されるインターフェース及びネットワークには、例えば、ファイバチャネルプロトコルが使用される。あるいは、ファイルサーバ１０５は、ファイルシステム機能に特化したネットワークアタッチドストレージ（ＮＡＳ）でも良い。
【００２６】
更に、ファイルサーバ１０５は、ディスク装置１１９を有し、かつ別筐体の記憶装置システムに接続するためのネットワークインターフェイスを有する構成としても良い。
【００２７】
ここで、記憶装置システムとは、記憶媒体及び制御部を有する記憶装置である。記憶媒体には、磁気ディスク又は光ディスク等が使用される。また、記憶装置システムには、冗長構成を有するディスクアレイも含まれる。尚、ファイルサーバ１０５が有するディスク装置１１９は、単体のハードディスクドライブでも、ディスクアレイ、ＤＶＤ等でも良い。
【００２８】
メモリ１０１には、ファイルシステムプログラム１２０、ノード・パス名変換テーブル１２１及びアクセス統計テーブル１２２が格納される。図では、テーブルの情報やプログラムは丸で囲んで示している。これらのプログラムやテーブルは、電源オフ時にはファイルサーバ１０５が有する不揮発性記憶媒体（ディスク装置１１９やＲＯＭなど）に格納されている。ファイルサーバ１０５は、これらのテーブルやプログラムを使用する際に、不揮発性記憶媒体からメモリ１０１にこれらのプログラム等を読み出す。ファイルシステムプログラム１２０等のプログラムは、フロッピー（登録商標）ディスクやＤＶＤの記憶媒体、ネットワーク等の通信回線あるいは無線通信等を介してファイルサーバ１０５のディスク装置１１９又はメモリ１０１にインストールされる。
【００２９】
ＣＰＵ１１６は、ファイルシステムプログラム１２０を実行し、ＬＡＮ１０１等に接続された他のファイルサーバ１０５等とのパケット通信、ディスク装置１１９へのアクセス、メモリ１０１内のデータの更新、等を行う。
【００３０】
また、各クライアント１０３もファイルサーバ同様に、ＣＰＵ１１６、メモリ１１１、ネットワークインターフェイス１１７を有する計算機である。尚、本実施形態では、クライアント１０３はディスク装置１１９の替わりにＲＯＭ装置１１０を有する。クライアント１０３をファイルサーバ１０５と同じ構成とすることもできる。クライアント１０３は、ネットワークインターフェイス１１６を介してＬＡＮ１０１と接続される。
【００３１】
クライアント１０３のメモリ１１１には、アプリケーションプログラム１１３、ファイルシステムプログラム１１４及びノード・パス名変換テーブル１１５が格納される。これらのプログラム等は、電源オフ時には、ＲＯＭ装置１１０に格納されている。
【００３２】
クライアント１０３のＣＰＵ１１６は、ファイルシステムプログラム１１４を実行し、ＬＡＮ１０１を介してファイルサーバ１０５のディスク装置１１９に格納されているファイルにアクセスする。また、クライアント１０３のＣＰＵ１１６は、アプリケーションプログラム１１３を実行して、クライアントを使用する人が所望するサービスを提供する。
【００３３】
本実施形態のファイルシステムプログラム１１４、１２０によって実現されるファイルシステムは、ＵＮＩＸ（登録商標）その他の一般的なＯＳに採用されているように、論理的な木構造の元にファイルを管理する階層型のファイルシステムである。具体的には、ルート・ディレクトリを根とし、ディレクトリの下にファイルもしくはディレクトリを配するデータ構造が用いられる。本実施形態では、ファイルシステムで管理されるファイルを、「／ｄｏｃ／ｍｉｓｃ／ｒｅａｄｍｅ．ｔｘｔ」のように、ディレクトリ名の連接とファイル名を区切り文字（”／”）で区切った文字列（以下、「ファイルのパス名」）により表す。
【００３４】
図２は、本実施形態のクライアント１０３とサーバ１０５間でやり取りされるアクセス要求および応答パケットの例を示す図である。ＬＡＮ１０１での通信は、所定の通信プロトコルに基づくパケットによるデータ送受信でおこなわれる。クライアント１０３は、図２のＡ及びＢに示す読み出し（以下「ｒｅａｄ」）及び書き込み（以下「ｗｒｉｔｅ」）要求パケットをファイルサーバ１０５へ送信する。ファイルサーバ１０５は、図２のＣ及びＤに示すｒｅａｄ／ｗｒｉｔｅ返答パケットをＬＡＮ１０１を介してクライアント１０３へ返信する。
【００３５】
図２Ａは、クライアントＡ（送り元フィールド値に１００．０．０．１のクライアントＡのＩＰアドレスが格納されている）がファイルサーバＣ（宛先フィールドが２００．０．０．１０１）に対して、ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）をｒｅａｄ要求（要求種別）するパケットである。
【００３６】
図２Ｂは、クライアントＡ（送り元）がファイルサーバＣ（宛先）に対して、ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）にデータ本体（データフィールドに格納）をｗｒｉｔｅ要求（要求種別）するパケットである。
【００３７】
図２Ｃは、サーバＣ（送り元）がクライアントＡ（宛先）に、ｒｅａｄ応答（要求種別）を返すパケットである。ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）をデータフィールドに格納して返答している。
【００３８】
図２Ｄは、サーバＣ（送り元）がクライアントＡ（宛先）に、ｗｒｉｔｅ応答（要求種別）を返すパケットである。ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）が正常に書き込まれたことを返答している。
【００３９】
各ファイルサーバ１０５のＣＰＵ１１６は、ファイルシステムプログラム１２０を実行することで、クライアント１０３からのアクセスを監視し、その結果をアクセス統計テーブル１２２に格納する。
【００４０】
図３は、アクセス統計テーブル１２２の例を示す図である。アクセス統計テーブル１２２には、クライアント１０３からアクセスされたファイルのパス名を登録するエントリ６０１、要求元となるクライアント１０３が所属するネットワークグループに共通するネットワークマスクを登録するエントリ６０２、ネットワークまでの距離（ただし、主にホップ数（中間ルータの数）や、遅延時間、通信料金、信頼性などにより算出される距離であり、物理的な距離を意味しない。）が登録されるエントリ６０３、そのネットワークグループに属するクライアント１０３からのアクセス回数を登録するエントリ６０４及びそのネットワークグループに属するクライアント１０３から最初にアクセスがあった時刻を記録するエントリ６０５を有する。また、本テーブル１２２には、ファイル毎にこれらの情報が登録される。
【００４１】
ここで、本発明の動作の概要を簡単に説明すると、ファイルサーバがアクセス統計テーブルの内容を確認し、移送対象となるファイルを探し出し、次に移送先となるファイルサーバを決定し、ファイルの格納位置情報を変更し、その後に、ファイルの実体を移行する。以下、動作の手順を追って説明する。
【００４２】
図４は、サーバ１０５が、アクセス統計テーブル１２２を更新する際の処理手順の例を示した図である。尚、本処理手順は、ファイルサーバ１０５が、クライアント１０３からのファイルアクセス要求を受信したときに実行される。
【００４３】
クライアント１０３からファイルアクセス要求を受信したサーバ１０５は（ステップ７０１）、まず、自身のメモリ１０１内のアクセス統計テーブル１２２に、アクセス要求を受けたファイルのエントリが既に存在するかどうかを調べる（ステップ７０２）。
【００４４】
アクセス統計テーブル１２２にアクセス要求を受けたファイルのエントリが存在しなければ、サーバ１０５は、アクセス統計テーブル１２２に新たにエントリを作成し、エントリ６０１に、アクセス要求を受けたファイルのパス名を登録する（ステップ７０３）。
【００４５】
アクセス統計テーブル１２２にアクセス要求を受けたファイルのエントリが既に存在する場合、サーバ１０５は、存在するファイルに対応するエントリ６０２に登録されたネットワークマスクに対応するネットワーク１０１が、ファイルアクセスを要求したクライアント１０３が属するネットワークグループのネットワーク１０１と一致するか検査する。具体的には、アクセス要求パケットに含まれる宛先（サーバ）エントリに登録されたアドレスの上位２４Ｂｉｔ（ただし、２４は、マスクビット長の例。）とエントリ６０２に登録されたネットワークマスクの値とを比較する（ステップ７０４）。
【００４６】
アクセス要求元であるクライアント１０３が属するネットワークグループに対応するネットワーク１０１と登録されたネットワークマスクに対応するネットワーク１０１とが異なる場合及びステップ７０３にて新たにファイルのエントリを作成した場合、サーバ１０５は、アクセス要求の対象となるファイルに対応するエントリ６０２に、クライアント１０３が属するネットワークグループのネットワークマスクを登録する。また、サーバ１０５は、アクセス要求の対象となるファイルに対応するエントリ６０３に、クライアント１０３が属するネットワークグループとサーバ１０５が属するネットワークグループとの間の距離（ここではクライアント１０３が属するネットワークグループとサーバ１０５が属するネットワークグループとの間に存在する、ネットワークを仲介する中間ルータ数）を登録する。尚、インターネットの場合、各装置間の距離（ホップ数）はＩＣＭＰパケット等を用いて算出することができる。
【００４７】
さらに、サーバ１０５は、アクセス対象のファイルに対応するエントリ６０４に値「１」を設定し、エントリ６０５に、現在時刻（ここでは、テーブルに値を設定するときの時刻）を設定する（７０５）。
【００４８】
ステップ７０４でアクセス要求元のクライアント１０３が属するネットワークグループがアクセス統計テーブル１２２に登録されたネットワークグループと同一であると判断した場合、サーバ１０５は、アクセス要求のあったファイルに対応するエントリ６０４に登録された値を１増分（インクリメント）する（ステップ７０６）。ステップ７０５又はステップ７０６の処理を実行したサーバ１０５は、アクセス統計テーブルの更新処理を終了する。
【００４９】
現在時刻が「２００２／９／１ １０：００：００」から０．３００秒後の場合、図３で例示したアクセス統計テーブル１２２の１行目は、ファイルサーバ１０５のファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に対して、ＬＡＮ１（１００．０．０．０／２４）のネットワークグループに属するクライアント１０３（サーバ１０５との間の距離は５）から、０．３００秒間（「現在時刻−アクセス開始時刻」にて算出）に連続して１２０回のアクセスが発生したことを示している。
【００５０】
ここで、仮にクライアント１０３Ｃがファイルサーバ１０５Ｃのファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に対してｒｅａｄ要求を発行すると、クライアント１０３Ｃの属するネットワークグループ（ここではＬＡＮ２）は、その前に登録されていたネットワークグループ（ここでは、ＬＡＮ１）とは異なるので、図３の第一行目の内容は、図４で示した処理により、”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”， ”２００．０．０．０／２４”， ”１”， ”１”， ”現在時刻”と書き換えられる。
【００５１】
各ファイルサーバ１０５は、一定時間毎にアクセス統計テーブル１２２の内容を検査し、ファイルサーバ１０５が管理するファイルに対して、特定のネットワークグループに属する任意のクライアント１０３からのアクセス（以下「ネットワークグループからのアクセス」と称する）が集中（詳細は後述）しているかどうかを確認する。もしそのようなファイルが見つかったときは、ファイルサーバ１０５は、そのファイルを移送すべきファイルの候補として選定する。
【００５２】
図５は、サーバ１０５がアクセス統計テーブル１２２の内容を確認して移送すべきファイルの候補を選択するまでの処理手順の例を示すフローチャートである。本処理は、ファイルサーバ１０５が、ファイルシステムプログラム１２０を実行することによって一定時間毎に実行される。
【００５３】
ファイルシステムプログラム１２０を実行するファイルサーバ１０５Ｃは（ステップ８０１）、アクセス統計テーブル１２２の内容を確認し、予め定められた条件を満たすファイルが存在するかどうかを確認する。尚、本実施形態では、移送候補となるファイルとして、クライアント１０３が属するネットワークグループとファイルサーバ１０５が属するネットワークグループとの間の距離が２以上、あるネットワークグループからのアクセス回数が１０回以上、かつ、アクセス開始時刻から現在時刻まで１時間以上経過している（その間、他のネットワークグループからのアクセスはない）ファイルが検出されるよう、条件が設定される（ステップ８０２）。（ただしこれらの閾値はファイルシステムプログラムにあらかじめ設定するほか、ユーザにより再設定する。）
条件を満たすファイルがある場合、サーバ１０５Ｃは、そのファイルを移送候補として選択する。例えば、現在時刻が仮に２００２／９／２ １１：００：０５（２００２年９月２日 １１時００分０５秒）ならば、図３のアクセス統計テーブル１２２の例では、ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が条件に適合している。このため、ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が移送候補として選定される（ステップ８０３）。
【００５４】
移送候補となるファイルを選定したら、ファイルサーバ１０５Ｃは、次に、選定されたファイルを集中的にアクセスしているネットワークグループに属するファイルサーバ１０５へ、選定されたファイルを移送しようと試みる。上記の例では、ファイルサーバ１０５Ｃは、選定されたファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”を、アクセスを行っているネットワークグループ（ここではＬＡＮ１）に属するファイルサーバ１０５Ａまたは１０５ＢをＬＡＮ１から検索する。具体的には、ファイルサーバ１０５Ｃは、移送先検索パケットをＬＡＮ１に接続されている機器に対してブロードキャストする。ここで、ブロードキャストとは、指定したネットワークに属する不特定の機器（ノード）を受信先としたパケットの送信を指す（ステップ８０４）。
【００５５】
図６は、移送先検索パケットの例を示す図である。移送先検索パケットは、移送元となるファイルサーバ１０５Ｃ（以下「移送元ファイルサーバ」）が、ファイルを特定のネットワークグループのいずれかのファイルサーバ１０５Ａまたは１０５Ｂへ移送することが可能かどうか判断するために発行する。すなわち、移送先となるファイルサーバ１０５Ａまたは１０５Ｂ（以下「移動先ファイルサーバ」）を検索するために発行される。
【００５６】
移送先検索パケットの「宛先ネットワーク」は移送先検索パケットのブロードキャスト先ネットワークマスクを格納する。「送り元サーバ」は本パケットの発行元ノードのＩＰアドレスを格納する。「移送ＩＤ」は一連の移送手続きを他の移送手続きと区別するために移送元ファイルサーバが付ける識別番号である。「移送元サーバ」は移送元サーバのＩＰアドレスである。
【００５７】
移送先検索パケットは、要求容量フィールドを有する。同フィールドには、移送元ファイルサーバが移送するファイル（以下「移送ファイル」）を格納するために、移送先ファイルサーバ１０５Ａまたは１０５Ｂに確保すべき記憶容量が設定される。具体的には、移送ファイルのサイズ（もしくはファイルサイズが拡大することを見越してそれ以上の値）が設定される。
【００５８】
移送先検索パケットを受け取ったＬＡＮ１のネットワークグループに属するファイルサーバ１０５Ａと１０５Ｂは、指定された移送ファイルを受け入れることができるかどうかを判定し、その結果を移送元ファイルサーバに送信する。
【００５９】
図７は、移送先検索パケットを受信したサーバ１０５Ａと１０５Ｂが実行する移送受け入れ判定処理のフローチャートを示す図である。本処理は、ファイルサーバ１０５Ａと１０５Ｂがファイルシステムプログラム１２０を実行することによって行われる。
【００６０】
移送先検索パケットを受け取ったファイルサーバ１０５Ａと１０５Ｂは、移送許可パケットを作成する。図８は、移送許可パケットの具体例を示す図である。ファイルサーバ１０５Ａと１０５Ｂは、移送許可パケットの管理者フィールドに、サーバを管理する管理者の管理者ＩＤ（本例では”ｆｏｏ”）を設定する。さらに、なりすましを防止し、管理者が本物であることを示すために、ファイルサーバ１０５は、暗号化された管理者署名（本例では”ｏｅｋｄｉｇｋｅ”）を管理者署名フィールドに設定する（ステップ１００２）。
【００６１】
次に、ファイルサーバ１０５Ａと１０５Ｂは、移送ファイルを受け入れることが可能かどうかを判定するために、自らが有するディスク装置１１９の空き容量を検査する。ファイルサーバ１０５Ａと１０５Ｂは、ディスク装置１１９に移送先検索パケットで指定された要求容量以上の空き容量が存在する場合は、移送ファイルを受け入れることができると判断する。ディスク装置１１９に移送先検索パケットで指定された要求容量以上の空き容量が存在しない場合は、ファイルサーバ１０５Ａ，１０５Ｂは、移送ファイルを受け入れることができないと判断する（ステップ１００３）。
【００６２】
移送ファイルを受け入れることができる場合、ファイルサーバ１０５Ａ，１０５Ｂは、作成した移送許可パケットの応答フィールドに受け入れ許可を示す数値、ここでは１を設定する。また、ファイルサーバ１０５Ａ，１０５Ｂは、移送許可パケットの許可容量フィールドに、ディスク装置１１９の記憶容量の空き容量を示す値をセットする。さらに、ファイルサーバ１０５Ａ，１０５Ｂは、移送ファイルを受け入れるためのディレクトリ（本例では、ディレクトリ”／２００．０．０．１０１／”）をディスク装置１１９に作成し、移送許可パケットの移送先パス名フィールドに作成したディレクトリのパス名を示す情報をセットする（ステップ１００４）。
【００６３】
移送ファイルを受け入れることができない場合、ファイルサーバ１０５Ａ、１０５Ｂは、作成した移送許可パケットの応答フィールドに、転送受け入れの不可を示す値、ここでは０を設定する（ステップ１００５）。
【００６４】
本実施形態では、移送先ファイルサーバの候補であるＬＡＮ１のネットワークグループに属するファイルサーバ１０５Ａ及び１０５Ｂが、それぞれ図８Ａ、Ｂに示した移送許可パケットを移送元ファイルサーバ１０５Ｃへ返送したとする。
【００６５】
ファイルサーバ１０５Ａ及び１０５Ｂから移送許可パケットを受信したファイルサーバ１０５Ｃは、受信した移送許可パケットの内容を比較して、移送先ファイルサーバを決定する。
【００６６】
図９は、移送元となるファイルサーバ１０５、ここではファイルサーバ１０５Ｃが、移送先ファイルサーバの決定する際の処理手順を示すフローチャートである。本処理は、移送許可パケットを受信したときに、ファイルサーバ１０５Ｃがファイルシステムプログラム１２０を実行することによって実行される。
【００６７】
まず、ある移送許可パケットを受信したファイルサーバ１０５Ｃは、他の移送許可パケットの到着を一定時間待つ（ステップ１３０２）。もし、移送先検索パケットをブロードキャストした後、一つも移送許可パケットを受信しない場合、ファイルサーバ１０５Ｃは受け入れ先無しとみなして何もしない。また、一定時間経過後に到着した移送許可パケットは無視される。その後、ファイルサーバ１０５Ｃは、その一定期間内に到着した移送許可パケットの中から、移送許可パケットの応答フィールドに移送許可を示す１が登録されている移送許可パケットを選択する（ステップ１３０３）。
【００６８】
その後、ファイルサーバ１０５Ｃは、選択された移送許可パケットの中から、その管理者ＩＤフィールドに登録された管理者ＩＤがファイルサーバ１０５Ｃの管理者と同一の管理者ＩＤであり、かつ管理者署名フィールドに登録されている暗号署名に基づいてその管理者ＩＤが本物であると認証できた移送許可パケットを選択する。尚、移送許可パケットを送信したファイルサーバ１０５Ａ、１０５Ｂの管理者が移送元ファイルサーバの管理者と同じでなければ、そのサーバ１０５は信頼できないとみなして移送先ファイルサーバとしなくても良い。ただし、管理者が異なる場合でも、あらかじめ許容される複数の管理者名が移送元ファイルサーバに登録され、移送許可パケットに登録された管理者がその複数の管理者に含まれる場合には、移送元ファイルサーバがファイルの移送を行う態様としても良い（ステップ１３０４、１３０５）。
【００６９】
その後、ファイルサーバ１０５Ｃは、選択された移送許可パケットの中から、確保容量フィールドに登録された記憶容量が最大のものを選択する（ステップ１３０６）。その結果、ファイルサーバ１０５Ｃは、選択された移送許可パケットを発行したファイルサーバ１０５Ａを移送先ファイルサーバとして選択する（本例では、ファイルサーバＡを選択したとする）。尚、ステップ１３０６で条件に合致する移送許可パケットとして複数の移送許可パケットが残った場合には、ファイルサーバ１０５Ｃは、そのうちのひとつをランダムに選択する。本実施形態では、図８Ａ、Ｂの移送許可パケットを受け取ったファイルサーバ１０５Ｃは、空き容量が最大のファイルサーバ１０５Ａを移送先ファイルサーバとして選択する（ステップ１３０７）。
【００７０】
上述した各ステップにおいて、条件に一致する移送許可パケットが見つからなかった場合は、ファイルサーバ１０５Ｃは、移送先ファイルサーバ無しとして、以下に述べる移送先ファイルサーバの指名処理は行わない。すなわち、ファイルサーバ１０５Ｃは、ファイルの移送をおこなわない（ステップ１３０８）。
【００７１】
移送先ファイルサーバを決定した、移送元ファイルサーバ１０５Ｃは、ファイルシステムプログラム１２０を実行して、ノード・パス名変換テーブル１２１を更新する。この更新により、移送ファイルを管理するファイルサーバ１０５が、移送元ファイルサーバ１０５Ｃから移送先ファイルサーバ１０５Ａへと変更される。
【００７２】
図１０は、ノード・パス名変換テーブル１２１の例を示す図である。ノード・パス名変換テーブル１２１には、移送ファイルの移送元と移送先ファイルサーバに関する情報が関連付けて登録される。ファイルサーバ１０５は、このテーブルを検索して、ファイルが移送されているかどうか及び移送されている場合にはその移送先についての情報を取得することが出来る。
【００７３】
移送先ファイルサーバを決定した移送元ファイルサーバ１０５Ｃは、ノード・パス名変換テーブル１２１に、決定された移送先ファイルサーバに対応する新たなエントリ（行）を追加し、移送元のノード及びパス名フィールド、移動先のノード及びパス名フィールドに値をセットする。尚、「移送ＩＤ」は一連の移送手続きを他の移送手続きと区別するために移送元ファイルサーバが付ける識別番号である。移送元ファイルサーバが移送先検索パケット内に設定する。
【００７４】
移送元のノードフィールドには、自ファイルサーバ１０５（この場合１０５Ｃ）のＩＰアドレス（本例では２００．０．０．１０１）がセットされる。移送元のパス名フィールドには、移送ファイルのパス（本例では”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）がセットされる。
【００７５】
移送先のノードフィールドには、選択された移送許可パケットの移送先サーバフィールドに登録された値（本例では１００．０．０．１０１）がセットされる。移送先のパス名フィールドには、選択された移送許可パケットの移送先パス名フィールドに登録された値（本例では”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）がセットされる。
【００７６】
その結果、ノード・パス名変換テーブル１２１の新たなエントリには、”２００．０．０．１０１”の”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”としてファイルサーバ１０５Ａに管理されていたファイルが、”１００．０．０．１０１”の”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に移送されたことを示す情報が登録されることになる。
【００７７】
ノード・パス名変換テーブル１２１を更新したファイルサーバ１０５Ｃは、ファイルサーバ１０５Ａが移送先ファイルサーバとして選択され、ファイルがファイルサーバ１０５Ａへ移送されたことをクライアント１０３及びファイルサーバ１０５へ通知するために、移送先ファイルサーバが属するネットワークグループのネットワークであるＬＡＮ１へ移送通知パケットをブロードキャストする（ステップ１３０９）。
【００７８】
尚、移送通知パケットがブロードキャストされる時点で、実際にファイルが移送されていても、移送されていなくても良い。ファイルが移送されていない場合、そのファイルの移送は、クライアント１０３から移送ファイルに対するアクセス要求があったタイミングで、移送先ファイルサーバの要求に基づいて行われても良い。このようにすることによって、移送が必要なファイル（移送ファイルとして決定されても、実際にその後アクセス要求がなければ、移送する必要はない）のみ移送することができ、移送ファイルの移送によるネットワーク１０１の負荷の増加を最小限に抑えることができる。
【００７９】
また、実際のファイルの移送を、移送通知パケットのブロードキャスト後で、アクセス要求とは無関係な任意の時点にすることもできる。例えば、ネットワーク１０１のトラフィックが少ない時を見計らってファイルの移送が行われても良い。一方、移送通知パケットをブロードキャストする前に、移送ファイルが実際に移送されても良い。この場合、アクセス要求があった際に行われる移送元ファイルサーバでの処理量が少なくなるというメリットがある。
【００８０】
図１１は、移送通知パケットの例を示す図である。同図の移送通知パケットには、移送元ファイルサーバに関する情報と移送先ファイルサーバに関する情報が含まれる。本図の移送通知パケットは、”２００．０．０．１０１”の”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”としてファイルサーバ１０５Ａが管理していたファイルが、ファイルサーバ１０５Ｃ（”１００．０．０．１０１”）の”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に移送されたことを示している。
【００８１】
移送通知パケットを受信したファイルサーバ１０５Ａおよびクライアント１０３Ａは、移送元ファイルサーバ（ここではファイルサーバ１０５Ｃ）が行ったのと同様に、ノード・パス名変換テーブル１１５、１２１に新たなエントリ（行）を追加し、移送元のノード及びパス名フィールド、移送先のノード及びパス名フィールドに値をセットする。
【００８２】
次に、移送ファイルをクライアント１０３Ａがアクセスする場合の動作について説明する。
【００８３】
図１２は、クライアント１０３におけるアクセス変換処理の手順を示すフローチャートである。本処理は、クライアント１０３がファイルシステムプログラム１１４を実行することで実行される。本実施形態では、クライアント１０３Ａが、ファイルサーバ１０５Ｃが管理するファイル（パス名”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）にアクセスする例を示す。ここで、クライアント１０３Ａのアプリケーションプログラム１１３は、ファイルの移送の有無について関知しないため、ファイルサーバ１０５Ｃが管理するファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”を、移送の有無を問わず、そのままアクセスしようとする。
【００８４】
アプリケーションプログラム１１３の実行によってアクセス要求パケットを作成したクライアント１０３Ａは、作成されたアクセス要求（ここではファイルサーバ１０５Ｃが管理するファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）に基づいてノード・パス名変換テーブル１１５を参照し、アクセスしようとするファイルが同テーブル１１５の移送元フィールドに存在するかどうかを確認する（ステップ１６０２）。
【００８５】
アクセス要求の対象となるファイルを有するファイルサーバ１０５Ｃがノード・パス名変換テーブル１１５の移送元フィールドに存在しなければ、クライアント１０３Ａは、そのままファイルサーバ１０５、ここではファイルサーバ１０５Ｃへアクセス要求パケットを発行する（ステップ１６０４）。
【００８６】
アクセス要求の対象となるファイルを有するファイルサーバ１０５Ｃがノード・パス名変換テーブル１１５の移送元フィールドに存在する場合、そのファイルは別のファイルサーバ１０５Ａへ移送されているので、クライアント１０３Ａは、アクセス要求パケットの送付先を移送先ファイルサーバへに変換してアクセス要求パケットを発行する。本実施形態では、アクセスしようとするファイル（”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）がテーブル１１５の移送元フィールドに存在するため、クライアント１０３Ａは、ファイルへのアクセス要求の発行先を、テーブル１１５の移送先フィールドに記述されたファイルサーバ（ＩＰアドレス：１００．０．０．１０１）１０５Ａの「２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ」に変換してアクセス要求パケットを発行する。
【００８７】
図１３は、変換前と変換後のアクセス要求パケットの例を示す図である。クライアント１０３Ａにおける変換により、宛先（サーバ）フィールドがノード・パス名変換テーブル１１５の移送先ノードフィールドに登録された値（１００．０．０．１０１）に変換され、要求パス名フィールドがテーブル１１５の移送先パス名フィールドに登録された値（／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ）に変換される（ステップ１６０３、１６０４）。
【００８８】
次に、移送ファイルに対するアクセス要求を受けた移送先ファイルサーバ１０５Ａの動作を説明する。
【００８９】
図１４は、アクセス要求を受け付けた移送先ファイルサーバ１０５Ａの処理手順を示すフローチャートである。
【００９０】
アクセス要求パケット（本例では、図１３の変換後のアクセス要求パケット）を受け付けた移送先ファイルサーバ１０５Ａは、アクセス要求パケットの要求パス名フィールドに記されたファイル（本例では、パス名が”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）が既に自分のディスク装置１１９に格納されているかどうかを検査する（ステップ１８０２）。
【００９１】
既にディスク装置１１９にファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が存在する場合、そのファイルは移送済みなので、ファイルサーバ１０５Ａは、そのままファイルにアクセスし、そのアクセス結果に基づいて返答パケットを生成し、クライアント１０３Ａへ応答パケットを送信し（ステップ１８０７）、手続きを完了する。
【００９２】
一方、ファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”がディスク装置１１９に格納されていない場合、ファイルサーバ１０５Ａは、そのファイルのパス名がノード・パス名変換テーブル１２１の移送先フィールドに存在するかどうかを確認する（ステップ１８０３）。
【００９３】
ノード・パス名変換テーブル１２１の移送先フィールドにファイルのパス名が存在しない場合、そのファイルはシステムのどのファイルサーバ１０５Ａ，１０５Ｂ，１０５Ｃにも存在しないので、ファイルサーバ１０５Ａは、クライアント１０３Ａにファイルが存在しないことを示すエラーを送信し（ステップ１８０４）、手続きを完了する。
【００９４】
ノード・パス名変換テーブル１２１の移送先フィールドにファイルのパス名が存在する場合、そのファイルはまだ移送元ファイルサーバ１０５Ｃから移送先ファイルサーバである本ファイルサーバ１０５Ａに移送されていないことになる。そこで、ファイルサーバ１０５Ａは、ノード・パス名変換テーブル１２１の移送元フィールドを参照し、ファイルのパス名に対応する移送元ファイルサーバＣ（２００．０．０．１０１）及びファイルのパス名（”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）を取得する。更に、ファイルサーバ１０５Ａは、取得した移送元ファイルサーバ１０５Ｃへファイルのｒｅａｄ要求パケットを発行する。さらに、ファイルサーバ１０５Ａは、移送元ファイルサーバ１０５Ｃに格納されている移送ファイルを削除する要求パケットも発行する。尚、ｒｅａｄ要求パケット及び移送ファイルの削除を要求する要求パケットを受信した移送元ファイルサーバ１０５Ｃは、ｒｅａｄ要求パケットで指定されるファイルを、ｒｅａｄ要求パケットを発行したファイルサーバ１０５Ａへ送信し、その送信したファイルをディスク装置１１９から削除する。尚、移送元ファイルサーバ１０５Ｃにｒｅａｄ要求パケットで指定されるファイルが存在しない場合、移送元ファイルサーバ１０５Ｃは、ｒｅａｄ要求パケットを発行したファイルサーバ１０５Ａにエラーを報告する（ステップ１８０５）。
【００９５】
移送元ファイルサーバからｒｅａｄ応答パケットが返信されると、ファイルサーバ１０５Ａは、受信したｒｅａｄ応答パケットに含まれるファイルのデータを、自ディスク装置１１９に格納する。このときのファイルのパス名は、ノード・パス名変換テーブル１２１の移送先のパス名フィールドに格納された値（”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）が用いられる（ステップ１８０６）。
【００９６】
最後に、ファイルサーバ１０５Ａは、ディスク装置１１９に格納したファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”へアクセスし、クライアント１０３Ａへ応答パケットを送信し（ステップ１８０７）、応答処理を完了する。
【００９７】
次に、移送先通知パケットを受信しなかったクライアント１０３（例としてクライアント１０３Ｃ）が、移送済みの移送ファイル（”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）にアクセスする動作について説明する。
【００９８】
移送通知パケットは、ある条件を満たしたアクセス要求元のクライアント１０３が属するネットワークグループのネットワーク１０１へブロードキャストされるため、その他のネットワークグループ（ここでは例としてＬＡＮ２）に属するクライアント１０３Ｃには、ファイル（例として、ファイルサーバ１０５Ｃの”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）が移送先ファイルサーバ（例としてファイルサーバ１０５Ａ）へ移送されたことが通知されない。また、本発明が適用されないクライアントがネットワーク１０１に多数属する環境でも、ファイルは全てのクライアントから正常にアクセスできなければならない。
【００９９】
図１５は、ファイルが移送されたことを知らないクライアント１０３Ｃがファイルサーバ１０５Ｃ（この場合、ファイルサーバ１０５Ｃは移送元ファイルサーバとなる）にアクセス要求パケットを発行した時の、ファイルサーバ１０５Ｃの応答処理の手順を示すフローチャートである。
【０１００】
アクセス要求パケット（本例では、図１６の変換前要求パケット）を受信したファイルサーバ１０５Ｃは、アクセス要求パケットの要求パス名フィールドに登録されたファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が自ディスク装置１１９に格納されているかどうかを検査する（ステップ１９０２）。
【０１０１】
ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が自ディスク装置１１９に格納されている場合、ファイルサーバ１０５Ｃは、そのファイルにアクセスし、その結果に基づいて返答パケットを生成し、クライアント１０３Ｃへ応答パケットを送信し（ステップ１９０３）、応答処理を完了する。
【０１０２】
ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が自ディスク装置１１９に格納されていない場合、ファイルサーバ１０５Ｃは、そのファイルのパス名がノード・パス名変換テーブル１２１（本例では、図１０のテーブル１２１をファイルサーバ１０５Ｃが有しているとする）の移送元フィールドに存在するかどうかを確認する（ステップ１９０４）。ノード・パス名変換テーブル１２１の移送元フィールドにそのファイルのパス名が存在しない場合、そのファイルはネットワークシステムのどこにも存在しないので、ファイルサーバ１０５Ｃは、クライアント１０３Ｃへファイルが存在しないことを示すエラーを送信し（ステップ１９０５）、応答処理を完了する。
【０１０３】
ノード・パス名変換テーブル１２１の移送元フィールドにファイルのパス名が存在する場合、そのファイルは既に移送先ファイルサーバへ移送されていることになる（図１０では、ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”の移送先ファイルサーバは、２００．０．０．１０１の”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ ”となる）。そこで、ファイルサーバ１０５Ｃは、ノード・パス名変換テーブル１２１において、検索されたファイルのパス名に対応する移送先フィールドを参照し、移送先ファイルサーバ（１００．０．０．１０１）及び移送先でのファイルのパス名（”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）の情報を取得する。
【０１０４】
次に、ファイルサーバ１０５Ｃは、クライアント１０３Ｃから受信したアクセス要求パケット（図１６の変換前要求パケット）の宛先フィールドと要求パス名フィールド（／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ）に登録された値を、上記処理で得た移送先ファイルサーバ（１００．０．０．１０１）とパス名（／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ）へ変更し、さらに、送元フィールドに自分のアドレス（２００．０．０．１０１）をセットする（図１６の変換後要求パケットを参照）。
【０１０５】
そして、ファイルサーバ１０５Ｃは、作成した変換後要求パケットを、移送先ファイルサーバ（本例ではファイルサーバ１０５Ａ）へ送信する。変換後要求パケットを受信した移送先ファイルサーバは、その内容で指定されるファイルを読み出して応答パケット（本例では図１７の変換前応答パケット）を作成し、ファイルサーバ１０５Ｃへ返信する（ステップ１９０６）。
【０１０６】
移送先ファイルサーバより応答パケットを受信したファイルサーバ１０５Ｃは、その応答パケットの内容を次のように変換する。応答パケットの宛先フィールドの値（２００．０．０．１０１）を、ｒｅａｄ要求パケットを発行したクライアント１０３Ｃのアドレス（２００．０．０．１）に、送元フィールドの値をファイルサーバ１０５Ｃのアドレス（２００．０．０．１０１）に、応答パス名フィールドの値をクライアント１０３Ｃから受信した変換前要求パケットの要求パス名フィールドに登録された値に変換する（図１７の変換後応答パケットを参照）。
【０１０７】
変換終了後、ファイルサーバ１０５Ｃは、変換して作成した応答パケットを、クライアント１０３Ｃへ送信する（ステップ１９０７）。
【０１０８】
最後に、ファイルサーバ１０５Ｃは、クライアント１０３Ｃに対して、次回以降の同ファイルへのアクセスはファイルサーバ１０５Ａに対して行うように指示するため、移送通知パケットをクライアント１０３Ｃに送信し（ステップ１９０８）、応答処理を完了する。
【０１０９】
移送通知パケットを受信したクライアント１０３Ｃでは、以下の二つの処理のうち、いずれか一つが行われる。クライアント１０３Ｃが移送通知パケットを認識できる場合、クライアント１０３Ｃは、ファイルサーバ１０５Ｃから送信された移送通知パケットを受信し、その内容に従ってノード・パス名変換テーブル１１５を更新する。この処理の結果、移送ファイルへのアクセスは、クライアント１０３内で移送先ファイルへのアクセスに変換されるようになるため、以後のクライアント１０３の移送ファイルへのアクセス要求の発行は移送先ファイルサーバに対して直接行なわれる。
【０１１０】
一方、クライアント１０３が移送通知パケットを認識することが出来ない場合、クライアント１０３において移送通知パケットは無視される。したがって、クライアント１０３からの移送ファイルへのアクセス要求は、引き続き移送元であるファイルサーバ１０５Ｃに対して発行される。しかし、ファイルサーバ１０５Ｃは、クライアント１０３からの要求を上記と同様の方法で変換し、移送先ファイルサーバへ代理アクセスを実施するため、クライアント１０３は従来通りの方法によるファイルアクセスの実行が可能である。
【０１１１】
次に、移送ファイルを移送元ファイルサーバへ返還する方法について説明する。ファイルアクセス要求元となるクライアント１０３は、時間の経過と共に変化する可能性がある。このため、一旦他のファイルサーバ１０５へ移送したファイルも、移送元ファイルサーバへ返還した方がアクセス性能が向上する場合がある。
【０１１２】
ファイル移送後も、ファイルサーバ１０５、特に移送先ファイルサーバはアクセス統計テーブル１２２にファイルアクセスに関する統計情報を引き続き収集し続ける。
【０１１３】
移送先ファイルサーバは、一定時間毎にアクセス統計テーブル１２２（本例では図１８）を検査し、移送ファイルを返還べきかどうかを以下の方法により検査する。具体的には、移送ファイルが移送元ファイルサーバが属するネットワークグループから集中してアクセスされているかどうかを検査する。
【０１１４】
図１９は、移送ファイルの返還処理のうち、返還対象となる移送ファイル（以下、「返還対象ファイル」）を決定する処理手順を示すフローチャートである。本処理は移送先ファイルサーバが、ファイルシステムプログラム１２０を実行することで、一定時間間隔毎に実施される。
【０１１５】
本処理の実行を開始した移送先ファイルサーバは、特定の条件に合致するファイルをアクセス統計テーブル１２２から検索する。本例においては、移送先ファイルサーバは、所定の時間、例えば、本処理の開始から１時間前の間に特定のネットワークグループのみから閾値以上の頻度（本例では１０回以上）でアクセスが行われたファイルをアクセス統計テーブル１２２から抽出する。尚、これらの閾値はファイルシステムプログラムにあらかじめ設定するほか、ユーザにより再設定する。本例においては、本処理を開始した時刻が２００２／１０／１ ９：００：００以降ならば、図１８のアクセス統計テーブル１２２に登録されているファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が上述した条件に適合する（ステップ２３０２）。
【０１１６】
次に、移送先ファイルサーバは、抽出されたファイルがノード・パス名変換テーブル１２１（本例では図１０に示す内容が登録されているとする）の移送先のパス名フィールドに登録されているかどうかを検査する（ステップ２３０３）。
【０１１７】
抽出されたファイルがノード・パス名変換テーブル１２１に登録されていれば、そのファイルは移送ファイルであることがわかる。この場合、移送先ファイルサーバは、抽出されたファイルに対応する距離フィールドに登録された値（＝５）と、そのファイルの移送元ファイルサーバと要求元ネットワークフィールドに登録されたネットワーク（ここではＬＡＮ２）との間の距離（＝同一ネットワーク内なので０）を比較する。本処理により、ファイルに集中的にアクセスするネットワークグループと移送先ファイルサーバが属するネットワークグループとの距離が、ファイルに集中的にアクセスするネットワークグループと移送元ファイルサーバが属するネットワークグループとの間の距離よりも大きいかどうかを判定することができる（ステップ２３０４）。
【０１１８】
距離フィールドに登録された値の方が大きい場合、すなわち、移送ファイルに集中的にアクセスするネットワークグループと移送先ファイルサーバが属するネットワークグループとの間の距離が、移送ファイルに集中的にアクセスするネットワークグループと移送元ファイルサーバが属するネットワークグループとの間の距離より大きい場合、移送先ファイルサーバは、検索された移送ファイルを返還対象ファイルとして選定する。これは、移送元ファイルサーバへ移送ファイルを返還した方が、ネットワーク間の距離が小さくなり、システムのアクセス性能が向上するからである。
【０１１９】
返還対象ファイルを選定すると、移送先ファイルサーバは、続いて、返還要請パケット（図２０に返還要請パケットの例を示す）を作成する。移送先ファイルサーバは、返還要請パケット作成の際、ノード・パス名変換テーブル１２１の各エントリに登録されている値を参照して返還要請パケットの各フィールドに値を登録する。その後、移送先ファイルサーバは、移送元ファイルサーバへ返還要請パケットを送信する（ステップ２３０５）。
【０１２０】
尚、上述した処理においてファイルが条件を満たさない場合、移送先ファイルサーバは、返還処理を行わずに処理を終了する。
【０１２１】
図２１は、先に決定された返還対象ファイルの返還処理の手順を示すフローチャートである。
【０１２２】
返還要請パケットを受信した移送元ファイルサーバは、返還要請パケットを送信した移送先ファイルサーバ（以下「返還元サーバ」）に対して、返還要請パケットの返還元パス名フィールドに登録されたファイルのｒｅａｄ要求を発行する（ステップ２５０２）。返還元サーバよりファイルを受信した移送元ファイルサーバは、取得したファイルを、返還要請パケットの返還先パス名で指定されたファイル名で自ディスク装置１１９に格納する（ステップ２５０３）。さらに、移送元ファイルサーバは、返還元サーバに対して、返還元パス名フィールドで指定されるファイルの削除要求を発行する（ステップ２５０４）。その後、移送元ファイルサーバは、該サーバが有するノード・パス名変換テーブル１２１から、返還を受けたファイルのエントリを削除し（ステップ２５０５）、ファイルの返還処理を完了する。
【０１２３】
尚、返還処理の完了以後に、クライアント１０３が移送先ファイルサーバに対してアクセス要求を発行した場合、クライアント１０３は移送先ファイルサーバよりファイルが存在しない旨のエラー応答を受信する。この場合、クライアント１０３は、該クライアント１０３のノード・パス名変換テーブル１１５からエラー応答を受信したファイルのエントリを削除し、移送元ファイルサーバへ再度アクセス要求パケットを発行する。
【０１２４】
第一の実施形態では、「ファイル」を移送の単位として扱った。次に、第一の実施形態の応用として、複数のファイルを下層に含む「ディレクトリ」を移送の単位として扱う第二の実施形態について説明する。
【０１２５】
ファイルシステムにおいては、ディレクトリの配下には、複数のファイルが配されている。第二の実施形態においては、移送したいディレクトリを移送ディレクトリとして指定することにより、同ディレクトリに含まれる全てのファイルの移送を行うことが出来る。
【０１２６】
尚、以下に説明するアクセス統計テーブル１２２の検査手順以外の処理手順は、第一の実施形態と同じ手順であるので、説明を省略する。以下、第二の実施形態におけるアクセス統計テーブル１２２の検査手順を説明する。
【０１２７】
図２２は、第二の実施形態において、ファイルサーバ１０５がアクセス統計テーブル１２２の内容を検査する手順を示すフローチャートである。本処理は、ファイルサーバ１０５がファイルシステムプログラム１２０を実行することで、一定時間毎に実行される。
【０１２８】
ファイルサーバ１０５は、一定時間毎にアクセス統計テーブル１２２を検査し、ディレクトリ下のファイルへのアクセスが特定のネットワークグループから集中しておこなわれているかどうかを検査する。もしそのようなディレクトリが見つかったときは、そのディレクトリを移送ディレクトリの候補として選定する。
【０１２９】
ファイルサーバ１０５は、まず、アクセス統計テーブル１２２（図２３に示したテーブルであるとする）の中から、ファイルサーバ１０５が属するネットワークグループとアクセスするネットワークグループとの間の距離が２以上、アクセス回数が１０回以上、かつアクセス開始時刻から現在時刻まで一定時間（例として１時間）以上経過している（その間、他のネットワークグループからのアクセスはない）ファイルを検索する。本ステップにより発見されるファイルを（ｄ）とする。本例では、”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が該当する（ステップ２６０２）。尚、検索の条件は本例に限られない。ただしこれらの閾値はファイルシステムプログラムにあらかじめ設定するほか、ユーザにより再設定する。
【０１３０】
アクセス統計テーブル１２２に（ｄ）が存在した場合、ファイルサーバ１０５は、当該ファイルを含むディレクトリ（図２３の例では”／ｄｏｃ／ｍｉｓｃ／”）を認識し（ｄ１）とする。また、当該ファイルに対応する要求元ネットワークフィールドに登録されたネットワークを認識し（Ｎ）（図２３の例では、”１００．０．０．０／２４”）とする（ステップ２６０３）。
【０１３１】
次に、ファイルサーバ１０５は、アクセス統計テーブル１２２の全エントリの中から、ファイルが（ｄ１）の配下でかつ要求元ネットワークフィールドに登録されているネットワークが（Ｎ）以外のエントリを検索する。これを（ｅ）とする（図２３では該当するファイルはない）（ステップ２６０５）。
【０１３２】
（ｅ）が存在する場合、（ｄ１）には異なるネットワークグループからアクセスされるファイルが混在していることになる。このため、（ｄ１）配下のファイルを全て移送することはシステムの性能低下を招く。したがって、ファイルサーバ１０５はディレクトリである（ｄ１）の移送をあきらめ、（ｄ）を移送ファイルの候補として選択する（ステップ２６０８）。
【０１３３】
（ｅ）が存在しない場合、（ｄ１）配下のファイルはネットワーク（Ｎ）以外のネットワークグループからアクセスを受けていないため、ファイルサーバ１０５は、（ｄ１）を移送ディレクトリの候補として選択することができる。
【０１３４】
しかし、（ｄ１）よりも１階層上位のディレクトリ（図２３の例では”／ｄｏｃ／”）を移送ディレクトリの候補として選択できる可能性もある。このため、ファイルサーバ１０５は、次に、（ｄ１）を新たな（ｄ）、（ｄ１）の上位階層のディレクトリを新たな（ｄ１）として（ステップ２６０７）、ステップ２６０４以降の処理を再度実施する。すなわち、アクセス統計テーブル１２２の全エントリの中から、新たな（ｄ１）配下のファイルで、要求元ネットワークフィールドに登録されているネットワークが（Ｎ）以外のエントリを検索する。検索の結果得られるファイルのエントリを（ｅ）とする（図２３では”ｄｏｃ／ｍｅｍｏ．ｔｘｔ”が該当する）。
【０１３５】
ファイルサーバ１０５は、上記処理を繰り返し、エントリ（ｅ）が見つかった時点で処理の繰り返しを中止する。そして、中止時までに選択された移送ディレクトリの候補（またはファイル）（ｄ）を移送ディレクトリの候補とし（ステップ２６０８）、処理を終了する。
【０１３６】
尚、ディレクトリ単位で移送する第二の実施形態においても、第一の実施形態の図１４に示すように、移送先ファイルサーバがクライアント１０３からのアクセス要求を受けてからファイルの実体を移送するため、必要なデータのみがその都度ネットワーク１０１上で転送される。つまり、移送ディレクトリに含まれる移送ファイル全てを同時に移送しない。このため、ネットワーク１０１のトラフィックを分散させ、また、ファイルサーバ１０５の負荷を分散させる効果がある。
【０１３７】
次の第三の実施形態について説明する。第一の実施形態では、移送元ファイルサーバは、ファイルに集中的にアクセスするネットワークグループに含まれるファイルサーバ１０５の中から、移送先サーバを選択した。このため、ファイルに集中的にアクセスするネットワークグループに含まれるファイルサーバ１０５の中に条件（空き容量が指定量以上かつ、管理者が移送元サーバと同一、など）が適合するファイルサーバ１０５が存在しない場合、第一の実施形態においては、移送元ファイルサーバは移送を行わないこととした。
【０１３８】
しかし、以下に示す第三の実施形態では、ファイルに集中的にアクセスするネットワークグループに含まれるファイルサーバ１０５に、条件に適合するファイルサーバ１０５が見つからなかった場合に、他のネットワークグループに条件に適合するファイルサーバ１０５が存在すれば、移送元ファイルサーバは、次善の策としてそのファイルサーバ１０５へファイルの移送をおこなう。
【０１３９】
図２３は、第三の実施形態のシステム構成を示す図である。本実施形態のシステムは、２つのネットワークＬＡＮ１、ＬＡＮ３がインターネットやＷＡＮを介して接続され、ＬＡＮ２はインターネット１０４を介してＬＡＮ３と接続されている。ＬＡＮ２とＬＡＮ１とはＬＡＮ３を経由してのみ接続されている。
【０１４０】
第三の実施形態での処理は、以下に説明する移送先ファイルサーバの選択手順を除き、第一の実施形態での処理手続きと同じであるので、それらの処理については説明を省略する。以下に、第三の実施形態の移送先ファイルサーバの選択方法を説明する。
【０１４１】
図２５は、第三の実施形態における、ファイルサーバ１０５における移送先ファイルサーバ選択処理の手順を示すフローチャートである。本処理は、移送元ファイルサーバが移送ファイルの候補を選定したときに実行される。以下、図２４において、移送元ファイルサーバがファイルサーバ１０５Ｃである場合で説明する。
【０１４２】
移送ファイルの候補を選定した移送元ファイルサーバは、アクセス統計テーブル１２２から、移送ファイルの候補へアクセスを行うネットワークグループに対応するネットワーク（１００．０．０．０／２４：ＬＡＮ１）へ移送先検索パケットをブロードキャストする（ステップ３００２）。
【０１４３】
移送元ファイルサーバは、返送された移送許可パケットの内容を確認し、予め指定された条件を満たすかどうか判定する。本例においては、ＬＡＮ１に接続されたファイルサーバ１０５Ａ及び１０５Ｂから移送許可パケットが返送され、移送元ファイルサーバは、これらの移送許可パケットが条件（空き容量が指定量以上かつ、管理者が移送元サーバと同一、など）に適合するかどうかを検査する（ステップ３００３）。
【０１４４】
いずれの移送許可パケットも条件に適合しない場合、移送元ファイルサーバは、移送先検索パケットをブロードキャストするネットワークの対象を拡大する。具体的には、移送元ファイルサーバは、先に移送先検索パケットをブロードキャストしたネットワーク（ＬＡＮ１）について、ネットワークマスクビットを短縮（例では、マスクビットを２４ｂｉｔ（２５５．２５５．２５５．０）から１６ｂｉｔ（２５５．２５５．０．０）に短縮）し、ＬＡＮ１と同じ上位１６ビットのアドレスを有するＬＡＮ３（１００．０．１．０／２４）に移送先検索パケットをブロードキャストする（ステップ３００４、３００５）。
【０１４５】
その結果、ネットワークＬＡＮ３に属するファイルサーバ１０５Ｄ（１００．０．１．１０２）から移送許可パケットが移送元ファイルサーバに返送される。その後、移送元ファイルサーバは、ファイルサーバ１０５Ｄからの移送許可パケットが条件に適合するかどうか検査する（ステップ３００６）。ファイルサーバ１０５Ｄからの移送許可パケットが条件と適合している場合、移送元ファイルサーバは、ファイルサーバ１０５Ｄを移送先ファイルサーバとして選択する（ステップ３００７）。条件に適合するファイルサーバ１０５が無ければ、移送元ファイルサーバは、移送先ファイルサーバ無し判断して、ファイルの移送は行わない（ステップ３００８）。
【０１４６】
第三の実施形態によれば、移送元ファイルサーバは、アクセスを集中して行うネットワークグループに移送先ファイルサーバが見つからない場合にも、次善の策として、アクセスを集中して行うネットワークグループとは別のネットワークグループに属するファイルサーバ１０５へファイルを移送することができる。
【０１４７】
【発明の効果】
本発明によれば、クライアントから遠隔地にあるファイルサーバが管理するファイルへのアクセス性能を向上させることができる。また、キャッシュ方式に比べ一貫性制御が不要なため、ネットワークに余分なトラフィックを発生させることも無い。
【図面の簡単な説明】
【図１】システムの概要を示す図。
【図２】アクセス要求パケットの例を示す図。
【図３】アクセス統計テーブルの例を示す図。
【図４】アクセス統計テーブルの更新処理の手順を示すフローチャート。
【図５】移送ファイルの候補を決定する処理手順の例を示すフローチャート。
【図６】移送先検索パケットの例を示す図。
【図７】移送受け入れ判定処理の手順の例を示すフローチャート。
【図８】移送許可パケットの例を示す図。
【図９】移送先ファイルサーバの選択手順の例を示すフローチャート。
【図１０】ノード・パス名変換テーブルの例を示す図。
【図１１】移送通知パケットの例を示す図。
【図１２】アクセス変換処理の手順を示すフローチャート。
【図１３】変換前／変換後のアクセス要求パケットの例を示す図。
【図１４】移送先ファイルサーバの処理手順の例を示すフローチャート。
【図１５】移送元ファイルサーバの処理手順の例を示すフローチャート。
【図１６】移送元ファイルサーバによる要求パケットの変換例を示す図。
【図１７】移送元ファイルサーバによる応答パケットの変換例を示す図。
【図１８】アクセス統計テーブルの例を示す図。
【図１９】返還するファイルを決定する処理手順を示すフローチャート。
【図２０】返還要請パケットの例を示す図。
【図２１】ファイルの返還処理の手順の例を示すフローチャート。
【図２２】移送対象の候補となるディレクトを決定する処理手順の例を示す図。
【図２３】アクセス統計テーブルの例を示す図。
【図２４】第三の実施形態のシステムの全体を示す図。
【図２５】移送先サーバの選択処理の手順を示すフローチャート。
【符号の説明】
１０１…ＬＡＮ、１０３…クライアント、１０５…ファイルサーバ、１０９…ＣＰＵ、１１０…ＲＯＭ装置、１１１…メモリ、１１２…ネットワークインターフェイス、１１９…ディスク装置。
【発明の属する技術分野】
本発明は、ネットワークを介して複数の計算機（コンピュータ）が接続されたシステム（以下「ネットワークシステム」）において、あるコンピュータがネットワークを介して他のコンピュータに接続された記憶装置内のデータにアクセスする技術に関する。
【０００２】
【従来の技術】
従来のネットワークシステムにおいて、他のコンピュータの記憶装置内のファイルに対してアクセス（読み出し（ｒｅａｄ）および書き込み（ｗｒｉｔｅ））を要求するコンピュータを、クライアントコンピュータ（以下、単にクライアント）と呼び、クライアントからの要求に応じて自ディスク装置内のファイルをアクセスし、その結果（ｒｅａｄデータや、正常にｗｒｉｔｅが行われたかどうかなど）を応答するコンピュータをファイルサーバコンピュータ（以下、単にファイルサーバもしくはサーバ）と呼ぶ。
【０００３】
クライアントがネットワークを介してファイルサーバが管理するファイルにアクセスする技術として、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）がある。以下、他のコンピュータが管理するファイルの読み出し又は書き込み（以下まとめて「アクセス」）を要求するコンピュータをクライアントと称する。また、クライアントからの要求に応じて、記憶装置に格納されたファイルをアクセスし、その結果（読み出したデータ、データの書き込みの完了報告等）をクライアントに応答するコンピュータをファイルサーバ又はサーバと称する。更に、ファイルとは、ユーザやコンピュータで実行されるアプリケーションプログラムが使用するデータの纏まりを指す。
【０００４】
ＮＦＳでは、クライアントはサーバに対してＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ：遠隔手続き呼び出し）要求メッセージパケットを送信してアクセスを要求する。一方、サーバは、ＲＰＣ応答メッセージパケットを返送してクライアントからの要求に応答する。
【０００５】
ＮＦＳのプロトコル設計は基本的にステートレス（サーバ・クライアント内に状態を保持しない）の方針に基づいているので、クライアントは、サーバから読み出したファイルをクライアントが有する記憶装置に一時的に保存（以下「キャッシュ」）しない。このため、クライアントが、サーバが管理するファイルをアクセスする場合には、かならずファイルサーバとの交信が発生する。
【０００６】
一方、ファイルサーバが管理するファイルをクライアント自身又はクライアント付近のサーバにキャッシュする技術として、分散ファイルシステム（ＤＦＳ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ）及びプロキシ（ｐｒｏｘｙ：代理）サーバがある。
【０００７】
ＤＦＳでは、クライアントが、サーバから読み出したファイルのデータを自身の記憶装置にキャッシュする。
【０００８】
また、プロキシサーバは、クライアントとサーバの間（多くはクライアントと同一のネットワーク上）に設置される。クライアントはサーバへファイルのアクセスを要求する際に、プロキシサーバへアクセス要求を送信する。プロキシサーバはクライアントに成り代わってサーバからファイルを読み出し、そのファイルをクライアントへ送信する。この際、プロキシサーバは取得したファイルをプロキシサーバ内にキャッシュする。
【０００９】
これ以降、クライアントから再び同一ファイルのアクセス要求がプロキシサーバへ送信された場合、プロキシサーバはサーバへアクセスすることなく、プロキシサーバ内にキャッシュされたファイルをクライアントに送信する。
【００１０】
更に、主となるファイルサーバと副となるファイルサーバを備え、主ファイルサーバの記憶容量が不足したとき、主ファイルサーバのファイルを副ファイルサーバへ移動し、移動されたファイルに対してクライアントからアクセス要求があった場合には、主ファイルサーバが副ファイルサーバからファイルを転送してもらうシステムが特許文献１に開示されている。
【００１１】
【特許文献１】
特開平６−２４３０７４号公報
【００１２】
【発明が解決しようとする課題】
ＮＦＳでは、クライアントがサーバのファイルをキャッシュしないため、クライアントが、サーバが管理するファイルへアクセスする時には、常にクライアント・サーバ間で要求パケットおよび応答パケットが往復する。このため、遠隔地にあるファイルサーバが管理するファイルをクライアントがアクセスする場合、サーバからのパケットがクライアントに到着するまでの遅延時間（レイテンシ）が増大し、クライアントのユーザに対するレスポンス性能が低下する。
【００１３】
一方、ＤＦＳ又はプロキシサーバのように、クライアント又はその近隣サーバにファイルをキャッシュすれば、パケット到着までのレイテンシの増加を抑えることができる。しかし、この「キャッシュ方式」には、以下の問題がある。
【００１４】
「キャッシュ方式」では、サーバ内にあるファイル（元ファイル）に加え、元ファイルの複製がクライアント等に複数個作成されるので、両者の同期を取る、即ち、データの内容を一致させる処理（「一貫性制御処理」）が必要となる。特に元ファイルと複製とが保存されているコンピュータとの間の距離が長いほど本処理の実行に時間がかかる。更に、ファイルが頻繁にクライアントによって更新される場合は、頻繁に本処理を行う必要があり、「キャッシュ方式」を導入したことによるレイテンシの増加抑制の効果が減少してしまう。
【００１５】
また、プロキシサーバでは、上述の一貫性制御は行われない。したがって、最新のファイルを得たい場合には、クライアントは、再度プロキシサーバにファイルのアクセス要求を指示しなければならず、レイテンシの増大は抑制できない。
【００１６】
一方、特許文献１に記載された「移送（ｍｉｇｒａｔｉｏｎ）方式」では、一貫性制御が不要である。しかし、ファイルの格納場所が移送前後で変化するので、移送されたファイルに対するクライアントのアクセス性能が移送元よりも移送先の方が悪ければ、ネットワークシステムの性能は低下してしまう。特に、特許文献１はファイルサーバの容量不足を解消することを目的としており、アクセス性能を向上させることは考慮されていない。したがって、特許文献１では、クライアントから主ファイルサーバまでの距離よりも副ファイルサーバまでの距離のほうが遠くなって、レイテンシが増大する可能性について考慮されていない。
【００１７】
特に、複数のクライアントから頻繁にアクセスされるファイルがどのファイルサーバに移送されるべきか否かは、そのファイルをアクセスする複数のクライアントがネットワークにどのように分布しているかの情報に基づいて行われることが重要であるが、従来技術では、この点について全く考慮されていない。
【００１８】
本発明の目的は、クライアントが遠隔地にあるファイルサーバが管理するファイルへアクセスする際に、ファイルの一貫性を保ちつつ一貫性制御のオーバヘッドをなくし、さらに、ネットワークのトラフィックを削減することである。
【００１９】
【課題を解決するための手段】
上記課題を解決するために、第一のサーバが、自ディスク装置内のファイルに対するアクセスを行うクライアントが属するネットワークの位置情報を検査し、ファイルの移送先となるサーバの候補を決定する。そして、アクセスを行うクライアントのネットワーク、もしくは、その周辺のネットワーク上の、不特定多数のサーバへ、ファイルを移送するサーバを調べるための移送先検索パケットを送信する。移送先検索パケットを受信した第二のサーバは、ファイルの移送の受け入れに関する移送許可パケットを第一のサーバに対して送信する。第一のサーバは、移送許可パケットの内容を検査し、第二のサーバがファイルを移送するのに適していることが分かれば、第二のサーバに対してファイルを移送する。
【００２０】
更に、第一のサーバは、ファイルを移送したことを示す移送通知パケットを、アクセスを行うクライアントのネットワーク、もしくは、その周辺のネットワークに送信するため、クライアントは、移送したファイルに対するアクセスを、第二のサーバに対して行う。
【００２１】
【発明の実施の形態】
図１は、本発明を適用したネットワークシステムの一実施形態を示す図である。本ネットワークシステムは、３台のファイルサーバ１０５、具体的には、ファイルサーバ１０５Ａ、１０５Ｂ及び１０５Ｃ、並びに３台のクライアント１０３、具体的には、クライアント１０３Ａ、１０３Ｂ及び１０３Ｃを有する。ファイルサーバ１０５Ａ、ファイルサーバ１０５Ｂ、クライアント１０３Ａ及びクライアント１０３Ｂは、通信線（ここではローカルエリアネットワーク。以下「ＬＡＮ」）１０１Ａ（以下「ＬＡＮ１」）を介して相互に接続されている。ファイルサーバ１０５Ｃ及びクライアント１０３Ｃは、ＬＡＮ１０１Ｂ（以下「ＬＡＮ２」）を介して相互に接続されている。
【００２２】
また、本例では、ＬＡＮ１及びＬＡＮ２は、インターネットやＷＡＮといった広域ネットワーク１０４により相互に接続されている。更に、ＬＡＮ１にはネットワークマスク１００．０．０．０／２４が、ＬＡＮ２には、ネットワークマスク２００．０．０．０／２４が与えられている。尚、本実施形態では通信線１０１としてＬＡＮを一例としてあげたが、他の通信線を用いても構わない。
【００２３】
また、本明細書では、インターネットプロトコルバージョン４（以下ＩＰｖ４）技術で用いられるアドレス表記をネットワークマスク等の表記に用いる。ここで、本実施形態のネットワークに接続されるコンピュータ等の機器には、それぞれ固有の３２ｂｉｔのＩＰアドレス（例えば”１００．０．０．１”）が割り振られる。また、ネットワークマスクの表記、例えばＬＡＮ１に割り振られたネットワークマスク”１００．０．０．０／２４”の表記は、ＬＡＮ１に接続されたコンピュータに、いずれも上位２４ｂｉｔ共通のＩＰアドレスが割り振られている、すなわち、ＬＡＮ１に接続されるコンピュータに、”１００．０．０．０”〜”１００．０．０．２５５”の範囲のＩＰアドレスが割り振られることを示している。したがって、ＬＡＮ１に接続される機器は、ＬＡＮ１に割り振られたネットワークマスクによって一つのグループ（以下「ネットワークグループ」）として識別されることになる。
【００２４】
各ファイルサーバ１０５は計算機であり、ＣＰＵ１１７、メモリ１０１、ネットワークインターフェイス１１７、ディスクＩＯインターフェイス１１８、及びディスク装置１１９を有する。ＣＰＵ１１７、メモリ１０１、ネットワークインターフェイス１１７及びディスクＩＯインターフェイス１１８は、接続線を介して相互に接続されている。また、ディスク装置１１９は、ディスクＩＯインターフェイス１１８を介してＣＰＵ１１７等と接続されている。更に、ファイルサーバ１０５は、ネットワークインターフェイス１１７を介してＬＡＮ１０１と接続される。
【００２５】
尚、ファイルサーバ１０５自身はディスク装置１１９を有さない構成としても良い。この場合、ファイルサーバ１０５はディスクＩＯインターフェース１１８の替わりにネットワークインターフェイスを有し、ファイルサーバ１０５は、このインターフェース及びネットワークを介して別筐体の記憶装置システムに接続されている構成とする。ここで使用されるインターフェース及びネットワークには、例えば、ファイバチャネルプロトコルが使用される。あるいは、ファイルサーバ１０５は、ファイルシステム機能に特化したネットワークアタッチドストレージ（ＮＡＳ）でも良い。
【００２６】
更に、ファイルサーバ１０５は、ディスク装置１１９を有し、かつ別筐体の記憶装置システムに接続するためのネットワークインターフェイスを有する構成としても良い。
【００２７】
ここで、記憶装置システムとは、記憶媒体及び制御部を有する記憶装置である。記憶媒体には、磁気ディスク又は光ディスク等が使用される。また、記憶装置システムには、冗長構成を有するディスクアレイも含まれる。尚、ファイルサーバ１０５が有するディスク装置１１９は、単体のハードディスクドライブでも、ディスクアレイ、ＤＶＤ等でも良い。
【００２８】
メモリ１０１には、ファイルシステムプログラム１２０、ノード・パス名変換テーブル１２１及びアクセス統計テーブル１２２が格納される。図では、テーブルの情報やプログラムは丸で囲んで示している。これらのプログラムやテーブルは、電源オフ時にはファイルサーバ１０５が有する不揮発性記憶媒体（ディスク装置１１９やＲＯＭなど）に格納されている。ファイルサーバ１０５は、これらのテーブルやプログラムを使用する際に、不揮発性記憶媒体からメモリ１０１にこれらのプログラム等を読み出す。ファイルシステムプログラム１２０等のプログラムは、フロッピー（登録商標）ディスクやＤＶＤの記憶媒体、ネットワーク等の通信回線あるいは無線通信等を介してファイルサーバ１０５のディスク装置１１９又はメモリ１０１にインストールされる。
【００２９】
ＣＰＵ１１６は、ファイルシステムプログラム１２０を実行し、ＬＡＮ１０１等に接続された他のファイルサーバ１０５等とのパケット通信、ディスク装置１１９へのアクセス、メモリ１０１内のデータの更新、等を行う。
【００３０】
また、各クライアント１０３もファイルサーバ同様に、ＣＰＵ１１６、メモリ１１１、ネットワークインターフェイス１１７を有する計算機である。尚、本実施形態では、クライアント１０３はディスク装置１１９の替わりにＲＯＭ装置１１０を有する。クライアント１０３をファイルサーバ１０５と同じ構成とすることもできる。クライアント１０３は、ネットワークインターフェイス１１６を介してＬＡＮ１０１と接続される。
【００３１】
クライアント１０３のメモリ１１１には、アプリケーションプログラム１１３、ファイルシステムプログラム１１４及びノード・パス名変換テーブル１１５が格納される。これらのプログラム等は、電源オフ時には、ＲＯＭ装置１１０に格納されている。
【００３２】
クライアント１０３のＣＰＵ１１６は、ファイルシステムプログラム１１４を実行し、ＬＡＮ１０１を介してファイルサーバ１０５のディスク装置１１９に格納されているファイルにアクセスする。また、クライアント１０３のＣＰＵ１１６は、アプリケーションプログラム１１３を実行して、クライアントを使用する人が所望するサービスを提供する。
【００３３】
本実施形態のファイルシステムプログラム１１４、１２０によって実現されるファイルシステムは、ＵＮＩＸ（登録商標）その他の一般的なＯＳに採用されているように、論理的な木構造の元にファイルを管理する階層型のファイルシステムである。具体的には、ルート・ディレクトリを根とし、ディレクトリの下にファイルもしくはディレクトリを配するデータ構造が用いられる。本実施形態では、ファイルシステムで管理されるファイルを、「／ｄｏｃ／ｍｉｓｃ／ｒｅａｄｍｅ．ｔｘｔ」のように、ディレクトリ名の連接とファイル名を区切り文字（”／”）で区切った文字列（以下、「ファイルのパス名」）により表す。
【００３４】
図２は、本実施形態のクライアント１０３とサーバ１０５間でやり取りされるアクセス要求および応答パケットの例を示す図である。ＬＡＮ１０１での通信は、所定の通信プロトコルに基づくパケットによるデータ送受信でおこなわれる。クライアント１０３は、図２のＡ及びＢに示す読み出し（以下「ｒｅａｄ」）及び書き込み（以下「ｗｒｉｔｅ」）要求パケットをファイルサーバ１０５へ送信する。ファイルサーバ１０５は、図２のＣ及びＤに示すｒｅａｄ／ｗｒｉｔｅ返答パケットをＬＡＮ１０１を介してクライアント１０３へ返信する。
【００３５】
図２Ａは、クライアントＡ（送り元フィールド値に１００．０．０．１のクライアントＡのＩＰアドレスが格納されている）がファイルサーバＣ（宛先フィールドが２００．０．０．１０１）に対して、ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）をｒｅａｄ要求（要求種別）するパケットである。
【００３６】
図２Ｂは、クライアントＡ（送り元）がファイルサーバＣ（宛先）に対して、ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）にデータ本体（データフィールドに格納）をｗｒｉｔｅ要求（要求種別）するパケットである。
【００３７】
図２Ｃは、サーバＣ（送り元）がクライアントＡ（宛先）に、ｒｅａｄ応答（要求種別）を返すパケットである。ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）をデータフィールドに格納して返答している。
【００３８】
図２Ｄは、サーバＣ（送り元）がクライアントＡ（宛先）に、ｗｒｉｔｅ応答（要求種別）を返すパケットである。ファイル”／ｄｏｃ／ｍｉｓｃ／ｓａｍｐｌｅ．ｌｏｇ”（要求パス名）の先頭から４０９６ｂｙｔｅ目（オフセット）から１０２４ｂｙｔｅ（サイズ）が正常に書き込まれたことを返答している。
【００３９】
各ファイルサーバ１０５のＣＰＵ１１６は、ファイルシステムプログラム１２０を実行することで、クライアント１０３からのアクセスを監視し、その結果をアクセス統計テーブル１２２に格納する。
【００４０】
図３は、アクセス統計テーブル１２２の例を示す図である。アクセス統計テーブル１２２には、クライアント１０３からアクセスされたファイルのパス名を登録するエントリ６０１、要求元となるクライアント１０３が所属するネットワークグループに共通するネットワークマスクを登録するエントリ６０２、ネットワークまでの距離（ただし、主にホップ数（中間ルータの数）や、遅延時間、通信料金、信頼性などにより算出される距離であり、物理的な距離を意味しない。）が登録されるエントリ６０３、そのネットワークグループに属するクライアント１０３からのアクセス回数を登録するエントリ６０４及びそのネットワークグループに属するクライアント１０３から最初にアクセスがあった時刻を記録するエントリ６０５を有する。また、本テーブル１２２には、ファイル毎にこれらの情報が登録される。
【００４１】
ここで、本発明の動作の概要を簡単に説明すると、ファイルサーバがアクセス統計テーブルの内容を確認し、移送対象となるファイルを探し出し、次に移送先となるファイルサーバを決定し、ファイルの格納位置情報を変更し、その後に、ファイルの実体を移行する。以下、動作の手順を追って説明する。
【００４２】
図４は、サーバ１０５が、アクセス統計テーブル１２２を更新する際の処理手順の例を示した図である。尚、本処理手順は、ファイルサーバ１０５が、クライアント１０３からのファイルアクセス要求を受信したときに実行される。
【００４３】
クライアント１０３からファイルアクセス要求を受信したサーバ１０５は（ステップ７０１）、まず、自身のメモリ１０１内のアクセス統計テーブル１２２に、アクセス要求を受けたファイルのエントリが既に存在するかどうかを調べる（ステップ７０２）。
【００４４】
アクセス統計テーブル１２２にアクセス要求を受けたファイルのエントリが存在しなければ、サーバ１０５は、アクセス統計テーブル１２２に新たにエントリを作成し、エントリ６０１に、アクセス要求を受けたファイルのパス名を登録する（ステップ７０３）。
【００４５】
アクセス統計テーブル１２２にアクセス要求を受けたファイルのエントリが既に存在する場合、サーバ１０５は、存在するファイルに対応するエントリ６０２に登録されたネットワークマスクに対応するネットワーク１０１が、ファイルアクセスを要求したクライアント１０３が属するネットワークグループのネットワーク１０１と一致するか検査する。具体的には、アクセス要求パケットに含まれる宛先（サーバ）エントリに登録されたアドレスの上位２４Ｂｉｔ（ただし、２４は、マスクビット長の例。）とエントリ６０２に登録されたネットワークマスクの値とを比較する（ステップ７０４）。
【００４６】
アクセス要求元であるクライアント１０３が属するネットワークグループに対応するネットワーク１０１と登録されたネットワークマスクに対応するネットワーク１０１とが異なる場合及びステップ７０３にて新たにファイルのエントリを作成した場合、サーバ１０５は、アクセス要求の対象となるファイルに対応するエントリ６０２に、クライアント１０３が属するネットワークグループのネットワークマスクを登録する。また、サーバ１０５は、アクセス要求の対象となるファイルに対応するエントリ６０３に、クライアント１０３が属するネットワークグループとサーバ１０５が属するネットワークグループとの間の距離（ここではクライアント１０３が属するネットワークグループとサーバ１０５が属するネットワークグループとの間に存在する、ネットワークを仲介する中間ルータ数）を登録する。尚、インターネットの場合、各装置間の距離（ホップ数）はＩＣＭＰパケット等を用いて算出することができる。
【００４７】
さらに、サーバ１０５は、アクセス対象のファイルに対応するエントリ６０４に値「１」を設定し、エントリ６０５に、現在時刻（ここでは、テーブルに値を設定するときの時刻）を設定する（７０５）。
【００４８】
ステップ７０４でアクセス要求元のクライアント１０３が属するネットワークグループがアクセス統計テーブル１２２に登録されたネットワークグループと同一であると判断した場合、サーバ１０５は、アクセス要求のあったファイルに対応するエントリ６０４に登録された値を１増分（インクリメント）する（ステップ７０６）。ステップ７０５又はステップ７０６の処理を実行したサーバ１０５は、アクセス統計テーブルの更新処理を終了する。
【００４９】
現在時刻が「２００２／９／１ １０：００：００」から０．３００秒後の場合、図３で例示したアクセス統計テーブル１２２の１行目は、ファイルサーバ１０５のファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に対して、ＬＡＮ１（１００．０．０．０／２４）のネットワークグループに属するクライアント１０３（サーバ１０５との間の距離は５）から、０．３００秒間（「現在時刻−アクセス開始時刻」にて算出）に連続して１２０回のアクセスが発生したことを示している。
【００５０】
ここで、仮にクライアント１０３Ｃがファイルサーバ１０５Ｃのファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に対してｒｅａｄ要求を発行すると、クライアント１０３Ｃの属するネットワークグループ（ここではＬＡＮ２）は、その前に登録されていたネットワークグループ（ここでは、ＬＡＮ１）とは異なるので、図３の第一行目の内容は、図４で示した処理により、”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”， ”２００．０．０．０／２４”， ”１”， ”１”， ”現在時刻”と書き換えられる。
【００５１】
各ファイルサーバ１０５は、一定時間毎にアクセス統計テーブル１２２の内容を検査し、ファイルサーバ１０５が管理するファイルに対して、特定のネットワークグループに属する任意のクライアント１０３からのアクセス（以下「ネットワークグループからのアクセス」と称する）が集中（詳細は後述）しているかどうかを確認する。もしそのようなファイルが見つかったときは、ファイルサーバ１０５は、そのファイルを移送すべきファイルの候補として選定する。
【００５２】
図５は、サーバ１０５がアクセス統計テーブル１２２の内容を確認して移送すべきファイルの候補を選択するまでの処理手順の例を示すフローチャートである。本処理は、ファイルサーバ１０５が、ファイルシステムプログラム１２０を実行することによって一定時間毎に実行される。
【００５３】
ファイルシステムプログラム１２０を実行するファイルサーバ１０５Ｃは（ステップ８０１）、アクセス統計テーブル１２２の内容を確認し、予め定められた条件を満たすファイルが存在するかどうかを確認する。尚、本実施形態では、移送候補となるファイルとして、クライアント１０３が属するネットワークグループとファイルサーバ１０５が属するネットワークグループとの間の距離が２以上、あるネットワークグループからのアクセス回数が１０回以上、かつ、アクセス開始時刻から現在時刻まで１時間以上経過している（その間、他のネットワークグループからのアクセスはない）ファイルが検出されるよう、条件が設定される（ステップ８０２）。（ただしこれらの閾値はファイルシステムプログラムにあらかじめ設定するほか、ユーザにより再設定する。）
条件を満たすファイルがある場合、サーバ１０５Ｃは、そのファイルを移送候補として選択する。例えば、現在時刻が仮に２００２／９／２ １１：００：０５（２００２年９月２日 １１時００分０５秒）ならば、図３のアクセス統計テーブル１２２の例では、ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が条件に適合している。このため、ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が移送候補として選定される（ステップ８０３）。
【００５４】
移送候補となるファイルを選定したら、ファイルサーバ１０５Ｃは、次に、選定されたファイルを集中的にアクセスしているネットワークグループに属するファイルサーバ１０５へ、選定されたファイルを移送しようと試みる。上記の例では、ファイルサーバ１０５Ｃは、選定されたファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”を、アクセスを行っているネットワークグループ（ここではＬＡＮ１）に属するファイルサーバ１０５Ａまたは１０５ＢをＬＡＮ１から検索する。具体的には、ファイルサーバ１０５Ｃは、移送先検索パケットをＬＡＮ１に接続されている機器に対してブロードキャストする。ここで、ブロードキャストとは、指定したネットワークに属する不特定の機器（ノード）を受信先としたパケットの送信を指す（ステップ８０４）。
【００５５】
図６は、移送先検索パケットの例を示す図である。移送先検索パケットは、移送元となるファイルサーバ１０５Ｃ（以下「移送元ファイルサーバ」）が、ファイルを特定のネットワークグループのいずれかのファイルサーバ１０５Ａまたは１０５Ｂへ移送することが可能かどうか判断するために発行する。すなわち、移送先となるファイルサーバ１０５Ａまたは１０５Ｂ（以下「移動先ファイルサーバ」）を検索するために発行される。
【００５６】
移送先検索パケットの「宛先ネットワーク」は移送先検索パケットのブロードキャスト先ネットワークマスクを格納する。「送り元サーバ」は本パケットの発行元ノードのＩＰアドレスを格納する。「移送ＩＤ」は一連の移送手続きを他の移送手続きと区別するために移送元ファイルサーバが付ける識別番号である。「移送元サーバ」は移送元サーバのＩＰアドレスである。
【００５７】
移送先検索パケットは、要求容量フィールドを有する。同フィールドには、移送元ファイルサーバが移送するファイル（以下「移送ファイル」）を格納するために、移送先ファイルサーバ１０５Ａまたは１０５Ｂに確保すべき記憶容量が設定される。具体的には、移送ファイルのサイズ（もしくはファイルサイズが拡大することを見越してそれ以上の値）が設定される。
【００５８】
移送先検索パケットを受け取ったＬＡＮ１のネットワークグループに属するファイルサーバ１０５Ａと１０５Ｂは、指定された移送ファイルを受け入れることができるかどうかを判定し、その結果を移送元ファイルサーバに送信する。
【００５９】
図７は、移送先検索パケットを受信したサーバ１０５Ａと１０５Ｂが実行する移送受け入れ判定処理のフローチャートを示す図である。本処理は、ファイルサーバ１０５Ａと１０５Ｂがファイルシステムプログラム１２０を実行することによって行われる。
【００６０】
移送先検索パケットを受け取ったファイルサーバ１０５Ａと１０５Ｂは、移送許可パケットを作成する。図８は、移送許可パケットの具体例を示す図である。ファイルサーバ１０５Ａと１０５Ｂは、移送許可パケットの管理者フィールドに、サーバを管理する管理者の管理者ＩＤ（本例では”ｆｏｏ”）を設定する。さらに、なりすましを防止し、管理者が本物であることを示すために、ファイルサーバ１０５は、暗号化された管理者署名（本例では”ｏｅｋｄｉｇｋｅ”）を管理者署名フィールドに設定する（ステップ１００２）。
【００６１】
次に、ファイルサーバ１０５Ａと１０５Ｂは、移送ファイルを受け入れることが可能かどうかを判定するために、自らが有するディスク装置１１９の空き容量を検査する。ファイルサーバ１０５Ａと１０５Ｂは、ディスク装置１１９に移送先検索パケットで指定された要求容量以上の空き容量が存在する場合は、移送ファイルを受け入れることができると判断する。ディスク装置１１９に移送先検索パケットで指定された要求容量以上の空き容量が存在しない場合は、ファイルサーバ１０５Ａ，１０５Ｂは、移送ファイルを受け入れることができないと判断する（ステップ１００３）。
【００６２】
移送ファイルを受け入れることができる場合、ファイルサーバ１０５Ａ，１０５Ｂは、作成した移送許可パケットの応答フィールドに受け入れ許可を示す数値、ここでは１を設定する。また、ファイルサーバ１０５Ａ，１０５Ｂは、移送許可パケットの許可容量フィールドに、ディスク装置１１９の記憶容量の空き容量を示す値をセットする。さらに、ファイルサーバ１０５Ａ，１０５Ｂは、移送ファイルを受け入れるためのディレクトリ（本例では、ディレクトリ”／２００．０．０．１０１／”）をディスク装置１１９に作成し、移送許可パケットの移送先パス名フィールドに作成したディレクトリのパス名を示す情報をセットする（ステップ１００４）。
【００６３】
移送ファイルを受け入れることができない場合、ファイルサーバ１０５Ａ、１０５Ｂは、作成した移送許可パケットの応答フィールドに、転送受け入れの不可を示す値、ここでは０を設定する（ステップ１００５）。
【００６４】
本実施形態では、移送先ファイルサーバの候補であるＬＡＮ１のネットワークグループに属するファイルサーバ１０５Ａ及び１０５Ｂが、それぞれ図８Ａ、Ｂに示した移送許可パケットを移送元ファイルサーバ１０５Ｃへ返送したとする。
【００６５】
ファイルサーバ１０５Ａ及び１０５Ｂから移送許可パケットを受信したファイルサーバ１０５Ｃは、受信した移送許可パケットの内容を比較して、移送先ファイルサーバを決定する。
【００６６】
図９は、移送元となるファイルサーバ１０５、ここではファイルサーバ１０５Ｃが、移送先ファイルサーバの決定する際の処理手順を示すフローチャートである。本処理は、移送許可パケットを受信したときに、ファイルサーバ１０５Ｃがファイルシステムプログラム１２０を実行することによって実行される。
【００６７】
まず、ある移送許可パケットを受信したファイルサーバ１０５Ｃは、他の移送許可パケットの到着を一定時間待つ（ステップ１３０２）。もし、移送先検索パケットをブロードキャストした後、一つも移送許可パケットを受信しない場合、ファイルサーバ１０５Ｃは受け入れ先無しとみなして何もしない。また、一定時間経過後に到着した移送許可パケットは無視される。その後、ファイルサーバ１０５Ｃは、その一定期間内に到着した移送許可パケットの中から、移送許可パケットの応答フィールドに移送許可を示す１が登録されている移送許可パケットを選択する（ステップ１３０３）。
【００６８】
その後、ファイルサーバ１０５Ｃは、選択された移送許可パケットの中から、その管理者ＩＤフィールドに登録された管理者ＩＤがファイルサーバ１０５Ｃの管理者と同一の管理者ＩＤであり、かつ管理者署名フィールドに登録されている暗号署名に基づいてその管理者ＩＤが本物であると認証できた移送許可パケットを選択する。尚、移送許可パケットを送信したファイルサーバ１０５Ａ、１０５Ｂの管理者が移送元ファイルサーバの管理者と同じでなければ、そのサーバ１０５は信頼できないとみなして移送先ファイルサーバとしなくても良い。ただし、管理者が異なる場合でも、あらかじめ許容される複数の管理者名が移送元ファイルサーバに登録され、移送許可パケットに登録された管理者がその複数の管理者に含まれる場合には、移送元ファイルサーバがファイルの移送を行う態様としても良い（ステップ１３０４、１３０５）。
【００６９】
その後、ファイルサーバ１０５Ｃは、選択された移送許可パケットの中から、確保容量フィールドに登録された記憶容量が最大のものを選択する（ステップ１３０６）。その結果、ファイルサーバ１０５Ｃは、選択された移送許可パケットを発行したファイルサーバ１０５Ａを移送先ファイルサーバとして選択する（本例では、ファイルサーバＡを選択したとする）。尚、ステップ１３０６で条件に合致する移送許可パケットとして複数の移送許可パケットが残った場合には、ファイルサーバ１０５Ｃは、そのうちのひとつをランダムに選択する。本実施形態では、図８Ａ、Ｂの移送許可パケットを受け取ったファイルサーバ１０５Ｃは、空き容量が最大のファイルサーバ１０５Ａを移送先ファイルサーバとして選択する（ステップ１３０７）。
【００７０】
上述した各ステップにおいて、条件に一致する移送許可パケットが見つからなかった場合は、ファイルサーバ１０５Ｃは、移送先ファイルサーバ無しとして、以下に述べる移送先ファイルサーバの指名処理は行わない。すなわち、ファイルサーバ１０５Ｃは、ファイルの移送をおこなわない（ステップ１３０８）。
【００７１】
移送先ファイルサーバを決定した、移送元ファイルサーバ１０５Ｃは、ファイルシステムプログラム１２０を実行して、ノード・パス名変換テーブル１２１を更新する。この更新により、移送ファイルを管理するファイルサーバ１０５が、移送元ファイルサーバ１０５Ｃから移送先ファイルサーバ１０５Ａへと変更される。
【００７２】
図１０は、ノード・パス名変換テーブル１２１の例を示す図である。ノード・パス名変換テーブル１２１には、移送ファイルの移送元と移送先ファイルサーバに関する情報が関連付けて登録される。ファイルサーバ１０５は、このテーブルを検索して、ファイルが移送されているかどうか及び移送されている場合にはその移送先についての情報を取得することが出来る。
【００７３】
移送先ファイルサーバを決定した移送元ファイルサーバ１０５Ｃは、ノード・パス名変換テーブル１２１に、決定された移送先ファイルサーバに対応する新たなエントリ（行）を追加し、移送元のノード及びパス名フィールド、移動先のノード及びパス名フィールドに値をセットする。尚、「移送ＩＤ」は一連の移送手続きを他の移送手続きと区別するために移送元ファイルサーバが付ける識別番号である。移送元ファイルサーバが移送先検索パケット内に設定する。
【００７４】
移送元のノードフィールドには、自ファイルサーバ１０５（この場合１０５Ｃ）のＩＰアドレス（本例では２００．０．０．１０１）がセットされる。移送元のパス名フィールドには、移送ファイルのパス（本例では”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）がセットされる。
【００７５】
移送先のノードフィールドには、選択された移送許可パケットの移送先サーバフィールドに登録された値（本例では１００．０．０．１０１）がセットされる。移送先のパス名フィールドには、選択された移送許可パケットの移送先パス名フィールドに登録された値（本例では”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）がセットされる。
【００７６】
その結果、ノード・パス名変換テーブル１２１の新たなエントリには、”２００．０．０．１０１”の”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”としてファイルサーバ１０５Ａに管理されていたファイルが、”１００．０．０．１０１”の”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に移送されたことを示す情報が登録されることになる。
【００７７】
ノード・パス名変換テーブル１２１を更新したファイルサーバ１０５Ｃは、ファイルサーバ１０５Ａが移送先ファイルサーバとして選択され、ファイルがファイルサーバ１０５Ａへ移送されたことをクライアント１０３及びファイルサーバ１０５へ通知するために、移送先ファイルサーバが属するネットワークグループのネットワークであるＬＡＮ１へ移送通知パケットをブロードキャストする（ステップ１３０９）。
【００７８】
尚、移送通知パケットがブロードキャストされる時点で、実際にファイルが移送されていても、移送されていなくても良い。ファイルが移送されていない場合、そのファイルの移送は、クライアント１０３から移送ファイルに対するアクセス要求があったタイミングで、移送先ファイルサーバの要求に基づいて行われても良い。このようにすることによって、移送が必要なファイル（移送ファイルとして決定されても、実際にその後アクセス要求がなければ、移送する必要はない）のみ移送することができ、移送ファイルの移送によるネットワーク１０１の負荷の増加を最小限に抑えることができる。
【００７９】
また、実際のファイルの移送を、移送通知パケットのブロードキャスト後で、アクセス要求とは無関係な任意の時点にすることもできる。例えば、ネットワーク１０１のトラフィックが少ない時を見計らってファイルの移送が行われても良い。一方、移送通知パケットをブロードキャストする前に、移送ファイルが実際に移送されても良い。この場合、アクセス要求があった際に行われる移送元ファイルサーバでの処理量が少なくなるというメリットがある。
【００８０】
図１１は、移送通知パケットの例を示す図である。同図の移送通知パケットには、移送元ファイルサーバに関する情報と移送先ファイルサーバに関する情報が含まれる。本図の移送通知パケットは、”２００．０．０．１０１”の”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”としてファイルサーバ１０５Ａが管理していたファイルが、ファイルサーバ１０５Ｃ（”１００．０．０．１０１”）の”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”に移送されたことを示している。
【００８１】
移送通知パケットを受信したファイルサーバ１０５Ａおよびクライアント１０３Ａは、移送元ファイルサーバ（ここではファイルサーバ１０５Ｃ）が行ったのと同様に、ノード・パス名変換テーブル１１５、１２１に新たなエントリ（行）を追加し、移送元のノード及びパス名フィールド、移送先のノード及びパス名フィールドに値をセットする。
【００８２】
次に、移送ファイルをクライアント１０３Ａがアクセスする場合の動作について説明する。
【００８３】
図１２は、クライアント１０３におけるアクセス変換処理の手順を示すフローチャートである。本処理は、クライアント１０３がファイルシステムプログラム１１４を実行することで実行される。本実施形態では、クライアント１０３Ａが、ファイルサーバ１０５Ｃが管理するファイル（パス名”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）にアクセスする例を示す。ここで、クライアント１０３Ａのアプリケーションプログラム１１３は、ファイルの移送の有無について関知しないため、ファイルサーバ１０５Ｃが管理するファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”を、移送の有無を問わず、そのままアクセスしようとする。
【００８４】
アプリケーションプログラム１１３の実行によってアクセス要求パケットを作成したクライアント１０３Ａは、作成されたアクセス要求（ここではファイルサーバ１０５Ｃが管理するファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）に基づいてノード・パス名変換テーブル１１５を参照し、アクセスしようとするファイルが同テーブル１１５の移送元フィールドに存在するかどうかを確認する（ステップ１６０２）。
【００８５】
アクセス要求の対象となるファイルを有するファイルサーバ１０５Ｃがノード・パス名変換テーブル１１５の移送元フィールドに存在しなければ、クライアント１０３Ａは、そのままファイルサーバ１０５、ここではファイルサーバ１０５Ｃへアクセス要求パケットを発行する（ステップ１６０４）。
【００８６】
アクセス要求の対象となるファイルを有するファイルサーバ１０５Ｃがノード・パス名変換テーブル１１５の移送元フィールドに存在する場合、そのファイルは別のファイルサーバ１０５Ａへ移送されているので、クライアント１０３Ａは、アクセス要求パケットの送付先を移送先ファイルサーバへに変換してアクセス要求パケットを発行する。本実施形態では、アクセスしようとするファイル（”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）がテーブル１１５の移送元フィールドに存在するため、クライアント１０３Ａは、ファイルへのアクセス要求の発行先を、テーブル１１５の移送先フィールドに記述されたファイルサーバ（ＩＰアドレス：１００．０．０．１０１）１０５Ａの「２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ」に変換してアクセス要求パケットを発行する。
【００８７】
図１３は、変換前と変換後のアクセス要求パケットの例を示す図である。クライアント１０３Ａにおける変換により、宛先（サーバ）フィールドがノード・パス名変換テーブル１１５の移送先ノードフィールドに登録された値（１００．０．０．１０１）に変換され、要求パス名フィールドがテーブル１１５の移送先パス名フィールドに登録された値（／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ）に変換される（ステップ１６０３、１６０４）。
【００８８】
次に、移送ファイルに対するアクセス要求を受けた移送先ファイルサーバ１０５Ａの動作を説明する。
【００８９】
図１４は、アクセス要求を受け付けた移送先ファイルサーバ１０５Ａの処理手順を示すフローチャートである。
【００９０】
アクセス要求パケット（本例では、図１３の変換後のアクセス要求パケット）を受け付けた移送先ファイルサーバ１０５Ａは、アクセス要求パケットの要求パス名フィールドに記されたファイル（本例では、パス名が”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）が既に自分のディスク装置１１９に格納されているかどうかを検査する（ステップ１８０２）。
【００９１】
既にディスク装置１１９にファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が存在する場合、そのファイルは移送済みなので、ファイルサーバ１０５Ａは、そのままファイルにアクセスし、そのアクセス結果に基づいて返答パケットを生成し、クライアント１０３Ａへ応答パケットを送信し（ステップ１８０７）、手続きを完了する。
【００９２】
一方、ファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”がディスク装置１１９に格納されていない場合、ファイルサーバ１０５Ａは、そのファイルのパス名がノード・パス名変換テーブル１２１の移送先フィールドに存在するかどうかを確認する（ステップ１８０３）。
【００９３】
ノード・パス名変換テーブル１２１の移送先フィールドにファイルのパス名が存在しない場合、そのファイルはシステムのどのファイルサーバ１０５Ａ，１０５Ｂ，１０５Ｃにも存在しないので、ファイルサーバ１０５Ａは、クライアント１０３Ａにファイルが存在しないことを示すエラーを送信し（ステップ１８０４）、手続きを完了する。
【００９４】
ノード・パス名変換テーブル１２１の移送先フィールドにファイルのパス名が存在する場合、そのファイルはまだ移送元ファイルサーバ１０５Ｃから移送先ファイルサーバである本ファイルサーバ１０５Ａに移送されていないことになる。そこで、ファイルサーバ１０５Ａは、ノード・パス名変換テーブル１２１の移送元フィールドを参照し、ファイルのパス名に対応する移送元ファイルサーバＣ（２００．０．０．１０１）及びファイルのパス名（”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）を取得する。更に、ファイルサーバ１０５Ａは、取得した移送元ファイルサーバ１０５Ｃへファイルのｒｅａｄ要求パケットを発行する。さらに、ファイルサーバ１０５Ａは、移送元ファイルサーバ１０５Ｃに格納されている移送ファイルを削除する要求パケットも発行する。尚、ｒｅａｄ要求パケット及び移送ファイルの削除を要求する要求パケットを受信した移送元ファイルサーバ１０５Ｃは、ｒｅａｄ要求パケットで指定されるファイルを、ｒｅａｄ要求パケットを発行したファイルサーバ１０５Ａへ送信し、その送信したファイルをディスク装置１１９から削除する。尚、移送元ファイルサーバ１０５Ｃにｒｅａｄ要求パケットで指定されるファイルが存在しない場合、移送元ファイルサーバ１０５Ｃは、ｒｅａｄ要求パケットを発行したファイルサーバ１０５Ａにエラーを報告する（ステップ１８０５）。
【００９５】
移送元ファイルサーバからｒｅａｄ応答パケットが返信されると、ファイルサーバ１０５Ａは、受信したｒｅａｄ応答パケットに含まれるファイルのデータを、自ディスク装置１１９に格納する。このときのファイルのパス名は、ノード・パス名変換テーブル１２１の移送先のパス名フィールドに格納された値（”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）が用いられる（ステップ１８０６）。
【００９６】
最後に、ファイルサーバ１０５Ａは、ディスク装置１１９に格納したファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”へアクセスし、クライアント１０３Ａへ応答パケットを送信し（ステップ１８０７）、応答処理を完了する。
【００９７】
次に、移送先通知パケットを受信しなかったクライアント１０３（例としてクライアント１０３Ｃ）が、移送済みの移送ファイル（”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）にアクセスする動作について説明する。
【００９８】
移送通知パケットは、ある条件を満たしたアクセス要求元のクライアント１０３が属するネットワークグループのネットワーク１０１へブロードキャストされるため、その他のネットワークグループ（ここでは例としてＬＡＮ２）に属するクライアント１０３Ｃには、ファイル（例として、ファイルサーバ１０５Ｃの”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）が移送先ファイルサーバ（例としてファイルサーバ１０５Ａ）へ移送されたことが通知されない。また、本発明が適用されないクライアントがネットワーク１０１に多数属する環境でも、ファイルは全てのクライアントから正常にアクセスできなければならない。
【００９９】
図１５は、ファイルが移送されたことを知らないクライアント１０３Ｃがファイルサーバ１０５Ｃ（この場合、ファイルサーバ１０５Ｃは移送元ファイルサーバとなる）にアクセス要求パケットを発行した時の、ファイルサーバ１０５Ｃの応答処理の手順を示すフローチャートである。
【０１００】
アクセス要求パケット（本例では、図１６の変換前要求パケット）を受信したファイルサーバ１０５Ｃは、アクセス要求パケットの要求パス名フィールドに登録されたファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が自ディスク装置１１９に格納されているかどうかを検査する（ステップ１９０２）。
【０１０１】
ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が自ディスク装置１１９に格納されている場合、ファイルサーバ１０５Ｃは、そのファイルにアクセスし、その結果に基づいて返答パケットを生成し、クライアント１０３Ｃへ応答パケットを送信し（ステップ１９０３）、応答処理を完了する。
【０１０２】
ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が自ディスク装置１１９に格納されていない場合、ファイルサーバ１０５Ｃは、そのファイルのパス名がノード・パス名変換テーブル１２１（本例では、図１０のテーブル１２１をファイルサーバ１０５Ｃが有しているとする）の移送元フィールドに存在するかどうかを確認する（ステップ１９０４）。ノード・パス名変換テーブル１２１の移送元フィールドにそのファイルのパス名が存在しない場合、そのファイルはネットワークシステムのどこにも存在しないので、ファイルサーバ１０５Ｃは、クライアント１０３Ｃへファイルが存在しないことを示すエラーを送信し（ステップ１９０５）、応答処理を完了する。
【０１０３】
ノード・パス名変換テーブル１２１の移送元フィールドにファイルのパス名が存在する場合、そのファイルは既に移送先ファイルサーバへ移送されていることになる（図１０では、ファイル”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”の移送先ファイルサーバは、２００．０．０．１０１の”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ ”となる）。そこで、ファイルサーバ１０５Ｃは、ノード・パス名変換テーブル１２１において、検索されたファイルのパス名に対応する移送先フィールドを参照し、移送先ファイルサーバ（１００．０．０．１０１）及び移送先でのファイルのパス名（”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”）の情報を取得する。
【０１０４】
次に、ファイルサーバ１０５Ｃは、クライアント１０３Ｃから受信したアクセス要求パケット（図１６の変換前要求パケット）の宛先フィールドと要求パス名フィールド（／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ）に登録された値を、上記処理で得た移送先ファイルサーバ（１００．０．０．１０１）とパス名（／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ）へ変更し、さらに、送元フィールドに自分のアドレス（２００．０．０．１０１）をセットする（図１６の変換後要求パケットを参照）。
【０１０５】
そして、ファイルサーバ１０５Ｃは、作成した変換後要求パケットを、移送先ファイルサーバ（本例ではファイルサーバ１０５Ａ）へ送信する。変換後要求パケットを受信した移送先ファイルサーバは、その内容で指定されるファイルを読み出して応答パケット（本例では図１７の変換前応答パケット）を作成し、ファイルサーバ１０５Ｃへ返信する（ステップ１９０６）。
【０１０６】
移送先ファイルサーバより応答パケットを受信したファイルサーバ１０５Ｃは、その応答パケットの内容を次のように変換する。応答パケットの宛先フィールドの値（２００．０．０．１０１）を、ｒｅａｄ要求パケットを発行したクライアント１０３Ｃのアドレス（２００．０．０．１）に、送元フィールドの値をファイルサーバ１０５Ｃのアドレス（２００．０．０．１０１）に、応答パス名フィールドの値をクライアント１０３Ｃから受信した変換前要求パケットの要求パス名フィールドに登録された値に変換する（図１７の変換後応答パケットを参照）。
【０１０７】
変換終了後、ファイルサーバ１０５Ｃは、変換して作成した応答パケットを、クライアント１０３Ｃへ送信する（ステップ１９０７）。
【０１０８】
最後に、ファイルサーバ１０５Ｃは、クライアント１０３Ｃに対して、次回以降の同ファイルへのアクセスはファイルサーバ１０５Ａに対して行うように指示するため、移送通知パケットをクライアント１０３Ｃに送信し（ステップ１９０８）、応答処理を完了する。
【０１０９】
移送通知パケットを受信したクライアント１０３Ｃでは、以下の二つの処理のうち、いずれか一つが行われる。クライアント１０３Ｃが移送通知パケットを認識できる場合、クライアント１０３Ｃは、ファイルサーバ１０５Ｃから送信された移送通知パケットを受信し、その内容に従ってノード・パス名変換テーブル１１５を更新する。この処理の結果、移送ファイルへのアクセスは、クライアント１０３内で移送先ファイルへのアクセスに変換されるようになるため、以後のクライアント１０３の移送ファイルへのアクセス要求の発行は移送先ファイルサーバに対して直接行なわれる。
【０１１０】
一方、クライアント１０３が移送通知パケットを認識することが出来ない場合、クライアント１０３において移送通知パケットは無視される。したがって、クライアント１０３からの移送ファイルへのアクセス要求は、引き続き移送元であるファイルサーバ１０５Ｃに対して発行される。しかし、ファイルサーバ１０５Ｃは、クライアント１０３からの要求を上記と同様の方法で変換し、移送先ファイルサーバへ代理アクセスを実施するため、クライアント１０３は従来通りの方法によるファイルアクセスの実行が可能である。
【０１１１】
次に、移送ファイルを移送元ファイルサーバへ返還する方法について説明する。ファイルアクセス要求元となるクライアント１０３は、時間の経過と共に変化する可能性がある。このため、一旦他のファイルサーバ１０５へ移送したファイルも、移送元ファイルサーバへ返還した方がアクセス性能が向上する場合がある。
【０１１２】
ファイル移送後も、ファイルサーバ１０５、特に移送先ファイルサーバはアクセス統計テーブル１２２にファイルアクセスに関する統計情報を引き続き収集し続ける。
【０１１３】
移送先ファイルサーバは、一定時間毎にアクセス統計テーブル１２２（本例では図１８）を検査し、移送ファイルを返還べきかどうかを以下の方法により検査する。具体的には、移送ファイルが移送元ファイルサーバが属するネットワークグループから集中してアクセスされているかどうかを検査する。
【０１１４】
図１９は、移送ファイルの返還処理のうち、返還対象となる移送ファイル（以下、「返還対象ファイル」）を決定する処理手順を示すフローチャートである。本処理は移送先ファイルサーバが、ファイルシステムプログラム１２０を実行することで、一定時間間隔毎に実施される。
【０１１５】
本処理の実行を開始した移送先ファイルサーバは、特定の条件に合致するファイルをアクセス統計テーブル１２２から検索する。本例においては、移送先ファイルサーバは、所定の時間、例えば、本処理の開始から１時間前の間に特定のネットワークグループのみから閾値以上の頻度（本例では１０回以上）でアクセスが行われたファイルをアクセス統計テーブル１２２から抽出する。尚、これらの閾値はファイルシステムプログラムにあらかじめ設定するほか、ユーザにより再設定する。本例においては、本処理を開始した時刻が２００２／１０／１ ９：００：００以降ならば、図１８のアクセス統計テーブル１２２に登録されているファイル”／２００．０．０．１０１／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が上述した条件に適合する（ステップ２３０２）。
【０１１６】
次に、移送先ファイルサーバは、抽出されたファイルがノード・パス名変換テーブル１２１（本例では図１０に示す内容が登録されているとする）の移送先のパス名フィールドに登録されているかどうかを検査する（ステップ２３０３）。
【０１１７】
抽出されたファイルがノード・パス名変換テーブル１２１に登録されていれば、そのファイルは移送ファイルであることがわかる。この場合、移送先ファイルサーバは、抽出されたファイルに対応する距離フィールドに登録された値（＝５）と、そのファイルの移送元ファイルサーバと要求元ネットワークフィールドに登録されたネットワーク（ここではＬＡＮ２）との間の距離（＝同一ネットワーク内なので０）を比較する。本処理により、ファイルに集中的にアクセスするネットワークグループと移送先ファイルサーバが属するネットワークグループとの距離が、ファイルに集中的にアクセスするネットワークグループと移送元ファイルサーバが属するネットワークグループとの間の距離よりも大きいかどうかを判定することができる（ステップ２３０４）。
【０１１８】
距離フィールドに登録された値の方が大きい場合、すなわち、移送ファイルに集中的にアクセスするネットワークグループと移送先ファイルサーバが属するネットワークグループとの間の距離が、移送ファイルに集中的にアクセスするネットワークグループと移送元ファイルサーバが属するネットワークグループとの間の距離より大きい場合、移送先ファイルサーバは、検索された移送ファイルを返還対象ファイルとして選定する。これは、移送元ファイルサーバへ移送ファイルを返還した方が、ネットワーク間の距離が小さくなり、システムのアクセス性能が向上するからである。
【０１１９】
返還対象ファイルを選定すると、移送先ファイルサーバは、続いて、返還要請パケット（図２０に返還要請パケットの例を示す）を作成する。移送先ファイルサーバは、返還要請パケット作成の際、ノード・パス名変換テーブル１２１の各エントリに登録されている値を参照して返還要請パケットの各フィールドに値を登録する。その後、移送先ファイルサーバは、移送元ファイルサーバへ返還要請パケットを送信する（ステップ２３０５）。
【０１２０】
尚、上述した処理においてファイルが条件を満たさない場合、移送先ファイルサーバは、返還処理を行わずに処理を終了する。
【０１２１】
図２１は、先に決定された返還対象ファイルの返還処理の手順を示すフローチャートである。
【０１２２】
返還要請パケットを受信した移送元ファイルサーバは、返還要請パケットを送信した移送先ファイルサーバ（以下「返還元サーバ」）に対して、返還要請パケットの返還元パス名フィールドに登録されたファイルのｒｅａｄ要求を発行する（ステップ２５０２）。返還元サーバよりファイルを受信した移送元ファイルサーバは、取得したファイルを、返還要請パケットの返還先パス名で指定されたファイル名で自ディスク装置１１９に格納する（ステップ２５０３）。さらに、移送元ファイルサーバは、返還元サーバに対して、返還元パス名フィールドで指定されるファイルの削除要求を発行する（ステップ２５０４）。その後、移送元ファイルサーバは、該サーバが有するノード・パス名変換テーブル１２１から、返還を受けたファイルのエントリを削除し（ステップ２５０５）、ファイルの返還処理を完了する。
【０１２３】
尚、返還処理の完了以後に、クライアント１０３が移送先ファイルサーバに対してアクセス要求を発行した場合、クライアント１０３は移送先ファイルサーバよりファイルが存在しない旨のエラー応答を受信する。この場合、クライアント１０３は、該クライアント１０３のノード・パス名変換テーブル１１５からエラー応答を受信したファイルのエントリを削除し、移送元ファイルサーバへ再度アクセス要求パケットを発行する。
【０１２４】
第一の実施形態では、「ファイル」を移送の単位として扱った。次に、第一の実施形態の応用として、複数のファイルを下層に含む「ディレクトリ」を移送の単位として扱う第二の実施形態について説明する。
【０１２５】
ファイルシステムにおいては、ディレクトリの配下には、複数のファイルが配されている。第二の実施形態においては、移送したいディレクトリを移送ディレクトリとして指定することにより、同ディレクトリに含まれる全てのファイルの移送を行うことが出来る。
【０１２６】
尚、以下に説明するアクセス統計テーブル１２２の検査手順以外の処理手順は、第一の実施形態と同じ手順であるので、説明を省略する。以下、第二の実施形態におけるアクセス統計テーブル１２２の検査手順を説明する。
【０１２７】
図２２は、第二の実施形態において、ファイルサーバ１０５がアクセス統計テーブル１２２の内容を検査する手順を示すフローチャートである。本処理は、ファイルサーバ１０５がファイルシステムプログラム１２０を実行することで、一定時間毎に実行される。
【０１２８】
ファイルサーバ１０５は、一定時間毎にアクセス統計テーブル１２２を検査し、ディレクトリ下のファイルへのアクセスが特定のネットワークグループから集中しておこなわれているかどうかを検査する。もしそのようなディレクトリが見つかったときは、そのディレクトリを移送ディレクトリの候補として選定する。
【０１２９】
ファイルサーバ１０５は、まず、アクセス統計テーブル１２２（図２３に示したテーブルであるとする）の中から、ファイルサーバ１０５が属するネットワークグループとアクセスするネットワークグループとの間の距離が２以上、アクセス回数が１０回以上、かつアクセス開始時刻から現在時刻まで一定時間（例として１時間）以上経過している（その間、他のネットワークグループからのアクセスはない）ファイルを検索する。本ステップにより発見されるファイルを（ｄ）とする。本例では、”／ｄｏｃ／ｍｉｓｃ／ｒｅｃｏｒｄ．ｏｕｔ”が該当する（ステップ２６０２）。尚、検索の条件は本例に限られない。ただしこれらの閾値はファイルシステムプログラムにあらかじめ設定するほか、ユーザにより再設定する。
【０１３０】
アクセス統計テーブル１２２に（ｄ）が存在した場合、ファイルサーバ１０５は、当該ファイルを含むディレクトリ（図２３の例では”／ｄｏｃ／ｍｉｓｃ／”）を認識し（ｄ１）とする。また、当該ファイルに対応する要求元ネットワークフィールドに登録されたネットワークを認識し（Ｎ）（図２３の例では、”１００．０．０．０／２４”）とする（ステップ２６０３）。
【０１３１】
次に、ファイルサーバ１０５は、アクセス統計テーブル１２２の全エントリの中から、ファイルが（ｄ１）の配下でかつ要求元ネットワークフィールドに登録されているネットワークが（Ｎ）以外のエントリを検索する。これを（ｅ）とする（図２３では該当するファイルはない）（ステップ２６０５）。
【０１３２】
（ｅ）が存在する場合、（ｄ１）には異なるネットワークグループからアクセスされるファイルが混在していることになる。このため、（ｄ１）配下のファイルを全て移送することはシステムの性能低下を招く。したがって、ファイルサーバ１０５はディレクトリである（ｄ１）の移送をあきらめ、（ｄ）を移送ファイルの候補として選択する（ステップ２６０８）。
【０１３３】
（ｅ）が存在しない場合、（ｄ１）配下のファイルはネットワーク（Ｎ）以外のネットワークグループからアクセスを受けていないため、ファイルサーバ１０５は、（ｄ１）を移送ディレクトリの候補として選択することができる。
【０１３４】
しかし、（ｄ１）よりも１階層上位のディレクトリ（図２３の例では”／ｄｏｃ／”）を移送ディレクトリの候補として選択できる可能性もある。このため、ファイルサーバ１０５は、次に、（ｄ１）を新たな（ｄ）、（ｄ１）の上位階層のディレクトリを新たな（ｄ１）として（ステップ２６０７）、ステップ２６０４以降の処理を再度実施する。すなわち、アクセス統計テーブル１２２の全エントリの中から、新たな（ｄ１）配下のファイルで、要求元ネットワークフィールドに登録されているネットワークが（Ｎ）以外のエントリを検索する。検索の結果得られるファイルのエントリを（ｅ）とする（図２３では”ｄｏｃ／ｍｅｍｏ．ｔｘｔ”が該当する）。
【０１３５】
ファイルサーバ１０５は、上記処理を繰り返し、エントリ（ｅ）が見つかった時点で処理の繰り返しを中止する。そして、中止時までに選択された移送ディレクトリの候補（またはファイル）（ｄ）を移送ディレクトリの候補とし（ステップ２６０８）、処理を終了する。
【０１３６】
尚、ディレクトリ単位で移送する第二の実施形態においても、第一の実施形態の図１４に示すように、移送先ファイルサーバがクライアント１０３からのアクセス要求を受けてからファイルの実体を移送するため、必要なデータのみがその都度ネットワーク１０１上で転送される。つまり、移送ディレクトリに含まれる移送ファイル全てを同時に移送しない。このため、ネットワーク１０１のトラフィックを分散させ、また、ファイルサーバ１０５の負荷を分散させる効果がある。
【０１３７】
次の第三の実施形態について説明する。第一の実施形態では、移送元ファイルサーバは、ファイルに集中的にアクセスするネットワークグループに含まれるファイルサーバ１０５の中から、移送先サーバを選択した。このため、ファイルに集中的にアクセスするネットワークグループに含まれるファイルサーバ１０５の中に条件（空き容量が指定量以上かつ、管理者が移送元サーバと同一、など）が適合するファイルサーバ１０５が存在しない場合、第一の実施形態においては、移送元ファイルサーバは移送を行わないこととした。
【０１３８】
しかし、以下に示す第三の実施形態では、ファイルに集中的にアクセスするネットワークグループに含まれるファイルサーバ１０５に、条件に適合するファイルサーバ１０５が見つからなかった場合に、他のネットワークグループに条件に適合するファイルサーバ１０５が存在すれば、移送元ファイルサーバは、次善の策としてそのファイルサーバ１０５へファイルの移送をおこなう。
【０１３９】
図２３は、第三の実施形態のシステム構成を示す図である。本実施形態のシステムは、２つのネットワークＬＡＮ１、ＬＡＮ３がインターネットやＷＡＮを介して接続され、ＬＡＮ２はインターネット１０４を介してＬＡＮ３と接続されている。ＬＡＮ２とＬＡＮ１とはＬＡＮ３を経由してのみ接続されている。
【０１４０】
第三の実施形態での処理は、以下に説明する移送先ファイルサーバの選択手順を除き、第一の実施形態での処理手続きと同じであるので、それらの処理については説明を省略する。以下に、第三の実施形態の移送先ファイルサーバの選択方法を説明する。
【０１４１】
図２５は、第三の実施形態における、ファイルサーバ１０５における移送先ファイルサーバ選択処理の手順を示すフローチャートである。本処理は、移送元ファイルサーバが移送ファイルの候補を選定したときに実行される。以下、図２４において、移送元ファイルサーバがファイルサーバ１０５Ｃである場合で説明する。
【０１４２】
移送ファイルの候補を選定した移送元ファイルサーバは、アクセス統計テーブル１２２から、移送ファイルの候補へアクセスを行うネットワークグループに対応するネットワーク（１００．０．０．０／２４：ＬＡＮ１）へ移送先検索パケットをブロードキャストする（ステップ３００２）。
【０１４３】
移送元ファイルサーバは、返送された移送許可パケットの内容を確認し、予め指定された条件を満たすかどうか判定する。本例においては、ＬＡＮ１に接続されたファイルサーバ１０５Ａ及び１０５Ｂから移送許可パケットが返送され、移送元ファイルサーバは、これらの移送許可パケットが条件（空き容量が指定量以上かつ、管理者が移送元サーバと同一、など）に適合するかどうかを検査する（ステップ３００３）。
【０１４４】
いずれの移送許可パケットも条件に適合しない場合、移送元ファイルサーバは、移送先検索パケットをブロードキャストするネットワークの対象を拡大する。具体的には、移送元ファイルサーバは、先に移送先検索パケットをブロードキャストしたネットワーク（ＬＡＮ１）について、ネットワークマスクビットを短縮（例では、マスクビットを２４ｂｉｔ（２５５．２５５．２５５．０）から１６ｂｉｔ（２５５．２５５．０．０）に短縮）し、ＬＡＮ１と同じ上位１６ビットのアドレスを有するＬＡＮ３（１００．０．１．０／２４）に移送先検索パケットをブロードキャストする（ステップ３００４、３００５）。
【０１４５】
その結果、ネットワークＬＡＮ３に属するファイルサーバ１０５Ｄ（１００．０．１．１０２）から移送許可パケットが移送元ファイルサーバに返送される。その後、移送元ファイルサーバは、ファイルサーバ１０５Ｄからの移送許可パケットが条件に適合するかどうか検査する（ステップ３００６）。ファイルサーバ１０５Ｄからの移送許可パケットが条件と適合している場合、移送元ファイルサーバは、ファイルサーバ１０５Ｄを移送先ファイルサーバとして選択する（ステップ３００７）。条件に適合するファイルサーバ１０５が無ければ、移送元ファイルサーバは、移送先ファイルサーバ無し判断して、ファイルの移送は行わない（ステップ３００８）。
【０１４６】
第三の実施形態によれば、移送元ファイルサーバは、アクセスを集中して行うネットワークグループに移送先ファイルサーバが見つからない場合にも、次善の策として、アクセスを集中して行うネットワークグループとは別のネットワークグループに属するファイルサーバ１０５へファイルを移送することができる。
【０１４７】
【発明の効果】
本発明によれば、クライアントから遠隔地にあるファイルサーバが管理するファイルへのアクセス性能を向上させることができる。また、キャッシュ方式に比べ一貫性制御が不要なため、ネットワークに余分なトラフィックを発生させることも無い。
【図面の簡単な説明】
【図１】システムの概要を示す図。
【図２】アクセス要求パケットの例を示す図。
【図３】アクセス統計テーブルの例を示す図。
【図４】アクセス統計テーブルの更新処理の手順を示すフローチャート。
【図５】移送ファイルの候補を決定する処理手順の例を示すフローチャート。
【図６】移送先検索パケットの例を示す図。
【図７】移送受け入れ判定処理の手順の例を示すフローチャート。
【図８】移送許可パケットの例を示す図。
【図９】移送先ファイルサーバの選択手順の例を示すフローチャート。
【図１０】ノード・パス名変換テーブルの例を示す図。
【図１１】移送通知パケットの例を示す図。
【図１２】アクセス変換処理の手順を示すフローチャート。
【図１３】変換前／変換後のアクセス要求パケットの例を示す図。
【図１４】移送先ファイルサーバの処理手順の例を示すフローチャート。
【図１５】移送元ファイルサーバの処理手順の例を示すフローチャート。
【図１６】移送元ファイルサーバによる要求パケットの変換例を示す図。
【図１７】移送元ファイルサーバによる応答パケットの変換例を示す図。
【図１８】アクセス統計テーブルの例を示す図。
【図１９】返還するファイルを決定する処理手順を示すフローチャート。
【図２０】返還要請パケットの例を示す図。
【図２１】ファイルの返還処理の手順の例を示すフローチャート。
【図２２】移送対象の候補となるディレクトを決定する処理手順の例を示す図。
【図２３】アクセス統計テーブルの例を示す図。
【図２４】第三の実施形態のシステムの全体を示す図。
【図２５】移送先サーバの選択処理の手順を示すフローチャート。
【符号の説明】
１０１…ＬＡＮ、１０３…クライアント、１０５…ファイルサーバ、１０９…ＣＰＵ、１１０…ＲＯＭ装置、１１１…メモリ、１１２…ネットワークインターフェイス、１１９…ディスク装置。
Claims (13)
- 第一のネットワークと、前記第一のネットワークに接続される第一の計算機と、前記第一のネットワークに接続される第二のネットワークと、前記第二のネットワークに接続される第二の計算機と第三の計算機とから構成される情報処理システムにおいて、
前記第一の計算機は、前記第一のネットワークと接続するための通信インタフェースと、データを格納するディスク装置と、前記ディスク装置とデータの送受信を行うためのディスクインタフェースと、前記第一の計算機を制御するＣＰＵと、データと前記ＣＰＵを動作させるためのプログラムを格納するメモリを備え、
前記プログラムは、前記第三の計算機からの前記ディスク装置に格納されるファイルへのアクセス状況を記録する部分と、前記アクセス状況に応じて前記ファイルを前記第二の計算機への移送候補とする部分と、前記第二の計算機へ前記ファイルの移送の受け入れの可否を問い合わせる移送許可パケットを送信する部分と、前記移送許可パケットに対する応答パケットを前記第二の計算機から受信する部分と、前記第二の計算機に前記ファイルを移送する部分を備える、情報処理システム。 - 前記メモリは、前記第三の計算機がアクセスするファイルのパスを、前記第三の計算機のアクセス状況を表す情報と対応付けて格納し、
前記プログラムは、前記アクセス状況を表す情報が所定の条件を満たした場合に、当該情報に対応するファイルを移送候補とする部分を備える、請求項１記載の情報処理システム。 - 前記プログラムは、前記ファイルを前記第二の計算機に移送したことを示す移送通知パケットを、前記第二のネットワークへ送信する部分を備える、請求項２記載の情報処理システム。
- 前記第三の計算機は、データとプログラムを格納するメモリを備え、
当該プログラムは、前記移送通知パケットを受信する部分と、当該パケットに応じて前記第二の計算機に対して前記ファイルのアクセスを行う部分を備える、請求項３記載の情報処理システム。 - 前記第一のネットワークは、更に第三のネットワークに接続され、
前記プログラムは、前記第二のネットワークにファイルを移送すべき計算機が存在しなかった場合、前記移送先検索パケットを前記第三のネットワークに送信する部分を備える、請求項１記載の情報処理システム。 - 第一のネットワークに接続される第一の計算機が有するファイルをアクセスし、前記第一のネットワークと通信できる第二のネットワークに接続される第二の計算機であって、
前記第二の計算機は、前記第ニのネットワークと接続するためのインタフェースと、前記第ニの計算機を制御するＣＰＵと、データと前記ＣＰＵを動作させるためのプログラムを格納するメモリを備え、
前記第一の計算機から前記ファイルを移送した先である第三の計算機へのパス名を前記インタフェースから受信した後は、前記パス名を用いて、前記インタフェースから前記ファイルへアクセスする、第二の計算機。 - 前記第三の計算機は、前記第二のネットワークに接続される、請求項６記載の第二の計算機。
- 前記メモリは、前記第一の計算機へのパス名と、前記第三の計算機へのパス名を対応付けて格納しており、
前記ＣＰＵは、前記メモリを参照して、前記第三の計算機への前記パス名を用いて、前記インタフェースから前記ファイルへアクセスする、請求項６記載の第二の計算機。 - 第二の計算機と第三の計算機が属する第二のネットワークと通信できる第一のネットワークに接続され、前記第三の計算機からファイルをアクセスされる第一の計算機であって、
前記第一の計算機は、前記第一のネットワークと接続するための通信インタフェースと、前記第一の計算機の制御を行うＣＰＵと、データを格納するディスク装置と、前記ディスク装置にデータの送受信を行うためのディスクインタフェースと、データと前記ＣＰＵを動作させるためのプログラムを格納するメモリを備え、
前記プログラムは、前記第三の計算機からの前記ディスク装置に格納されるファイルへのアクセス状況を記録する部分と、前記アクセス状況に応じて前記ファイルを前記第二の計算機への移送候補とする部分と、前記第二の計算機へ前記ファイルの移送の受け入れの可否を問い合わせる移送許可パケットを送信する部分と、前記移送許可パケットに対する応答パケットを前記第二の計算機から受信する部分と、前記第二の計算機に前記ファイルを移送する部分を備える、第一の計算機。 - 第一のネットワークに接続される第一の計算機からデータを受信し、前記第一のネットワークと通信できる第二のネットワークに接続される第二の計算機であって、
前記第二の計算機は、前記第二のネットワークと接続するための通信インタフェースと、前記第二の計算機の制御を行うＣＰＵと、データを格納するディスク装置と、前記ディスク装置にデータの送受信を行うためのディスクインタフェースと、データと前記ＣＰＵを動作させるためのプログラムを格納するメモリを備え、
前記プログラムは、前記第一の計算機からファイルの移送の受け入れに関する移送許可パケットを受信する部分と、前記移送許可パケットに対する応答パケットを作成する部分と、前記第一の計算機に前記移送許可パケットを送信する部分を備える、第二の計算機。 - 第一のネットワークに接続される第一の計算機が有するファイルをアクセスし、前記第一のネットワークと通信できる第二のネットワークに接続される第二の計算機が有するメモリに格納されるプログラムであって、
前記プログラムは、前記第一の計算機から前記ファイルを移送した先である第三の計算機へのパス名を前記第ニのネットワークと接続するためのインタフェースから受信した後は、前記パス名を用いて、前記インタフェースから前記ファイルへアクセスする部分を備える、プログラム。 - 第二の計算機と第三の計算機が属する第二のネットワークと通信できる第一のネットワークに接続され、前記第三の計算機からファイルをアクセスされる第一の計算機が有するメモリに格納されるプログラムであって、
前記プログラムは、前記第三の計算機からの前記第一の計算機が有するファイルへのアクセス状況を記録する部分と、前記アクセス状況に応じて前記ファイルを前記第二の計算機への移送候補とする部分と、前記第二の計算機へ前記ファイルの移送の受け入れの可否を問い合わせる移送許可パケットを送信する部分と、前記移送許可パケットに対する応答パケットを前記第二の計算機から受信する部分と、前記第二の計算機に前記ファイルを移送する部分を備える、プログラム。 - 第一のネットワークに接続される第一の計算機からデータを受信し、前記第一のネットワークと通信できる第二のネットワークに接続される第二の計算機が有するメモリに格納されるプログラムであって、
前記プログラムは、前記第一の計算機からファイルの移送の受け入れに関する移送許可パケットを受信する部分と、前記移送許可パケットに対する応答パケットを作成する部分と、前記第一の計算機に前記移送許可パケットを送信する部分を備える、プログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003115183A JP2004318743A (ja) | 2003-04-21 | 2003-04-21 | ファイル移送装置 |
| US10/645,699 US7472143B2 (en) | 2003-04-21 | 2003-08-20 | File migration device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003115183A JP2004318743A (ja) | 2003-04-21 | 2003-04-21 | ファイル移送装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004318743A true JP2004318743A (ja) | 2004-11-11 |
Family
ID=33157075
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003115183A Pending JP2004318743A (ja) | 2003-04-21 | 2003-04-21 | ファイル移送装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7472143B2 (ja) |
| JP (1) | JP2004318743A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007115140A (ja) * | 2005-10-21 | 2007-05-10 | Hitachi Ltd | ストレージシステム、及びストレージスシステムの制御方法 |
| JP2007187513A (ja) * | 2006-01-12 | 2007-07-26 | Oki Electric Ind Co Ltd | 位置推定システム |
| JP2010507876A (ja) * | 2006-10-26 | 2010-03-11 | アリババ グループ ホールディング リミテッド | ネットワークデータストレージシステムおよびそのデータアクセス方法 |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7769722B1 (en) | 2006-12-08 | 2010-08-03 | Emc Corporation | Replication and restoration of multiple data storage object types in a data network |
| US20050125456A1 (en) * | 2003-12-09 | 2005-06-09 | Junichi Hara | File migration method based on access history |
| US7398428B2 (en) * | 2004-09-07 | 2008-07-08 | Hewlett-Packard Development Company, L.P. | Diagnostic tool with ethernet capability |
| JP4451293B2 (ja) | 2004-12-10 | 2010-04-14 | 株式会社日立製作所 | 名前空間を共有するクラスタ構成のネットワークストレージシステム及びその制御方法 |
| US8126856B2 (en) * | 2005-05-26 | 2012-02-28 | Hewlett-Packard Development Company, L.P. | File access management system |
| US20070038697A1 (en) * | 2005-08-03 | 2007-02-15 | Eyal Zimran | Multi-protocol namespace server |
| US20070055703A1 (en) * | 2005-09-07 | 2007-03-08 | Eyal Zimran | Namespace server using referral protocols |
| US20070061465A1 (en) * | 2005-09-15 | 2007-03-15 | Hostway Corporation | Host migration system |
| US7818454B2 (en) * | 2005-09-15 | 2010-10-19 | Hostway Corporation | Host migration system |
| US20070088702A1 (en) * | 2005-10-03 | 2007-04-19 | Fridella Stephen A | Intelligent network client for multi-protocol namespace redirection |
| US8275750B2 (en) * | 2006-11-08 | 2012-09-25 | International Business Machines Corporation | Method to efficiently use the disk space while unarchiving |
| US8706833B1 (en) | 2006-12-08 | 2014-04-22 | Emc Corporation | Data storage server having common replication architecture for multiple storage object types |
| US7818535B1 (en) | 2007-06-30 | 2010-10-19 | Emc Corporation | Implicit container per version set |
| US8285758B1 (en) | 2007-06-30 | 2012-10-09 | Emc Corporation | Tiering storage between multiple classes of storage on the same container file system |
| US7631155B1 (en) | 2007-06-30 | 2009-12-08 | Emc Corporation | Thin provisioning of a file system and an iSCSI LUN through a common mechanism |
| US7694191B1 (en) | 2007-06-30 | 2010-04-06 | Emc Corporation | Self healing file system |
| US9298417B1 (en) * | 2007-07-25 | 2016-03-29 | Emc Corporation | Systems and methods for facilitating management of data |
| US20090150414A1 (en) * | 2007-12-07 | 2009-06-11 | Brocade Communications Systems, Inc. | Detecting need to access metadata during file operations |
| WO2009123614A1 (en) * | 2008-03-31 | 2009-10-08 | Hewlett-Packard Development Company, L.P. | Updating retrieval codes in response to file transfers |
| US7503047B1 (en) * | 2008-04-08 | 2009-03-10 | International Business Machines Corporation | System and method for enhancing the sharing of application libraries between different JVM's and systems with a dynamic relocation based on usage patterns |
| US8676760B2 (en) * | 2008-08-05 | 2014-03-18 | International Business Machines Corporation | Maintaining data integrity in data servers across data centers |
| US7937453B1 (en) | 2008-09-24 | 2011-05-03 | Emc Corporation | Scalable global namespace through referral redirection at the mapping layer |
| US20120124168A1 (en) * | 2009-12-18 | 2012-05-17 | Paul Boerger | Server migration method |
| US8037345B1 (en) | 2010-03-31 | 2011-10-11 | Emc Corporation | Deterministic recovery of a file system built on a thinly provisioned logical volume having redundant metadata |
| US8775732B1 (en) * | 2011-04-29 | 2014-07-08 | Symantec Corporation | Method and system for passing information to disk arrays for efficient storage management |
| US20130124674A1 (en) * | 2011-11-15 | 2013-05-16 | Hitachi, Ltd. | Computer system and data migration method |
| CN102841931A (zh) * | 2012-08-03 | 2012-12-26 | 中兴通讯股份有限公司 | 分布式文件***的存储方法及装置 |
| US9135263B2 (en) * | 2013-01-18 | 2015-09-15 | Sonatype, Inc. | Method and system that routes requests for electronic files |
| US9305071B1 (en) * | 2013-09-30 | 2016-04-05 | Emc Corporation | Providing virtual storage processor (VSP) mobility with induced file system format migration |
| WO2016047096A1 (ja) * | 2014-09-24 | 2016-03-31 | 日本電気株式会社 | アプリケーションサーバ、クラウド装置、記憶媒体アクセス監視方法およびコンピュータ・プログラムが格納されているコンピュータ読み取り可能な記憶媒体 |
| US9697083B2 (en) * | 2014-11-21 | 2017-07-04 | International Business Machines Corporation | Using geographical location information to provision multiple target storages for a source device |
| US11971855B2 (en) * | 2020-05-19 | 2024-04-30 | EMC IP Holding Company LLC | Supporting multiple operations in transaction logging for a cloud-enabled file system |
| CN114466000B (zh) * | 2021-12-22 | 2023-10-10 | 天翼云科技有限公司 | 一种cdn网关回源方法及装置 |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0789332B2 (ja) | 1988-02-02 | 1995-09-27 | 日本電気株式会社 | ファイルのマイグレーション・リコール方式 |
| JPH0391041A (ja) | 1989-09-04 | 1991-04-16 | Nec Corp | ファイルの自動マイグレーション方式 |
| US5544347A (en) * | 1990-09-24 | 1996-08-06 | Emc Corporation | Data storage system controlled remote data mirroring with respectively maintained data indices |
| US5367698A (en) | 1991-10-31 | 1994-11-22 | Epoch Systems, Inc. | Network file migration system |
| JPH06243074A (ja) | 1993-02-18 | 1994-09-02 | Fuji Xerox Co Ltd | ファイルサービスシステム |
| JP3572641B2 (ja) | 1993-09-10 | 2004-10-06 | 住友電気工業株式会社 | ファイルサーバの選択システム |
| US6226785B1 (en) * | 1994-09-30 | 2001-05-01 | Apple Computer, Inc. | Method and apparatus for storing and replaying creation history of multimedia software or other software content |
| US5564037A (en) | 1995-03-29 | 1996-10-08 | Cheyenne Software International Sales Corp. | Real time data migration system and method employing sparse files |
| US5680640A (en) * | 1995-09-01 | 1997-10-21 | Emc Corporation | System for migrating data by selecting a first or second transfer means based on the status of a data element map initialized to a predetermined state |
| US6256675B1 (en) * | 1997-05-06 | 2001-07-03 | At&T Corp. | System and method for allocating requests for objects and managing replicas of objects on a network |
| US6366988B1 (en) | 1997-07-18 | 2002-04-02 | Storactive, Inc. | Systems and methods for electronic data storage management |
| US6026414A (en) * | 1998-03-05 | 2000-02-15 | International Business Machines Corporation | System including a proxy client to backup files in a distributed computing environment |
| US6442601B1 (en) * | 1999-03-25 | 2002-08-27 | International Business Machines Corporation | System, method and program for migrating files retrieved from over a network to secondary storage |
| US6477522B1 (en) | 1999-06-10 | 2002-11-05 | Gateway, Inc. | Dynamic performance based server selection |
| US7143144B2 (en) * | 1999-11-30 | 2006-11-28 | Ricoh Company, Ltd. | System, method and computer readable medium for certifying release of electronic information on an internet |
| US7406106B2 (en) * | 2000-04-07 | 2008-07-29 | Broadcom Corporation | Method of sharing information among a plurality of stations in a frame-based communications network |
| DE10112751B4 (de) * | 2000-11-16 | 2006-01-12 | Fujitsu Ltd., Kawasaki | Gerät und Verfahren zum Einstellen einer Umgebung eines Client in einem Client/Server-System und Programm-Aufzeichnungsmedium dafür |
| US6957433B2 (en) * | 2001-01-08 | 2005-10-18 | Hewlett-Packard Development Company, L.P. | System and method for adaptive performance optimization of data processing systems |
| US6889232B2 (en) | 2001-02-15 | 2005-05-03 | Microsoft Corporation | System and method for data migration |
| US7028079B2 (en) | 2001-05-25 | 2006-04-11 | Lenovo (Singapore) Pte, Ltd. | Method and apparatus for the automatic migration of applications and their associated data and configuration files |
| AU2002322223A1 (en) * | 2001-07-25 | 2003-02-17 | Hyperchip Inc. | Apparatus and method for establishing tunnel routes to protect paths established in a data network |
| US6718435B2 (en) * | 2001-08-14 | 2004-04-06 | International Business Machines Corporation | Method and system for migrating data in a raid logical drive migration |
| US7447731B2 (en) * | 2001-12-17 | 2008-11-04 | International Business Machines Corporation | Method and apparatus for distributed application execution |
| US7178050B2 (en) * | 2002-02-22 | 2007-02-13 | Bea Systems, Inc. | System for highly available transaction recovery for transaction processing systems |
| JP2004280283A (ja) * | 2003-03-13 | 2004-10-07 | Hitachi Ltd | 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法 |
-
2003
- 2003-04-21 JP JP2003115183A patent/JP2004318743A/ja active Pending
- 2003-08-20 US US10/645,699 patent/US7472143B2/en not_active Expired - Fee Related
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007115140A (ja) * | 2005-10-21 | 2007-05-10 | Hitachi Ltd | ストレージシステム、及びストレージスシステムの制御方法 |
| JP2007187513A (ja) * | 2006-01-12 | 2007-07-26 | Oki Electric Ind Co Ltd | 位置推定システム |
| JP2010507876A (ja) * | 2006-10-26 | 2010-03-11 | アリババ グループ ホールディング リミテッド | ネットワークデータストレージシステムおよびそのデータアクセス方法 |
| US8953602B2 (en) | 2006-10-26 | 2015-02-10 | Alibaba Group Holding Limited | Network data storing system and data accessing method |
Also Published As
| Publication number | Publication date |
|---|---|
| US7472143B2 (en) | 2008-12-30 |
| US20040210583A1 (en) | 2004-10-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004318743A (ja) | ファイル移送装置 | |
| KR102301353B1 (ko) | 컨텐츠 중심 네트워크에서 컨텐츠 소유자 및 노드의 패킷 전송 방법 | |
| US11388251B2 (en) | Providing access to managed content | |
| US11194719B2 (en) | Cache optimization | |
| US10230819B2 (en) | Translation of resource identifiers using popularity information upon client request | |
| US7437479B2 (en) | Position identifier management apparatus and method, mobile computer, and position identifier processing method | |
| US8086634B2 (en) | Method and apparatus for improving file access performance of distributed storage system | |
| JP4696089B2 (ja) | 分散ストレージシステム | |
| US20050240574A1 (en) | Pre-fetching resources based on a resource lookup query | |
| US7734820B1 (en) | Adaptive caching for a distributed file sharing system | |
| US7802014B2 (en) | Method and system for class-based management of dynamic content in a networked environment | |
| US8370583B2 (en) | Network memory architecture for providing data based on local accessibility | |
| US6424992B2 (en) | Affinity-based router and routing method | |
| US8073972B2 (en) | System and method for location discovery based on DNS | |
| US20160277497A1 (en) | Facilitating access to remote cloud services | |
| US20160065665A1 (en) | Request routing using a popularity identifier at a dns nameserver | |
| US6760756B1 (en) | Distributed virtual web cache implemented entirely in software | |
| CN101997785A (zh) | 网关***及控制方法 | |
| JPH1185710A (ja) | サーバ装置およびファイル管理方法 | |
| US20120191769A1 (en) | Site-aware distributed file system access from outside enterprise network | |
| US20150106468A1 (en) | Storage system and data access method | |
| JP4573732B2 (ja) | サーバント装置 | |
| US20110282923A1 (en) | File management system, method, and recording medium of program | |
| JP4327869B2 (ja) | 分散ファイルシステム、分散ファイルシステムサーバ及び分散ファイルシステムへのアクセス方法 | |
| US20150019755A1 (en) | Data-centric communications system, node, and data forwarding method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051219 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080812 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080909 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081110 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081202 |