(57)【要約】【課題】複数の作動中ノードを有するクラスタ・ファイル・システムにおいて、要求ノードが、障害発生後に、フェンスを解除しファイル・システムをマウントするのを効果的に防止する方法を提供する。【解決手段】該方法は、最初に、クラスタ中の一つの作動中ノードを格上げし、クラスタ・マネージャ・ノードとして機能させるステップを含む。クラスタ・マネージャは全ノードと連通している。クラスタ・マネージャにはマネージャ責任が割当てられ、この一部には、ファイル・システムをマウントすることを要求するノードからの作動中ステータス要求をまず受信する責任が含まれる。クラスタ・マネージャは、最初に、クォーラム・ノード群に問合わせを行い、各ノードが、該クラスタ・マネージャは現在もファイル・システムに対するクラスタ管理責任を有すると見なしているかどうかを判定する。クォーラム・ノード群の過半数が、クラスタ・マネージャは現在もファイル・システムに対するクラスタ管理責任を有すると見なしている場合は、該クラスタ・マネージャは、要求ノードからの作動中ステータス要求に応答する。しかる後、要求ノードはファイル・システムのマウント実施を進める。【選択図】図１
2010533324.tif 000002
【特許請求の範囲】
【請求項１】
複数の作動中ノードを有するクラスタ・ファイル・システムにおいて、要求ノードが、障害発生後にフェンス解除してファイル・システムをマウントするのを防止する方法であって、
前記方法は、
前記クラスタ中の一つの作動中ノードをクラスタ・マネージャ・ノードに格上げするステップと、
前記クラスタ中の作動中ノード群の過半数をクォーラム・ノードと定義するステップと
前記クラスタ・マネージャを前記クラスタ中の作動中ノード群と連通させるステップと、
前記クラスタ・マネージャに対し、
前記クラスタ中の前記要求ノードから作動中ステータス要求を受信する責任、
前記クォーラム・ノード群に、各ノードが、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしているかどうかを問合わせる責任、
クォーラム・ノード群の過半数が前記問合わせに応答したかどうかを判定する責任、および
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしている場合には、前記クラスタ・マネージャは前記要求ノードの作動中ステータス要求に応答する責任、
を一部として含む責任を割当てるステップと、
前記作動中ステータス要求に対する前記応答を受信した後、前記要求ノードが前記ファイル・システムをマウントするステップと、
を含む、前記方法。
【請求項２】
前記クラスタ中の他のノード群と連通している前記クラスタ・ノードは、ＳＣＳＩ−３の永続予約命令のサブセットを少なくとも一部に用いる、請求項１に記載の方法。
【請求項３】
前記要求ノードは、まず最初に、前記クラスタ・マネージャに、前記ファイル・システムをマウントする許可を与えるトークンを要求する、請求項１または２に記載の方法。
【請求項４】
前記クラスタ・マネージャ・ノードは、前記クラスタ中の作動中ノードのリストにさらにアクセスする、請求項１、２、または３に記載の方法。
【請求項５】
前記クォーラム・ノード群の過半数は、ノード障害が検知された後、動的に選定される、先行請求項のいずれかに記載の方法。
【請求項６】
前記クラスタ・マネージャは、前記クォーラム・ノード群への前記問合わせの間、作動中ステータス要求を待ち行列に入れる、先行請求項のいずれかに記載の方法。
【請求項７】
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有すると見なさない場合、前記クラスタ・マネージャは、前記要求ノードに対し、前記クラスタ・マネージャがもはや前記ファイル・システムに対する管理責任を有さないと回答する、先行請求項のいずれかに記載の方法。
【請求項８】
複数の作動中ノードを有するクラスタ・ファイル・システムにおいて、要求ノードが、障害の発生後にフェンス解除しファイル・システムをマウントするのを防止するための命令の一組を包含するマシン可読の媒体であって、
前記命令の一組は、
前記クラスタ中の一つの作動中ノードをクラスタ・マネージャ・ノードに格上げするステップと、
前記クラスタ中の作動中ノード群の過半数をクォーラム・ノードと定義するステップと
前記クラスタ・マネージャを前記クラスタ中の作動中ノード群と連通させるステップと、
前記クラスタ・マネージャに対し、
前記クラスタ中の前記要求ノードから作動中ステータス要求を受信する責任、
前記クォーラム・ノード群に、各ノードが、前記クラスタ・マネージャが現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしているかどうかを問合わせる責任、
クォーラム・ノード群の過半数が前記問合わせに応答したかどうかを判定する責任、および
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしている場合には、前記クラスタ・マネージャは前記要求ノードの作動中ステータス要求に応答する責任、
を一部として含む責任を割当てるステップと、
前記作動中ステータス要求に対する前記応答を受信した後、前記要求ノードが前記ファイル・システムをマウントするステップと、
を含む、前記マシン可読媒体。
【請求項９】
前記要求ノードは、前記作動中ステータス要求に対する前記応答を受信するまでは、ファイル・システムをマウントしない、請求項８に記載のマシン可読媒体。
【請求項１０】
前記クラスタ中の他のノード群と連通している前記クラスタ・ノードは、ＳＣＳＩ−３の永続予約命令のサブセットを少なくとも一部に用いる、請求項８または９に記載のマシン可読媒体。
【請求項１１】
前記要求ノードは、まず最初に、前記クラスタ・マネージャに、前記ファイル・システムをマウントする許可を与えるトークンを要求する、請求項８、９、または１０に記載の前記マシン可読媒体。
【請求項１２】
前記クォーラム・ノード群の過半数は、ノード障害が検知された後、動的に選定される、請求項８から１１のいずれかに記載のマシン可読媒体。
【請求項１３】
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有すると見なさない場合、前記クラスタ・マネージャは、前記要求ノードに対し、前記クラスタ・マネージャがもはや前記ファイル・システムに対する管理責任を有さないと回答する、請求項８から１２のいずれかに記載のマシン可読媒体。
【請求項１４】
要求ノードが、障害発生後にフェンス解除してクラスタ・ファイル・システムにファイル・システムをマウントするのを防止する、コンピュータ・ノード群の前記クラスタ・ファイル・システムであって、
前記システムは、
作動中ノードの過半数がクォーラム・ノードである、複数の作動中ノードと、
前記作動中ノード群と連通している、少なくとも一つのクラスタ・マネージャ・ノードと、
を含み、
前記クラスタ・マネージャの責任の一部には、
前記要求ノードから作動中ステータス要求を受信する責任と、
前記クォーラム・ノード群に、各ノードが、前記クラスタ・マネージャは現在前記ファイル・システムに対する管理責任を有する、と見なしているかどうかを問合せる責任と、
クォーラム・ノード群の少なくとも過半数が前記問合せに応答したかどうかを判定する責任と、
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在クラスタの管理責任を有すると見なしている場合には、前記クラスタ・マネージャは前記要求ノードの作動中ステータス要求に応答する責任と、
が含まれ、
前記作動中ステータス要求に対する前記応答を受信した後、前記要求ノードが前記ファイル・システムをマウントする、
前記クラスタ・ファイル・システム。
【請求項１５】
前記要求ノードは、前記作動中ステータス要求に対する前記応答を受信するまでは、ファイル・システムをマウントしない、請求項１４に記載のクラスタ・ファイル・システム。
【請求項１６】
前記クラスタ中の他のノード群と連通している前記クラスタ・ノードは、ＳＣＳＩ−３の永続予約命令のサブセットを少なくとも一部に用いる、請求項１４または１５に記載のクラスタ・ファイル・システム。
【請求項１７】
前記要求ノードは、まず最初に、前記クラスタ・マネージャに、前記ファイル・システムをマウントする許可を与えるトークンを要求する、請求項１５に記載のクラスタ・ファイル・システム。
【請求項１８】
前記クォーラム・ノード群の過半数は、ノード障害が検知された後、動的に選定される、請求項１４から１７のいずれかに記載のクラスタ・ファイル・システム。
【請求項１９】
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有すると見なさない場合、前記クラスタ・マネージャは、前記要求ノードに対し、前記クラスタ・マネージャがもはや前記ファイル・システムに対する管理責任を有さないと回答する、請求項１４から１８のいずれかに記載のクラスタ・ファイル・システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して分散型ファイル・システムに関し、さらに具体的には、クラスタ化ファイル・システム中のノードが、通信障害の後で、そのフェンス機能を解除してファイル・システムをマウントするのを、迅速且つ効率的に防止するシステムおよび方法に関する。
【背景技術】
【０００２】
通信技術の進展により、多数のマシンを、事実上制限のない処理能力と記憶容量とを持つコンピューティング・クラスタに統合し、単一のマシンで可能なよりもはるかに大きな問題を解くために使うことができるようになった。クラスタは、独立した、事実上冗長な数のコンピュータで構成されているので、これらは耐障害性の潜在能力を有する。このことは、これらを、信頼性が最重要課題である各種の問題処理に適するものとしている。このため、ここ数年クラスタ化技術に対し多大な関心が払われてきた。
【０００３】
この技術分野におけるクラスタ・ファイル・システムには、ＩＢＭ（Ｒ）のジェネラル・パラレル・ファイル・システム（ＧＰＦＳ：Ｇｅｎｅｒａｌ Ｐａｒａｌｌｅｌ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＩＢＭ社の商標））が含まれる。ＧＰＦＳは、ＲＳ／６０００（Ｒ）ＳＰ（ＩＢＭ社の商標）並列スーパーコンピュータおよびＬｉｎｕｘ（Ｒ）クラスタで利用可能な、クラスタ・コンピュータのための並列、共有ディスク・ファイル・システムであり、単一マシンで実行される汎用ポジックス（ＰＯＳＩＸ）ファイル・システムにできるだけ近付けた動きを備えている。（ＩＢＭ、ＧＰＦＳ、ＲＳ／６０００、およびＳＰは、米国、その他の国、またはその両方におけるＩｎｔｅｒｎａｔｉｏｎａｌＢｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ社の商標である。Ｌｉｎｕｘは、米国、その他の国、またはその両方におけるＬｉｎｕｓ Ｔｏｒｖａｌｄｓ社の商標である。）
【０００４】
クラスタの一つの欠点は、複数のマシンで実行するため、プログラムを区分けしなければならないことである。これらの区分けされたプログラムが、協働しまたは資源を共有するのに困難が生ずることがある。恐らく、最重要資源の一つはファイル・システムであろう。クラスタ・ファイル・システムがない場合、区分化プログラムの個別のコンポーネントは、その場その場に応じたやり方でクラスタ記憶装置を共用する。これにより、プログラミングが複雑になり、パフォーマンスが限定され、信頼性が低下する可能性がある。
【０００５】
一部のクラスタ・ファイル・システムは、クライアントのノードが、ファイル・データに沿ってデータ・サーバ群に格納されたディレクトリおよびファイル属性（分散メタデータ）などのメタデータに直接アクセスすることを可能にし、分散ロッキング・プロトコルを使って、これらメタデータの更新を同期させる。ＳＡＮ−ＦＳ、Ｌｕｓｔｒｅ、およびＰ−ＮＦＳなどの他のシステムは、一つ以上の専用メタデータ・サーバ・ノードを使って、メタデータを取り扱う。従来式ファイル・サーバに対するクラスタ・ファイル・システムの利点は、多くのデータ・サーバにデータを分散することによって、より大きな合計データ・スループットが得られることである。
【０００６】
従来式のスーパーコンピューティング・アプリケーションは、クラスタで実行されるとき、該クラスタ全体で共有されているファイル内に、複数のノードからの並列アクセスを必要とする。拡張可能ファイルおよびウェブ・サーバ並びに大型デジタル・ライブラリを含む、他のアプリケーションの多くは、ファイル間並列アクセスによって特徴付けられる。後者の種類のアプリケーションでは、個別ファイル中のデータは、必ずしも並行してアクセスされない。しかしながら、これらファイルは、共通ディレクトリに所在し、同一のディスク上にスペースを割当てるので、ファイル・システム・データ構造（メタデータ）については、前記にかかわらず並列的にアクセスされる。大型のコンピューティング・システムにおいては、ファイル・システムからのディスクの除去または追加、あるいは全ディスクに亘るファイル群の再バランス化といった管理上の処置ですら、多大な作業を要することがある。
【０００７】
クラスタ化ファイル・システムのディスク群は、該クラスタを構成しているノード群の一部または全部に亘って展開することができる。
【０００８】
多くのディスク・ドライブ・システムは、小型コンピュータ用周辺機器インタフェース（ＳＣＳＩ：ＳｍａｌｌＣｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）バスを使って、ホスト・コンピュータをコントローラに連結し、該コントローラとディスク・ドライブとを接続している。ＳＣＳＩは、ますます普及している、コンピュータと他のＩ／Ｏデバイスを相互接続するための通信プロトコル規格である。この接続のため、ＳＣＳＩは論理的に階層化されている。この階層化により、ファイバ・チャネルおよびエスエスエー（ＳＳＡ：ＳｅｒｉａｌＳｔｏｒａｇｅ Ａｒｃｈｉｔｅｃｔｕｒｅ）などのシリアル相互接続に基づいて、ソフトウエア・インタフェースをあまり変えることなく、新規の物理的相互接続スキームに対応することができる。ＳＣＳＩの初回バージョン（ＳＣＳＩ−１）は、ＡＮＳＩＸ３．１３１−１９８６に記載されている。ＳＣＳＩ規格は、ドライブの速度および容量が増大するにつれ、何回も改訂されてきた。ＳＣＳＩ−３規格は、機能をさらに向上し、高速シリアル伝送インタフェースに対応するよう設計されている。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ノード障害が検知されたとき、ノードが物理的に故障しているのか、あるいは、通信ネットワークに障害があり、実際には該ノードが好調に動作可能であるにもかかわらず故障しているように見えるのか不明確なことがある。その結果、検知時点から、障害ノードの状態が確実に判明し、該障害ノードが一切のＩ／Ｏを遂行することができないことが明確になるまで、ファイル・システムのログの修復を遅らせなければならなくなる。システムの複雑性が増しているので、ディスク・ドライブあるいはコントローラ・レベルにおいて中断障害が生ずることは、ますます不都合になってきている。その結果、システムは、さらに信頼できるものとなってきた。それでもなお、ユーザにとってディスク・ドライブ・システムが故障したりオフラインになったりするのは、これら問題が比較的迅速に是正されるとはいえ、単に不便であるにとどまらない。
【００１０】
高可用性クラスタ・マルチプロセッシングは、非同時モードで作動しているとき、ＳＣＳＩの予約／解除命令を使ってディスク記憶デバイスへのアクセスを制御することができる。ＳＣＳＩ−３の永続予約（ＰｅｒｓｉｓｔｅｎｔＲｅｓｅｒｖｅ）命令を使いマルチプル・パスを介する、論理ボリュームへの共有非同時アクセスが、米国特許第６，９５４，８８１号に記載されている。高稼働率のクラスタ・マルチプロセッシングは、ハードウエアまたはソフトウエア不具合の際、別ノードによるディスク記憶デバイスへの障害迂回アクセスの手段を提供する。
【００１１】
永続予約は、ＳＣＳＩ−３規格の命令およびコマンド・オプションの一組をいう技法であって、該技法は、特定の標的デバイスに対する予約ポリシーを、設定、先取り、問合わせ、およびリセットする能力を備えたＳＣＳＩ開始プログラムを提供する。永続予約命令により提供される機能は、予約／解除命令群のサブセットである。永続予約は、データの整合性、および大型ファイル・システムではしばしば要求される迅速な修復を提供するためには不十分である。
【００１２】
あるノードが、通信障害の後にそのフェンス機能を解除してファイル・システムをマウントするのを迅速且つ効率的に防止するシステムおよび方法が必要とされている。
【課題を解決するための手段】
【００１３】
本発明は、添付の特許請求項に定義されており、以降これを参照すべきである。
【００１４】
本方法の好適な実施形態は、ノードが、通信障害の後にそのフェンス機能を解除してファイル・システムをマウントするのを防止する。ノード群のクラスタに対するディスクＩ／Ｏを管理するため、クラスタ・マネージャ・ノードが選出される。クラスタ中のある動作中ノードがファイル・システムをマウントする前に、該ノードは、まず、クラスタ・マネージャ・ノードに遠隔手続呼び出し（ＲＰＣ：ＲｅｍｏｔｅＰｒｏｃｅｄｕｒｅ Ｃａｌｌ）を送信し、クラスタ・マネージャが、該要求ノードは該クラスタ内の作動中ノードであると現在見なしていることの証明を要求しなければならない。要求ノードは、処置実施の前に、クラスタ・マネージャから適切なトークンを受信するのを待つ。クラスタ・マネージャが要求ノードからＲＰＣを受信した後、だが適切なトークンを返信する前に、該クラスタ・マネージャは、クォーラム（クラスタ内定足数）ノード群にＲＰＣを送信する。クラスタ・マネージャは、これらクォーラム・ノード群が、該クラスタ・マネージャを、当該特定ファイル・システムに対するクラスタ・マネージャと現在見なしていることの証明を要求することになる。全クォーラム・ノードがしかるべく応答することになる。問合わせをした該クォーラム・ノード群から受信した応答に基き、これらノードが、該クラスタ・マネージャを、当該ファイル・システムの現在のクラスタ・マネジメントであると了解していると判定された場合、該クラスタ・マネージャは、要求ノードに、その作動中ステータス証明ＲＰＣを返信する。要求ノードが、クラスタ・マネージャから、該クラスタ・マネージャが要求ノードを（障害ノードでなく）作動中ノードであると見なす旨の応答を受信したならば、要求ノードは、そのフェンスを解除しファイル・システムをマウントする。他方、クラスタ・マネージャがクォーラム・ノード群から回答を受信しなかった場合、該クラスタ・マネージャは、何らかの形で該一群のノードとの連絡を喪失したか、あるいは、何らかの理由でそのクラスタ・マネージャとしての役割を格下げされたと想定する。この場合、クラスタ・マネージャは、当該クラスタ・マネージャ・ノードでないと返信し、要求ノードは、新しく選出されたクラスタ・マネージャ（選出が可能な場合）へのＲＰＣを再試行することになる。上記のクラスタ・マネージャ・ノードは、修復作業の開始／完了を待つ所定の状態に入るか、あるいは、別途、障害が発生したことを表す。上記のようなやり方で、ソフトウエアまたはハードウエアいずれかの障害により機能しなくなったと見なされたノードが、障害発生後にファイル・システムをマウントして、それによりデータが毀損されるのを迅速且つ効率的に防止する。
【００１５】
次に、例示目的だけのため、特定の例示実施形態に関連させて本発明を説明する。本発明の精神と範囲とを逸脱することなく、当業者はさまざまな変更および修正をこれに加えることができることを理解すべきである。
【００１６】
添付図面の別個の図面中の同じ参照番号は、同一のまたは機能的に類似のエレメントを示し、これらの図は、以下の詳細な説明とともに本明細書に組み込まれ、その一部を形成し、全て本発明によるさまざまな実施形態のさらなる例示、およびさまざまな原理および利点の説明に用立てられる。
【図面の簡単な説明】
【００１７】
【図１】本発明の新規特徴の使用目的の対象となるクラスタ化ファイル・システムの、共有ディスク・アーキテクチャを示す。
【図２】本発明の一つの実施形態を示す流れ図である。
【発明を実施するための形態】
【００１８】
作動中ノード群のクラスタ化ファイル・システムの中の障害を起こしたノードが、該ノードとクラスタ中の一つ以上のノードとの通信が断たれる障害の発生の後に、ファイル・システムをマウントしないことを確実にするための新規なプロトコルを構築する方法を提供する。該障害ノードがそのフェンスを解除してファイル・システムをマウントするのを、迅速且つ効率的に防止する。
【００１９】
当業者は、並列ファイル・システムに特有の概念、およびファイル／データ共有状況における並列処理の関連する概念については十分精通していよう。さらに、当業者は、クラスタ化ファイル・システム環境における、ノード、トークン、ロッキングなどに関連するコンピュータ・プログラミング技術に熟達しているであろう。
【００２０】
本明細書の目的の上で、マシン可読媒体とは、フレキシブル・ディスク、高容量読取り専用メモリ、光学的可読コンパクト・ディスクないしＣＤＲＯＭまたはＤＶＤ、テープ、デジタルまたはアナログ通信リンクなどの送信様式媒体、あるいは分野に一般的な同種の媒体などの製品をいう。
【００２１】
以下に記載する本発明の実施形態の説明をよりよく理解するために、本明細書で用いるいくつかの用語の簡単な概要を提示する。
【００２２】
ファイルとは、コンピュータ・アプリケーションがアクセス可能な、一連のビットを含む命名されたデータ・オブジェクトである。ファイルは、２〜３例を挙げると、長さ、変更日時、および最新のアクセス日時などの特定の属性を有する。
【００２３】
メタデータは、ファイル・システム・ソフトウエアによって、ファイルの構造、およびファイル・システムを包含するディスク群の使用を記述するため作成された制御構造として定義される。この種のファイル・システムに適用される特定様式のメタデータには、アイノード（ｉｎｏｄｅ）、ディレクトリ、割当てマップ、およびログが含まれる。アイノードは、ファイルの属性にプラスして、当該ファイルを構成するデータが含まれる、ディスクの領域に対する一連のポインタを包含する。ファイルが大きい場合、アイノードに追加のポインタを補足する間接ブロックによってアイノードを補うことができる。ディレクトリは、名称を、アイノードによって表される一組のデータに関連付ける制御構造である。割当てマップとは、特定のディスク領域、またはアイノードなど他の制御構造が使用中かあるいは利用可能状態かを示す制御構造である。これにより、ソフトウエアは、新規ファイルに対し、利用可能なブロックまたはアイノードを効率的に割当てることができる。ログは、障害が生じた場合のため、各種のメタデータを同期して保存するため用いられる記録をいう。これには、複数の構造に関連する更新事項を記載するする単一の記録が包含される。
【００２４】
ファイル構造とは、ディスク上の、データ・オブジェクトの編成体である。通常、ファイル構造には、ファイル・データ自体に加え、メタデータ、すなわち、ファイル名を対応するファイルにマップするディレクトリ、ファイルについての情報を包含するファイル・メタデータ、および、ファイル・データのディスク上の位置（すなわちどのディスク・ブロックが当該ファイル・データを保持しているか）も含まれる。これには、どのディスク・ブロックがメタデータおよびファイル・データの格納のため使用中であるかを記録する割当てマップ、および、ファイル構造についての全体的情報（例、ディレクトリ、割当てマップ、および他のメタデータ構造の場所）を包含するスーパーブロックが含まれる。
【００２５】
ファイル・システムは、他のアプリケーション・プログラムが、ディスク・ドライブなどの媒体上にデータを格納したり読出したりすることを可能にするコンピュータ・プログラムである。ソフトウエア・コンポーネントは、ファイル・データに関する一式のエックスオープン（Ｘｏｐｅｎ）およびポジックス規格によって規定されたやり方で、データへのアクセスを提供する、定義された一組のディスク群を管理する。また、ファイル・システムという用語は、特定の一組のディスク内に包含されたデータおよびメタデータ一式をも表す。簡明化のため、本明細書の以降の説明でディスクという用語を使っているが、その概念は、任意の類似のブロック構造化記憶媒体に適用される。ファイル・システムは、アプリケーション・プログラムが、ファイルを生成しそれらに名前を付けること、それらの中にデータを格納する（または書込む）こと、それらからデータを読出すこと、それらを削除すること、およびそれらファイルに他の操作を施すことを可能にする。
【００２６】
共有ディスク・ファイル・システムとは、一つ以上のディスクに所在するファイル構造が、別々のコンピュータで実行されている複数のファイル・システムからアクセスされるシステムである。これらコンピュータの全てピアであり、どのコンピュータも、データを管理するのに必要などのような役割をも遂行することができる。必要な場合、各特定のコンピュータにノードとしての特定の役割を割当てることができる。共有ディスク接続機構とは、ディスクが各ファイル・システムにローカルに接続されているように見えるプロトコルを使って、これらディスクを複数のコンピュータに接続する方法である。各コンピュータに対する接続機構プロトコルの厳密性は重要でなく、ネットワーク接続ディスク、交換ディスク接続機構、または格納および転送接続機構などさまざまな様式が含まれる。重要な事項は、その機構が、対象ファイル・システムにとってローカルに見え、該ファイル・システムの全てのインスタンスからも同様に見えることである。
【００２７】
クラスタを使用するファイル・システムおよびアプリケーションが実行されている該ノード群のクラスタは、スイッチング構造を介してディスク群またはディスク・サブシステム群に連結し、該クラスタ中のノードは、全てのディスクへのアクセス権を有する。ファイル・システム・コードは、アプリケーションが要求する読出しおよび書込みを管理する。この管理では、アプリケーションの要求とメタデータとを使って、ファイル・システム内のアクセス・データが生成される。この機能は、処理作業の大半を占め、多くの場合、クラスタ内の全てのコンピュータにおいて同一である。
【００２８】
一般に、クラスタ・ファイル・システムは、ノード群、データ・サーバ群、および一つ以上のメタデータ・サーバ、の一組から成る。クライアント・ノードは、ブロック・ストレージ・プロトコル（例、ＳＣＳＩ）、オブジェクト・ストレージ・プロトコル（例、Ｔ１０ＯＳＤ）またはファイル・アクセス・プロトコル（例、Ｐ−ＮＦＳ）を使い、ＳＡＮまたは他の通信ネットワーク（例、イーサネット（Ｒ）またはインフィニバンド（Ｒ））を介してデータ・サーバに格納されたデータにアクセスする。一般に、該クラスタ・システムは、ディスク側に特別なインテリジェンスのない、従来型のブロックＩ／Ｏインタフェースを前提としている。本明細書では、コンピュータ（またはノード）が、これらが共有メモリを有することが可能であり、あり得る多くの実装において、ローカル・メモリおよび少なくとも一部の共有メモリを有していたとしても、共有メモリを持たないことを前提とし、これらが、バスまたはスイッチング・ネットワークまたは他の何らかの通信ネットワークなど何らかの手段によって、ファイル構造が所在するディスク群に連結されていることを前提としている。これらノードが同様な手段によって相互に通信することをも前提としている。
【００２９】
クラスタ・ファイル・システムでは、大きなファイルは、通常、等しいサイズのブロックに分割され、連続するブロックが、通常、ラウンドロビン方式で相異なるディスク群に配置される。探索オーバーヘッドを最小化するため、ブロック・サイズは大きくされる。大きなブロックは、各ディスクから、一回のＩ／Ｏで大量のデータを読み出すことを可能にする。小さなファイル、および大きなファイルの終端部は、サブブロックと呼ばれるもっと小さなユニットに格納することができ、該ユニットは、フルサイズのブロックの１／３２またはそれ以下のサイズにすることができる。
【００３０】
図１に注目すると、これには、本発明の使用目的の対象となるクラスタ化ファイル・システムの、共有ディスク・アーキテクチャ１０が図示されている。図１のクラスタ化ファイル・システムは、一般に、集合的に１２で示されるコンピュータ（ノード）のクラスタで構成され、この上でアプリケーションが実行される。これらのノードは、集合的に１６で示される複数のディスクまたはディスク・サブシステムと、スイッチング構造１４を介して連通している。通常、クラスタ中の全ノードは全ディスクに対する同等なアクセス権を有する。
【００３１】
通常、ファイル群は、ファイル・システム中の全ディスクに亘ってストライプされる。複数のディスクに亘るデータのストライピングは、（例えば、あるファイルの）連続するデータ・ブロックを違ったディスクに格納するための技法である。ストライピングでは、ファイル・システムは、ファイルの連続するブロックを、ディスク番号０、…、Ｎ−１への何らかの巡回置換に従って異なるディスク群に書込む。ストライピングは、ディスクの負荷をバランスさせることに加え、ディスク・サブシステムの能力いっぱいのスループットを実現する。
【００３２】
ファイル・システム・ノードをディスク群に連結するスイッチング構造は、ストレージ・エリア・ネットワーク（ＳＡＮ：ｓｔｏｒａｇｅ ａｒｅａ ｎｅｔｗｏｒｋ）（例、ファイバ・チャンネルまたはｉＳＣＳＩ）で構成することができる。これに換えて、個別のディスクを、汎用通信ネットワーク上で実行されるソフトウエア層を介してファイル・システム・ノードからのアクセスを可能にする、いくつかのＩ／Ｏサーバ・ノードに接続させることもできる。
【００３３】
単一スレッドのアプリケーションから大きなファイルを読取るとき、ディスクの並列処理を利用するため、多くの場合、データは、バッファ・プールの中にプリフェッチされる。プリフェッチは、この技術で一般的な技法で、ファイル・システムでＩ／Ｏ待ち時間を低減するため使われる。これは、アプリケーションによってデータが要求されたとき、順次にアクセスされたファイルのブロックを前もって読出しておくことにより達成される。Ｉ／Ｏ要求は、スイッチング構造が可能な処理能力いっぱいを達成するため必要な数のディスクに、並行して発行される。同様に、もはやアクセスされないダーティ・データ・バッファも並行してディスクに書込まれる。このアプローチは、基調となるディスク・サブシステムおよびスイッチング構造がサポートしている、集合された速度で、単一のファイルへデータを読み書きすることを可能にする。
【００３４】
図１の共有ディスク実装は、データをディスクから使用するアプリケーションに往き来移動させるための最短の利用可能な経路を提供する。この経路には、データまたはメタデータのいずれに対するファイル・システム・サーバもない。隘路または障害発生点を回避する、任意の経路を使うことができる。
【００３５】
本発明をよりよく理解するために、ここで、並列ファイル・システムの関連する側面についての一般的な説明を提供する。これは、なじみのない読者に、本発明が関わる本主題についての基本的な理解を提供するためのものであることを理解すべきである。当業者は、これが簡単なものであり、本主題をさらに徹底して理解するためにはもっと包括的な学習が必要であることをよく理解していよう。シュマック（Ｓｃｈｍｕｃｋ）らの、米国特許．第５，８９３，０８６号、第５，９４０，８３８号、第５，９５０，１９９号、第５，９６３，９６３号、第５，９７４，４２４号、第５，９８７，４７７号、第５，９９９，９７６号、第６，０２１，５０８号、第６，０２３，７０６号、第６，０３２，２１６号、第７，１２０，６５０号、および第７，２１６，１３５号を含む一連の特許は、共有並列ディスク・ファイル・システムのさまざまな側面を記載している。
【００３６】
ファイル・システムは、一般に、個別ファイル名のエントリを有する複数のディレクトリを含む。読出しまたは作成されるファイルに対し、ファイル名が存在する場合はそれをディレクトリ中に見出さねばならいし、存在しない場合には、ディレクトリ・ブロックにそれを追加しなければならない。大きなファイル・システムには、各々が自分のファイル名を持つ、何百万もの個別ファイルを包含する非常に大きなディレクトリ群を備えることができる。非常に大きなディレクトリ中での効率的なファイル名の検索をサポートするため、多くの場合、拡張可能ハッシュ法を使って、各ディレクトリ内の複数のディレクトリ・エントリを体系化する。拡張可能ハッシュ法は標準的ハッシュ技法より進んだ技法であり、標準的技法では、最初からハッシュ・バケットの最大数が分かっていることが必要である。拡張可能ハッシュ法は、ハッシュ関数の値からの可変数のビットを用いることによって、この問題を解決する。
【００３７】
複数のディスク・ブロックを占めるディレクトリについては、ファイル名にハッシュ関数を適用しハッシュ値の低位ビットｎヶをブロック番号として用いて、特定の名前に対するディレクトリ・エントリを包含するブロックを見出すことができ、ｎは対象ディレクトリのサイズ如何により決まる。ディレクトリが大きくなってくると、拡張可能ハッシュ法は、一度にｌヶずつ新しいディレクトリ・ブロックを追加する。生成オペレーションにおいて、新規ファイル名のハッシュ値により指定されたディレクトリ・ブロック中に、もうスペースがないことが判明すると、オペレーションはそのブロックは２つに分割する。ハッシュ・バケットが分かれて、新規ハッシュ・バケットが追加され、記録の一部が、既存のハッシュ・バケットから新規バケットに移される。どの記録が写されるかは、ハッシュ関数を再評価し、ハッシュ・バケット番号を指定するもう一つの追加ビットを使って決められ、該追加ビット値が０の記録は、元のバケットに留まり、追加ビット値が１の記録は新規バケットに移される。該新規ディレクトリ・ブロックの論理ブロック番号は、旧ブロック・番号のｎ＋１のビット位置に「１」を加算することによって導き出され、ハッシュ値の該ｎ＋１ビットに「１」を有するディレクトリ・エントリは新規ブロックに移動される。それ以外のブロックは変わることなく留められる。
【００３８】
あるファイル・システムにおいて、通常ファイルに書込まれたデータは、多くの場合、ディスク上の一つ以上のディスク・ブロックに格納される。ＵＮＩＸ（Ｒ）およびＵＮＩＸ類似のファイル・システム・インタフェースは、ファイルの現在の終端を過ぎた後方に新規データを書込めるようにしている。（ＵＮＩＸは、米国およびその他の国におけるＴｈｅＯｐｅｎ Ｇｒｏｕｐの登録商標である。）このやり方は、ギャップないし「ホール」、すなわち、データが書込まれないファイル内の領域を有するファイルの生成を可能にする。こういったファイルは、しばしば、穴あきファイルと呼ばれる。穴あきファイルをサポートするファイル・システム実装は、データが書込まれたファイル領域にだけディスクの記憶域を効率的に割当て、ホール、もしくは、少なくとも、該ファイル・システムが使っているブロック・サイズまたはディスク割当ての単位より大きなホールに対しては割当てない。
【００３９】
拡張可能ハッシュ法に基く大ディレクトリは、まだ未分割のディレクトリ・ブロックを表現するファイル中にホールを有する、穴空きファイルとして表すことができる。該ディレクトリ・ファイル中の穴あき領域を点検することにより、ディレクトリ・ブロックがどの位の回数分割されてきたか、およびこれから、所与のファイル名を包含するディレクトリ・ブロックを配置するため、どの位の数のハッシュ値ビットを使うかを算定することができる。ディレクトリ・ファイルのサイズおよび構造に関わらず、検索オペレーションには、ディレクトリ・ブロックへの一回のアクセスが必要なだけである。読取りオフセットおよび長さがホールを横切る箇所では、穴あきファイルの読取りオペレーションはゼロに戻る。
【００４０】
ハッシュ・ツリーは、ディスク上の穴あきファイルとして表すことができる。ハッシュ・バケットが分割されるとき、記録は再配置される。各ハッシュ・バケットは、ファイル中のｉ＊ｓで与えられるオフセットに格納され、このｉはハッシュ・バケット番号（ゼロから開始）であり、ｓはそのハッシュ・バケットのサイズである。ディレクトリは、空のファイルとして開始される。最初の記録が挿入されると、それはハッシュ・バケット０に格納され、引き続いてファイルに書込まれ、該ファイルのサイズはゼロからｓまで増大する。ハッシュ・バケット０を分割する必要がある場合、ファイル・サイズをｓから２＊ｓに増大してバケット１が書込まれる。次のハッシュ・バケット分割では、ハッシュ・バケット２番または３番が書込まれることになり、これらに応じて次に最初の２つのバケットを分割することが必要となる。バケット１が次いで分割される場合、ファイル・サイズを２＊ｓから４＊ｓに増大し、オフセット２＊ｓにホールを有するファイルを残して、ハッシュ・バケット３番が書込まれることになり、残されたファイルには、ハッシュ・バケット２番が置かれることになる。該ファイル・サイズ、最長のハッシュ・ツリー分岐の深さ（最大の深さｄを有するハッシュ・ツリーにおいて、全てのハッシュ・バケット番号はｄビット以下であり、少なくとも一つのハッシュ・バケットは、第ｄ番のビットが１であるバケット番号を有していなければならない）が所与であれば、最大深さｄは、最大のハッシュ・バケット番号中のビットの数、ｆ／ｓ−１として計算することができる。ｆはファイル・サイズである。所与のキーを有する記録を検索するため、該所与のキーに対するハッシュ値の最下位ビット群、深さｄから、ハッシュ・バケット番号ｂが計算される。全てのハッシュ・ツリーの分岐が同じ深さの場合、当該キーによって与えられたハッシュ・バケット中の記録を見出せることが確かになろう。所与のキーを格納している分岐がｄより小さな深さを有することがあり、バケットｂが、該ハッシュ・ツリーに存在しないこともある。この場合には、ファイルは、オフセットｂ＊ｓにホールを有することになる。従って、ホールが見出された場合、１ビット少ないハッシュ値を使って、新しいバケット番号ｂ’を計算することができる。これにより、ハッシュ・ツリーがｄ−１の深さである場合に、記録の場所が得られよう。この手順は、ファイル中でホールに遭遇する限り繰り返される。非ホール域が検知されたならば、所与のキーを有する記録が存在するものならば、そのハッシュ・バケットに在るはずである。
【００４１】
上記の拡張ハッシュ法実施は、任意のハッシュ・バケット・サイズに対して機能するが、バケット・サイズが、ファイル・システムのブロック・サイズまたはブロック・サイズの倍数と等しければさらに効率的に機能することになろう。これは、ホールがファイル・システム・ブロックの境界に配列されていれば、そのホールを読取るためにいかなるディスクＩ／Ｏも必要とせず、穴あきファイルの実施が効率的になるからである。従って、全ての検索において、対象記録を保持して可能性のある実際のハッシュ・バケットが現在キャッシュされていない場合、該ハッシュ・バケットを読取るために一回だけのディスクＩ／Ｏが必要なだけである。なお、これは、ファイルのディスク・ブロックの位置を包含するファイル・メタデータがキャッシュされていることを前提としている。
【００４２】
また、割当てマップもファイル構造の一部であり、通常、一つ以上のディスク・ブロック中に所在するファイル構造の一部としてディスク上に格納されている。割当てマップは、ファイル・システム中の全ディスク・ブロックの割当てステータス（空きまたは使用中）を記録する。該マップは、望ましくは、大きな固定数ｎヶの別々にロック可能な領域に分割されている。各領域は、ファイル・システム中の各々のディスク上のディスク・ブロック群の１／ｎ番の割当てステータスを包含している。このマップ・レイアウトは、一度に一つの割当て領域だけにアクセスすることによって、割当てられたディスク・スペースが、全ディスク群に亘って適切にストライプされることを可能にしている。合計領域数は、望ましくは、ファイル・システムの生成時に、クラスタ中のノードの予測数に基いて設定される。
【００４３】
共有ディスク・ファイル・システムを構成するノード群が、その共有ディスクへのアクセスを適切に相互同期しなければ、これによりファイル構造が損壊されることになろう。このことは、特に割当てマップについて当てはまる。これを例証するために、空きブロックを割当てるプロセスを考えてみる。２つのノードが同時にあるブロックを割当てようとしたとする。これを行うプロセスにおいて、両ノードは、同一の割当てマップ・ブロックを読取り、両者は、空きブロック（ｉ，ｊ）を表す同一のエレメントＡ（ｉ，ｊ）を見出し、両者は、ブロック（ｉ，ｊ）が割当てられたことを示すためＡ（ｉ，ｊ）を更新し、両者は、該ブロックをディスクに再書込みし、両者は、ブロック（ｉ，ｊ）を異なる用途のため使うことになり、しかしてファイル構造の整合性を毀損することになろう。これらノードが、相異なるブロックＸおよびＹを同時に割当てたとしても、Ａ（Ｘ）とＡ（Ｙ）との双方が同一のマップ・ブロック中に包含されている場合、もっと微妙だが同様に重大な問題が生じる。この場合、第一ノードはＡ（Ｘ）を割当て設定し、第二ノードはＡ（Ｙ）を割当て設定し、両者は、それぞれのマップ・ブロックのバッファ・コピーをディスクに同時に書込む。どちらの書込みが先にされたかによって、ブロックＸあるいはＹのいずれかがディスク上のマップでは空きブロックに見えることになる。例えば、第二ノードの書込みが、第一ノードの書込みの後で実行された場合、ディスク上のマップでは、ブロックＸは空き状態になることになる。第一ノードは（例えば、あるファイルのデータ・ブロックを格納するために）ブロックＸを使用することになるが、上記書込み後に、別のノードが他の何らかの用途にブロックＸを割当てし、上記同様にファイル構造の整合性を毀損する結果となることが起こり得る。
【００４４】
ディスク・スペースを割当てるには、割当てマップの更新が必要であり、これはノード群の間で同期が取れていなければならない。割当てマップの編成は、同時にファイルに書き込みをしようとするノード間の干渉を大きく低減するが、いくつかの干渉は起こり得る。これは、ノードが、領域を切替える際に、切替え先領域の選択の基礎とすべき情報を一切持っていないという事実に起因する。理想的には、該ノードは、現在別のノードによって使われていない領域で、さらなる領域切替えをすることなく、連続して書き込みの可能な十分な大きさの空きブロックを有する領域に切替えるのがよい。ノードが領域のインフォームド選択をすることを可能にするための手段を提供するため、割当てマネージャを用いる。
【００４５】
各々のファイル・システムに対し、クラスタ中のノード群の一つが、全割当て領域についての空きスペースの統計データを維持する責任を負う。この割当てマネージャ・ノードは、ファイル・システムがマウントされる際に、割当てマップを読取って、空きスペース統計データを初期化する。該統計データは、各ノードが、最新期間中に割当てられたまたは解放されたディスク・スペースの正味容量を報告する定期的メッセージを介して、大まかな更新状態に維持される。全てのノードが個別に、空きスペースをまだ包含している領域を探索するのに換えて、各ノードは、現在使用している領域のディスク・スペースが不足したならば、当たってみる領域について、常に割当てマネージャに問合わせる。可能な程度において、割当てマネージャは、異なるノードには異なる領域を指定することによって、ノード間のロック競合を防止する。
【００４６】
上記により、ファイル生成のための割当てマップへのアクセスはローカライズされる。しかしながら、ファイルの削除も同様に割当てマップを更新するので、ファイル削除が頻繁な領域切替えをもたらし、これが、同時点でファイル書込みをしているノードに干渉する可能性がある。個別ファイル中のブロックが単一の領域にローカライズされたとしても、あるノードが、これと異なるノードによって、または違った時期に生成され、従って、異なる領域から割当てられたいくつかのファイル（例えば、ディレクトリの内容）を消去するというケースがまだ頻繁に生じることになる。数百のノード上で実行されるある並列プログラムによって生成されたあるファイルが、数百の領域にブロック群を割当ててしまうこともあり得よう。ファイルの削除には、これらの領域の各々を、おそらくはこれらに割当てをしているノードから取上げ、ロックして更新することが必要となり、パフォーマンスに悪影響を与える可能性がある。従って、ファイルが削除されたノードにおいて割当てマップ更新の全てを処理するのでなく、他のノードが使用中であることが判明している領域を書き換える更新は、それら使用ノードに実行のため送信される。割当てマネージャは、割当て解除要求の転送を容易にするため、どの領域がどのノードによって使用されているかについての手掛かり情報を定期的に配信する。
【００４７】
ファイル構造の毀損を回避するため、ノードは、各ビット・マップ・ブロックをメモリ中に読取る前に、該ブロックに対するトークンを得なければならない。ノードが（ブロックを割当てるまた解放することによって）ブロックを変更する場合、該ノードは、トークンを手放す前に、当該ブロックをディスクに書込まなければならない。トークンは、ノードがディスクから読み出したデータをキャッシュすることを可能にする。というのは、何処であれ、解除状態のトークンなくしてはデータを変更することはできないからである。
【００４８】
ノードに対しトークンを認可するため、多くの場合、複数のトークン管理サブシステムが用いられる。ロック・マネージャは、共有ディスク・ファイル・システムに必要な各種の修復パラダイムを取扱い、また、同一ファイルの並行更新を可能とするために必要なさらなるロック状態も加える。ロック・マネージャ中の必要な中央機能は、特定のコンピュータに付属していないので、これらはコンピュータからコンピュータへ移動し、パフォーマンスおよび利用上の必要性を満たすことができる。
【００４９】
トークン・マネージャ・サブシステムからトークンを取得し、ブロック上に保持されたトークンを開放する前に、ディスクにマップ・ブロックを書き戻すのためのオーバーヘッドが、共有ディスク・ファイル・システムのパフォーマンスを大きく損ずる可能性がある。トークン・マネージャは、クラスタ内の全ノードに対し認可した全てのロック・トークンを追跡する。トークンを取得し、手放し、格上げまたは格下げするには、トークン・マネージャへのメッセージが必要となる。ファイルの必要な部分だけを直接にロックするのは手数がかかり、あらゆるアプリケーション呼び出しについてトークン・マネージャへのコールが必要なことになろう。トークン管理コールの回数を最小化する試みが重要である。
【００５０】
ストライプされたファイルの連続したブロックを割当てるため、ノードは、ある領域に対するトークンを取得し、該領域中の空きブロック（すなわち、それらの割当てマップエレメントが空き状態を示しているブロック）を用いて、ストライピング順列に従い連続するブロックを割当てる。トークンを開放する前に、ノードは、該領域をディスクに書き戻す。あるブロックをそのディスクに割当てようとする際に、ノードが、領域を切替える場合には、該ノードは、該領域をディスクに書き戻し、トークンを解放した後、別の領域に対するトークンを取得し、該書込みから割当てを実施しようとする。ノードが、特定のディスク上に空きブロックを見出そうとして、その全領域を試みても見出せない場合、該ノードは（ファイル・システムのストライピングのやり方に応じ）、ブロックを別のディスクに割当てるか、あるいは、アプリケーションに対しスペースがない状態を返信することができる。前者の場合、全てのディスクに対する試みが失敗した場合、ファイル・システムは、スペースがない状態を返信する。パフォーマンスの向上策として、通常、ファイル・システムは、ファイル・ブロック書込みの合間に、他のノードが自己の領域のため当該トークンを流用できるようにすることになろう。トークン流用要求に応じ、当該ノードは、該領域をディスクに書込み、トークンを手放す。
【００５１】
ブロックの割当て解除をするため、ファイル・システムは、該ブロックを表している割当てマップを包含する領域を読込み、ブロックの状態を空きに更新し、該領域をディスクに書き戻した後にトークンを解放する。
【００５２】
トークン競合に起因するディスクＩ／Ｏのコストは、トークン・マネージャ・メッセージのコストの過半を占める。トークン・マネージャ・ノードへの高負荷に対する最も可能性の高い原因の一つは、トークン取り消しを引き起こすロック競合である。あるノードがトークンを格下げまたは手放すとき、そのトークンの対象となったダーティ・データまたはメタデータは、ディスクにフラッシュされるかまたはキャッシュから放棄されるか、あるいはその両方の処置がされる。従って、トークン・マネージャの負荷を軽減し、全体的なパフォーマンスを向上させる大いに効果的なやり方は、まず第一に、ロック競合を回避することである。
【００５３】
トークン・プロトコルを最適化し、トークン管理のコストをさらに低減し、応答時間を改善することができる。トークンを取り消すことが必要なとき、競合モードで該トークンを保持している全てのノードに、取り消しメッセージを送信し、それらノードからの返信を回収し、それを単一のメッセージとしてトークン・マネージャに転送するのは、取り消しをするノードの責任である。このようなやり方で、トークンの取得には、競合モードで対象トークンを保持しているノードがいくつあるかに関わらず、トークン・マネージャに２回を超えるメッセージが必要となることはほとんどないことになる。
【００５４】
クラスタ・ファイル・システムは、単一のノードが処理できる限界を超えたＩ／Ｏスループットの拡張を可能にする。ファイル・システムの整合性およびポジックスの動作を保持するためには、複数のノードからのデータおよびメタデータへのアクセスを同期させることが必要である。同期化は、ロッキングを分配することにより実現できる。分配型ロッキングは、異なったノードがデータ／メタデータの異なった構成部分で作動しているのであれば、集中型管理よりも多量の並列処理を可能にする。
【００５５】
分配ロック・マネージャは、各ファイル・システム・ノード中のローカル・ロック・マネージャとともに、クラスタ中のノードの一つで実行されている中央グローバル・ロック・マネージャを用いる。グローバル・ロック・マネージャは、ロックが取得されまたは解放される都度に別個のメッセージ交換をする必要なく、分配されたロックを認可する権利を搬送するロック・トークンを操作することによって、ローカル・ロック・マネージャ群の間でロックを調整する。
【００５６】
同一のノードからの同一のディスク・オブジェクトへの繰り返しアクセスについては、該オブジェクトに対するロックを確保する権利（ロック・トークン）を得るため、一回のメッセージが必要なだけである。ノードが、トークン・マネージャまたは「トークン・サーバ」または「ロック・マネージャ」からトークンを取得したならば、同じノードに発行された次のオペレーションは、追加のメッセージの必要なしに同じオブジェクトに対するロックを取得することができる。別のノードにおけるオペレーションが、同じオブジェクトに対し競合するロックを要求する場合においてだけ、第一ノードからロック・トークンを撤回し、それを他のノードに許諾できるようにするため、さらなるメッセージが必要となる。また、ロック・トークンは、ノード間のキャッシュの整合性を維持する役割をも果たす。ロック競合が頻繁に生じる場合、分配型ロッキングに対するオーバーヘッド負担は、中央ノードに要求を送信する方式のコストを上回る可能性がある。こういった場合、いろいろなノードから頻繁にアクセスされ更新されるデータまたはメタデータについては、競合する全てのオペレーションを、要求される読取りまたは更新オペレーションを遂行する指定のノードに転送するという、もっと集中化されたアプローチを用いてよりうまく管理することができる。
【００５７】
ロックを確保するには、通常はまずトークンの取得が必要となり、これがコストの高いオペレーションと考えられている。ファイルへのアクセス・パターンを予測することにより、ノードにてトークンをキャッシュすることは有益であろう。他方で、必要でないトークンの取得は、別のノードがそのトークンを必要とすることがあり、パフォーマンスを低下させることにもなろう。分配型バイト範囲ロックを使い、ファイル中の異なる領域へのアクセスを逐次化して、相異なるノード上のプロセスに並行して書込みをさせることができる。
【００５８】
バイト範囲ロッキングは、ファイル・データへの読み書きを同期化するために使われる。これは、アプリケーション群が並行して、ポジックスの読取り／書込みアトミック性動作を維持しながら、同一ファイルの異なる部分に同時に書込みすることを可能にする。ポジックス動作を必要としないアプリケーションは、バイト範囲ロッキングをバイパスし、トークン状態発行を回避するデータ転送を利用することができる。しかしながら、バイト範囲に対するトークンを、読取り／書込み呼び出しの持続期間の間取得し、しかる後それを開放することはロッキング・オーバーヘッドを増加させる可能性がある。
【００５９】
あるプロセスが、バイト範囲をロックする必要がある場合、該プロセスは、まず、然るべきバイト範囲トークンを取得する必要がある。バイト範囲トークン要求は、指定バイト範囲について、該要求を当該多ノード・システム全体における、既存の競合範囲と対比して分析され、別のコンピュータからトークンを撤回する必要なしに可能最大のバイト範囲が認可される。これにより、該要求ノードにおける次のオペレーションが別のトークンを要求する蓋然性は低下する。
【００６０】
バイト範囲トークンは、ファイルのある部分へのノードのアクセス権を表す。しかして、あるノードが、読取りモードで、ファイルＸの範囲（１００，２００）に対するバイト範囲トークンを保持していれば、そのことは、該ノードがファイルのその部分を安全に読取れることを意味している。しかしながら、トークンの流用を防止するために、該ノードは、実際の読取りの前にトークンをロックしなければならない。というのは、別のノードが同じ部分に書込みをする必要がある場合に、そのノードがトークンを流用するかもしれないからである。トークンをロッキングすることにより流用を防止する。読取りが完了した後、安全にトークンをロック解除することができる。
【００６１】
バイト範囲トークンは、以下のように取り決められる。トークン取り決めの過程では、現在処理されている書込みシステム呼出しのオフセットおよび長さに対応する必要範囲と、将来アクセスする可能性の高い所望範囲とを指定することにより、書込みオフセットについての情報が連絡される。順次アクセスにおいて、上記所望範囲は、現在の書込みオフセットから無限大まで間に設定される。トークン・プロトコルは、該必要範囲を競合するノードからだけバイト範囲を撤回することになる。次いで、トークン・サーバは、所望範囲中の、他のノードに現在保持されている範囲と競合しない、できるだけ大きなサブ範囲を認可することになる。
【００６２】
あるファイルに書込みをする最初のノードは、ファイル全体に対するバイト範囲（ゼロから無限大まで）トークンを取得することになる。他のノードからの同じファイルへのアクセスがない限り、ノード間の追加的なやりとりなしに、全ての読取りおよび書込みオペレーションが処理される。第二ノードが同一のファイルに書込みを開始するとき、該ノードは、第一ノードが保持しているバイト範囲トークンの少なくとも一部を取り消して貰う必要がある。第一ノードが取り消し要求を受信したとき、該ノードは対象ファイルがまだ使用中であるかどうかを点検する。該ファイルが既に閉じられている場合、第一ノードは全トークンを放棄し、これにより第二ノードはファイル全体を網羅するトークンを得ることができる。しかして、同時の書込み共有が実施されていなければ、バイト範囲ロッキングは、全体ファイル・ロッキングのごとくに機能する。このやり方は、一回のトークン交換でファイル全体にアクセスできるので効率的である。
【００６３】
第一ノードがファイルを閉じる前に第二ノードが書込みを始める場合、第一ノードは、そのバイト範囲トークンの一部だけを手放す。第一ノードがオフセット０１から、第二ノードはオフセット０２から、順次書込みをする場合、第一ノードは、そのトークンの０２から無限大まで（０２＞０１の場合）またはゼロから０２まで（０２＜０１の場合）を放棄することになる。これにより、さらなるトークン競合なしに、両方のノードはその現在の書込みオフセットから前方へ書込みを続けることができることになる。一般に、複数のノードが、同一のファイルのオーバーラップのないセクションに、順次書込みをする場合、各ノードは、最初の書込みオペレーションの一部として、一回のトークン交換によって必要なトークンを取得できることになる。
【００６４】
バイト範囲をロックしようとする場合、トークン・マネージャは、まず、当該ノードに適合するトークンが存在するかどうかの判定の問合わせを受ける。探査される範囲は、オペレーションが必要とする最小限の範囲である。トークンがローカルに利用可能な場合、それはロックされ、それ以上のトークン処理作業は行われない。しかしながら、トークンが利用可能でない場合は、トークン要求が行われる。必要範囲は、ファイル・オペレーションのオフセット位置と長さに基いて計算される。所望範囲は、該ファイルのアクセス・パターンに基く。該ファイルがランダムにアクセスされる場合、おそらくは他のノードからトークンを流用する何の利点もないので、所望範囲は必要範囲と等しいものとなろう。しかしながら、該ファイルが順次的にアクセスされる場合は、所望範囲は、必要範囲の開始点から開始されるが、その終了点は無限大となる（無限大を表現する特殊な値が使われる）。これは、将来のロックの必要性が（手掛かり情報から）予測可能なので、将来のトークン要求を最小化しようとする試みである。
【００６５】
あるノードが、別のノードによるトークン要求と競合するトークンを保持している場合、そのノードは撤回要求を受ける。該要求は、要求しているノードの必要範囲と所望範囲とを包含する。ここで、受け側ノードは、その範囲を手放せるか決定しなければならない。必要範囲が所望範囲と等しい場合は、決定は容易で、許諾する範囲は必要（且つ所望）範囲となる。しかしながら、所望範囲が必要範囲と異なる場合、このことは、要求しているノードがファイルに順次アクセスしようとしており、該ノードは、要求範囲の開始点から開始されるが終了点が無限大のトークンを得たい、と望んでいるということである。
【００６６】
この場合、受け側ノードは、対象ファイルにアクセスするその全ての作動中プロセスを調べ、それらが該ファイルに順次アクセスするのかあるいはランダムにアクセスするのかを点検する。これらの全てがファイルにランダムにアクセスするのであれば、該ノードは、所望範囲を許諾する。しかしながら、これらプロセスの一つ以上が当該ファイルに順次アクセスする場合は、高い蓋然性でどのトークンがすぐに必要となるか分かっているので、希望された範囲を手放すのは作業の浪費となろう。この場合、全ての順次オペレーションのファイル・ポインタ（すなわち、次のオペレーションが予期される位置）が調べられ、その最小オフセットが計算される。これらのオペレーションは順次的なので、この最小値よりも低いファイル領域にはアクセスがないことになる。許諾範囲は、計算された最小値が必要範囲より高ければ、その最小値まで伸張される。ファイル・アクセス・パターンに関連してトークンのキャッシングを可能にすることで、コストのかかるオペレーションであるトークンの取得作業が省かれ、これによりシステムの全体的パフォーマンスが向上する。
【００６７】
メタノード・マネージャは、共有ディスク環境において、並列読取りおよび書込みのため、メタデータをファイルする。ノードは、それらが読取りまたは書込み中、当該セクションに適切なロックを表示していれば、ファイルの相異なった領域の読取りおよび書込みを行うことができるが、これらの全ては同一のメタデータにアクセスする必要がある。メタノードは、メタデータへのアクセスを制御することにより、全ノードがファイルを確実にビューできるように読取り／書込みオペレーションを同期させる。
【００６８】
各ファイルに対し、該ファイルのメタデータへのアクセスとその更新に責任を有する単一のノードが指定される。ある特定のファイルに対するメタノードは、トークン・マネージャまたはトークン・サーバの助力を得て動的に選出される。メタノードは、メタデータが所在するディスク（またはディスク群）へのメタデータの出入りＩ／Ｏ処理を取り扱う責任を有する。他の全ノードは、メタデータ情報を取り出しまたは更新するため、該メタノードと交信する。これらノードは、ディスク上のメタデータに直接アクセスすることはしない。ノードはメタデータへのアクセスのためメタノードにアクセスする。メタノードは、かなりの量のディスク作業を節減する。
【００６９】
あるノードが最初にファイルにアクセスするとき、該ノードは該ファイル・ノードに対するメタノード・トークンを（メタノード・トークン・サーバから）取得しようとする。これを行うためのトークンが第一ノードに対し認可される。他のノードは、代わりにその認可されたメタノードの身元を知る。しかして、同時ファイル共有のない従来式の作業負荷においては、各ノードが自己が使用するファイルに対するメタノードとなり、全てのメタデータ更新をローカルに処理する。該メタノード上のファイルがもはやアクセスされなくなり、そのノード上のキャッシュからエージ・アウトされると、該ノードはそのメタノード・トークンを放棄し、メタノードとしての役割を止める。その後、該ノードが、別のノードからメタデータ要求を受信すると、該ノードは拒否回答を送信する。このとき、その別ノードは、メタノード・トークンを取得して、メタノード役を引き継ごうとする。あるファイルに対するメタノードは、該ファイルに活発にアクセスする一連のノード内に留まる傾向がある。
【００７０】
メタノードは、ディスク上のメタデータを反映する、メタデータのキャッシュ・コピーを保持する。また、他のノードも、それらが過去にメタノードから読取り必要に応じ増補してきた、メタデータのキャッシュ・コピーを保持する。各メタデータ・エレメントは、その固有の使用パターンと特殊な特性とを有する。
【００７１】
メタノードは、対象ファイルのメタデータについての情報を保持し、ディスクと該ファイルにアクセスする全てのノードとの間でスマート・キャッシュの役割を果たす。メタノードがこの機能を果たすことを中止する状況がある。円滑なオペレーションと修復とを可能にするために、こういった状況を処置する必要がある。今までメタノードにアクセスしていたノードは、簡明なやり方で新規のメタノードを選出する必要がある。この選出プロセスでは、対象ファイルへのアクセス・パターンが考慮に入れられる。一つの実施形態では、ファイルごとに一つだけのメタノードがある。
【００７２】
各ファイルに対し、メタノード・トークンが設定される。該メタノード・トークンに対し、典型的には３つのモードがある。すなわち「ｒｏ」（ｒｅａｄ−ｏｎｌｙ：読取り専用）、「ｗｗ」（ｗｅａｋ−ｗｒｉｔｅ：弱い書込み）、および「ｘｗ」（ｅｘｃｌｕｓｉｖｅ−ｗｒｉｔｅ：排他的書込み）トークンである。この規則では、「ｘｗ」トークンは、全モードと抵触する。「ｗｗ」は「ｘｗ」およびそれ自体と抵触する。「ｒｏ」は「ｘｗ」とだけ抵触する。しかして、２つの可能性がある。すなわち、０ヶまたは１ヶ以上のノードが「ｒｏ」トークンを保持し、このとき最多でも１ヶのノードが「ｗｗ」トークンを保持することができるケース、あるいは、単一のノードが「ｘｗ」トークンを保持するケースである。ノードがあるファイルを最初に開くとき、該ノードは、「ｗｗ」モードのメタノード・トークンを取得しようとする。トークン・マネージャは、他に「ｗｗ」または「ｗｘ」のトークンを保持しているノードがない場合、「ｗｗ」トークンを認可する。こうなれば、該ノードはメタノード・マネージャとなる。しかしながら、別のノードが「ｗｗ」トークンを保持している場合は、トークン・マネージャは「ｒｏ」のトークンを認可する。このとき、被認可ノードは、別のノードがメタノードであることを知る。該ノードは、トークン・マネージャに、どのノードが当該ファイルに対するメタノードであるかを問合わせることができる。
【００７３】
あるノードがメタノードにならなければならない状況がある。この場合、「ｗｗ」トークンの要求は、従来のメタノードがそのトークンを格下げしないので役立たない。そこで、メタノードになることを望むノードは、「ｘｗ」トークンを要求する。これにより、撤回メッセージが既存のメタノードに送信されることになる。旧メタノードは、これを受け、そのトークンを「ｒｏ」に格下げし、次いで、トークン・マネージャが新規のメタノードに「ｗｗ」トークンを返信することになる。あるノードが「ｘｗ」トークンを要求し、このトークンを保持するノードが全くなければ、トークン・マネージャは、このモードのトークンを認可することになる。あるノードが「ｘｗ」のトークンを保持していれば、そのノードは、対象ファイルに対するメタノードであるが、加えて、他のどのノードも該ファイルを開いていないこと。この場合、あるノードが「ｗｗ」トークンを取得しようと試みると、該メタノードに対し撤回メッセージが送信される。その結果、ノードはその「ｘｗ」トークンを「ｗｗ」に格下げし、トークン・マネージャは、しかして新規ノードに「ｒｏ」トークンを認可することができる。
【００７４】
どのノードも、特定のモードの指名トークンを要求することができる。トークン・マネージャは、該モードが、他のノードに認可された同一名のトークンと抵触しなければ、そのノードに対しトークンを認可する。各トークンに対し、取り得るモードのリストおよび競合表がある。要求されるトークンが、別のノードに認可されたトークンと抵触する場合、撤回が行われ、競合するノードは、そのトークン・モードを、要求されたモードと競合しないモードに格下げする。トークン・マネージャは、該モードが他のノードに認可された同一名のトークンと抵触しなければ、そのノードに対しトークンを認可する。
【００７５】
大きなファイル・システムでは、ファイル・システムがマウントされる都度、または、クラスタ中のノードの一つが作動停止する都度、ファイル・システムの整合性を検証／修復するためのファイル・システム・チェック（ｆｓｃｋ：ｆｉｌｅ  ｓｙｓｔｅｍ  ｃｈｅｃｋ）を実行することは実際上可能でない。その代わりに、ファイル・システムの整合性に影響する全てのメタデータの更新が、ジャーナルまたは先書きログに記録される。
【００７６】
各ノードは、それがマウントした各ファイル・システムに対する別々のログを有する。このログは当該ファイル・システムの中に格納される。このログは、他の全てのノードが読むことができるので、障害を起こしたノードになり代わってどのノードも修復を行うことができる。障害ノードが復帰するのを待つ必要はない。ノードの故障の後は、単に、障害ノードのログ中に記録された全ての更新事項を再適用することによって、ファイル・システムの整合性を迅速に修復することができる。例えば、新規のファイルを作成するためには、新規ファイルのディレクトリ・ブロックおよびｉノードの更新が必要である。該ディレクトリ・ブロックおよびｉノードに対するロックを確保した後、この双方はバッファ・キャッシュ中で更新され、該双方の更新を記載したログ記録がスプールされる。修正されたｉノードまたはディレクトリ・ブロックをディスクに書き戻す前に、対応するログ記録をディスクに格納しなければならない。これにより、ノードが、ディレクトリ・ブロックを書込んだ後、だがｉノードがディスクに書込まれる前に故障した場合、該ノードのログによって、失敗したｉノード更新のやり直し実施が保証される。ログ記録に記載された更新事項がディスクに書き戻されたならば、そのログ記録はもはや必要でなく廃棄することができる。ダーティ・メタデータをバックグラウンドのディスクにフラッシュ・バックすることにより、いつでもログ中のスペースを空けることができるので、ログを固定サイズにすることができる。
【００７７】
ログ修復が完了した後、他のノードは、障害ノードが保持していた任意のメタノード・トークンを取得でき、しかしてメタノードの役割を肩代わりすることができる。別のノードが、メタデータの更新を旧メタノードに送信したが、故障の時点であって、その更新をディスクに書き留めたとの確認応答が受信されなかった場合、該ノードは、その更新を新規のメタノードに再送信する。新規メタノードは、これらの更新事項を再適用することができる。
【００７８】
トークン・マネージャに障害がある場合、別のノードがその責任を肩代わりして、残存する全ノードに、それらが現在保持しているトークンについて問合わせすることによって、トークン・マネージャ状態を再構築することになる。新規トークン・マネージャは、どのようなトークンが障害ノードに保持されていたか不知であるため、ログの修復が完了するまでは、いっさいの新規トークンを認可しないことになる。残存するノードによって現在保持されているトークンは影響を受けない。
【００７９】
同様に、障害ノードが実施していた他の特別な機能（例、割当てマネージャ）も別のノードに割当てることができ、該ノードは、ディスクから情報を読取りまたは他のノードに問合わせ、あるいはその両方を行うことによって必要な状態を再構築する。
【００８０】
ノード障害は、定期的な短時間メッセージによってノードおよび通信リンクをモニタし、グループ・メンバーシップ・プロトコルを実施するグループ・サービス・レイヤによって検知される。あるノードが障害を起こしたとき、グループ・サービス・レイヤは、残りのノードに対し、グループ・メンバーシップの変化を連絡することができる。次いで、これにより、必要な一切の修復処置が開始される。ノードが障害を起こすと、ファイル・システム・マネージャが、データの毀損を防止するためディスクへのアクセスをフェンスすることになる。
【００８１】
以下のシナリオを考察してみる。ノード１は、ファイル・システムをマウントすることを意図している。ノード１は、遠隔手続呼出し（ＲＰＣ：Ｒｅｍｏｔｅ ＰｒｏｃｅｄｕｒｅＣａｌｌ）をファイル・システム・マネージャに送信し、ファイル・システムをマウントするためのしかるべき許可トークンを要求する。ファイル・システム・マネージャは、ＲＰＣを受信し、適正な許可トークンをノード１に返送する。ここで、該許可トークンがノード１に返送される前に、ネットワークに障害が生じ、ノード１と、クラスタ中の一つ以上の作動中ノードとの通信が途切れたと仮定する。ファイル・システム・マネージャは、ノード１との通信が失われたのを認識し、ノード１のディスク・アクセスを阻止（フェンス）する。だが、ノード１は、障害発生の前に送信された許可トークンを受信する。適正な許可を受信し、ノード１は、今や、自体をフェンス解除し、ファイル・システムを構成するディスクに書込みを開始してよいと判断する。一方、クラスタ中の他のノードは、ノード１は、ディスク・アクセスから完全に閉め出されたと考える。他の作動中のノードが、ノード１と同じディスクに書込みを開始すると、このとき、データの毀損が生ずることになる。
【００８２】
ある好適な実施形態において、本発明の方法は、当技術分野に既存のＳＣＳＩ−３の永続予約命令の一組を使って実施される。
【００８３】
一つの実施形態において、クラスタ中の一つのノードが、該クラスタにおいてノード管理責任を有するクラスタ・マネージャに指定される。該クラスタ・マネージャは、クラスタ中の全作動中ノードと連通している。クラスタ・マネージャ自体も作動中ノードの一つである。クラスタ・マネージャの管理責任の一部には、クラスタ中のどのノードが作動中であるかを検証すること、および、それら作動中ノードに、作動中ノードのクォーラムが、該クラスタ・マネージャは現在該クラスタに対するマネージャであると考えているかどうか、確認するための問合わせをすることが含まれる。本発明を最善に説明するため事例を用いる。
【００８４】
図２に注目すると、本発明の一つの実施形態が例示されている。
【００８５】
ノード１があるファイル・システムをマウントしたく望んでいると仮定する。ノード１は、クラスタ・マネジメントに遠隔手続呼び出し（ＲＰＣ）を送信し、ファイル・システムをマウントするためのしかるべき許可トークンを請求する。クラスタ・マネージャは、ノード１に適正な許可トークンを送信する。要求したノード１が許可トークンを受信した後、だがノード１は自体をフェンス解除してファイル・システムをマウントする前の時点で、ステップ２０において、ノード１は、クラスタ・マネージャにＲＰＣを送信し、該クラスタ・マネージャ・ノードがノード１を作動中ノードと見なしているとの証明を要求する。この間、ノード１は、クラスタ・マネージャから適切な応答を受信するまでは何もしない。ノード１が適切な応答を受信した後、該ノードは、自体のフェンス解除およびファイル・システムのマウントへと進む。ノード１がクラスタ・マネージャとの交信を喪失している場合、クラスタ・マネージャは、作動中ステータス証明を要求するＲＰＣを受信せず、従って、適切に応答しない。但し、代わりに、根底的な通信メカニズムによって、該クライアント・ノードにＲＰＣが送信できなかったことを示すことはできよう。
【００８６】
本発明の方法により、クラスタ・マネージャ・ノードがノード１の作動中ステータス証明の要求に応答する前に、ステップ２２において、クラスタ・マネージャは、それ自体のＲＰＣ問合わせをクォーラム・ノード群に対し送信し、それらクォーラム・ノード群が、当クラスタ・マネージャは現在当該ファイル・システムに対する管理責任を有する、と見なしていることの証明を要求する。クラスタ・マネージャは、クラスタ中のクォーラム・ノード群の過半数から応答を受信するまでは、要求ノード１のＲＰＣに対する応答は行わない。ステップ２４において、クォーラム・ノード群はクラスタ・マネージャの問合わせに応答する。ステップ２６において、受信した応答に基き、クラスタ中のクォーラム・ノード群の過半数が、該クラスタ・マネージャは現在実際に当該ファイル・システムのマネージャである、と応答してきた場合は、次にステップ２８において、クラスタ・マネージャは、ノード１の作動中ステータス証明のＲＰＣに対しノード１が現在作動中であると見なされていることを回答する。
【００８７】
他方、クラスタ・マネージャが、クラスタ中の一部のクォーラム・ノードからだけ回答を貰った場合は、クラスタ・マネージャは、何らかの破局的障害があったと想定する。ステップ３０において、クラスタ・マネージャは、要求ノードに対し、自分が現在クラスタ・マネージャでないと回答する。この時点で、要求ノードは、どのノードが新しいクラスタ・マネージャかを知る必要があり、新規の要求を開始する。新規クラスタ・マネージャの選出、およびその新情報のクラスタ中の作動中ノードへの伝達のためのメカニズムは従来技術に存在する。ステップ３２において、クラスタ・マネージャは、修復プロトコルを実施する。修復プロトコルは、障害の性質に如何による。一つの実施形態では、クラスタ・マネージャ・ノードは、さらなる命令を待ち受ける。別の実施形態では、クラスタ・マネージャは、ユーザの介入を待ち受ける。他方、クラスタ・マネージャがクラスタ中のどのノードからも回答を受信しなかった場合、該クラスタ・マネージャ・ノードは、自分がもはやクラスタ内の他の作動中ノードと連通していないので、通信障害の悪影響を受けたに相違ないと想定する。クラスタ・マネージャ・ノードは、望ましくは、ＲＰＣ要求群を待ち行列にしている。この場合、クラスタ・マネージャ・ノードは、待ち行列に入れたどのＲＰＣにも応答しない。ここで留意すべきことは、本発明の技法は、クラスタ・マネージャ・ノードがディスクへの書込みを所望しており自分が現在作動中と考えているのに、クラスタの他のノードとの交信を喪失しているケースについてもうまく処置することである。一つの実施形態において、クラスタ・マネージャは、自分のクラスタ・マネージャとしてのステータスを格下げし、ノード障害プロトコルを実施する。別の実施形態では、クラスタ・マネージャは、システム修復プロセスからの連絡、あるいは、ユーザの介入を待つ。
【００８８】
さらに別の実施形態において、作動中のノード群がそれらのクラスタ・マネージャ・ノードとの交信を喪失したので、これら作動中ノードは、所与のプロトコルを実施し、新しいクラスタ・マネージャとしての機能を果たしてくれる、クラスタ中の別のノードを選出（格上げ）することに合意する。この場合、ファイル・システムは継続して正常な機能を果たしながら、修復プロセスが、該クラスタ・マネージャに何が起こったかを判定し、そのノードを修理するかあるいは他の方法でそれをオンラインに回復させる。別の実施形態では、上記作動中ノード群は、該クラスタ・マネージャ・ノードがオンラインに回復した後、それにクラスタ管理責任を返還する。別の実施形態では、これら作動中ノード群は、ユーザの介入を待つ。
【００８９】
本発明の新規のアプローチにより、システム・オーバーヘッド負担に悪影響を与えることなく、ファイル・マウント中のファイル・システムの整合性が確保される。
【００９０】
過度な実験をしなくても、当業者は、彼ら自身の特定のファイル・システム構成の中で、本明細書の好適な実施形態において開示されたＳＣＳＩ−３の永続予約命令を活用する技法を容易に実施できることを理解すべきである。
【００９１】
本発明の例示的実施形態の前述の説明は、例示と説明とを目的として提示したものである。これらは、包括的な説明、あるいは本発明を開示されたとおりの形態に限定することを意図したものではない。前述の教示を踏まえ、多くの変更および変形を行うことができる。記載外のソフトウエアおよびハードウエア実装も、請求された本発明の範囲に含まれる。
【００９２】
本発明の特定の実施形態を開示したが、当業者は、本発明の精神および範囲から逸脱することなく、これら特定の実施形態に対し変更を加えるのが可能であることを理解していよう。従って、本発明の範囲は、これら特定の実施形態に限定されるものではない。さらに、添付の特許請求項には、本発明の範囲内のかかるあらゆる用途、変更、および実施形態を網羅することが意図されている。
【００９３】
疑問の生じないように、本明細書の説明および請求項を通して用いられている「含む（ｃｏｍｐｒｉｓｉｎｇ）」という用語は「だけを含む（ｃｏｎｓｉｓｔｉｎｇｏｎｌｙ ｏｆ）」意味と解釈しないものとする。
【図１】
2010533324.tif 000003
【図２】
2010533324.tif 000004
【手続補正書】
【提出日】平成22年3月31日(2010.3.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数の作動中ノードを有するクラスタ・ファイル・システムへのファイル・システム・マウンティングの方法であって、
前記方法は、
前記クラスタ中の一つの作動中ノードをクラスタ・マネージャ・ノードに指定するステップと、
要求ノードから前記クラスタ・マネージャ・ノードに対し、前記ファイル・システムをマウントする要求を発行するステップと、
前記クラスタ中の作動中ノード群の過半数をクォーラム・ノードと定義するステップと
前記クラスタ・マネージャを前記クラスタ中の作動中ノード群と連通させるステップと、
前記クラスタ・マネージャに対し、
前記クラスタ中の前記要求ノードから作動中ステータス要求を受信する責任、
前記クォーラム・ノード群に、各ノードが、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしているかどうかを問合わせる責任、
クォーラム・ノード群の過半数が前記問合わせに応答したかどうかを判定する責任、および
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしている場合には、前記クラスタ・マネージャは前記要求ノードの作動中ステータス要求に応答する責任、
を一部として含む責任を割当てるステップと、
前記要求ノードが、前記作動中ステータス要求に対する前記応答の受信後においてだけ、前記ファイル・システムをマウントするステップと、
を含む前記方法。
【請求項２】
前記クラスタ中の他のノード群と連通しているクラスタ・ノードは、ＳＣＳＩ−３の永続予約命令のサブセットを少なくとも一部に用いる、請求項１に記載の方法。
【請求項３】
前記要求ノードは、まず最初に、前記クラスタ・マネージャに、前記ファイル・システムをマウントする許可を与えるトークンを要求する、請求項１または２に記載の方法。
【請求項４】
前記クラスタ・マネージャ・ノードは、前記クラスタ中の作動中ノードのリストにさらにアクセスする、請求項１、２、または３に記載の方法。
【請求項５】
前記クォーラム・ノード群の過半数は、ノード障害が検知された後、動的に選定される、先行請求項のいずれかに記載の方法。
【請求項６】
前記クラスタ・マネージャは、前記クォーラム・ノード群への前記問合わせの間、作動中ステータス要求を待ち行列に入れる、先行請求項のいずれかに記載の方法。
【請求項７】
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有すると見なさない場合、前記クラスタ・マネージャは、前記要求ノードに対し、前記クラスタ・マネージャがもはや前記ファイル・システムに対する管理責任を有さないと回答する、先行請求項のいずれかに記載の方法。
【請求項８】
複数の作動中ノードを有するクラスタ・ファイル・システムにおいて、要求ノードが、障害の発生後にフェンス解除しファイル・システムをマウントするのを防止するための、プログラムを記録した、コンピュータ可読媒体であって、前記プログラムがコンピュータに、
前記クラスタ中の一つの作動中ノードをクラスタ・マネージャ・ノードに格上げするステップと、
前記クラスタ中の作動中ノード群の過半数をクォーラム・ノードと定義するステップと
前記クラスタ・マネージャを前記クラスタ中の作動中ノード群と連通させるステップと、
前記クラスタ・マネージャに対し、
前記クラスタ中の前記要求ノードから作動中ステータス要求を受信する責任、
前記クォーラム・ノード群に、各ノードが、前記クラスタ・マネージャが現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしているかどうかを問合わせる責任、
クォーラム・ノード群の過半数が前記問合わせに応答したかどうかを判定する責任、および
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有する、と見なしている場合には、前記クラスタ・マネージャは前記要求ノードの作動中ステータス要求に応答する責任、
を一部として含む責任を割当てるステップと、
前記要求ノードが、前記作動中ステータス要求に対する前記応答の受信後においてだけ、前記ファイル・システムをマウントするステップと、
を実行させる、コンピュータ可読媒体。
【請求項９】
前記クラスタ中の他のノード群と連通しているクラスタ・ノードは、ＳＣＳＩ−３の永続予約命令のサブセットを少なくとも一部に用いる、請求項８に記載のコンピュータ可読媒体。
【請求項１０】
前記要求ノードは、まず最初に、前記クラスタ・マネージャに、前記ファイル・システムをマウントする許可を与えるトークンを要求する、請求項８または９に記載の前記コンピュータ可読媒体。
【請求項１１】
前記クォーラム・ノード群の過半数は、ノード障害が検知された後、動的に選定される、請求項８から１０のいずれかに記載のコンピュータ可読媒体。
【請求項１２】
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有すると見なさない場合、前記クラスタ・マネージャは、前記要求ノードに対し、前記クラスタ・マネージャがもはや前記ファイル・システムに対する管理責任を有さないと回答する、請求項８から１１のいずれかに記載のコンピュータ可読媒体。
【請求項１３】
要求ノードが、障害発生後にフェンス解除してクラスタ・ファイル・システムにファイル・システムをマウントするのを防止する、コンピュータ・ノード群の前記クラスタ・ファイル・システムであって、
前記システムは、
作動中ノードの過半数がクォーラム・ノードである、複数の作動中ノードと、
前記作動中ノード群と連通している、少なくとも一つのクラスタ・マネージャ・ノードと、
を含み、
前記クラスタ・マネージャの責任の一部には、
前記要求ノードから作動中ステータス要求を受信する責任と、
前記クォーラム・ノード群に、各ノードが、前記クラスタ・マネージャは現在前記ファイル・システムに対する管理責任を有する、と見なしているかどうかを問合わせる責任と、
クォーラム・ノード群の少なくとも過半数が前記問合わせに応答したかどうかを判定する責任と、
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在クラスタの管理責任を有すると見なしている場合には、前記クラスタ・マネージャは前記要求ノードの作動中ステータス要求に応答する責任と、
が含まれ、
前記作動中ステータス要求に対する前記応答を受信した後、前記要求ノードが前記ファイル・システムをマウントし、前記要求ノードは、前記作動中ステータス要求に対する前記応答を受信するまではファイル・システムをマウントしない、
前記クラスタ・ファイル・システム。
【請求項１４】
前記クラスタ中の他のノード群と連通しているクラスタ・ノードは、ＳＣＳＩ−３の永続予約命令のサブセットを少なくとも一部に用いる、請求項１３に記載のクラスタ・ファイル・システム。
【請求項１５】
前記要求ノードは、まず最初に、前記クラスタ・マネージャに、前記ファイル・システムをマウントする許可を与えるトークンを要求する、請求項１３に記載のクラスタ・ファイル・システム。
【請求項１６】
前記クォーラム・ノード群の過半数は、ノード障害が検知された後、動的に選定される、請求項１３から１５のいずれかに記載のクラスタ・ファイル・システム。
【請求項１７】
前記クォーラム・ノード群の過半数が、前記クラスタ・マネージャは現在前記ファイル・システムに対するクラスタ管理責任を有すると見なさない場合、前記クラスタ・マネージャは、前記要求ノードに対し、前記クラスタ・マネージャがもはや前記ファイル・システムに対する管理責任を有さないと回答する、請求項１３から１６のいずれかに記載のクラスタ・ファイル・システム。
【国際調査報告】
2010533324.tif 000005
2010533324.tif 000006
2010533324.tif 000007