JP2012525634A - ストライプ化ファイルシステムにおける能力平準化によるデータ分散 - Google Patents

Abstract

データ分散技術は、ストライプ化ファイルシステムにおける能力平準化を提供するように構成される。新たなノードがストライプ化ボリュームセットに追加されると、ストライピングテーブルは、その新たに追加されたノードを受け入れるように発展される。クラスタの各ノードは、例えば、そのノードのプロセッサ速度、プロセッサの数、ハードウェア構成、及び／又は使用可能なソフトウェアを考慮する能力値に関連する。ストライピングテーブルの発展処理の際、この技術は、種々のストライプがＳＶＳの種々のストライプの各ノードの能力値に従ってノードに最適に割り当てられるような形で、ＳＶＳの種々のストライプを種々のノードに分配する。能力値を含む発展的ストライピングテーブルの使用により、ヘテロジニアスなノードをストライプ化ボリュームセット中においてその最大能力まで使用することができ、それによって、十分に活用されない処理リソースを減らすことができる。
【選択図】図１８

Description

[関連出願]
本願は、２００５年４月２９日に出願され、２００５年９月１日に米国出願公開第ＵＳ２００５−０１９２９３２号として公開された「STORAGE ARCHITECTURE FOR STRIPING DATA CONTAINER CONTENT ACROSS VOLUMES OF A CLUSTER」と題するリチャード・ジャーニガン他による米国特許出願第１１／１１９，２７８号に関連するものであり、この米国特許出願の内容は、参照により本明細書に援用される。

[発明の分野]
本発明は、ストライプ化ファイルシステムに関し、特に、ストライプ化ファイルシステムの複数のノードにわたる能力平準化に関する。

[発明の背景]
ストレージシステムは通常、１以上の記憶装置を含み、要望に応じて、その中に情報を入れ、又はそこから情報を取得することができる。ストレージシステムは、とりわけ、システムにより実施されるストレージサービスを支える種々のストレージオペレーションを実施することにより、システムを機能的に編成するストレージオペレーティングシステムを含む。ストレージシステムは、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ（ＮＡＳ）環境、ストレージ・エリア・ネットワーク（ＳＡＮ）、及びクライアント又はホストコンピュータに直接取り付けられるディスクアセンブリを含む種々のストレージアーキテクチャに従って実施される場合がある。記憶装置は一般に、ディスクアレイとして編成された複数のディスクドライブであり、「ディスク」という用語は一般に、内蔵型回転式磁気媒体記憶装置を表す。この文脈におけるディスクという用語は、ハードディスクドライブ（ＨＤＤ）、又はダイレクト・アクセス・ストレージ・デバイス（ＤＡＳＤ）と同義である。なお、代替実施形態において、記憶装置は、例えば、フラッシュメモリ、バッテリーバックアップ不揮発性ランダムアクセスメモリなどのような固体装置からなる場合もある。従って、本明細書の説明は、ディスクを例として記載されているが、それらの実施形態は、単なる例として見るべきである。

ストレージシステムのストレージオペレーティングシステムは、ファイルシステムのような上位モジュールを実施し、種々のボリュームに記憶された情報を、ファイル、及び論理ユニットのようなデータコンテナの階層構造として論理編成する。例えば、「ディスク上」の各ファイルは、そのファイルの実際のデータのような情報を記憶するように構成された一組のデータ構造、すなわちディスクブロックとして実施される場合がある。それらのデータブロックは、ファイルシステムにより管理されるボリュームブロック番号（ｖｂｎ）空間の中に編成される。ファイルシステムはさらに、ファイル内の各データブロックに、対応する「ファイルオフセット」、又はファイルブロック番号（ｆｂｎ）を割り当てる場合がある。ファイルシステムは通常、ファイル単位でｆｂｎのシーケンスを割り当てるのに対し、ｖｂｎは、より大きなボリュームアドレス空間にわたって割り当てられる。ファイルシステムは、ｖｂｎ空間の中にデータブロックを「論理ボリューム」として編成する。各論理ボリュームは、必須ではないが、独自のファイルシステムに関連する場合がある。

１つの既知のタイプのファイルシステムは、ディスク上でデータを上書きしないｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムである。あるデータブロックが、ディスクからストレージシステムのメモリへ取り出され（読み出され）、新たなデータで「汚され」（すなわち、更新、又は変更され）る場合、書込み性能を最適化するために、そのデータブロックは、以後、ディスク上の新たな場所に記憶される（書き込まれる）。ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、最初に、データがディスク上に実質的に連続的に配置されるような最適レイアウトを前提とする場合がある。最適レイアウトにより、ディスクに対する効率的なアクセスオペレーションが得られ、特に、シーケンシャル読み出しオペレーションの場合に効率的なアクセスオペレーションが得られる。ストレージシステムにおいて動作するように構成されたｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットアップ，インコーポレイテッドから入手可能なＷｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ（登録商標））ファイルシステムである。

ストレージシステムは、情報配送のクライアント／サーバモデルに従って動作するようにさらに構成される場合があり、それによって多数のクライアントが、システムに記憶されたデータコンテナにアクセスすることが可能になる。このモデルでは、クライアントは、ポイント・ツー・ポイントリンク、共有ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、又はインターネットのような公衆ネットワークを介して実施される仮想私設ネットワーク（ＶＰＮ）のようなコンピュータネットワークを介してストレージシステムに「接続」するコンピュータ上で実行されるデータベースアプリケーションのようなアプリケーションを含む場合がある。各クライアントは、ネットワークを介してファイルベースのプロトコルメッセージ、及びブロックベースのプロトコルメッセージ（パケットの形をしている）をシステムへ発行することにより、ストレージシステムに種々のサービスを要求する場合がある。

多数のクライアントにサービスを提供するために、複数のストレージシステムが相互接続される場合がある。各ストレージシステムは、１以上のボリュームを提供するように構成される場合があり、各ボリュームは、１以上のデータコンテナを記憶する。しかしながら、しばしば、クライアントにより発行された多数のデータアクセス要求が、環境の特定のストレージシステムにより提供される少数のデータコンテナに向けて送信されることがある。そのような問題の一つの解決策は、特定のストレージシステムにより提供されるボリュームを、環境の全てのストレージシステムにわたって分散させることである。その結果、データアクセス要求、及びそれらの要求に対するサービスを提供するために必要な処理リソースは、全てのストレージシステムにわたって分散され、それによって、各ストレージシステムにおける個々の処理負荷は低減される。但し、ファイルのような単一のデータコンテナのみが、ストレージシステム環境の種々のクライアントにより非常に頻繁にアクセスされる場合、顕著な欠点が現れる。その結果、そのデータコンテナに対する要求についてサービスを提供しようとするストレージシステムは、自身の処理リソースを超過し、速度と処理能力の同時低下を伴う過剰負荷状態になる場合がある。

非常に頻繁に使用される単一データコンテナの問題を克服する一つの技術は、ストライプ化ボリュームセットとして構成された複数のボリュームにわたってデータコンテナをストライピングし、各ボリュームが、異なるストレージシステムからサービスの提供を受けるようにし、それによって、単一データコンテナについての負荷を複数のストレージシステムにわたって分散させることである。データコンテナストライピングのための一つの技術は、「STORAGE SYSTEM ARCHITECTURE FOR STRIPING DATA CONTAINER CONTENT ACROSS VOLUMES OF A CLUSTER」と題する上で援用した米国特許出願公開第ＵＳ２００５−０１９２９３２号に記載されている。一般に、ストライプ化ボリュームセットが最初に生成されるとき、ストライプ化ボリュームセットの種々の構成要素ボリュームを提供する構成要素ノードはそれぞれ、同一または類似の生成技術を使用する。すなわち、各ノードは通常、同一、又は実質的に同一のハードウェア、及び／又はソフトウェア構成を備える。すなわち、それらのノードは、各ノードが互いに実質的に同一であるため、ホモジニアスであると見られる場合がある。このようなシステムの顕著な欠点は、時間的に後の時点でストライプ化ボリュームセットが拡張され、顧客が、新たに追加されたノードのために、後世代（すなわち、新世代）のハードウェア、及び／又はソフトウェアを使用する場合に発生する。新たに追加されたノードは、非常に最新のハードウェア、及び／又はソフトウェアを使用するため、それらは通常、クラスタの元のノードに比べて、余分な計算能力を必要とする。より一般的には、この問題は、ヘテロジニアスなクラスタが形成されるとき、すなわち、クラスタのヘテロジニアスなノードが実質的に異なる機能、及び／又はプロセッサ能力を有するときに、顕著となる場合がある。そのようなヘテロジニアスなシステムでは、各ノードが通常、ストライピング処理のために同量だけ使用される。顕著な欠点は、新世代のノードが、十分に活用されない、又は使用されない余分な処理能力を有する場合があることから生じる。すなわち、新たな、及び／又は高速なノードは事実上、クラスタの最も非力なノード、すなわち元のノードと同種であるかのように使用されるため、新たな、及び／又は高速なノードを使用する利点は、無駄となる。そのような処理能力の無駄を回避するために、ユーザは、全てのノードが、共通のホモジニアスタイプのものであることを確保しなければならない。これは例えば、古いノードを購入することにより、又は、古いノードを新しいモデルに置き換えることにより達成される場合がある。これらの解決策はいずれも、最適なものではなく、クラスタ化ストレージシステムの所有権の総合的コストを上昇させる。

[発明の概要]
本発明は、ストライプ化ファイルシステムにおける能力平準化を提供するように構成されたデータ分散技術を提供することにより、従来技術の欠点を克服する。ストライプ化ボリュームセットは、例えば、ボリュームの順序付きリスト、及びデータがストライピングされる宛先となる関連ノードを識別するストライピングテーブルとして実施される場合がある例えばストライピングデータ構造のような一組のストライピングルールに関連する。クラスタの各ノードは、ＳＶＳの１つのボリュームを提供するように構成されたディスク要素と、データアクセス要求をクラスタのいずれかのデモジュールへリダイレクトするように構成されたネットワーク要素とを含む。データコンテナの中身は、ＳＶＳの種々のボリュームにわたって分配され、それによって、クラスタにより提供されるストレージサービスの効率が改善される。その目的のために、ストライピングテーブルは、データコンテナの中身をストライプとして複数のボリュームにわたって分配する態様を指定する。動作において、新たなノードがストライプ化ボリュームセットに追加されるとき、ストライピングテーブルは、新たに追加されたノードを受け入れるように発展される。例示的実施形態において、クラスタの各ノードは、例えば、そのノードのプロセッサ速度、プロセッサの数、ハードウェア構成、及び／又は使用可能なソフトウェアを考慮に入れた能力値に関連する。ストライピングテーブルの発展処理の際に、本技術は、ＳＶＳの種々のストライプが各ノードの能力値に従って最適にノードに割当てられるような形で、ＳＶＳの種々のストライプを種々のノードにわたって分配する。例えば、２ノードシステムにおいて、第１のノードが能力値１００を有し、第２のノードが能力値２００を有する場合、最適な処理能力を得るためには、第２のノードは、第１のノードに比べて２倍の量のストライプを提供しなければならない。能力値を含む発展的ストライピングテーブルの使用により、ヘテロジニアスなノードをストライプ化ボリュームセットの中においてその最大能力まで使用することができ、それによって、十分に活用されない処理リソースを減らすことができる。

本発明の上記の利点、及び他の利点は、添付の図面と併せて下記の説明を参照することで、より良好に理解することができるであろう。図面において、同様の符号は、同一の要素、又は機能的に類似の要素を示している。

