JP5291456B2 - ストレージシステム・アーキテクチャ内のデータ・アロケーション - Google Patents

Description

発明の分野

[技術分野]
本発明の実施形態はストレージシステムに関し、特に、ストレージ・システム・クラスタの複数のボリュームにわたるデータ・アロケーションに関する。

[背景]
一般に、ストレージシステムは、当該ストレージシステムに接続された１以上の記憶装置に格納された情報へのアクセスを提供する。情報へのアクセスは、それらの記憶装置をボリュームに編成することによって可能となり、記憶装置に格納される情報は、ボリュームによって論理編成される。記憶装置は通常、ディスクアレイとして編成された複数のディスクドライブである。ここで、「ディスク」という用語は、内蔵型の回転式磁気媒体記憶装置を表わす。また、この文脈におけるディスクという用語は、ハード・ディスク・ドライブ（ＨＤＤ）やダイレクト・アクセス・ストレージ・デバイス（ＤＡＳＤ）と同じ意味である。

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

複数のストレージシステムを相互接続し、多数のクライアントにサービスを提供するように構成されたストレージシステム環境を形成する場合もある。各ストレージシステムは１以上のボリュームを提供するように構成され、各ボリュームは１以上のデータコンテナを格納する。しかしながら、しばしば、クライアントによって発行される多数のデータアクセス要求は、当該環境の特定のストレージシステムが提供する少数のデータコンテナに対して発行される。このような問題に対する解決策は、特定のストレージシステムによって提供されるボリュームを、その環境のすべてのストレージシステムにわたって分散させることである。そして、その結果、そのようなデータアクセス要求は、そのような要求に応じるために必要な処理リソースとともに、すべてのストレージシステムにわたって分散され、それによって、各ストレージシステムにおける個々の処理負荷が軽減される。ただし、ファイルのような単一のデータコンテナだけが、ストレージシステム環境のクライアントによって非常に頻繁にアクセスされる場合、顕著な欠点が浮上する。その結果、そのデータコンテナに対する要求に応じようとするストレージシステムは、自分が有する処理リソースを超過し、過負荷になり、速度と性能が両方とも低下する場合がある。

[発明の概要]
本発明の実施形態は、ストレージシステム・アーキテクチャ内でのデータ・アロケーションのための方法、及びシステムを提供する。具体的には、本発明は、１つのクラスタとして相互接続された複数のノードにわたって分散された１以上のボリュームを含むストレージシステム・アーキテクチャを提供することにより、従来技術の欠点を克服する。ボリュームは、ストライピングされたボリュームセット（ＳＶＳ）として編成され、クライアントが発行したマルチプロトコル・データアクセス要求に応答して、クラスタが提供するファイルや論理ユニットのようなデータコンテナの中身を記憶するように構成される。クラスタの各ノードは、（１）ＳＶＳのボリュームを提供するように構成されたストレージサーバ、及び（２）データアクセス要求をクラスタのいずれかのストレージサーバへリダイレクトするように構成されたマルチプロトコル・エンジンを含む。特に、各データコンテナの中身は、ＳＶＳの複数のボリュームにわたって分散され、それによって、クラスタによって提供されるストレージサービスの性能が改善される。なお、本発明は、種々の態様で実施することができ、例えば、プロセス、装置、システム、デバイス、あるいは、コンピュータ読み取り可能媒体上の手段として実施することができる。本発明の幾つかの実施形態について以下で説明する。

データ・アロケーションの方法の一実施形態として、該方法は、複数のストレージシステムにわたってデータを割り当てるためのストレージシステム・アーキテクチャを識別するステップを含む。この方法は、データの塊（データチャンク）の分布を表わすアロケーション構造を判定するステップをさらに含む。この方法は、ストレージシステム・アーキテクチャを変更するときに、アロケーション構造を更新するステップをさらに含む。

ストレージシステム・アーキテクチャ内におけるデータ・アロケーションのためのシステムのさらに別の例示的実施形態として、該システムは、データチャンクを分散させるための複数のボリュームを識別するアロケーション構造を含む。複数のボリュームはそれぞれ、ストレージシステム・アーキテクチャの少なくとも１つのストレージシステムによって編成される。さらに、システムの実施形態は複数の再ストライピングプロセスを含み、該複数の再ストライピングプロセスのそれぞれが、ストレージシステム・アーキテクチャの変更に応答して、アロケーション構造の中身を再構成する。

ストレージシステム・アーキテクチャ内におけるデータ・アロケーションのための命令を含むコンピュータ読み取り可能媒体の一実施形態として、該実施形態は、ストレージシステム・アーキテクチャの複数のストレージシステムにわたってデータを割り当てるための命令を含む。この実施形態は、データチャンクの分布を表わすアロケーション構造を判定するための命令をさらに含む。この実施形態は、ストレージシステム・アーキテクチャを変更するときに、アロケーション構造を更新するための命令をさらに含む。

データ・アロケーションのためのコンピューティング環境の一実施形態として、該実施形態は、データチャンクを分散させるための複数のボリュームを識別する手段を含む。前記複数のボリュームはそれぞれ、コンピューティング環境の少なくとも１つのシステムによって編成される。この実施形態は、コンピューティング環境の変更に応答して、アロケーション構造の中身を再構成する手段をさらに含む。

本発明の他の態様は、添付の図面と併せて下記の説明を読むことにより明らかになるであろう。図面は、本発明の原理を例として示すものである。

[例示的実施形態の詳細な説明]
下記の実施形態は、ストレージシステム・アーキテクチャ内におけるデータ・アロケーションのための方法、およびシステムを表わす。具体的には、本発明は、クラスタ化コンピューティング環境として相互接続された複数のノードにわたって分散された１以上のボリュームを含むストレージシステム・アーキテクチャを提供することによって、従来技術の欠点を克服する。ボリュームは、ストライピングされたボリュームセット（ＳＶＳ）として編成され、クライアントが発行したマルチプロトコルデータアクセス要求に応答して、クラスタによって提供されるファイルや論理ユニットのようなデータコンテナの中身を記憶するように構成される。クラスタの各ノードは、（１）ＳＶＳのボリュームを提供するように構成されたストレージサーバ、及び（２）前記データアクセス要求をクラスタのいずれかのストレージサーバにリダイレクトするように構成されたマルチプロトコル・エンジンを含む。特に、各データコンテナの中身は、ＳＶＳの複数のボリュームにわたって分散され、それにより、クラスタによって提供されるストレージサービスの効率が向上する。ただし、当業者には明らかなように、本発明のそれらの実施形態は、それらの特定の詳細の一部、または全部がなくても、実施することができる。例によっては、本明細書に記載する本発明の実施形態を不明瞭にしないために、既知のプロセスオペレーションについては、詳しく記載されない場合もある。

図１のコンピューティング環境は、本発明の一実施形態による、クラスタ化コンピューティング環境として相互接続された複数のノード１００を示す図である。ノード１００は、ディスクアレイ１４０のような記憶装置上での情報の編成に関するストレージサービスを提供するように構成される。ノード１００は種々の機能的コンポーネントを含み、それらが協働して、クラスタの分散ストレージシステム・アーキテクチャを提供する。さらに、各ノード１００は、ネットワーク要素（Ｎブレード１６０）、及びディスク要素（Ｄブレード１７０）として編成される。Ｎブレード１６０は、接続システム１２０を介してノード１００をクライアント１１０に接続する機能を有する一方、各Ｄブレード１７０は、ディスクアレイ１４０のディスク１５０のような１以上の記憶装置に接続される。ノード１００は、クラスタ切り替え装置１３０によって相互接続され、クラスタ切り替え装置は一実施形態において、ギガビット・イーサネット(R)・スイッチとして実施される場合がある。分散ファイルシステムアーキテクチャの一例は、２００２年８月２２日に発行されたM. Kazar他による「METHOD AND SYSTEM FOR RESPONDING TO FILE SYSTEM REQUESTS」と題する米国特許出願公開第ＵＳ２００２／０１１６５９３号に概ね記載されている。なお、図１に示すクラスタには、同数のＮブレード、及びＤブレードが描かれているが、本発明の種々の実施形態によれば、Ｎブレードの数とＤブレードの数は異なる場合もある。例えば、ＮブレードとＤブレードの間の一対一の対応を反映しないクラスタ構成では、相互接続された複数のＮブレード、及び／又はＤブレードが存在する場合がある。したがって、１つのＮブレードと１つのＤブレードを含むノード１００の説明は、単なる例として捉えなければならない。

クライアント１１０は、情報配送のクライアント／サーバモデルにしたがってノード１００と通信するように構成された汎用コンピュータであってもよい。つまり、各クライアント１１０がノード１００のサービスを要求すると、ノード１００は、接続システム１２０を介してパケットをやりとりすることによって、クライアント１１０により要求されたサービスの結果を返す場合がある。ファイルやディレクトリのような形態の情報をアクセスする場合、クライアント１１０は、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）上で実施されるコモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルやネットワーク・ファイルシステム（ＮＦＳ）プロトコルのようなファイルベースのアクセスプロトコルを有するパケットを発行する場合がある。一方、ブロック形態の情報をアクセスする場合、クライアントは、「ＳＣＳＩ ｏｖｅｒ ＴＣＰ（ｉＳＣＳＩ）」プロトコルや「ＳＣＳＩ ｏｖｅｒ ＦＣ（ＦＣＰ）」プロトコルのようなブロックベースのアクセスプロトコルを有するパケットを発行する場合がある。

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

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

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

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

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

ディスクアレイ１４０への情報の記憶は、１以上のストレージ「ボリューム」として実施されることが好ましく、ボリュームは一群の物理的記憶装置１５０を含み、それらが協働して、ボリューム上のボリュームブロック番号（ｖｂｎ）空間の全体的論理配置を規定する。各論理ボリュームは通常、必須ではないが、そのボリューム独自のファイルシステムに関連する。論理ボリューム／ファイルシステム中のディスクは通常、１以上のグループに編成され、各グループは、ＲＡＩＤ（Redundant Array of Independent Disk）として運用される場合がある。ＲＡＩＤ−４実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ中の所与の数の物理的ディスクにわたってデータ「ストライプ」を冗長書き込みし、そのストライプ状データに関するパリティ情報を適切に記憶することによって、データ記憶の信頼性／完全性を向上させる。ＲＡＩＤ実施形態の一例はＲＡＩＤ−４レベル実施形態であるが、他のタイプ、及びレベルのＲＡＩＤ実施形態を本明細書に記載する本発明の原理にしたがって使用することも可能である。なお、当然ながら、本発明の例示的実施形態に関し、そのようなデータ「ストライプ」は、複数のストレージシステムにわたってデータの塊（データチャンク）として分散された割り当て済みデータとは異なる。例示的実施形態の「ストライプ状データ」については、図１３Ａを参照して後で詳しく説明する。

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

