JP6221717B2 - ストレージ装置、ストレージシステム及びデータ管理プログラム - Google Patents

Description

本発明は、ストレージ装置、ストレージシステム及びデータ管理プログラムに関する。

従来のスタンドアロンストレージ装置では、装置モデル毎に性能限界があり、業務負荷が高くなったり、単一装置の容量限界に至ったりした際には、上位モデルにアップグレードするか、別個の複数装置にサービスを分ける必要があった。

しかし、アップグレードや複数装置へのサービスの分割はユーザの利便性を阻害するものであり、近年ストレージ装置に求められるデータ量の増加等を背景としてスケールアウト型ストレージシステムが求められている。

スケールアウトＳＡＮ（Storage Area Network）装置はブロックがアクセス単位であることから、ＳＡＮ装置では、複数のストレージ装置でユーザの要求を処理することは容易であり、スケールアウト型ストレージが比較的普及してきている。

一方、スケールアウトＮＡＳ（Network Attached Storage）装置は一貫性のあるネームスペースを複数のストレージ装置で維持する必要があるために、ＮＡＳ装置では、単純に複数のストレージ装置でユーザの要求を並列処理することはできない。スケールアウトＮＡＳ装置はユーザに対して単一のネームスペースのファイルシステムを提供する必要があり、スケールアウトＮＡＳ装置には、ファイルシステムのメタデータ管理方式の違いにより複数の実装方式が存在する。

図１３及び図１４は、スケールアウトＮＡＳ装置における従来の実装方式を説明するための図である。図１３は、ジャンクションによる複数ボリュームの内部マウントによる実装を説明するための図である。図１３において、各ノード８１〜８４は、ストレージ装置であり、独立したＲＡＩＤ（Redundant Arrays of Inexpensive Disks）及びファイルシステムを有する。また、ネットワークで接続された複数のノード８１〜８４が１つのストレージシステムを構成している。

Ａ〜Ｅは、ボリュームと呼ばれる記憶領域であり、ユーザのファイルは、ボリュームの中に作られる。ノード８１は、ボリュームＡ及びＤを有し、ノード８２は、ボリュームＣを有し、ノード８３は、ボリュームＥを有し、ノード８４は、ボリュームＢを有する。

ストレージシステムは、ジャンクションポイントにおいて各ボリュームをマウントすることにより、ユーザからストレージシステムが単一ネームスペースとして見えるようにする。ここで、ジャンクションポイントとは、図１３に示すようにボリュームを階層構造で接続したとき、下の階層のボリュームを上の階層のボリュームに接続するポイントである。例えば、ボリュームＢには、ボリュームＤ及びボリュームＥをボリュームＢの下に接続するジャンクションポイントがある。

図１４は、単一のネームスペースコンテナによる実装を説明するための図である。図１４において、各ノード９１〜９４は、ストレージ装置であり、ネットワークで接続され、１つのストレージシステムを構成している。

Ｄ₁〜Ｄ₅は、ファイルコンテナと呼ばれる記憶領域であり、ユーザのファイルは、ファイルコンテナの中に作られる。ノード９１は、ファイルコンテナＤ₁及びＤ₄を有し、ノード９２は、ファイルコンテナＤ₃を有し、ノード９３は、ファイルコンテナＤ₅を有し、ノード９４は、ファイルコンテナＤ₂を有する。

また、ノード９４は、ネームスペースコンテナＮＳを有する。ＮＳは、ファイルの名前とファイルを有するファイルコンテナとを対応付けて記憶し、ストレージシステム全体のファイル名を管理する。例えば、ＮＳは、ファイル₁はＤ₁に含まれ、ファイル₂はＤ₄に含まれ、ファイル₃はＤ₃に含まれることを記憶する。

これらの２つの実装方式の他にも、複数ストレージ装置を有するストレージシステムが、単一のネームスペースと単一のファイルコンテナを提供し、複数のストレージ装置に跨ってデータをストライピングする実装方式もある。

また、別々のＮＡＳシステムによって提供される複数のファイルシステムを統合して、単一の「グローバル」ネームスペースにし、統合されたネームスペースをＮＡＳクライアントに提供する従来技術がある（例えば、特許文献１参照）。

また、複数のファイルシステムを仮想化して１つのファイルシステムとしてアクセスを可能としたネットワークストレージシステムにおいて、複数のファイルシステムのストレージ資源の使用制限を統合的に行う従来技術がある（例えば、特許文献２参照）。

特開２００８−１５９０２７号公報 特開２００６−９２３２２号公報

ジャンクションによる複数ボリュームの内部マウントによる実装には、スケールアウト前のアーキテクチャをほぼそのまま利用でき、ボリューム単位で特定のノードがファイルを占有管理するのでスケールアウト化におけるオーバーヘッドが少ないという利点がある。一方、この実装には、ボリューム単位という大きな粒度でしかファイルをノードに割り当てることができないという問題がある。