本発明の例示的実施形態に従ってクラスタとして相互接続された複数のノードを示す略ブロック図である。 本発明の例示的実施形態によるノードを示す略ブロック図である。 本発明の例示的実施形態に有利に使用される場合があるストレージオペレーティングシステムを示す略ブロック図である。 本発明の例示的実施形態によるクラスタファブリック（ＣＦ）メッセージのフォーマットを示す略ブロック図である。 本発明の例示的実施形態によるデータコンテナハンドルのフォーマットを示す略ブロック図である。 本発明の例示的実施形態による例示的ｉｎｏｄｅを示す略ブロック図である。 本発明の例示的実施形態による例示的バッファツリーを示す略ブロック図である。 本発明に有利に使用される場合があるファイルのバッファツリーの例示的実施形態を示す略ブロック図である。 本発明の例示的実施形態による例示的なアグレゲートを示す略ブロック図である。 本発明の例示的実施形態によるアグレゲートの例示的なディスク上レイアウトを示す略ブロック図である。 本発明の例示的実施形態による一群の管理プロセスを示す略ブロック図である。 本発明の例示的実施形態によるボリューム位置データベース（ＶＬＤＢ）ボリュームエントリを示す略ブロック図である。 本発明の例示的実施形態によるＶＬＤＢアグレゲートエントリを示す略ブロック図である。 本発明の例示的実施形態によるストライプ化ボリュームセット（ＳＶＳ）を示す略ブロック図である。 本発明の例示的実施形態によるＶＬＤＢ ＳＶＳエントリを示す略ブロック図である。 本発明の例示的実施形態によるＳＶＳの種々のボリューム上に記憶されたファイルの中身の周期的散在を示す略ブロック図である。 本発明の例示的実施形態によるＳＶＳ内におけるデータコンテナのストライピングを示す略ブロック図である。 本発明の例示的実施形態による、能力平準化に基づくデータ分散を実施するための手順の種々のステップの詳細を示すフロー図である。 本発明の例示的実施形態による、ノードの追加に基づくストライピングテーブルの発展を示す略ブロック図である。 本発明の例示的実施形態による、ノードの追加に基づくストライピングテーブルの発展を示す略ブロック図である。 本発明の例示的実施形態による、ノードの追加に基づくストライピングテーブルの発展を示す略ブロック図である。 本発明の例示的実施形態による、ノードの追加に基づくストライピングテーブルの発展を示す略ブロック図である。

[例示的実施形態の詳細な説明]
Ａ．クラスタ環境
図１は、本発明の例示的実施形態に従って、クラスタ１００として相互接続され、種々の記憶装置における情報の編成に関連するストレージサービスを提供するように構成された複数のノード２００を示す略ブロック図である。ノード２００は、互いに協働し、クラスタ１００の分散ストレージシステムアーキテクチャを提供する種々の機能的要素を含む。その目的のために、各ノード２００は一般に、ネットワーク要素（Ｎモジュール３１０）、及びディスク要素（Ｄモジュール３５０）として構成される。Ｎモジュール３１０は、ノード２００をコンピュータネットワーク１４０を介して種々のクライアント１８０に接続することを可能にする機能を有する一方、各Ｄブレード３５０は、ディスクアレイ１２０のディスク１３０のような１以上の記憶装置に接続する。ノード２００は、クラスタスイッチングファブリック１５０により相互接続され、例示的実施形態において、クラスタスイッチングファブリック１５０は、ギガビットイーサネット（登録商標）スイッチとして実施される場合がある。分散ファイルシステムアーキテクチャの一例は、２００３年１２月３０日に発行されたエム・ケイザー他による「METHOD AND SYSTEM FOR RESPONDING TO FILE SYSTEM REQUESTS」と題する米国特許第６，６７１，７７３号に概ね記載されている。なお、例示的なクラスタ１００には、、同数のＮモジュールとＤモジュールが示されているが、本発明の種々の実施形態によれば、異なる数のＮモジュール、及び／又はＤモジュールが存在する場合もある。例えば、クラスタ構成１００には、ＮモジュールとＤモジュールの間に一対一の対応を反映しない複数のＮモジュール及び／又Ｄモジュールが存在する場合もある。従って、１つのＮモジュールと１つのＤモジュールを含むノード２００の説明は、単なる例として解釈すべきである。

クライアント１８０は、情報配送のクライアント／サーバモデルに従ってノード２００と情報をやりとりするように構成された汎用コンピュータであってもよい。すなわち、各クライアントは、ノードにサービスを要求する場合があり、ノードは、ネットワーク１４０を介してパケットをやりとりすることにより、クライアントにより要求されたサービスの結果を返す場合がある。クライアントは、ファイル及びディレクトリの形をした情報にアクセスするときに、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）を介して、コモン・インターネット・ファイル・システム（ＣＩＦＳ）プロトコル、又はネットワーク・ファイル・システム（ＮＦＳ）プロトコルのようなファイルベースのアクセスプロトコルを含むパケットを発行する場合がある。あるいはクライアントは、ブロックの形をした情報にアクセスするときに、「ＳＣＳＩ（Small Computer Systems Interface） ｏｖｅｒ ＴＣＰ」（ｉＳＣＳＩ）プロトコル、及び「ＳＣＳＩ ｏｖｅｒ ＦＣ」（ＦＣＰ）プロトコルのようなブロックベースのアクセスプロトコルを含むパケットを発行する場合がある。

Ｂ．ストレージシステムノード
図２は、例えば、システムバス２２３によって相互接続された複数のプロセッサ２２２ａ，ｂ、メモリ２２４、ネットワークアダプタ２２５、クラスタアクセスアダプタ２２６、ストレージアダプタ２２８、及びローカルストレージ２３０を含むストレージシステムとして実施される。ローカルストレージ２３０は、ユーザモードアプリケーション１１００として実行される１以上の管理プロセスにより提供される構成情報をローカルに記憶（例えば、設定ファイル２３５に）するためにノードにより使用されるディスクのような１以上の記憶装置を含む（図１１参照）。クラスタアクセスアダプタ２２６は、ノード２００をクラスタ１００の他のノードに接続するように構成された複数のポートを含む。例示的実施形態では、イーサネット（登録商標）をクラスタリングプロトコル及び相互接続媒体として使用しているが、当業者には明らかなように、本明細書に記載されるクラスタアーキテクチャの中において、他のタイプのプロトコル及び相互接続を使用することも可能である。代替実施形態として、Ｎモジュール及びＤモジュールが個別のストレージシステム又はコンピュータ上で実施される場合、Ｎ／Ｄモジュールは、クラスタ１００における他のＮ／Ｄモジュールとの通信のために、クラスタアクセスアダプタ２２６により使用される場合がある。

各ノード２００は、例えば、ストレージオペレーティングシステム３００を実行するデュアルプロセッサストレージシステムとして実施され、ストレージオペレーティングシステム３００は、好ましくは、ファイルシステムのような上位モジュールを実施し、情報を、名前付きディレクトリ、ファイル、及び仮想ディスク（以後、一般に「ブロック」）と呼ばれる特殊なタイプのファイルの階層構造としてディスク上に論理編成する。但し、当業者には明らかなように、ノード２００は、代替として、単一の、又は３以上のプロセッサシステムを含む場合がある。例えば、１つのプロセッサ２２２ａは、ノード上でＮモジュール３１０の機能を実行し、他のプロセッサ２２２ｂは、Ｄモジュール３５０の機能を実行する場合がある。

メモリ２２４は、例えば、本発明に関連するソフトウェアプログラムコード及びデータ構造を記憶するためにプロセッサ及びアダプタによりアドレス指定可能な種々の記憶場所を含む。さらに、プロセッサ、及びアダプタは、ソフトウェアコードを実行し、データ構造を操作するように構成された処理要素、及び／又は論理回路を含む。ストレージオペレーティングシステム３００は、その一部がメモリ上に常駐し、処理要素によって実行され、とりわけ、ノードにより実施されるストレージサービスを支える種々のストレージオペレーションを実施することにより、ノード２００を機能的に編成する。当業者には明らかなように、、本明細書に記載される本発明に関連するプログラム命令を記憶し、実行するために、例えばフラッシュメモリ、固体記憶装置などのような種々のコンピュータ読取可能記憶媒体を含む、他の処理手段、及び記憶手段を使用してもよい。

ネットワークアダプタ２２５は、ポイント・ツー・ポイントリンク、ワイドエリアネットワーク、公衆ネットワーク（インターネット）を介して実施される仮想私設ネットワーク、又は共有ローカルエリアネットワークを介してノード２００を１以上のクライアント１８０に接続するように構成された複数のポートを含む。従って、ネットワークアダプタ２２５は、ノードをネットワークに接続するために必要な機械的、電気的、及び信号的回路を含む場合がある。例えば、コンピュータネットワーク１４０は、イーサネットネットワーク、又はファイバーチャネル（ＦＣ）ネットワークとして実施される場合がある。各クライアント１８０は、ＴＣＰ／ＩＰのような所定のプロトコルにしたがってデータの個々のフレーム又はパケットをやりとりすることにより、ネットワーク１４０を介してノードと通信する場合がある。

ストレージアダプタ２２８は、ノード２００上で実行されるストレージオペレーティングシステム３００と協働し、クライアントにより要求された情報にアクセスする。情報は、例えば、ビデオテープ、光学的、ＤＶＤ、磁気テープ、バブルメモリ、電子的ランダムアクセスメモリ、微小電気機械、及び、データ及びパリティ情報を含む情報を記憶するように構成された任意の他の同様の媒体のような、書き込み可能な記憶装置媒体の任意のタイプのアタッチド・アレイに記憶される場合がある。但し、本明細書に例示的に記載されるように、情報は、好ましくは、アレイ１２０のディスク１３０上に記憶される。ストレージアダプタは、従来の高性能ＦＣリンクトポロジーのようなＩ／Ｏ相互接続構成を介してディスクに接続される入出力（Ｉ／Ｏ）インタフェース回路を有する複数のポートを含む。

各アレイ１２０上への情報の記憶は、好ましくは、ボリューム（複数可）上のボリュームブロック番号（ｖｂｎ）空間の全体的論理構成を定義するように協働する一群の物理的記憶ディスク１３０を含む１以上のストレージ「ボリューム」として実施される。各論理ボリュームは一般に、必須ではないが、独自のファイルシステムに関連する。論理ボリューム／ファイルシステム中のディスクは通常、１以上のグループとして編成され、各グループは、ＲＡＩＤ（Redundant Array of Independent or Inexpensive Array）として動作する場合がある。ＲＡＩＤ４レベル実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ中の所与の数の物理ディスクにわたるデータ「ストライプ」の冗長書込み、及びストライピングされたデータに関連するパリティ情報の適切な記憶により、データ記憶の信頼性／完全性を向上させる。ＲＡＩＤ実施形態の一例は、ＲＡＩＤ４レベル実施形態であるが、他のタイプ、及びレベルのＲＡＩＤ実施形態も、本明細書に記載する本発明の原理に従って使用される場合がある。

Ｃ．ストレージオペレーティングシステム
ディスク１３０へのアクセスを可能にするために、ストレージオペレーティングシステム３００は、１以上の仮想化モジュールと協働し、ディスク１３０により提供される記憶空間を「仮想化」するｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。ファイルシステムは、情報を、名前付きディレクトリ及びファイルの階層構造としてディスク上に論理編成する。「ディスク上」の各ファイルは、データのような情報を記憶するように構成された一組のディスクブロックとして実施される場合がある一方、ディレクトリは、他のファイル及びディレクトリの名前、及びそれらへのリンクを記憶する特殊なフォーマットのファイルとして実施される場合がある。仮想化モジュール（複数可）によれば、ファイルシステムは、情報を、名前付き論理ユニット番号（ｌｕｎ）としてエキスポートされるディスク上の種々のブロックの階層構造としてさらに論理編成することが可能となる。

例示的実施形態において、ストレージオペレーティングシステムは、好ましくは、カリフォルニア州サニーベイルにあるネットアップ，インコーポレイテッドから入手可能なＷｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ（登録商標））ファイルシステムを実施するＮｅｔＡｐｐ（登録商標） Ｄａｔａ ＯＮＡＴＰ（登録商標）オペレーティングシステムである。但し、当然ながら、本明細書に記載される発明の原理に従って、任意の適当なストレージオペレーティングシステムを拡張して使用することが可能であるものと考えられる。従って、「ＯＮＴＡＰ」という用語が使用された場合でも、それは、本発明の教示に適用可能な任意のストレージオペレーティングシステムを広く指し示すものとして解釈すべきである。

