JP2006185463A

JP2006185463A - ゲートウェイ装置

Info

Publication number: JP2006185463A
Application number: JP2006042697A
Authority: JP
Inventors: Yoji Nakatani; 洋司中谷; Masaaki Iwasaki; 正明岩嵜; Yutaka Enko; 豊円光
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2006-02-20
Filing date: 2006-02-20
Publication date: 2006-07-13
Anticipated expiration: 2023-03-13
Also published as: JP4005102B2

Abstract

【課題】クライアント側の変更を行うことなく、ＮＦＳやＣＩＦＳ等の従来プロトコルを用いて分散ファイルシステム（ＤＦＳ）にアクセスを行うこと。
【解決手段】ＤＦＳサーバ２に従来プロトコルを受け付け、それに対応する処理をＤＦＳに対して行うゲートウェイ部２５を設ける。ゲートウェイ部２５は、ＮＦＳやＣＩＦＳ等のファイルシステムに存在するディレクトリ構造をエミュレートする。また、ＤＦＳが追記型ファイルシステムである場合に、更新処理を新しい世代の作成処理に変換し、参照処理を世代管理されているファイル群の最新世代へのアクセスに変換する。そして、ゲートウェイ部２５は、ＤＦＳ処理部２６を介してファイルにアクセスする。
【選択図】図４

Description

本発明は、分散ファイルシステム（ＤＦＳ：ディストリビューティッドファイルシステム）に含まれるゲートウェイ装置に係り、特に、ネットワーク上の複数のサーバにファイルを分散して格納することにより、１つのファイルシステムを構成する分散ファイルシステムに含まれるゲートウェイ装置に関する。

ネットワークファイルシステムとして、ＮＦＳやＣＩＦＳ（コモンインターネットファイルシステム）と呼ばれるＵＮＩＸ（登録商標）等のＯＳ上に構築されたファイルシステムが知られている。これらのファイルシステムは、１つのサーバによって１つのファイルシステムを構成する集中型のファイルシステムであり、ファイルの実体がある特定のサーバ上に存在する。クライアントからファイルに対してアクセスを行う場合、各クライアントは、それぞれのプロトコルを用いてまずこのファイルの存在するサーバにアクセスを行う。そして、クライアントは、サーバ上でファイルを特定するために、ディレクトリ構造を用いる。

これに対して、OceanStore等のＤＦＳは、クライアントがファイルにアクセスを行う場合、サーバやパス名を特定する代わりに、GUIDというシステムで一意に付けられた識別子を用いている。ＤＦＳの場合、ファイルは、ネットワーク上に存在する複数のＤＦＳサーバ上のいずれかにその実体が存在する。ファイルの実体は、１つのサーバだけが持っている必要はなく、複製として他のサーバ上に存在してもよい。また、ファイルの実体は、そのファイル全体を１つのＤＦＳサーバで保持する必要はなく、ファイルが幾つかの部分に分割され、１つのＤＦＳサーバにはその分割された１つの部分（フラグメントと呼ぶ）のみを存在させ、他のフラグメントを他のＤＦＳサーバ上に存在させてもよい。

ＤＦＳにおけるファイルにアクセスするクライアントは、ファイルに対する参照、書き込みを行う場合、ネットワーク上のいずれか１つのサーバに対し、GUIDを指定してファイルを特定してアクセスする。

なお、本発明に近い従来技術として、ストレージサーバがあらゆる種類のユーザデータへの接続を担う通信インタフェースを備えたシステムが、例えば、特許文献１等に記載されて知られている。
特開２０００−３３９０９８号公報

ＤＦＳは、ＮＦＳやＣＩＦＳといったネットワークファイルシステムと異なる特性を持つため、ＤＦＳのファイルにアクセスを行うためには、専用のＤＦＳプロトコルを用いてアクセスを行わなければならない。このため、ＮＦＳやＣＩＦＳといったプロトコルのみを使用する従来のクライアントは、ＤＦＳのファイルに対してアクセスを行うことが不可能であり、従来から用いていたプログラムを改良する等、クライアント側をＤＦＳに対応させる変更を行う必要があった。

本発明の目的は、前述した点に鑑み、クライアント側の変更を行うことなく、従来プロトコルを用いてＤＦＳのファイルにアクセスを行うことを可能とした分散ファイルシステムに含まれるゲートウェイ装置を提供することにある。

本発明によれば前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムにおいて、分散してファイルを格納している複数のＤＦＳサーバをネットワーク上に備え、前記複数のＤＦＳサーバの少なくとも１つが、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることにより達成される。

また、前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いてアクセス可能な分散ファイルシステムの分散してファイルを格納している分散ファイルシステムサーバにおいて、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスするゲートウェイ部を備えて構成されることにより達成される。

さらに、前記目的は、集中型のファイルシステムにアクセスを行うためのプロトコルを用いて、分散ファイルシステムにアクセスを行う分散ファイルシステムへのアクセス方法において、集中型のファイルシステムにアクセスを行うためのプロトコルを分散ファイルをアクセス可能なプロトコルに変換して分散ファイルにアクセスすることにより達成される。

本発明によれば、クライアント側の変更を行うことなく、ＮＦＳやＣＩＦＳ等の従来プロトコルを用いてＤＦＳ上のファイルにアクセスを行うことができる。

以下、本発明によるゲートウェイ装置の実施形態を図面により詳細に説明する。

図１は本発明の一実施形態によるゲートウェイ装置を含む分散ファイルシステムの構成例を示すブロック図である。図１において、１はネットワーク、２はＤＦＳサーバ、３はＤＦＳクライアント、４はＮＦＳクライアント、５はＣＩＦＳクライアントである。

図１に示す本発明の一実施形態による分散ファイルシステム（ＤＦＳ）は、ネットワーク１と、ネットワーク１に接続された複数のＤＦＳサーバ２と、ＤＦＳ用のプロトコルを用いてネットワーク１上のファイルシステムにアクセスを行うＤＦＳクライアント３と、ＮＦＳやＣＩＦＳといったネットワーク１上の１つのファイルサーバにより実現されたファイルシステムにアクセスを行うための従来プロトコルでアクセスを行う従来プロトコルクライアントであるＮＦＳクライアント４及びＣＩＦＳクライアント５とにより構成される。

図１に示すＤＦＳにおいて、ネットワーク１上のＤＦＳクライアント３は、専用のＤＦＳプロトコルを用いて１つのＤＦＳサーバ２に対してアクセスを行って、ファイルに対する参照や書き込みを行う。ＤＦＳ上のファイルには、システム内で一意に識別できる番号であるGUIDという識別子が付けられており、参照時にＤＦＳクライアント３からファイルを特定するために用いられる。ファイルに対するGUIDは、ファイルの書き込み時に、ＤＦＳサーバ２によって一意に割り当てられ、ＤＦＳクライアント３に書き込みの応答として知らされる。

詳述すれば、ＤＦＳクライアントは、ファイルに対する参照を行う場合、ネットワーク上のいずれか１つのＤＦＳサーバ２に対し、GUIDを指定してファイルを特定してアクセスする。アクセスされたＤＦＳサーバ２は、自サーバ上にファイルの実体が存在しない場合、ファイルの実体が存在する他のＤＦＳサーバ２に対して問い合わせを行い、データを集めてファイルの実体を自ＤＦＳサーバ上に構築することにより、クライアントに対してアクセスを可能とさせる。

また、ＤＦＳクライアントは、ファイルの書き込みを行う場合、１つのＤＦＳサーバに対して書き込みのデータを送信する。書き込みの応答として、クライアントは、サーバからGUIDを受け取る。書き込んだファイルに対するアクセスは、このサーバから受け取ったGUIDを用いて行う。

ＤＦＳの場合、同一のファイルの実体が複数のＤＦＳサーバ上に存在することがある。このような状況で、クライアントが一度書き込まれたデータの内容を変更する更新書き込みを行った場合、各ＤＦＳサーバでファイルのデータの一貫性を保証するのが難しい。このため、ＤＦＳの中には、GUIDで指定されるファイルへの書き込みを一度だけ行い、更新書き込みを存在させず、一度書き込んだ後は参照のみを可能とするようにしたものがある。このような特性のファイルシステムを追記型ファイルシステムと呼ぶ。

追記型ファイルシステムの場合、更新書き込みに当たるファイルの内容の変更は、新たなファイルの世代への書き込みに当たり、その書き込み、すなわち、新たな世代に対して、新たなGUIDが割り振られて行われることとなる。そして、これらの一連の世代はファイル群として管理される。

図１に示す本発明の実施形態によるＤＦＳは、前述したような追記型のファイルシステムであり、一度書き込みを行い、GUIDを割り当てられたファイルに対して内容の更新を行うことができないものとする。その代わりに、図１に示すＤＦＳは、ファイルには世代が存在し、ファイルに対する更新書き込みに当たる処理が、新しい世代のファイルを作成することに相当する。各世代には、別のGUIDが割り当てられるが、世代の異なるファイルの集まりはファイル群として管理される。このファイル群に対しても一意に識別可能なファイル群識別子が割り当てられる。そして、ファイル群識別子と世代とを示す世代番号を指定することによりファイルを識別するGUIDを得ることができる。

図２はファイル群識別子と世代番号とからGUIDを求める方法の一例を説明する図である。図２に示すように、GUIDとして、GUIDの内上位のビットをファイル群識別子６１とし、残りの下位のビットを世代番号６２としたものを用いる。図２に示す例は、１つの例であり、GUIDを別の方法で求めるようにしてもよい。

従来プロトコルクライアントであるＮＦＳクライアント４及びＣＩＦＳクライアント５は、ＤＦＳのプロトコルではない従来のネットワークファイルシステムのプロトコルを用いてファイルにアクセスを行う。通常、これらの従来プロトコルクライアントは、ファイルにアクセスを行う場合、すでに説明したように、ファイルを特定するためにディレクトリ構造を用いる。

図３は従来プロトコルクライアントが用いるディレクトリ構造について説明する図であり、図３を参照して、ディレクトリの構造について説明する。図３の中では、ディレクトリを実線で囲んだ四角で表し、ファイルを破線で囲んだ四角で表している。

全てのディレクトリは、ルートディレクトリ４１（“／”で示される）の配下に属す木構造で定義される。そして、全てのファイルは、この木構造のディレクトリのいずれかのディレクトリ（複数であってもよい）に属することになる。このような木構造のディレクトリは、１つのディレクトリ内のファイルに対して、一意に名前（ファイル名）を付けることができる形となっている。このため、ファイルを特定する場合には、ファイルの属するディレクトリを示すパス名とそのファイルのファイル名とを指定すればよいことになる。例えば、図３に示すファイル４５は、/dira/dira2/dira22/file0001 という形で特定することができる。従って、クライアントは、ファイルへの参照や更新といったアクセスを行う場合、そのファイルの存在するサーバに対してパス名とファイル名とを指定してファイルを特定し、その後にそのファイルの参照や更新の要求を行うことになる。

