JP4787315B2 - データコンテナの中身をクラスタの複数のボリュームにわたってストライピングするためのストレージシステム・アーキテクチャ - Google Patents

データコンテナの中身をクラスタの複数のボリュームにわたってストライピングするためのストレージシステム・アーキテクチャ Download PDF

Info

Publication number
JP4787315B2
JP4787315B2 JP2008508821A JP2008508821A JP4787315B2 JP 4787315 B2 JP4787315 B2 JP 4787315B2 JP 2008508821 A JP2008508821 A JP 2008508821A JP 2008508821 A JP2008508821 A JP 2008508821A JP 4787315 B2 JP4787315 B2 JP 4787315B2
Authority
JP
Japan
Prior art keywords
data
file
volume
volumes
storage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008508821A
Other languages
English (en)
Other versions
JP2008539505A (ja
Inventor
カザル，マイケル
ジェーニガン，リチャード，ピー，ザ・フォース
サンジ，リチャード，エヌ，ジュニア
Original Assignee
ネットアップ，インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ネットアップ，インコーポレイテッド filed Critical ネットアップ，インコーポレイテッド
Publication of JP2008539505A publication Critical patent/JP2008539505A/ja
Application granted granted Critical
Publication of JP4787315B2 publication Critical patent/JP4787315B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers

Description

[発明の分野]
本発明はストレージシステムに関し、詳しくは、１つのファイルを１以上のストレージシステム上の複数のボリュームにわたってストライピングすることに関する。
[発明の背景]
ストレージシステムは通常、必要に応じて情報を入れたり、情報を取り出したりするための１以上の記憶装置を備える。ストレージシステムは、とりわけ、当該システムによって提供されるストレージサービスを支援するストレージ・オペレーションを実施することにより、当該システムを機能的に編成するためのストレージ・オペレーティング・システムを有する。ストレージシステムは、種々のストレージ・アーキテクチャにより実施することができ、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、及びクライアント又はホストコンピュータに直接取り付けられたディスクアセンブリ等によって実施される場合がある。記憶装置は通常、ディスクアレイとして編成されたディスクドライブである。ここで、「ディスク」という用語は一般に、内蔵型の回転磁気媒体ストレージディスクを意味する。この文脈におけるディスクという用語は、ハード・ディスク・ドライブ（ＨＤＤ）やダイレクト・アクセス・ストレージ・デバイス（ＤＡＳＤ）と同じ意味である。
ストレージシステムのストレージ・オペレーティング・システムは、ボリューム上に格納される情報をファイルや論理ユニットのようなデータコンテナの階層構造として論理編成するために、ファイルシステムのような高レベルモジュールを実施する場合がある。例えば、「ディスク上」の各ファイルは、そのファイルの実際のデータのような情報を格納するように構成された一組のデータ構造、すなわちディスクブロックとして実施される場合がある。それらのデータブロックは、ファイルシステムによって管理されるボリュームブロック番号（ｖｂｎ）空間の中で編成される。また、ファイルシステムは、ファイル内の各データブロックに、対応する「ファイル・オフセット」、又はファイルブロック番号（ｆｂｎ）を割り当てる場合がある。ファイルシステムは通常、ファイルごとに一連のｆｂｎを割り当てる一方、より大きなボリュームアドレス空間にわたってｖｂｎを割り当てる。ファイルシステムは、ｖｂｎ空間内のデータブロックを「論理ボリューム」として編成し、各論理ボリュームは、必須ではないが、その論理ボリューム独自のファイルシステムに関連する。
既知のタイプのファイルシステムの１つは、ディスク上でデータを上書きしないｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムである。ディスクからストレージシステムのメモリへとデータブロックを取得し（読み出し）、新たなデータで「汚す」（すなわち、更新する、又は変更する）場合、書き込み性能を最適化するために、そのデータブロックは、以後、ディスク上の新たな場所に格納される（書き込まれる）。ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、データがディスク上に実質的に連続的に配置されるような最適レイアウトを最初に想定する場合がある。この最適ディスクレイアウトによれば、ディスクに対する効率的なアクセスオペレーションが可能となり、特に、シーケンシャル読み出しアクセスの場合に、効率的なアクセスオペレーションが可能になる。ストレージシステム上で動作するように構成されたｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているＷｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムである。
ストレージシステムは、情報配送のクライアント／サーバモデルにしたがって動作するように更に構成される場合があり、それによって、多数のクライアントが、そのストレージシステムに格納されたデータコンテナにアクセスすることができる。このモデルでは、クライアントは、コンピュータ上で実行されるデータベース・アプリケーションのようなアプリケーションを含み、ポイント・ツー・ポイントリンク、共有ローカル・エリア・ネットワーク（ＬＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、または、インターネットのような公共ネットワークを介して実施される仮想私設ネットワーク（ＶＰＮ）のようなコンピュータネットワークを介してストレージシステムに「接続」する。各クライアントは、ネットワークを介して、ファイルベースのプロトコルメッセージ、及びブロックベースのプロトコルメッセージ（パケットの形をしている）をシステムに発行することによって、ストレージシステムのサービスを要求することができる。
複数のストレージシステムを相互接続し、多数のクライアントに対してサービスを提供するように構成されたストレージシステム環境を形成する場合もある。各ストレージシステムは、１以上のボリュームを提供するように構成され、各ボリュームは、１以上のデータコンテナを格納する場合がある。また、クライアントにより発行される多数のデータアクセス要求が、その環境の特定のストレージシステムによって提供される少数のデータコンテナに対して発行されることがある。そのような問題の１つの解決策は、特定のストレージシステムによって提供されるボリュームをその環境の全てのストレージシステムにわたって分散させることである。その結果、データアクセス要求、及び、その要求に応じるために必要とされる処理リソースは、全てのストレージシステムにわたって分散され、それによって、各ストレージオペレーティングシステムの個々の処理負荷は低減される。しかしながら、ファイルのような単一のデータコンテナだけが、ストレージシステム環境のクライアントによって頻繁にアクセスされる場合、顕著な欠点が現れる。その結果、そのデータコンテナに対する要求に応じるストレージシステムは、自分が有する処理リソースを超過し、過負荷になると同時に、速度や性能が低下する。
[発明の概要]
本発明は、クラスタとして相互接続された複数のノードにわたって分散された１以上のボリュームを含むストレージシステムアーキテクチャを提供することにより、従来技術の欠点を克服する。ボリュームは、ストライピングされたボリュームセット（ＳＶＳ）として編成され、クライアントが発行したマルチプロトコル・データアクセス要求に応答して、クラスタが提供するファイルや論理ユニットのようなデータコンテナの中身を格納するように構成される。クラスタの各ノードは、（１）ＳＶＳのボリュームを提供するように構成されたストレージサーバ、及び（２）データアクセス要求をクラスタのいずれかのストレージサーバへリダイレクトするように構成されたマルチプロトコル・エンジンを含む。特に、各データコンテナの中身は、ＳＶＳの複数のボリューム間に分配され、それによって、クラスタによって提供されるストレージサービスの効率が向上する。
本発明の一態様によれば、ＳＶＳは、１つのメタデータ・ボリューム（ＭＤＶ）、及び１以上のデータボリューム（ＤＶ）を含む。ＭＤＶは、ＳＶＳに格納されるすべてのメタデータに関連するアクセス・コントロール・リスト、及びディレクトリを格納するように構成される一方、各ＤＶは、少なくとも、それらのコンテナのデータ内容を格納するように構成される。ＳＶＳに格納される各データコンテナについて、１つのボリュームは、ＣＡＶに指定され、その目的のために、そのボリュームは、そのデータコンテナに関連する高速に変化する特定の属性メタデータを格納（「キャッシュ」」するように構成され、それによって、通常ならばＭＤＶへ送られるアクセス要求の負荷を低減する。
本発明の他の態様によれば、ＳＶＳは、ストライプ・アルゴリズム、ストライプ幅、及びＳＶＳ内のボリュームの順序付きリストを規定する一組のストライピング・ルールに関連する。ストライプ・アルゴリズムは、データコンテナの中身をストライプとして複数のボリュームにわたって分配する仕方を指定する一方、ストライプ幅は、各ストライプのサイズ／幅を指定する。また、ボリュームの順序付きリストは、そのＳＶＳの種々のボリューム、及びストライピング・ルールの機能、及び実施形態を指定する。例えば、順序付きリスト中の最初のボリュームは、ＳＶＳのＭＤＶを意味する一方、該リスト中のボリュームの順序は、例えばラウンド・ロビンのような特定のストライピング・アルゴリズムを実施する仕方を意味する場合がある。
一実施形態において、各ノードのストレージサーバは、ディスク要素（Ｄブレード）として実施され、マルチプロトコル・エンジンは、ネットワーク要素（Ｎブレード）として実施される。Ｎブレードは、マルチプロトコル・データアクセス要求をクライアントから受信し、その要求をクラスタ・ファブリック（ＣＦ）メッセージに変換し、そのメッセージをクラスタの適当なＤブレードにリダイレクトする。ＮブレードのＣＦモジュールは、そのメッセージの宛先となるＳＶＳボリューム中のデータコンテナ・コンテンツの位置を計算するために新規のＬｏｃａｔｅ（）関数を実施し、それによって、クラスタによって提供されるそのようなコンテンツの整合性を確保する。各Ｄブレードは、ファイルシステムとボリューム・ストライピング・モジュール（ＶＳＭ）を含み、それらが協働し、ストライピング・ルールにしたがってＣＦメッセージを処理することによって、ＳＶＳのボリュームを提供する。特に、ＶＳＭは、新規のＬｏｃａｔｅ（）関数を実施する。
本発明の上記の利点、及び他の利点は、添付の図面と併せて下記の説明を読むと、よりよく理解できるであろう。図中、同じ符号は、同一の構成要素、又は機能的に類似の構成要素であることを示している。
[例示的実施形態の詳細な説明]
Ａ．クラスタ環境
図１は、クラスタ１００として相互接続され、記憶装置上の情報の編成に関するストレージサービスを提供するように構成された複数のノード２００を示す略ブロック図である。ノード２００は種々の機能的構成要素を含み、それが協働して、クラスタ１００の分散ストレージシステムアーキテクチャを提供する。その目的のために、各ノード２００は通常、ネットワーク環境（Ｎブレード３１０）、及びディスク要素（Ｄブレード３５０）として編成される。Ｎブレード３１０は、コンピュータ・ネットワーク１４０を介してノード２００をクライアント１８０に接続する機能を有する一方、各Ｄブレード３５０は、ディスクアレイ１２０のディスク１３０のような１以上の記憶装置に接続される。ノード２００は、クラスタ切り替え装置１５０によって相互接続され、例示的実施形態として、クラスタ切り替え構造１５０は、ギガビット・イーサネット(R)・スイッチとして実施される場合がある。分散ファイルシステムアーキテクチャの一例は、２００２年８月２２日に発行されたM. Kazar他による「METHOD AND SYSTEM FOR RESPONDING TO FILE SYSTEM REQUESTS」と題する米国特許出願公開公報第ＵＳ２００２／０１１６５９３号に記載されている。なお、図示のクラスタ１００では、同数のＮブレード、及びＤブレードが描かれているが、本発明の種々の実施形態によれば、Ｎブレード、及びＤブレードの数は異なる場合もある。クラスタ構成１００には、例えば、複数の相互接続されたＮブレード、及び／又はＤブレードが存在する場合があり、それらは、ＮブレードとＤブレードの一対一対応を反映しない場合がある。したがって、１つのＮブレードと１つのＤブレードを含むノード２００の説明は、単なる例として捉えなければならない。
クライアント１８０は、情報配送のクライアント／サーバモデルにしたがってノード２００と通信するように構成された汎用コンピュータであってもよい。つまり、各クライアントが、ノードにサービスを要求すると、そのノードは、ネットワーク１４０を介してパケットをやりとりすることによって、そのクライアントによって要求されたサービスの結果を返す場合がある。ファイルやディレクトリの形態をした情報をアクセスするとき、クライアントは、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）上で実施されるコモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルやネットワーク・ファイルシステム（ＮＦＳ）プロトコルのようなファイルベースのアクセスプロトコルを有するパケットを発行する場合がある。あるいはクライアントは、ブロックの形態をした情報をアクセスする場合、「ＳＣＳＩ ｏｖｅｒ ＴＣＰ（ｉＳＣＳＩ）」プロトコルや「ＳＣＳＩ ｏｖｅｒ ＦＣ（ＦＣＰ）」プロトコルのようなブロックベースのアクセスプロトコルを有するパケットを発行する場合がある。
Ｂ．ストレージシステムノード
図２は、システムバス２２３によって相互接続された複数のプロセッサ２２２ａ，ｂ、メモリ２２４、ネットワーク・アダプタ２２５、クラスタ・アクセス・アダプタ２２６、ストレージアダプタ２２８、及びローカルストレージ２３０を含むストレージシステムとして例えば実施されるノード２００を示す略ブロック図である。ローカルストレージ２３０は、ユーザモード・アプリケーション１１００として実施される１以上の管理プロセスによって提供される（図１１参照）設定情報（例えば、設定テーブル２３５の中にあるようなもの）をローカルに格納するために使用されるディスクのような１以上の記憶装置を含む。クラスタ・アクセス・アダプタ２２６は、ノード２００をクラスタ１００の他のノードに接続するための複数のポートを備える。一実施形態では、クラスタリング・プロトコル、及び相互接続媒体としてイーサネット(R)が使用されるが、当業者には明らかなように、本明細書に記載するクラスタアーキテクチャの中で、他のタイプのプロトコル、及び相互接続を使用することも可能である。ＮブレードとＤブレードが個別のストレージシステム、又はコンピュータ上で実施されるような代替実施形態の場合、Ｎ／Ｄブレードは、クラスタ・アクセス・アダプタ２２６を使用して、クラスタ１００中の他のＮ／Ｄブレードと通信する場合がある。
各ノード２００は、例えば、ストレージ・オペレーティング・システム３００を実行するデュアル・プロセッサ・ストレージ・システム３００として実施される。ストレージ・オペレーティング・システム３００は、情報を名前付きディレクトリ、ファイル、及び仮想ディスクと呼ばれる特殊なタイプのファイル（以後、「ブロック」）の階層構造としてディスク上に論理編成するために、ファイルシステムのような高レベルモジュールを実施することが好ましい。ただし、当業者には明らかなように、ノード２００は、代わりに、１以上のプロセッサ・システムを含む場合がある。例えば、一方のプロセッサ２２２ａは、そのノード上のＮブレード３１０の機能を実行する一方、他方のプロセッサ２２２ｂは、Ｄブレード３５０の機能を実行する場合がある。
メモリ２２４は例えば、本発明に関連するソフトウェア・プログラム・コード、及びデータ構造を記憶するために、プロセッサ、及びアダプタによってアドレス指定可能な複数の記憶場所を有する。さらに、プロセッサ、及びアダプタは、そのソフトウェア・コードを実行し、データ構造を操作するように構成された処理要素、及び／又は論理回路を含む場合がある。ストレージ・オペレーティング・システム３００は通常、その一部がメモリに常駐し、処理要素によって実行され、とりわけ、そのノードにより実施されるストレージサービスを支援するストレージ・オペレーションを実施することによって、ノード２００を機能的に編成する。当業者には明らかなように、本明細書に記載する本発明に関するプログラム命令の格納や実行には、他の処理手段や、コンピュータ読み取り可能媒体を含む他の記憶手段を使用してもよい。
ネットワークアダプタ２２５は、ポイント・ツー・ポイントリンク、ワイド・エリア・ネットワーク、公共ネットワーク（インターネット）上で実施される仮想私設ネットワーク、又は共有ローカル・エリア・ネットワークを介して、ノード２００を１以上のクライアント１８０に接続するように構成された複数のポートを有する。したがって、ネットワークアダプタ２２５は、ノードをネットワークに接続するために必要とされる機械的、電気的、及び信号的回路を含む場合がある。例えば、コンピュータネットワーク１４０は、イーサネット・ネットワークやファイバ・チャネル（ＦＣ）ネットワークとして実施される場合がある。各クライアント１８０は、ＴＣＰ／ＩＰのような所定のプロトコルにしたがってデータパケット、またはデータフレームをやりとりすることにより、ネットワーク１４０を介してノードと通信することができる。
ストレージアダプタ２２８は、ノード２００上で実行されているストレージ・オペレーティング・システム３００と協働し、クライアントによって要求された情報を取得する。この情報は、ビデオテープ、光学媒体、ＤＶＤ、磁気テープ、バブルメモリ、電気的ランダム・アクセス・メモリ、及びＭＥＭＳデバイスの他、データやパリティ情報のような情報を格納するように構成された他の任意の同様の媒体のような書き込み可能なストレージ・デバイスの任意のタイプのアタッチド・アレイに格納される場合がある。ただし、本明細書に記載するように、情報は、アレイ１２０のディスク１３０上に記憶されることが好ましい。ストレージ・アダプタは、従来の高性能ＦＣリンクトポロジのようなＩ／Ｏ相互接続構成を介してディスクに接続するための入出力（Ｉ／Ｏ）インタフェース回路を備えた複数のポートを有する。
各アレイ１２０への情報の格納は、一群の物理ストレージディスク１３０を含む１以上のストレージ「ボリューム」として実施されることが好ましく、それらの物理ストレージディスク１３０が協働し、そのボリューム（複数の場合もあり）上のボリュームブロック番号（ｖｂｎ）空間の全体的論理配置を規定する。各論理ボリュームは通常、必須ではないが、そのボリューム独自のファイルシステムに関連する。論理ボリューム／ファイルシステム内のディスクは通常、１以上のグループに編成され、各グループは、ＲＡＩＤ（Redundant Array of Independent Disks）として運用される場合がある。ＲＡＩＤ−４レベル実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ中の所与の数の物理ディスクにわたってデータ「ストライプ」を冗長書き込みし、そのストライプ状データに対するパリティ情報を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。ＲＡＩＤ実施形態の一例はＲＡＩＤ−４レベル実施形態である。しかしながら、他のタイプ、又はレベルのＲＡＩＤ実施形態も、本明細書に記載する本発明の原理にしたがって使用可能であるものと考えるべきである。
Ｃ．ストレージ・オペレーティング・システム
ディスク１３０へのアクセスを容易にするために、ストレージ・オペレーティング・システム３００は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。このファイルシステムは、１以上の仮想化モジュールと協働し、ディスク１３０によって提供される記憶空間を「仮想化」する。ファイルシステムは、情報を名前付きディレクトリ、及びファイルの階層構造としてディスク上に論理編成する。「ディスク上」の各ファイルは、データのような情報を格納するように構成された一組のディスクブロックとして実施される一方、ディレクトリは、特殊フォーマットのファイルとして実施され、その中に、他のファイルやディレクトリの名前、及びそれらへのリンクが格納される場合がある。仮想化モジュール（複数の場合もあり）により、ファイルシステムは、情報をブロックの階層構造としてディスク上に更に論理編成し、それらを名前付き論理ユニット番号（ＬＵＮ）としてエキスポートすることが可能になる。
例示的実施形態として、ストレージ・オペレーティング・システムは、カリフォルニア州サニーベイルにあるネットワーク・アプライアンス・インコーポレイテッドから市販されているＮｅｔＡｐｐ Ｄａｔａ ＯＮＴＡＰオペレーティングシステムであることが好ましい。このオペレーティングシステムは、Ｗｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムを実施する。ただし、当然ながら、任意の適当なストレージオペレーティングシステムを本明細書に記載する本発明の原理に従って使用されるように拡張することも可能である。したがって、「ＷＡＦＬ」という用語を使用した場合でも、この用語は、本発明の教示に適合する任意のストレージ・オペレーティング・システムを指すものとして広い意味で解釈しなければならない。
図３は、本発明とともに有利に使用されるストレージ・オペレーティング・システム３００を示す略ブロック図である。ストレージ・オペレーティング・システムは、統合ネットワーク・プロトコル・スタックを形成するように編成された一連のソフトウェア層を含み、より一般的に言えば、ノードに格納された情報をクライアントがブロックアクセスプロトコルとファイルアクセスプロトコルを使用してアクセスするためのデータパスを提供するマルチプロトコル・エンジン３２５を含む。マルチプロトコル・エンジンは、ＩＰ層３１４、並びにその支援搬送機構であるＴＣＰ層３１６、及びユーザ・データグラム・プロトコル（ＵＤＰ）層３１５のようなネットワークプロトコル層に対するインタフェースとして機能するネットワークドライバ（例えば、ギガビット・イーサネット(R)・ドライバ）のメディア・アクセス層３１２を含む。ファイルシステムプロトコル層はマルチプロトコルアクセスを提供し、その目的のために、ダイレクト・アクセス・ファイルシステム（ＤＡＦＳ）プロトコル３１８、ＮＦＳプロトコル３２０、ＣＩＦＳプロトコル３２２、及びハイパー・テキスト・トランスファ・プロトコル（ＨＴＴＰ）プロトコル３２４をサポートする。ＶＩ層３２６は、ＤＡＦＳプロトコル３１８によって必要とされるＲＤＭＡのようなダイレクト・アクセス・トランスポート（ＤＡＴ）機能を提供するために、ＶＩアーキテクチャを実施する。ｉＳＣＳＩドライバ層３２８は、ＴＣＰ／ＩＰネットワークプロトコル層を介したブロックプロトコルアクセスを提供する一方、ＦＣドライバ層３３０は、ブロックアクセス要求、及び応答をノードとの間で送受信する。ＦＣドライバ、及びｉＳＣＳＩドライバは、ブロックに対するＦＣ固有の、及びｉＳＣＳＩ固有のアクセスコントロールを提供し、したがって、ノード２００上のブロックにアクセスするときに、ｉＳＣＳＩとＦＣＰのいずれか、またはｉＳＣＳＩとＦＣＰの両方に対するＬＵＮのエキスポートを管理する。
さらに、ストレージ・オペレーティング・システムは、ノード２００のディスク１３０上に格納された情報にアクセスするためのデータパスを提供するストレージサーバ３６５を形成するように編成された一連のソフトウェア層を含む。その目的のために、ストレージサーバ３６５は、ボリューム・ストライピング・モジュール（ＶＳＭ）３７０、ＲＡＩＤシステムモジュール３８０、及びディスクドライバシステムモジュール３９０と協働するファイルシステムモジュール３６０を含む。ＲＡＩＤシステム３８０は、Ｉ／Ｏオペレーションにしたがって、ボリューム／ディスクに対する情報の記憶、及び読み出しを管理し、ディスクドライバシステム３９０は、例えばＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施する。ＶＳＭ３７０は、例えば、本発明のストライピングされたボリュームセット（ＳＶＳ）を実施する。後で詳しく説明するように、ＶＳＭは、ファイルシステム３６０と協働し、ストレージサーバ３６５が、ＳＶＳのボリュームを提供できるようにする。具体的には、ＶＳＭ３７０は、ＳＶＳボリューム中のデータコンテナコンテンツの位置を計算するための新規なＬｏｃａｔｅ（）関数３７５を実施し、それによって、クラスタによって提供されるそのようなコンテンツの整合性を確保する。
ファイルシステム３６０は、１以上の仮想化モジュールと通信することにより、ストレージ・オペレーティング・システム３００の仮想化システムを実施する。仮想化モジュールは、例えば仮想ディスク（ｖｄｉｓｋ）モジュール（図示せず）、及びＳＣＳＩターゲットモジュール３３５として実施される場合がある。ｖｄｉｓｋモジュールは、ユーザ（システム管理者）がノード２００に対して発行したコマンドに応答して、管理フレームワーク１１１０(図１参照）のユーザインタフェースのような管理インタフェースによるアクセスを有効化する。ＳＣＳＩターゲットモジュール３３５は通常、ＦＣドライバ２３０、ｉＳＣＳＩドライバ３２８と、ファイルシステム３６０との間に配置され、ブロック（ＬＵＮ）空間とファイルシステム空間との間に、仮想化システムの変換層を提供する。その際、ＬＵＮは、ブロックとして表現される。
ファイルシステム３６０は、例えば、ディスクのような記憶装置に格納された情報のアクセスに使用される論理ボリューム管理機能を提供するメッセージベースのシステムである。つまり、ファイルシステム３６０は、ファイルシステムセマンティックを提供するだけでなく、通常ならばボリューム・マネージャに関わる機能も提供する。そのような機能には、（１）ディスクの集合化、（２）ディスクの記憶帯域幅の集合化、（３）ミラーリング、及び／又はパリティ（ＲＡＩＤ）のような信頼性保証がある。

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

Claims (10)

  1. １つのクラスタを形成するように互いに接続された２以上のコンピュータと、
    前記２以上のコンピュータにわたって分散され、ストライピングされたボリュームセットを形成する複数のボリュームであって、前記ストライピングされたボリュームセットが一組のストライピング・ルールによって規定され、各ボリュームが前記２以上のコンピュータのうちの１つのコンピュータに取り付けられた記憶空間の論理配置であるように構成される、複数のボリュームと、
    前記クラスタ中の１以上のコンピュータ上で実行されるボリューム・ストライピング・モジュールであって、前記ストライピングされたボリュームセットの全域にわたって１以上のデータコンテナをストライピングするボリューム・ストライピング・モジュールと
    を含み、
    前記ストライピングされたボリュームセットは、メタデータボリューム、及び２以上のデータボリュームを含み、
    前記メタデータボリュームは、前記ストライピングされたボリュームセットに格納されたデータコンテナに関連するメタデータを格納するが、データコンテナのためのデータを格納せず、
    前記２以上のデータボリュームは、前記ストライピングされたボリュームセットに格納されたデータコンテナのためのデータを格納し、
    前記ストライピングされたボリュームセットに格納された各データコンテナについて、前記２以上のデータボリュームのうちの１つが、そのデータコンテナに関連するメタデータをキャッシュするために指定され、それによって、通常ならばメタデータボリュームに関連するアクセス要求の負荷を軽減することを特徴とするシステム。
  2. 前記複数のボリュームは複数の仮想ボリュームである、請求項１に記載のシステム。
  3. 前記２以上のコンピュータのうちの第１のコンピュータに取り付けられた１以上の記憶装置が、物理ボリュームブロック番号（ｐｖｂｎ）記憶空間を備えた集合体を形成するように論理配置される、請求項２に記載のシステム。
  4. 前記複数の仮想ボリュームのうちの１以上が、前記第１のコンピュータの前記集合体の中に格納される、請求項３に記載のシステム。
  5. 前記複数のボリュームは物理ボリュームである、請求項１に記載のシステム。
  6. 前記データコンテナは、ファイル、又はＬＵＮである、請求項１に記載のシステム。
  7. 前記一組のストライピング・ルールは、ストライプ幅、及びボリュームの順序付きリストを含む、請求項１に記載のシステム。
  8. 前記メタボリュームは、アクセス・コントロール・リスト、及び前記ストライピングされたボリュームセットの全域にわたって格納されたデータコンテナのディレクトリをさらに格納する、請求項１に記載のシステム。
  9. ２以上のコンピュータを１つのクラスタを形成するように互いに接続するステップと、
    一組のストライピング・ルールを使用して、複数のボリュームを、ストライピングされたボリュームセットとして編成し、前記複数のボリュームが、前記クラスタの全域にわたって分散され、各ボリュームが、前記２以上のコンピュータのうちの１つのコンピュータに取り付けられた記憶空間の論理配置となるようにするステップと、
    １以上のデータコンテナを１つのストライプを成すように前記ストライピングされたボリュームセットの全域にわたって記憶するステップと
    を含み、
    前記ストライピングされたボリュームセットは、メタデータボリューム、及び２以上のデータボリュームを含み、
    前記メタデータボリュームは、前記ストライピングされたボリュームセットに格納されたデータコンテナに関連するメタデータを格納するが、データコンテナのためのデータを格納せず、
    前記２以上のデータボリュームは、前記ストライピングされたボリュームセットに格納されたデータコンテナのためのデータを格納し、
    前記ストライピングされたボリュームセットに格納された各データコンテナについて、前記２以上のデータボリュームのうちの１つが、そのデータコンテナに関連するメタデータをキャッシュするために指定され、それによって、通常ならばメタデータボリュームに関連するアクセス要求の負荷を軽減することを特徴とする方法。
  10. 前記一組のストライピング・ルールは、ストライプ幅、及びボリュームの順序付きリストを含む、請求項９に記載の方法。
JP2008508821A 2005-04-29 2005-08-31 データコンテナの中身をクラスタの複数のボリュームにわたってストライピングするためのストレージシステム・アーキテクチャ Expired - Fee Related JP4787315B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/119,278 2005-04-29
US11/119,278 US7698289B2 (en) 2003-12-02 2005-04-29 Storage system architecture for striping data container content across volumes of a cluster
PCT/US2005/030889 WO2006118592A1 (en) 2005-04-29 2005-08-31 Storage system architecture for striping data container content across volumes of a cluster

Publications (2)

Publication Number Publication Date
JP2008539505A JP2008539505A (ja) 2008-11-13
JP4787315B2 true JP4787315B2 (ja) 2011-10-05

Family

ID=35478702

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008508821A Expired - Fee Related JP4787315B2 (ja) 2005-04-29 2005-08-31 データコンテナの中身をクラスタの複数のボリュームにわたってストライピングするためのストレージシステム・アーキテクチャ

Country Status (9)

Country Link
US (1) US7698289B2 (ja)
EP (1) EP1875385B1 (ja)
JP (1) JP4787315B2 (ja)
CN (1) CN101218583B (ja)
AT (1) ATE493714T1 (ja)
AU (1) AU2005331262B2 (ja)
DE (1) DE602005025702D1 (ja)
IL (1) IL186996A (ja)
WO (1) WO2006118592A1 (ja)

Families Citing this family (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7647451B1 (en) 2003-11-24 2010-01-12 Netapp, Inc. Data placement technique for striping data containers across volumes of a storage system cluster
US7698289B2 (en) 2003-12-02 2010-04-13 Netapp, Inc. Storage system architecture for striping data container content across volumes of a cluster
US7409497B1 (en) 2003-12-02 2008-08-05 Network Appliance, Inc. System and method for efficiently guaranteeing data consistency to clients of a storage system cluster
US8312110B2 (en) * 2004-03-12 2012-11-13 Kanata Limited Content manipulation using hierarchical address translations across a network
JP4313703B2 (ja) * 2004-03-12 2009-08-12 彼方株式会社 情報処理装置、システム、方法及びプログラム
US7409494B2 (en) 2004-04-30 2008-08-05 Network Appliance, Inc. Extension of write anywhere file system layout
US7430571B2 (en) * 2004-04-30 2008-09-30 Network Appliance, Inc. Extension of write anywhere file layout write allocation
US20050262090A1 (en) * 2004-05-21 2005-11-24 Correl Stephen F Method, system, and article of manufacture for storing device information
CN101228523B (zh) 2005-04-25 2012-06-06 网络装置公司 用于高速缓存网络文件系统的系统和方法
US7698501B1 (en) 2005-04-29 2010-04-13 Netapp, Inc. System and method for utilizing sparse data containers in a striped volume set
US7904649B2 (en) 2005-04-29 2011-03-08 Netapp, Inc. System and method for restriping data across a plurality of volumes
US7743210B1 (en) 2005-04-29 2010-06-22 Netapp, Inc. System and method for implementing atomic cross-stripe write operations in a striped volume set
US7698334B2 (en) 2005-04-29 2010-04-13 Netapp, Inc. System and method for multi-tiered meta-data caching and distribution in a clustered computer environment
US7617370B2 (en) * 2005-04-29 2009-11-10 Netapp, Inc. Data allocation within a storage system architecture
WO2006119100A2 (en) * 2005-04-29 2006-11-09 Network Appliance, Inc. System and method for generating consistent images of a set of data objects
US7739318B2 (en) 2005-06-20 2010-06-15 Netapp, Inc. System and method for maintaining mappings from data containers to their parent directories
US8484213B2 (en) * 2005-08-31 2013-07-09 International Business Machines Corporation Heterogenous high availability cluster manager
US8484365B1 (en) * 2005-10-20 2013-07-09 Netapp, Inc. System and method for providing a unified iSCSI target with a plurality of loosely coupled iSCSI front ends
EP1949214B1 (en) 2005-10-28 2012-12-19 Network Appliance, Inc. System and method for optimizing multi-pathing support in a distributed storage system environment
US8032896B1 (en) 2005-11-01 2011-10-04 Netapp, Inc. System and method for histogram based chatter suppression
US7325111B1 (en) * 2005-11-01 2008-01-29 Network Appliance, Inc. Method and system for single pass volume scanning for multiple destination mirroring
US7376796B2 (en) * 2005-11-01 2008-05-20 Network Appliance, Inc. Lightweight coherency control protocol for clustered storage system
US8255425B1 (en) 2005-11-01 2012-08-28 Netapp, Inc. System and method for event notification using an event routing table
US7730258B1 (en) 2005-11-01 2010-06-01 Netapp, Inc. System and method for managing hard and soft lock state information in a distributed storage system environment
US7565519B1 (en) 2006-03-23 2009-07-21 Netapp, Inc. System and method for automatically upgrading/reverting configurations across a plurality of product release lines
US7769723B2 (en) * 2006-04-28 2010-08-03 Netapp, Inc. System and method for providing continuous data protection
US7840969B2 (en) * 2006-04-28 2010-11-23 Netapp, Inc. System and method for management of jobs in a cluster environment
US8046422B2 (en) * 2006-08-21 2011-10-25 Netapp, Inc. Automatic load spreading in a clustered network storage system
US7747584B1 (en) 2006-08-22 2010-06-29 Netapp, Inc. System and method for enabling de-duplication in a storage system architecture
US7933921B2 (en) * 2006-11-29 2011-04-26 Netapp, Inc. Referent-controlled location resolution of resources in a federated distributed system
US8301673B2 (en) * 2006-12-29 2012-10-30 Netapp, Inc. System and method for performing distributed consistency verification of a clustered file system
US8099766B1 (en) * 2007-03-26 2012-01-17 Netapp, Inc. Credential caching for clustered storage systems
US9134921B1 (en) 2007-04-23 2015-09-15 Netapp, Inc. Uniquely naming storage devices in a global storage environment
US7827350B1 (en) 2007-04-27 2010-11-02 Netapp, Inc. Method and system for promoting a snapshot in a distributed file system
US8315984B2 (en) * 2007-05-22 2012-11-20 Netapp, Inc. System and method for on-the-fly elimination of redundant data
US7797489B1 (en) 2007-06-01 2010-09-14 Netapp, Inc. System and method for providing space availability notification in a distributed striped volume set
US7975102B1 (en) * 2007-08-06 2011-07-05 Netapp, Inc. Technique to avoid cascaded hot spotting
US8224864B1 (en) * 2008-01-07 2012-07-17 Network Appliance, Inc. Striping directories across a striped volume set by the filenames contained in the directories
US7996607B1 (en) 2008-01-28 2011-08-09 Netapp, Inc. Distributing lookup operations in a striped storage system
US8019956B1 (en) 2008-03-07 2011-09-13 Network Appliance, Inc. System and method for concurrently storing and accessing data in a tree-like data structure
US7840730B2 (en) 2008-06-27 2010-11-23 Microsoft Corporation Cluster shared volumes
US9323681B2 (en) 2008-09-18 2016-04-26 Avere Systems, Inc. File storage system, cache appliance, and method
US8214404B2 (en) * 2008-07-11 2012-07-03 Avere Systems, Inc. Media aware distributed data layout
US9043288B2 (en) * 2008-10-27 2015-05-26 Netapp, Inc. Dual-phase file system checker
US7992055B1 (en) 2008-11-07 2011-08-02 Netapp, Inc. System and method for providing autosupport for a security system
US20100235878A1 (en) * 2009-03-13 2010-09-16 Creative Technology Ltd. Method and system for file distribution
US9164689B2 (en) * 2009-03-30 2015-10-20 Oracle America, Inc. Data storage system and method of processing a data access request
US8161076B1 (en) * 2009-04-02 2012-04-17 Netapp, Inc. Generation and use of a data structure for distributing responsibilities among multiple resources in a network storage system
US8117388B2 (en) * 2009-04-30 2012-02-14 Netapp, Inc. Data distribution through capacity leveling in a striped file system
US8560855B2 (en) * 2009-08-27 2013-10-15 Cleversafe, Inc. Verification of dispersed storage network access control information
US8639658B1 (en) * 2010-04-21 2014-01-28 Symantec Corporation Cache management for file systems supporting shared blocks
US8626713B2 (en) 2010-12-08 2014-01-07 International Business Machines Corporation Multiple contexts in a redirect on write file system
US8458181B2 (en) 2010-12-08 2013-06-04 International Business Machines Corporation Distributed free block map for a clustered redirect-on-write file system
US8904006B2 (en) 2010-12-08 2014-12-02 International Business Machines Corporation In-flight block map for a clustered redirect-on-write filesystem
US8396832B2 (en) 2010-12-08 2013-03-12 International Business Machines Corporation Independent fileset generations in a clustered redirect-on-write filesystem
US8732346B2 (en) 2010-12-17 2014-05-20 Microsoft Corporation Coordination of direct I/O with a filter
US8683170B1 (en) 2011-09-23 2014-03-25 Netapp, Inc. Consistent distributed storage communication protocol semantics in a clustered storage system
US9203900B2 (en) * 2011-09-23 2015-12-01 Netapp, Inc. Storage area network attached clustered storage system
US9444889B1 (en) 2013-02-08 2016-09-13 Quantcast Corporation Managing distributed system performance using accelerated data retrieval operations
US9430545B2 (en) 2013-10-21 2016-08-30 International Business Machines Corporation Mechanism for communication in a distributed database
US9465820B2 (en) 2013-11-13 2016-10-11 Cellco Partnership Method and system for unified technological stack management for relational databases
US9336300B2 (en) * 2014-01-17 2016-05-10 Facebook, Inc. Client-side search templates for online social networks
US20150363118A1 (en) * 2014-06-17 2015-12-17 Netapp, Inc. Techniques for harmonic-resistant file striping
US9892041B1 (en) * 2014-09-30 2018-02-13 Veritas Technologies Llc Cache consistency optimization
US10379742B2 (en) * 2015-12-28 2019-08-13 Netapp, Inc. Storage zone set membership
US10514984B2 (en) 2016-02-26 2019-12-24 Netapp, Inc. Risk based rebuild of data objects in an erasure coded storage system
CN110704249A (zh) * 2016-12-30 2020-01-17 成都华为技术有限公司 一种保证应用一致性的方法、装置及系统
US10947756B2 (en) 2017-05-10 2021-03-16 R.R. Brink Locking Systems, Inc. Electromechanical lock with mechanical latch holdback and remote release
CN110019081B (zh) * 2017-07-20 2023-04-07 中兴通讯股份有限公司 数据持久化处理方法、装置、系统及可读存储介质
CN107844436B (zh) * 2017-11-02 2021-07-16 郑州云海信息技术有限公司 一种缓存中脏数据的组织管理方法、系统及存储系统
US10678752B2 (en) 2018-02-07 2020-06-09 International Business Machines Corporation Closure-based container volumes with ratio-based modeling
US11301421B2 (en) * 2018-05-25 2022-04-12 Microsoft Technology Licensing, Llc Scalable multi-tier storage structures and techniques for accessing entries therein
US11153382B2 (en) * 2018-06-29 2021-10-19 International Business Machines Corporation Isolation of management data for security and operational advantages
US11204892B2 (en) 2019-03-21 2021-12-21 Microsoft Technology Licensing, Llc Techniques for snapshotting scalable multitier storage structures
CN116107520B (zh) * 2023-04-13 2023-06-30 北京中科特瑞科技有限公司 S3对象存储协议的加密数据存储方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003099210A (ja) * 2001-09-25 2003-04-04 Toshiba Corp 仮想的なｒａｉｄ装置を有するクラスタシステム及び同システム用のコンピュータ

Family Cites Families (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5202979A (en) 1985-05-08 1993-04-13 Thinking Machines Corporation Storage system using multiple independently mechanically-driven storage units
US4916608A (en) 1986-05-30 1990-04-10 International Business Machines Corporation Provision of virtual storage resources to an operating system control program
US4899342A (en) 1988-02-01 1990-02-06 Thinking Machines Corporation Method and apparatus for operating multi-unit array of memories
US4989206A (en) 1988-06-28 1991-01-29 Storage Technology Corporation Disk drive memory
US5163131A (en) 1989-09-08 1992-11-10 Auspex Systems, Inc. Parallel i/o network file server architecture
WO1991004540A1 (en) 1989-09-08 1991-04-04 Auspex Systems, Inc. Multiple facility operating system architecture
US5124987A (en) 1990-04-16 1992-06-23 Storage Technology Corporation Logical track write scheduling system for a parallel disk drive array data storage subsystem
US5155835A (en) 1990-11-19 1992-10-13 Storage Technology Corporation Multilevel, hierarchical, dynamically mapped data storage subsystem
AU662973B2 (en) 1992-03-09 1995-09-21 Auspex Systems, Inc. High-performance non-volatile ram protected write cache accelerator system
US5581724A (en) 1992-10-19 1996-12-03 Storage Technology Corporation Dynamically mapped data storage subsystem having multiple open destage cylinders and method of managing that subsystem
EP0701716B1 (en) 1993-06-03 2002-08-14 Network Appliance, Inc. Method and file system for allocating blocks of files to storage space in a RAID disk system
US5963962A (en) 1995-05-31 1999-10-05 Network Appliance, Inc. Write anywhere file-system layout
US6138126A (en) 1995-05-31 2000-10-24 Network Appliance, Inc. Method for allocating files in a file system integrated with a raid disk sub-system
ATE409907T1 (de) 1993-06-03 2008-10-15 Network Appliance Inc Verfahren und vorrichtung zum beschreiben beliebiger bereiche eines dateisystems
JPH103440A (ja) 1996-06-14 1998-01-06 Fujitsu Ltd 計算機システム
US5897661A (en) 1997-02-25 1999-04-27 International Business Machines Corporation Logical volume manager and method having enhanced update capability with dynamic allocation of storage and minimal storage of metadata information
US6032216A (en) 1997-07-11 2000-02-29 International Business Machines Corporation Parallel file system with method using tokens for locking modes
US6021508A (en) 1997-07-11 2000-02-01 International Business Machines Corporation Parallel file system and method for independent metadata loggin
US5987477A (en) 1997-07-11 1999-11-16 International Business Machines Corporation Parallel file system and method for parallel write sharing
US5941972A (en) 1997-12-31 1999-08-24 Crossroads Systems, Inc. Storage router and method for providing virtual local storage
US6173293B1 (en) 1998-03-13 2001-01-09 Digital Equipment Corporation Scalable distributed file system
US6697846B1 (en) 1998-03-20 2004-02-24 Dataplow, Inc. Shared file system
US6868442B1 (en) 1998-07-29 2005-03-15 Unisys Corporation Methods and apparatus for processing administrative requests of a distributed network application executing in a clustered computing environment
US6324581B1 (en) 1999-03-03 2001-11-27 Emc Corporation File server system using file system storage, data movers, and an exchange of meta data among data movers for file locking and direct access to shared file systems
US6564252B1 (en) 1999-03-11 2003-05-13 Microsoft Corporation Scalable storage system with unique client assignment to storage server partitions
US6275898B1 (en) 1999-05-13 2001-08-14 Lsi Logic Corporation Methods and structure for RAID level migration within a logical unit
US20020049883A1 (en) 1999-11-29 2002-04-25 Eric Schneider System and method for restoring a computer system after a failure
US6502166B1 (en) * 1999-12-29 2002-12-31 International Business Machines Corporation Method and apparatus for distributing data across multiple disk drives
US20030188045A1 (en) * 2000-04-13 2003-10-02 Jacobson Michael B. System and method for distributing storage controller tasks
US6636879B1 (en) 2000-08-18 2003-10-21 Network Appliance, Inc. Space allocation in a write anywhere file system
US6671773B2 (en) 2000-12-07 2003-12-30 Spinnaker Networks, Llc Method and system for responding to file system requests
US6868417B2 (en) 2000-12-18 2005-03-15 Spinnaker Networks, Inc. Mechanism for handling file level and block level remote file accesses using the same server
US6931450B2 (en) 2000-12-18 2005-08-16 Sun Microsystems, Inc. Direct access from client to storage device
US6606690B2 (en) 2001-02-20 2003-08-12 Hewlett-Packard Development Company, L.P. System and method for accessing a storage area network as network attached storage
US7073044B2 (en) 2001-03-30 2006-07-04 Intel Corporation Method and apparatus for sharing TLB entries
US6643654B1 (en) 2001-06-25 2003-11-04 Network Appliance, Inc. System and method for representing named data streams within an on-disk structure of a file system
US6713630B2 (en) * 2001-08-03 2004-03-30 Basf Aktiengesellschaft Continuous preparation of substituted oxazoles
US6978283B1 (en) 2001-12-21 2005-12-20 Network Appliance, Inc. File system defragmentation technique via write allocation
US7039663B1 (en) 2002-04-19 2006-05-02 Network Appliance, Inc. System and method for checkpointing and restarting an asynchronous transfer of data between a source and destination snapshot
US7010528B2 (en) 2002-05-23 2006-03-07 International Business Machines Corporation Mechanism for running parallel application programs on metadata controller nodes
US7873700B2 (en) 2002-08-09 2011-01-18 Netapp, Inc. Multi-protocol storage appliance that provides integrated support for file and block access protocols
US20040139167A1 (en) 2002-12-06 2004-07-15 Andiamo Systems Inc., A Delaware Corporation Apparatus and method for a scalable network attach storage system
US20040122917A1 (en) 2002-12-18 2004-06-24 Menon Jaishankar Moothedath Distributed storage system for data-sharing among client computers running defferent operating system types
US7159093B2 (en) * 2002-12-20 2007-01-02 Veritas Operating Corporation Development of a detailed logical volume configuration from high-level user requirements
US7185144B2 (en) * 2003-11-24 2007-02-27 Network Appliance, Inc. Semi-static distribution technique
KR100508019B1 (ko) 2003-07-19 2005-08-17 한미약품 주식회사 고순도 1-안드로스텐 유도체의 제조 방법
US7412496B2 (en) 2003-08-22 2008-08-12 Emc Corporation Management of the file-modification time attribute in a multi-processor file server system
US7590807B2 (en) 2003-11-03 2009-09-15 Netapp, Inc. System and method for record retention date in a write once read many storage system
US7366837B2 (en) * 2003-11-24 2008-04-29 Network Appliance, Inc. Data placement technique for striping data containers across volumes of a storage system cluster
US7698289B2 (en) 2003-12-02 2010-04-13 Netapp, Inc. Storage system architecture for striping data container content across volumes of a cluster
US7409497B1 (en) 2003-12-02 2008-08-05 Network Appliance, Inc. System and method for efficiently guaranteeing data consistency to clients of a storage system cluster
US7302520B2 (en) 2003-12-02 2007-11-27 Spinnaker Networks, Llc Method and apparatus for data storage using striping
US7409494B2 (en) 2004-04-30 2008-08-05 Network Appliance, Inc. Extension of write anywhere file system layout
US20070088702A1 (en) 2005-10-03 2007-04-19 Fridella Stephen A Intelligent network client for multi-protocol namespace redirection

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003099210A (ja) * 2001-09-25 2003-04-04 Toshiba Corp 仮想的なｒａｉｄ装置を有するクラスタシステム及び同システム用のコンピュータ

Also Published As

Publication number Publication date
US20050192932A1 (en) 2005-09-01
JP2008539505A (ja) 2008-11-13
AU2005331262B2 (en) 2009-10-29
DE602005025702D1 (de) 2011-02-10
WO2006118592A1 (en) 2006-11-09
EP1875385B1 (en) 2010-12-29
IL186996A (en) 2012-01-31
CN101218583B (zh) 2012-07-04
AU2005331262A1 (en) 2006-11-09
US7698289B2 (en) 2010-04-13
IL186996A0 (en) 2008-02-09
ATE493714T1 (de) 2011-01-15
CN101218583A (zh) 2008-07-09
EP1875385A1 (en) 2008-01-09

Similar Documents

Publication Publication Date Title
JP4787315B2 (ja) データコンテナの中身をクラスタの複数のボリュームにわたってストライピングするためのストレージシステム・アーキテクチャ
JP5507670B2 (ja) ストライプ化ファイルシステムにおける能力平準化によるデータ分散
JP5068252B2 (ja) ストレージシステムクラスタの複数のボリュームにわたってデータコンテナをストライピングするためのデータ配置技術
JP5291456B2 (ja) ストレージシステム・アーキテクチャ内のデータ・アロケーション
US7904649B2 (en) System and method for restriping data across a plurality of volumes
US7743210B1 (en) System and method for implementing atomic cross-stripe write operations in a striped volume set
EP1875384B1 (en) System and method for multi-tiered meta-data caching and distribution in a clustered computer environment
US7698501B1 (en) System and method for utilizing sparse data containers in a striped volume set
US8301673B2 (en) System and method for performing distributed consistency verification of a clustered file system
US7334095B1 (en) Writable clone of read-only volume
US7827350B1 (en) Method and system for promoting a snapshot in a distributed file system
US8489811B1 (en) System and method for addressing data containers using data set identifiers
US8224777B2 (en) System and method for generating consistent images of a set of data objects
US8209289B1 (en) Technique for accelerating the creation of a point in time representation of a virtual file system
US7962689B1 (en) System and method for performing transactional processing in a striped volume set
US8001580B1 (en) System and method for revoking soft locks in a distributed storage system environment
US20190258604A1 (en) System and method for implementing a quota system in a distributed file system
JP4779012B2 (ja) 瞬時ボリューム復元のためのオン・デマンドでデータを復元するシステム、および方法
US7783611B1 (en) System and method for managing file metadata during consistency points
US10521159B2 (en) Non-disruptive automatic application regrouping

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101124

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110224

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110303

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110524

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110705

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110714

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140722

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees