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