本発明の実施形態は、クライアント側に新たなソフトウェアを組み込む等の変更を不要とし、ＮＦＳやＣＩＦＳといった従来プロトコルクライアントがＤＦＳのファイルにアクセスを行うことを可能としており、次に、そのためのＤＦＳサーバの構成を説明する。

図４はＤＦＳサーバの構成を示すブロック図、図５はゲートウェイ部の構成を示すブロック図である。図４、図５において、２１はＤＦＳ制御部、２２はディスクドライブ、２３は主メモリ、２４はＯＳ、２５はゲートウェイ部、２６はＤＦＳ処理部、２７はディスクドライブ処理部、２８はＣＰＵ、２９はＨＤＤ、３１は従来プロトコル処理部、３２はＤＦＳアクセス部、３３はディレクトリ管理部である。

ＤＦＳサーバ２は、図４に示すように、サーバ全体の処理を実行するＣＰＵ２８と、主メモリ２３と、ファイルを格納するディスクを備えるディスクドライブ２２と、主メモリ２３に展開して使用されるＯＳ、アプリケーション等を格納するＨＤＤ２９とを備えて構成される。主メモリ２３内には、ＯＳ２４とＤＦＳ制御部２１とが構成され、また、ＤＦＳ制御部２１は、ゲートウェイ部２５と、ＤＦＳ処理部２６と、ディスクドライブ処理部２７とにより構成される。

ＤＦＳ制御部２１は、ＣＰＵ２８上でＤＦＳ機能を提供するプログラムが動作することによりＤＦＳのサーバとしての機能を果たす。そして、ＤＦＳ制御部２１は、ゲートウェイ部２５、ＤＦＳ処理部２６、ディスクドライブ処理部２７の処理により、ネットワーク１を介してクライアント（ＮＳＦクライアント４、ＣＩＳＦクライアント５等の従来プロトコルクライアント及びＤＦＳクライアント３）や、他のＤＦＳサーバ２からの要求に対して処理を行う。

ＤＦＳ処理部２６は、ＤＦＳプロトコルによる要求を受け付け、その要求に従ってディスクドライブ処理部２７や他のＤＦＳサーバ２に対して処理要求を行い、その結果から応答を作成して要求元に返す。

ゲートウェイ部２５は、ＮＦＳやＣＩＦＳといった従来プロトコルのネットワークファイルシステムに対するのと同一の要求をＮＦＳクライアントやＣＩＦＳクライアントから受け付け、その要求に従った処理を必要に応じて他の処理部に要求を行って処理した後、要求に対する処理の結果をＮＦＳクライアントやＣＩＦＳクライアントクライアントに応答として返す。

前述により、ＤＦＳサーバ２は、従来プロトコルクライアントからの要求に対して、従来プロトコルのファイルサーバと同様にアクセスを受け、同様に、応答することが可能となる。

ゲートウェイ部２５は、全てのＤＦＳサーバ２上に存在する必要はなく、従来プロトコルのクライアントからのアクセスポイントとなりうるＤＦＳサーバ２上にのみ存在すればよい。すなわち、ゲートウェイ部２５は、従来プロトコルのクライアントからアクセスが行われるＤＦＳサーバにのみ必要となる。このため、通常のＤＦＳクライアント３からアクセスを行う場合、ゲートウェイ部２５は必要ではない。

ゲートウェイ部２５は、図５に示すように、従来プロトコル処理部３１と、ＤＦＳアクセス部３２と、ディレクトリ管理部３３とにより構成される。

従来プロトコル処理部３１は、ＮＦＳクライアント、ＣＩＦＳクライアントからの従来プロトコルを受け付け、従来プロトコルに合った応答を返す処理を行う処理部である。この従来プロトコル処理部３１は、受け付けるプロトコル毎に存在し、対応するプロトコルの内容を判断し、要求に応じて他の処理部に処理の要求を行う。

ＤＦＳアクセス部３２は、従来プロトコル処理部３１からの要求を受け付け、ＤＦＳ制御部２１内のＤＦＳ処理部２６との橋渡しを行う処理部である。すなわち、ＤＦＳアクセス部３２は、従来プロトコル処理部３１からの要求に応じて、ＤＦＳに対する要求を作成し、ＤＦＳ処理部２６を介してＤＦＳのファイルにアクセスを行うための処理部である。

ディレクトリ管理部３３は、従来プロトコルのファイルシステムが持っているディレクトリ構造上のファイルとＤＦＳでのファイル識別子であるGUIDとの対応を管理するための処理部である。従来プロトコルによるファイルの指定は、そのファイルが存在するディレクトリを示すパス名とディレクトリ内で一意のファイル名とにより行われる。これに対し、ＤＦＳによるファイルの指定は、GUIDというシステム内で一意である識別子によって行われる。ＤＦＳは、従来プロトコルでのディレクトリに当たる構造を持っている場合、その構造を使用することにより、従来ファイルシステムのファイルとGUIDとの対応を取ることが可能である。しかし、ＤＦＳの中には、ディレクトリに当たる構造を有しないシステムも存在する。すなわち、このディレクトリに当たる構造を有しないＤＦＳは、GUIDのみで全システム内でのファイルを一意に認識することができるため、ファイルのパスに当たる構造を必要としない。

このようなディレクトリ構造を持たないＤＦＳは、従来プロトコルでアクセスを行うことを可能とするために、ディレクトリ構造のパスで指定されるファイルとGUIDとの対応を取るための仕組みが必要である。これを行うディレクトリ管理部３３は、ディレクトリ構造のパスで指定されるファイルとGUIDとの対応を取るための仕組みを提供するものである。

ディレクトリ管理部３３は、従来プロトコルからのディレクトリ操作やディレクトリ情報の読み出し要求に対する処理を行う。このため、ディレクトリ管理部３３は、従来プロトコルのファイルシステムが持っているディレクトリ管理情報と同等のディレクトリ管理情報を持つ。

図６はディレクトリ管理情報５０の構造を説明する図である。ディレクトリ管理情報５０は、複数のエントリ５１により構成されている。そして、エントリ５１は、図３により説明したディレクトリまたはファイル毎に存在する。

各エントリ５１は、そのディレクトリまたはファイルが属するディレクトリである親ディレクトリのエントリへのポインタであるp_parent５２と、そのエントリ５１がディレクトリの場合、そのディレクトリに属するディレクトリまたはファイルの１つへのポインタであるp_subdir５３と、同一のディレクトリのエントリ同士を指すポインタである p_child５４と、ディレクトリまたはファイルの名前を格納するf_name５５とを有する。また、エントリ５１がファイルの場合、ＤＦＳ上でそのファイルを識別するファイル群識別子がf_id５６に格納される。このディレクトリ管理情報５０の各エントリ５１は、p_parent５２、p_subdir５３、 p_child５４の３種類のポインタによりディレクトリ構造に対応した構造に作成されている。そのため、パスに指定されたディレクトリのエントリについてポインタを順にたどっていくことにより目的のファイルのエントリ５１にたどり着くことが可能である。そして、そのエントリ５１には、ファイル群識別子が格納されているため、従来プロトコルのファイルシステムで指定するパス名とファイルから、ＤＦＳのファイル群識別子を求めることが可能である。

すなわち、いま、図６の最上段に示すエントリが、図３に示すルートエントリであるとすると、図６の中段に示すエントリは、図３に示すディレクトリdira、dirb、file1 等に相当し、最上段に示すエントリのp_subdir５３がディレクトリdiraに相当する中段右側のエントリを指し示し、この中段右側のエントリの p_child５４がディレクトリdirbに相当する中段右側のエントリを指し示す。同様に、ディレクトリdiraに相当する中段右側のエントリのp_subdir５３がディレクトリdira1 に相当する下段のエントリを指すことになる。

従って、従来クライアントからのパス名とそのファイルのファイル名とが、図３で説明したように、例えば、/dira/dira2/dira22/file0001 と指定されたとき、ディレクトリに従って、順にエントリ５１を辿っていくことにより、ディレクトリまたはファイルの名前を格納するf_name５５に指定されたファイル名を持つエントリを探すことができ、これにより、ファイル群識別子f_id５６を得ることができる。

前述したようなディレクトリ管理情報５０へのファイルの登録は、次のような場合に行われる。１つ目は、従来プロトコルでファイルを作成する場合である。この場合、パス名とファイル名とが指定されてファイルが作成されるので、従来プロトコル処理部３１は、それに合わせてエントリを作成し、ディレクトリ管理情報５０のパス名に当たる位置にエントリを追加すればよい。２つ目は、ＤＦＳプロトコルでファイルを作成する場合である。この場合、そのままではディレクトリ管理情報５０が作成されないため、従来プロトコルからアクセスを行うことができない。そのため、ＤＦＳで作成したファイルに従来プロトコルからアクセスを行いたい場合、ＤＦＳ処理部２６は、ゲートウェイ部２５に対してディレクトリへの登録要求を行う必要がある。この登録要求は、ＤＦＳ処理部２６からパス名、ファイル名及び登録するファイルのファイル群識別子を指定してゲートウェイ部２５に行われる。

また、前述のディレクトリ管理情報５０は、システム内の各ＤＦＳサーバ２に存在するゲートウェイ部同士で通信する等により共有することができる。これにより、各アクセスポイントから同一のファイルシステムとしてアクセスを行うことが可能となる。または、各ＤＦＳサーバ２のそれぞれのゲートウェイ部２５が別個のディレクトリ管理情報５０を持つようにすることができ、これにより、それぞれのアクセスポイントで異なるファイルシステムとして見せることも可能である。

図７は従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを参照するときの処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）従来プロトコルで、あるディレクトリ内のファイルの参照を行う場合、従来プロトコルクライアント４または５は、ファイルのディレクトリ位置を示すパスとファイル名とを指定してファイルを特定し、そのファイルに対する参照を行うためのアクセスを行う。

（２）従来プロトコル処理部３１は、前述のようなファイルを特定した参照要求を受けた場合、ディレクトリ管理部３３に問い合わせを行い、ファイル群識別子を得ることになる。ディレクトリ管理部３３は、従来のファイルシステムでディレクトリを１階層ずつたどるのと同様に、ディレクトリ管理部３３の持つディレクトリ管理情報５０のエントリについて順にポインタをたどって指定のファイルのエントリにたどり着く。そして、そのエントリから指定されたファイル名のファイル群識別子を得て、従来プロトコル処理部３１に返す（ステップ８１）。

（３）従来プロトコル処理部３１は、GUIDを得るためにファイル群識別子の最新世代番号をＤＦＳアクセス部３２に対して問い合わせる。ＤＦＳアクセス部３２は、ＤＦＳのプロトコルを使用することにより、ファイル群識別子を管理する他のＤＦＳサーバ２に問い合わせる等の方法により最新の世代番号を求め、従来プロトコル処理部３１に返す（ステップ８２）。

（４）従来プロトコル処理部３１は、ステップ８１、８２で得たファイル群識別子と世代番号とからGUIDを求める（ステップ８３）。

