(57)【要約】クラスタとして相互接続された複数のノードをにわたって分散された１以上のボリュームを備えたストレージ・システム・アーキテクチャ。ボリュームは、ストライピングされたボリュームセット（ＳＶＳ）として編成され、クライアントが発行したマルチプロトコル・データアクセス要求に応答して、クラスタにより提供されるデータコンテナの中身を格納するように構成される。クラスタの各ノードは、（１）ＳＶＳのボリュームを提供するように構成されたストレージ・サーバ、及び（２）データアクセス要求をクラスタのいずれかのストレージ・サーバへリダイレクトするように構成されたマルチプロトコル・エンジンを有する。特に、各データコンテナの中身は、ＳＶＳの複数のボリュームにわたって分散され、それにより、クラスタによって提供されるストレージサービスの効率が向上する。
2008539505.tif 000002
【特許請求の範囲】
【請求項１】
ストライピングされたボリュームセットにわたって１以上のデータコンテナをストライピングするシステムであって、
複数のストライピングされたボリュームセットに編成された複数のボリュームであって、該ストライピングされたボリュームセットのそれぞれが、一組のストライピング・ルールによって規定される、複数のボリュームと、
クラスタを成す１以上のコンピュータ上で実行されるボリューム・ストライピング・モジュールであって、該コンピュータのそれぞれが、前記複数のボリュームのうちの１以上のボリュームを提供する、ボリューム・ストライピング・モジュールと
を含み、前記ボリューム・ストライピング・モジュールが、前記ストライピングされたボリュームセットに対するコマンドを実施する、システム。
【請求項２】
前記一組のストライピング・ルールは、ストライプ幅を含む、請求項１に記載のシステム。
【請求項３】
前記一組のストライピング・ルールは、前記ストライピングされたボリュームセットとともに使用されるストライピング・アルゴリズムを識別するストライピング・アルゴリズム識別子を含む、請求項１に記載のシステム。
【請求項４】
前記ストライピング・ルールは、前記ボリュームの順序付き集合を含む、請求項１に記載のシステム。
【請求項５】
前記ボリュームの順序付き集合のうちの第１のボリュームは、メタデータボリュームからなる、請求項４に記載のシステム。
【請求項６】
前記ストライピングされたボリュームセットにわたってストライピングされた１以上のデータコンテナのそれぞれに対し、前記複数のボリュームのうちの１つが、コンテナ属性ボリュームとして規定される、請求項１に記載のシステム。
【請求項７】
ストライピングされたボリュームセットにわたって１以上のデータコンテナをストライピングするシステムであって、
前記ストライピングされたボリュームセットに対するコマンドをクライアントから受信するように構成され、更に、受信したコマンドを１以上のディスク要素のうちの１つと通信するためのプロトコルに変換するように構成された１以上のネットワーク要素を含み、
前記ディスク要素のそれぞれが、前記ストライピングされたボリュームセットに対するオペレーションを実施するための前記プロトコルを処理するように構成されたボリューム・ストライピング・モジュールを含む、システム。
【請求項８】
前記ストライピングされたボリュームセットは複数のボリュームを含み、該ボリュームのそれぞれが、前記１以上のディスク要素のうちのひとつによって提供される、請求項７に記載のシステム。
【請求項９】
前記ストライピングされたボリュームセットは、一組のストライピング・ルールによって規定される、請求項７に記載のシステム。
【請求項１０】
前記一組のストライピング・ルールは、ストライプ幅を含む、請求項９に記載のシステム。
【請求項１１】
前記ストライピング・ルールは、前記ストライピングされたボリュームセットとともに使用されるストライピング・アルゴリズムを識別するストライピング・アルゴリズム識別子を含む、請求項９に記載のシステム。
【請求項１２】
前記ストライピング・ルールは、ボリュームの順序付き集合を含む、請求項９に記載のシステム。
【請求項１３】
前記ボリュームの順序付き集合のうちの第１のボリュームは、メタデータ・ボリュームからなる、請求項９に記載のシステム。
【請求項１４】
ストライピングされたボリュームセットにわたって１以上のデータコンテナをストライピングする方法であって、
一組のストライピング・ルールを使用して、ストライピングされたボリュームセットを規定するステップと、
複数のボリュームを、一組のストライピング・ルールによって規定されるストライピングされたボリュームセットに編成するステップと、
クラスタを成す１以上のコンピュータ上で実行されるボリューム・ストライピング・モジュールであって、該コンピュータのそれぞれが、前記複数のボリュームのうちの１以上のボリュームを提供する、ボリューム・ストライピング・モジュールを提供するステップと
を含み、前記ボリューム・ストライピング・モジュールが、前記ストライピングされたボリュームセットに対するコマンドを実施する、方法。
【請求項１５】
前記一組のストライピング・ルールは、ストライプ幅を含む、請求項１４に記載の方法。
【請求項１６】
前記ストライピング・ルールは、前記ストライピングされたボリュームセットとともに使用されるストライピング・アルゴリズムを識別するストライピング・アルゴリズム識別子を含む、請求項１４に記載の方法。
【請求項１７】
前記ストライピング・ルールは、ボリュームの順序付き集合を含む、請求項１４に記載の方法。
【請求項１８】
前記ボリュームの順序付き集合のうちの第１のボリュームは、メタデータボリュームからなる、請求項１７に記載の方法。
【請求項１９】
前記ストライピングされたボリュームセットにわたってストライピングされた１以上のデータコンテナのそれぞれに対し、前記複数のボリュームのうちの１つをコンテナ属性ボリュームとして規定するステップを更に含む、請求項１４に記載の方法。
【請求項２０】
前記複数のボリュームのうちの１つをメタデータボリュームとして規定するステップを更に含む、請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
[発明の分野]
本発明はストレージシステムに関し、詳しくは、１つのファイルを１以上のストレージシステム上の複数のボリュームにわたってストライピングすることに関する。
【背景技術】
【０００２】
[発明の背景]
ストレージシステムは通常、必要に応じて情報を入れたり、情報を取り出したりするための１以上の記憶装置を備える。ストレージシステムは、とりわけ、当該システムによって提供されるストレージサービスを支援するストレージ・オペレーションを実施することにより、当該システムを機能的に編成するためのストレージ・オペレーティング・システムを有する。ストレージシステムは、種々のストレージ・アーキテクチャにより実施することができ、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及びクライアント又はホストコンピュータに直接取り付けられたディスクアセンブリ等によって実施される場合がある。記憶装置は通常、ディスクアレイとして編成されたディスクドライブである。ここで、「ディスク」という用語は一般に、内蔵型の回転磁気媒体ストレージディスクを意味する。この文脈におけるディスクという用語は、ハード・ディスク・ドライブ（ＨＤＤ）やダイレクト・アクセス・ストレージ・デバイス（ＤＡＳＤ）と同じ意味である。
【０００３】
ストレージシステムのストレージ・オペレーティング・システムは、ボリューム上に格納される情報をファイルや論理ユニットのようなデータコンテナの階層構造として論理編成するために、ファイルシステムのような高レベルモジュールを実施する場合がある。例えば、「ディスク上」の各ファイルは、そのファイルの実際のデータのような情報を格納するように構成された一組のデータ構造、すなわちディスクブロックとして実施される場合がある。それらのデータブロックは、ファイルシステムによって管理されるボリュームブロック番号（ｖｂｎ）空間の中で編成される。また、ファイルシステムは、ファイル内の各データブロックに、対応する「ファイル・オフセット」、又はファイルブロック番号（ｆｂｎ）を割り当てる場合がある。ファイルシステムは通常、ファイルごとに一連のｆｂｎを割り当てる一方、より大きなボリュームアドレス空間にわたってｖｂｎを割り当てる。ファイルシステムは、ｖｂｎ空間内のデータブロックを「論理ボリューム」として編成し、各論理ボリュームは、必須ではないが、その論理ボリューム独自のファイルシステムに関連する。
【０００４】
既知のタイプのファイルシステムの１つは、ディスク上でデータを上書きしないｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムである。ディスクからストレージシステムのメモリへとデータブロックを取得し（読み出し）、新たなデータで「汚す」（すなわち、更新する、又は変更する）場合、書き込み性能を最適化するために、そのデータブロックは、以後、ディスク上の新たな場所に格納される（書き込まれる）。ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、データがディスク上に実質的に連続的に配置されるような最適レイアウトを最初に想定する場合がある。この最適ディスクレイアウトによれば、ディスクに対する効率的なアクセスオペレーションが可能となり、特に、シーケンシャル読み出しアクセスの場合に、効率的なアクセスオペレーションが可能になる。ストレージシステム上で動作するように構成されたｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているＷｒｉｔｅ  Ａｎｙｗｈｅｒｅ  Ｆｉｌｅ  Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムである。
【０００５】
ストレージシステムは、情報配送のクライアント／サーバモデルにしたがって動作するように更に構成される場合があり、それによって、多数のクライアントが、そのストレージシステムに格納されたデータコンテナにアクセスすることができる。このモデルでは、クライアントは、コンピュータ上で実行されるデータベース・アプリケーションのようなアプリケーションを含み、ポイント・ツー・ポイントリンク、共有ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、または、インターネットのような公共ネットワークを介して実施される仮想私設ネットワーク（ＶＰＮ）のようなコンピュータネットワークを介してストレージシステムに「接続」する。各クライアントは、ネットワークを介して、ファイルベースのプロトコルメッセージ、及びブロックベースのプロトコルメッセージ（パケットの形をしている）をシステムに発行することによって、ストレージシステムのサービスを要求することができる。
【０００６】
複数のストレージシステムを相互接続し、多数のクライアントに対してサービスを提供するように構成されたストレージシステム環境を形成する場合もある。各ストレージシステムは、１以上のボリュームを提供するように構成され、各ボリュームは、１以上のデータコンテナを格納する場合がある。また、クライアントにより発行される多数のデータアクセス要求が、その環境の特定のストレージシステムによって提供される少数のデータコンテナに対して発行されることがある。そのような問題の１つの解決策は、特定のストレージシステムによって提供されるボリュームをその環境の全てのストレージシステムにわたって分散させることである。その結果、データアクセス要求、及び、その要求に応じるために必要とされる処理リソースは、全てのストレージシステムにわたって分散され、それによって、各ストレージオペレーティングシステムの個々の処理負荷は低減される。しかしながら、ファイルのような単一のデータコンテナだけが、ストレージシステム環境のクライアントによって頻繁にアクセスされる場合、顕著な欠点が現れる。その結果、そのデータコンテナに対する要求に応じるストレージシステムは、自分が有する処理リソースを超過し、過負荷になると同時に、速度や性能が低下する。
【発明の開示】
【課題を解決するための手段】
【０００７】
[発明の概要]
本発明は、クラスタとして相互接続された複数のノードにわたって分散された１以上のボリュームを含むストレージシステムアーキテクチャを提供することにより、従来技術の欠点を克服する。ボリュームは、ストライピングされたボリュームセット（ＳＶＳ）として編成され、クライアントが発行したマルチプロトコル・データアクセス要求に応答して、クラスタが提供するファイルや論理ユニットのようなデータコンテナの中身を格納するように構成される。クラスタの各ノードは、（１）ＳＶＳのボリュームを提供するように構成されたストレージサーバ、及び（２）データアクセス要求をクラスタのいずれかのストレージサーバへリダイレクトするように構成されたマルチプロトコル・エンジンを含む。特に、各データコンテナの中身は、ＳＶＳの複数のボリューム間に分配され、それによって、クラスタによって提供されるストレージサービスの効率が向上する。
【０００８】
本発明の一態様によれば、ＳＶＳは、１つのメタデータ・ボリューム（ＭＤＶ）、及び１以上のデータボリューム（ＤＶ）を含む。ＭＤＶは、ＳＶＳに格納されるすべてのメタデータに関連するアクセス・コントロール・リスト、及びディレクトリを格納するように構成される一方、各ＤＶは、少なくとも、それらのコンテナのデータ内容を格納するように構成される。ＳＶＳに格納される各データコンテナについて、１つのボリュームは、ＣＡＶに指定され、その目的のために、そのボリュームは、そのデータコンテナに関連する高速に変化する特定の属性メタデータを格納（「キャッシュ」」するように構成され、それによって、通常ならばＭＤＶへ送られるアクセス要求の負荷を低減する。
【０００９】
本発明の他の態様によれば、ＳＶＳは、ストライプ・アルゴリズム、ストライプ幅、及びＳＶＳ内のボリュームの順序付きリストを規定する一組のストライピング・ルールに関連する。ストライプ・アルゴリズムは、データコンテナの中身をストライプとして複数のボリュームにわたって分配する仕方を指定する一方、ストライプ幅は、各ストライプのサイズ／幅を指定する。また、ボリュームの順序付きリストは、そのＳＶＳの種々のボリューム、及びストライピング・ルールの機能、及び実施形態を指定する。例えば、順序付きリスト中の最初のボリュームは、ＳＶＳのＭＤＶを意味する一方、該リスト中のボリュームの順序は、例えばラウンド・ロビンのような特定のストライピング・アルゴリズムを実施する仕方を意味する場合がある。
【００１０】
一実施形態において、各ノードのストレージサーバは、ディスク要素（Ｄブレード）として実施され、マルチプロトコル・エンジンは、ネットワーク要素（Ｎブレード）として実施される。Ｎブレードは、マルチプロトコル・データアクセス要求をクライアントから受信し、その要求をクラスタ・ファブリック（ＣＦ）メッセージに変換し、そのメッセージをクラスタの適当なＤブレードにリダイレクトする。ＮブレードのＣＦモジュールは、そのメッセージの宛先となるＳＶＳボリューム中のデータコンテナ・コンテンツの位置を計算するために新規のＬｏｃａｔｅ（）関数を実施し、それによって、クラスタによって提供されるそのようなコンテンツの整合性を確保する。各Ｄブレードは、ファイルシステムとボリューム・ストライピング・モジュール（ＶＳＭ）を含み、それらが協働し、ストライピング・ルールにしたがってＣＦメッセージを処理することによって、ＳＶＳのボリュームを提供する。特に、ＶＳＭは、新規のＬｏｃａｔｅ（）関数を実施する。
【００１１】
本発明の上記の利点、及び他の利点は、添付の図面と併せて下記の説明を読むと、よりよく理解できるであろう。図中、同じ符号は、同一の構成要素、又は機能的に類似の構成要素であることを示している。
【発明を実施するための最良の形態】
【００１２】
[例示的実施形態の詳細な説明]
Ａ．クラスタ環境
図１は、クラスタ１００として相互接続され、記憶装置上の情報の編成に関するストレージサービスを提供するように構成された複数のノード２００を示す略ブロック図である。ノード２００は種々の機能的構成要素を含み、それが協働して、クラスタ１００の分散ストレージシステムアーキテクチャを提供する。その目的のために、各ノード２００は通常、ネットワーク環境（Ｎブレード３１０）、及びディスク要素（Ｄブレード３５０）として編成される。Ｎブレード３１０は、コンピュータ・ネットワーク１４０を介してノード２００をクライアント１８０に接続する機能を有する一方、各Ｄブレード３５０は、ディスクアレイ１２０のディスク１３０のような１以上の記憶装置に接続される。ノード２００は、クラスタ切り替え装置１５０によって相互接続され、例示的実施形態として、クラスタ切り替え構造１５０は、ギガビット・イーサネット(R)・スイッチとして実施される場合がある。分散ファイルシステムアーキテクチャの一例は、２００２年８月２２日に発行されたM. Kazar他による「METHOD AND SYSTEM FOR RESPONDING TO FILE SYSTEM REQUESTS」と題する米国特許出願公開公報第ＵＳ２００２／０１１６５９３号に記載されている。なお、図示のクラスタ１００では、同数のＮブレード、及びＤブレードが描かれているが、本発明の種々の実施形態によれば、Ｎブレード、及びＤブレードの数は異なる場合もある。クラスタ構成１００には、例えば、複数の相互接続されたＮブレード、及び／又はＤブレードが存在する場合があり、それらは、ＮブレードとＤブレードの一対一対応を反映しない場合がある。したがって、１つのＮブレードと１つのＤブレードを含むノード２００の説明は、単なる例として捉えなければならない。
【００１３】
クライアント１８０は、情報配送のクライアント／サーバモデルにしたがってノード２００と通信するように構成された汎用コンピュータであってもよい。つまり、各クライアントが、ノードにサービスを要求すると、そのノードは、ネットワーク１４０を介してパケットをやりとりすることによって、そのクライアントによって要求されたサービスの結果を返す場合がある。ファイルやディレクトリの形態をした情報をアクセスするとき、クライアントは、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）上で実施されるコモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルやネットワーク・ファイルシステム（ＮＦＳ）プロトコルのようなファイルベースのアクセスプロトコルを有するパケットを発行する場合がある。あるいはクライアントは、ブロックの形態をした情報をアクセスする場合、「ＳＣＳＩ  ｏｖｅｒ  ＴＣＰ（ｉＳＣＳＩ）」プロトコルや「ＳＣＳＩ  ｏｖｅｒ  ＦＣ（ＦＣＰ）」プロトコルのようなブロックベースのアクセスプロトコルを有するパケットを発行する場合がある。
【００１４】
Ｂ．ストレージシステムノード
図２は、システムバス２２３によって相互接続された複数のプロセッサ２２２ａ，ｂ、メモリ２２４、ネットワーク・アダプタ２２５、クラスタ・アクセス・アダプタ２２６、ストレージアダプタ２２８、及びローカルストレージ２３０を含むストレージシステムとして例えば実施されるノード２００を示す略ブロック図である。ローカルストレージ２３０は、ユーザモード・アプリケーション１１００として実施される１以上の管理プロセスによって提供される（図１１参照）設定情報（例えば、設定テーブル２３５の中にあるようなもの）をローカルに格納するために使用されるディスクのような１以上の記憶装置を含む。クラスタ・アクセス・アダプタ２２６は、ノード２００をクラスタ１００の他のノードに接続するための複数のポートを備える。一実施形態では、クラスタリング・プロトコル、及び相互接続媒体としてイーサネット(R)が使用されるが、当業者には明らかなように、本明細書に記載するクラスタアーキテクチャの中で、他のタイプのプロトコル、及び相互接続を使用することも可能である。ＮブレードとＤブレードが個別のストレージシステム、又はコンピュータ上で実施されるような代替実施形態の場合、Ｎ／Ｄブレードは、クラスタ・アクセス・アダプタ２２６を使用して、クラスタ１００中の他のＮ／Ｄブレードと通信する場合がある。
【００１５】
各ノード２００は、例えば、ストレージ・オペレーティング・システム３００を実行するデュアル・プロセッサ・ストレージ・システム３００として実施される。ストレージ・オペレーティング・システム３００は、情報を名前付きディレクトリ、ファイル、及び仮想ディスクと呼ばれる特殊なタイプのファイル（以後、「ブロック」）の階層構造としてディスク上に論理編成するために、ファイルシステムのような高レベルモジュールを実施することが好ましい。ただし、当業者には明らかなように、ノード２００は、代わりに、１以上のプロセッサ・システムを含む場合がある。例えば、一方のプロセッサ２２２ａは、そのノード上のＮブレード３１０の機能を実行する一方、他方のプロセッサ２２２ｂは、Ｄブレード３５０の機能を実行する場合がある。
【００１６】
メモリ２２４は例えば、本発明に関連するソフトウェア・プログラム・コード、及びデータ構造を記憶するために、プロセッサ、及びアダプタによってアドレス指定可能な複数の記憶場所を有する。さらに、プロセッサ、及びアダプタは、そのソフトウェア・コードを実行し、データ構造を操作するように構成された処理要素、及び／又は論理回路を含む場合がある。ストレージ・オペレーティング・システム３００は通常、その一部がメモリに常駐し、処理要素によって実行され、とりわけ、そのノードにより実施されるストレージサービスを支援するストレージ・オペレーションを実施することによって、ノード２００を機能的に編成する。当業者には明らかなように、本明細書に記載する本発明に関するプログラム命令の格納や実行には、他の処理手段や、コンピュータ読み取り可能媒体を含む他の記憶手段を使用してもよい。
【００１７】
ネットワークアダプタ２２５は、ポイント・ツー・ポイントリンク、ワイド・エリア・ネットワーク、公共ネットワーク（インターネット）上で実施される仮想私設ネットワーク、又は共有ローカル・エリア・ネットワークを介して、ノード２００を１以上のクライアント１８０に接続するように構成された複数のポートを有する。したがって、ネットワークアダプタ２２５は、ノードをネットワークに接続するために必要とされる機械的、電気的、及び信号的回路を含む場合がある。例えば、コンピュータネットワーク１４０は、イーサネット・ネットワークやファイバ・チャネル（ＦＣ）ネットワークとして実施される場合がある。各クライアント１８０は、ＴＣＰ／ＩＰのような所定のプロトコルにしたがってデータパケット、またはデータフレームをやりとりすることにより、ネットワーク１４０を介してノードと通信することができる。
【００１８】
ストレージアダプタ２２８は、ノード２００上で実行されているストレージ・オペレーティング・システム３００と協働し、クライアントによって要求された情報を取得する。この情報は、ビデオテープ、光学媒体、ＤＶＤ、磁気テープ、バブルメモリ、電気的ランダム・アクセス・メモリ、及びＭＥＭＳデバイスの他、データやパリティ情報のような情報を格納するように構成された他の任意の同様の媒体のような書き込み可能なストレージ・デバイスの任意のタイプのアタッチド・アレイに格納される場合がある。ただし、本明細書に記載するように、情報は、アレイ１２０のディスク１３０上に記憶されることが好ましい。ストレージ・アダプタは、従来の高性能ＦＣリンクトポロジのようなＩ／Ｏ相互接続構成を介してディスクに接続するための入出力（Ｉ／Ｏ）インタフェース回路を備えた複数のポートを有する。
【００１９】
各アレイ１２０への情報の格納は、一群の物理ストレージディスク１３０を含む１以上のストレージ「ボリューム」として実施されることが好ましく、それらの物理ストレージディスク１３０が協働し、そのボリューム（複数の場合もあり）上のボリュームブロック番号（ｖｂｎ）空間の全体的論理配置を規定する。各論理ボリュームは通常、必須ではないが、そのボリューム独自のファイルシステムに関連する。論理ボリューム／ファイルシステム内のディスクは通常、１以上のグループに編成され、各グループは、ＲＡＩＤ（Redundant Array of Independent Disks）として運用される場合がある。ＲＡＩＤ−４レベル実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ中の所与の数の物理ディスクにわたってデータ「ストライプ」を冗長書き込みし、そのストライプ状データに対するパリティ情報を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。ＲＡＩＤ実施形態の一例はＲＡＩＤ−４レベル実施形態である。しかしながら、他のタイプ、又はレベルのＲＡＩＤ実施形態も、本明細書に記載する本発明の原理にしたがって使用可能であるものと考えるべきである。
【００２０】
Ｃ．ストレージ・オペレーティング・システム
ディスク１３０へのアクセスを容易にするために、ストレージ・オペレーティング・システム３００は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。このファイルシステムは、１以上の仮想化モジュールと協働し、ディスク１３０によって提供される記憶空間を「仮想化」する。ファイルシステムは、情報を名前付きディレクトリ、及びファイルの階層構造としてディスク上に論理編成する。「ディスク上」の各ファイルは、データのような情報を格納するように構成された一組のディスクブロックとして実施される一方、ディレクトリは、特殊フォーマットのファイルとして実施され、その中に、他のファイルやディレクトリの名前、及びそれらへのリンクが格納される場合がある。仮想化モジュール（複数の場合もあり）により、ファイルシステムは、情報をブロックの階層構造としてディスク上に更に論理編成し、それらを名前付き論理ユニット番号（ＬＵＮ）としてエキスポートすることが可能になる。
【００２１】
例示的実施形態として、ストレージ・オペレーティング・システムは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているＮｅｔＡｐｐ  Ｄａｔａ  ＯＮＴＡＰオペレーティングシステムであることが好ましい。このオペレーティングシステムは、Ｗｒｉｔｅ  Ａｎｙｗｈｅｒｅ  Ｆｉｌｅ  Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムを実施する。ただし、当然ながら、任意の適当なストレージオペレーティングシステムを本明細書に記載する本発明の原理に従って使用されるように拡張することも可能である。したがって、「ＷＡＦＬ」という用語を使用した場合でも、この用語は、本発明の教示に適合する任意のストレージ・オペレーティング・システムを指すものとして広い意味で解釈しなければならない。
【００２２】
図３は、本発明とともに有利に使用されるストレージ・オペレーティング・システム３００を示す略ブロック図である。ストレージ・オペレーティング・システムは、統合ネットワーク・プロトコル・スタックを形成するように編成された一連のソフトウェア層を含み、より一般的に言えば、ノードに格納された情報をクライアントがブロックアクセスプロトコルとファイルアクセスプロトコルを使用してアクセスするためのデータパスを提供するマルチプロトコル・エンジン３２５を含む。マルチプロトコル・エンジンは、ＩＰ層３１４、並びにその支援搬送機構であるＴＣＰ層３１６、及びユーザ・データグラム・プロトコル（ＵＤＰ）層３１５のようなネットワークプロトコル層に対するインタフェースとして機能するネットワークドライバ（例えば、ギガビット・イーサネット(R)・ドライバ）のメディア・アクセス層３１２を含む。ファイルシステムプロトコル層はマルチプロトコルアクセスを提供し、その目的のために、ダイレクト・アクセス・ファイルシステム（ＤＡＦＳ）プロトコル３１８、ＮＦＳプロトコル３２０、ＣＩＦＳプロトコル３２２、及びハイパー・テキスト・トランスファ・プロトコル（ＨＴＴＰ）プロトコル３２４をサポートする。ＶＩ層３２６は、ＤＡＦＳプロトコル３１８によって必要とされるＲＤＭＡのようなダイレクト・アクセス・トランスポート（ＤＡＴ）機能を提供するために、ＶＩアーキテクチャを実施する。ｉＳＣＳＩドライバ層３２８は、ＴＣＰ／ＩＰネットワークプロトコル層を介したブロックプロトコルアクセスを提供する一方、ＦＣドライバ層３３０は、ブロックアクセス要求、及び応答をノードとの間で送受信する。ＦＣドライバ、及びｉＳＣＳＩドライバは、ブロックに対するＦＣ固有の、及びｉＳＣＳＩ固有のアクセスコントロールを提供し、したがって、ノード２００上のブロックにアクセスするときに、ｉＳＣＳＩとＦＣＰのいずれか、またはｉＳＣＳＩとＦＣＰの両方に対するＬＵＮのエキスポートを管理する。
【００２３】
さらに、ストレージ・オペレーティング・システムは、ノード２００のディスク１３０上に格納された情報にアクセスするためのデータパスを提供するストレージサーバ３６５を形成するように編成された一連のソフトウェア層を含む。その目的のために、ストレージサーバ３６５は、ボリューム・ストライピング・モジュール（ＶＳＭ）３７０、ＲＡＩＤシステムモジュール３８０、及びディスクドライバシステムモジュール３９０と協働するファイルシステムモジュール３６０を含む。ＲＡＩＤシステム３８０は、Ｉ／Ｏオペレーションにしたがって、ボリューム／ディスクに対する情報の記憶、及び読み出しを管理し、ディスクドライバシステム３９０は、例えばＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施する。ＶＳＭ３７０は、例えば、本発明のストライピングされたボリュームセット（ＳＶＳ）を実施する。後で詳しく説明するように、ＶＳＭは、ファイルシステム３６０と協働し、ストレージサーバ３６５が、ＳＶＳのボリュームを提供できるようにする。具体的には、ＶＳＭ３７０は、ＳＶＳボリューム中のデータコンテナコンテンツの位置を計算するための新規なＬｏｃａｔｅ（）関数３７５を実施し、それによって、クラスタによって提供されるそのようなコンテンツの整合性を確保する。
【００２４】
ファイルシステム３６０は、１以上の仮想化モジュールと通信することにより、ストレージ・オペレーティング・システム３００の仮想化システムを実施する。仮想化モジュールは、例えば仮想ディスク（ｖｄｉｓｋ）モジュール（図示せず）、及びＳＣＳＩターゲットモジュール３３５として実施される場合がある。ｖｄｉｓｋモジュールは、ユーザ（システム管理者）がノード２００に対して発行したコマンドに応答して、管理フレームワーク１１１０(図１参照）のユーザインタフェースのような管理インタフェースによるアクセスを有効化する。ＳＣＳＩターゲットモジュール３３５は通常、ＦＣドライバ２３０、ｉＳＣＳＩドライバ３２８と、ファイルシステム３６０との間に配置され、ブロック（ＬＵＮ）空間とファイルシステム空間との間に、仮想化システムの変換層を提供する。その際、ＬＵＮは、ブロックとして表現される。
【００２５】
ファイルシステム３６０は、例えば、ディスクのような記憶装置に格納された情報のアクセスに使用される論理ボリューム管理機能を提供するメッセージベースのシステムである。つまり、ファイルシステム３６０は、ファイルシステムセマンティックを提供するだけでなく、通常ならばボリューム・マネージャに関わる機能も提供する。そのような機能には、（１）ディスクの集合化、（２）ディスクの記憶帯域幅の集合化、（３）ミラーリング、及び／又はパリティ（ＲＡＩＤ）のような信頼性保証がある。
ファイルシステム３６０は、例えばＷＡＦＬファイルシステム（以後、一般に「ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム」）を実施する場合があり、このファイルシステムは、例えば、４キロバイト（ｋＢ）ブロックを使用し、インデックスノード（「ｉｎｏｄｅ」）を使用してファイルやファイル属性（例えば、作成時刻、アクセス・パーミッション、サイズ、及びブロック位置など）を識別するオン・ディスク・フォーマット表現を有する。ファイルシステムは、ファイルを使用して、自分のファイルシステムのレイアウトを表わすメタデータを格納する。そのようなメタデータファイルには、特に、ｉｎｏｄｅファイルがある。ディスクからｉｎｏｄｅを読み出すために、ファイルハンドル、すなわちｉｎｏｄｅ番号を含む識別子が使用される。
【００２６】
簡単に言えば、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの全てのｉｎｏｄｅは、ｉｎｏｄｅファイルの中に編成される。ファイルシステム（ｆｓ）ｉｎｆｏブロックは、ファイルシステム中の情報のレイアウトを指定するものであり、そのファイルシステムの他の全てのｉｎｏｄｅを含むファイルのｉｎｏｄｅを有する。各論理ボリューム（ファイルシステム）はｆｓｉｎｆｏブロックを有し、ｆｓｉｎｆｏブロックは、例えばＲＡＩＤグループ中の固定位置に格納されることが好ましい。ｉｎｏｄｅファイルのｉｎｏｄｅは、ｉｎｏｄｅファイルのデータブロックを直接参照する（指し示す）場合もあれば、ｉｎｏｄｅファイルの間接ブロックを参照し、更にｉｎｏｄｅファイルのデータブロックを参照する場合もある。ｉｎｏｄｅファイルの各データブロックの中にはｉｎｏｄｅが埋め込まれ、各ｉｎｏｄｅは、間接ブロックを参照し、さらにファイルのデータブロックを参照する場合がある。
【００２７】
動作時には、クライアント１８０からの要求は、コンピュータ・ネットワーク１４０を介してパケットとしてｉｎｏｄｅ２００へ転送され、ｉｎｏｄｅ２００はそれをネットワークアダプタ２２５で受信する。（層３１２や層３３０の）ネットワークドライバは、そのパケットを処理し、必要に応じて、それをネットワークプロトコル、及びファイルアクセス層に渡し、更なる処理を施してから、それをｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム３６０へ転送する。その際、ファイルシステムは、要求されたデータが「コア内」に、すなわちメモリ２２４上になければ、要求されたデータをディスク１３０からロードする（読み出す）ためのオペレーションを生成する。要求された情報がメモリ上になければ、ファイルシステム３６０は、ｉｎｏｄｅ番号を使用してｉｎｏｄｅファイル内を検索し、適当なエントリにアクセスし、論理ｖｂｎを読み出す。そして、ファイルシステムは、その論理ｖｂｎを含むメッセージ構造をＲＡＩＤシステム３８０に渡す。論理ｖｂｎは、ディスク識別子、及びディスクブロック番号（ディスク、ｄｂｎ）にマッピングされ、ディスクドライバシステム３９０の適当なドライバ（例えば、ＳＣＳＩ）に送信される。ディスクドライバは、指定されたディスク１３０からｄｂｎを取得し、要求されたデータブロック（複数の場合もあり）をメモリにロードし、そのノードで処理する。要求の処理が終わると、ノード（及び、オペレーティングシステム）は、ネットワーク１４０を介してクライアント１８０に返答を返す。
【００２８】
なお、ノードで受信されたクライアント要求に対し、実施する必要がある上記のストレージ・オペレーティング・システム層を貫通するソフトウェア「パス」は、代わりに、ハードウェアで実施してもよい。つまり、本発明の代替実施形態では、ストレージアクセス要求データパスは、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）の中に実現される論理回路として実施される場合がある。この種のハードウェア実施形態によれば、クライアント１８０により発行された要求に応答してノード２００により提供されるストレージサービスの性能を向上させることができる。また、本発明の更に別の実施形態では、アダプタ２２５、２２８の処理要素は、プロセッサ２２２からパケット処理オペレーションやストレージ・アクセス・オペレーションの負荷の一部、または全部を取り除くように構成される場合があり、それによって、ノードによって提供されるストレージサービスの性能を向上させることができる。当然ながら、本明細書に記載する種々の処理、アーキテクチャ、及び手順は、ハードウェアで実施しても、ファームウェアで実施しても、ソフトウェアで実施してもよい。
【００２９】
本明細書では、「ストレージ・オペレーティング・システム」という用語は通常、データアクセスを管理するためのストレージ機能を実施するために、コンピュータ上で実行されるコンピュータ実行可能コードを意味し、ノード２００の場合、このコンピュータ実行可能コードは、汎用オペレーティングシステムのデータ・アクセス・セマンティックを実施する場合がある。また、ストレージ・オペレーティング・システムは、マイクロカーネルとして実施してもよいし、ＵＮＩＸやＷｉｎｄｏｗｓ  ＮＴのような汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施してもよいし、本明細書に記載するストレージ・アプリケーションのために構成された構成変更機能を備えた汎用オペレーティングシステムとして実施してもよい。
【００３０】
さらに、当業者には分かるように、本明細書に記載する発明は、ストレージシステムを含む、又はストレージシステムとして実施される、スタンドアロンのコンピュータやその一部を含めて、いかなるタイプの特殊目的（例えば、ファイルサーバ、ファイラ、又はストレージサービスを提供する装置）のコンピュータ、及び汎用コンピュータにも適用することができる。さらに、本発明の教示は、種々のストレージシステムアーキテクチャに適合させることができ、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及びクライアントやホストコンピュータに直接取り付けられたディスクアセンブリ等に適合させることができる。したがって、「ストレージシステム」という用語を使用した場合でも、この用語は、ストレージ機能を実施するように構成された任意のサブシステムだけでなく、そのような構成も含むものとして、広い意味で解釈しなければならない。なお、本明細書の説明は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムに関するものとして書かれているが、本発明の教示は、ｗｒｉｔｅ  ｉｎ  ｐｌａｃｅファイルシステムを含む、任意の適当なファイルシステムに適用することができる。
【００３１】
Ｄ．ＣＦプロトコル
一実施形態において、ストレージサーバ３６５は、アレイ１２０の１以上のボリュームを提供するストレージ・オペレーティング・システム３００のＤブレード３５０として実施される。また、マルチプロトコル・エンジン３２５はＮブレード３１０として実施され、（１）ネットワークを介して到来した、クライアントにより発行されたデータアクセス要求パケットに対してプロトコル・ターミネーションを実施し、（２）それらのデータアクセス要求をクラスタ１００の任意のストレージサーバ３６５にリダイレクトする。さらに、Ｎブレード３１０とＤブレード３５０は協働し、クラスタ１００の非常に高いスケーラビリティを有する分散ストレージシステムアーキテクチャを提供する。その目的のために、各ブレードは、本明細書に記載するデータコンテナ・ストライピング・オペレーションのためのＤブレード間通信のような、クラスタ内でのブレード間通信を実施するように構成されたクラスタ・ファブリック（ＣＦ）インタフェース・モジュール３４０ａ，ｂを含む。
【００３２】
Ｎブレード３１０の例えばＮＦＳ／ＣＩＦＳ層やｉＳＣＳＩ／ＦＣ層のようなプロトコル層は、クライアントからのファイルベースの、又はブロックベースのデータアクセス要求を、Ｄブレード３５０との通信に使用されるＣＦプロトコルメッセージに変換するプロトコルサーバとして機能する。すなわち、Ｎブレードサーバは、到来したデータアクセス要求を、クラスタ１００のＤブレード３５０へ伝送するために、ＣＦインタフェースモジュール３４０によって、ＣＦメッセージに埋め込まれたファイルシステム・プリミティブ・オペレーション（コマンド）に変換する。特に、複数のＣＦインタフェースモジュール３４０が協働し、クラスタ１００内の全てのＤブレード３５０にまたがる単一のファイルシステムイメージを提供する。したがって、クライアント要求を受信するＮブレードのネットワークポートはすべて、そのクラスタの任意のＤブレード３５０上にある単一のファイルシステムイメージ中のいずれのコンテナにもアクセスすることができる。
【００３３】
例示的実施形態に関し、Ｎブレード３１０とＤブレード３５０は、ストレージ・オペレーティング・システム３００の個別にスケジューリングされたプロセスとして実施される。しかしながら、代替実施形態では、それらのブレードは、単一のオペレーティングシステムプロセス内のコード片として実施される場合がある。したがって、ＮブレードとＤブレードとの間の通信は、例えば、それらのブレード間で受け渡されるメッセージの使用によって達成される。しかしながら、異なるノードにあるＮブレードとＤブレードとの間のリモート通信の場合、そのようなメッセージの受け渡しは、クラスタ切り替え装置１５０を介して実施される。ブレード（プロセス）間で情報をやりとりするためにストレージ・オペレーティング・システムによって提供される既知のメッセージ受け渡しメカニズムは、プロセス間通信（ＩＰＣ）メカニズムである。ＩＰＣメカニズムで使用されるプロトコルは、例えば、汎用のファイルベース、及び／又はブロックベースの「不可知論的」ＣＦプロトコルであり、このプロトコルは、ＣＦアプリケーション・プログラミング・インタフェース（ＡＰＩ）を構成する一群の方法／機能からなる。そのような不可知論的プロトコルの例としては、ネットワーク・アプライアンス・インコーポレイテッドから市販されているＳｐｉｎＦＳプロトコルやＳｐｉｎＮＰプロトコルがある。ＳｐｉｎＦＳプロトコルについては、上で参照した米国特許出願公開公報第ＵＳ２００２／０１１６５９３号に記載されている。
【００３４】
ＣＦインタフェースモジュール３４０は、クラスタ１００のブレード間でファイルシステムコマンドをやりとりするためのＣＦプロトコルを実施する。通信は、例えば、Ｎブレード（又は他のＤブレード）が発行する呼び出しの宛先となるＣＦ  ＡＰＩを露出しているＤブレードによって実施される。その目的のために、ＣＦインタフェースモジュール３４０は、ＣＦエンコーダ、及びＣＦデコーダとして編成される。例えばＮブレード３１０上のＣＦインタフェース３４０ａのＣＦエンコーダは、（１）同じノード２００上にあるＤブレード３５０にファイルシステムコマンドを送るときは、ＣＦメッセージをローカル・プロシージャ・コール（ＬＰＣ）としてカプセル化し、（２）クラスタ１００のリモートノードにあるＤブレードにファイルシステムコマンドを送るときは、ＣＦメッセージをのリモート・プロシージャ・コール（ＲＰＣ）としてカプセル化する。いずれの場合も、Ｄブレード３５０上のＣＦインタフェース３４０ｂのＣＦデコーダは、そのＣＦメッセージのカプセル化を解除し、ファイルシステムコマンドを処理する。
【００３５】
図４は、本発明の一実施形態によるＣＦメッセージ４００のフォーマットを示す略ブロック図である。ＣＦメッセージ４００は、例えば、クラスタ１００のリモートブレード間における、切り替え装置１５０を介したＲＰＣ通信に使用される。ただし、「ＣＦメッセージ」という用語は通常、クラスタのブレード間におけるＬＰＣ通信、及びＲＰＣ通信を指すものとして使用される。ＣＦメッセージ４００は、メディアアクセス層４０２、ＩＰ層４０４、ＵＤＰ層４０６、信頼性接続（ＲＣ）層４０８、及びＣＦプロトコル層４１０を含む。上記のように、ＣＦプロトコルは、クライアント要求に含まれる、クラスタ１００上に格納されたデータコンテナにアクセスするためのオペレーションに関連するファイルシステムコマンドを運ぶための汎用ファイルシステムプロトコルである。ＣＦプロトコル層４１０は、そのようなファイルシステムメッセージを有するメッセージ４００の部分である。例えば、ＣＦプロトコルは、データグラムに基づき、したがって、ソース（例えば、Ｎブレード３１０）から宛先（例えば、Ｄブレード３５０）へ信頼性の高い態様でメッセージ、または「エンベロープ」を伝送する必要がある。ＲＣ層４０８は、ＵＤＰ４０６のようなコネクションレスのプロトコルにしたがって、そのようなエンベロープを処理するように構成された信頼性の高いトランスポートプロトコルを実施する。
【００３６】
ファイルシステム中の例えばファイルのようなデータコンテナは、データコンテナハンドルを使用してアクセスされる。図５は、ＳＶＳ  ＩＤフィールド５０２、ｉｎｏｄｅ番号フィールド５０４、一意の識別子フィールド５０６、ストライプ化フラグフィールド５０８、及びストライピング・エポック番号・フィールド５１０を有するデータコンテナハンドル５００のフォーマットを示している。ＳＶＳ  ＩＤフィールド５０２は、ＳＶＳの（クラスタ１００内の）グローバル識別子を有し、その中に、データコンテナがある。ｉｎｏｄｅ番号フィールド５０４は、そのデータコンテナに関する（ｉｎｏｄｅファイル内の）ｉｎｏｄｅのｉｎｏｄｅ番号を有する。一意の識別子フィールド５０６は、そのデータコンテナハンドル５００を一意に識別する単調増加番号を有する。この一意の識別子は、特に、ｉｎｏｄｅ番号が削除され、再使用され、新たなデータコンテナに再割り当てされるときに有用である。一意の識別子は、特定のデータコンテナ中のその再使用されたｉｎｏｄｅ番号を、それらのフィールドに以前使用された可能性があるものから区別する。ストライプ化フラグフィールド５０８は、例えば、そのデータコンテナがストライピングされているか否かを識別するブール値を有する。ストライピング・エポック番号・フィールド５１０は、ＳＶＳが、異なるデータコンテナに対し、異なるストライピング技術を使用するような実施形態の場合に、データコンテナとともに使用される適当なストライピング技術を示す。
【００３７】
Ｅ．ファイルシステム編成
例示的実施形態として、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムでは、データコンテナは、ディスク１３０に格納されるｉｎｏｄｅデータ構造として表現される。図６は、ｉｎｏｄｅ６００を示す略ブロック図であり、ｉｎｏｄｅ６００は、メタデータ部６０５、及びデータ部６６０を有することが望ましい。各ｉｎｏｄｅ６００のメタデータ部６０５に格納される情報は、データコンテナ(例えば、ファイル）を表わし、したがって、ファイルのタイプ（例えば、通常、ディレクトリ、ｖｄｉｓｋ）、ファイルのサイズ６１５、タイムスタンプ（例えば、アクセス時刻、及びまたは変更時刻）、並びに、そのファイルの所有者、すなわちユーザＩＤ（ＵＩＤ）、及びグループＩＤ（ＧＩＤ）を含む。また、メタデータ部６０５は、生成番号６３１、及びメタデータ無効フラグフィールド６３４を更に含む。後で詳しく説明するように、メタデータ無効フラグフィールド６３４は、このｉｎｏｄｅ中のメタデータが使用可能であるか否か、すなわち、メタデータをＭＤＶから再取得しなければならないか否かを示すために使用される。各ｉｎｏｄｅのデータ部６６０の中身は、タイプフィールド６１０の中に規定されたそのファイル（ｉｎｏｄｅ）のタイプに応じて、異なる解釈をされる場合がある。例えば、ディレクトリｉｎｏｄｅのデータ部６６０は、ファイルシステムによって制御されるメタデータを有する一方、通常ｉｎｏｄｅのデータ部は、ファイルシステムデータを有する場合がある。後者の場合、データ部６６０は、そのファイルに関連するデータの表現を含む。
【００３８】
具体的には、通常のディスク上のｉｎｏｄｅのデータ部６６０は、ファイルシステムデータ、またはポインタを含む場合があり、後者は、そのファイルシステムデータの格納に使用される、ディスク上の４ｋＢデータブロックを指し示す。ディスク上のデータをアクセスするときの、ファイルシステムとＲＡＩＤシステム３８０との間の効率を向上させるために、各ポインタは論理ｖｂｎであることが好ましい。ｉｎｏｄｅのサイズに制限がある場合（例えば、１２８バイト）、６４バイト以下のサイズのファイルシステムデータは、その全部が、そのｉｎｏｄｅのデータ部の中に表現される。しかしながら、データコンテナの中身の長さが６４バイトよりも長く、６４ｋＢ以下である場合、そのｉｎｏｄｅのデータ部（例えば、第１レベルｉｎｏｄｅ）は、最大で１６個のポインタを有し、各ポインタが、ディスク上の４ｋＢブロックのデータを参照する。
【００３９】
また、データのサイズが６４ｋＢよりも大きく、且つ、６４メガバイト（ＭＢ）以下であった場合、ｉｎｏｄｅ（例えば、第２レベルｉｎｏｄｅ）のデータ部６６０内の各ポインタは、１０２４個のポインタを有する間接ブロック（例えば、第１レベルブロック）を参照し、各ポインタが、ディスク上の４ｋＢのデータブロックを参照する。６４ＭＢを超えるサイズのファイルシステムデータに関しては、ｉｎｏｄｅ（例えば、第３レベルｉｎｏｄｅ）のデータ部６６０内の各ポインタは、１０２４個のポインタを有する二重間接ブロック（例えば、第２レベルＬ２ブロック）を参照し、各ポインタが、間接（例えば、第１レベルＬ１）ブロックを参照する。さらに、その間接ブロックは、１０２４個のポインタを有し、各ポインタが、ディスク上の４ｋＢデータブロックを参照する。ファイルをアクセスする場合、そのファイルの各ブロックは、ディスク１３０からメモリ２２４へとロードされる場合がある。
【００４０】
ディスク上のｉｎｏｄｅ（または、ブロック）がディスク１３０からメモリ２２４へとロードされるとき、それに対応するコア内構造が、そのディスク上の構造に埋め込まれる。例えば、破線で囲まれたｉｎｏｄｅ６００は、ディスク上のｉｎｏｄｅ構造のコア内表現を示している。コア内構造は、ディスク上の構造、及び、メモリ上にある（ただし、ディスク上にない）データを管理するために必要とされる補助的情報を格納するためのメモリブロックである。この補助的情報には、例えば、「ダーティ」ビット６７０がある。例えば書き込みオペレーションによる命令にしたがってｉｎｏｄｅ（又はブロック）内のデータが更新／変更された後、変更されたデータは、ダーティビット６７０を使用して「汚れたもの」としてマーキングされ、その結果、そのｉｎｏｄｅ（ブロック）は、その後、ディスクに「フラッシュする」（書き込む）ことができるようになる。ｉｎｏｄｅ、及びｉｎｏｄｅファイルを含む、ＷＡＦＬファイルシステムのコア内フォーマット構造、及びディスク上のフォーマット構造については、１９９８年１０月６日に発行されたDavid Hitz他による「METHOD FOR MAINTAINING CONSISTENT STATES OF A FILE SYSTEM AND FOR CREATING USER-ACCESSIBLE READ-ONLY COPIES OF A FILE SYSTEM」と題する、上で援用した米国特許第５、８１９，２９２号に開示、及び記載されている。
【００４１】
図７は、本発明とともに有利に使用されるファイルのバッファ・ツリーの一実施形態を示す略ブロック図である。バッファ・ツリーは、メモリ２２４にロードされ、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム３６０によって管理されるファイル（例えば、ファイル７００）のブロックの内部表現である。埋め込みｉｎｏｄｅのようなルート（トップレベル）ｉｎｏｄｅ７０２は、間接（例えば、レベル１）ブロック７０４を参照する。なお、ファイルのサイズによっては、更に別のレベル（例えば、レベル２やレベル３）の間接ブロックが存在する場合もある。間接ブロック（及び、ｉｎｏｄｅ）は、ファイルの実際のデータの格納に使用されるデータブロック７０６を最終的に参照するポインタ７０５を有する。すなわち、ファイル７００のデータは、データブロックに格納され、それらのブロックの位置が、そのファイルの間接ブロックに格納される。各レベル１間接ブロック７０４は、１０２４個ものデータブロックへのポインタを有する場合がある。ファイルシステムの「ｗｒｉｔｅ  ａｎｙｗｈｅｒｅ」な性質によれば、それらのブロックは、ディスク１３０上の如何なる場所に置かれる場合もありうる。
【００４２】
基礎となる物理ボリュームをノード２００のようなストレージシステムの１以上の仮想ボリューム（又は、フレキシブルボリューム）に分配するファイルシステムレイアウトが、使用される。そのようなファイルシステムレイアウトの一例は、John K. Edwards他により出願され、ネットワーク・アプライアンス・インコーポレイテッドに譲渡された「EXTENSION OF WRITE ANYWHERE FILE SYSTEM LAYOUT」と題する米国特許出願第１０／８３６，８１７号に記載されている。基礎となる物理ボリュームは、ノードの１以上のＲＡＩＤグループのようなグループのディスクを含む集合体である。集合体は、その集合体独自の物理ボリュームブロック番号（ｐｖｂｎ）空間を有し、ｐｖｂｎ空間内において、ブロックアロケーション構造のようなメタデータを管理する。各フレキシブルボリュームは、そのボリューム独自の仮想ボリュームブロック番号（ｖｖｂｎ）空間を有し、ｖｖｂｎ空間内において、ブロックアロケーション構造のようなメタデータを管理する。各フレキシブルボリュームは、コンテナファイルに関連するファイルシステムである。コンテナファイルは、フレキシブルボリュームによって使用される全てのブロックを含む、集合中のファイルである。さらに、各フレキシブルボリュームは、データブロック、及び、他の間接ブロック又はデータブロックを指し示すブロックポインタを有する間接ブロックを含む。
【００４３】
一実施形態において、ｐｖｂｎは、フレキシブルボリュームに格納された（例えば、ファイル７００のような）ファイルのバッファ・ツリー内でブロックポインタとして使用される。この「ハイブリッド」フレキシブルボリューム実施形態では、親間接ブロック（例えば、ｉｎｏｄｅ、又は間接ブロック）にｐｖｂｎを挿入することしか必要としない。論理ボリュームの読み出しパス上において、「論理」ボリューム（ｖｏｌ）ｉｎｆｏブロックは、１以上のｆｓｉｎｆｏブロックを参照する１以上のポインタを有し、さらに、各ｆｓｉｎｆｏブロックは、ｉｎｏｄｅファイル、及びそれに対応するｉｎｏｄｅバッファ・ツリーを指し示す。ブロックの適当な位置を見付けるためのｐｖｂｎ（ｖｖｂｎではなく）に習って、フレキシブルボリューム上の読み出しパスは通常、同じである。この文脈において、フレキシブルボリュームの読み出しパス（及び、対応する読み出し性能）は、物理ボリュームのものと実質的に同じである。ｐｖｂｎからディスク、ｄｂｎへの変換は、ストレージ・オペレーティング・システム３００のファイルシステム／ＲＡＩＤシステム境界において行われる。
【００４４】
例示的なデュアルｖｂｎ・ハイブリッド・フレキシブルボリューム実施形態では、ｐｖｂｎとそれに対応するｖｖｂｎとの両方が、ファイルのバッファ・ツリー内の親間接ブロックに挿入される。すなわち、例えば、レベル１（Ｌ１）間接ブロックやｉｎｏｄｅファイルレベル０（Ｌ０）ブロックのような他のブロックへのポインタを有する大半のバッファ・ツリー構造では、各ブロックポインタについて、ｐｖｂｎとｖｖｂｎがペアとして格納される。図８は、本発明とともに有利に使用されるファイル８００のバッファ・ツリーの一実施形態を示す略ブロック図である。埋め込みｉｎｏｄｅのようなルート（トップレベル）ｉｎｏｄｅ８０２は、間接（例えば、レベル１）ブロック８０４を参照する。なお、ファイルのサイズによっては、さらに別のレベル(例えば、レベル２やレベル３）の間接ブロックが存在する場合もある。間接ブロック（及び、ｉｎｏｄｅ）は、ファイルの実際のデータの格納に使用されるデータブロック８０６を最終的に参照するｐｖｂｎ／ｖｖｂｎポインタ対構造８０８を有する。
【００４５】
ｐｖｂｎは、集合体のディスク上の位置を参照する一方、ｖｖｂｎは、フレキシブルボリュームのファイル内の位置を参照する。間接ブロック８０４におけるブロックポインタのようなｐｖｂｎの使用は、読み出しパス上の効率を提供する一方、ｖｖｂｎブロックポインタの使用は、要求されたメタデータへの効率的なアクセスを提供する。すなわち、ファイルのブロックを開放するとき、そのファイル中の親間接ブロックは、ｖｖｂｎブロックポインタを即座に使用することができ、それによって、ｐｖｂｎからｖｖｂｎへの変換のための所有者マップへのアクセスに伴う待ち時間を回避することができ、それでも、読み出しパス上で、ｐｖｂｎを使用することが可能となる。
【００４６】
図９は、本発明とともに有利に使用される集合体９００の一実施形態を示す略ブロック図である。ＬＵＮ（ブロック）９０２、ディレクトリ９０４、ｑｔｒｅｅ９０６、及びファイル９０８は、例えばデュアルｖｂｎフレキシブルボリュームのようなフレキシブルボリューム９１０の中に格納され、さらに、集合体９００の中に格納される場合がある。集合体９００は、例えば、ＲＡＩＤシステムの最上部に層として形成される。ＲＡＩＤシステムは、少なくとも１つのＲＡＩＤプレックス９５０によって表わされ（ストレージ構成がミラーリングされているか否かに応じて）、各プレックス９５０は、少なくとも１つのＲＡＩＤグループ９６０を含む。各ＲＡＩＤグループは、複数のディスク９３０を含み、例えば、１以上のデータ（Ｄ）ディスク、及び少なくとも１つのパリティ（Ｐ）ディスクを含む場合がある。
【００４７】
集合体９００は、従来のストレージシステムの物理ボリュームに似たものである一方、フレキシブルボリュームは、その物理ボリューム内のファイルに似たものである。すなわち、集合体９００は、１以上のファイルを含む場合があり、各ファイルはフレキシブルボリュームを含み、フレキシブルボリュームによって消費される記憶空間の合計は、物理ボリューム全体のサイズよりも物理的に小さい（又は、それに等しい）。集合体は、物理ボリュームのディスクにより提供されるブロックの記憶空間を規定する「物理的」なｐｖｂｎ空間を使用する一方、（ファイル内の）各埋め込みフレキシブルボリュームは、例えばファイルのようなそれらのブロックを編成するために「論理的」なｖｖｂｎ空間を使用する。各ｖｖｂｎ空間は、ファイル内の複数の位置に対応する独立した一組の数であり、その後、それらの位置は、ディスク上のｄｂｎに変換される。フレキシブルボリューム９１０は、論理ボリュームでもあるため、そのボリューム独自のｖｖｂｎ空間中に、そのボリューム独自のブロックアロケーション構造（例えば、アクティブマップ、空間マップ、及び概要マップ）を有する。
【００４８】
コンテナファイルは、フレキシブルボリュームによって使用されるすべてのブロックを有する、集合体中のファイルである。コンテナファイルは、フレキシブルボリュームをサポートする内部機能（集合体にとって）であり、例えば、１つのフレキシブルボリュームあたり１つのコンテナファイルが存在する。ファイルアプローチにおける純粋な論理ボリュームと同様に、コンテナファイルもまた、フレキシブルボリュームによって使用されているあらゆるブロックを保持する、集合体中の隠しファイルである。集合体は、例えば、ＷＡＦＬ／ｆｓｉｄ／ファイルシステムファイル、及びストレージラベルファイルのようなフレキシブルボリュームのサブディレクトリを含む隠しメタデータルートディレクトリを含む。
【００４９】
具体的には、物理的ファイルシステム（ＷＡＦＬ）ディレクトリは、集合体中の各フレキシブルボリュームについてサブディレクトリを有し、サブディレクトリの名前は、そのフレキシブルボリュームのファイルシステム識別子（ｆｓｉｄ）になっている。各ｆｓｉｄサブディレクトリ（フレキシブルボリューム）は、少なくとも２つのファイル、すなわち、ファイルシステムファイルとストレージラベルファイルを有する。ストレージラベルファイルは、例えば、従来のＲＡＩＤラベルに格納されているものと同様のメタデータを有する４ｋＢファイルである。言い換えれば、ストレージラベルファイルは、ＲＡＩＤラベルに似たものであり、したがって、例えば、フレキシブルボリュームの名前、フレキシブルボリュームの世界的に一意な識別子（ｕｕｉｄ）やｆｓｉｄ、フレキシブルボリュームがオンラインであるか、作成中であるか、又は破壊中であるか等、フレキシブルボリュームの状態に関する情報を有する。
【００５０】
図１０は、集合体１０００のオン・ディスク表現を示す略ブロック図である。例えばＲＡＩＤシステム３８０のようなストレージ・オペレーティング・システム３００は、集合体１０００を作成するために、ｐｖｂｎの物理ボリュームを組み立てる。その際、ｐｖｂｎ１、及び２は、その集合体に関する「物理的」ｖｏｌｉｎｆｏブロック１００２を含む。ｖｏｌｉｎｆｏブロック１０２は、ｆｓｉｎｆｏブロック１００４へのブロックポインタを有し、各ブロックポインタは、集合体のスナップショットを表わす場合がある。各ｆｓｉｎｆｏブロック１００４は、ｉｎｏｄｅファイル１００６へのブロックポインタを含み、ｉｎｏｄｅファイル１００６は、所有者マップ１０１０、アクティブマップ１０１２、概要マップ１０１４、及び空間マップ１０１６、並びに他の特殊なメタデータファイルのような複数のファイルのｉｎｏｄｅを有する。ｉｎｏｄｅファイル１００６は、ルートディレクトリ１０２０、及び「隠し」メタデータルートディレクトリ１０３０を更に含み、後者は、ユーザがファイルを見ることができないフレキシブルボリュームに関連するファイルを有する名前空間を有する。この隠しメタデータルートディレクトリは、ファイルシステムファイル１０４０、及びストレージラベルファイル１０９０を有するＷＡＦＬ／ｆｓｉｄ／ディレクトリ構造を含む。なお、集合体中のルートディレクトリ１０２０は空であり、集合体に関連するファイルは全て、隠しメタデータルートディレクトリ１０３０の中に編成される。
【００５１】
ファイルシステム１０４０は、コンテナマップとして編成されたレベル１ブロックを有するコンテナファイルとして実施されるだけでなく、フレキシブルボリューム１０５０として実施される種々のファイルシステムを参照するブロックポインタを含む。集合体１０００は、それらのフレキシブルボリューム１０５０を特殊な予約されたｉｎｏｄｅ番号に維持する。各フレキシブルボリューム１０５０はさらに、自分のフレキシブルボリューム空間の中に、特殊な予約されたｉｎｏｄｅ番号を有する。それらのｉｎｏｄｅ番号は、とりわけ、ブロックアロケーションビットマップ構造のために使用される。上記のように、アクティブマップ１０６２、概要マップ１０６４、及び空間マップ１０６６のようなブロックアロケーションビットマップ構造は、各フレキシブルボリュームに配置される。
【００５２】
特に、各フレキシブルボリューム１０５０は、集合体と同じｉｎｏｄｅファイル構造／内容を有する。ただし、隠しメタデータルートディレクトリ１０８０の中に、所有者マップ、ＷＡＦＬ／ｆｓｉｄ／ファイルシステムファイル、及びストレージラベルファイルディレクトリ構造は存在しない。その目的のために、各フレキシブルボリューム１０５０は、１以上のｆｓｉｎｆｏブロック１０５４を指し示すｖｏｌｉｎｆｏブロック１０５２を有し、各ｆｓｉｎｆｏブロック１０５４は、そのフレキシブルボリュームのアクティブファイルシステムとともに、スナップショットを表わす場合がある。さらに、各ｆｓｉｎｆｏブロックは、上記のような例外を除き、集合体と同じｉｎｏｄｅ構造／中身を有するｉｎｏｄｅファイル１０６０を指し示す。各フレキシブルボリューム１０５０は、そのボリューム独自のｉｎｏｄｅファイル１０６０、及び対応するｉｎｏｄｅ番号を有する個別のｉｎｏｄｅ空間を有し、さらに、そのボリューム独自のルート（ｆｓｉｄ）ディレクトリ１０７０、及び、他のフレキシブルボリュームとは無関係にエキスポートすることが可能なファイルのサブディレクトリを有する。
【００５３】
集合体の隠しメタデータルートディレクトリ１０３０の中に格納されるストレージラベルファイル１０９０は、従来のＲＡＩＤラベルに似た働きをする小さなファイルである。ＲＡＩＤラベルは、ボリューム名のようなそのストレージシステムに関する物理的情報を含み、その情報が、ストレージラベルファイル１０９０の中にロードされる。例えば、ストレージラベルファイル１０９０は、関連フレキシブルボリューム１０５０の名前１０９２、そのフレキシブルボリュームのオンライン／オフライン状態１０９４、及び、その関連フレキシブルボリュームの他の識別、及び状態情報１０９６（そのボリュームが作成中であるか、破壊中であるか）を含む。
【００５４】
Ｆ．ＶＬＤＢ
図１１は、クラスタのノードに関する構成情報（すなわち、管理データ）を管理するために、ストレージ・オペレーティング・システム３００上でユーザ・モード・アプリケーション１１００として実行される一群の管理プロセスを示す略ブロック図である。その目的のために、管理プロセスは、管理フレームワークプロセス１１１０、及びボリューム位置データベース（ＶＬＤＢ）プロセス１１３０を含み、これらはそれぞれ、ライブラリとしてリンクされたデータ複製サービス（ＲＤＢ１１５０）を利用する。管理フレームワーク１１１０は、ユーザに対し、コマンドラインインタフェース（ＣＬＩ）、及び／又はウェブベースのグラフィカルユーザインタフェース（ＧＵＩ）による管理者１１７０インタフェースを提供する。この管理フレームワークは、例えば、従来のコモン・インタフェース・モデル（ＣＩＭ）オブジェクトマネージャに基づくものであり、このオブジェクトマネージャは、ノード２００と対話するユーザ／システム管理者に対し、クラスタ１００を管理するためのエンティティを提供する。
【００５５】
ＶＬＤＢ１１３０は、クラスタ１００内の種々の記憶要素（例えば、ＳＶＳ、フレキシブルボリューム、集合体など）の位置を追跡記録することにより、クラスタ全体を通じた要求のルーティングを可能にするデータベースプロセスである。例示的実施形態として、各ノードのＮブレード３１０は、データベース・コンテナ・ハンドル５００のＳＶＳ  ＩＤ５２を、クラスタ内でそのデータコンテナを「所有」（提供）するＤブレード３５０にマッピングする設定テーブル２３５にアクセスする。ＶＬＤＢは、複数のエントリを有し、さらに、設定テーブル２３５内のエントリの中身を提供し、とりわけ、それらのＶＬＤＢエントリは、そのクラスタ内のフレキシブル・ボリューム（以後、まとめて「ボリューム９１０」）、及び集合体９００の位置を追跡記録する。そのようなＶＬＤＢエントリの例には、ＶＬＤＢボリュームエントリ１２００やＶＬＤＢ集合体エントリ１３００がある。
【００５６】
図１２は、例示的なＶＬＤＢボリュームエントリ１２００を示す略ブロック図である。エントリ１２００は、ボリュームＩＤフィールド１２０５、集合体ＩＤフィールド１２１０を含み、代替実施形態では、更に別のフィールド１２１５を含む場合がある。ボリュームＩＤフィールド１２０５は、ボリューム位置プロセスにおいて使用されるボリューム９１０を識別するＩＤを有する。集合体ＩＤフィールド１２１０は、ボリュームＩＤフィールド１２０５によって識別されるボリュームを含む集合体９００を識別する。同様に、図１３は、ＶＬＤＢ集合体エントリ１３００の例を示す略ブロック図である。エントリ１３００は、集合体ＩＤフィールド１３０５、ＤブレードＩＤフィールド１３１０を含み、代替実施形態では、更に別のフィールド１３１５を含む場合がある。集合体ＩＤフィールド１３０５は、クラスタ１００中の特定の集合体９００のＩＤを有する。ＤブレードＩＤフィールド１３１０は、集合体ＩＤフィールド１３０５によって識別される特定の集合体を有するＤブレードのＩＤを有する。
【００５７】
ＶＬＤＢは例えば、例えばＳｕｎ  ＲＰＣインタフェースのようなＲＰＣインタフェースを実施し、それによって、Ｎブレード３１０は、ＶＬＤＢ１１３０に問い合わせをすることができる。Ｎブレードは、自分の設定テーブル中に記憶されていないデータコンテナ・ハンドル５００の中身に遭遇すると、ＲＰＣをＶＬＤＢプロセスに送信する。これに応答してＶＬＤＢ１１３０は、そのデータコンテナを有しているＤブレードのＩＤを含む、適当なマッピング情報をＮブレードに返す。Ｎブレードは、その情報を自分の設定テーブル２３５に格納し、ＤブレードＩＤを使用して、到来した要求を適当なデータコンテナに転送する。Ｎブレード３１０、及びＤブレード３５０機能、並びにそれらの間における通信は、一群の管理プロセス、及びＲＤＢライブラリ・ユーザモード・アプリケーション１１００によって、クラスタ幅ごとに調整される。
【００５８】
その目的のために、管理プロセスは、ＲＤＢ１１５０に対するインタフェースを備える（管理プロセスは、ＲＤＢ１１５０に非常に密接に結合される）。ＲＤＢは、管理プロセスによって処理される管理データの永久的オブジェクト記憶（オブジェクトの記憶）を提供するライブラリからなる。特に、ＲＤＢ１１５０は、クラスタ１００の全ノード２００にわたって、管理データオブジェクト記憶アクセスを複製、及び同期させ、それによって、すべてのノード２００上のＲＤＢデータベースイメージが同じになることを保証する。システム起動時には、各ノード２００が、自分のインタフェースの状態、及びＩＰアドレス（自分が「所有」するＩＰアドレス）をＲＤＢデータベースに記録する。
【００５９】
Ｇ．ストレージ・システム・アーキテクチャ
本発明は、例えばクラスタ１００の複数のノード２００にわたって分散された２以上のボリューム９１０を含むストレージ・システム・アーキテクチャに関する。ボリュームはＳＶＳとして編成され、クライアント１８０により発行されるマルチプロトコル・データ・アクセス・要求に応答して、クラスタによって提供されるファイルやＬＵＮのようなデータコンテナの中身を記憶するように構成される。特に、各データコンテナの中身は、ＳＶＳの複数のボリュームにわたって分配され、それにより、クラスタによって提供されるストレージサービスの効率が向上する。本発明の説明、及び理解を容易にするために、以後、データコンテナは通常、「ファイル」と呼ばれる。
【００６０】
本発明の一態様によれば、ＳＶＳは、１つのメタデータボリューム（ＭＤＶ）と、１以上のデータボリューム（ＤＶ）とを含む。ＭＤＶは、そのＳＶＳ上に格納されるすべてのファイルに関連するアクセスコントロールリスト（ＡＣＬ）やディレクトリのようなメタデータの正規のコピーを記憶するように構成される一方、各ＤＶは、少なくとも、それらのファイルの中身を記憶するように構成される。ＳＶＳ上に格納される各ファイルについて、１つのボリュームはＣＡＶとして指定され、その目的のために、そのボリュームは、そのファイルに関連する高速に変化する特定の属性メタデータを記憶（「キャッシュ」）するように構成され、それによって、通常ならばＭＤＶに向けられるであろうアクセス要求の負荷を軽減する。本明細書に記載する例示的実施形態では、ファイルのＣＡＶの判定は、ファイルの中身（データ）の最初のストライプを保持しているボリュームをそのファイルのＣＡＶとして指定する、という単純なルールに基づいて行われる。この単純なルールは便利なだけでなく、小さなファイルに対する最適化も提供する。つまり、もしファイルが指定されたストライプ幅に納まるくらい十分に小さければ、ＣＡＶは、ＳＶＳの他のボリュームと通信することなく、特定のオペレーションを実施することができる場合がある。理想的には、ファイルのデータの最初の幾つかのストライプは、ＳＶＳの複数のＤＶ間に分配され、それによって、ＳＶＳの複数のボリュームにわたるＣＡＶ指定の均一な分配が可能となる。代替実施形態として、ファイルのデータは、ＭＤＶ、及びＤＶにわたってストライピングされる場合あｇある。
【００６１】
図１４は、本発明の一実施形態によるＳＶＳ１４００のｉｎｏｄｅファイルを示す略ブロック図である。ＳＶＳ１４００は例えば、３つのボリューム、すなわち、ＭＤＶ１４０５と２つのＤＶ１４１０、１４１５からなる。なお、代替実施形態では、更に別の、及び／又は異なるボリュームが、本発明にしたがって使用される場合もある。例えば、ＭＤＶ１４０５は、ルートディレクトリ（ＲＤ）ｉｎｏｄｅ１４２０、ディレクトリ（ＤＩＲ）ｉｎｏｄｅ１４３０、ファイル（Ｆ）ｉｎｏｄｅ１４２５、１４３５、１４４５、及びＡＣＬ  ｉｎｏｄｅ１４４０のような複数のｉｎｏｄｅを格納する。例えば、これらのｉｎｏｄｅはそれぞれ、そのｉｎｏｄｅに関連するメタデータ（Ｍ）を有する場合がある。例示的実施形態として、ＭＤＶ１４０５上の各ｉｎｏｄｅは、データ（Ｄ）を持たない場合がある。ただし、代替実施形態では、ＭＤＶは、ユーザデータを有する場合がある。
【００６２】
これに対し、各ＤＶ１４１０、１４１５は、ファイル（Ｆ）ｉｎｏｄｅ１４２５、１４３５、１４４５、及びＡＣＬ  ｉｎｏｄｅ１４４０だけを格納する。本発明によれば、ＤＶは、ディレクトリや、シンボリックリンクのような他のデバイスｉｎｏｄｅ／構造を格納しない。しかしながら、各ＤＶはＦ  ｉｎｏｄｅを格納し、場合によっては、ＡＣＬ  ｉｎｏｄｅのキャッシュされたコピーを格納し、それらのｉｎｏｄｅは、ＭＤＶ１４０５内の対応するｉｎｏｄｅと同じ位置に配置される。特定のＤＶは、そのｉｎｏｄｅに関連するデータコンテナのＩ／Ｏ要求が、そのＤＶを提供するＤブレードによって受信されるまで、そのｉｎｏｄｅのコピーを記憶しない。また、それらのＦ  ｉｎｏｄｅによって表わされるファイルの中身は、後で詳しく説明するＳＶＳストライピング・ルールにしたがって定期的に分散される。さらに、ＳＶＳ１４００に格納された各ファイルについて１つのボリュームはＣＡＶとして指定されるため、ＤＶ１４１５は、ｉｎｏｄｅ１４２５によって表わされるファイルのＣＡＶとして指定され、ＤＶ１４１０は、ｉｎｏｄｅ１４３５、１４４５により識別されるファイルのＣＡＶとして指定される。したがって、それらのＣＡＶは、例えばファイルサイズ６１５のような、それらのファイルに関連する特定の高速に変化する属性メタデータ（Ｍ）だけでなく、さらに、アクセスタイムスタンプや変更タイムスタンプ６２０もキャッシュする。
【００６３】
本発明の他の態様によれば、ＳＶＳは、ストライプアルゴリズム、ストライプ幅、及びそのＳＶＳ内のボリュームの順序付きリストを規定する一組のルールに関連する。各ＳＶＳについてのそのようなストライピング・ルールは、例えば、ＶＬＤＢ１１３０の１つのエントリとして記憶され、ＳＶＳ  ＩＤによってアクセスされる。図１５は、本発明の一実施形態による例示的ＶＬＤＢ  ＳＶＳエントリ１５００を示す略ブロック図である。ＶＬＤＢエントリ１５００は、１つのＳＶＳ  ＩＤフィールド１５０５と、一組又は複数組のストライピング・ルール１５３０とを含む。代替実施形態では、更に別のフィールド１５３５を有する場合もある。ＳＶＳ  ＩＤフィールド１５０５は、ＳＶＳのＩＤを格納し、このフィールドは、動作時には、データ・コンテナ・ハンドル５００において指定される。
【００６４】
ストライピング・ルール１５３０の各組は、例えば、ストライプ幅フィールド１５１０、ストライプ・アルゴリズムＩＤフィールド１５１５、ボリュームの順序付きリスト・フィールド１５２０を含み、代替実施形態では、更に別のフィールド１５２５を有する場合がある。ストライピング・ルール１５３０は、ＳＶＳの編成を識別するための情報を有する。例えば、ストライピングアルゴリズムＩＤフィールド１５１５は、そのＳＶＳとともに使用されるストライピング・アルゴリズムを識別する。例示的実施形態では、複数のストライピング・アルゴリズムが、１つのＳＶＳとともに使用される場合がある。そのため、どのアルゴリズムを使用するかを指定するために、ストライピング・アルゴリズムＩＤが必要となる。さらに、各ストライピング・アルゴリズムは、そのＳＶＳの複数のボリュームにわたってファイルの中身をストライプとして分配するときの態様を指定する。ストライプ幅フィールド１５１０は、各ストライプのサイズ／幅を指定する。ボリュームの順序付きリスト・フィールド１５２０は、そのＳＶＳを含むボリュームのＩＤを有する。一実施形態として、ボリュームの順序付きリストは、フレキシブルボリュームＩＤと、そのフレキシブルボリュームを格納している集合体ＩＤとからなる、複数のタプルからなる。また、ボリュームの順序付きリストは、ＳＶＳの種々のボリュームの機能や実施形態、並びにＳＶＳのストライピング・ルールを指定する場合もある。例えば、順序付きリスト中の最初のボリュームは、そのＳＶＳのＭＤＶを表わす一方、そのリスト中のボリュームの順序は、例えばラウンド・ロビンのような特定のストライピング・アルゴリズムを実施する態様を表わす場合がある。
【００６５】
本発明の更に別の態様では、Ｌｏｃａｔｅ（）関数３７５が使用される場合がある。この関数は、ファイルへのアクセス要求に応じるために、ＶＳＭ３７０、及び他のモジュール（例えば、Ｎブレード３１０のものなど）が、ＳＶＳ１４００のＤブレード３５０、及びそれに関連するボリュームを探し出せるようにするためのものである。Ｌｏｃａｔｅ（）関数は、引数として少なくとも、（１）ＳＶＳ  ＩＤ１５０５、（２）そのファイル内のオフセット、（３）そのファイルのｉｎｏｄｅ番号、及び（４）一組のストライピング・ルールをとり、ＳＶＳ１４００内の、そのオフセットが始まるボリューム９１０を返す関数である。例えば、あるファイルに対するデータアクセス要求が、クライアント１８０によって発行され、それが、ノード２００のＮブレード３１０において受信された場合を仮定すると、そのデータアクセス要求は、マルチプロトコル・エンジン３２５によって分散され、Ｎブレード３１０の適当なプロトコルサーバに渡される。
【００６６】
ＣＦメッセージの送付先であるＤブレード３５０の位置を判定するために、Ｎブレード３１０は、まず、そのＳＶＳに関連するストライピング・ルール１５３０（及びボリュームのリスト１５２０）を取得するためのＳＶＳエントリ１５００を読み出す場合がある。次に、Ｎブレード３１０は、Ｌｏｃａｔｅ（）関数３７５を実行し、オペレーションの対象となる適当なボリュームを識別する。その後、Ｎブレードは、そのボリュームを含む集合体を識別するために適当なＶＬＤＢボリュームエントリ１２００を読み出し、適当なＤブレード３５０を最終的に識別するための適当なＶＬＤＢ集合体エントリを識別する場合がある。次に、Ｎブレード３１０のプロトコルサーバは、ＣＦメッセージ４００をＤブレード３５０に送信する。
【００６７】
図１６は、本発明の一実施形態によるＳＶＳ１６００のボリュームＡ１６０５、Ｂ１６１０、及びＣ１６１５に格納されるファイルの中身の周期的散在状況を示す略ブロック図である。上記のように、ファイルの中身、ＳＶＳストライピングルールにしたがって周期的に分散され、ＳＶＳストライピングルールは、ストライピング・アルゴリズム（ストライプ・アルゴリズム・ＩＤフィールド１５１５によって示されているようなもの）、及び、各ストライプのサイズ／幅（ストライプ幅フィールド１５１０によって示されているようなもの）を指定する。なお、図示の実施形態では、ストライプ幅は、各ストライプが、ファイルの間接ブロック（例えば、レベル１ブロック８０４）によって参照される実際のデータ（例えば、データブロック８０６に格納されているようなもの）を確実に収容できるように選択されている。
【００６８】
例えば、ラウンド・ロビン・ストライピング・アルゴリズムによれば、ボリュームＡ１５０５は、１ストライプのファイル・コンテンツ、又はデータ（Ｄ）１６２０を格納し、次いで、２ストライプの散在（Ｓ）１６２２、１６２４、別のストライプのデータ（Ｄ）１６２６、及び２ストライプの散在（Ｓ）１６２８、１６３０を格納する。一方、ボリュームＢ１６１０は、１ストライプの散在（Ｓ）１６３２を格納し、次いで、１ストライプのデータ（Ｄ）１６３４、２ストライプの散在（Ｓ）１６３６、１６３８、別のストライプのデータ（Ｄ）１６４０、及び１ストライプの散在（Ｓ）１６４２を格納する。ボリュームＣ１６１５は、ラウンドロビン・ストライピング・パターンを継続し、その目的のために、２ストライプの散在（Ｓ）１６４４、１６４６を格納し、次いで、１ストライプのデータ（Ｄ）１６４８、２ストライプの散在（Ｓ）、及び他のストライプのデータ（Ｄ）１６５４を格納する。
【００６９】
Ｈ．ＳＶＳオペレーション
本明細書に記載するシステム・アーキテクチャによれば、ＳＶＳの複数のボリュームにわたるファイル（及び他のデータコンテナ）・コンテンツの効率的、且つ正確な提供を可能にするために、複数のＳＶＳオペレーションが用意される。そうしたＳＶＳオペレーションには、とりわけ、ファイルの作成、ファイルの消去、ファイル属性の読み出し、ファイル属性の書き込み／変更、ファイル読み出し、ファイル書き込みオペレーションなどがある。図１７は、本発明の一実施形態による新たなファイルを作成する手順１７００のステップの詳細を示すフロー図である。手順１７００は、ステップ１７０５から開始され、ステップ１７１０へ進み、そこで、Ｎブレード３１０は、新たなファイルを作成するための要求を受信する。この要求は、例えば、クライアント１８０が、ファイル作成要求をノード２００に送信することによってなされる。ステップ１７１５において、Ｎブレードは、その要求を、ＳＶＳ１４００のＭＤＶ１４０５を提供している適当なＤブレードへリダイレクトする。例えば、Ｎブレードは、そのファイル作成要求をプロシージャ・コール（ＬＰＣまたはＲＰＣ）に変換し、そのコールに関連するＣＦ  ＡＰＩ関数に応じて取るべきアクションを決定する。例えば、Ｄブレードは、ファイル作成要求に応じて、対応するファイル作成プロシージャ・コールをＭＤＶ１４０５に対して発行し、すなわち、より具体的には、そのＭＤＶを提供しているＤブレード３５０のＶＳＭ３７０に対して発行する。
【００７０】
例示的実施形態として、Ｎブレードは、ＶＬＤＢ１１３０のＳＶＳエントリ１５００内の、ボリュームの順序付きリスト１５２０を検査することにより、ＳＶＳ１４００のどのボリュームがＭＤＶであるかを判定する。上記のように、例えば、順序付きリスト１５２０内にリストされた最初のボリュームが、ＭＤＶである。ただし、当業者には分かるように、順序付きリスト１５２０内の任意のボリューム位置をＭＤＶ１４０５として指定することができる。また、順序付きリスト１５２０内のどのボリュームがそのＳＶＳのＭＤＶであるかを明示的に示すために、ＶＬＤＢエントリ１５００を増強することも可能である。
【００７１】
ファイル作成プロシージャ・コールを受信すると、ステップ１７１８において、ＶＳＭ３７０は、ＭＤＶ上のディレクトリを更新することにより（すなわち、そのファイルのための新たなディレクトリエントリを作成することにより）、そのコールを処理し、ステップ１７２０において、そのファイルにｉｎｏｄｅを割り当てる。割り当てられるｉｎｏｄｅは、例えば、従来のｉｎｏｄｅ選択技術を使用して、ＳＶＳ内の空きｉｎｏｄｅの中から選択されることが好ましい。なお、ＳＶＳ１４００の各ボリュームには、その新たに作成されたファイルのｉｎｏｄｅと同じものが割り当てられる。また、各ボリュームについて、ｉｎｏｄｅは、ｉｎｏｄｅファイルと同じ位置／場所に割り当てられる。すなわち、各ボリューム上のｉｎｏｄｅファイルは、そのｉｎｏｄｅファイルと同じｉｎｏｄｅインデックスが割り当てられる。ステップ１７３５において、ＭＤＶ１４０５のＶＳＭ３７０は、例えば、Ｄブレード３５０上で動作しているフィルシステム３６０に対し、割り当てられたｉｎｏｄｅを使用したファイル作成を命じることによって、ファイル作成を完了する。そして、手順１７００は、ステップ１７４０で完了する。
【００７２】
図１８は、本発明の一実施形態による、ファイルを削除するための手順１８００のステップの詳細を示すフロー図である。手順１８００は、ステップ１８０５から開始され、ステップ１８１０へ進み、そこで、Ｎブレードは、ファイルを削除するためのクライアント要求を受信する。ステップ１８１５において、Ｎブレードは、上記のように、その要求をファイル削除プロシージャ・コールとしてＳＶＳ１４００のＭＤＶ１４０５を提供している適当なＤブレードのＶＳＭ３７０へリダイレクトする。ステップ１８２５において、ＶＳＭは、例えば、プロシージャ・コールを発行したり、メッセージを渡したりする従来のＩＰＣメカニズムにより、対応する削除要求をファイルシステム３６０に渡す。ステップ１８３０において、ファイルシステムは、その削除（削除）要求を、そのファイルシステムからｉｎｏｄｅが実際に削除されるポイントまで処理する。そして、そのポイントにおいて、ファイルシステムは、例えばＩＰＣメカニズムにより、その特定の状態に達したことをＶＳＭ３７０に警告する（ステップ１８３５）。例えば、ＶＳＭ３７０は、ＳＶＳ１４００のＤＶを提供しているＤブレードのＣＦインタフェースモジュール３４０と協働し、それらの要求をＣＦメッセージとして送信する。次に、ステップ１８４２において、ＣＳＭは、すべてのＤＶが、要求の完了を示す確認メッセージを受信するまで待機する。ステップ１８４５において、ＶＳＭは、ファイルシステム３６０に対し、そのｉｎｏｄｅの削除を命じ、それに応答して、ステップ１８５０において、ファイルシステムは、そのｉｎｏｄｅを削除する。そして、手順はステップ１８５５において完了する。
【００７３】
図１９は、本発明の一実施形態によるファイル属性を読み出すための手順１９００のステップの詳細を示すフロー図である。手順１９００は、ステップ１９０５から開始され、ステップ１９１０へ進み、そこで、Ｎブレードは、ファイル属性を取得する（読み出す）ための要求を受信する。ステップ１９１５において、Ｎブレードは、その要求を、そのファイルのＣＡＶを有しているＤブレードのＶＳＭに転送する。ステップ１９２０において、ＶＳＭ３７０は、そのファイルのｉｎｏｄｅ６００のメタデータ無効フラグ６３４をチェックすることにより、自分の有しているメタデータ属性のキャッシュされたコピーが有効なものであるかを、すなわち、無効なものでないかを判断する。キャッシュされたコピーが無効化されていなければ、ステップ１９３０においてＶＳＭは要求された属性を返し、手順はステップ１９３５において完了する。一方、キャッシュされたコピーが無効化されていれば、手順はステップ１９２５へと分岐し、そこで、ＶＳＭは、例えば、そのＭＤＶを提供しているＤブレード３５０に属性読み出し要求を送信することにより、ＭＤＶ１４０５から属性を読み出す。例えば、そのような要求は、ＣＦインタフェースモジュール３４０を介してＣＦメッセージ４００として送信される。次に、手順はステップ１９３０へ進み、そこで、そのＣＡＶを有しているＤブレードのＶＳＭは、要求された属性を返し、その後、ステップ１９３５で手順は完了する。
【００７４】
図２０は、本発明の一実施形態による、ファイル属性を書き込み／変更するための手順２０００のステップの詳細を示すフロー図である。手順２０００は、ステップ２００５から開始され、ステップ２０１０へ進み、そこで、Ｎブレードは、ファイル属性を変更するための要求を受信する。ステップ２０１５において、Ｎブレードは、その要求を、そのＭＤＶを有しているＤブレード３５０のＶＳＭ３７０へ転送する。ステップ２０２０において、そのＭＤＶを提供しているＶＳＭは、自分が有しているメタデータのキャッシュされたコピーを無効にするための要求を、そのファイルのＣＡＶを提供しているＶＳＭに転送する。それに応答して、ステップ２０２５において、ＣＡＶのＶＳＭは、例えば、そのキャッシュされたメタデータが無効なものであることを示すようにメタデータ無効フラグ６３４を設定することによって、そのキャッシュを無効にする。さらに、ＣＡＶを提供しているＶＳＭは、その無効化要求をすべてのＤＶに転送し、各ＶＳＭから応答が得られるまで待機し、応答が得られると、ステップ２０３０において、そのキャッシュされたコピーが無効化されたことを示す確認メッセージを返送する。ＭＤＶを提供しているＶＳＭがその確認メッセージを受信すると、ＶＳＭは、受信した要求ごとに、メタデータの正規のコピーを変更し、ファイル属性を変更する（ステップ２０３５）。そして、ステップ２０４０において、ＶＳＭが、例えば、オペレーションが無事に実行されたことを示すステータスインジケータをＮブレードに返した後、ステップ２０４５において、Ｎブレードは、クライアントにステータスを返答する。そして、手順はステップ２０５０において完了する。
【００７５】
図２１は、本発明の一実施形態による、読み出し要求を処理するための手順２１００のステップの詳細を示すフロー図である。手順２１００は、ステップ２１０５から開始され、ステップ２１１０へ進み、そこで、Ｎブレードは、クライアントから読み出し要求を受信する。ステップ２１１５において、Ｎブレードは、Ｌｏｃａｔｅ（）３７５関数を使用して、要求をリダイレクトの宛先となるＤブレードを識別する。上記のように、Ｌｏｃａｔｅ（）関数は、引数としてＳＶＳ  ＩＤ、一組のストライピング・ルール、ｉｎｏｄｅ番号、及び、ファイル内へのオフセットをとり、そのファイルオフセットを提供する適当なボリュームの識別情報（ＩＤ）を返す。ステップ２１２０において、Ｎブレードは、その要求を適当なＤブレード３５０に転送し、そこで、ＶＳＭ３７０は、その読み出し要求が、そのボリューム上の単一のストライプに収まるか否かを、すなわち、その要求が、このボリューム上のストライプ内に完全に格納されたデータを要求するものであるか否かを判定する。そうである場合、ＶＳＭ３７０は、例えば、一連のチェックを実施し、その要求を直ぐに処理してもよいか否かを判定する。
【００７６】
例えば、ＶＳＭは、自分がローカルに有している特定のメタデータのキャッシュされたコピーが存在するか否か（ステップ２１２５）、その読み出し要求が、キャッシュされたファイル長よりも短いか否か（ステップ２１３０、及びそのファイルのＣＡＶが最近消費されたか否か（ステップ２１３５）を判定する。それらを合わせると、ＣＡＶが、そのファイルの比較的最近チェックされた適当なメタデータを有しているかを確実にチェックすることができる。それらのチェックの結果うちの何れかが否定的なものであれば、手順はステップ２１４０へと分岐し、そこで、ＣＡＶのＶＳＭは、例えば、最新のメタデータをＭＤＶに問い合わせることにより、自分がローカルに有しているファイルメタデータのキャッシュされたコピーを更新する。一方、チェックの結果が肯定的なものであれば、手順はステップ２１４５へ進み、そこで、ＶＳＭは、その読み出し要求をファイルシステムに渡す。ステップ２１５０において、ファイルシステムは、例えば、適当なメタデータをディスクから読み出すことにより、その読み出し要求を処理する。ステップ２１５５において、ファイルシステムは、Ｎブレードに応答を返し、ステップ２１６０において、適当な応答をクライアントに返す。この応答は、例えば、ボリュームから読み出された要求されたデータを含み、また、後で更に詳しく説明するように、他のボリュームから読み出された要求されたデータを更に含む場合もある。そして、手順はステップ２１６５において終了する。
【００７７】
ただし、ステップ２１２２において、要求された読み出しデータが、そのストライプ内に完全には収容されていないという判定がなされた場合、手順はステップ２１７０へと分岐し、そこでＶＳＭは、そのストライプ上に収容されていないデータに対する読み出し要求を、次のストライプのデータを提供するボリュームのＶＳＭに渡す。これに応答して、次のストライプのデータを保持しているボリュームのＶＳＭは、その読み出し要求に応じ、ステップ２１７５において、読み出したデータを要求元のＶＳＭに返す。そして、手順はステップ２１２５へと続く。
【００７８】
図２２は、本発明の一実施形態による、書き込み要求を処理するための手順２２００のステップの詳細を示すフロー図である。手順２２００はステップ２２０２から開始され、ステップ２２０５へと続き、そこで、Ｎブレードは、クライアントから書き込み要求を受信する。ステップ２２１０において、Ｎブレードは、例えば、本明細書に記載するように、Ｌｏｃａｔｅ（）関数３７５を使用して、その処理要求をリダイレクトする宛先となるＤブレードを識別する。ステップ２２１５において、Ｎブレードは、その要求を適当なＤブレード（複数の場合もあり）に転送する。ステップ２２２０において、Ｄブレード上のＶＳＭは、書き込むべきデータが、単一のストライプに収まるか否かを判定する。ＶＳＭは、例えば、書き込みオペレーションのサイズ、ストライプ幅、及び、その書き込みオペレーションが開始されるストライプ内のオフセットを分析することにより、この判定を行うことができる。
【００７９】
書き込みが単一のストライプに収まる場合、ＶＳＭは、読み出しオペレーションに関して上で説明した３つのチェック、すなわち、ローカルキャッシュが直ぐに使用できる状態にあるか否か（ステップ２２２５）、書き込み要求がキャッシュされたファイル長よりも短いか否か（ステップ２２３０）、及びＦＡＶが最近消費されたか否か（ステップ２２３５）のチェックを実施する。それらのチェックのうちのいずかが否であれば、手順はステップ２２５５へと分岐し、そこで、ＶＳＭは、ＣＡＶからメタデータを読み出し、ステップ２２４０へと進む。一方、すべてのチェックについてその結果が肯定的なものであれば、手順は２２４０へとそのまま進み、そこで、ＶＳＭは、その書き込み要求をファイルシステムに渡す。ステップ２２４５において、ファイルシステムは、その書き込み要求を処理した後、ステップ２２５０において、ステータスをＮブレードに返す。そして、手順はステップ２２９０において完了する。
【００８０】
ステップ２２７０において、ＶＳＭは、書き込みオペレーションに関連するデータの一部を、自分のファイルシステム３６０に渡し、ステップ２２７５において、ファイルシステム３６０は、データのその部分を自分のボリュームに書き込む。ステップ２２８０において、ＶＳＭは、その書き込みオペレーションに関連する余分なデータを、次のストライプを格納するように構成されたＳＶＳ内のボリュームに渡す。ステップ２２８５において、そのボリュームのＶＳＭは、その余分なデータをそのボリュームに書き込む（記憶する）ために、自分のファイルシステムに渡す。その後、ステップ２２５０において、ファイルシステムは、Ｎブレードにステータスを返し、手順はステップ２２９０において完了する。
【００８１】
上記の説明は、本発明の特定の幾つかの実施形態に関するものになっている。しかしながら、当然ながら、それらの実施形態の利点の一部、又は全部を維持したまま、それらの実施形態に対し、他の変形、又は変更を施すことも可能である。具体的には、本発明の原理は、非分散ファイルシステムにおいて実施することも可能である。さらに、本明細書の説明は、Ｎブレード、及びＤブレードに関して記載されているが、本発明の教示は、Ｎブレードの機能とＤブレードの機能が単一のシステムで実施されるシステムにも、等しく適用することが可能である。あるいは、Ｎブレード、及びＤブレードの機能は、任意数の個別のシステムにわたって分散させることもでき、各システムが、それらの機能のうちの１以上を実施するようにしてもよい。さらに、本明細書に記載する手順、プロセス、及び／又はモジュールは、ハードウェアで実施しても、プログラム命令が格納されたコンピュータ読み取り可能媒体として実施されるソフトウェアで実施しても、ファームウェアで実施してもよく、また、それらの組み合わせによって実施してもよい。したがって、添付の特許請求の範囲は、そうした変形や変更も、本発明の思想、及び範囲に含めることを目的としている。
【００８２】
【図面の簡単な説明】
【００８３】
【図１】本発明の一実施形態による、クラスタとして相互接続された複数のｉｎｏｄｅを示す略ブロック図である。
【図２】本発明の一実施形態によるノードを示す略ブロック図である。
【図３】本発明とともに有利に使用されるストレージ・オペレーティング・システムを示す略ブロック図である。
【図４】本発明の一実施形態による、クラスタ・ファブリック（ＣＦ）・メッセージのフォーマットを示す略ブロック図である。
【図５】本発明の一実施形態による、データコンテナ・ハンドルのフォーマットを示す略ブロック図である。
【図６】本発明の一実施形態による、例示的ｉｎｏｄｅを示す略ブロック図である。
【図７】本発明の一実施形態による、例示的バッファ・ツリーを示す略ブロック図である。
【図８】本発明とともに有利に使用されるファイルのバッファ・ツリーの一実施形態を示す略ブロック図である。
【図９】本発明の一実施形態による集合体の例を示す略ブロック図である。
【図１０】本発明の一実施形態による、集合体のオン・ディスク・レイアウトの一例を示す略ブロック図である。
【図１１】本発明の一実施形態による、一群の管理プロセスを示す略ブロック図である。
【図１２】本発明の一実施形態による、ボリューム位置データベース（ＶＬＤＢ）ボリュームエントリを示す略ブロック図である。
【図１３】本発明の一実施形態による、ＶＬＤＢ集合体エントリを示す略ブロック図である。
【図１４】本発明の一実施形態による、ストライピングされたボリューム・セット（ＳＶＳ）を示す略ブロック図である。
【図１５】本発明の一実施形態による、ＶＬＤＢ  ＳＹＳエントリを示す略ブロック図である。
【図１６】本発明の一実施形態による、ＳＶＳの複数のボリューム上に格納されたファイル・コンテンツの周期的散在を示す略ブロック図である。
【図１７】本発明の一実施形態による、新たなファイルを作成する手順のステップの詳細を示すフロー図である。
【図１８】本発明の一実施形態による、ファイルを削除する手順のステップの詳細を示すフロー図である。
【図１９】本発明の一実施形態による、ファイル属性を読み出す手順のステップの詳細を示すフロー図である。
【図２０】本発明の一実施形態による、ファイル属性を書き込み、及び／又は変更する手順のステップの詳細を示すフロー図である。
【図２１】本発明の一実施形態による、読み出し要求を処理する手順のステップの詳細を示すフロー図である。
【図２２】本発明の一実施形態による、書き込み要求を処理する手順のステップの詳細を示すフロー図である。
【図１】
2008539505.tif 000003
【図２】
2008539505.tif 000004
【図３】
2008539505.tif 000005
【図４】
2008539505.tif 000006
【図５】
2008539505.tif 000007
【図６】
2008539505.tif 000008
【図７】
2008539505.tif 000009
【図８】
2008539505.tif 000010
【図９】
2008539505.tif 000011
【図１０】
2008539505.tif 000012
【図１１】
2008539505.tif 000013
【図１２】
2008539505.tif 000014
【図１３】
2008539505.tif 000015
【図１４】
2008539505.tif 000016
【図１５】
2008539505.tif 000017
【図１６】
2008539505.tif 000018
【図１７】
2008539505.tif 000019
【図１８】
2008539505.tif 000020
【図１９】
2008539505.tif 000021
【図２０】
2008539505.tif 000022
【図２１】
2008539505.tif 000023
【図２２】
2008539505.tif 000024
【手続補正書】
【提出日】平成20年1月7日(2008.1.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
１つのクラスタを形成するように互いに接続された２以上のコンピュータと、
前記２以上のコンピュータにわたって分散され、ストライピングされたボリュームセットを形成する複数のボリュームであって、前記ストライピングされたボリュームセットが一組のストライピング・ルールによって規定され、各ボリュームが前記２以上のコンピュータのうちの一方のコンピュータに取り付けられた記憶空間の論理配置であるように構成される、複数のボリュームと、
前記クラスタ中の１以上のコンピュータ上で実行されるボリューム・ストライピング・モジュールであって、前記ストライピングされたボリュームセットの全域にわたって１以上のデータコンテナをストライピングするボリューム・ストライピング・モジュールと
からなるシステム。
【請求項２】
前記複数のボリュームは複数の仮想ボリュームである、請求項１に記載のシステム。
【請求項３】
前記２以上のコンピュータのうちの第１のコンピュータに取り付けられた１以上の記憶装置が、グローバル記憶空間を備えた集合体を形成するように論理配置される、請求項２に記載のシステム。
【請求項４】
前記複数の仮想ボリュームのうちの１以上が、前記第１のコンピュータの前記集合体の中に格納される、請求項３に記載のシステム。
【請求項５】
前記複数のボリュームは物理ボリュームである、請求項１に記載のシステム。
【請求項６】
前記データコンテナは、ファイル、又はＬＵＮである、請求項１に記載のシステム。
【請求項７】
前記一組のストライピング・ルールは、ストライプ幅、及びボリュームの順序付きリストを含む、請求項１に記載のシステム。
【請求項８】
前記複数のボリュームのうちの１つのボリュームは、メタデータ・ボリュームであり、アクセス・コントロール・リスト、及び前記ストライピングされたボリュームセットの全域にわたって格納されたデータコンテナのディレクトリを格納し、前記複数のボリュームのうちの１以上のボリュームは、データ・ボリュームであり、前記１以上のデータコンテナのデータを格納する、請求項１に記載のシステム。
【請求項９】
２以上のコンピュータを１つのクラスタを形成するように互いに接続するステップと、
一組のストライピング・ルールを使用して、複数のボリュームを、ストライピングされたボリュームセットとして編成し、前記複数のボリュームが、前記クラスタの全域にわたって分散され、各ボリュームが、前記２以上のコンピュータのうちの１つのコンピュータに取り付けられた記憶空間の論理配置となるようにするステップと、
１つのストライプを成す１以上のデータコンテナを、前記ストライピングされたボリュームセットの全域にわたって記憶するステップと
からなる方法。
【請求項１０】
前記一組のストライピング・ルールは、ストライプ幅、及びボリュームの順序付きリストを含む、請求項９に記載の方法。
【国際調査報告】
2008539505.tif 000025
2008539505.tif 000026
2008539505.tif 000027