例示的実施形態として、ストレージ・オペレーティング・システム２３０は、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているＤａｔａ ＯＮＴＡＰオペレーティングシステムであることが好ましい。このファイルシステムは、Ｗｒｉｔｅ ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムを実施する。ただし、当然ながら、任意の適当なオペレーティングシステムを本明細書に記載する本発明の原理にしたがって使用するように拡張してもよい。したがって、「ＷＡＦＬ」という用語を使用した場合でも、この用語は、本発明の教示に適合する任意のストレージ・オペレーティング・システムを指すものとして広い意味で解釈しなければならない。

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

さらに、ストレージ・オペレーティング・システム２３０は、ノード１００のディスク１５０上に格納された情報をアクセスするためのデータパスを提供するストレージサーバ３５６を形成するように編成された一連のソフトウェア層を含む。その目的のために、ストレージサーバ３６５は、ボリューム１、ボリューム２、及びボリュームＮのような任意数のボリュームを編成するファイルシステムモジュール３６０、並びに、ＲＡＩＤシステムモジュール３８０、及びディスクドライバシステムモジュール３９０を含む。ファイルシステム３６０のボリューム・ストライピング・モジュール（ＶＳＭ：図示せず）は、図１０を参照して後で詳しく説明されるストライピングされたボリュームセット（ＳＶＳ）を実施する。ＶＳＭは、ファイルシステム３６０と協働し、ストレージサーバ３６５が、ＳＶＳのボリュームを提供できるようにする。特に、ＶＳＭは、ＳＶＳボリューム上のデータコンテナの中身の位置を計算し、それによって、クラスタにより提供されるそのような中身の整合性を確保する。ＲＡＩＤシステム３８０は、Ｉ／Ｏオペレーションによるボリューム／ディスクに対する情報の記憶、及び取り出しを管理し、ディスクドライバシステム３９０は、例えばＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施する。

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

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

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

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

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

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

さらに、当業者には分かるように、本明細書に記載する発明は、ストレージシステムとして実施され、またはストレージシステムを含むスタンドアロンのコンピュータやその一部を含めて、任意のタイプの特殊目的（例えば、ファイルサーバ、ストレージサービスを提供する装置など）、または汎用コンピュータに適用することができる。

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

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

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

例示した実施形態では、詳しくは、Ｎブレード１６０とＤブレード１７０は、ストレージ・オペレーティング・システム２３０の個別にスケジューリングされるプロセスとして実施される。ただし、代替実施形態では、それらのブレードは、単一のオペレーティングシステムプロセス中のコード片として実施される場合もある。したがって、ＮブレードとＤブレードの間の通信は、例えば、それらのブレード間で受け渡しされるメッセージの使用により影響を受ける場合がある。ただし、異なるノードにあるＮブレードとＤブレードの間のリモート通信の場合、そのようなメッセージの受け渡しは、クラスタ切り替え装置１３０を介して行われる。ブレード（プロセス）間で情報を転送するためにストレージ・オペレーティング・システムによって提供される既知のメッセージ受け渡しメカニズムの１つは、プロセス間通信（ＩＰＣ）メカニズムである。ＩＰＣとともに使用されるプロトコルの例は、ＣＦアプリケーション・プログラミング・インタフェース（ＡＰＩ）を構成する一群の方法／機能を含む汎用のファイル、及び／又はブロックベースの「不可知論的」ＣＦプロトコルである。そのような不可知論的プロトコルの例には、例えば、ネットワーク・アプライアンス・インコーポレイテッドから市販されているＳｐｉｎＦＳプロトコルやＳｐｉｎＮＰプロトコルがある。ＳｐｉｎＦＳプロトコルについては、上で参照した米国特許出願公開公報第ＵＳ２００２／０１１６５９３号に記載されている。

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

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

図４Ｂは、本発明の一実施形態による、データコンテナハンドル４００のフォーマットの詳細を示す図である。具体的には、例えばファイルのような、ファイルシステム中のデータコンテナは、データコンテナハンドルを使用してアクセスされる。データコンテナハンドル４００は、ＳＶＳ ＩＤフィールド４２０、ｉｎｏｄｅ番号フィルド４３０、一意の識別子フィールド４４０、ストライプ化フラグフィールド４５０、及びストライピング・エポック番号フィールド４６０を含む。ＳＶＳ ＩＤフィールド４２０は、ＳＶＳの（クラスタ内の）グローバル識別子であり、その中に、データコンテナがある。ｉｎｏｄｅ番号フィールド４３０は、データコンテナに関連する（ｉｎｏｄｅファイル中の）ｉｎｏｄｅのｉｎｏｄｅ番号を有する。一意の識別子フィールド４４０は、データコンテナハンドル４００を一意に識別する単調増加番号を有する。一意の識別子は、ｉｎｏｄｅ番号が削除され、再使用され、新たなデータコンテナに再割り当てされている場合に、特に有用である。一意の識別子は、特定のデータコンテナ中のその再使用されたｉｎｏｄｅ番号を、それらのフィールドで以前使用された可能性があるものから区別する。ストライプ化フラグフィールド４５０は、データコンテナ４００がストライピングされているか否かを識別するブール値である。また、ＳＶＳが異なるデータコンテナ４００に異なるデータストライピング技術を使用する実施形態の場合、ストライピング・エポック番号フィールド４６０は、このデータコンテナとともに使用される適当なストライピング技術を示す。クラスタ化コンピューティング環境のノード１００間で有利にロードバランスをとることが可能なストライピング技術の一例は、ラウンドロビン・ロードバランシング技術である。なお、当然ながら、ラウンドロビンは、純粋な例であり、クラスタ内のロードバランスをとることが可能なストライピング技術であれば、他のストライピング技術を使用することも可能である。

Ｄブレード１７０のファイルシステム３６０によって編成されるボリュームは、集合体としてさらに編成される。図５は、本発明の一実施形態による、集合体５００の例を示す図である。ＬＵＮ（ブロック）５０２、ディレクトリ５０４、ｑｔｒｅｅ５０６、及びファイル５０８は、デュアルｖｂｎフレキシブルボリュームのようなボリューム５１０の中に格納され、さらに集合体５００に格納される場合がある。集合体５００は、例えば、ＲＡＩＤシステム３８０の最上部に層として形成され、ＲＡＩＤシステム３８０は、少なくとも１つのＲＡＩＤプレックス５５０によって表わされ（ストレージ構成がミラーリングされているか否かに応じて）、各プレックス５５０は、少なくとも１つのＲＡＩＤグループ５６０を含む。各ＲＡＩＤグループは、複数のディスク１５０を含み、例えば、１以上のデータ（Ｄ）ディスクと、少なくとも１つのパリティ（Ｐ）ディスクとを含む場合がある。

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

コンテナファイルは、フレキシブルボリュームによって使用されるすべてのブロックを含む、集合中のファイルである。コンテナファイルは、フレキシブルボリュームを支援する（集合体の）内部機能であり、例えば、１つのフレキシブルボリュームあたり、１つのコンテナファイルが存在する。ファイルアプローチにおける純粋な論理ボリュームと同様に、コンテナファイルもまた、集合体中の隠しファイル（ユーザがアクセスできない）であり、そのフレキシブルボリュームによって使用されているあらゆるブロックを保持する。集合体は例えば、ＷＡＦＬ／ｆｓｉｄ／ファイルシステムファイル、ストレージラベルファイルといった、フレキシブルボリュームのサブディレクトリを有する隠しメタデータルートディレクトリを含む。

具体的には、物理ファイルシステム（ＷＡＦＬ）ディレクトリは、集合体中の各フレキシブルボリュームについてサブディレクトリを有し、サブディレクトリの名前は、フレキシブルボリュームのファイルシステム識別子（ｆｓｉｄ）になっている。各ｆｓｉｄサブディレクトリ（フレキシブルボリューム）は、少なくとも２つのファイル、すなわち、ファイルシステムファイル、及びストレージラベルファイルを含む。ストレージラベルファイルは、例えば、従来のＲＡＩＤラベルに格納されるものと同様のメタデータを有する。言い換えれば、ストレージラベルファイルは、ＲＡＩＤラベルに似たものであり、したがって、例えば、フレキシブルボリュームの名前、フレキシブルボリュームの世界的に一意な識別子（ｕｕｉｄ）、及びｆｓｉｄ、並びに、フレキシブルボリュームがオンラインであるか、作成中であるか、破壊中であるかなど、フレキシブルボリュームに関する情報を有する。

一実施形態として、データコンテナは、ディスク１５０への格納に適したｉｎｏｄｅデータ構造としてｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム上に表現される。ｉｎｏｄｅ（図示せず）は、メタデータ部（図示せず）、及びデータ部（図示せず）を有する。各ｉｎｏｄｅのメタデータ部に格納される情報は、データコンテナ（例えば、ファイル）を表わし、したがって、ファイルのタイプ（例えば、通常、ディレクトリ、ｖｄｉｓｋなど）、ファイルのサイズ、タイムスタンプ（例えば、アクセス時刻、及び／又は変更時刻）、及び、ファイルの所有者、すなわち、ユーザ識別子（ＵＩＤ）、及びグループＩＤ（ＧＩＤ）を含む。また、メタデータ部は、生成番号、及びメタデータ無効フラグフィールドをさらに有する。後で詳しく説明するように、メタデータ無効フラグフィールドは、そのｉｎｏｄｅ中のメタデータが使用可能であるか否か、すなわち、そのメタデータをＭＤＶ（図１０参照）から再取得しなければならないか否かを示すために使用される。各ｉｎｏｄｅのデータ部の中身は、タイプフィールドに規定されたファイル（ｉｎｏｄｅ）のタイプに応じて、異なる解釈をされる場合がある。例えば、ディレクトリｉｎｏｄｅのデータ部は、ファイルシステムによってコントロールされるメタデータを有する一方、通常ｉｎｏｄｅのデータ部は、ファイルシステムデータを有する。後者の場合、データ部は、そのファイルに関連するデータの表現を含む。