図３は、本発明に有利に使用することが可能なストレージオペレーティングシステム３００を示す略ブロック図である。ストレージオペレーティングシステムは、統合ネットワークプロトコルスタック、すなわち、より一般的には、ノードに記憶された情報をクライアントがブロックアクセスプロトコル及びファイルアクセスプロトコルを使用してアクセスするためのデータパスを提供するマルチプロトコルエンジン３２５、を形成するように構成された一連のソフトウェア層を含む。マルチプロトコルエンジンは、ＩＰ層３１４、並びにその支援搬送手段であるＴＣＰ層３１６及びユーザデータグラムプロトコル（ＵＤＰ）層３１５のような種々のネットワークプロトコル層に対するインタフェースとなるネットワークドライバ（例えば、ギガビットイーサネットドライバ）のメディアアクセス層３１２を含む。ファイルシステムプロトコル層は、マルチプロトコルファイルアクセスを提供し、その目的のために、ダイレクトアクセスファイルシステム（ＤＡＦＳ）プロトコル３１８、ＮＦＳプロトコル３２０、ＣＩＦＳプロトコル３２２、及びハイパーテキストトランスファープロトコル（ＨＴＴＰ）プロトコル３２４をサポートする。ＶＩ層３２６は、ＤＡＦＳプロトコル３１８により必要とされるようなＲＤＭＡのようなダイレクトアクセストランスポート（ＤＡＴ）機能を提供するためのＶＩアーキテクチャを実施する。ｉＳＣＳＩドライバ層３２８は、ＴＣＰ／ＩＰネットワークプロトコル層を介したブロックプロトコルアクセスを提供する一方、ＦＣドライバ層３３０は、ノードとの間でブロックアクセス要求及び応答を送受信する。ＦＣ及びｉＳＣＳＩドライバは、種々のブロックに対するＦＣ固有の、及びｉＳＣＳＩ固有のアクセス制御を提供し、従って、ノード２００上の種々のブロックにアクセスするときに、ｉＳＣＳＩ又はＦＣＰのいずれか一方、又はｉＳＣＳＩとＦＣＰの両方へのｌｕｎのエキスポートを管理する。

さらに、ストレージオペレーティングシステムは、ノード２００のディスク１３０上に記憶された情報にアクセスするための種々のデータパスを提供するストレージサーバ３６５を形成するように構成された一連のソフトウェアモジュールを含む。その目的のために、ストレージサーバ３６５は、ボリュームストライピングモジュール（ＶＳＭ）３７０、ＲＡＩＤシステムモジュール３８０、及びディスクドライバシステムモジュール３９０と協働するファイルシステムモジュール３６０を含む。ＲＡＩＤシステム３８０は、Ｉ／Ｏオペレーションに従って、ボリューム／ディスクに対する情報の記憶及び読み出しを管理するのに対し、ディスクドライバシステム３９０は、例えばＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施する。ＶＳＭ３７０は、例えば、ストライプ化ボリュームセット（ＳＶＳ）を実施する。本明細書に詳しく記載されるように、ＶＳＭは、ファイルシステム３６０と協働し、ストレージサーバ３６５が、ＳＶＳのボリュームに対するサービスを提供できるようにする。特に、ＶＳＭ３７０は、Ｌｏｃａｔｅ（）関数３７５を実施し、ＳＶＳボリューム中のデータコンテナ中身の位置を計算し、それによって、クラスタにより提供されるそのような中身の一貫性を確保する。

ファイルシステム３６０は、例えば、仮想ディスク（ｖｄｉｓｋ）モジュール（図示せず）、及びＳＣＳＩターゲットモジュール３３５として実施される１以上の仮想化モジュールとの情報のやりとりにより、ストレージオペレーティングシステム３００の仮想化システムを実施する。ｖｄｉｓｋモジュールによれば、ノード２００に対してユーザ（システム管理者）が発行したコマンドに応答し、管理フレームワーク１１１０（図１１参照）のユーザインタフェースのような管理インタフェースによるアクセスが可能となる。ＳＣＳＩターゲットモジュール３３５は通常、ＦＣ及びｉＳＣＳＩドライバ３２８、３３０と、ファイルシステム３６０との間に配置され、ｌｕｎがブロックとして表現される場合に、ブロック（ｌｕｎ）空間とファイルシステム空間との間の仮想化システムの変換層を提供する。

ファイルシステム３６０は、例えば、ディスクのような記憶装置に記憶された情報へのアクセスの際に使用される論理ボリューム管理機能を提供するメッセージベースのシステムである。すなわち、ファイルシステム３６０は、ファイルシステムセマンティックを提供するだけでなく、通常ならばボリュームマネージャに関連する機能も提供する。そのような機能には、（１）ディスクのアグレゲーション、（２）ディスクの記憶帯域幅のアグレゲーション、及び（３）ミラーリング、及び／又はパリティ（ＲＡＩＤ）のような信頼性保証が含まれる。ファイルシステム３６０は、例えば、４キロバイト（ＫＢ）ブロックを使用するブロックベースのディスク上フォーマット表現を有し、インデックスノード（ｉｎｏｄｅ）を使用して、ファイル及びファイル属性（例えば、作成時刻、アクセス権、サイズ、及びブロック位置など）を識別するＷＡＦＬファイルシステム（以後、一般に「ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム」）を実施する。ファイルシステムは、ファイルを使用して、そのファイルシステムのレイアウトを表すメタデータを記憶する。そのようなメタデータファイルとしては、とりわけ、ｉｎｏｄｅファイルが挙げられる。ディスクからのｉｎｏｄｅの読み出しには、ファイルハンドル、すなわち、ｉｎｏｄｅ番号を含む識別子が使用される。

概して、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの全てのｉｎｏｄｅは、ｉｎｏｄｅファイルの中に編成される。ファイルシステム（ｆｓ）情報ブロックは、ファイルシステム上の情報のレイアウトを指定し、ファイルシステムの全ての他のｉｎｏｄｅを含むファイルのｉｎｏｄｅを含む。各論理ボリューム（ファイルシステム）は、ｆｓｉｎｆｏブロックを有し、ｆｓｉｎｆｏブロックは、好ましくは例えばＲＡＩＤグループ内の固定位置に記憶される。ｉｎｏｄｅファイルのｉｎｏｄｅは、ｉｎｏｄｅファイルのデータブロックを直接参照する（指し示す）場合もあれば、ｉｎｏｄｅファイルの間接ブロックを参照し、さらにその間接ブロックが、ｉｎｏｄｅファイルのデータブロックを参照する場合もある。ｉｎｏｄｅファイルの各データブロックの中には、埋め込みｉｎｏｄｅがあり、埋め込みｉｎｏｄｅはそれぞれ、間接ブロックを参照し、さらにその間接ブロックが、ファイルのデータブロックを参照する場合がある。

動作としては、クライアント１８０からの要求は、コンピュータネットワーク１４０を介してパケットとしてノード２００へ転送され、そこでパケットは、ネットワークアダプタ２２５によって受信される。（層３１２又は層３３０の）ネットワークドライバは、そのパケットを処理し、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム３６０へ転送する前に、必要に応じてそのパケットをネットワークプロトコル及びファイルアクセス層へと渡し、さらなる処理を施す。ここで、ファイルシステムは、要求されたデータが「コア内」に、すなわち、メモリ２２４内に存在しない場合、要求されたデータをディスク１３０からロード（読み出す）処理を生成する。情報がメモリ上に無い場合、ファイルシステム３６０は、ｉｎｏｄｅ番号を使用してｉｎｏｄｅファイル内を検索し、適当なエントリにアクセスし、論理ｖｂｎを読み出す。次にファイルシステムは、その論理ｖｂｎを含むメッセージ構造をＲＡＩＤシステム３８０へ渡す。論理ｖｂｎは、ディスク識別子及びディスクブロック番号（ｄｉｓｋ，ｖｂｎ）にマッピングされ、ディスクドライバシステム３９０の適当なドライバ（例えば、ＳＣＳＩ）へ送信される。ディスクドライバは、指定されたディスク１３０からそのｄｂｎをアクセスし、ノードによる処理に備えて、要求されたデータブロック（複数可）をメモリにロードする。要求が完了すると、ノード（及び、オペレーティングシステム）は、ネットワーク１４０を介してクライアント１８０へ返答を返す。

なお、ノードにおいて受信されたクライアント要求についてデータストレージアクセスを実施するために必要となる上記のストレージオペレーティングシステム層を通るソフトウェア「パス」は、代替として、ハードウェアで実施してもよい。すなわち、本発明の代替実施形態では、ストレージアクセス要求データパスは、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は特定用途向け集積回路（ＡＳＩＣ）の中に論理回路として実施される場合がある。この種のハードウェア実施形態によれば、クライアント１８０により発行される要求に応答してノード２００により提供されるストレージサービスのパフォーマンスを向上させることができる。また、本発明の代替実施形態において、アダプタ２２５、２２８の処理要素は、パケット処理、及びストレージアクセスオペレーションに関する負荷の一部又は全部をプロセッサ２２２からそれぞれ取り除くように構成され、それによって、ノードにより提供されるストレージサービスの能力を向上させる場合がある。当然ながら、本明細書に記載される種々の処理、アーキテクチャ、及び手順は、ハードウェアで実施しても、ファームウェアで実施しても、ソフトウェアで実施してもよい。

本明細書において、「ストレージオペレーティングシステム」という用語は通常、データアクセスを管理するストレージ機能を実施するための、コンピュータ上で動作可能なコンピュータ実行可能コードを意味し、ノード２００の場合、汎用オペレーティングシステムのデータアクセスセマンティックを実施する。ストレージオペレーティングシステムは、マイクロカーネル、ＵＮＩＸ（登録商標）又はＷｉｎｄｏｗｓ ＮＴ（登録商標）のような汎用オペレーティングシステム上で動作するアプリケーションプログラム、あるいは本明細書に記載されるようなストレージアプリケーションのために構成される構成変更可能な機能を有する汎用オペレーティングシステムとして実施されてもよい。

さらに、当業者には分かるように、本明細書に記載される発明は、スタンドアロンのコンピュータ、あるいはストレージシステムとして実施され、又はストレージシステムを含むものとして実施されるスタンドアロンのコンピュータの一部を含む、いかなるタイプの特殊な目的（例えば、ファイルサーバ、ファイラ、又はストレージサービスを提供するアプライアンス）のコンピュータにも、汎用コンピュータにも適用することができる。さらに、本発明の教示は、種々のストレージシステムアーキテクチャに適用することができ、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及びクライアント又はホストコンピュータに直接取り付けられたディスクアセンブリに適用することができる。従って、「ストレージシステム」という用語は、ストレージ機能を実施するように構成され、他の装置又はシステムに関連する任意のサブシステムだけでなく、そのような構成をも含むものとして、広い意味で解釈しなければならない。なお、本明細書の説明は、ｗｒｉｔｅ ａｎｙｗｈｅｒｅファイルシステムを例として記載されているが、本発明の教示は、ｗｒｉｔｅ ｉｎ ｐｌａｃｅファイルシステムを含む任意の適当なファイルシステムに使用することが可能である。

Ｄ． ＣＦプロトコル
例示的実施形態において、ストレージサーバ３６５は、ストレージオペレーティングシステム３００のＤモジュール３５０として実施され、アレイ１２０の１以上のボリュームに対するサービスを提供する。さらに、マルチプロトコルエンジン３２５は、Ｎモジュール３１０として実施され、（１）ネットワーク１４０上にクライアントが発行する到来データアクセス要求パケットに関するプロトコルターミネーションを実施するとともに、（２）そのようなデータアクセス要求をクラスタ１００のいずれかのストレージサーバ３６５へリダイレクトする。さらに、Ｎモジュール３１０とＤモジュール３５０は互いに協働し、クラスタ１００の高いスケーラビリティを有する分散ストレージシステムアーキテクチャを提供する。その目的のために、各モジュールは、本明細書に記載されるデータコンテナストライピングオペレーションのためのＤモジュール間の通信のような、モジュール間におけるクラスタ内通信を実施するように構成された、クラスタファブリック（ＣＦ）インタフェースモジュール３４０ａ，ｂを含む。

Ｎモジュール３１０の、例えばＮＦＳ／ＣＩＦＳ層、及びｉＳＣＳＩ／ＦＣ層のようなプロトコル層は、クライアントからのファイルベース及びブロックベースのデータアクセス要求を、Ｄモジュール３５０との通信に使用されるＣＦプロトコルメッセージに変換するプロトコルサーバとして機能する。すなわち、Ｎモジュールサーバは、到来するデータアクセス要求をＣＦインタフェースモジュール３４０によってＣＦメッセージの中に埋め込まれたプリミティブオペレーション（コマンド）に変換し、クラスタ１００のＤモジュール３５０へ送信する。特に、ＣＦインタフェースモジュール３４０は、互いに協働し、クラスタ１００の全てのＤモジュール３５０にわたる単一のファイルシステムイメージを提供する。すなわち、クライアント要求を受信したＮモジュールのネットワークポートはいずれも、クラスタのいずれのＤモジュール３５０に配置された単一のファイルシステムイメージ内のいずれのデータコンテナにもアクセスすることができる。

例示的実施形態に関し、Ｎモジュール３１０とＤモジュール３５０は、ストレージオペレーティングシステム３００の個別にスケジューリングされたプロセスとして実施される。但し、代替実施形態として、モジュールは、単一のオペレーティングシステムプロセスの中において、コードの断片として実施されてもよい。従って、ＮモジュールとＤモジュールの間の通信は、例えば、モジュール間で受け渡しされるメッセージの使用により実施されるが、異なるノードのＮモジュールとＤモジュールの間におけるリモート通信の場合、そのようなメッセージの受け渡しは、クラスタスイッチングファブリック１５０を介して行われる。モジュール（プロセス）間で情報を伝送するためにストレージオペレーティングシステムにより提供される既知のメッセージ受け渡しメカニズムは、インター・プロセス・コミュニケーション（ＩＰＣ）メカニズムである（を処理する）。ＩＰＣメカニズムに使用されるプロトコルは、例えば、ＣＦアプリケーションプログラミングインタフェース（ＡＰＩ）を構成する一群のメソッド／関数を含む、ジェネリックファイル、及び／又はブロックベースの「アグノスティック」ＣＦプロトコルである。そのようなアグノスティックプロトコルの例としては、ネットアップ，インコーポレイテッドから入手可能なＳｐｉｎＦＳ及びＳｐｉｎＮＰプロトコルが挙げられる。

ＣＦインタフェースモジュール３４０は、クラスタ１００のモジュール間においてファイルシステムコマンドを伝送するためのＣＦプロトコルを実施する。通信は、例えば、ＣＦ ＡＰＩを露出しているＤモジュールにより実施され、Ｎモジュール（又は、他のＤモジュール）は、そのＣＦ ＡＰＩに対してコールを発行する。その目的のために、ＣＦインタフェースモジュール３４０は、ＣＦエンコーダ、及びＣＦデコーダとして構成される。Ｎモジュール３１０上の例えばＣＦインタフェース３４０ａのＣＦエンコーダは、（１）ファイルシステムコマンドを同じノード２００上にあるＤモジュール３５０へ伝送する場合、ＣＦメッセージをローカル・プロシージャ・コール（ＬＰＣ）としてカプセル化し、（２）ファイルシステムコマンドをクラスタ１００のリモートノードにあるＤモジュールへ伝送する場合は、ＣＦメッセージをリモート・プロシージャ・コール（ＲＰＣ）としてカプセル化する。いずれの場合も、Ｄモジュール３５０上のＣＦインタフェース３４０ｂのＣＦデコーダは、ＣＦメッセージのカプセル化を解除し、ファイルシステムコマンドを処理する。

図４は、本発明の一実施形態によるＣＦメッセージ４００のフォーマットを示す略ブロック図である。ＣＦメッセージ４００は、例えば、クラスタ１００のリモートモジュール間におけるスイッチングファブリック１５０を介したＲＰＣ通信に使用される。但し、「ＣＦメッセージ」という用語は、クラスタのモジュール間におけるＬＰＣ及びＲＰＣ通信を指すものとして一般に使用される場合があると理解すべきである。ＣＦメッセージ４００は、メディアアクセス層４０２、ＩＰ層４０４、ＵＤＰ層４０６、リライアブルコネクション（ＲＣ）層４０８、及びＣＦプロトコル層４１０を含む。上記のように、ＣＦプロトコルは、クラスタ１００上に記憶された種々のデータコンテナにアクセスするためのクライアント要求の中に含まれる種々のオペレーションに関連するファイルシステムコマンドを運ぶ汎用ファイルシステムプロトコルである。ＣＦプロトコル層４１０は、メッセージ４００の中のそのファイルシステムコマンドを保持している部分である。例えば、ＣＦプロトコルは、データグラムに基づくものであるから、ソース（例えば、Ｎモジュール３１０）から宛先（例えば、Ｄモジュール３５０）への信頼できる形でのメッセージ又は「エンベロープ」の伝送を必要とする。ＲＣ層４０８は、そのようなエンベロープをＵＤＰ４０６のような接続プロトコルに従って処理するように構成された信頼性のあるトランスポートプロトコルを実施する。

例えばファイルのようなデータコンテナは、ファイルシステムにおいて、データコンテナハンドルを使用してアクセスされる。図５は、ＳＶＳ ＩＤフィールド５０２、ｉｎｏｄｅ番号フィールド５０４、ユニーク識別子フィールド５０６、ストライプ化フラグフィールド５０８、及びストライピングエポック番号フィールド５１０を含むデータコンテナハンドル５００のフォーマットを示す略ブロック図である。ＳＶＳ ＩＤフィールド５０２は、ＳＶＳの（クラスタ１００内の）グローバル識別子を含み、その中に、データコンテナは存在する。ｉｎｏｄｅ番号フィールド５０４は、データコンテナに関連する（ｉｎｏｄｅファイル内の）ｉｎｏｄｅのｉｎｏｄｅ番号を含む。ユニーク識別子フィールド５０６は、データコンテナハンドル５００を一意に識別する単調増加番号を含む。ユニーク識別子は、ｉｎｏｄｅ番号が既に削除され、再使用され、新たなデータコンテナに再割当てされている場合に特に有用である。ユニーク識別子は、特定データコンテナにおいて再使用されたｉｎｏｄｅ番号を、それらのフィールドの潜在的な以前の使用から区別する。ストライプ化フラグフィールド５０８は、例えば、データコンテナがストライピングされているか否かを識別するブール値である。ストライピングエポックフィールド５１０は、ＳＶＳが、異なるデータコンテナに対し異なるストライピング技術を使用する実施形態の場合に、このデータコンテナに使用すべき適当なストライピング技術を示す。

Ｅ．ファイルシステム構成
例示的実施形態として、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムでは、データコンテナは、ディスク１３０上への記憶に適したｉｎｏｄｅデータ構造として表現される。図６は、メタデータ部６０５及びデータ部６６０を有することが好ましいｉｎｏｄｅ６００を示す略ブロック図である。各ノード６００のメタデータ部６０５に記憶される情報は、データコンテナ（例えばファイル）を表し、従って、ファイルのタイプ（例えば、通常、ディレクトリ、ｖｄｉｓｋ）６１０、そのサイズ６１５、タイムスタンプ（例えば、アクセス、及び／又は変更時刻）及び所有権、すなわち、そのファイルのユーザ識別子（ＵＩＤ６２５）及びグループＩＤ（ＧＩＤ６３０）を含む。各ｉｎｏｄｅのデータ部６６０の中身は、タイプフィールド６１０に定義されるファイル（ｉｎｏｄｅ）のタイプに応じて、異なる解釈をされる場合がある。例えば、ディレクトリｉｎｏｄｅのデータ部６６０は、ファイルシステムにより制御されるメタデータを含む一方、通常ｉｎｏｄｅのデータ部は、ファイルシステムデータを含む。後者の場合、データ部６６０は、そのファイルに関連するデータの表現を含む。

具体的には、通常のオンディスクｉｎｏｄｅのデータ部６６０は、ファイルシステムデータ、又はポインタを含む場合があり、後者は、ファイルシステムデータの記憶に使用されるディスク上の４ＫＢデータブロックを参照する。ディスク上のデータをアクセスする際のファイルシステムとＲＡＩＤシステム３８０の間における効率を促進するために、各ポインタは、論理ｖｂｎであることが好ましい。ｉｎｏｄｅのサイズに制限がある場合（例えば、１２８バイト）、６４バイト以下のサイズのファイルシステムデータは、その全体が、そのｉｎｏｄｅのデータ部の中に表現される。一方、データコンテナの中身の長さが６４バイトを超え、かつ、６４ＫＢ以下である場合、ｉｎｏｄｅ（例えば、第１レベルｉｎｏｄｅ）のデータ部は、最大で１６個のポインタを含み、各ポインタは、ディスク上の４ＫＢブロックのデータを参照する。

さらに、データのサイズが６４ＫＢよりも大きく、かつ６４メガバイト（ＭＢ）以下である場合、そのｉｎｏｄｅ（例えば、第２レベルｉｎｏｄｅ）のデータ部６６０における各ポインタは、１０２４個のポインタを含む間接ブロック（例えば、第１レベルＬ１ブロック）を参照し、各ポインタは、ディスク上の４ＫＢデータブロックを参照する。６４ＭＢより大きなサイズのファイルシステムデータの場合、ｉｎｏｄｅ（例えば、第３レベルＬ３ｉｎｏｄｅ）のデータ部６６０における各ポインタは、１０２４個のポインタを含む二重間接ブロック（例えば、第２レベルＬ２ブロック）を参照し、各ポインタは、間接（例えば、第１レベルＬ１）ブロックを参照する。さらに、その間接ブロックは、１０２４個のポインタを含み、各ポインタは、ディスク上の４ＫＢデータブロックを参照する。ファイルをアクセスする場合、そのファイルの各ブロックは、ディスク１３０からメモリ２２４へロードされる場合がある。

オンディスクｉｎｏｄｅ（又はブロック）がディスク１３０からメモリ２２４へロードされるとき、それに対応するコア内構造が、オンディスク構造に埋め込まれる。例えば、ｉｎｏｄｅ６００を取り囲む破線は、オンディスクｉｎｏｄｅ構造のコア内表現を示している。コア内構造は、オンディスク構造の他に、メモリ上の（但し、ディスク上には無い）データを管理するために必要となる追加的な情報をさらに記憶する１ブロックのメモリである。追加的な情報には、例えば、「ダーティ」ビット６７０が含まれる。ｉｎｏｄｅ（又はブロック）中のデータが例えば書込みオペレーションによる命令に従って更新／変更された後、変更されたデータは、ダーティビット６７０を使用して「ダーティ」であるものとしてマークされ、そのｉｎｏｄｅ（ブロック）をその後、ディスクへ「フラッシュ」（記憶）することが可能となる。

図７は、本発明に有利に使用することが可能なファイルのバッファツリーの一実施形態を示す略ブロック図である。バッファツリーは、メモリ２２４にロードされ、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム３６０によって管理されるファイル（例えば、ファイル７００）の種々のブロックの内部表現である。埋め込みｉｎｏｄｅのようなルート（最上位）ｉｎｏｄｅ７０２は、間接（例えば、レベル１）ブロック７０４を参照する。なお、ファイルのサイズによっては、さらに別のレベルの間接ブロック（例えば、レベル２、レベル３）が存在する場合もある。間接ブロック（及びｉｎｏｄｅ）は、ポインタ７０５を含み、ポインタ７０５は、ファイルの実際のデータの記憶に使用されるデータブロック７０６を最終的に参照する。すなわち、ファイル７００のデータは、種々のデータブロックに保持され、それらのブロックの位置が、ファイルの間接ブロックに記憶される。各レベル１間接ブロック７０４は、１０２４個のデータブロックと同数のポインタを含む場合がある。ファイルシステムの「ｗｒｉｔｅ−ａｎｙｗｈｅｒｅ」な性質によれば、これらのブロックは、ディスク１３０のいずれの場所に置かれる場合もあり得る。

基礎物理ボリュームをノード２００のようなストレージシステムの１以上の仮想ボリューム（又はフレキシブルボリューム）に分配するファイルシステムレイアウトが提供される。そのようなファイルシステムレイアウトの一例は、２００８年８月５日に発行され、ネットアップ，インコーポレイテッドに譲渡されたジョン・ケイ・エドワード他による「EXTENSION OF WRITE ANYWHERE FILE SYSTEM LAYOUT」と題する米国特許第７，４０９，４９４号に記載されている。基礎物理ボリュームは、ノードのＲＡＩＤグループのような、ディスクの１以上のグループを含むアグレゲートである。アグレゲートは、独自の物理ボリュームブロック番号（ｐｖｂｎ）空間を有し、そのｐｖｂｎ空間の中に、ブロックアロケーション構造のようなメタデータを保持している。各フレキシブルボリュームは、独自の仮想ボリュームブロック番号（ｖｖｂｎ）空間を有し、そのｖｖｂｎ空間の中に、ブロックアロケーション構造のようなメタデータを保持している。各フレキシブルボリュームは、コンテナファイルに関連するファイルシステムであり、コンテナファイルは、フレキシブルボリュームにより使用される全ブロックを含むアグレゲート中のファイルである。さらに、各フレキシブルボリュームは、データブロックと、他の間接ブロック又はデータブロックのいずれかを指し示すブロックポインタを含む間接ブロックとを含む。

一実施形態において、ｐｖｂｎは、フレキシブルボリュームに記憶される（ファイル７００のような）ファイルのバッファツリーの中においてブロックポインタとして使用される。この「ハイブリッド」フレキシブルボリューム実施形態は、ｐｖｂｎのみを親間接ブロック（例えば、ｉｎｏｄｅ又は間接ブロック）に挿入することを必要とする。論理ボリュームの読み出しパスにおいて、「論理」ボリューム（ｖｏｌ）情報ブロックは、１以上のｆｓｉｎｆｏブロックを参照する１以上のポインタを有し、さらに、各ポインタは、ｉｎｏｄｅファイル、及びそれに対応するｉｎｏｄｅバッファツリーを指し示す。フレキシブルボリュームの読み出しパスは一般に、ブロックの適当な位置を見付けるための同じ次のｐｖｂｎである（ｖｖｂｎではなく）。この文脈において、フレキシブルボリュームの読み出しパス（及び、対応する読み出し処理能力）は、物理ボリュームのものと実質的に同様である。ｐｖｂｎからｄｉｓｋ，ｄｂｎへの変換は、ストレージオペレーティングシステム３００のファイルシステム／ＲＡＩＤシステム境界において行われる。

デュアルｄｂｎハイブリッドフレキシブルボリュームの一実施形態において、ｐｖｂｎ、及びそれに対応するｖｖｂｎは、ファイルのバッファツリーにおける親間接ブロックに挿入される。すなわち、ｐｖｂｎ及びｖｖｂｎは、例えばレベル１（Ｌ１）間接ブロック、ｉｎｏｄｅファイルレベル０（Ｌ０）ブロックのような他のブロックへのポインタを有する大半のバッファツリー構造において、各ブロックポインタについて一対として記憶される。図８は、本発明に有利に使用することが可能なファイル８００のバッファツリーの例示的実施形態を示す略ブロック図である。埋め込みｉｎｏｄｅのようなルート（最上位）ｉｎｏｄｅ８０２は、間接（例えば、レベル１）ブロック８０４を参照する。なお、ファイルのサイズによっては、さらに別のレベルの間接ブロック（例えば、レベル２、レベル３）が存在する場合もある。間接ブロック（及びｉｎｏｄｅ）は、ｐｖｂｎ／ｖｖｂｎポインタ対構造８０８を含み、構造８０８は、最終的に、ファイルの実際のデータの記憶に使用されるデータブロック８０６を参照する。

ｐｖｂｎは、アグレゲートの種々のディスク上の位置を参照する一方、ｖｖｂｎは、フレキシブルボリュームの種々のファイル内の位置を参照する。間接ブロック８０４におけるブロックポインタ８０８のようなｐｖｂｎの使用は、読み出しパスにおける効率を提供する一方、ｖｖｂｎブロックポインタの使用は、要求されたメタデータへの効率的アクセスを提供する。すなわち、ファイルのブロックを開放するとき、ファイル中の親間接ブロックは、直ちに使用可能なｖｖｂｎブロックポインタを有し、当該ポインタにより、ｐｖｂｎからｖｖｂｎへの変換を実施するための所有者マップのアクセスに関連する待ち時間は回避されるが、読み出しパスにおいては、ｐｖｂｎが使用可能である。

図９は、本発明に有利に使用することが可能なアグレゲート９００の一実施形態を示す略ブロック図である。ｌｕｎ（ブロック）９０２、ディレクトリ９０４、ｑｔｒｅｅ９０６、及びファイル９０８は、デュアルｖｂｎフレキシブルボリュームのようなフレキシブルボリューム９１０の中に収容され、さらに、アグレゲート９００の中に収容される場合がある。アグレゲート９００は、例えば、ＲＡＩＤシステムの最上部に層として形成され、ＲＡＩＤシステムは、少なくとも１つのＲＡＩＤプレックス９５０によって表され（ストレージ構成がミラーリングされるか否かによって変わる）、各プレックス９５０は、少なくとも１つのＲＡＩＤグループ９６０を含む。各ＲＡＩＤグループは、例えば１以上のデータ（Ｄ）ディスク及び少なくとも１つのパリティ（Ｐ）ディスクのような、複数のディスク９３０をさらに含む。

アグレゲート９００は、従来のストレージシステムの物理ボリュームに類似する一方、フレキシブルボリュームは、その物理ボリューム中のファイルに類似する。すなわち、アグレゲート９００は、１以上のファイルを含む場合があり、各ファイルは、１つのフレキシブルボリューム９１０を含み、種々のフレキシブルボリュームにより消費される記憶空間の合計は、物理ボリューム全体のサイズよりも物理的に小さい（又は等しい）。アグレゲートは、「物理」ｐｖｂｎ空間を利用して、物理ボリュームの種々のディスクにより提供されるブロックの記憶空間を定義するのに対し、（ファイル内の）各埋め込みフレキシブルボリュームは、「論理」ｖｖｂｎ空間を利用して、例えばファイルのようなそれらのブロックを編成する。各ｖｖｂｎ空間は、ファイル内の種々の位置に対応する独立した一組の数値であり、その位置は、その後、ディスク上のｄｂｎに変換される。フレキシブルボリューム９１０もまた、論理ボリュームであるため、そのｖｖｂｎ空間において独自のブロックアロケーション構造（例えば、アクティブマップ、空間マップ、及び概要マップ）を有する。

コンテナファイルは、フレキシブルボリュームにより使用される全てのブロックを保持するアグレゲート中のファイルである。コンテナファイルは、フレキシブルボリュームをサポートする内部機能（アグレゲートにとって）であり、例えば、１つのフレキシブルボリュームにつき１つのコンテナが存在する。ファイルアプローチにおける純粋な論理ボリュームと同様に、コンテナファイルは、フレキシブルボリュームにより使用されるあらゆるブロックを保持するアグレゲート中の隠しファイル（ユーザにとってアクセスできないファイル）である。アグレゲートは、次のようなフレキシブルボリュームのサブディレクトリを含む例示的な隠しメタデータルートディレクトリを含む。

ＷＡＦＬ／ｆｓｉｄ／ファイルシステムファイル、ストレージラベルファイル

具体的には、物理的ファイルシステム（ＷＡＦＬ）ディレクトリは、アグレゲート中の各フレキシブルボリュームについてサブディレクトリを含み、サブディレクトリの名称は、フレキシブルボリュームのファイルシステム識別子（ｆｓｉｄ）になっている。各ｆｓｉｄサブディレクトリ（フレキシブルボリューム）は、少なくとも２つのファイル、１つのファイルシステムファイル、及び１つのストレージラベルファイルを有する。ストレージラベルファイルは、例えば、従来のｒａｉｄラベルに記憶されるものに類似するメタデータを有する４ＫＢファイルである。換言すれば、ストレージラベルファイルは、ｒａｉｄラベルに類似し、したがって、例えば、フレキシブルボリュームの名称、フレキシブルボリュームのユニバーサルユニーク識別子（ｕｕｉｄ）、及びｆｓｉｄ、並びに、フレキシブルボリュームがオンラインであるか、作成中であるか、又は破壊されているところであるか等のような、フレキシブルボリュームの状態に関する情報を有する。

図１０は、アグレゲート１０００のディスク上の表現を示す略ブロック図である。例えばＲＡＩＤシステム３８０のようなストレージオペレーティングシステム３００は、ｐｖｂｎの物理ボリュームを組み立て、アグレゲート１０００を作成する。ｐｖｂｎ１及び２は、そのアグレゲートについての「物理」ｖｏｌｉｎｆｏブロック１００２を含む。ｖｏｌｉｎｆｏブロック１００２は、ｆｓｉｎｆｏブロック１００４へのブロックポインタを含み、各ｆｓｉｎｆｏブロック１００４は、アグレゲートのスナップショットを表す場合がある。各ｆｓｉｎｆｏブロック１００４は、所有者マップ１０１０、アクティブマップ１０１２、概要マップ１０１４、及び空間マップ１０１６、並びに他の特殊なメタデータファイルを含む複数のファイルのｉｎｏｄｅを有するｉｎｏｄｅファイル１００６へのブロックポインタを含む。ｉｎｏｄｅファイル１００６は、ルートディレクトリ１０２０、及び「隠し」メタデータルートディレクトリ１０３０をさらに含み、そのうちの後者は、ユーザがその中のファイルを「見る」ことが出来ないフレキシブルボリュームに関連するファイルを有する名前空間を含む。隠しメタデータルートディレクトリは、ファイルシステムファイル１０４０、及びストレージラベルファイル１０９０を含むＷＡＦＬ／ｆｓｉｄ／ディレクトリ構造を含む。なお、アグレゲート中のルートディレクトリ１０２０は空であり、アグレゲートに関連する全てのファイルは、隠しメタデータルートディレクトリ１０３０の中に編成される。

ファイルシステムファイル１０４０は、コンテナマップとして編成されるレベル１ブロックを有するコンテナファイルとして実施されるほかに、フレキシブルボリューム１０５０として実施される種々のファイルシステムを参照するブロックポインタを含む。アグレゲート１０００は、それらのフレキシブルボリューム１０５０を特殊な予約済みｉｎｏｄｅ番号に維持する。各フレキシブルボリューム１０５０も、とりわけ、ブロックアロケーションビットマップ構造のために使用されるそのフレキシブルボリューム空間の中に、特殊な予約済みｉｎｏｄｅ番号を有する。上記のように、例えば、アクティブマップ１０６２、概要マップ１０６４、及び空間マップ１０６６のよなブロックアロケーションビットマップ構造は、各フレキシブルボリュームに配置される。

具体的には、各フレキシブルボリューム１０５０は、隠しメタデータルートディレクトリ１０８０の中に所有者マップ、及びＷＡＦＬ／ｆｓｉｄ／ファイルシステム，ストレージラベルファイルディレクトリ構造が存在しない点を除き、アグレゲートと同じｉｎｏｄｅファイル構造／中身を有する。その目的のために、各フレキシブルボリューム１０５０は、１以上のｆｓｉｎｆｏブロック１０５４を指し示すｖｏｌｉｎｆｏブロック１０５２を有し、各ｆｓｉｎｆｏブロック１０５４は、フレキシブルボリュームのアクティブファイルシステムとともに、スナップショットを表す場合がある。さらに、各ｆｓｉｎｆｏブロックは、上記のように、上記の点を除き、アグレゲートと同じｉｎｏｄｅ構造／中身を有するｉｎｏｄｅファイル１０６０を指し示す。各フレキシブルボリューム１０５０は、独自のｉｎｏｄｅファイル１０６０及び対応するｉｎｏｄｅ番号を有する個別のｉｎｏｄｅ空間、並びに、独自のルート（ｆｓｉｄ））ディレクトリ、及び他のフレキシブルボリュームとは別にエキスポートすることが可能なファイルのサブディレクトリを有する。