また、単一のネームスペースコンテナＮＳによる実装には、ファイル単位でノードにファイルを割り当てることができるという利点があるが、ＮＳにファイルの記憶ノードを問い合わせるオーバーヘッドがあるという問題がある。

本発明は、１つの側面では、ファイル単位でノードにファイルを割り当てることができ、かつ、ＮＳにファイルの記憶ノードを問い合わせるオーバーヘッドをなくすことができるストレージシステムを提供することを目的とする。

本願の開示するストレージ装置は、１つの態様において、ストレージシステムを構築する他のストレージ装置とともにデータを記憶する。前記ストレージ装置は、前記ストレージシステムが記憶するデータの階層構造に関する階層構造情報を他のストレージ装置と分担した個所について記憶する階層構造情報記憶部を有する。また、前記ストレージ装置は、データを識別するデータ識別子と該データを所有するストレージ装置を識別する装置識別子とを対応付けた所有装置情報を前記階層構造情報記憶部が分担して記憶する個所について記憶する所有装置情報記憶部を有する。また、前記ストレージ装置は、前記分担した箇所について前記階層構造情報記憶部と前記所有装置情報記憶部が記憶する情報に基づいて管理し、残りの箇所について管理を分担する前記他のストレージ装置とともに当該ストレージシステムが記憶するデータを管理する管理部を有する。

１実施態様によれば、ファイル単位でノードにファイルを割り当てることができ、かつ、ＮＳにファイルの記憶ノードを問い合わせるオーバーヘッドをなくすことができる。

図１は、実施例に係るノードが所有する情報を説明するための図である。 図２は、実施例に係るストレージシステムの構成を示す図である。 図３は、ｉノードテーブルの一例を示す図である。 図４は、ノード管理テーブルの一例を示す図である。 図５は、管理部の機能構成を示す図である。 図６は、ディレクトリ情報のキャッシュを説明するための図である。 図７は、ノード間でのファイルの移動を説明するための図である。 図８は、ファイル作成処理のフローを示すフローチャートである。 図９は、ファイル読み込み処理のフローを示すフローチャートである。 図１０は、ファイル更新処理のフローを示すフローチャートである。 図１１は、ファイルの移動を伴うファイル更新処理のフローを示すフローチャートである。 図１２は、複数ノードによるファイルの共同所有を説明するための図である。 図１３は、ジャンクションによる複数ボリュームの内部マウントによる実装を説明するための図である。 図１４は、単一のネームスペースコンテナによる実装を説明するための図である。

以下に、本願の開示するストレージ装置、ストレージシステム及びデータ管理プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

まず、実施例に係るノードが所有する情報について説明する。図１は、実施例に係るノードが所有する情報を説明するための図である。図１に示すように、ストレージシステム１は、プロトコルネットワーク２で接続された複数のノード１０を有する。

ノード１０は、ファイルを記憶する記憶領域を有するストレージ装置である。プロトコルネットワーク２は、ユーザがストレージシステム１を利用する場合に使用する端末装置であるクライアント２０とストレージシステム１を接続するネットワークである。なお、ここでは、「ノード１」、「ノード２」及び「ノード３」の３台のノード１０と、１台のクライアント２０を示すが、ストレージシステム１は任意の台数のノード１０及びクライアント２０を有することができる。

ストレージシステム１は、全体で１つのファイルシステム及びネームスペースを提供する。ネームスペースツリー２１は、ファイルシステムに含まれるディレクトリ及びファイルの構成を示すツリーであり、○はディレクトリ又はファイルを示し、リンクはディレクトリ間又はディレクトリとファイルとの間の親子関係を示す。

各ノード１０は、ネームスペースツリー２１の一部であるネームスペースブランチ２１ａの情報を有し、全ノード１０が有するネームスペースブランチ２１ａを集めるとネームスペースツリー２１が得られる様にネームスペースツリー２１の情報を分担して記憶する。

各ノード１０は、ネームスペースブランチ２１ａのディレクトリ又はファイルに対応付けて、ディレクトリの情報又はファイルの情報を記憶するノード１０を識別する番号を記憶する。例えば、「ノード１」は、ルートディレクトリ２１ｂに対応付けて、ルートディレクトリ２１ｂの情報を記憶するノード１０の番号として「１」、「２」及び「３」を記憶する。また、「ノード１」は、ルートディレクトリ２１ｂの子のディレクトリ２１ｃに対応付けて、ディレクトリ２１ｃの情報を記憶するノード１０の番号として「１」及び「２」を記憶する。また、「ノード１」は、ディレクトリ２１ｃの子のファイル２１ｄに対応付けて、ファイル２１ｄの情報を記憶するノード１０の番号として「１」を記憶する。

同様に、「ノード２」は、ルートディレクトリ２１ｂの情報を記憶するノード１０の番号、ルートディレクトリ２１ｂの子のディレクトリ２１ｃ及びディレクトリ２１ｅの情報を記憶するノード１０の番号を記憶する。また、「ノード２」は、ディレクトリ２１ｃの子のファイル２１ｆの情報を記憶するノード１０の番号を記憶する。