（５）従来プロトコル処理部３１は、ステップ８３で求めたGUIDを使用してＤＦＳアクセス部３２に対してGUIDの読み出し要求を発行する。この要求を受けたＤＦＳアクセス部３２は、ＤＦＳプロトコルを使用してＤＦＳに対して要求を発行し読み出し要求に対するデータを得る（ステップ８４）。

（６）従来プロトコル処理部３１は、ステップ８４で、ＤＦＳアクセス部３２が読み出したデータを応答として、参照要求を行ったクライアントに返す（ステップ８５）。

図８は従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを更新するときの処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）従来プロトコルで、あるディレクトリ内のファイルの更新を行う場合、従来プロトコルクライアント４または５は、ファイル参照時と同様に、ファイルのディレクトリ位置を示すパスとファイル名とを指定してファイルを特定し、そのファイルに対する更新を行うためのアクセスを行う。

（２）従来プロトコル処理部３１は、前述のようなファイルを特定して更新要求を受けた場合、受け取った要求が分割されて行われる要求の２つ目以降の要求であるか否か（これについての詳細は後述する）、すなわち、すでに更新中のデータに対する更新か否かを判定する（ステップ９１）。

（３）ステップ９１の判定で、すでに更新中のデータに対する更新ではなかった場合、従来プロトコル処理部３１は、ディレクトリ管理部３３に問い合わせを行い、ファイル群識別子を得ることになる。そのため、従来プロトコル処理部３１は、参照処理の場合と同様に、ディレクトリ管理部３３にファイル群識別子を問い合わせる。更新書込みの場合、既に存在するファイルに対する書込みであるため、ディレクトリ管理テーブルにエントリが存在する。参照のときと同様に、このエントリを求めることで、ファイル群識別子を得ることができる。また、ファイルの新規作成の場合、新規に作成されるファイルに対するエントリは存在しない。この場合、ファイルの作成要求時に、ディレクトリ管理情報５０にエントリを作成して登録すると共に、ＤＦＳ処理部２６に対してもファイル作成要求を発行し、ＤＦＳ処理部２６からファイル群識別子を得る処理を行う必要がある。その後は、新しく作成したファイルに対して、更新時と同様に後述するステップ９５からの処理を行い、データの書込みを行えばよい（ステップ９２）。

（４）ファイル群識別子を得た後、ファイルの更新内容を書き込むために、ファイル識別子の指すファイル群に新しい世代を作成する必要がある。このために、従来プロトコル処理部３１は、ステップ９３で、ＤＦＳアクセス部３２に対して新世代作成の要求発行を依頼する（ステップ９３）。

（５）ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に対して新世代を登録し、得た世代番号を応答として従来プロトコル処理部３１に返す。従来プロトコル処理部３１は、この応答の世代番号とファイル群識別子からGUIDを得ることができる（ステップ９４）。

（６）従来プロトコルは、ファイルへの一連の更新でも、１度の処理要求で行われることは限らない。例えば、ＮＦＳでは設定によりサイズの変更が可能ではあるが、通常、更新要求は、８ＫＢ単位という決まった大きさ毎のファイルの更新処理として行われ、８ＫＢを越える更新を行う場合、複数の更新要求に分割されて行われる。例えば、２４ＫＢの更新を行いたいような場合、３つの８ＫＢの更新に分割されて行われることとなる。このような分割されて行われる更新要求毎に新たな世代番号が作成されるのを防ぐため、一旦ファイルの更新を開始すると、その更新が終了するまでファイルが更新中であることを記憶しておく必要がある。このため、従来プロトコル処理部３１は、更新を開始したファイルを後述するファイル監視テーブルに登録する（ステップ９５）。

（７）ステップ９１の判定で、すでに更新中のデータに対する更新であった場合、従来プロトコル処理部３１は、後述するファイル監視テーブルからGUIDを得る（ステップ９６）。

（８）従来プロトコル処理部３１は、ステップ９５の処理で、ファイル監視テーブルへの登録の後、または、ステップ９６の処理処理で、ファイル監視テーブルからGUIDを得た後、ステップ９７で、GUIDを指定して更新要求のデータの書き込みをＤＦＳアクセス部３２に依頼する。ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に対して書き込みの要求を行う（ステップ９７）。

（９）書き込み終了後、従来プロトコル処理部３１は、ＤＦＳ処理部２６からの応答をＤＦＳアクセス部３２を介して受け取り、従来プロトコルクライアントに対して更新要求の完了の応答を返す（ステップ９８）。

図９はファイル監視テーブルの構造を説明する図である。このテーブル７０の各エントリは、更新中のファイルに対応する。エントリの内容は、ファイルを識別するための情報７２と、書き込み中のファイルの世代を表す世代番号７３からなる。ファイルを識別するための情報７２として、この図９ではディレクトリ情報のエントリへのポインタとしてp_dentryを用いている。

受け取った要求が分割されて行われる要求の２つ目以降の要求であるか否かは、ファイル監視テーブル７０に登録されている情報を調べることにより知ることができ、従来プロトコル処理部３１は、２つ目以降の要求である場合、新たに世代を作成しないようにする。このために、図８により説明した処理において、従来プロトコル処理部３１は、更新要求を受け取った場合、ステップ９１の処理で、ファイル監視テーブル７０を調べ、既に更新中のファイルに対する更新要求であるか否かをチェックしている。そして、更新中でない場合、前述したように、ステップ９２に進み、新世代を作成してデータの書き込みを行うことになる。また、既に更新中であった場合、ステップ９６で、ファイル監視テーブル７０からGUIDを得て、そのGUIDに対してステップ９７で、データの書き込み要求を行う。