具体的には、通常のディスク上のｉｎｏｄｅのデータ部は、ファイルシステムデータ、またはポインタを有し、後者は、ファイルシステムデータの格納に使用される４ｋＢデータブロックを参照する。ディスク上のデータをアクセスするときのファイルシステムとＲＡＩＤシステム３８０の間の効率を高めるために、各ポインタは、論理ｖｂｎであることが好ましい。ｉｎｏｄｅのサイズが限られている場合（例えば、１２８バイト）、６４バイト以下のサイズのファイルシステムデータは、その全体が、そのｉｎｏｄｅのデータ部の中に表現される。一方、データコンテナの長さが６４バイトよりも大きく、且つ、６４ｋＢ以下である場合、そのｉｎｏｄｅのデータ部（例えば、第１レベルｉｎｏｄｅ）は、最大で１６個のポインタを有し、各ポインタが、ディスク上の４ｋＢデータブロックを参照する。

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

ディスク上のｉｎｏｄｅ（または、ブロック）が、ディスク１５０からメモリ２２０へロードされるとき、それに対応するコア内構造が、そのオンディスク構造に埋め込まれる。このコア内構造は、そのオンディスク構造と、メモリ上（かつディスク上にはない）のデータを管理するために必要とされる補助的情報とを格納する。この捕縄的情報には、例えば、「ダーティ」ビットがある。例えば書き込みオペレーションによる命令にしたがって、ｉｎｏｄｅ（または、ブロック）内のデータが更新／変更された後、その変更されたデータは、ダーティビットを使用して「汚れたもの」としてマーキングされ、そのｉｎｏｄｅ（ブロック）を直ぐにディスクへ「フラッシュ」（格納）することができるようになる。ｉｎｏｄｅ、及びｉｎｏｄｅファイルを含む、このＷＡＦＬファイルシステムのコア内フォーマット構造、及びオンディスク・フォーマット構造については、１９９８年１０月６日に発行されたDavit 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」と題する米国特許出願第１０／８３６，８１７号に記載されている。基礎となる物理ボリュームは、ノード１００のＲＡＩＤグループのような１以上のグループのディスクを含む集合体５００である。集合体５００は、その集合体独自の物理ブロック番号（ｐｖｂｎ）空間を有し、そのｐｖｂｎ空間の中で、ブロックアロケーション構造のようなメタデータを管理する。各フレキシブルボリュームは、そのボリューム独自の仮想ボリュームブロック番号（ｖｖｂｎ）空間を有し、そのｖｖｂｎ空間の中で、ブロックアロケーション構造のようなメタデータを管理する。各フレキシブルボリュームは、コンテナファイルに関連するファイルシステムであり、コンテナファイルは、フレキシブルボリュームによって使用されるすべてのブロックを有する、集合体中のファイルである。また、各フレキシブルボリュームは、データブロック、及び、他の間接ブロック、またはデータブロックを指し示すブロックポインタを有する間接ブロックを含む。

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

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

ｐｖｂｎは、集合体のディスク上の位置を参照する一方、ｖｖｂｎは、フレキシブルボリュームのファイル内の位置を参照する。間接ブロック６２４におけるブロックポインタ６２５のようなｐｖｂｎの使用は、読み出しパス上の効率を提供する一方、ｖｖｂｎブロックポインタの使用は、要求されたメタデータへ効率的なアクセスを提供する。すなわち、ファイルのあるブロックを開放するとき、そのファイル中の親間接ブロックは、すぐに利用可能なｖｖｂｎブロックポインタを有し、それによって、ｐｖｂｎからｖｖｂｎへの変換を実施するための所有者マップへのアクセスにともなう遅延を回避することができ、それでも、読み出しパス上で、ｐｖｂｎを利用することができる。

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

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

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

集合体の隠しメタデータルートディレクトリ７３０の中に格納されるストレージラベルファイル７９０は、従来のＲＡＩＤラベルと同様の働きをする小さなファイルである。ＲＡＩＤラベルは、ボリューム名のような、ストレージシステムに関する物理的情報を有し、その情報は、ストレージラベルファイル７９０の中にロードされる。例えば、ストレージラベルファイル７９０は、関連フレキシブルボリューム７５０の名前７９２、フレキシブルボリュームのオンライン／オフラインステータス７９４、並びに、関連フレキシブルボリュームの他の識別情報（ＩＤ）、及びステータス情報７９６（そのボリュームが作成中であるか、破壊中であるか）を含む。

一実施形態として、各ノード１００のＮブレード１６０は、データコンテナハンドル４００のＳＶＳ ＩＤ４２０をクラスタ化コンピューティング環境内にあるそのデータコンテナを「所有」しているＤブレード１７０にマッピングする設定テーブル２６０にアクセスする。ボリューム位置データベース（ＶＬＤＢ）は、ノード１００のボリューム、及び集合体の位置を追跡記録する機能を有する。具体的には、ＶＬＤＢは、設定テーブル２６０中のエントリの中身を提供する複数のエントリを有し、とりわけ、それらのＶＬＤＢエントリは、クラスタ化・コンピューティング環境中のフレキシブルボリューム（以後、一般に「ボリューム５１０」）、及び集合体５００の位置を追跡記録する。図８Ａは、本発明の一実施形態による、例示的なＶＬＤＢボリュームエントリ８１０を示す図である。また、図８Ｂは、本発明の一実施形態による、例示的なＶＬＤＢ集合体エントリ８５０を示す図である。したがって、ＶＬＤＢエントリの例には、ＶＬＤＢボリュームエントリ８１０とＶＬＤＢ集合体エントリ８５０がある。

図８ＡのＶＬＤＢエントリ８１０は、ボリュームＩＤフィールド８０５、集合体ＩＤフィールド８１５を有し、代替実施形態では、さらに別のフィールド８２０を有する場合がある。ボリュームＩＤフィールド８０５は、ボリューム探索プロセスにおいて、ボリューム５１０を識別するＩＤを格納する。集合体ＩＤフィールド８１５は、ボリュームＩＤフィールド８０５によって識別されるボリュームを含む集合体５００を識別する。同様に、図８Ｂは、ＶＬＤＢ集合体エントリ８５０の例を示している。ＶＬＤＢ集合体エントリ８５０は、集合体ＩＤフィールド８５５、及びＤブレードＩＤフィールド８６０を有し、代替実施形態では、さらに別のフィールド８６５を有する場合がある。集合体ＩＤフィールド８５５は、クラスタ化コンピューティング環境中の特定の集合体５００のＩＤを有する。ＤブレードＩＤフィールド８６０は、集合体ＩＤフィールド８５５によって識別されるその特定の集合体を有するＤブレード１７０のＩＤを有する。

ＶＬＤＢは、例えばＳｕｎ ＲＰＣインタフェースのようなＲＰＣインタフェースを実施し、それによって、Ｎブレード１６はがＶＬＤＢに問い合わせすることができる。Ｎブレード１６０は、自分の設定テーブルに格納されていないデータコンテナハンドル４００のコンテンツに遭遇すると、図９を参照して説明したように、ＲＰＣをＶＬＤＢプロセスに対して送信する。これに応答して、ＶＬＤＢプロセスは、そのデータコンテナを所有するＤブレードのＩＤを含む適当なマッピング情報をＮブレード１６０に返す。Ｎブレード１６０は、その情報を自分の設定テーブル２６０上にキャッシュし、ＤブレードＩＤ８６０を使用して、その到来した要求を適当なデータコンテナに転送する。Ｎブレード１６０、及びＤブレード１７０の機能、及びそれらの間の通信はすべて、後で詳しく説明するように、一群の管理プロセス、及びＲＤＢライブラリ・ユーザモード・アプリケーションによってクラスタ幅ごとに調整される。

本発明は、クラスタ化コンピューティング環境の複数のノード１００にわたって分散された１以上のボリューム５１０を含むストレージアーキテクチャに関する。ボリューム５１０は、ＳＶＳとして編成され、クライアント１１０によって発行されたマルチプロトコル・データアクセス要求に応答してクラスタにより提供されるファイルやＬＵＮのようなデータコンテナの中身を記憶するように構成される。特に、各データコンテナの中身は、ＳＶＳの複数のボリュームにわたって分散され、それによって、クラスタ化環境により提供されるストレージサービスの効率が向上する。本発明の説明、及び理解を容易にするために、以後、データコンテナは一般に、「ファイル」と呼ばれる。

本発明の一実施形態によれば、ＳＶＳは、１つのメタデータボリューム（ＭＤＶ）、及び１以上のデータボリューム（ＤＶ）を含む。ＭＤＶは、ＳＶＳに格納された全ファイルに関連するアクセス・コントロール・リスト（ＡＣＬ）やディレクトリのようなメタデータの正規のコピーを格納するように構成され、各ＤＶは、少なくとも、それらのファイルのデータコンテンツを格納するように構成される。ＳＶＳに格納される各ファイルについて、１つのボリュームはＣＡＶとして指定され、その目的のために、そのファイルに関連する特定の高速に変化する属性メタデータを格納（「キャッシュ」）するように構成され、それによって、通常ならばＭＤＶに対して発行されるアクセス要求の負荷を軽減する。本明細書に記載する例示的実施形態では、ファイルのＣＡＶの決定は、そのファイルの中身（データ）の最初のストライプをそのファイルのＣＡＶとして指定する、という単純なルールに基づいて行われる。この単純なルールは、便利なだけでなく、小さなファイルに対する最適化も提供する。すなわち、ファイルが指定されたストライプ幅の中に納まるくらい十分に小さい場合、ＣＡＶは、ＳＶＳの他のボリュームと通信することなく幾つかのオペレーションを実施することができる場合がある。理想的には、ファイルの最初のストライプのデータは、ＳＶＳの複数のＤＶにわたって分散され、それによって、ＳＶＳの複数のボリュームにわたるＣＡＶ指定の均一な分散が可能になる。代替実施形態では、ファイルのデータは、ＭＤＶ、及びＤＶにわたってストライピングされる場合がある。