同様に、「ノード３」は、ルートディレクトリ２１ｂの情報を記憶するノード１０の番号、ルートディレクトリ２１ｂの子のディレクトリ２１ｅの情報を記憶するノード１０の番号を記憶する。また、「ノード３」は、ディレクトリ２１ｅの子のファイル２１ｇの情報を記憶するノード１０の番号を記憶する。

そして、例えば、クライアント２０からファイルアクセス要求を受けたノード１０は、ネームスペースブランチ２１ａの情報をルートからファイルアクセス要求のパスと一致するところまで辿る。そして、ファイルアクセス要求を受けたノード１０は、ファイルアクセス要求で指定されたファイルを所有している場合には、ファイルアクセス要求を実行する。一方、所有していない場合には、ファイルアクセス要求を受けたノード１０は、ファイルアクセス要求のパスと一致する最後のディレクトリに対応付けられた他の番号のノード１０にファイルアクセス要求を送信する。

例えば、図１において、ネームスペースツリー２１のファイル２２に対するアクセス要求を「ノード１」が受け取ると、「ノード１」は、ネームスペースブランチ２１ａの情報をルートから辿り、アクセス要求のパスと一致するディレクトリ２１ｃを特定する。ここで、「ノード１」は、ファイル２２の情報を所有していないことがわかり、また、「ノード２」がディレクトリ２１ｃの情報を所有することがわかる。そこで、「ノード１」は、「ノード２」にアクセス要求を送る。

このように、ノード１０は、ネームスペースツリー２１の一部であるネームスペースブランチ２１ａの情報を有する。そして、ノード１０は、ネームスペースブランチ２１ａのディレクトリ又はファイルに対応付けて、ディレクトリの情報又はファイルの情報を記憶するノード１０を識別する番号を記憶する。そして、ノード１０は、アクセス要求の対象ファイルを所有していない場合に、ネームスペースブランチ２１ａのディレクトリに対応付けられた番号のノード１０にアクセス要求を送信する。したがって、ノード１０は、アクセス要求の対象ファイルを所有していない場合に、ＮＳにファイルの記憶ノードを問い合わせる必要がなく、問合せにともなうオーバーヘッドをなくすことができる。

次に、実施例に係るストレージシステム１の構成について説明する。図２は、実施例に係るストレージシステム１の構成を示す図である。図２に示すように、ストレージシステム１では、複数のノード１０は、プロトコルネットワーク２以外に、ノード間ネットワーク３で接続される。ノード間ネットワーク３は、例えば、ユーザリクエストの転送やノード１０間のファイルの移動など、ノード１０間通信に使用される。

ノード１０は、プロトコルインタフェース１１と、ノード間インタフェース１２と、ＣＰＵ（Central Processing Unit）１３と、メモリ１４と、不揮発メモリ１５と、ＲＡＩＤ１６とを有する。

プロトコルインタフェース１１は、プロトコルネットワーク２を介してクライアント２０と通信するためのインタフェースである。ノード間インタフェース１２は、ノード間ネットワーク３を介して他のノード１０と通信するためのインタフェースである。

ＣＰＵ１３は、メモリ１４に記憶されたプログラムを実行する中央処理装置である。メモリ１４は、プログラム、演算の途中結果、ＲＡＩＤ１６が記憶するデータ等を記憶するＲＡＭ（Random Access Memory）である。不揮発メモリ１５は、ノード１０に故障が発生したときにメモリ１４が記憶するデータを保存するフラッシュメモリである。

ＲＡＩＤ１６は、データを記憶する記憶装置であり、データ保存領域３０を有する。また、ＲＡＩＤ１６は、ＲＡＩＤ１６が記憶するデータを管理する管理プログラム４０を記憶する。管理プログラム４０は、メモリ１４にロードされ、ＣＰＵ１３により実行されることにより、ＣＰＵ１３に、ＲＡＩＤ１０のデータを管理する管理部としての機能を持たせることができる。

データ保存領域３０は、ユーザデータを記憶するとともにユーザデータの管理に使われるメタデータを、ｉノードテーブル記憶部３１やノード管理テーブル３２などに記憶する。

ｉノードテーブル記憶部３１は、複数のｉノードテーブル３１ａを記憶する記憶部である。各ｉノードテーブル３１ａは、１つのディレクトリに含まれる直接の子供のディレクトリ又はファイルの情報を記憶する。

図３は、ｉノードテーブル３１ａの一例を示す図である。図３に示すように、ｉノードテーブル３１ａは、直接の子供のディレクトリ又はファイル毎に、参照先ｉノードと、ファイル名又はディレクトリ名と、属性情報と、所有ノードとを記憶する。

参照先ｉノードは、直接の子供のディレクトリに対応するｉノードテーブル３１ａの記憶先を示す情報である。参照先ｉノードにより、ネームスペースツリー２１の階層構造情報が表わされる。

ファイル名又はディレクトリ名は、直接の子供がファイルである場合にはファイルの名前であり、直接の子供がディレクトリである場合にはディレクトリの名前である。属性情報は、データの書き込みが可能か否かなどの情報である。所有ノードは、参照先ｉノードに対応するディレクトリの情報又はファイルの情報を所有するノード１０の番号である。

例えば、「ＡＡＡ」をディレクトリ名とすると、名前が「ＡＡＡ」であるディレクトリは、対応するｉノードの記憶先が「ｘｘｘｘｘ２」であり、属性情報が「ｘｘｘ２」であり、ディレクトリの情報を所有するノード１０の番号は「２」と「３」である。

このように、ディレクトリ及びファイルに対応させてディレクトリの情報又はファイルの情報を所有するノード１０の番号をｉノードテーブル３１ａが記憶する。したがって、ノード１０は自分が所有しないファイル情報及びディレクトリ情報を所有するノード１０を特定してユーザのアクセス要求を転送することができ、ＮＳに転送先を問い合わせるオーバーヘッドをなくすことができる。

ノード管理テーブル３２は、ノード１０に関する情報を記憶するテーブルである。図４は、ノード管理テーブル３２の一例を示す図である。図４に示すように、ノード管理テーブル３２は、ノード１０毎に、ノード番号と、総容量と、空き容量と、性能指標と、ＣＰＵ負荷率とを記憶する。

ノード番号は、ノード１０を識別する番号である。総容量は、ノード１０が記憶するデータの最大容量である。空き容量は、データを記憶するために残されている領域の容量である。性能指標は、ノード１０がデータを処理する性能を示す値である。ＣＰＵ負荷率は、ＣＰＵ１３の負荷状態を示す値である。なお、空き容量及びＣＰＵ負荷率は、各ノード１０が例えば１分などの一定時間間隔でポーリングして他のノード１０に通知することで、全ノード１０で共有される。

例えば、番号が「１」であるノード１０は、記憶するデータの最大容量が「１００ＴＢ」であり、データを記憶するために残されている領域の容量が「５０ＴＢ」であり、処理性能を示す値が「２」であり、ＣＰＵ１３の負荷状態は「２０％」である。

次に、管理プログラム４０の実行により、実現された管理部が有する機能について説明する。図５は、管理部の機能構成を示す図である。図５に示すように、管理部は、作成部４１と、読込部４２と、更新部４３と、キャッシュ部４４と、移動部４５とを有する。

作成部４１は、クライアント２０からの要求に基づいて、ディレクトリ又はファイルを作成する。なお、クライアント２０は、任意のノード１０にストレージシステム１へのアクセス要求を送信することができる。

作成部４１は、ネームスペースブランチ２１ａを末端のディレクトリまで辿り、作成対象のディレクトリを含むブランチを所有するノード１０を対象ノード候補としてリストアップする。そして、作成部４１は、辿ったディレクトリが作成対象の親ディレクトリでなく、対象ノード候補が一定数以上ある場合は、対象ノード候補の一つの中でさらに末端のディレクトリまで辿り、対象ノード候補をリストアップする。一方、辿ったディレクトリが作成対象の親ディレクトリであるか、対象ノード候補が一定数以下である場合は、作成部４１は、対象ノード候補の空き容量、負荷状況により対象ノード１０を選択する。

そして、対象ノード１０の作成部４１は、作成対象のファイル又はディレクトリを作成する。なお、対象ノード１０の作成部４１は、作成対象に到達するまでのディレクトリを所有していない場合は、ディレクトリも作成する。そして、対象ノード１０の作成部４１は、リストアップした他の対象ノード候補に所有情報の更新を指示し、クライアント２０から要求を受けたノード１０は、対象ノード候補の全てから処理完了の応答を得ると、クライアント２０に完了を応答する。

なお、作成部４１は、対象ノード候補から対象ノード１０を選択する場合、まず、空き容量が一定値以上である対象ノード候補があるか否かを判定し、対象ノード候補がある場合には、負荷が一定値未満であるノード１０を対象ノード１０として選択する。一方、負荷が一定値未満であるノード１０がない場合には、作成部４１は、最も負荷の少ないノード１０を対象ノード１０として選択する。また、空き容量が一定値以上である対象ノード候補がない場合には、作成部４１は、最も空き容量が大きいノード１０を対象ノード１０として選択する。なお、空き容量の一定値は、例えば３０％であり、負荷の一定値は、例えば５０％である。

読込部４２は、クライアント２０からの要求に基づいて、ディレクトリの情報又はファイルを読み込み、クライアント２０に送信する。具体的には、読込部４２は、ネームスペースブランチ２１ａを末端のディレクトリまで辿り、読み込み対象を所有している場合には、ディレクトリの情報又はファイルを読み込みクライアント２０に送信する。

一方、読み込み対象を所有していない場合には、読込部４２は、読み込み対象を含むブランチを所有しているノード１０に、読み込み対象の情報を所有しているか否かの確認を指示する。なお、確認を指示されるノード１０は複数の場合もある。そして、確認の指示を受けたノード１０の読込部４２は、読み込み対象を所有しているか否かを確認し、読み込み対象を所有している場合には、確認を指示した指示ノード１０に読み込み対象の情報を送信し、指示ノード１０がクライアント２０に情報を送信する。

更新部４３は、クライアント２０からの要求に基づいて、ファイルを更新する。具体的には、更新部４３は、ネームスペースブランチ２１ａを末端のディレクトリまで辿り、更新対象を所有している場合には、ファイルを更新し、クライアント２０に更新の完了を応答する。

一方、更新対象を所有していない場合には、更新部４３は、更新対象を含むブランチを所有しているノード１０に、更新対象のファイルを所有しているか否かの確認を指示する。なお、確認を指示されるノード１０は複数の場合もある。そして、確認の指示を受けたノード１０の更新部４３は、更新対象を所有しているか否かを確認し、更新対象を所有している場合には、ファイルを更新し、確認を指示した指示ノード１０に更新完了を送信する。そして、指示ノード１０がクライアント２０に更新完了を応答する。

キャッシュ部４４は、ネームスペースツリー２１の一部の情報であるディレクトリ情報をキャッシュする。具体的には、ディレクトリには、自分が所有しないファイルを所有するノード１０の情報を含むことができる。全てのノード１０が末端までキャッシュを持つと、書き込み処理に対するキャッシュ更新のペナルティが増加する。したがって、キャッシュ部４４は、リード及びライト処理の頻度の統計をディレクトリ階層毎に取り、性能を最適化するよう各ノード１０が持つディレクトリ階層レベルを自動調整する。

完全にリードのみの環境であれば、全てのノード１０が完全なファイルシステムのツリー構造の情報を持つ事になる。一方、完全にライトのみの環境であれば、全てのノード１０は自分が所有する分のファイルシステムツリー構造の情報しか持たない。

図６は、ディレクトリ情報のキャッシュを説明するための図である。図６において、ファイル２２の情報は、「ノード２」に所有されているが、「ノード１」にもキャッシュ２２ａが記憶されている。

移動部４５は、ノード１０間でのファイルの移動、ネームスペースブランチ２１ａ単位での移動をバックグラウンド処理として行い、ノード１０間での負荷のバランスをとる。図７は、ノード１０間でのファイルの移動を説明するための図である。

図７では、「ノード２」の負荷が高い、あるいは空き容量が少ない状況において、「ノード２」が所有するファイル２２が「ノード１」に移動されている。ファイル２２の親ディレクトリ２２ｃを所有するノード１０は、「ノード１」と「ノード２」である。そこで、移動部４５は、ファイル２２を移動する場合に、移動先として親ディレクトリ２２ｃを所有する「ノード１」を選択する。親ディレクトリ２２ｃを所有する「ノード１」を選択することによって、移動部４５は、親ディレクトリ２２ｃを所有しない「ノード３」を選択する場合と比較して、容易にファイル２２を移動することができる。

次に、ファイル作成処理のフローについて説明する。図８は、ファイル作成処理のフローを示すフローチャートである。なお、ディレクトリを作成する処理のフローは、図８において、「ファイル作成要求」を「ディレクトリ作成要求」に、「対象ファイル」を「対象ディレクトリ」に置き換えたものとなる。

図８に示すように、作成部４１は、クライアント２０からファイル作成要求を受ける（ステップＳ１）と、自ノード１０内で対象ファイルのパスに従い、ネームスペースブランチ２１ａを辿る（ステップＳ２）。そして、作成部４１は、辿り着いた末端のディレクトリを確認し（ステップＳ３）、対象ファイルを含むブランチを所有するノード１０を対象ノード候補としてリストアップする（ステップＳ４）。

そして、作成部４１は、末端のディレクトリが対象ファイルの親ディレクトリか否かを判定し（ステップＳ５）、親ディレクトリである場合には、対象ノード候補の空き容量、ＣＰＵ負荷率を参照し、対象ファイルを作成する対象ノード１０を決定する（ステップＳ６）。

そして、対象ノード１０の作成部４１は、対象ファイルを作成し、対象ノード１０以外の対象ノード候補は、所有情報を更新する（ステップＳ７）。そして、クライアント２０からファイル作成要求を受けたノード１０は、全対象ノード候補から完了応答受け取り後、クライアント２０に完了を応答する（ステップＳ８）。

一方、末端のディレクトリが対象ファイルの親ディレクトリでない場合には、作成部４１は、対象ノード候補は一定数以下か否かを判定する（ステップＳ９）。その結果、一定数以下である場合には、作成部４１は、対象ノード候補の空き容量、ＣＰＵ負荷率を参照し、対象ファイルを作成する対象ノード１０を決定する（ステップＳ１０）。