アグレゲートの隠しメタデータルートディレクトリ１０３０の中に収容されるストレージラベルファイル１０９０は、従来のｒａｉｄラベルに類似した機能を有する小さなファイルである。ｒａｉｄレベルは、ボリューム名のような、ストレージシステムに関する物理的情報を含み、その情報は、ストレージラベルファイル１０９０にロードされる。例えば、ストレージラベルファイル１０９０は、関連フレキシブルボリューム１０５０の名称１０９２、そのフレキシブルボリュームのオンライン／オフライン状態１０９４、及び、関連フレキシブルボリュームの他の識別・状態情報１０９６（そのフレキシブルボリュームが、作成処理中であるか、又は破壊処理中であるか）を含む。

Ｆ．ＶＬＤＢ
図１１は、クラスタのノードについて構成情報（すなわち、管理データ）の管理を提供するために、ユーザモードアプリケーション１１００としてストレージオペレーティングシステム３００上で実行される一群の管理プロセスを示す略ブロック図である。その目的のために、管理プロセスは、管理フレームプロセス１１１０、及びボリューム位置データベース（ＶＬＤＢ）プロセス１１３０を含み、各プロセスは、ライブラリとしてリンクされたデータ複製サービス（ＲＤＢ１１５０）を使用する。管理フレームワーク１１１０は、コマンドラインインタフェース（ＣＬＩ）及び／又はウェブベースのグラフィカルユーザインタフェース（ＧＵＩ）による管理者インタフェース１１７０を、ユーザに提供する。管理フレームワークは、例えば、ユーザ／システム管理者がクラスタ１００を管理するためにノード２００と情報をやりとりする際に、その相手先となるエンティティを提供する従来のコモン・インタフェース・モデル（ＣＩＭ）オブジェクトマネージャに基づく場合がある。

ＶＬＤＢ１１３０は、クラスタ１００内の種々のストレージコンポーネント（例えば、ＳＶＳ、フレキシブルボリューム、アグレゲートなど）の位置を追跡管理し、それによってクラスタ全体を通じた要求のルーティングを可能にするデータベースプロセスである。例示的実施形態において、各ノードのＮモジュール３１０は、データコンテナハンドル５００のＳＶＳ ＩＤ５０２を、クラスタ内のそのデータコンテナを「所有している」（提供している）Ｄモジュール３５０にマッピングする構成ファイル２３５にアクセスする。ＶＬＤＢは、複数のエントリを有し、さらに、構成テーブル２３５中の種々のエントリの中身を提供する。とりわけ、それらのＶＬＤＢエントリは、クラスタ内におけるフレキシブルボリューム（以後、一般に「ボリューム９１０」）及びアグレゲート９００の位置を追跡管理する。そのようなＶＬＤＢエントリの例としては、ＶＬＤＢボリュームエントリ１２００、及びＶＬＤＢアグレゲートエントリ１３００が挙げられる。

図１２は、例示的なＶＬＤＢボリュームエントリ１２００を示す略ブロック図である。エントリ１２００は、ボリュームＩＤフィールド１２０５、アグレゲートＩＤフィールド１２１０を含み、代替実施形態では、さらに別のフィールド１２１５を含む場合がある。ボリュームＩＤフィールド１２０５は、ボリューム探索プロセスにおいて使用されるボリューム９１０を識別するＩＤを有する。アグレゲートＩＤフィールド１２１０は、ボリュームＩＤフィールド１２０５により識別されるボリュームを有するアグレゲート９００を識別する。同様に、図１３は、例示的なＶＬＤＢアグレゲートエントリ１３００を示す略ブロック図である。エントリ１３００は、アグレゲートＩＤフィールド１３０５、ＤモジュールＩＤフィールド１３１０を含み、代替実施形態では、さらに追加フィールド１３１５を含む場合がある。アグレゲートＩＤフィールド１３０５は、クラスタ１００における特定のアグレゲート９００のＩＤを有する。ＤモジュールＩＤフィールド１３１０は、アグレゲートＩＤフィールド１３０５により識別される特定のアグレゲートを有しているＤモジュールのＩＤを有する。

ＶＬＤＢは、Ｎモジュール３１０がＶＬＤＢ１１３０に問合せをすることを可能にする、例えばＳｕｎ ＲＰＣインタフェースのような、ＲＰＣインタフェースを実施する。Ｎモジュールは、自分の構成江ｔ-ブルに記憶されていないデータコンテナハンドル５００の中身に遭遇すると、ＲＰＣをＶＬＤＢプロセスへ送信する。これに応答し、ＶＬＤＢ１１３０は、そのデータコンテナを所有しているＤモジュールのＩＤを含む適当なマッピング情報を、Ｎモジュールに返す。Ｎモジュールは、この情報を自分の構成テーブル２３５にキャッシュし、ＤモジュールＩＤを使用して、到来する要求を適当なデータコンテナへ転送する。Ｎモジュール３１０とＤモジュール３５０の間の全ての機能、及び情報のやりとりは、一群の管理プロセス、及びＲＤＢライブラリユーザモードアプリケーション１１００により、クラスタ幅単位で適宜実施される。

その目的のために、管理プロセスは、ＲＤＢ１１５０に対する（ＲＤＢ１１５０にに密接に結合された）種々のインタフェースを有する。ＲＤＢは、管理プロセスにより処理される管理データの永久的オブジェクト記憶（オブジェクトの記憶）を提供するライブラリを含む。特に、ＲＤＢ１１５０は、管理データオブジェクト記憶アクセスを、クラスタ１００の全てのノード２００にわたって複製し、同期させ、それによって、ＲＤＢデータベースイメージが、全てのノード２００上において同一となることを確保する。システム始動時に、各ノード２００は、自分が有するインタフェースのステータス／状態、及びＩＰアドレス（自分が「所有」するＩＰアドレス）を、ＲＤＢデータベースに記録する。

Ｇ．ストレージシステムアーキテクチャ
提供されるストレージアーキテクチャは、例えば、クラスタ１００の複数のノード２００にわたって分散された２以上のボリューム９１０を含む。これらのボリュームは、１つのＳＶＳとして編成され、クライアント１８０により発行されたマルチプロトコルデータアクセス要求に応答し、クラスタにより提供されるファイル及びｌｕｎのようなデータコンテナの中身を記憶するように構成される。特に、各データコンテナの中身は、ＳＶＳの種々のボリュームにわたって分配され、それによって、クラスタにより提供されるストレージサービスの効率が改善される。本発明の説明及び理解を容易にするために、データコンテナは、以後、一般に「ファイル」と呼ばれる。

ＳＶＳは、メタデータボリューム（ＭＤＶ）と、１以上のデータボリューム（ＤＶ）とを含む。ＭＤＶは、ＳＶＳに記憶される全てのファイルに関連する、アクセスコントロールリスト（ＡＣＬ）及びディレクトリのような、メタデータの正統なコピーを記憶するように構成されるのに対し、各ＤＶは、少なくともそれらのファイルのデータ内容を記憶するように構成される。ＳＶＳ上に記憶される各ファイルについて、１つのボリュームはＣＡＶに指定され、その目的のために、そのファイルに関連する特定の急速に変化する属性メタデータを記憶（「キャッシュ」）するように構成され、それによって、通常ならばＭＤＶへ向けられることになるアクセス要求の負荷を低減する。本明細書に記載される一実施形態において、ファイルについてのＣＡＶの決定は、次のような単純なルールに基づく。すなわち、そのファイルの中身（データ）の第１のストライプを保持しているボリュームを、そのファイルのＣＡＶとして指定するというものである。この単純なルールは、単に便利というだけでなく、小さなファイルの最適化も提供する。すなわち、ファイルが、指定されたストライプ幅の中にフィットするくらい十分に小さい場合、ＣＡＶは、ＳＶＳの他のボリュームと通信する必要なく、特定の処理を実施することができる場合がある。理想的には、種々のファイルについてのデータの第１のストライプは、ＳＶＳの種々のＤＶにわたって分散され、それによって、ＳＶＳの種々のボリュームにわたるＣＡＶ指定の均一な分散が可能となる。代替実施形態として、種々のファイルについてのデータは、ＭＤＶ及びＤＶにわたってストライピングされる場合がある。さらに別の実施形態として、ＭＤＶは省略される場合があり、ＭＤＶ上に通常収容されるデータは、ＳＶＳの種々のＤＶにわたって分散される場合がある。

図１４は、本発明の例示的実施形態によるＳＶＳ１４００を示す略ブロック図である。ＳＶＳ１４００は、例えば、３つのボリューム、すなわち、ＭＤＶ１４０５、及び２つのＤＶ１４１０、１４１５を含む場合がある。なお、代替実施形態では、本発明に従って、更に別の、及び／又は異なる数のボリュームが使用される場合もある。例えば、ＭＤＶ１４０５は、ルートディレクトリ（ＲＤ）ｉｎｏｄｅ１４２０、ディレクトリ（ＤＩＲ）ｉｎｏｄｅ１４３０、ファイル（Ｆ）ｉｎｏｄｅ１４２５、１４３５、１４４５、及びＡＣＬｉｎｏｄｅ１４４０を含む複数のｉｎｏｄｅを記憶する場合がある。これらのｉｎｏｄｅはそれぞれ、例えば、ｉｎｏｄｅに関連するメタデータ（Ｍ）を有する場合がある。例示的実施形態において、ＭＤＶ１４０５上の各ｉｎｏｄｅは、データ（Ｄ）を持たないが、代替実施形態において、ＭＤＶは、ユーザデータを有する場合がある。

これに対し、各ＤＶ１４１０、１４１５は、ファイル（Ｆ）ｉｎｏｄｅ１４２５、１４３５、１４４５、及びＡＣＬｉｎｏｄｅ１４４０のみを記憶する。ここで、ＤＶは、ディレクトリ、又は、シンボリックリンクのような他のデバイスｉｎｏｄｅ／構成を記憶しない。しかしながら、各ＤＶは、Ｆｉｎｏｄｅを記憶し、さらに、ＭＤＶ１４０５における対応するｉｎｏｄｅと同じ位置に配置されたＡＣＬｉｎｏｄｅのキャッシュコピーを記憶する場合がある。ＤＶによっては、ｉｎｏｄｅに関連するデータコンテナに対するＩ／Ｏ要求が、そのＤＶを提供しているＤモジュールによって受信されるまで、ｉｎｏｄｅのコピーを記憶しないものがある。さらに、それらのＦｉｎｏｄｅにより表される種々のファイルの中身は、本明細書に詳しく記載されるようなＳＶＳストライピングルールに従って、周期的に散在される。さらに、ＳＶＳ１４００に記憶される各ファイルについて１つのボリュームがＣＡＶとして指定されるため、ＤＶ１４１５は、ｉｎｏｄｅ１４２５により表されるファイルのためのＣＡＶとして指定され、ＤＶ１４１０は、ｉｎｏｄｅ１４３５、１４４５により識別されるファイルのためのＣＡＶとされる。したがって、これらのＣＡＶは、例えばファイルサイズ６１５のような、それらのファイルに関連する特定の急速に変化する属性メタデータ（Ｍ）、並びに、アクセス及び／又は変更タイムスタンプ６２０をキャッシュする。

例えば、ＳＶＳは、ストライプアルゴリズム、ストライプ幅、及びＳＶＳ内のボリュームの順序付きリストを定義する一組のストライピングルール（例えば、ストライピングテーブルとして実施されるストライピングデータ構造）に関連する。なお、本明細書ではストライピングテーブルという用語を使用するが、この用語は、ＶＳＭがデータをＳＶＳ上にストライピングする際の順序を特定できるようにする任意の形のデータ構造を意味するものと解釈すべきである。各ＳＶＳについてのストライピングルールは、例えば、ＶＬＤＢ１１３０の１つのエントリとして記憶され、ＳＶＳ ＩＤによりアクセスされる場合がある。図１５は、本発明の一実施形態による例示的なＶＬＤＢ ＳＶＳエントリ１５００を示す略ブロック図である。ＶＬＤＢエントリ１５００は、ＳＶＳ ＩＤフィールド１００５と、一組以上のストライピングルール１５３０とを含む。代替実施形態では、更に別のフィールド１５３５が含まれる場合もある。動作中、ＳＶＳ ＩＤフィールド１５０５は、データコンテナハンドル５００において指定されたＳＶＳのＩＤを有する。