図９は、本発明の一実施形態による、複数のボリュームにわたってストライピングされた割り当て済みデータを管理するための一群の管理プロセスを示している。これらの管理プロセスは、ユーザモード・アプリケーション９００としてストレージ・オペレーティング・システム２３０上で実行され、クラスタ化コンピューティング環境のノード１００の設定情報（すなわち、管理データ）の管理を提供する。その目的のために、管理プロセスは、管理フレームワークプロセス９１０、及びボリューム位置データベース（ＶＬＤＢ）プロセス９６０を含み、これらのプロセスがそれぞれ、ライブラリとしてリンクされたデータ複製サービス（ＲＤＢ９５０）を使用する。管理フレームワーク９１０は、ユーザに対し、コマンドラインインタフェース（ＣＬＩ）、及び／又はウェブベースのグラフィカル・ユーザ・インタフェース（ＧＵＩ）による管理者９７０インタフェースを提供する。管理フレームワークは、例えば従来のコモン・インタフェース・モデル（ＣＩＭ）オブジェクトマネージャに基づくものであり、クラスタの管理のために、ユーザ／システム管理者がノード１００と通信するためのエンティティを提供する。ＶＬＤＢプロセス９６０は、クラスタ内の種々のストレージコンポーネント（例えば、ＳＶＳ、フレキシブルボリューム、集合体など）の位置を追跡記録し、それによって、クラスタ全体を通じた要求のルーティングを可能にするデータベースプロセスである。

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

本明細書に記載するストレージシステム・アーキテクチャによれば、複数のＳＶＳオペレーションによって、ＳＶＳの複数のボリュームにわたって分散されたファイル（及び、他のデータコンテナ）コンテンツの効率的かつ正確な提供が可能になる。そのようなＳＶＳオペレーションには、とりわけ、ファイル作成、ファイル消去、ファイル属性の読み出し、ファイル属性の書き込み／変更、ファイル読み出し、及びファイル書き込みオペレーションがある。図１０は、本発明の一実施形態によるストライピングされたボリュームセット（ＳＶＳ）１０００を示す図である。ＳＶＳ１０００は例えば、３つのボリューム、すなわち、ＭＤＶ１００５、及び２つのＤＶ１０１０、１０１５を含む。なお、代替実施形態では、本発明にしたがって、更に別のボリューム、及び／又は異なる数のボリュームが使用される場合もある。例えば、ＭＤＶ１００５は、ルートディレクトリ（ＲＤ）ｉｎｏｄｅ１０２０、ディレクトリ（ＤＩＲ）ｉｎｏｄｅ１０３０、ファイル（Ｆ）ｉｎｏｄｅ１０２５、１０３５、１０４５、及びＡＣＬ ｉｎｏｄｅ１０４０のような複数のｉｎｏｄｅを格納する。これらのｉｎｏｄｅはそれぞれ、例えば、そのｉｎｏｄｅに関連するメタデータ（Ｍ）を有する。例示的実施形態において、ＭＤＶ１００５上の各ｉｎｏｄｅは、データ（Ｄ）を持たない。ただし、代替実施形態では、ＭＤＶは、ユーザデータを有する場合がある。

これに対し、各ＤＶ１０１０、１０１５は、ファイル（Ｆ）ｉｎｏｄｅ１０２５、１０３５、１０４５、及びＡＣＬ ｉｎｏｄｅ１０４０だけを格納する。本発明のアーキテクチャによれば、ＤＶは、ディレクトリや、シンボリックリンクのような他のデバイスｉｎｏｄｅ／構造を格納しない。ただし、各ＤＶは、Ｆ ｉｎｏｄｅを格納し、ＡＣＬ ｉｎｏｄｅのキャッシュされたコピーを格納する場合があり、これらは、ＭＤＶ１００５内の対応するｉｎｏｄｅと同じ場所に格納される。特定のＤＶは、ｉｎｏｄｅに関連するデータコンテナに対するＩ／Ｏ要求が、その特定のＤＶを提供するＤブレードによって受信されるまで、そのｉｎｏｄｅのコピーを格納しない場合がある。また、それらのＦ ｉｎｏｄｅによって表わされるファイルの中身は、後で詳しく説明するように、ＳＶＳストライピング・ルールにしたがって定期的に構文解析される。さらに、ＳＶＳ１０００上に格納された各ファイルについて、１つのボリュームはＣＡＶとして指定され、ＤＶ１０１５はｉｎｏｄｅ１０２５によって表わされるファイルのＣＡＶとして指定され、ＤＶ１０１０は、ｉｎｏｄｅ１０３５、１０４５によって識別されるファイルのＣＡＶとして指定される。したがって、それらのＣＡＶは、例えばファイルサイズのような、それらのファイルに関連する特定の高速に変化する属性メタデータ（Ｍ）、ならびに、アクセスタイムスタンプ、及び／又は変更タイムスタンプをキャッシュする。

本発明の他の実施形態によれば、ＳＶＳは、ストライプ・アルゴリズム、ストライプ幅、及び、ＳＶＳ中のボリュームの順序付きリストを規定する一組のストライピング・ルールに関連する。各ＳＶＳのストライピング・ルールは、例えば、ＶＬＤＢプロセス９６０の１つのエントリとして格納され、ＳＶＳ ＩＤによってアクセスされる。図１１は、本発明の一実施形態によるＶＬＤＢ ＳＶＳエントリ１１００を示す図である。ＶＬＤＢエントリ１１００は、ＳＶＳ ＩＤフィールド１１０５、及び、一組以上のストライピング・ルール１１３０を含む。代替実施形態では、更に別のフィールド１１３５を有する場合もある。ＳＶＳ ＩＤフィールド１１０５は、ＳＶＳのＩＤを有し、動作時には、それが、データコンテナハンドル４００の中に指定される。

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

ストライプ幅フィールド１１１０は、各ストライプのサイズ／幅を指定する。ボリュームの順序付きリストフィールド１１２０は、ＳＶＳを含むボリュームのＩＤを有する。一実施形態において、ボリュームの順序付きリストは、フレキシブルボリュームＩＤ、及び該フレキシブルボリュームを格納している集合体ＩＤを含む複数のタプルを含む。さらに、ボリュームの順序付きリストは、種々のボリュームの機能や実施形態、及びＳＶＳのストライピング・ルールを指定する場合がある。例えば、順序付きリスト上の最初のボリュームは、ＳＶＳのＭＤＶを表わす一方、リスト上のボリュームの順序は、例えばラウンドロビンのような特定のストライピング・アルゴリズムを実施する態様を表わす。

ＣＦメッセージ３７０を送信する宛先となるＤブレード１７０の位置を判定するために、Ｎブレード１６０は、まず、ＳＶＳエントリ１１００を読み出し、ＳＶＳに関連するストライピング・ルール（及び、ボリュームのリスト１１２０）を取得する。次に、Ｎブレード１６０は、Ｌｏｃａｔｅ（）関数（図示せず）のような探索プロセスを実行し、オペレーションの対象となる適当なボリュームを識別する。その後、Ｎブレード１６０は、適当なＶＬＤＢボリュームエントリ８１０を読み出し、そのボリュームを格納している集合体を識別するとともに、適当なＶＬＤＢ集合体エントリを読み出し、適当なＤブレード１７０を最終的に識別する。次に、Ｎブレード３１０のプロトコルサーバは、ＣＦメッセージ３７０をＤブレード１７０に送信する。

図１２は、本発明の一実施形態による、ＳＶＳのボリュームに格納されるファイル・コンテンツの周期的散在状況を示す図である。散在状況は、ＳＶＳのボリュームのストライプが、ファイルコンテンツ、またはデータを有しないことを意味する。ボリュームの例としては、ＳＶＳ１２００のボリュームＡ１２０５、Ｂ１２１０、及びＣ１２１５がある。上記のように、ファイル・コンテンツは、ＳＶＳストライピングルールにしたがって、定期的に分散され、ＳＶＳストライピングルールは、ストライピング・アルゴリズム（ストライプアルゴリズムＩＤフィールド１１１５によって示される）、及び、各ストライプのサイズ／幅（ストライプ幅フィールド１１１０によって示される）を指定する。なお、例示的実施形態では、ストライプ幅は、各ストライプが、ファイルの間接ブロック（例えば、レベル１ブロック６０４）によって参照される実際のデータ（例えば、データブロック６０６に格納されているようなもの）を確実に収容できるように選択される。

例示的なラウンドロビン・ストライピング・アルゴリズムによれば、ボリュームＡ１２０５は、１ストライプのファイル・コンテンツ、又はデータ（Ｄ）１２２０を有し、それに続いて、２ストライプの散在（Ｓ）１２２２、１２２４、さらに別のストライプのデータ（Ｄ）１２２６、及び２ストライプの散在（Ｓ）１２２８、１２３０を有する。一方、ボリュームＢ１２１０は、１ストライプの散在（Ｓ）１２３２を有し、それに続いて、１ストライプのデータ（Ｄ）１２３４、２ストライプの散在（Ｓ）１２３６、１２３８、さらに別のストライプのデータ（Ｄ）１２４０、及び１ストライプの散在（Ｓ）１２４２を有する。ボリュームＣ１２１５は、ラウンドロビン・ストライピング・パターンを継続し、その目的のために、２ストライプの散在（Ｓ）１２４４、１２４６を有し、それに続いて、１ストライプのデータ（Ｄ）１２４８、２ストライプの散在（Ｓ）１２５０、１２５２、及びさらに別のストライプのデータ（Ｄ）１２５４を有する。