そして、作成部４１は、対象ノード１０内で対象ファイルのパスに従い、ネームスペースブランチ２１ａを辿る（ステップＳ１１）。そして、対象ノード１０が対象ファイルまでのディレクトリを所有していない場合は、作成部４１は、対象ファイルまでのディレクトリを作成し（ステップＳ１２）、ステップＳ７へ進む。

一方、対象ノード候補が一定数以下でない場合には、対象ノード候補のいずれかで、作成部４１は、対象ファイルのパスに従い、ネームスペースブランチ２１ａを辿る（ステップＳ１３）。そして、作成部４１は、辿り着いた末端のディレクトリを確認し（ステップＳ１４）、対象ファイルを含むブランチを所有するノード１０を対象ノード候補としてリストアップする（ステップＳ１５）。そして、作成部４１は、ステップＳ５に戻る。

このように、作成部４１は、ネームスペースブランチ２１ａを辿ることによって対象ファイルを作成するノード１０を決定するので、対象ファイルを作成するノード１０を効率よく決定することができる。

次に、ファイル読み込み処理のフローについて説明する。図９は、ファイル読み込み処理のフローを示すフローチャートである。なお、ディレクトリの情報を読み込む処理のフローは、図９において、「ファイルリード要求」を「ディレクトリリード要求」に、「対象ファイル」を「対象ディレクトリ」に、「ファイルデータ」を「ディレクトリ情報」に置き換えたものとなる。また、図９において、「受付ノード」は、クライアント２０からファイルリード要求を受け付けたノード１０であり、「所有ノード」は、ファイルを所有するノード１０である。

図９に示すように、読込部４２は、クライアント２０からファイルリード要求を受ける（ステップＳ２１）と、自ノード１０内で対象ファイルのパスに従い、ネームスペースブランチ２１ａを辿る（ステップＳ２２）。そして、読込部４２は、対象ファイルまで辿り着いたか否かを判定し（ステップＳ２３）、対象ファイルまで辿り着いた場合には、クライアント２０に対象ファイルを送信する（ステップＳ２４）。

一方、対象ファイルまで辿り着かない場合には、読込部４２は、辿り着けた最後のディレクトリ情報より対象ファイルを所有する対象ノード候補を確認する（ステップＳ２５）。そして、読込部４２は、対象ノード候補に、辿り着いたディレクトリ以下でファイルリード要求を送る（ステップＳ２６）。

そして、ファイルリード要求を受けたノード１０の読込部４２は、送られてきたディレクトリ以下でネームスペースブランチ２１ａを辿り、対象ファイルを確認する（ステップＳ２７）。そして、対象ファイルを所有していたノード１０の読込部４２は、要求元のノード１０にファイルデータを送る（ステップＳ２８）。

そして、クライント２０からファイルリード要求を受けたノード１０の読込部４２は、対象ファイルを所有しているノード１０からファイルデータを受け取り（ステップＳ２９）、対象ファイルをクライアント２０に送信する（ステップＳ３０）。

このように、読込部４２は、対象ファイルを所有するノード１０をネームスペースブランチ２１ａを辿ることによって特定するので、対象ファイルを所有するノード１０を効率良く特定することができる。

次に、ファイル更新処理のフローについて説明する。図１０は、ファイル更新処理のフローを示すフローチャートである。図１０に示すように、更新部４３は、クライアント２０からファイル更新要求を受ける（ステップＳ４１）と、自ノード１０内で対象ファイルのパスに従い、ネームスペースブランチ２１ａを辿る（ステップＳ４２）。そして、更新部４３は、対象ファイルまで辿り着いたか否かを判定し（ステップＳ４３）、対象ファイルまで辿り着いた場合には、対象ファイルを更新し（ステップＳ４４）、クライアント２０に完了を応答する（ステップＳ４５）。

一方、対象ファイルまで辿り着かない場合には、更新部４３は、辿り着けた最後のディレクトリ情報より対象ファイルを所有する対象ノード候補を確認する（ステップＳ４６）。そして、更新部４３は、対象ノード候補に、辿り着いたディレクトリ以下でファイル更新要求を送る（ステップＳ４７）。

そして、ファイル更新要求を受けたノード１０の更新部４３は、送られてきたディレクトリ以下でネームスペースブランチ２１ａを辿り、対象ファイルを確認する（ステップＳ４８）。そして、対象ファイルを所有していたノード１０の更新部４３は、対象ファイルを更新し（ステップＳ４９）、要求元のノード１０に完了を応答する（ステップＳ５０）。

そして、クライント２０からファイル更新要求を受け付けたノード１０の更新部４３は、対象ファイルを所有するノード１０から完了の応答を受け取り、クライアント２０に完了を応答する（ステップＳ４５）。

このように、更新部４３は、対象ファイルを所有するノード１０をネームスペースブランチ２１ａを辿ることによって特定するので、対象ファイルを所有するノード１０を効率良く特定することができる。