ストライピングルール１５３０の各組は、例えば、ストライプ幅フィールド１５１０、ストライプアルゴリズムＩＤフィールド１５１５、ボリュームの順序付きリストフィールド１５２０を含み、代替実施形態では、さらに別のフィールド１５２５を含む場合がある。ストライピングルール１５３０は、ＳＶＳの構成を特定するための情報を含む。例えば、ストライプアルゴリズムＩＤフィールド１５１５は、ＳＶＳに使用されるストライピングアルゴリズムを特定する。一実施形態では、複数のストライピングアルゴリズムが、ＳＶＳに使用される場合があり、したがって、ストライプアルゴリズムＩＤは、どの特定のアルゴリズムを使用するかを特定するために必要となる。さらに、各ストライピングアルゴリズムは、ファイルの中身をＳＶＳの複数のボリュームにわたってストライプとして分配する態様を指定する。ストライプ幅フィールド１５１０は、各ストライプのサイズ／幅を指定する。

ボリュームの順序付きリストフィールド１５２０は、ＳＶＳを構成する種々のボリュームのＩＤを含み、本発明の例示的実施形態に従って、能力均一化態様を成すデータレイアウトを決定するためのストライピングテーブルとして機能する。例示的実施形態において、ボリュームの順序付きリストは、フレキシブルボリュームＩＤ、及びそのフレキシブルボリュームを記憶しているアグレゲートＩＤを含む複数のタプルを含む。さらに、ボリュームの順序付きリストは、ＳＶＳの種々のボリューム、及びストライピングルールの機能及び実施形態を指定する場合がある。例えば、順序付きリストにおける第１のボリュームは、ＳＶＳのＭＤＶを表す場合があるのに対し、リスト中のボリュームの順序は、例えばラウンドロビンのような特定のストライピングアルゴリズムの実施の態様を表す場合がある。

動作において、ストライピングルールの組は、事実上、ＳＶＳの種々のブロックを記憶するために使用すべきＤモジュールの順序付きセットを特定するストライピングテーブルを定義する。ＳＶＳをそれらの種々のＤモジュールにわたって分配することにより、単一モジュールの全体的処理消費は制限され、したがって、特定のモジュールが例えばホットスポットになることによりバックログを生成する可能性は、低減される。

ＶＳＭ３７０及び他のモジュール（例えば、Ｎモジュール３１０のもの）が、ファイルへのアクセス要求に対するサービスを提供するために、ＳＶＳ１４００のＤモジュール３５０、及びそれに関連するボリュームの探索を可能にするために、Ｌｏｃａｔｅ（）関数が用意される。Ｌｏｃａｔｅ（）関数は、少なくとも、（１）ＳＶＳ ＩＤ１５０５、（２）ファイル内オフセット、（３）ファイルのｉｎｏｄｅ番号、（４）一組のストライピングルール１５３０を引数としてとり、ＳＶＳ１４００内においてそのオフセットが開始されるボリューム９１０を返す。例えば、ファイルに対するデータアクセス要求が、クライアント１８０により発行され、ノード２００のＮモジュール３１０において受信される場合を仮定した場合、そこで、そのデータアクセス要求は、マルチプロトコルエンジン３２５により構文解析され、Ｎモジュール３１０の適当なプロトコルサーバへ渡される。

ＣＦメッセージを送信する宛先となるＤモジュール３５０の位置を決定するために、Ｎモジュール３１０は、まずＳＶＳエントリ１５００を読み出し、ＳＶＳに関連するストライピングルール（及び、ボリュームのリスト１５２０）を取得する場合がある。次にＮモジュール３１０は、Ｌｏｃａｔｅ（）関数３７５を実行し、処理の対象となる適当なボリュームを特定する。以後、Ｎモジュールは、適当なＶＬＤＢボリュームエントリ１２００を読み出し、そのボリューム、及び適当なＶＬＤＢアグレゲートエントリ１３００を含むアグレゲートを特定し、最終的に、適当なＤモジュール３５０を特定する場合がある。その後、Ｎモジュール３１０のプロトコルサーバは、ＣＦメッセージ４００をそのＤモジュール３５０へ送信する。

図１６は、本発明の例示的実施形態によるＳＶＳ１６００のボリュームＡ１６０５、Ｂ１６１０、及びＣ１６１５に記憶されたファイル内容の周期的な散在を示す略ブロック図である。上記のように、ファイル内容は、ＳＶＳストライピングルールに従って周期的に散在され、当該ルールは、（ストライプアルゴリズムＩＤフィールド１５１５により示されるような）ストライピングアルゴリズム、及び（ストライプ幅フィールド１５１０により示されるような）各ストライプのサイズ／幅を指定する。なお、一実施形態において、ストライプ幅は、各ストライプが、ファイルの間接ブロック（例えば、レベル１ブロック８０４）により参照される（例えば、データブロック８０６に記憶されるような）実際のデータを受け入れることが出来るように選択される場合がある。

例示的なラウンドロビンストライピングアルゴリズムによれば、ボリュームＡ１６０５は、１ストライプのファイル内容又はデータ（Ｄ）１６２０、その後に続く２ストライプのスパースネス（Ｓ）１６２２、１６２４、他のストライプのデータ（Ｄ）１６２６、及び２ストライプのスパースネス（Ｓ）１６２８、１６３０を含む。一方、ボリュームＢ１６１０は、１ストライプのスパースネス（Ｓ）１６３２、その後に続く１ストライプのデータ（Ｄ）１６３４、２ストライプのスパースネス（Ｓ）１６３６、１６３８、他のストライプのデータ（Ｄ）１６４０、及び１ストライプのスパースネス（Ｓ）１６４２を含む。ボリュームＣ１６１５は、ラウンドロビンストライピングパターンを継続し、その目的のために、２ストライプのスパースネス（Ｓ）１６４４、１６４６、その後に続く１ストライプのデータ（Ｄ）１６４８、２ストライプのスパースネス（Ｓ）１６５０、１６５２、及び他のストライプのデータ（Ｄ）１６５４を含む。

Ｈ．能力平準化
本発明は、ストライプ化ファイルシステムにおける能力平準化を提供するように構成されたデータ分散技術を提供する。ストライプ化ボリュームセットは、例えば、ボリュームの順序付きリスト、及びデータをストライピングする宛先となる関連ノードを特定するストライピングテーブル１５００を含む一組のストライピングルールに関連する。クラスタの各ノードは、ＳＶＳのボリュームを提供するように構成されたディスク要素と、データアクセス要求をクラスタのいずれかのデモジュールへリダイレクトするように構成されたネットワーク要素とを含む。データコンテナの中身は、ＳＶＳの種々のボリュームにわたって分配され、それによって、クラスタにより提供されるストレージサービスの効率は向上される。その目的のために、ストライピングテーブルは、データコンテナの中身を複数のボリュームにわたってストライプとして分配する態様を指定する。動作として、新たなノードをストライプ化ボリュームセットに追加するとき、ストライピングテーブルは、その新たに追加されたノードを受け入れるように発展され、すなわち、繰り返し更新される。一実施形態において、クラスタの各ノードは、例えば、そのノードについてのプロセッサ速度、プロセッサの数、ハードウェア構成、及び／又は使用可能なソフトウェアを考慮に入れた能力値に関連する。ストライピングテーブルの発展処理の際、本技術は、ＳＶＳの種々のストライプを、ストライプが各ノードの能力値に従って種々のノードに最適に割当てられるような形で、種々のノードに分配する。例えば、第１のノードが能力値１００を有し、第２のノードが能力値２００を有する２ノードシステムの場合、最適な処理能力を得るためには、第２のノードは、第１のノードに比べて２倍の量のストライプを提供しなければならない。本明細書に記載される能力値を含むストライピングテーブルの使用により、ヘテロジニアスなノード、すなわち、異なる能力値を有するノードを、ストライプ化ボリュームセットの中で良好に使用することができ、それによって、活用されない処理リソースを減らすことができる。すなわち、高い能力値のノードを必要とすることなく、ノードを使用してノードの処理能力をクラスタ内の最も非力なノードに調節することができる。

図１７は、本発明の例示的実施形態による、図１６に示したデータコンテナについての例示的なストライピングテーブルを示す略ブロック図である。例えば、ストライピングテーブル１７００は、データコンテナの第１のブロックが、第１のノードのボリュームＡに記憶され、第２のブロックが、第２のノードのボリュームＢに記憶される、等を示す場合がある。ストライピングテーブル１７００は、本発明の例示的実施形態にしたがってラウンドロビン態様を成すように、例えばＶＳＭ３７５によって生成される場合がある。当業者には明らかなように、ストライピングテーブルは通常、例示的なストライピングテーブル１７００よりも遥かに大きい。同様に、種々のノードの構成は、単に例示の目的で、ラウンドロビンとして示されている。

図１８は、本発明の例示的実施形態に従って能力平準化を実施するために、ストライピングテーブルを発展させる手順１８００の種々のステップの詳細を示すフロー図である。手順１８００は、ステップ１８０５から開始され、ステップ１８１０へ進み、そこで新たなノードが、クラスタに追加される。新たなノードのクラスタへの追加は、例えば管理者、及び／又は他のユーザが、その新たなノードをクラスタスイッチファブリック１５０に物理的に接続し、その新たなノードのＮ／Ｄモジュール上で実行されるストレージオペレーティングシステム、及び／又は他のソフトウェアを構成することにより成される場合がある。

さらに、本発明の一実施形態によれば、クラスタの新たに追加されたノードにはそれぞれ、一般にそのノードのベンダ（例えば、製造業者）により、能力値が割当てられる。但し、代替実施形態では、能力値は、管理者、及び／又は自動化プロセスによって割当てられる場合もある。この能力値は、以下で詳しく説明されるストライピングテーブル発展技術を開始するために、クラスタの種々のノードのボリュームストライピングモジュール３７０に提供される場合がある。新たなノードの追加に応答し、ステップ１８１５において、ストライピングテーブルは、新たなノードを受け入れるように発展される。一般に、本明細書に記載される技術は、各ノードが、そのノードの能力値を（その新たなノードを含む）クラスタ中の全能力値の合計で割ったものに概ね比例するような形で、ストライピングテーブルを発展させる。すなわち、ノードＸの概算の比率は、ノードＸの能力値をクラスタの全ノードの全能力値の合計で割ったものに等しい。ストライピングテーブルの発展については、図１９を参照して以下で詳しく説明される。

新たなストライピングテーブルが発展され、すなわち繰り返し更新された後、ステップ１８２０において、次に、新たなストライピングテーブルは、ＳＶＳに関連付けられる。例えば、ステップ１８２５において、次に、再ストライピング処理が実施される。再ストライピング処理は一般に、データが、発展されたストライピングテーブルに従ってストライピングされ、すなわち、データが、本発明の一実施形態から得られる能力平準化に従って分散されるような形での、ＳＶＳ中の全データの再割当てを生じさせる。なお、再ストライピング処理の実施は、任意選択的なものである。一部の特定の実施形態では、データは、ストライプ化ボリュームセットに書き込まれるときに、再ストライピングされる場合がある。

手順１８００は、ステップ１８３０において終了する。

図１９Ａ〜図１９Ｄは、本発明の例示的実施形態による発展中のストライピングテーブルを示す略ブロック図である。説明のために図１９を参照し、管理者が、ヘテロジニアスノードの４ノードクラスタを形成することを望んでいる場合を仮定する。３つのノードは、下記の能力レートを有している。

ノードＡ １００
ノードＢ ２００
ノードＣ ５０
ノードＤ ５０

当業者には明らかなように、この例において記載される原理は、任意数の異なる、及び／又は同一の能力値を有する任意数のノードに使用することができる。したがって、ストライピングテーブル１９００の発展に関する本明細書の説明は、単なる例として解釈すべきである。動作として、ストライピングテーブルはまず、図１９Ａに示したような単一のエントリテーブルとして生成される。単一ノードクラスタの場合、データの各ストライプは、クラスタの単一のノードに、すなわち、この例ではノードＡに記憶される。