図１３Ａは、本発明の一実施形態による、ストレージシステム・アーキテクチャの複数のボリュームにわたって分散されるデータのアロケーションを示す図である。当然ながら、ストライピングされたデータを割り当てるための本発明の実施形態によれば、クラスタ化コンピューティング環境内で、可変長の任意数のボリュームを実施することができる。具体的には、各ノード１００に１つのボリュームが割り当てられ、各ノード１００は、クラスタ化コンピューティング環境のストレージシステムであり、１つのノード１００に対して任意数のボリュームを割り当てることができる。例えば、複数のノード１００が、クラスタ切り替え装置１３０を介して互いに通信する場合がある。具体的には、ノード１００のＮ／Ｄブレードは、上で説明したようにして通信する。各Ｄブレード１７０は１つのボリュームを有し、各ボリュームは、ストライピングされたデータを格納することができる。例えば、図１３Ｂに示されているように、データボリューム０（ＤＶ０）は、第１の位置に１ストライプのデータを格納することができ、データボリューム１（ＤＶ１）は、第２の位置に１ストライプのデータを格納することができ、データボリューム２（ＤＶ２）は、第３の位置に１ストライプのデータを格納することができ、データボリューム３（ＤＶ３）は、第４の位置に１ストライプのデータを格納することができる。

また、図１３Ｂは、本発明の一実施形態による、ストライピングテーブル１３００の例を示す図である。ストライピングテーブル１３００は、複数のボリュームにわたってストライピングされたデータの塊（データチャンク）の分布を表わす。代替的に記載されるように、ボリューム間におけるデータチャンクの各位置は、ストライピングテーブル１３００によって識別される。したがって、ストライピングテーブル１３００は、ストライピングされたデータが、ＤＶ０上の第１の位置、ＤＶ１上の第２の位置、ＤＶ２上の第３の位置、及びＤＶ３上の第４の位置に配置されることを示している。例示的実施形態において、ストライピングされたデータは、ストライピングされたファイルシステムの複数のボリュームにわたってストライピングされたファイルを含む。したがって、図１３Ａは、ストライピングされたファイルシステムのジオメトリ、または編成を示している。

有利なことに、複数のストレージシステムにわたって分散された複数のボリュームにわたってファイルを分散させることにより、ボリューム使用効率を向上させることができ、ホットスポットを防止、または軽減することができる。さらに、本発明の例示的実施形態の再ストライピングプロセスを実施することにより、後で詳しく説明するように、再ストライピングプロセスは、Ｄブレード１７０間で移動されるデータの量を制限することができる。データを複数のボリューム全体にわたって均一に分散させることにより、ボリューム使用効率が向上する。具体的には、データアクセスオペレーション中、いずれか１つのボリュームは、他のボリュームに比べて頻繁にアクセスされてはならない。同じファイルに関する連続した２ストライプのデータの記憶を防止することにより、ホットスポットの発生が防止される。したがって、ファイルの特定の領域をアクセスするときに、１つのボリュームは、ボトルネックになってはならない。また、図１３Ａに示すストライピングされたファイルシステムのジオメトリが変更された場合、再ストライピングプロセスが実施される。例えば、ストライピングされたファイルシステムに１つのボリュームを追加したり、ストライピングされたファイルシステムから１つのボリュームを除去する場合、各再ストライピングプロセスは、アロケーション構造の中身を再構成し、それに対応して、ストライプピングされたデータをボリューム間で巡回させるように移動させる。ボリュームの追加又は除去によるクラスタ化コンピューティング環境の変化に応答して、少なくとも１つの再ストライピングプロセスが実施される。再ストライピングプロセスについては、図１４〜図１７を参照して後で詳しく説明する。

図１４は、本発明の一実施形態による、ストレージシステム・アーキテクチャの追加、及び除去を示す図である。ＤＶ０、ＤＶ１、及びＤＶ２のような３つのボリュームは、ストレージシステム・アーキテクチャの例示的実施形態において分散されたボリュームである。具体的には、１つのストレージシステムに１つのボリュームが割り当てられる。ただし、実施形態によっては、ストレージシステム・アーキテクチャの複数のストレージシステムのそれぞれに少なくとも１つのボリュームが割り当てられる場合もある。図１４に示すような、ラウンドロビン・ロードバランシング技術を使用して３つのボリュームにわたってストライピングされたデータチャンクは、ストライピングテーブル１３００によって識別される。例えば、ストライピングされたデータ１４１０のボリューム位置は、ストライピングテーブル１３００の中身によって識別され、それらのボリュームの散在位置１４２０は、ストライピングテーブル１３００によって識別されない。前述のように、ストライピングテーブルは、本発明の実施形態のアロケーション構造である。アロケーション構造は、線形構造として例示されているが、アロケーション構造は、いかなるタイプの構造によって実施してもよく、例えば、三次元構造によって実施したり、あるいは、特定のジオメトリにある複数のボリュームにわたって割り当てられたストライピング後のデータを実際に識別するものであれば、ｎ次元構造によって実施することもできる。

したがって、図１４のストライピングテーブル１４００は、３つのボリュームにわたってストライピングされたファイルのストライピング後のデータのシーケンスが、ＤＶ０、ＤＶ１、ＤＶ２、ＤＶ０、ＤＶ１、ＤＶ２、ＤＶ０、ＤＶ１、ＤＶ２、ＤＶ０、ＤＶ１、及びＤＶ２に配置されることを示している。次に、例えばＤＶ３（図示せず）のような１つのボリュームを追加し、続いて削除するときの、再ストライピングプロレスの例について詳しく説明する。具体的には、クラスタにボリュームを追加する場合、再ストライピングプロセスは、進化型アルゴリズムである。あるいは、クラスタからボリュームを除去する場合、再ストライピングプロセスは、退化型アルゴリズムである。したがって、ジオメトリが変化したときに、少なくとも１つの再ストライピングアルゴリズムを実施することによって、データを最適に分散させることができると同時に、ホットスポットの挙動を抑制することができる。さらに、再ストライピングプロセスによれば、ストライピングテーブルを変更するための時間の長さも最小限に抑えることができる。

図１４に示す進化型アルゴリズムの実行中に、ストライピングテーブル１３００の長さは増大し、ボリュームの総数に等しい数の位置が追加される。さらに、ストライピングテーブル１３００の中身は、ボリュームの総数によってグループ化される。各グループ内において、そのグループ内に識別子が現れる回数を識別するようなカウンタが判定される。したがって、ステップ１４３０において、ＤＶ０については、識別子が２回現れているため、カウント０は２になる。ＤＶ１については、識別子が１回現れているため、カウント１は１になり、ＤＶ２については、識別子が１回現れているため、カウント２は１になる。しかしながら、ステップ１４３２において、ＤＶ０については識別子が１回現れ、ＤＶ１については識別子が２回現れ、ＤＶ２については識別子が１回現れる。次に、各グループ内において、最大の値を有するカウンタが、新たに追加された第４のボリュームＤＶ３に対応する識別子に置き換えられる。したがって、ストライピングテーブル１４４０に示されているように、各グループ中の重複する参照は、新たな識別子「３」に置き換えられる。なお、当然ながら、進化型アルゴリズムは、クラスタにボリュームが追加されるたびに毎回実施され、それに対応して、ストライピングテーブル１４４０に変更が加えられる。

クラスタからボリュームを除去する場合、再ストライピングプロセスは、クラスタから除去される各ボリュームについても実施される。そのような再ストライピングプロセスは、退化型アルゴリズムである。ストライピングテーブルは更にもう一度グループ化され、そのボリューム除去の結果、各グループは、総数のボリュームになる。ただし、総数は３である。なぜなら、ストライピングテーブル１４４０は、４つのボリュームにわたってストライピングされたデータの位置を識別するからである。今除去された第４のボリュームに対する識別子を含む各グループでは、その識別子を置き換えなければならない。この置き換え識別子は、そのグループ中に現れる回数が最も少ないボリュームから選択される。例えば、グループ中のボリュームに対する参照の回数のカウントを保持することにより、最少数の参照を有するカウンタを置き換えることができる。具体的には、グループ１４５０は、ＤＶ０、及びＤＶ２の識別子を有するが、ＤＶ１の識別子は有しない。したがって、識別子「１」が、ストライピングテーブル１４６０の中身として挿入される。これに対応して、グループ１４５２は、ＤＶ０、及びＤＶ１の識別子を有するが、ＤＶ２の識別子は有しない。したがって、識別子「２」が、ストライピングテーブル１４６０に挿入される。

図１４に示した進化型アルゴリズム、及び退化型アルゴリズムを実施する本発明の他の例示的実施形態では、当然ながら、ストライピングテーブル１３００のサイズは、必ずしも増減させなくても足りる場合がある。特に、ストライピングテーブル１３００は、固定サイズに維持されることもある。そのようなストライピングテーブルサイズの例は、例えば４０９６エントリである。したがって、ストライピング後のボリュームセット間におけるデータの割り当てが変化するプロセスを実施する場合、ストライピングテーブルによっては、そのサイズが一定に維持されることもある。

図１５Ａは、本発明の一実施形態による、クラスタ化コンピューティング環境のようなストレージアーキテクチャ内におけるボリュームの追加、及び除去のためのオペレーションを示すフロー図である。オペレーション１５１０において、管理者、またはストレージ・オペレーティング・システムによって管理される何らかの他のプロセスは、ストライピングテーブルを生成することができる。具体的には、このストライピングテーブルは、クラスタ化コンピューティング環境の複数の分散ボリュームにわたるデータチャンクの分布を表わすアロケーション構造である。ストライピングテーブルを生成するとき、例示的実施形態は、１つのノードに１つのボリュームを割り当て、結合されたノードがクラスタを形成するようにする。具体的には、ノードのＤブレードは、ボリュームに格納されたデータへのアクセスを提供する。ただし、当然ながら、本発明の実施形態によっては、複数のボリュームが１つのノードに分散される場合もある。ボリュームは、ストライピングされたボリュームセット（ＳＶＳ）と編成され、ＳＶＳは、そのファイルをＳＶＳ全体にわたって「ストライピングされたデータ」としてストライピングする。ボリューム上の各ストライピングされたデータは、ストライピングテーブルによって識別される。したがって、ストライピングテーブルは、データチャンクがＳＶＳ上に格納される場所を表わす。

