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