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