続いて、オペレーション１５２０において、ボリュームを追加するか、除去するかの判定がなされる。複数のボリュームを追加、及び／又は除去する場合、ＳＶＳへの変更により、再ストライピングプロセスが実施されることになる。再ストライピングプロセスは、ストライピングテーブルの中身を再配置し、それに対応して、ＳＶＳ内のデータチャンクを移動させる。ボリュームを追加する場合、再ストライピングプロセスは、進化型アルゴリズムであると言われ、ボリュームを除去する場合、退化型アルゴリズムであると言われる。各ボリューム変更について、適当な再ストライピングプロセスが一回実施される。したがって、４つのボリュームを追加する場合、進化型アルゴリズムの４つの実施形態が発生する。例えば、ボリュームを追加する場合、オペレーション１５３０は、追加されるボリュームのそれぞれについて進化型アルゴリズムを適用するオペレーションを表わす。あるいは、ボリュームを除去する場合、オペレーション１５５０は、除去されるボリュームのそれぞれについて退化型アルゴリズムを適用するオペレーションを表わす。ＳＶＳへの各変更について再ストライピングプロセスを適用した後、オペレーション１５３０、及びオペレーション１５５０は、いずれもオペレーション１５２０へ戻り、そこで、ボリュームの追加、または除去を判定する。

図１５Ｂは、本発明の一実施形態による、ボリューム追加の場合のオペレーションを示すフロー図である。オペレーション１５３２では、１ボリュームの追加により、ストライピングされたデータをＳＶＳに格納するために利用可能なボリュームの量を増加させる。ＳＶＳ上のストライピングされたデータの位置を識別するストライピングテーブルは、図１４を参照して説明したように、ボリュームの総数によってグループ化される。次に、オペレーション１５３４は、各グループ位置についてカウンタを維持する。例えば、あるグループが、４つの位置を有している場合、追加されたボリュームを除き、そのＳＶＳの各ボリュームについてカウンタが生成される。これらのカウンタは比較され、オペレーション１５３６は、各グループについて、比較により、ストライピングテーブル中に重複するボリューム参照があるか否かを識別する。したがって、オペレーション１５３８では、例示的実施形態の再ストライピングプロセスは、各グループについて、ストライピングテーブル上の少なくとも１つの重複したボリューム参照を、追加したボリューム参照に置き換え、置き換えられた重複ボリューム参照が、最大カウンタ値を有するようにする。最後に、オペレーション１５４０において、ストライピングテーブルの中身を再構成した後、プロセスは、変更後のストライピングテーブルにしたがって、複数のデータボリュームにわたってデータを割り当てる。

本発明の更に別の実施形態では、グループ中にボリューム参照の置換が１つしか存在しない場合がある。したがって、グループ内における複数のボリューム参照置換によれば、ストライピング後のボリュームセット間のデータ分布はわずかに改善される場合もあるが、再ストライピング特性を大幅に悪化させるという犠牲をともなう場合がある。そのような再ストライピング特性の悪化は、ストライピング後のボリュームセット間におけるデータのラウンドロビン分布を減少させる。

図１５Ｃは、本発明の一実施形態による、ボリューム除去の場合のオペレーションを示すフロー図である。オペレーション１５５２では、１ボリュームの除去により、ＳＶＳ中のストライピングされたデータを格納するために利用可能なボリュームの量を減少させる。上記の進化型アルゴリズムの場合と同様に、オペレーション１５５４において、プロセスは、各グループ位置についてカウンタを維持する。次に、オペレーション１５５６において、プロセスは、複数の最小カウンタ値が同一の値でない限り、ストライピングテーブルに追加するために、各グループについて、最小カウンタのボリューム参照を選択する。グループ中の複数の最小カウンタ値が同一の値であった場合、オペレーション１５５８の後、プロセスは、オペレーション１５６０において複数のカウンタ値の中から選択する。具体的には、プロセスは、ストライピングテーブル上において、自分の位置から最も近い位置にある既存のボリューム参照が、ストライピングテーブルの挿入箇所から最も遠い位置にあるようなボリューム参照を選択する。挿入箇所は、除去されるボリューム上のストライピング後のデータの位置が識別されたコンテンツ位置である。したがって、オペレーション１５６２では、ストライピングテーブル中の除去されたボリューム参照を、ストライピングテーブルの挿入箇所から最も遠い位置にあるボリューム参照で置き換えることによって、ストライピングテーブルの変更が行われ、ホットスポットが防止され、同時に、ボリューム使用効率が向上される。最後に、オペレーション１５６４において、ストライピングテーブルの中身を再構成した後、プロセスは、変更後のストライピングテーブルにしたがって、複数のデータボリュームにわたってデータを割り当てる。

一方、オペレーション１５５８において、複数のカウンタ値が同一の値でなかった場合、プロセスはオペレーション１５６２へ進む。オペレーション１５６２では、ストライピングテーブル中の除去されたボリューム参照を適当なボリューム参照に置き換えることによって、ストライピングテーブルの変更が行われる。そのような適当なボリューム参照は、ストライピングテーブルの挿入箇所から最も遠い位置にある、ボリュームの識別子であってもよい。

上記の再ストライピングプロセスは、本発明の例示的実施形態によって実施される。しかしながら、前述の再ストライピングプロセスの代わりに、あるいはそれに加えて、他のストライピングプロセスを実施してもよい。例えば、再ストライピングプロセスによっては、ストライピングテーブル中の参照をＮ個置きに置き換えるものがある。図１４を参照すると、ストライピングテーブル１３００は、ＳＶＳにボリュームが追加されるときに再構成される。したがって、３ボリュームのセットに１つのボリュームを追加する場合、ストライピングテーブル中のボリューム参照は３つ置きに新たなボリュームに置き換えられる。例えば、第４の識別子「０」は、「３」に変更され、第４の識別子「１」は、「３」に変更され、第４の識別子「２」は、「３」に変更される。ただし、この再ストライピングプロセスを実施した場合、ＳＶＳサイズが比較的大きいと、ホットスポットが増加し、ボリューム使用効率は低下する。したがって、以下では、この再ストライピングプロセスに対する改良を他の再ストライピングプロセスによって例示する。

例えば、図１６Ａ〜図１６Ｇは、本発明の他の例示的実施形態により実施される他の再ストライピングプロセスを示している。具体的には、図１６Ａは、本発明の一実施形態による他の再ストライピングプロセスを示す図である。明瞭化のために、図示のストライピングテーブルには、「Ａ」〜「Ｌ」のラベルが付されることがある。さらに、ストライピングテーブルの中身は、ＳＶＳ中のストライピング後ののラウンドロビン分布を示している。すなわち、Ａ〜Ｃ、Ｄ〜Ｆ、Ｇ〜Ｉ等は、ボリューム０、１、及び２が、ストライピング後のデータを有するものとして識別されることを示している。上記の第（Ｎ＋１）再ストライピングプロセスの後、第４の識別子は、新たなボリューム識別子「３」で置き換えられる。ただし、ボリュームの使用分布を改善するために、置換オペレーション（例えば、トランプのデッキのシャッフルに似た「シャッフル」オペレーション）を追加し、ストライピング後のデータの位置を並べ替える場合もある。この置換は、以下に記載するような擬似ランダム技術によって確定的に生成される固定置換であってもよい。ボリュームに対するストライプの割り当てをテーブル形態で記録する場合、この置換は、テーブル中のエントリを擬似ランダムに、かつ確定的でない仕方で並び替える場合がある。その結果、複数のボリュームにわたるちょうど同じ全体的分布が得られることになるが、その分布は、良好な局所的分布、及びバランスを達成しない。

具体的には、Ｉ＜（ｎ／２）の場合、シャッフルオペレーションは、第１の位置Ｉにある識別子を第２の位置（２×Ｉ）へ移動させることによる、図１６Ａのストライピングテーブルの識別子の置換を含む場合がある。ここで、ｎは、ストライピングテーブルの位置の総数である。また、（ｎ／２）≦Ｉ＜ｎである場合、識別子は、第１の位置Ｉから第２の位置（（２×Ｉ ＭＯＤ ｎ）＋１）へ移動される場合がある。さらに、トランプカードのデッキを「切る」ときと同様に、シャッフルオペレーションは、ストライピングテーブルの識別子を擬似ランダム数ｐによって異なる位置へ回転させ、位置Ｉにある識別子が位置（（Ｉ＋Ｐ） ＭＯＤ ｎ）にくるようにすることを含む。ｐを擬似ランダムに選択することにより、ストライピングテーブルの位置の置換は、既知のシード値を使用して、「カット」と「シャッフル」の繰り返しによって確定的に行うことができる。なお、当然ながら、擬似ランダムオペレーションに使用されるシード値は、当業者にとって既知のものである。図１６Ａに示されているストライピングテーブルにおいて例として６回繰り返されているように、「カット」と「シャッフル」をある程度の回数繰り返した後、ストライピングテーブルの識別子の良好な擬似ランダム化が達成される。ただし、トランプカードのデッキを満足のいくまで「カット、及びシャッフル」する繰り返し数のように、任意の適当な数の繰り返しが可能である。

実施形態によっては、線形アレイとしてメモリに格納された所定の置換（例えば、ＳＶＳの確立に先立って計算される）をストライピングテーブルに適用してもよい。したがって、ストライピングテーブルは、上記の「シャッフル」オペレーションを使用して整備された後、次に、所定の置換が適用される場合がある。さらに、ストライピングテーブルに適用するために、ランダム、または擬似ランダムに生成された複数の所定の置換が、記憶される場合がある。

図１６Ｂに示されているような次の再ストライピングは、シャッフルを必要としない。具体的には、このプロセスは、置換を利用して、例示的なサイズを有するＳＶＳの１つのストライピングテーブルをラウンドロビン順序に並び替え、かつ、それと全く同じ置換を、異なるサイズのＳＶＳの別のストライピングテーブルにも適用する。例えば、任意の２つのテーブルが、本明細書に記載するプロセスのいずれかによって生成される。このプロセスは、ストライピングテーブルを、ラウンドロビンレイアウトのＳＶＳを表わすものにするものが好ましい。なぜなら、ラウンドロビンレイアウトは、ＳＶＳ中のデータの均一な分布といった、多数の優れた性質を有するからである。しかしながら、ＳＶＳを変更するとき、目標は、ボリューム数ＶのＳＶＳのストライプのうちの（１／（Ｖ＋１））だけを移動させることである。なお、本明細書に記載するプロセスは、ラウンドロビンレイアウトを得るために使用されているが、良好な性質を有するものであれば任意の適当なレイアウトを使用することが可能である。そのような良好な性質には、ホットスポット等に関して上で述べたものがある。