例えば、管理者は、クラスタ中に全部で４つのノードを得るために、３つのさらに別のノードが追加されることに示すように、ボリュームストライピングモジュールを構成した。次に、ボリュームストライピングモジュールは、各エントリについてサポートの追加を繰り返し開始する場合がある。新たなノードのためのエントリを最初に追加することにより、ボリュームストライピングモジュール３７０は、その新たに追加されたエントリについてのみではなく、ストライピングテーブル中に表されるべき他の全ての他のエントリについても、能力値を考慮する。これを考慮に入れることにより、ストライピングテーブルにおけるノードＡの発生の正しい回数が得られ、それによって、その後の繰り返しの際にノードＡのインスタンスを置き換える必要性を、未然に取り除くことができる。一実施形態において、各ノードは、ストライピングテーブルにおいて、その能力値をクラスタ内のノードの全ての能力値の合計で割ったものに概ね比例する形で現れることになる。

上記の例示的な能力値が与えられた場合、所望の表現は、Ａの能力レートを合計能力レートで割ったもの、すなわち、ＡをＡ＋Ｂ＋Ｃ＋Ｄで割ったものに等しい。これは例えば、１００を４００（１００＋２００＋５０＋５０）で割ったものに等しい。したがって、ボリュームストライピングモジュールは、Ｂ＋Ｃ＋Ｄ（すなわち、後で追加されることになるノードの合計能力値）をＡ＋Ｂ＋Ｃ＋Ｄ（すなわち、全ての能力値の合計）のレートで割った数のエントリを、すなわち、４００エントリにつき３００エントリを第１の繰り返しにおいて置き換える。数学的削減を実施することにより、ボリュームストライピングモジュールは、ストライピングテーブルにおいて４つのエントリにつき３つのエントリをＢに置き換えるべきことを決定する。このグループ内における置換は、Ａのエントリを新たな値Ｂに置き換えることにより成されるべきである。例えば、どのエントリを置き換えるべきかの厳密な選択は、例えば、「SEMI-STATIC DISTRIBUTION TECHNIQUE」と題する米国特許第７，１８５，１４４号に記載されているような準静的技術により実施され、この特許の内容は、参照により本明細書に援用される。

次に、ＶＳＭ３７０は、次のエントリ（すなわち、エントリＣ）を追加することにより、反復的プロセスを繰り返す。この例を継続し、ボリュームストライピングモジュールは、適当な総数のＢ’を残しつつ、ストライピングテーブルにおける十分な数のＢ’を置き換えるべきことを決定する。この場合も、これは、残すべきもののレートを合計レートで割ることにより決定される場合がある。これは、Ｃ＋ＤのレートをＢ＋Ｃ＋Ｄのレートで割ったものに等しいものとなり、それは１００／３００に等しい。この部分を減らすことにより、ボリュームストライピングモジュールは、３つのＢにつき１つのＢをＣに置き換えるべきことを特定した。そして、最終的な反復により、十分な数のＣが、Ｄに置換される。この数は、Ｄの能力値をＣ＋Ｄのレートで割ることにより計算される場合があり、それは、１つおきのＣ（すなわち、１／２）に等しい。図１９Ｄから分かるように、その結果は、ノードＡへの８つの参照、ノードＢへの１６個の参照、ノードＣへの４つの参照、及びノードＤへの４つの参照を有する例示的なストライピングテーブルとなる。

当然ながら、その結果、各ノードは、その能力レートに基づいて適当に分配されることになる。ノードＡを基準として使用した場合、ノードＤは、ノードＡの２倍の能力値を有しているため、ノードＡに比べて２倍の頻度で出現する、等。本明細書に記載した反復的技術を使用することにより、クラスタ内のヘテロジニアスなコンピュータの最適な使用を可能にする能力平準化を達成することができる。

上記の説明は、本発明の特定の実施形態に関するものである。しかし、当然ながら、それらの利点の一部又は全部を維持しつつ、記載した実施形態に対し、種々の変更及び修正を施すことも可能である。具体的には、本明細書に記載した技術は、非分散ファイルシステムにおいて実施されてもよい。さらに、本明細書の説明は、Ｎモジュール及びＤモジュールを例として記載されているが、本明細書の教示は、ＮモジュールとＤモジュールの機能が単一システムにおいて実施されるような種々のシステムにも等しく適用可能である。あるいは、ＮモジュールとＤモジュールの機能は、任意数の独立したシステムにわたって分散されてもよく、各システムが、そうした機能の１以上を実施する場合がある。さらに、本明細書に記載した手順、プロセス、及び／又はモジュールは、ハードウェアで実施されても、ソフトウェアで実施されても、プログラム命令を有するコンピュータ読取可能媒体として実施されても、ファームウェアとして実施されても、それらの組み合わせとして実施されてもよい。従って、添付の特許請求の範囲の目的は、そうした変更や修正もすべて、本発明の真の思想及び範囲の中に入るようにカバーすることにある。

Claims (21)

1. ストライプ化ファイルシステムをサポートするクラスタ化コンピュータシステムにおける能力平準化のための方法であって、
   前記ストライプ化ファイルシステムをサポートするために、前記クラスタ化コンピュータシステムとして編成された複数のノードの各ノードに、関連する能力値を割り当てるステップと、
   前記複数のノードのうちの１つのプロセッサ上で実行されるボリュームストライピングモジュールにより、ストライピングデータ構造中におけるノードの発生回数を繰り返し調節し、各ノードに関連する前記能力値に基づいて能力平準化されたストライピングデータ構造を生成するステップと
   データアクセス要求に応答し、前記能力平準化されたストライピングデータ構造を使用して、データ割り当てを実施するステップと
   からなる方法。
2. 前記ストライピングデータ構造において、各ノードは、その能力値を前記複数のノードの全能力値の合計で割ったものに概ね比例する形で、前記ストライピングデータ構造中に現れる、請求項１に記載の方法。
3. 準静的分散技術を使用して、前記ストライピング構造内におけるノードの発生回数を繰り返し調節するステップをさらに含む、請求項１に記載の方法。
4. 前記ストライプ化ファイルシステムに対し再ストライピング処理を実施し、前記能力平準化されたストライピングデータ構造を使用するステップをさらに含む、請求項１に記載の方法。
5. ノードのプロセッサ速度を使用してそのノードの能力値を決定するステップをさらに含む、請求項１に記載の方法。
6. 前記複数のノードは、異なる能力値に関連する、請求項１に記載の方法。
7. 前記ストライプ化ファイルシステムのストライプ化ボリュームセットを実施するステップをさらに含み、前記ストライプ化ボリュームセットは、複数のボリュームを含み、各ボリュームが、前記複数のノードのうちの１つに記憶される、請求項１に記載の方法。
8. 前記複数のノードのそれぞれからアクセス可能なボリューム位置データベースに、発展されたストライピングデータ構造を記憶するステップをさらに含む、請求項１に記載の方法。
9. データ割り当ては、能力平準化ストライピングデータ構造に従って前記複数のノードにわたってデータを分散させることを含む、請求項１に記載の方法。
10. ストライプ化ファイルシステムをサポートするクラスタ化コンピュータシステムにおいて使用される能力平準化されたストライピングデータ構造を生成する方法であって、
    前記ストライプ化ファイルシステムをサポートする前記クラスタ化コンピュータシステムとして編成された複数のノードの各ノードに、関連する能力値を割り当てるステップであって、前記能力値が、前記複数のノードのうちの他のノードと比較したときのあるノードに関連する処理速度の決定を反映する、前記クラスタ化コンピュータシステムとして編成された複数のノードの各ノードに、関連する能力値を割り当てるステップと、
    前記複数のノードのうちの１つのプロセッサ上で実行されるボリュームストライピングモジュールにより、ストライピングデータ構造中におけるノード発生回数を繰り返し調節し、各ノードに関連する前記能力値に基づいて能力平準化されたストライピングデータ構造を生成するステップであって、前記能力平準化されたストライピングデータ構造は、前記ノードの能力値を前記クラスタ化コンピュータシステムにおける全ノードの前記能力値の合計で割ったものに比例する形で各ノードを含む、能力平準化されたストライピングデータ構造を生成するステップと、
    前記ボリュームストライピングモジュールにより、前記能力平準化されたストライピングデータ構造を使用して、前記クラスタ化コンピュータシステムの前記ノードにわたってデータを割り当てるステップと
    からなる方法。
11. 各ノードがプロセッサを含む一組のノードであって、前記一組のノードに記憶された種々のボリュームに分配されたストライプ化ボリュームを含むストライプ化ファイルシステムをサポートするように構成された１つのクラスタとして編成され、前記一組のノードのそれぞれが、能力値に関連する、一組のノードと、
    前記プロセッサのうちの１つにおいて実行され、前記ストライプ化ボリュームセットの種々のストライプを前記一組のノードに記憶された種々のボリュームに分配するように構成され、各ノードが、ストライピングデータ構造において、そのノードの能力値を前記一組のノードの全能力値の合計で割ったものに概ね比例する形で現れるようにするボリュームストライピングモジュールと
    を含み、前記ストライプ化ファイルシステムは、データアクセス要求に応答し、前記ストライピングデータ構造を使用して、前記ストライプ化ファイルシステムに対するデータ割り当てを実施するようにさらに構成される、システム。
12. 前記ストライピングデータ構造は、前記一組のノードのそれぞれによってアクセス可能なボリューム位置データベースに記憶される、請求項１１に記載のシステム。
13. 前記一組のノードのそれぞれに、異なる能力値が割り当てられる、請求項１１に記載のシステム。
14. 前記ボリュームストライピングモジュールは、前記一組のノードへの新たなノードの追加に応答し、前記ストライピングデータ構造を発展させるようにさらに構成され、前記ストライピングデータ構造は、各ノードの能力値を前記一組のノードと前記新たなノードの全ての能力値の合計で割ったものに概ね比例する形で、前記一組のノード、及び前記新たなノードのそれぞれについてエントリを有する、請求項１１に記載のシステム。
15. 前記ボリュームストライピングモジュールは、前記ストライピングデータ構造を使用して、前記ストライプ化ボリュームセットに対し繰り返し処理を実施するようにさらに構成される、請求項１４に記載のシステム。
16. 前記ボリュームストライピングモジュールは、準静的分散技術を使用して、前記ストライピング構造内におけるノードの発生回数を繰り返し調節することにより、前記ストライプ化データ構造を発展させるようにさらに構成される、請求項１４に記載のシステム。
17. ストレージシステムのストライプ化ファイルシステムをサポートするために、クラスタとして構成された一組のノードに新たなノードを追加するステップと、
    前記ストライプ化ファイルシステムに関連するストライピングデータ構造を、前記新たなノードを取り込むように発展させるステップであって、発展されたストライピングデータ構造は、前記一組のノード及び前記新たなノードのそれぞれについて、前記ノードのそれぞれに関連する能力値を前記一組のノード及び前記新たなノードの全ての能力値で割ったものに概ね比例する形でエントリを有する、前記ストライプ化ファイルシステムに関連するストライピングデータ構造を発展させるステップと、
    データアクセス要求に応答し、能力平準化されたストライピングデータ構造を使用して、前記ストライプ化ファイルシステムに対するデータアロケーションを実施するステップと
    からなる方法。
18. 前記展開されたストライピングデータ構造を使用して、前記ストライプ化ファイルシステムに対する再ストライピング処理を実施するステップをさらに含む、請求項１７に記載の方法。
19. 前記ストライピングデータ構造を前記一組のノード及び前記新たなノードのそれぞれによりアクセス可能なボリューム位置データベースに記憶するステップをさらに含む、請求項１７に記載の方法。
20. 前記ストライピングデータ構造を発展させるステップは、準静的分散技術を使用する、請求項１７に記載の方法。
21. ストライピングデータ構造を発展させるステップは、追加すべきノードについての能力値を特定し、追加すべきノードについての能力値を、前記追加すべきノード、及び前記ストライプ化データ構造に追加すべき全ての他のノードの合計能力値で割ることを含む、請求項１７に記載の方法。

Images