(57)【特許請求の範囲】
【請求項１】
階層構造を持つ複数のディレクトリによって構成され、データを管理するファイルシステムを備えた複数のネットワークストレージ装置を、仮想的な一つのネットワークストレージシステムとしてネットワーク経由で接続されるクライアントからアクセスさせるためのネットワークストレージ仮想化方法において、
前記クライアントから要求されたデータの前記ネットワークストレージにおける格納位置を前記ファイルシステム内で特定する際に、前記クライアント側から指定されるディレクトリの情報を元にlookupコマンドを順次実行して当該ディレクトリのディレクトリハンドラを取得することを繰り返すことにより、前記複数のディレクトリの階層構造を上位から下位に辿るネットワークストレージ仮想化方法であって、
前記lookupコマンドを実行して得られるディレクトリハンドラに現在のディレクトリのパス名のハッシュ値を埋め込んで前記クライアント側にreturnを返し、
当該returnに対してクライアント側から返される更に下位のディレクトリの情報と現在のディレクトリのパス名のハッシュ値を用いて当該下位ディレクトリのlookupコマンドを実行し、もって前記データの格納位置を特定することを特徴とするネットワークストレージ仮想化方法。
【請求項２】
請求項１に記載のネットワークストレージ仮想化方法において、
前記データが前記複数のネットワークストレージ装置にストライピングされて格納されることを特徴とするネットワークストレージ仮想化方法。
【請求項３】
請求項１に記載のネットワークストレージ仮想化方法において、
前記複数のネットワークストレージ装置は、所定のネットワーク装置を介して前記ネットワークに接続され、
当該ネットワーク装置は、前記仮想的な一つのネットワークストレージシステムに対する前記クライアントからのアクセス要求を前記複数のネットワークストレージ装置に転送し、
前記複数のネットワークストレージ装置の各々は、前記転送されたアクセス要求のアクセス対象であるデータのパス名を引数とするハッシュ関数を用いて当該アクセス対象であるデータの格納先が自己のネットワークストレージ装置と一致するか否か判定し、
一致する場合には、前記アクセス要求を処理することを特徴とするネットワークストレージ仮想化方法。
【請求項４】
請求項１に記載のネットワークストレージ仮想化方法において、
前記複数のネットワークストレージ装置は、所定のネットワーク装置を介して前記ネットワークに接続され、
当該ネットワーク装置は、前記仮想的な一つのネットワークストレージシステムに対する前記クライアントからのアクセス要求を前記複数のネットワークストレージ装置のいずれか１つに転送し、
当該アクセス要求を受信したネットワークストレージ装置は、当該転送されたアクセス要求のアクセス対象であるデータのパス名を引数とするハッシュ関数を用いて当該アクセス対象であるデータの格納先が自己のネットワークストレージ装置と一致するか否か判定し、
一致する場合には、前記アクセス要求を処理し、
一致しない場合には、前記ハッシュ関数で特定されるネットワークストレージ装置に、前記アクセス要求を転送することを特徴とするネットワークストレージ仮想化方法。
【請求項５】
複数のネットワークストレージ装置により構成され、ネットワークを介して接続されるクライアントからのアクセス要求を処理するネットワークストレージシステムにおいて、
前記ネットワークストレージ装置は、
データを格納するためのストレージシステムと、
階層構造を持つ複数のディレクトリによって構成され、当該格納するデータを管理するファイルシステムと、
複数のファイルシステムを仮想的に一つに見せるための仮想一元化ファイルシステムとを有し、
前記ファイルシステムは、以下の動作を繰り返して実行することにより前記複数のディレクトリの階層構造を上位から下位に辿り、もってクライアントから要求されたデータの前記ネットワークストレージにおける格納位置を前記ファイルシステム内で特定することを特徴とするネットワークストレージシステム。
（１）前記クライアント側から指定されるディレクトリの情報を元にlookupコマンドを実行して当該ディレクトリのディレクトリハンドラを取得する、
（２）当該取得したディレクトリハンドラに現在のディレクトリのパス名のハッシュ値を埋め込んで前記クライアント側にreturnを返す、
（３）当該returnに対してクライアント側から返される更に下位のディレクトリの情報と前記現在のディレクトリのパス名のハッシュ値を用いて、該更に下位のディレクトリに対するlookupコマンドを実行する。
【請求項６】
複数のネットワークストレージ装置を備え、ネットワークを介して接続されるクライアントから仮想的にひとつのネットワークストレージとしてアクセスさせる機能を提供するネットワークストレージシステムにおけるオブジェクトのハンドル情報生成方法において、
前記クライアント側から指定されるディレクトリの情報を元にlookupコマンドを実行することにより当該ディレクトリのディレクトリハンドラを生成し、
当該ディレクトリのパス名のハッシュ値を生成し、前記ディレクトリハンドラに埋め込み、
当該ハッシュ値を埋め込んだディレクトリハンドラを、前記オブジェクトのハンドル情報として前記クライアント側に返送することを特徴とするオブジェクトのハンドル情報生成方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ネットワークストレージの仮想化方法に関し、特に複数のファイルシステムをひとつに見せるための方法に関する。
【０００２】
【従来の技術】
従来の情報処理システムでは、情報は計算機システムに直接接続されたストレージに格納されていた。ストレージに格納されている情報は直接接続されている計算機を介してのみアクセスすることが許されていたため、他の計算機システムからは前記直接接続されている計算機を経由してデータをアクセスする必要があった。しかしながら、近年のネットワーク技術の発達と格納すべき情報量の飛躍的な増大は情報を処理する計算機システムと情報を格納するストレージシステムの分離を促し、ストレージがネットワークに接続され、複数の計算機システムで共有できるようになってきた。このようなネットワークに接続されるストレージのことをネットワークストレージと呼ぶ。
このようなネットワークストレージの例としては、SAN（Storage  Area  Network）で接続されてブロックアクセスを提供するSANストレージ、IPネットワークやInfiniband等で接続されてファイルアクセスを提供するNAS（Network Attached Storage)、WebアクセスのインタフェースHTTPプロトコルやそれを拡張したプロトコルでのアクセス形態を提供するWebストレージなど、種々のネットワークストレージがある。
ネットワークストレージが普及するにつれ、システム管理者はネットワークに接続された複数のネットワークストレージを管理する必要がでてきた。例えば、格納すべきデータの量が既存のネットワークストレージの最大値を超えてしまうような場合には新たなネットワークストレージを追加し、データの再分配などのシステム再構築を行なう必要がある。ストレージ容量に対する需要の急激な伸びは度重なるシステム再構築を強いることとなり、システム管理コストを膨張させてきた。
システム管理コストを抑制するためには複数のネットワークストレージを計算機システムからは仮想的にひとつに見せ、新たな装置の追加を行なってもシステム全体に影響が及ばないようにするストレージの仮想化技術が必須となっている。このようなストレージの仮想化技術に関しては種々の方式が開発され、提案されている。
例えば、The Zebra Striped Network File System,  Hartman et. al., ACM Transactions on Computer System, vol. 13, No. 3, 1995, pp. 274-310.には、ひとつのファイルを複数のネットワークストレージに分散格納する方式が記載される。ファイルは一定の長さ毎に分割され、ネットワークストレージにラウンド・ロビン方式で順次格納されている。ファイルがどのストレージにどのような順で分散格納されているか集中管理するサーバがあり、ファイルアクセス処理時にはこの管理サーバにファイルの格納位置に関する情報を問い合わせてからデータをアクセスするという特長を有する。すなわち、ファイルを複数のサーバに分散格納させて一つのサーバで集中管理することにより複数のネットワークストレージを仮想的に一つの大きいネットワークストレージに見せる効果を得ている。
また、米国特許第6,029,168号には上記の集中管理サーバ方式と異なる非集中管理サーバ方式によりファイルのストライピングを行なう方法が記載されている。この方式では、ファイル識別子にファイルのストライピング情報が格納されているスタータノード情報を埋め込むことによって、ストライピング情報を複数のネットワークストレージで分散管理している。ファイル識別子にスタータノードが格納されているため、ファイルアクセスの際にはまずスタータノードへアクセスを行ない、そこで、ファイルの格納位置を決定し必要があればアクセスすべきファイルの断片（ブロック）を格納しているサーバへアクセス要求を転送して処理することが特徴となっている。このため、クライアントは当該ファイルについてのアクセスはスタータノードへ要求を発行するだけで良く、ファイルのストライピングによる格納位置を考慮する必要がないという効果を得ている。
【０００３】
【発明が解決しようとする課題】
前記The Zebra Striped Network File Systemに記載のシステムでは、アクセスするファイルの断片を格納するネットワークストレージを決定する際に集中管理サーバに問い合わせる必要があった。従って、ネットワークストレージの台数が増加すると集中管理サーバが隘路となり、システムのスケーラビリティの阻害要因となっていた。
また、米国特許第6,029,168号に記載の非集中管理サーバ方式では、管理サーバが複数のサーバに分散されている点では集中管理サーバの問題点を解決している。しかしながら、該システムではファイルアクセスする際にファイルを一意に特定するファイル名あるいはディレクトリ名とスタータノードが埋め込まれているファイル識別子との変換を分散ディレクトリ等のサーバが行なうことが前提となっており、ファイルの格納場所を管理するサーバ（スタータノード）とファイル名との対応を管理する情報が別途必要となっている。なお、米国特許第6,029,168号にはそのような情報を格納する手段としてとして a "well-known" distributed Directory fileを利用するとの記載がある。また、ファイル識別子にスタータノードの位置が直接埋め込まれるため、新しいネットワークストレージを追加して既存のファイルのスタータノードを新しいネットワークストレージに移動する際には前記分散ディレクトリに格納されているファイル名とファイル識別子との対応情報を書きかえる必要があった。
本発明の一つの目的は、アクセス対象のオブジェクトの論理識別子からそのアクセス対象を格納するネットワークストレージを一意に決定できる複数ネットワークストレージの仮想一元化方法を提供することにある。
本発明の他の目的は、ネットワークストレージの拡張性が高い複数ネットワークストレージの仮想一元化方法を提供することにある。
【０００４】
【課題を解決するための手段】
本発明の特徴は、ファイルシステムではファイルのフルパス名、WebストレージではURLなど、ネットワークストレージに格納するオブジェクトを論理的に識別するオブジェクト識別子のハッシュ値に基づき格納するネットワークストレージを決定する点にある。これにより、オブジェクト識別子と格納するネットワークストレージの対応の管理が排除される。
一つの代表的な例では、クライアントのアクセス要求は仮想化対象のネットワークストレージ群の任意のひとつに通知され、このアクセス要求を受け取ったネットワークストレージがオブジェクト識別子のハッシュ値に基づきその要求のアクセス対象のオブジェクトを格納するネットワークストレージを特定し、アクセス要求を特定したネットワークストレージへと転送して処理を行なう。別の例では、クライアントからのアクセス要求を仮想化対象のネットワークストレージ群の全てに通知し、各ネットワークストレージがオブジェクト識別子のハッシュ値に基づき該アクセス要求を処理すべきネットワークストレージが自装置か否かを判定して自装置が該当する場合に処理を行なう、という方法でクライアントからのアクセス要求を処理する。
サン・マイクロシステムズ社（Sun Microsystems, Inc.）によって開発されたNFS（Network File System）など、ファイルアクセスプロトコルでファイルやディレクトリをアクセスするためのハンドルにファイル名やディレクトリ名などのオブジェクトを論理的に識別する情報が含まれないプロトコルを用いたネットワークストレージの場合には、ハンドルの生成時にファイルの論理的識別子（フルパス名）のハッシュ値を埋め込むことで、ファイルのフルパス名がアクセスハンドルに含まれる場合と同様の方法でアクセス要求を処理するネットワークストレージを決定することができる。
本発明により、アクセス対象のオブジェクトの論理的識別子、例えばファイル名、と該オブジェクトを物理的に格納しているネットワークストレージとの対応表を管理する必要がなくなり、管理サーバを必要としない複数ネットワークストレージの仮想化方法が可能となる。
また、管理サーバが不要なため、ファイルの物理的格納位置の変更が容易になり、動的なネットワークストレージの追加などが容易となる。
更に、管理サーバが不要なため、システムの隘路がなくなりネットワークストレージの拡張性が高くなる。
更に、ファイルの論理的識別子からハッシュ関数により格納位置を算出できるため、アクセス要求を適切なサーバへ転送する処理が高速化される。
【０００５】
【発明の実施の形態】
図１は本発明の実施例を示す図である。クライアント１はネットワークルータ２を介して複数のネットワークストレージ（３，４，５）に接続されている。各ネットワークストレージはクライアント１からのファイルアクセス要求を処理するためのファイルシステム７と該ファイルシステムによってアクセスされるストレージシステム８を有する。また、複数のファイルシステムを仮想的に一つのファイルシステムに見せるための仮想一元化ファイルシステム６を有する。ネットワークルータ２および複数のネットワークストレージ（３，４，５）はクライアントからは仮想的にひとつのネットワークストレージ９として認識される。すなわち、クライアントからはネットワークルータが提供するひとつのネットワークアドレスまたはネットワーク識別名で仮想的に一元化されたネットワークストレージ９を識別する。このような機能を持つネットワークルータとしてクライアント側のネットワークにはひとつのネットワークアドレスを、複数のネットワークストレージ側にはプライベートアドレスをそれぞれ提供し、プライベートアドレスと外部アドレスの変換を行なうルータが適用可能であるが、ひとつの外部アドレスと、複数の内部アドレスを管理できる機能を有するネットワークルータ、負荷分散機、サーバやPCなどの汎用の計算機、ネットワークスイッチなどネットワークルータ以外の装置ももちろん適用可能である。また、ネットワークストレージのひとつがネットワークルータ２の機能を備える構成も可能である。さらに、複数のネットワークストレージが物理的にひとつの装置内に配置されていても良いことは明白である。また、サーバやPCなどの汎用の計算機とネットワークスイッチなどの組み合わせでネットワークルータを構成しても良い。さらに、ネットワークルータ２と各装置の間のネットワークは有線・無線のいかなる形態であっても良い。また、ネットワークルータ２を複数接続して外部との通信の負荷を分散させるたりシステムに冗長度を持たせる構成を取ることも可能である。
図２はクライアント１から見える仮想化一元化されたファイルシステムのイメージである。本実施例では説明を簡単にするため、クライアントから見えるディレクトリツリーとネットワークストレージのディレクトリツリーが同一である場合を示しているが、ネットワークストレージのディレクトリツリーをクライアントのローカルファイルシステムのディレクトリツリーの一部にマウントしてもよい。その場合にはマウントポイント以下の部分がネットワークストレージのディレクトリツリーとなる。なお、本発明ではファイルシステムがファイルを識別する記号としてファイルの階層構造を持つパス名を例として説明しているが、ファイルの識別子が階層構造を持つパス名以外であっても構わない。例えば、ファイル自身に内在するキーワードを識別子としてファイルをアクセスするようなファイルシステムにおいては、識別子として扱うキーワードをパス名と同等に扱うことにより本発明と同等の複数のファイルシステムの仮想化が実現できることは明白である。
本実施例ではネットワークファイルシステムを例として説明しているが、オブジェクトを格納するネットワークストレージであればオブジェクト自身はファイルでなくても良く、Webにおけるページなど、オブジェクトの論理的な識別子を有する全てのオブジェクトを格納するシステムが対象となる。論理的な識別子とはファイルシステムではファイルのパス名、WebストレージではURLなど、ストレージの構成に依存しない上位ソフトウェアから見たオブジェクトの識別子のことを意味する。また、オブジェクトの識別子は必ずしも一意にオブジェクトを特定する必要はなく、複数のオブジェクトをさしていても良い。その場合には同一識別子を持つオブジェクトは同じネットワークストレージに格納される。
本発明では図２で示す仮想的に一元化されたファイルシステムを複数のネットワークストレージ（３，４，５）に分散格納する方法とそのアクセス方法を提供する。各ファイルはファイルのパス名のハッシュ値と分散格納するネットワークストレージの台数を引数とする格納位置決定関数によって一意に決定されるネットワークストレージに格納される。たとえば、本実施例では、ハッシュ関数をパス名を構成する各コンポーネントの文字列の和を２の16乗で割った余りをハッシュ関数とし、格納位置決定関数ｆを
ｆ＝mod（ハッシュ値、ネットワークストレージ台数）
とした場合の例を示している。すなわち、図２の/usr/local/aのファイルのハッシュ値は"usr" "local" "a"の各コンポーネントの文字コードの和
('u'+'s'+'r')+('l'+'o'+'c'+'a'+'l')+('a') = 0x03c6
であり、格納位置決定関数の値は
mod(0x03c6, 3) = 0
となるので、最初のネットワークストレージ３に格納されている。同様に/usr/loca/b, /usr/home/c, /use/d, /usr/bin/eのそれぞれのハッシュ値はそれぞれ0x03c7, 0x0366, 0x01be, 0x258となり、格納位置決定関数ｆの値は1, 0, 2, 1となり、図１に示されるように対応するネットワークストレージにそれぞれ格納される。
本実施例ではハッシュ関数を各コンポーネントの文字列の和としたが、引数の値に対して一意に決定される値を返す他のいかなる関数を用いても同様の実装ができることは明らかである。ここで、一意に決定されるとは、引数の値が同じ時に同じ値を返すということを意味しており、異なる引数に対して異なる値（ユニークな値）を返すという意味ではない。すなわち，異なる２つの引数が同じ値を返しても構わない。また、格納位置決定関数として乗余関数を用いたが、これに関しても、他のいかなる関数を用いても同様の実装ができることは明らかである。本発明ではファイルの格納の冗長化を行なわない場合について述べているが、ファイルの冗長格納を行なう場合には、上記のハッシュ関数あるいは格納関数を複数種類用意して、それぞれの値に応じた格納場所へ対象となるファイルを格納する。従って、引数の値に対して一意に決定される値を返す関数が複数提供される場合や、ひとつの関数が、冗長化を行なう目的で複数の値を返す場合も含まれる。
本発明の最大の特徴は、ファイルのパス名あるいは識別子のみからハッシュ値が計算でき、また、ハッシュ値と分散格納するネットワークストレージの台数のみから格納すべきネットワークストレージの番号が一意に決定できることである。従来の分散ファイルシステムではファイルのパス名あるいは識別子から格納位置を求める際にディレクトリサーバなどに問い合わせを行ない、格納位置情報を求めていたが、本発明ではこの問い合わせが全く不要となる。また、ファイルのパス名あるいは識別子と格納位置のマッピングを示す情報をテーブルとして格納する必要があるため、該テーブルをメンテナンスする必要があったが、本発明では該テーブルは不要であり、一貫性の維持や排他処理、構成変更時のメンテナンスなどのオーバヘッドは発生しない。
また、本実施例では簡単のためファイルのストライピングを行なわない場合について説明を行なっているが、ファイルのストライピングを行なう場合も格納位置決定関数の引数としてファイルのパス名とアクセス位置（あるいはファイルの断片番号）を追加するだけで、同様のシステムが容易に実現可能であることは明らかである。
図３はクライアントからのアクセス要求の処理の流れを示す図である。クライアント１が発行したアクセス要求はネットワークルータ２に送信される（１５）。ネットワークルータは仮想化で一元化すべきストレージに受け取ったアクセス要求をフォワードする（１６）。各ネットワークストレージは受け取った要求の内容とハッシュ関数および格納位置決定関数の値の基づき処理を行ない（１７）、結果をクライアント１にリターンする（１８）。
ネットワークをアクセスするプロトコルの一例としてNetwork File System(NFS)プロトコルがある。NFSプロトコルではファイルやディレクトリをアクセスするためにフルパス名を用いず、LOOKUPコマンド要求で取得するハンドル情報でファイルやディレクトリをアクセスする。本発明では、フルパス名のハッシュ値で格納位置を決定しているため、このハンドルにファイルのフルパス名もしくはハッシュ値を格納する必要が有る。NFSプロトコルではハンドルの実装はネットワークストレージが自由に決定して良いことになっているが、ファイルハンドルの長さに制限がある。そのため、ファイルやディレクトリのフルパス名を格納することが一般にできない。そこで、ハンドルの一部にフルパス名のハッシュ値を格納しておくことによりハンドルがフルパス名を格納できない場合でもハッシュ値による格納位置決定処理を実行できるようにする。なお、NFS以外のプロコルで、ファイルやディレクトリをアクセスする際に用いる識別情報がフルパス名を含む場合にはパス名のハッシュ値を識別情報に含めなくても良い。ファイルやディレクトリをアクセスする際にはアクセス対象を識別できる識別情報が必要である。識別情報にフルパス名が含まれる場合には該フルパス名からハッシュ値を導出することができるのでハッシュ値そのものの保持は任意である。識別情報にフルパス名が含まれないアクセスプロトコルの場合にはアクセスの識別情報がハッシュ値を保持するように改変を行ない、もってファイルの格納位置がアクセスの識別情報から一意に決定できるようにする。いずれにしても、任意のファイルアクセスプロトコルに対して本発明は適用可能である。以下では簡単のためにアクセスプロトコルとしてNFSを例に取りアクセス処理の流れについて説明する。
図４はアクセスに用いるディレクトリハンドル２０およびファイルハンドル２５の構成を示す例である。ディレクトリハンドル２０はディレクトリ識別子２１およびディレクトリパスハッシュ値２２から構成される。ファイルハンドル２５はファイル識別子２２とファイルパスハッシュ値２７から構成される。ディレクトリ識別子およびファイル識別子は従来のハンドルと同様の方法で生成することができるが、ハンドラの長さが固定長の場合には、パスハッシュ値を格納するサイズ分だけ短くする必要がある。図４では、ファイル/usr/local/aをオープンしてオフセット1024から4096バイトのデータを読み込む場合を例に取り説明する。まず、最初にLOOKUPコマンド３０を発行して実行結果３１を得る。実行結果３１には/usrのディレクトリハンドラが含まれており、/usrのディレクトリハンドラにはパスハッシュ値0x015a(='u'+'s'+'r')が埋め込まれている。次にこのディレクトリハンドラを用いて/usr/localのディレクトリをLOOKUPし（３２）、実行結果３３を得る。実行結果３３には/usr/localのディレクトリハンドラが含まれており、/usr/localのディレクトリハンドラにはパスハッシュ値0x0365(='u'+'s'+'r'+'l'+'o'+'c'+'a'+'l')が埋め込まれている。次に/usr/local/aのLOOKUPを行ない（３４）、そのファイルハンドルを得る（３５）。最後に、取得したファイルハンドルを用いてREADコマンドを発行し（３６）、データを読み込む。
NFSプロトコルなどではハンドルとファイルやディレクトリを１対１に対応付けるためにinodeへのポインタなどを用いている。本発明では複数のネットワークストレージにファイルを格納するため、ハンドルにファイルのフルパス名を含まないNFSのようなプロトコルの場合には、ディレクトリの実体とハンドルを１対１に対応付ける為のローカルなマッピングテーブル等が必要となる場合がある。これらに関しては適用するネットワークプロトコルの仕様に応じて適切な手法を実装することができる。
図５はファイルやディレクトリ情報を取得するLOOKUPコマンドの処理の流れを示す図である。LOOKUPコマンドを仮想一元化ファイルシステムが受け付けると（５０）、ディレクトリハンドルの指定の有無をチェックし（５１）、ディレクトリハンドルの指定がある場合には５３の処理に進む。そうでない場合には、ディレクトリハンドルを初期化し、ディレクトリパスハッシュ値を０に初期化する（５２）。次に、ディレクトリハンドルに格納されているディレクトリパスハッシュ値とアクセスするファイル名（またはディレクトリ名）を引数としてハッシュ関数を呼び出し、ハッシュ値を求める（５３）。求めたハッシュ値が自装置が処理すべき値かどうかを格納位置決定関数を用いて判定を行ない（５４）、自装置が処理すべき値でない場合には、要求を破棄する（５５）。自装置が処理すべき値である場合には、当該ファイルをLOOKUPして（５６）、その結果得られたハンドル情報に５３で求めたハッシュ値を埋め込み、（５７）、要求元に結果をリターンする。なお、LOOKUPに失敗した場合にはエラー情報をクライアントにリターンするなどの適切な処理を行なう。エラー処理に関しては適用するファイルアクセスプロトコルの規格に合せて実装する。また、上記ではハンドルにファイルのパス名が含まれない場合を想定してパス名の代わりにハッシュ値をハンドルに埋め込む場合のフローを提示したが、ハンドルにファイルのパス名が含まれている場合には、５３のハッシュ値を求める処理でディレクトリのパス名とファイル名を用いてハッシュ値を計算する。その場合、ハッシュ値をLOOKUPの結果得られたファイルハンドルに埋め込む処理５７は不要となる。
LOOKUPと同様の処理フローとなるコマンドにはCREATE、SYMLINK、MKNOD、REMOVE等が有る。なお，REMOVE処理の場合にはリターン値にファイルハンドルを含まないので、ハッシュ値のハンドラへの埋め込み（５７）に相当する処理は不要である。
図６はファイルを読み込むREADコマンドの処理の流れを示す図である。READコマンドを受け取ると（６０）、ファイルハンドルに格納されているファイルパスハッシュ値を取りだし（６１）、格納位置決定関数を用いてハッシュ値が自サーバの処理すべき値かどうかをチェックし（６２）、該当しない場合には要求を破棄する（６３）。該当する場合には、当該ファイルをREADし（６４）、結果を要求元にリターンする（６５）。本処理においても適用するアクセスプロトコルの規格に合せてエラー発生時の処理を適宜追加する。
READと同様の処理フローとなるコマンドにはWRITE、GETATTR、SETATTR、READLINK、STATFS等が有る。
図７はディレクトリを作成するコマンドMKDIRの処理の流れを示す図である。MKDIRのコマンドを受け取ると（６６）、ディレクトリハンドルの指定の有無をチェックし（６７）、ディレクトリハンドルの指定がある場合には６９の処理に進み、そうでない場合にはディレクトリハンドルの初期化を行ないディレクトリパスハッシュ値を０にセットする（６８）。次にディレクトリハンドルに格納されているディレクトリパスハッシュ値と作成するディレクトリ名を引数としてハッシュ関数を呼び出し、ハッシュ値を求める（６９）。求めたハッシュ値が自装置で処理すべきことを示す値かどうかを格納位置決定関数を用いて判定する（７０）。自装置で処理すべき値でない場合には、MKDIRを実行して指定されたディレクトリを作成し（７１）、その結果をMKDIRを処理すべきネットワークストレージ装置に送信する（７２）。自装置が処理すべきハッシュ値である場合には、MKDIRを実行して指定されたディレクトリを作成し（７４）、他の全てのネットワークストレージ装置からのMKDIR実行結果通知（７３）を受信するまで待つ（７５）。全てのネットワークストレージ装置からの結果を受け取ったら、それが全て成功かどうかをチェックし（７６）、全て成功である場合にはリターンするディレクトリハンドルにハッシュ値を埋め込み（７７）、要求元のクライアントに結果をリターンする（７８）。そうでない場合には、MKDIRに成功した全てのサーバに対して作成したディレクトリを削除するコマンドRMDIRを発行して要求元にエラーをリターンする。RMDIRが失敗したときやその他の個所（例えば７３の通信の送受信）でエラーが発生した場合には、適用するプロトコルの規格に従ったエラー処理を行なう。
RMDIRもMKDIRと同様の処理フローとなる。すなわち、全てのサーバから指定されたディレクトリをREMOVEする。また、一部のサーバがRMDIRに失敗したば場合にはRMDIRに成功したサーバでMKDIRを実行して現状を回復し、エラーリターンさせるなどプロトコルに応じたエラー処理を実装する。
図８はファイル名の変更を行なうRNAMEコマンドの処理の流れを示す図である。REMANEコマンドを受け取ると（８１）、リネーム元のファイルのハッシュ値とリネーム先ファイルのハッシュ値をそれぞれ求め（８２）、リネーム元およびリネーム先のハッシュ値が自ネットネットワークストレージ装置で処理すべき値かどうかを格納位置決定関数に基づき判断する（８３）。リネーム元およびリネーム先が共に自ネットネットワークストレージ装置で処理すべき場合には、自ネットネットワークストレージ装置内でRENAMEコマンドを実行する（８５）。リネーム元が自ネットネットワークストレージ装置、リネーム先が他ネットネットワークストレージ装置である場合には、リネーム先サーバにファイルをコピーし（８６）、コピーが成功したかどうか判定し（８７）、コピーが失敗した場合には要求元にエラーをリターンする（８８）。コピーが成功した場合にはファイルハンドルリダイレクト情報を登録し（８９）、リネーム元ファイルを削除する（９０）。ファイルハンドルリダイレクト情報はリネーム元のファイルハンドルと、リネーム先のファイルハンドラの対を格納しているテーブルで、リネーム前のハンドラを一定時間有効にするためにリネーム前のファイルを格納すべきサーバが一定時間保持する。ハンドラとファイルの実体のマッピングを取る際に、該リダイレクト情報を参照することで、リネームにより格納位置が変更されたファイルに対するアクセスを可能にする事を目的とする。該テーブルに登録されているファイルハンドラはリネーム後のファイルハンドラに自動的に変更されて、当該サーバへのアクセスとして転送される。なお、８３の判定でリネーム元が自サーバの場合には上記処理を行なった後、要求元に結果をリターンする（９１）。それ以外の場合には要求を破棄する（８４）。
図８はRENAMEの対象がファイルである場合の処理フローを示している。RENAMEの対象がディレクトリの場合には、種々の実装方法が実現可能である。例えば、リネーム先のディレクトリをリカーシブに最下層までMKDIRしてから、リネーム元の当該ディレクトリに有るファイルを順次RENAMEする。最後に、リネーム元のディレクトリを最下層までリカーシブにRMDIRする。これ以外にも本発明が適用可能な種々のディレクトリのRENAMEコマンドが実装可能であることは明らかである。
図９はディレクトリ情報を取得するREADDIRコマンドの処理の流れを示す。READDIRコマンドを受け取ると、ディレクトリハンドラのハッシュ値を取りだし（９２）、格納位置決定関数を用いてハッシュ値が自サーバの処理すべき値かどうかをチェックし（９３）、該当しない場合にはREADDIRコマンドを実行して（９５）結果を該READDIRコマンドを実行すべきネットワーックストレージ装置に送信する（９６）。自装置が処理すべきネットワーックストレージ装置に該当する場合には、READDIRコマンドを実行し（９４）、他の全てのネットワーックストレージ装置からREADDIRコマンドの実行結果（９７）を受信するまで待つ（９８）。全てのREADDIRコマンドの結果を受信するとそれらの結果をマージし（９９）、要求元に結果をリターンする（１００）。
本実施例では全てのネットワークストレージが同一のディレクトリツリー構造を有するため、全てのサーバでMKDIRおよびRMDIRは実行され、格納位置決定関数で指定されたひとつのサーバがそれらの実行結果を取りまとめてクライアントに応答する。しかしながら、格納位置決定関数で指定されたひとつのサーバのみでMKDIRやRMDIRを行なう別の実施例も可能である。その場合には、ディレクトリの作成時やファイルの作成時に指定された親ディレクトリが格納位置決定関数で指定される実行サーバに存在しない場合、当該親ディレクトリまでのディレクトリを生成コマンド実行時と同様の方法で生成する必要がある。また、READDIRコマンドなどではディレクトリが存在しないサーバが存在するため、それらに対する処理フローの修正も必要となるが、いずれも容易に実装可能であるのは明らかである。
図１０は、本発明の他の実施例を示す図である。本実施例では各ネットワークストレージ（３，４，５）はクライアントとネットワーク１０１を介して接続されている。クライアントからは全てのネットワークストレージのIPアドレスが見える。また、ネットワークストレージ間はネットワークスイッチ１０２を介して接続しており、ネットワーク１０１に負荷をかけずにコマンドやデータの送受信を行なう。この場合、クライアントはネットワークストレージの任意のひとつに対してアクセス要求を発行する（１０３）。アクセス要求を受け取ったネットワークストレージ４がパス名のハッシュ値に基づき実行すべきネットワークストレージを決定し、この実行すべきネットワークストレージが他のネットワークストレージの場合には、その実行すべきネットワークストレージに対してアクセス要求を転送する（１０４）。転送を受けたネットワークストレージがアクセス要求を処理し（１０５）、その結果をアクセス要求を受け付けたネットワークストレージ４経由でクライアント１にリターンする（１０５、１０６）。なお、アクセス要求のリターンが別サーバから戻ってきても良いのであれば、アクセス要求を実行したネットワークストレージから直接結果を要求元クライアントに送信しても良い（１０８）。インターネットの発行元IPアドレスを書きかえることでアクセス要求受付サーバ経由で結果をリターンするのと同等のことを実現することも容易に可能である。また、ネットワーク１０１の負荷が問題とならないのであれば、ネットワークスイッチ１０２を省略して、サーバ間の通信をネットワーク１０１経由で行なうことも当然可能である。
図１１は、本発明の更に他の実施例を示す図である。本実施例は、図３に示す実施例と同様のハードウェア構成を取る。クライアントから発行されたアクセス要求１１０をネットワークルータ２がグループ内の1台のネットワークストレージ（図１１ではネットワークストレージ４）に転送する。ネットワークルータ２にていずれのネットワークストレージに転送するかを決定する方法は、例えばラウンドロビン等を採用できる。アクセス要求の転送を受けたネットワークストレージは、図１の実施例の各ネットワークストレージと同様な方法で、つまりアクセス対象の論理的な識別子（ファイルのパス名）のハッシュ値に基づき要求を処理すべきネットワークストレージを決定する。処理すべきネットワークストレージが自分であれば要求を処理する。処理すべきネットワークストレージが自分以外であれば（図示のケース）、その処理すべきネットワークストレージに要求を転送する（１１１）。要求を受け取ったネットワークストレージは転送された要求を処理し（１１２）、その結果をクライアントにリターンする（１１１）。なお、リターンする経路は、要求を最初に受け取ったネットワークストレージ経由であっても構わない。
図１２は、ネットワークストレージ１４９のソフトウェア構成の一実施例を示す。図１２では、ネットワークファイルシステム１４２に仮想一元化制御部１４３を組み込み、ハンドラ生成部１４４でシステム全体のグローバルなハンドル１４０を生成する。ハンドルの内部にファイルやディレクトリのフルパスが存在しない場合にはハンドル１４０にパスのハッシュ値１４１を埋め込む。また、仮想一元化制御部１４３は必要に応じてクライアントから受け取ったアクセス要求１４７を他のネットワークストレージに送受信する（１４６）。
図１３は、ネットワークストレージ１４９のソフトウェア構成の他の実施例を示す。図１３では、ネットワークファイルシステム１５６の上位に仮想化ネットワークファイルシステム１５１を置く。仮想化ネットワークファイルシステム１５１は仮想一元化制御部１５２とローカルハンドラ・グローバルハンドラ変換部１５３を有する。本ソフトウェア構成ではネットワークファイルシステム１５６がローカルに生成するローカルハンドラ１５４と他のネットワークストレージと共通に利用するグローバルハンドラ１５０とのマッピングをローカルハンドル・グローバルハンドル変換部１５３で行なう。ローカルハンドル・グローバルハンドル変換部１５３はハンドル変換表１５５を参照してクライアントから指定されたグローバルハンドルをネットワークファイルシステム１５６が利用するローカルハンドルに変換する。仮想一元化制御部１５２は必要に応じて他のネットワークファイルシステムとアクセス要求を送受信する（１５９）。
【０００６】
【発明の効果】
本発明のネットワークストレージの仮想化方式では、オブジェクトの格納位置を該オブジェクトをアクセスする時に用いる論理的な識別子のハッシュ値に基づき格納すべきネットワークストレージを決定することで、オブジェクトの格納位置に関する情報を管理サーバに保持する必要をなくした。これにより、オブジェクトの格納位置に関する情報を管理サーバに問い合わせるための処理コストが削減され、システムのスケーラビリティが向上した。また、ネットワークストレージを追加・削除する際にも管理サーバに対する情報の更新処理が不要となるため、サーバの構成変更が容易となり、運用管理が簡素化される。
【図面の簡単な説明】
【図１】本発明のネットワークストレージの仮想化方式のシステム構成を示す図である。
【図２】クライアントから見たファイルシステムイメージを示す図である。
【図３】本発明のネットワークストレージ仮想化方式の処理の概略を示す図である。
【図４】ハンドラの構成の一実施例およびファイルアクセス処理の例を示す図である。
【図５】  LOOKUP処理の流れを示すフローチャートである。
【図６】  READ処理の流れを示すフローチャートである。
【図７】  MKDIR処理の流れを示すフローチャートである。
【図８】ファイルのRENAME処理の流れを示すフローチャートである。
【図９】  READDIR処理の流れを示すフローチャートである。
【図１０】本発明のネットワークストレージの仮想化方式の他のシステム構成例と処理の流れを示す図である。
【図１１】本発明のネットワークストレージの仮想化方式の更に他のシステム構成例と処理の流れを示す図である。
【図１２】ネットワークストレージのソフトウェア構成の実装例を示す図である。
【図１３】ネットワークストレージのソフトウェア構成の他の実装例を示す図である。
【符号の説明】
１  クライアント
２  ネットワーク装置
３、４、５  ネットワークストレージ
６  仮想一元化ファイルシステム
７  ローカルファイルシステム
８  記憶装置
９  仮想化されたネットワークストレージ
１０  ネットワーク
１１  クライアントから見た仮想化されたファイルシステムイメージ
２０  ディレクトリハンドラ
２５  ファイルハンドラ
１０１  ネットワーク
１０２  ネットワーク装置
１４２  ネットワークファイルシステム
１４３  仮想一元化制御部
１４４  ハンドラ性西部
１４５  ローカルファイルシステム
１５０  グローバルハンドラ
１５１  仮想化ネットワークファイルシステム
１５２  仮想一元化制御部
１５３  ローカルハンドラ・グローバルハンドラ変換部
１５４  ローカルハンドラ
１５５  ハンドラ変換表
１５６  ネットワークファイルシステム
１５７  ハンドラ生成部。
【図１】
0004154893.tif 000002
【図２】
0004154893.tif 000003
【図３】
0004154893.tif 000004
【図４】
0004154893.tif 000005
【図５】
0004154893.tif 000006
【図６】
0004154893.tif 000007
【図７】
0004154893.tif 000008
【図８】
0004154893.tif 000009
【図９】
0004154893.tif 000010
【図１０】
0004154893.tif 000011
【図１１】
0004154893.tif 000012
【図１２】
0004154893.tif 000013
【図１３】
0004154893.tif 000014