さらに別の実施形態として、図１６Ｂは、本発明の一実施形態による、他の再ストライピングプロセスを示す図である。この例示的実施形態では、２つのストライピングテーブル、すなわち、テーブル１とテーブル２を使用する。テーブル１は、ＳＶＳ中の現在のボリューム数を表わし、テーブル２は、追加のボリュームを有するＳＶＳを表している。テーブル１は、一度に１ボリュームづつ３ボリュームまで「成長」するストライピングテーブルを示している。当初、このストライピングテーブルは、ストライピングテーブル１６０１上のボリューム０を指す識別子を有している。ストライピングテーブル１６０２は、１ボリュームが追加された後の、識別子「０」及び「１」を有する２つのボリュームのラウンドロビンを示している。具体的には、第（Ｎ＋１）のボリューム参照を置き換えることにより、ラウンドロビン・ロードバランシングが行われる。第３のボリュームを追加するとき、識別子「２」がテーブル１に挿入され、ストライピングテーブルは、ストライピングテーブル１６０３のようになる。

それに対応して、テーブル２は、ストライピングテーブル１６０５上に１つのボリュームを有する当初のＳＶＳから「成長」される。ボリュームを追加するたびに、テーブル２上の各一意の識別子の第（Ｎ＋１）の発生が、置換される。したがって、ストライピングテーブル１６０６は、ボリューム０及び１の識別子を示し、ストライピングテーブル１６０７は、ボリューム０、１、及び２の識別子を示し、ストライピングテーブル１６０８は、ボリューム０、１、２、及び３の識別子を示している。その結果、スワップ・オペレーション中に、ストライピングテーブル１６０４の中身が、ストライピングテーブル１６０９の中身と合わせて再配置される。したがって、ラウンドロビン方式でストライピングされたデータの識別子を示すテーブル１の再配置は、ラウンドロビン方式でストライピングされたデータを得るために、テーブル２上でも模倣される。ただし、この再ストライピングプロセスは、図１６Ａの再ストライピングプロセスより改善されてはいるものの、比較的大きなボリュームセットについては、ボリューム利用効率の低下を受ける場合がある。

図１６Ｂに示す更に別の実施形態において、２つのテーブルを使用したプロセスは、本明細書に記載する任意のプロセスを使用して、Ｖ（例えば、テーブル１）、及びＶ＋１（例えば、テーブル２）の２つの値について２つのテーブルを生成することを含む。そして、ボリュームｄを追加する場合、プロセスは、残りのストライプの１／ｄを全て移動させなければならない。テーブル１の置換により、ラウンドロビンレイアウトを表わすストライピングテーブルになる。置換の１つの方法は、位置Ｉを埋めるときに、値（Ｉ ＭＯＤ ｖ）を有する次の移動されないエントリを選択することによって、ストライピングテーブルを順序付けることである。テーブル１を強制的にラウンドロビンにするためにテーブル１上のボリューム数Ｖに対して一組の移動を実施するとき、同時に、テーブル２上でも、ボリューム数Ｖ＋１に対する移動が実施される。この置換の結果、レイアウトテーブルは、Ｖに関するテーブルに「近い」所望の性質を有するものとなる。所望の性質が得られる理由は、２つのテーブル上の大半のエントリが、当初同じであったこと、そして、２つのテーブル上の全てのエントリについて、同様の、又はほぼ同様の置換が、全く同じ方法で行われたからである。さらに、上記の技術を使用すれば、サイズＶ＋１のＳＶＳの場合のストライピングテーブルは、１／（Ｖ＋１）のデータ移動しか必要としないであろう。したがって、ある数Ｖのボリューム中の識別子のレイアウトを表わす任意のストライピングテーブルに対し、ストライピングテーブルを１以上の方法で並び替える（置換する）ことで、複数のボリュームにわたる識別子のラウンドロビンレイアウトを生成することができる。

図１６Ｃは、本発明の一実施形態による、更に別の再ストライピングプロセスを示す。この再ストライピングプロセスは、図１４に関して上で説明した（Ｎ＋１）ボリューム参照の置換に似ているが、第（Ｎ＋１）のボリューム参照を置換する代わりに、ストライピングテーブル上の第（Ｎ＋１）識別子をその中身に関わらず置換する。例えば、ストライピングテーブル１６１０によって参照される３ボリュームのＳＶＳに対して第４のボリュームを追加した後、その３ボリュームのＳＶＳにおいて既に識別されているボリューム参照とは無関係に、第４の識別子は「３」に置換される。この再ストライピングプロセスに関し、識別子は、ストライピングテーブル全体に撒き散らされ、ボリューム参照の分布を増大させるが、全体的なボリューム利用効率は最適にならない場合がある。

図１６Ｄは、本発明の一実施形態による、更に別の再ストライピングプロセスを示す図である。具体的には、ＤＶ０、ＤＶ１、及びＤＶ２によって示されているように、３ボリュームのＳＶＳに１つのボリュームを追加する場合、結果的に得られるストライピングテーブル１６１１は、準備リストの使用によって得られる。準備リストは、ストライピングテーブル上の置換可能なボリューム参照を有する。当初、準備リストは、あらゆるボリューム参照を有する。第４のボリュームを追加するとき、ストライプテーブル上の第４の位置が置換される。次に、置換されたボリューム参照は、準備リストから取り除かれる。例えば、ＤＶ１へのボリューム参照が、準備リストから取り除かれ、ストライピングテーブル上のコンテンツ位置「Ｃ］にある識別子は、ボリューム「３」を参照する（すなわち、ＤＶ３、追加された第４のボリューム）。次に、コンテンツ位置「Ｈ」の置換を検査する。しかしながら、ＤＶ１は準備リストから既に取り除かれているので、プロセスは、準備リスト上のボリューム対応する第１のコンテンツ位置を探して、置換コンテンツ位置から前後にストライピングテーブルをスキャンする。スキャンにより得られた第１のコンテンツ位置は、準備リスト上のＤＶ０を識別する。したがって、コンテンツ位置「Ｔ」はボリューム識別子「３」に置換され、ＤＶ０は準備リストから取り除かれる。なお、前後の順でスキャンするという判断は自由であり、プロセスは、他の方向からスキャンを開始してもよい。準備リストが使い果たされると、全てのボリューム参照が、再度、準備リストに入れられる。このプロセスによれば、高いボリューム使用効率が可能となり、ある程度のランダム性が提供され、したがって、高い分散効率が提供される。

図１６Ｅは、本発明の一実施形態による再ストライピングプロセスを示す図である。例示的実施形態において再ストライピングプロセスを実施する場合、図１４の例と同様に、ストライピングテーブルは、ＳＶＳのボリュームの総数によって再度グループ化される。ただし、ＳＶＳのボリューム数をＮとしたとき、（Ｎ＋１）個のグループを生成した後、ボリュームを追加する前に、重複したボリューム参照をカウンタを使用せずに置換する。このプロセスは、高いボリューム使用効率を生み出すが、このプロセスでは、十分なラウンドロビン・ロードバランシングは得られない。

したがって、図１６Ｆは、本発明の一実施形態による、更に別の再ストライピングプロセスを示す図である。例えば、（Ｎ＋１）個のグループが生成された後、ストライピングテーブル１６１２上に存在するボリューム参照の総数をカウントするカウンタが、カウンタリスト１６１３に記録される。具体的には、ストライピングテーブル１６１２上で、ボリューム０は、８回参照される一方、ボリューム１及び２は、６回参照される。カウンタ１６１３を検査することにより、プロセスは、最大のカウンタを有するボリュームを置換することができる。したがって、カウンタが、５つのボリューム参照（これは、カウンタリスト１６１３上の残りのカウンタよりも小さい）に減少するまでに、ボリューム０は、３回置換される。ボリューム利用効率は、図１６Ｅに示したプロセスに比べて僅かに減少するが、同一グループ中の複数の置換により、ホットスポットの挙動は増加する。また、このプロセスは、各グループについて複数の置換が行われる可能性があることから、最適以下の再ストライピング挙動の影響を受ける場合がある。

図１６Ｇは、本発明の一実施形態による再ストライピングプロセスを示す図である。進化型アルゴリズムを例示するこの再ストライピングプロセスの例では、４ボリュームのＳＶＳから１つのボリュームが除去される。このプロセスにおいて、ボリューム「３」を参照するボリューム参照は、もはや有効ではない。したがって、プロセスは、そのボリューム参照をストライピングテーブルの末尾に移動させる。ボリューム「３」に対する識別子の再配置は、既存の有効なボリューム参照の中から、ラウンドロビン方式で選択される。ここで、有効なボリューム参照は、「０」、「１」、及び「２」である。

上に記載した種々の再ストライピングプロセスは、進化型と退化型に分類することができるが、本発明の実施形態によっては、退化型アルゴリズムを実施することなく、進化型アルゴリズムを実施することもある。図１７は、本発明の一実施形態による、進化型ストライピングテーブルのためのオペレーションを示すフロー図である。オペレーションは、１ボリューム用のストライピングテーブルを作成することにより、オペレーション１７１０から開始される。一度に１つのボリュームを追加することによりＳＶＳが「成長」するのに応じて、オペレーション１７２０は、ストライピングテーブルを進化させ、数ボリュームにつき各ストライピングテーブルを記憶する。例えば、１ボリューム、２ボリューム、３ボリューム等のストライピングテーブルの構成の記録が記憶される。ＳＶＳからボリュームが除去された場合、それらのレコードを検査することができる。具体的には、オペレーション１７３０において、ストライピングテーブルが退化される場合、ストライピングテーブルの「退化」には、以前に記憶されたストライピングテーブルへのアクセスが必要となる。

あるいは、本発明の他の実施形態（図示せず）では、進化型アルゴリズムを実施することなく、ストライピングテーブルを退化させるオペレーションを実施することがある。例えば、最大量のボリュームを有するある程度自由にストライピングされたボリュームセットの場合、ストライピングテーブルは、ラウンドロビンを使用して実施されることがある。そのような最大量のボリュームは、例えば２５５個のボリュームである。したがって、ボリュームを除去するときにＳＶＳが「縮小」する場合（例えば、２２５ボリュームから開始して）、退化型アルゴリズムの実施により得られるストライピングテーブルの種々の構成は、図１７の記録されたストライピングテーブル構成の使用と同様に、将来の使用に備えて格納することができる。具体的には、ストライピングテーブルが進化する場合、ストライピングテーブルの「退化」には、以前に記憶されたストライピングテーブルが必要となる。なお、最大サイズのＳＶＳの場合、退化型アルゴリズムだけを実施してストライピングテーブル構成が実現される限り、任意の適当な数のボリュームを使用することが可能である。