ゲートウェイ部２５は、前述したようにしてファイルの更新要求を処理することが可能であるが、作成した新しい世代の登録を完了させるために、この世代への更新の終了をＤＦＳ処理部２６に通知する必要がある。このために、ゲートウェイ部２５は、従来プロトコルクライアントから従来プロトコルで送られてくる一連の更新要求の終了を監視する必要がある。

この一連の更新要求の終了を示すトリガは、それぞれのプロトコルにより異なる。例えば、ＣＩＦＳのように、ファイルに対して操作を行うときにオープンし、終了するときにクローズを行うような、ファイル操作中の状態を持つプロトコルである場合、操作終了のクローズ要求がこの更新要求の終了を示すトリガに当たる。これに対し、ＮＦＳは、ファイルのオープンやクローズに当たる操作がなく、ファイルが操作中であるか否かを示す状態を持たない。このようなプロトコルの場合、別のトリガで操作の終了を判断する必要がる。

この場合のトリガとしては複数の場合が考えられる。１つは、更新要求が到着する時間間隔である。従来プロトコルクライアントは、ゲートウェイ部２５に対して一連の更新を分割して発行するが、通常、分割された１つの更新要求が終了するとすぐに次の更新要求を発行する。このため、ゲートウェイ部２５は、更新要求が到着する時間間隔を監視し、ある一定時間以上次の更新要求が到着しない場合に、一連の更新要求が終了したとみなすことができる。また、別のトリガとしてコミットの要求が考えられる。例えば、ＮＦＳのバージョン３以降のものは、更新を行ったファイルの内容をディスクに反映させる方法としてコミットというコマンドが用意されている。コミットの発行契機は、特に規定されているわけではないが、通常、あるまとまった意味のある更新が終了した場合に発行される。このため、ゲートウェイ部２５は、このコミットの要求が到着した場合に一連の更新要求が終了したとみなすことができる。但し、コミットは、更新の終了時に必ず発行されるとは限らないので、このコミットのみをトリガとすると更新の終了を認識することができない場合があるので、先に説明した時間監視と組み合わせて用いる必要がある。

前述のようなトリガを監視して新しい世代作成の終了を判断する方法は、本来の一連の更新の終了以前にトリガだと認識し世代作成を終了してしまう可能性がある。例えば、一定時間をトリガとしている方法は、ネットワーク１の状態等の理由により次の更新要求の到着が遅れることにより、本来引き続いて行われている更新を終了と判断してしまう場合がある。しかし、このような場合でも、余計に世代が追加されてしまうだけで、ファイルの更新内容が失われなければ特に問題はない。一度途切れたと判断して世代作成を終了してしまった後、更新要求を受け取った場合、また新たに世代を作成してその世代に書き込みを行えばよい。

図１０は世代作成終了時のゲートウェイ部２５での処理動作を説明するフローチャートであり、次に、これについて説明する。

ゲートウェイ部２５は、ステップ１０１で、前述したような更新終了のトリガ発生を待ち、トリガ発生時に処理を開始する。更新終了のトリガ発生があると、ステップ１０２で、従来プロトコル処理部３１は、ファイル監視テーブル７０を参照し、作成中の世代のGUIDを得る。ステップ１０３で、このGUIDに対して、ＤＦＳアクセス部３２は、ＤＦＳ処理部２６に更新終了の要求を発行する。ＤＦＳ処理部２６での更新終了の処理が完了後、ステップ１０４で、従来プロトコル処理部３１は、ファイル監視テーブル７０から当該エントリを削除し、ファイルに対する更新中の状態を解除する。

前述のようにして、ゲートウェイ部２５は、従来プロトコルを用いるクライアント４、５からのＤＦＳのファイルに対するアクセスが可能である。

前述した本発明の実施形態による各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができる。

前述で説明した実施形態は、ＤＦＳとして追記型のファイルシステムを前提として説明したが、本発明は、追記型でないＤＦＳに対しても適用することが可能である。この場合、ファイルの世代という考えはなく、ファイルが更新されてもGUIDの値は変化しない。そのため、ディレクトリ管理情報５０のf_id５６にファイル群識別子の代わりに直接ファイルのGUIDを持つようにすればよい。そして、図７におけるファイルの参照時のフローでは、ステップ８１でGUIDを得ることができ、ステップ８２とステップ８３とは不要となる。同様に、図８に示すファイルの更新時のフローでは、ステップ９２でGUIDを得ることになり、世代作成のステップ９３とGUIDを得るステップ９４とは不要となる。

また、前述した本発明の実施形態は、ゲートウェイ部２５をＤＦＳサーバ２内に内蔵させるとして説明したが、本発明は、ゲートウェイ部２５をＤＦＳサーバ２内に実装しなくてもよい。例えば、他の実装位置として、ネットワーク１上にゲートウェイ部２５の処理を行うゲートウェイサーバを持つ場合や、従来プロトコルクライアント４や５内に組み込むことが考えられる。

図１１は本発明の他の実施形態による分散ファイルシステムの構成例を示すブロック図である。図１１において、１１０はゲートウェイサーバであり、他の符号は図１の場合と同一である。

図１１に示す例は、前述で説明したゲートウェイ部２５をネットワーク１上に設けたゲートウェイサーバ１１０として備えた例である。この場合、従来プロトコルクライアント４や５は、ゲートウェイサーバ１１０に対してアクセスを行うことになる。そして、ゲートウェイサーバ１１０は、ＤＦＳサーバ２に対して、ＤＦＳプロトコルを用いてアクセスを行う。ゲートウェイサーバ１１０は、ゲートウェイ部２５と同等の処理を行う。