上述してきたように、実施例では、ノード１０は、ネームスペースツリー２１の一部であるネームスペースブランチ２１ａの情報を有する。そして、ノード１０は、ネームスペースブランチ２１ａのディレクトリ又はファイルに対応付けて、ディレクトリの情報又はファイルの情報を記憶するノード１０を識別する番号を記憶する。そして、ノード１０は、アクセス要求の対象ファイル又は対象ディレクトリを所有していない場合に、ネームスペースブランチ２１ａのディレクトリに対応付けられた番号のノード１０にアクセス要求を送信する。したがって、ノード１０は、アクセス要求の対象ファイル又は対象ディレクトリを所有していない場合に、ＮＳにファイルの記憶ノードを問い合わせる必要がなく、問合せにともなうオーバーヘッドをなくすことができる。

ところで、上記実施例では、ノード１０間でのファイルの移動、ネームスペースブランチ２１ａ単位での移動をバックグラウンド処理として行う場合について説明した。しかしながら、ファイルの移動をファイル更新時に行うこともできる。そこで、ファイルの移動をファイル更新時に行う場合について説明する。

図１１は、ファイルの移動を伴うファイル更新処理のフローを示すフローチャートである。図１１に示すように、更新部４３は、クライアント２０からファイル更新要求を受ける（ステップＳ６１）と、自ノード１０内で対象ファイルのパスに従い、ネームスペースブランチ２１ａを辿る（ステップＳ６２）。

そして、更新部４３は、対象ファイルまで辿り着いたか否かを判定し（ステップＳ６３）、対象ファイルまで辿り着いた場合には、対象ファイルの親ディレクトリを有するノード１０を対象候補としてリストアップする（ステップＳ６４）。そして、更新部４３は、対象ノード候補から空き容量、ＣＰＵ負荷率に応じて対象ノード１０を選択する（ステップＳ６５）。そして、更新部４３は、対象ノード１０にファイルの作成を指示して、自ノード１０内のファイルを削除し（ステップＳ６６）、クライアント２０に完了を応答する（ステップＳ６７）。

一方、対象ファイルまで辿り着かない場合には、更新部４３は、辿り着けた最後のディレクトリ情報より対象ファイルを所有する対象ノード候補を確認する（ステップＳ６８）。そして、更新部４３は、対象ノード候補に、辿り着いたディレクトリ以下でファイル更新要求を送る（ステップＳ６９）。

そして、ファイル更新要求を受けたノード１０の更新部４３は、送られてきたディレクトリ以下でネームスペースブランチ２１ａを辿り、対象ファイルの親ノード１０を確認する（ステップＳ７０）。そして、対象ファイルを所有していたノード１０の更新部４３は、対象ファイルを更新し（ステップＳ７１）、対象ファイルの親ディレクトリを有するノード１０を対象候補としてリストアップする（ステップＳ７２）。

そして、対象ファイルを所有していたノード１０の更新部４３は、対象ノード候補から空き容量、ＣＰＵ負荷率に応じて対象ノード１０を選択する（ステップＳ７３）。そして、対象ファイルを所有していたノード１０の更新部４３は、対象ノード１０にファイルの作成を指示して、自ノード１０内のファイルを削除し（ステップＳ７４）、要求元のノード１０に要求の完了を応答する（ステップＳ７５）。そして、要求元のノード１０は、クライアント２０に完了を応答する（ステップＳ６７）。

このように、更新部４３は、ファイルを更新する際に、空き容量、ＣＰＵ負荷率に応じて対象ノード１０を選択し、対象ノード１０にファイルの作成を指示して自ノード１０内のファイルを削除することによって、ノード１０間の負荷をバランスすることができる。

また、上記実施例では、特定のノード１０がファイルを占有する場合について説明したが、ファイルに共同所有するノード情報を付与することで複数ノード１０によるファイルの共有を可能にすることができる。クライアント２０から要求を受けたノード１０の管理プログラム４０は、論理的に近い、あるいは負荷の少ないノード１０を複数選択し、複数のノード１０に分割して要求を送ることで、スパニングによりシーケンシャルアクセスの性能を向上できる。複数ノード１０で所有することにより特定のファイル、あるいはネームスペースブランチ２１ａ単位で冗長性を高めることができる。また、クライアント２０から要求を受けたノード１０は、ファイルを冗長符号化し複数ノード１０にストライプすることでシーケンシャルアクセス性能を高めるとともに、冗長性を確保することができる。

図１２は、複数ノード１０によるファイルの共同所有を説明するための図である。図１２は、ファイル２２が「ノード１」と「ノード２」に共同所有される場合を示し、「ノード１」と「ノード２」において、ファイル２２にノード番号「１」と「２」が対応付けられている。

また、実施例では、複数のｉノードテーブル３１ａを用いてネームスペースツリー２１の階層構造情報及び所有ノード１０の情報を記憶する場合について説明した。しかしながら、本発明はこれに限定されるものではなく、ネームスペースツリー２１の階層構造情報と所有ノード１０の情報を別々に記憶する場合にも同様に適用することができる。