上記の説明は、本発明の特定の幾つかの実施形態に関するものになっている。しかしながら、それらの実施形態の利点の一部または全部を維持しながら、記載した実施形態に対し、他の変形、及び変更を施すことも可能である。具体的には、本発明の原理は、分散されていないファイルシステム上で実施することも可能である。また、本明細書の説明は、Ｎブレード、及びＤブレードに関するものとして書かれているが、本発明の教示は、ＮブレードとＤブレードの機能が単一のシステムで実施されるシステムにも、等しく適合させることができる。単一の装置は、それらのオペレーションを実施するためのデバイス、または装置に関する。装置は、必要とされる目的にあわせて特別に構成することができ、あるいは、コンピュータに格納されたコンピュータプログラムによって選択的に有効化、または構成された汎用コンピュータであってもよい。特に、種々の汎用マシンは、本明細書記載する教示にしたがって書かれたコンピュータプログラムとともに使用することができ、あるいは、より特殊な装置を構成し、必要とされるオペレーションを実施したほうが便利な場合もある。あるいは、Ｎブレード、及びＤブレードの機能を任意数の独立したシステム間に分散させ、各システムが、１以上の機能を実施するようにしてもよい。

本発明の実施形態は、コンピューティング環境管理システムによって管理することができる。例えば、カリフォルニア州サニーベイルのネットワーク・アプライアンス・インコーポレイテッドにより開発されたデータ・ファブリック・マネージャ（ＤＦＭ）等のようなコンピューティング環境管理システムは、クラスタ化コンピューティング環境を管理することができる。上記の実施形態を考慮すれば、本発明は、コンピュータシステムに格納されたデータに関わる種々の、コンピュータによって実施されるオペレーションに使用可能であるものと考えられる。こうしたオペレーションは、物理量の物理的操作を必要とする。一般に、必須ではないが、それらの量は、記憶、伝送、結合、比較、及び他の操作をすることが可能な電気的、磁気的、光信号などの形をとる。本明細書に記載した発明を構成するオペレーションはいずれも、機械処理に有用である。また、本明細書に記載する手順、プロセス、及び／又はモジュールは、ハードウェアで実施しても、プログラム命令を有するコンピュータ読み取り可能媒体として実施されるソフトウェアで実施しても、ファームウェアで実施してもよく、あるいは、それらの組み合わせによって実施してもよい。したがって、添付の特許請求の範囲の目的は、そうした変形や変更もすべて、本発明の真の思想、及び範囲に含めることにある。

本発明の一実施形態による、クラスタ化コンピューティング環境のクラスタとして相互接続された複数のノードを示す図である。 本発明の一実施形態によるノードを示す図である。 本発明の一実施形態とともに使用されるストレージ・オペレーティング・システムを示す図である。 本発明の一実施形態による、クラスタ・ファブリック（ＣＦ）メッセージのフォーマットを示す図である。 本発明の一実施形態による、データコンテナハンドルのフォーマットの詳細を示す図である。 本発明の一実施形態による、集合体の例を示す図である。 本発明の一実施形態による、バッファ・ツリーの例を示す図である。 本発明の一実施形態による、バッファ・ツリーの他の例を示す図である。 本発明の一実施形態による、集合体のオンディスク・フォーマットの例を示す図である。 本発明の一実施形態による、ボリューム位置データベース（ＶＬＤＢ）ボリュームエントリを示す図である。 本発明の一実施形態による、ＶＬＤＢ集合体エントリを示す図である。 本発明の一実施形態による、一群の管理プロセスを示す図である。 本発明の一実施形態による、ストライピングされたボリュームセット（ＳＶＳ）を示す図である。 本発明の一実施形態による、ＶＬＤＢ ＳＶＳエントリを示す図である。 本発明の一実施形態による、ＳＶＳのボリュームに格納されたファイル・コンテンツの周期的散在を示す図である。 本発明の一実施形態による、ストレージ・システム・アーキテクチャの複数のボリューム間に分散されたデータの割り当てを示す図である。 本発明の一実施形態による、ストライピングテーブルの例を示す図である。 本発明の一実施形態による、ストレージ・システム・アーキテクチャのボリュームの追加、及び除去を示す図である。 本発明の一実施形態による、ストレージ・システム・アーキテクチャ内でのボリュームの追加、及び除去のためのオペレーションを示すフロー図である。 本発明の一実施形態による、ボリュームの追加のためのオペレーションを示すフロー図である。 本発明の一実施形態による、ボリュームの除去のためのオペレーションを示すフロー図である。 本発明の一実施形態による、再ストライピングプロセスを示す図である。 本発明の一実施形態による、再ストライピングプロセスを示す図である。 本発明の一実施形態による、再ストライピングプロセスを示す図である。 本発明の一実施形態による、再ストライピングプロセスを示す図である。 本発明の一実施形態による、再ストライピングプロセスを示す図である。 本発明の一実施形態による、再ストライピングプロセスを示す図である。 本発明の一実施形態による、再ストライピングプロセスを示す図である。 本発明の一実施形態による、ストライピングテーブルを進化させるためのオペレーションを示すフロー図である。

Claims (9)

1. １つのクラスタとして相互接続された複数のストレージシステムによって提供される複数のボリュームにわたってデータを割り当てる方法であって、各ボリュームが、識別子を有するものにおいて、
   ２以上のコンピュータを互いに結合し、前記クラスタを形成するステップと、
   複数のボリュームを、ストライピングされたボリュームセットとして編成し、前記複数のボリュームが、前記クラスタの全域に分散され、各ボリュームが、前記２以上のコンピュータのうちの１つのコンピュータに取り付けられた記憶空間の論理配置となるようにするステップと、
   前記ストライピングされたボリュームセットの複数のボリュームにわたるデータチャンクの分布を表すように構成されたアロケーション構造を生成するステップであって、前記アロケーション構造の中身が、ボリュームの総数によってグループ化され、複数のグループを形成し、各グループが、前記ボリュームの各々について、そのグループの中にそのボリュームのための前記識別子が現れる回数を識別するためのカウンタを含む、アロケーション構造を生成するステップと、
   前記アロケーション構造を使用して、ストライプを成す１以上のデータコンテナを、前記ストライピングされたボリュームセットの全域にわたって格納するステップと、
   前記ストライピングされたボリュームセットの変更に応答して、前記カウンタに基づいて前記識別子を置き換えることにより、前記アロケーション構造を更新するステップと、
   更新されたアロケーション構造に従って、変更されたストライピングされたボリュームセットの複数のボリュームにわたってデータを再割当てするステップと
   を含み、
   前記ストライプは、パリティ情報を含まない、方法。
2. ラウンドロビン・ストライピングアルゴリズムを使用して、前記データチャンクを前記複数のボリュームにわたってストライピングされたデータとして分散させることを更に含む、請求項１に記載の方法。
3. 前記アロケーション構造を生成するステップは、前記複数のボリュームにわたって分散された各データチャンクの位置を識別することを更に含む、請求項１に記載の方法。
4. 前記アロケーション構造を更新するステップは、前記ストライピングされたボリュームセットにボリュームが追加されることに応答して、前記アロケーション構造の中身を再構成することからなる、請求項１に記載の方法。
5. 前記アロケーション構造を更新するステップは、前記ストライピングされたボリュームセットからボリュームが除去されることに応答して、前記アロケーション構造の中身を再構成することからなる、請求項１に記載の方法。
6. ストレージシステムクラスタによって提供される複数のボリュームにわたってデータを割り当てるように構成されたシステムであって、各ボリュームが、識別子を有するものにおいて、
   ストレージシステムクラスタを形成するように互いに結合された複数のコンピュータであって、前記複数のコンピュータのそれぞれが、前記複数のボリュームのうちの１以上を格納し、該ボリュームをストライピングされたボリュームセットとして編成するように構成され、前記ボリュームがそれぞれ、前記複数のコンピュータのうちの１つのコンピュータに取り付けられた記憶空間の論理配置である、複数のコンピュータと、
   前記複数のボリュームにわたるデータチャンクの分布を表すように構成されたアロケーション構造を有するように構成されたストレージシステムクラスタであって、前記アロケーション構造の中身が、ボリュームの総数によってグループ化され、複数のグループを形成し、各グループが、前記ボリュームの各々について、そのグループの中にそのボリュームのための前記識別子が現れる回数を識別するためのカウンタを含む、ストレージシステムクラスタと、
   前記ストレージシステムクラスタ中の１以上のコンピュータ上で実行されるボリューム・ストライピング・モジュールであって、該ボリューム・ストライピング・モジュールが、前記アロケーション構造を使用して、前記ストライピングされたボリュームセットの全域にわたって１以上のデータコンテナをストライプにストライピングする、ボリューム・ストライピング・モジュールと、
   前記ストレージシステムクラスタ上で実行される複数の再ストライピングプロセスであって、該再ストライピングプロセスのそれぞれが、前記ストライピングされたボリュームセットの変更に応答して、前記カウンタに基づいて前記識別子を置き換えることにより、前記アロケーション構造の中身を再構成し、更新されたアロケーション構造に従って、変更されたストライピングされたボリュームセットの複数のボリュームにわたってデータを再割当てするように構成される、複数の再ストライピングプロセスと
   を含み、
   前記ストライプは、パリティ情報を含まない、システム。
7. 前記アロケーション構造の中身は複数の識別子であり、各識別子は、前記複数のボリュームにわたって分散されたデータチャンクの位置を表す、請求項６に記載のシステム。
8. 前記ストライピングされたボリュームセットに対する追加ボリュームであって、前記アロケーション構造の中身を増加させる追加ボリュームと、
   前記アロケーション構造の中身を減少させるように構成された、前記ストライピングされたボリュームセットから除去される除去ボリュームと
   を更に含む、請求項７に記載のシステム。
9. 前記データコンテナは、ファイル、又はＬＵである、請求項６に記載のシステム。

Images