前述したゲートウェイ部２５のＤＦＳアクセス部３２は、ＤＦＳ処理部２６と連携して処理を行っていたが、図１１に示す例の場合、ＤＦＳサーバ２と別のサーバ上にゲートウェイ部の機能が実装されるため、前述した連携した処理をおこなうことが不可能となる。その代わりに、図１１に示す例のシステムは、ゲートウェイサーバ１１０内に設けられるＤＦＳアクセス部３２がＤＦＳクライアントとなり、ＤＦＳプロトコルを使用してＤＦＳサーバ２に要求を行うことにより同等の処理を行うことが可能である。

また、従来プロトコルクライアントに組み込む方法としては、例えば、ＮＦＳのプロトコル処理部にこのゲートウェイ部２５の機能を組み込むことが考えられる。この場合、上位のＮＦＳを使用するプログラムは、ＮＦＳのプロトコルを用いて処理を行って、ゲートウェイ部２５の機能がＮＦＳのプロトコルをＤＦＳプロトコルに変換し、ネットワーク１上ではＤＦＳのプロトコルを用いてＤＦＳサーバ２にアクセスを行うこととなる。

前述した本発明の実施形態によれば、ＮＦＳやＣＩＦＳ等の従来プロトコルのファイルシステムに存在するディレクトリ構造をエミュレートし、ディレクトリ構造上でファイルの存在する位置を示すパス名とファイルの名前であるファイル名とによりアクセスを行う方式を、ＤＦＳでのファイル識別子であるGUIDによるアクセスに変換することにより、従来プロトコルを使用してＤＦＳ上のファイルに対するアクセスを行うことができる。

また、本発明の実施形態によれば、ＤＦＳが追記型のファイルシステムである場合、従来プロトコルの更新処理を新しい世代の作成処理に変換することにより、参照時には、世代管理されているファイル群から最新の世代のファイルを求め、そのファイルのデータにアクセスを行うことが可能となる。

本発明の一実施形態によるゲートウェイ装置を含む分散ファイルシステムの構成例を示すブロック図である。ファイル群識別子と世代番号とからGUIDを求める方法の一例を説明する図である。従来プロトコルクライアントが用いるディレクトリ構造について説明する図である。ＤＦＳサーバの構成を示すブロック図である。ゲートウェイ部の構成を示すブロック図である。ディレクトリ管理情報５０の構造を説明する図である。従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを参照するときの処理動作を説明するフローチャートである。従来プロトコルを使用してＤＦＳのファイルにアクセスしてファイルを更新するときの処理動作を説明するフローチャートである。ファイル監視テーブルの構造を説明する図である。世代作成終了時のゲートウェイ部２５での処理動作を説明するフローチャートである。本発明の他の実施形態による分散ファイルシステムの構成例を示すブロック図である。

符号の説明

１ネットワーク
２ＤＦＳサーバ
３ＤＦＳクライアント
４ＮＦＳクライアント
５ＣＩＦＳクライアント
２１ＤＦＳ制御部
２２ディスクドライブ
２３主メモリ
２４ＯＳ
２５ゲートウェイ部
２６ＤＦＳ処理部
２７ディスクドライブ処理部
２８ＣＰＵ
２９ＨＤＤ
３１従来プロトコル処理部
３２ＤＦＳアクセス部
３３ディレクトリ管理部
１１０ゲートウェイサーバ

Claims