１ ストレージシステム
２ プロトコルネットワーク
３ ノード間ネットワーク
１０，８１〜８４，９１〜９４ ノード
１１ プロトコルインタフェース
１２ ノード間インタフェース
１３ ＣＰＵ
１４ メモリ
１５ 不揮発メモリ
１６ ＲＡＩＤ
２１ ネームスペースツリー
２１ａ ネームスペースブランチ
２１ｂ ルートディレクトリ
２１ｃ，２１ｅ ルートディレクトリの子のディレクトリ
２１ｄ，２１ｆ，２１ｇ ファイル
２２ ファイル
３０ データ保存領域
３１ ｉノードテーブル記憶部
３１ａ ｉノードテーブル
３２ ノード管理テーブル
４０ 管理プログラム
４１ 作成部
４２ 読込部
４３ 更新部
４４ キャッシュ部
４５ 移動部

Claims (8)

1. ストレージシステムを構築する他のストレージ装置とともにデータを記憶するストレージ装置において、
   前記ストレージシステムが記憶するデータの階層構造に関する階層構造情報を他のストレージ装置と分担した箇所について記憶する階層構造情報記憶部と、
   データを識別するデータ識別子と該データを所有するストレージ装置を識別する装置識別子とを対応付けた所有装置情報を前記階層構造情報記憶部が記憶する前記分担した箇所について記憶する所有装置情報記憶部と、
   前記分担した箇所について前記階層構造情報記憶部と前記所有装置情報記憶部が記憶する情報に基づいて管理し、残りの箇所について管理を分担する前記他のストレージ装置とともに前記ストレージシステムが記憶するデータを管理する管理部と
   を有することを特徴とするストレージ装置。
2. 前記管理部は、データのアクセス要求をクライアント装置から受信した場合に、アクセスを要求されたデータを自装置が所有するか否かを前記階層構造情報に基づいて判定し、自装置が所有しない場合には、該データを所有するストレージ装置を前記所有装置情報を用いて特定し、特定したストレージ装置に前記アクセス要求を転送することを特徴とする請求項１に記載のストレージ装置。
3. 前記管理部は、データの作成要求をクライアント装置から受信した場合に、作成を要求されたデータの親であるディレクトリを所有するストレージ装置を前記階層構造情報及び前記所有装置情報に基づいて特定し、特定したストレージ装置にデータを作成することを特徴とする請求項２に記載のストレージ装置。
4. 前記管理部は、他のストレージ装置が作成したデータについて他のストレージ装置が有する前記階層構造情報及び前記所有装置情報の一部をキャッシュ情報として記憶することを特徴とする請求項２又は３に記載のストレージ装置。
5. 前記管理部は、リード及びライト処理の頻度の統計を取り、前記キャッシュ情報として記憶する情報を調整し、ライトのみの環境の場合、前記他のストレージ装置の前記階層構造情報及び前記所有装置情報をキャッシュ情報として記憶しないことを特徴とする請求項４に記載のストレージ装置。
6. 前記管理部は、データを他のストレージ装置に移動する場合に、移動するデータの親であるディレクトリを所有するストレージ装置を前記階層構造情報及び前記所有装置情報に基づいて特定し、特定したストレージ装置にデータを移動することを特徴とする請求項２〜５のいずれか１つに記載のストレージ装置。
7. 複数のストレージ装置で分散してデータを記憶するストレージシステムにおいて、
   各ストレージ装置は、
   当該ストレージシステムが記憶するデータの階層構造に関する階層構造情報を他のストレージ装置と分担した個所について記憶する階層構造情報記憶部と、
   データを識別するデータ識別子と該データを所有するストレージ装置を識別する装置識別子とを対応付けた所有装置情報を前記階層構造情報記憶部が記憶する前記分担した個所について記憶する所有装置情報記憶部と、
   前記分担した箇所について前記階層構造情報記憶部と前記所有装置情報記憶部が記憶する情報に基づいて管理し、残りの箇所について管理を分担する前記他のストレージ装置とともに当該ストレージシステムが記憶するデータを管理する管理部と
   を有することを特徴とするストレージシステム。
8. ストレージシステムを構築する他のストレージ装置とともにデータを記憶するストレージ装置が有するコンピュータで実行されるデータ管理プログラムにおいて、
   前記ストレージシステムが記憶するデータの階層構造に関する階層構造情報を他のストレージ装置と分担した個所について階層構造情報記憶部に記憶し、
   データを識別するデータ識別子と該データを所有するストレージ装置を識別する装置識別子とを対応付けた所有装置情報を前記階層構造情報記憶部が分担して記憶する個所について所有装置情報記憶部に記憶し、
   前記分担した箇所について前記階層構造情報記憶部と前記所有装置情報記憶部が記憶する情報に基づいて管理し、残りの箇所について管理を分担する前記他のストレージ装置とともに前記ストレージシステムが記憶するデータを管理する
   処理を前記コンピュータに実行させることを特徴とするデータ管理プログラム。

Images