クライアント計算機とファイルサーバとに接続されるゲートウェイ装置であって、
前記クライアント計算機に接続され、前記クライアント計算機から第１の形式のプロトコルに基づいた第１の形式のファイルアクセスリクエストを受信する第１の手段と、
前記ファイルサーバと接続され、前記ファイルサーバに対して第２の形式のプロトコルに基づいた第２の形式のファイルアクセスリクエストを送信する第２の手段と、
前記第１及び第２の手段と接続される処理部と、
前記処理部に接続されるメモリとを有し、
前記第１のプロトコルに基づく前記第１の形式のファイルアクセスリクエストは、アクセスされるファイルが含まれるディレクトリを示すパス名と、前記ディレクトリ内で一意であって、前記ファイルを示すファイル名とを含み、
前記第２のプロトコルに基づく前記第２の形式のファイルアクセスリクエストは、前記ファイルサーバ内で一意であって前記ファイルを示すファイルＩＤを含み、
前記メモリは、前記パス名及び前記ファイル名並びに前記ファイルＩＤの対応関係に関する情報を格納し、
前記第１の手段が、前記クライアント計算機から、第１のファイルにデータを書き込むことを指示する、前記第１のファイルに対応する前記パス名と前記ファイル名の第１の組とを含み前記第１の形式のプロトコルに従う第１のコマンドを受信した場合、前記処理部は、前記第１のファイルが前記ファイルサーバに既に存在しているかどうか確認し、
前記第１のファイルが未だ前記ファイルサーバに存在しない場合、前記処理部は、第１のファイルＩＤが割り当てられた前記第１のファイルの生成を前記ファイルサーバに指示する、前記第２の形式のプロトコルに従う第２のコマンドを前記ファイルサーバに送信し、
前記第１のファイルが既に前記ファイルサーバに存在している場合、前記処理部は、第２のファイルＩＤが割り当てられ、前記第１のファイルの更新された内容を含む第２のファイルの生成を前記ファイルサーバに指示する、前記第２の形式のプロトコルに従う第３のコマンドを前記ファイルサーバに送信し、
前記第１のファイルＩＤと前記第２のファイルＩＤとは異なることを特徴とするゲートウェイ装置。
前記第１の手段と前記第２の手段とは同一であることを特徴とする請求項１記載のゲートウェイ装置。
前記第１の形式のプロトコルは、ＮＦＳまたはＣＩＦＳであることを特徴とする請求項２記載のゲートウェイ装置。
前記制御部は、前記第１の組、前記第１のファイルＩＤ及び前記第２のファイルＩＤの対応関係を前記メモリに格納することを特徴とする請求項３記載のゲートウェイ装置。
前記第１のコマンドは、複数のコマンドからなるコマンドシーケンスであり、
前記制御部は、前記コマンドシーケンスの最新のコマンドを前記第１の手段が受信してから一定の時間が経過したかどうかを確認することにより、前記コマンドシーケンスの最終のコマンドを特定することを特徴とする請求項４記載のゲートウェイ装置。
前記第２のファイルが前記ファイルサーバに作成された後、前記第１の手段が、前記クライアント計算機から、前記第１のファイルに対応する前記第１の組を含み、前記第１のファイルの読み出しを指示する、前記第１の形式のプロトコルに従う第４のコマンドを受信した場合、前記制御部は、前記第２のファイルＩＤを含み、前記第２のファイルに格納された前記第１のファイルの更新内容を該ゲートウェイ装置に送信することを前記ファイルサーバに指示する、前記第２の形式のプロトコルに従う第５のコマンドを前記ファイルサーバに送信することを特徴とする請求項２記載のゲートウェイ装置。
クライアント計算機とファイルサーバとに接続されるゲートウェイ装置であって、
前記クライアント計算機及び前記ファイルサーバとネットワークを介して接続され、前記クライアント計算機から第１の形式のプロトコルに基づいた第１の形式のファイルアクセスリクエストを受信し、前記ファイルサーバに対して第２の形式のプロトコルに基づいた第２の形式のファイルアクセスリクエストを送信する手段と、
前記手段に接続される処理部と、
前記処理部に接続されるメモリとを有し、
前記第１の形式のファイルアクセスリクエストは、アクセスされるファイルが含まれるディレクトリを示すパス名と、前記ディレクトリ内で一意であって、前記ファイルを示すファイル名とを含み、
前記第２の形式のファイルアクセスリクエストは、前記ファイルサーバ内で一意であって前記ファイルを示すファイルＩＤを含み、
前記メモリは、前記パス名及び前記ファイル名並びに前記ファイルＩＤの対応関係に関する情報を格納し、
前記手段が、前記クライアント計算機から、第１のファイルを作成することを指示する、前記第１のファイルに対応する前記パス名と前記ファイル名との第１の組を含み前記第１の形式のプロトコルに基づく第１のコマンドを受信した場合、前記処理部は、第１のファイルＩＤが割り当てられた前記第１のファイルの生成を前記ファイルサーバに指示する、前記第２の形式のプロトコルに従う第２のコマンドを前記ファイルサーバに送信し、
前記第１のコマンドの処理後、前記手段が、前記クライアント計算機から、前記第１のファイルの内容を更新することを指示する、前記第１のファイルに対応する前記パス名と前記ファイル名の前記第１の組を含み前記第１の形式のプロトコルに従う第３のコマンドを受信した場合、前記処理部は、第２のファイルＩＤが割り当てられ、前記第３のコマンドで指示された前記第１のファイルの更新内容が含まれる第２のファイルの生成を前記ファイルサーバに指示する、前記第２の形式のプロトコルに従う第４のコマンドを前記ファイルサーバに送信し、
前記第１のファイルＩＤと前記第２のファイルＩＤとは異なることを特徴とするゲートウェイ装置。
前記手段には、前記クライアント計算機に接続され、前記クライアント計算機から前記第１の形式のプロトコルに基づいた前記第１の形式のファイルアクセスリクエストを受信する第１の手段と、前記ファイルサーバと接続され、前記ファイルサーバに対して前記第２の形式のプロトコルに基づいた前記第２の形式のファイルアクセスリクエストを送信する第２の手段とが含まれていることを特徴とする請求項７記載のゲートウェイ装置。
前記第１の形式のプロトコルは、ＮＦＳまたはＣＩＦＳであることを特徴とする請求項８記載のゲートウェイ装置。
前記制御部は、前記第１の組、前記第１のファイルＩＤ及び前記第２のファイルＩＤの対応関係を前記メモリに格納することを特徴とする請求項９記載のゲートウェイ装置。
前記第１のコマンドは、複数のコマンドからなるコマンドシーケンスであり、
前記制御部は、前記コマンドシーケンスの最新のコマンドを前記手段が受信してから一定の時間が経過したかどうかを確認することにより、前記コマンドシーケンスの最終のコマンドを特定することを特徴とする請求項１０記載のゲートウェイ装置。
前記第２のファイルが前記ファイルサーバに作成された後、前記手段が、前記クライアント計算機から、前記第１のファイルに対応する前記第１の組を含み、前記第１のファイルの読み出しを指示する、前記第１の形式のプロトコルに従う第５のコマンドを受信した場合、前記制御部は、前記第２のファイルＩＤを含み、前記第２のファイルに格納された前記第１のファイルの更新内容を該ゲートウェイ装置に送信することを前記ファイルササーバに指示する、前記第２の形式のプロトコルに従う第６のコマンドを前記ファイルサーバに送信することを特徴とする請求項７記載のゲートウェイ装置。