JP4204769B2 - フェールオーバを処理するシステムおよび方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、クラスタ化情報技術環境内で分散されているデータ記憶リソース間で共用される情報の管理という分野に関し、より具体的には、このような疎結合ノード・クラスタで使用する共用ディスク・ファイル・システムのデータ管理のフェールオーバ回復を処理するための方法およびシステムに関する。
【０００２】
【従来の技術】
大規模またはネットワーク化したコンピューティング環境を備えた企業では、分散ファイル・システムを使用している場合が多い。近年では、高解像度画像、科学データなどを記憶する必要性により、データ入出力（Ｉ／Ｏ）と記憶システムのパフォーマンスおよび機能性との間に重大なアンバランスが発生している。したがって、現行の大容量記憶システムのパフォーマンスと容量は大幅に改善しなければならない。
【０００３】
このような記憶集約的なコンピューティング環境で費用効果の高いデータ・アクセスを可能にするためには、大容量記憶システムを下にある分散ファイル・システムと統合しなければならない。このため、大容量記憶システムとこのようなファイル・システムを結合すると、ファイル・システムのシームレス・ビューが得られる。
【０００４】
データ記憶容量に対する要求が増加し続けるということは、分散記憶システムの管理に関連するコストが記憶域自体のコストより大幅に高くなっていることを暗示している。したがって、データ管理（ＤＭ）アプリケーションによる高機能かつ効率的な記憶管理が引き続き必要である。
【０００５】
ＤＭアプリケーションは、記憶容量が限られた高速オンライン記憶域と３次記憶アーカイブとの間でデータを移送する。さらに、このアプリケーションは３次アーカイブに記憶されたすべてのデータ用のオンライン・セマンティクスを提供し、すなわち、ユーザはそのデータにアクセスするために管理操作を実行する必要はない。そのうえ、ＤＭアプリケーションは、アーカイブされたデータへのアクセスを認識し、自動的にそのデータをユーザに転送する。そのため、ユーザがデータ・ファイルからデータ・ブロックを読み取ろうと試みたときにＤＭアプリケーションへの通知が必要になるように、何らかの監視機能を設けなければならない。
【０００６】
前述の概念、すなわち、遠隔記憶装置にデータを移送することによりローカル記憶空間を解放することは、一般に階層記憶管理（ＨＳＭ）として知られている。この記憶管理はユーザにとって透過的なものであり、すなわち、ユーザは依然としてそのデータがローカルである場合のようなビューを有する。
【０００７】
ファイルベースのＨＳＭでは、ＤＭアプリケーションは、ファイル属性を保持するだけのプレースホルダとして、いわゆる「スタブ・ファイル」を生成する。このスタブ・ファイルまたはこれに対応する穿孔済みディスク領域（複数も可）にアクセスすると、もう一度そのファイル（またはディスク領域）のデータが遠隔記憶装置から再呼出しされる。通常、ＨＳＭは、大量の滅多にアクセスされないデータ（たとえば、アーカイブされた天気図、ビデオ・プレゼンテーション）を記憶するファイル・サーバ上にインストールされる。
【０００８】
さらに、前述の分散大容量記憶システムの一部が障害記憶システムのサービスを引き継ぐことができる場合、その記憶システムの可用性、すなわち、下にあるデータ記憶装置とＤＭアプリケーション（複数も可）との組合せの可用性を改善できることが知られており、通常、「フェールオーバ」と呼ばれる。
【０００９】
そのため、本出願人によって開発され販売されているＡＩＸ ＳＰ（ＵＮＩＸ（Ｒ）ベースのスケーラブル・パワー・パラレル・コンピュータ）上で実行される汎用パラレル・ファイル・システム（ＧＰＦＳ）など、複数のホスト・マシン間でのディスクの共用を管理するファイル・システムが知られている。通常のソフトウェア・アプリケーションのようにＤＭアプリケーションを開発できるようにするために、そのファイル・システムによって実現され、以下の機能を実行するためにデータ管理（ＤＭ）アプリケーションが使用するデータ管理アプリケーション・インタフェース（ＤＭＡｐｉ）（データ管理インタフェース・グループ（ＤＭＩＧ）コンソーシアムによって指定されている）が提案されている。
− 階層記憶管理（ＨＳＭ）
− データ・バックアップおよび復元
【００１０】
ＤＭＡｐｉは、堅固でコマーシャルグレードのＤＭアプリケーションを実現するのに適した環境を提供することを目標としている。共用ディスク環境では、ＤＭＡｐｉは、特に、ファイル・システム・オブジェクトのＤＭアプリケーション・クラッシュ回復およびステートフル制御のための諸機能を含むことができる。
【００１１】
特に本発明で対処する疎結合コンピュータ・ノードのクラスタでは、各ノードは、同期または非同期のいずれかになる可能性のある、いわゆる「ＤＭＡｐｉイベント」を必要とする記憶管理サポートを提供するＤＭアプリケーションを含む。ＤＭＡｐｉイベントは、そのクラスタの所与のノード上に実現された、下にあるオペレーティング・システムで所与の動作が行われたときに必ずＤＭアプリケーションに通知できるようにするメカニズムである。このようなメカニズムにより、１カ所の障害を発生している他のノードがＤＭＡｐｉセッションを引き継ぐことができる。ＤＭＡｐｉセッションは、ＤＭアプリケーションと、下にあるオペレーティング・システムで実現されたＤＭＡｐｉのカーネル・コンポーネントとの１次通信チャネルである。
【００１２】
古典的な１ノード／コンピュータ環境では、システム障害が発生した場合にファイル・システム・サービスが終了する恐れがある。クラスタ環境では、単一ノード障害がシステム内の他の（独立）ノードに影響しない可能性が高い。ＤＭアプリケーションが障害ノードに常駐する場合、アクティブ・クラスタ・ノード上で実行中のプロセスに潜在的に割り込むスタブ済みファイルへのアクセスは使用不能になる。したがって、初期ノード障害による影響を受けていない他のクラスタ・ノードを残すために、ＤＭアプリケーションをアクティブ・クラスタ・ノードに移送し、ＨＳＭ機能を回復することが望ましい。
【００１３】
【発明が解決しようとする課題】
したがって、本発明の一目的は、分散コンピューティング環境内の共用ディスク・ファイル・システムに関するデータ管理アプリケーションのフェールオーバを処理するための方法およびシステムを提供することにある。
【００１４】
他の目的は、データ・アクセス・サービスを提供する疎結合ノードのクラスタを有する分散コンピューティング環境でフェールオーバを処理するためのこのような方法およびシステムを提供することにある。
【００１５】
さらに他の目的は、このようなクラスタ環境でＤＭＡｐｉベースのＨＳＭアプリケーションのフェールオーバ処理を可能にするこのような方法およびシステムを提供することにある。
【００１６】
上記の目的は独立クレームの特徴によって解決される。本発明の有利な実施形態は従属クレームの主題である。
【００１７】
【課題を解決するための手段】
本発明による方法は、そのクラスタの所与のノードをフェールオーバ候補ノードとして定義するステップと、すべてのフェールオーバ候補ノードに関する構成情報を記憶するステップと、フェールオーバ候補ノードのうちの少なくとも１つのフェールオーバ候補ノードの障害情報を含みかつこれに限定されないメッセージ情報を配布するステップと、フェールオーバ候補ノードによって障害ノードのサービスを引き継ぐべきかどうかを判定するために配布したメッセージ情報と記憶した構成情報を分析するステップと、少なくとも１つのフェールオーバ候補ノードが障害ノードのサービスを引き継ぐ場合に構成情報を更新するステップによって、上記の目的を達成する。
【００１８】
一般に、クラスタ環境には２通りの障害タイプがある。第１のタイプは、あるノードがデータ・アクセス・サービスをもはや提供できないことをそのノードが認識しており、したがって、異なるノード上でデータ・アクセス・サービスを回復するためにフェールオーバ要求をトリガしなければならないことである。あるノードの完全な障害が発生した場合、クラスタ・サービスはフェールオーバ候補ノードに障害イベントを配布する。本発明は、両方のタイプの障害に対処し、唯一のメカニズムを提供する。
【００１９】
本発明の下にある特定の概念は、障害時にＤＭＡｐｉセッションを移動できるようにし、その結果、ＤＭアプリケーションのカスケード・フェールオーバを可能にする、ファイル・システムに関するメカニズムを提供することである。このメカニズムは、固有のやり方で分散大容量記憶システムのユーザ（複数も可）により高レベルの可用性を提供する。
【００２０】
疎結合システムは、共用メイン・メモリ（ＲＡＭ）の欠落によって発生するクラスタ・ノードの明白な独立性を特徴とする。このクラスタ機能は、ハードウェア側の何らかの類の高速相互接続と、ノード間通信および共用データ記憶などの諸機能を提供するクラスタ・ソフトウェアに基づくものである。
【００２１】
モノリシック（マルチプロセッサ）システムと比較すると、疎結合クラスタ・ノード間の同期に関する問題は２つある。
− システム・ミューテックスと同様の同期ロック・メカニズムの欠落
− 障害ノードに関するローカル構成情報の喪失
【００２２】
本発明は、２次記憶域と代替オブジェクト・ロック・メカニズムを使用してこの機能をシミュレートすることにより、上記の問題を克服する。
【００２３】
さらに、本発明は有利なことに、スタブ済みファイルにアクセス保証を提供する。
【００２４】
本発明の好ましい実施形態では、第１のフェールオーバ候補が障害ノードからファイルシステムのサブセットを引き継ぐ場合にのみ、少なくとも第２のフェールオーバ候補にフェールオーバ要求を持ち込む。このカスケード・メカニズムは、疎結合コンピュータ環境での障害回復の堅固さを大幅に強化するものである。
【００２５】
【発明の実施の形態】
図１は、従来技術により経時的に（「時間線」）非常駐ファイルを読み取るためのＤＭＡｐｉモデル・データ・フローを示している。分散クラスタ化コンピュータ環境の図示のノード１００は、ローカルに（ここでは図示しない）、たとえば、図示のノードに接続された磁気ディスクにすることができるローカル・ディスクまたは２次記憶域に記憶されたファイル・データへのユーザ・アクセスを制御するための複数の方法を提供するＤＭアプリケーション１１０を実行するホスト・コンピュータを含む。ノード１００上では、ＤＭＡｐｉインプリメンテーション１３０を備えたオペレーティング・システム・カーネル１２０が実行されている。
【００２６】
遠隔ノード１４０上には、記憶容量は大きいがデータ・アクセスまたは記憶パフォーマンスが低く、アクセス頻度の低いデータに使用する記憶装置を含む、３次記憶域１５０が設けられている。３次記憶域１５０は、ロボット・テープ・ライブラリまたは光ディスク・オートチェンジャである場合が多く、ネットワーク上の他の何らかのホストに接続される場合が多い。２次記憶域と３次記憶域１５０との間でデータを移動するプロセス１６０は、データ移送と呼ばれる場合が多い。
【００２７】
ファイル・システム・データ（常駐データ）は、ローカル・ディスク上に存在し、おそらく３次記憶域１５０に複製される。常駐データに対するローカル変更は、３次コピーがあればそれを無効にするものでなければならない。非常駐データは、３次記憶域１５０にのみ存在し、ユーザがそれにアクセスする前にローカル・ディスクにコピーしておかなければならない。先にそのデータがローカル・ディスクにコピーされていない場合、ＤＭＡｐｉデータ・フロー・モデルはそのデータへのアクセスを許可しないことに留意されたい。
【００２８】
３次記憶域１５０からローカル記憶域上のファイルにデータを転送するために、ＤＭアプリケーション１１０は、管理下領域が設定されている間にファイルに書き込むことができる。ＤＭＡｐｉは、イベント生成コードを迂回し、「保護されている」データにアクセスするための特殊インタフェース（ここでは図示しない）を提供する。このようなインタフェースは、不可視入出力と呼ばれる場合が多い。それぞれのセマンティクスは、正規のread(2)およびwrite(2)システム・コールと同様であるが、データ・イベントを生成せず、ファイル・タイムスタンプを修正しない。
【００２９】
３次記憶域１５０にファイル・データを送るために、ＤＭアプリケーション１１０は、ターゲット・ファイルへのアクセス権を取得する必要がある。専用のＤＭＡｐｉコールを使用すると、ファイル属性とファイル・データの両方を読み出して、遠隔データ・サーバに送ることができる。その後、ローカル記憶域を獲得するために（データ・ホールを穿孔して）データ・セグメントを解放することができる。この「データ・ホール」はいわゆる管理下領域である。ＤＭアクセス権は、この手順後にリリースされる。
【００３０】
ファイルシステムからメッセージを受け取るために、ＤＭアプリケーション１１０は、それが所与のファイルシステムに関して受け取ることを希望する１組のＤＭイベントを定義する必要がある。とりわけ、このようなイベントは、取付けまたは記憶空間に関するファイルまたはファイルシステム状態イベント（たとえば、空間外通知）への読取り／書込み／打切りアクセスである可能性がある。
【００３１】
ユーザ・アプリケーション１７０が穿孔済みファイル（→その管理下領域）を読み取った場合、ＤＭＡｐｉはそのアプリケーションを中断し、メッセージ待ち行列にイベントを送出する。適切なＤＭイベント処置を備えたＤＭアプリケーションは、そのイベントを読み出して、遠隔記憶域からのファイル・データを復元することができる。その後、その読取りイベントを引き起こしたオリジナル・アプリケーションを再活動化（非ブロック化）するイベントに対する応答が行われる。
【００３２】
チボリ・スペース・マネージャなどのＨＳＭインプリメンテーションは、通常、ローカル記憶空間を自動的に管理する。したがって、ファイルシステムが定義済み使用率たとえば７０％を超えるかまたは空間外イベントを生成する場合、ＤＭデーモンは、定義済みの低しきい値に達するまで、生成した候補リストに基づく適格ファイルを遠隔サーバに移送することを開始する。
【００３３】
図２は、本発明による４ノード・クラスタ２００の初期状態を示している。ノード２は、「/gpfs1」という指定の汎用パラレル・ファイル・システム（ＧＰＦＳ）用のＤＭサービスを提供している。ノード１および３は、ノード２のサービスを引き継ぐべき潜在的な候補（フェールオーバ候補ノード）である。ノード４上には共用ファイルシステムが実現されておらず、したがって、適格ではない。この構成データはＩＢＭのＡＩＸ ＳＰ全体の「システム・データ・リポジトリ」（ＳＤＲ）２１０に記憶される。ノード間の通信は、ノード障害を追跡するＳＰグループ・サービス（ＧＳ）２２０により実施され、定義済みのノード・グループ（ここではクラスタに関与するノード）内でメッセージを配布するための通信プロトコルを提供する。
【００３４】
クラスタ２００内の均一構成は、すべてのフェールオーバ・ノード２３０〜２５０に関する構成データをクラスタ２００内に配置されたＳＤＲ２１０に記憶することによって保証される。
【００３５】
共用環境は、以下のものを把握している必要がある。
・ファイルシステム固有設定を含む、クラスタ２００内で管理されるファイルシステムのリスト
・１つまたは複数のファイルシステムを現在管理しているノード
・たとえば遠隔記憶サーバへのアクセス情報のような追加の構成情報
【００３６】
さらに、フェールオーバ環境の関与ノードにメッセージ（たとえば、ノードの障害レポート）を配布するために通信インタフェースが設けられている（妥当な障害回復通信プロトコルについては図３を参照）。
【００３７】
通信インスタンス（ＡＩＸ ＳＰグループ・サービスなど）は、関与クラスタ・ノードが管理グループを形成できるようにするＡＰＩを提供する。この通信アーキテクチャの各ノードは、グループ・サービス・インスタンス（サーバ）のクライアント（ＳＰ ＧＳ界におけるいわゆるサービス「プロバイダ」）である。インタフェースに送られるクライアント・メッセージは、自動的に関与グループ・メンバに配布される。ＡＩＸ ＳＰ ＧＳメッセージ通知はイベント主導のものである（→コールバック機能）。
【００３８】
あるノード上のＤＭアプリケーションがもはやそのサービスを提供できなくなっている場合、フェールオーバ・グループの他のメンバに対してその障害に関する通知を行わなければならない。これは、障害ノードからアクティブに行われる場合もあれば、完全なノード障害（クラッシュ）の場合にはクラスタ通信サービス（たとえば、ＳＰ ＧＳ）によって報告される場合もある。
【００３９】
この障害通知に基づき、障害環境にある潜在的な引継ぎノードは、以前は障害ノードによって管理されていたファイルシステムに関するＤＭサービスを回復するためのそれぞれの努力を同期させなければならない。各ノードは、障害ノードのサービスを引き継ぐためにそれが適格であるかどうかを判断するために、中央データ・リポジトリ２１０に記憶された共用構成データを分析する必要がある。この手順の結果は、以下のようになる可能性がある。
１．候補なし： 何も行うことはない − サービスを回復することはできない
２．１つの候補： 追加の同期努力なしにサービスを回復することができる
３．複数の候補： サービスを回復することができるが同期が必要である
【００４０】
結果オプション３に関しては、ノードのクラスタ２００が共用メモリを介して通信しない場合（たとえば、ＩＢＭ ＳＰなどの独立マシンのクラスタ）、それは各種ノードを同期させるための余分な努力を要する。障害ノードのファイルシステムを引き継ぐための複数の候補間の同期は以下のいずれかで行うことができる。
ａ）同時性または
ｂ）非同時性
【００４１】
図３は、図２に示すような４ノード・クラスタにおける本発明による方法の第１の実施形態を示している。これは、１つの障害ノード３００のサービスを引き継ぐために複数のフェールオーバ候補ノード間で同時性すなわち通信ベースの同期を可能にするものである。
【００４２】
あるクラスタの異なるノード間のフェールオーバ機能を提供するために、ＤＭアプリケーションは、障害回復プロセスに関与しなければならないすべてのノード上にインストールする必要がある。初期構成では、これらのノードのうちの少なくとも１つが特定のファイルシステムに関するデータ管理（ＤＭ）サービスを提供する。潜在的なフェールオーバ候補３１０、３２０は、バックグラウンドでスリープ中のままになるか、または異なるファイルシステムに関するサービスを提供する。
【００４３】
適格ノード３１０、３２０は、そのグループの他のメンバ３１０、３２０、３５０に配布するために、前述のグループ・サービスなどの専用クラスタ通信サービス３３０によって処理されるクラスタ通信メカニズムにより１つのメッセージを送出する。このメッセージは優先順位キー３４０（たとえば、そのノードの作業負荷３６０に基づくもの）を含む。
【００４４】
この方法は好ましくは、ＡＩＸ ＳＰで使用するシステム・データ・リポジトリ（ＳＤＲ）が提供するコマンド・インタフェースに基づくブロック化メカニズムを提供する。このＳＤＲにより、所与のデータ・レコード・タイプに関する持続データ・オブジェクトの作成および修正が可能になる。アトミック動作でデータ・オブジェクトをチェックして修正し、その結果、以下のIF-THEN条件付きステップとして本実施形態で実現された共用ＨＳＭ資源にロック（システム・ミューテックスと同様のもの）を設定することは可能である。
If (lock == 0) then { lock = 1 }
【００４５】
このチェックが失敗した場合、呼出し元はしばらくの間待機してからもう一度試みる。ロックに加え、後続のノードはロック固有タイムスタンプ（クラスタ全体で同期したクロックに基づくもの）も更新する必要がある。ロックを保持するノードがクラッシュした場合、待機ノードは永遠にロックにアクセスしようと試みることになるが、これは明らかに望ましくないことである。
【００４６】
サービス引継ぎは約６０秒もかかる場合がある。あるロックのタイムスタンプがこの６０秒より古い場合、候補ノードは、ロックを保持するノードが回復せず、自由にロックの引継ぎを強要できる（タイムスタンプをもう一度更新する）と想定することができる。共用ＨＳＭ資源のアクセスが完了した後、ロックはゼロにリセットされる。
【００４７】
前述の優先順位キーはＵＮＩＸ（Ｒ）の「アップタイム」コマンドに基づくものである。そのうえ、他のデータ「アップタイム」は、最後の１５分間のシステム作業負荷をレポートする。レポートした作業負荷が高ければ高いほど、優先順位キーの値が小さくなる。
【００４８】
メッセージを受け取るノードは、着信キーとそれ自体のキーを突き合わせることができる。最良キー３８０はそのサービスを引き継ぐ権利を勝ち取る。キーを送出する潜在的なバックアップ・ノードの数はシステム内では不明なので、投票段階は所与のタイムアウト３７０後に終了する必要がある。
【００４９】
勝利ノードは、その現在アクティブなＨＳＭ構成に１つまたは複数のファイルシステムを追加するかまたはＨＳＭサービス３８０を始動する。ＤＭＡｐｉベースのアプリケーションにとって典型的なことに、それは、ターゲット・ファイル・システム（複数も可）のために生成されたすべての着信イベントを引き継ぐようにイベント・マスクを設定する必要がある。サービスを引き継ぐノードは、整合性を保証するために中央データ・リポジトリ内の構成ファイルを更新する必要がある。この更新メカニズムは、競合条件を回避するためにロック・メカニズム（上記を参照）によるものでなければならない。残りは、スリープ中のバックアップのままになるかまたはそれ自体のＨＳＭファイルシステムに関するサービスを続行する。あるノードが投票段階で遅延された場合、そのノードは所有者ファイルで定義されたアクティブ・ノードと障害発生ノードを突き合わせることができる。不一致が存在する場合、引継ぎがすでに行われているので制御しようという試みをやめてしまう。
【００５０】
前述したように同時性マルチフェーズ・ハンドシェーク・メカニズムによってこの状況を処理するには何らかの時間の間、状況情報を保持する必要があり、そのうえ、わずかな通信オーバヘッドを伴う。また、初期引継ぎノードは障害ノードのすべてのファイルシステムを管理できない可能性があるので（たとえば、ファイルシステムが搭載されていない）、ファイルシステムごとに投票することも必要である。
【００５１】
図４は、フェールオーバ候補ノード間の同期が非同時性（データ・ロックベース）プロトコルにより実施される、他の実施形態を示している。この実施形態は３つのノードを備えた状況で示されている。各ノードは、構成ファイルをロックし、更新し、アンロックするだけでファイルシステムを引き継ごうと競合する可能性がある。クラスタ・データ・リポジトリ内の構成ファイルをロックし修正できたノードは、障害ノードからファイルシステムを引き継ぐ権利を勝ち取る。フェールオーバ要求は、前の引継ぎノードによって対応できない残りのファイルシステムを依然として引き継ぐことができる遅延ノードにさらにカスケードすることになる。図３に示す同時性手法とは対照的に、前述の非同時性フェールオーバ・メカニズムは、フェールオーバ・グループのノード間の明示メッセージを必要としない。
【００５２】
障害時には、障害発生ノードは、ファイルシステムからのデータ管理（ＤＭ）イベントを処理することができる。このようなイベントを生成するプロセスは、あるファイルのデータが遠隔記憶サーバから再呼出しされた後でＤＭアプリケーションがそのイベントをリリースするまでＤＭＡｐｉ環境によってブロックされる。サービスを引き継ぐノードは、既存のＤＭＡｐｉセッションを使用するか、または何も存在しない場合は新しいＤＭＡｐｉセッションを作成する。さらに、そのノードは障害発生ノードからのセッションを引き受ける。障害発生ノードからの保留イベントは、一時ＤＭＡｐｉセッションに移動され、イベントの種類に応じて様々な方法で管理される。これは、ブロックしたプロセスがもう一度リリースされることを保証する。
【００５３】
図５に示す例示は、遠隔データ再呼出し要求の引継ぎを示している。ＧＰＦＳＨＳＭでは、ＧＰＦＳデーモンが（異常に、ノード・クラッシュにより、ユーザ要求により）休止した場合、ＤＭＡｐｉがこの種のイベント引継ぎをサポートする。
【００５４】
通信イベント処理の種類に応じて、ＤＭアプリケーションは、並行スレッドの問題を回避するためにある種の待ち行列化が必要になる場合もある。原則として、すべてのプロセス／スレッドは、中央データ・リポジトリ内のロックされたデータ・オブジェクトによってブロックされるが、これは望ましくない使用中待機を引き起こすものである。単一スレッド化環境では、単純なＦＩＦＯリストに要求を記憶できるだろう。また、マルチスレッド化環境では、システム・ミューテックスまたは条件変数によって同期を達成できるだろう。
【００５５】
最後に、図６は、ＩＢＭ ＳＰ上のＡＩＸ用のＧＰＦＳ ＨＳＭにおける本発明のグループ・サービス・インプリメンテーションを示している。
【００５６】
図示のＳＰ環境は、以下のものを特徴とする。
・クラスタ全体の通信プロトコルに加え、ノード・クラッシュ用の追跡メカニズムを提供するグループ・サービス（ＧＳ）６００
・クラスタ全体の構成ファイルを記憶するためのシステム・データ・リポジトリ（ＳＤＲ）６１０
【００５７】
ＳＰグループ・サービスは、任意のＳＰノード上に配布され実行中のプロセスからなる通信グループを形成するためのメカニズムを提供する。関与プロセスは、そのグループのすべてのメンバにメッセージを配布することができる。そのうえ、メンバ・プロセスの寿命状況を監視するようグループ・サービスに指示することができるが、これはフェールオーバ・メカニズムをトリガするグループ・メンバにプロセス（→完全ノード）障害をレポートするために使用できる特徴である。
【００５８】
ＡＩＸ ＳＰ上のＧＰＦＳ ＨＳＭのタスクは３つのデーモンに分割されている。
・すべてのフェールオーバ／回復活動のフォーカル・ポイントであるdsmwatchd６２０、６３０、６４０
・移送したデータを遠隔記憶サーバから再呼出しすることを担当するdsmrecalld６８０、６９０、７００
・ファイルシステムの空間外条件と遠隔記憶サーバへの自動データ移送を処理するdsmmonitord６５０、６６０、６７０
【００５９】
dsmwatchdは基本的に２つのタスクを履行する。
− メイン・プロセス（ＤＭスレッド）７２０によって実行される、クラッシュしたdsmmonitordおよびdsmrecalldの回復
− ＧＳコールバック・スレッド７３０によってトリガされるフェールオーバ環境の管理であって、以下のものを含む
・破壊されたローカル環境（ＧＰＦＳデーモン・クラッシュ／シャットダウン、ノード・クラッシュ、ＨＳＭデーモンの破壊）の場合のアクティブ・フェールオーバ
・遠隔障害ノードのファイルシステムのアクティブ引継ぎ
【００６０】
第１のタスク１によれば、ＤＭサービスが立ち上がっていることをチェックし、dsmrecalldが実際に実行中であることを保証するために、dsmwatchdはＤＭコールによりdsmrecalldを「ピングする」。dsmwatchdがもはやdsmrecalldをピングできなくなった場合、それはdsmrecalldを１回再始動しようと試みることになり、これが成功しなかった場合、ＤＭ環境が破壊されたという想定に基づいて異なるノードへのフェールオーバを開始することになる。そのうえ、ＰＩＤがもはや存在しない場合にターゲット・デーモンを再始動するために、それはプロセスＩＤを追跡する。
【００６１】
第２のタスク２によれば、ＳＰグループ・サービス（ＧＳ）動作は前述のように実現される。この引継ぎメカニズムは好ましくは非同期で機能する。というのは、所与のＧＳ制限により同時動作を行うことができないことが多いからである。複数のフェールオーバ要求はpthreadミューテックスにより待ち行列化される。
【００６２】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００６３】
（１）サービスを提供する疎結合ノードのクラスタを有する分散コンピューティング環境で共用ディスク・ファイル・システムに関するデータ管理アプリケーションのフェールオーバを処理するための方法において、
前記クラスタの所与のノードをフェールオーバ候補ノードとして定義するステップと、
すべての前記フェールオーバ候補ノードに関する構成情報を記憶するステップと、
前記フェールオーバ候補ノードのうちの少なくとも１つのフェールオーバ候補ノードの障害情報を含みかつこれに限定されないメッセージ情報を配布するステップと、
フェールオーバ候補ノードによって障害ノードのサービスを引き継ぐべきかどうかを判定するために前記配布したメッセージ情報と前記記憶した構成情報を分析するステップと、
少なくとも１つのフェールオーバ候補ノードが障害ノードのサービスを引き継ぐ場合に前記構成情報を更新するステップとを含む方法。
（２）第１のフェールオーバ候補が前記障害ノードから前記ファイルシステムのサブセットを引き継ぐ場合にのみ、少なくとも第２のフェールオーバ候補にフェールオーバ要求を持ち込む、上記（１）に記載の方法。
（３）前記構成情報が前記クラスタ内に配置された中央データ記憶域に記憶される、上記（１）または（２）に記載の方法。
（４）前記配布されたメッセージ情報が少なくとも１つのノードの障害レポートを含む、上記（１）ないし（３）のいずれか一項に記載の方法。
（５）前記フェールオーバ候補ノードが、前記配布されたメッセージ情報の一部として配布された、前記フェールオーバ候補ノードのそれぞれの作業負荷に関連する優先順位キーを計算する、上記（１）ないし（４）のいずれか一項に記載の方法。
（６）前記優先順位キーを受け取る前記フェールオーバ候補ノードが、前記受け取った優先順位キーをそれぞれの優先順位キーと比較し、それにより、最良優先順位キーが前記サービスを引き継ぐ権利を勝ち取る、上記（５）に記載の方法。
（７）前記構成情報の更新がロック・メカニズムにより処理される、上記（１）ないし（６）のいずれか一項に記載の方法。
（８）サービスを提供する疎結合ノードのクラスタを有する分散コンピューティング環境で共用ディスク・ファイル・システムに関するデータ管理アプリケーションのフェールオーバを処理させるためにそこに実施されたコンピュータ可読プログラム・コード手段を有するコンピュータ使用可能媒体を含む製品において、前記製品内の前記コンピュータ可読プログラム・コード手段が、
前記クラスタの所与のノードをフェールオーバ候補ノードとして定義することと、
すべての前記フェールオーバ候補ノードに関する構成情報を記憶することと、
前記フェールオーバ候補ノードのうちの少なくとも１つのフェールオーバ候補ノードの障害情報を含みかつこれに限定されないメッセージ情報を配布することと、
フェールオーバ候補ノードによって障害ノードのサービスを引き継ぐべきかどうかを判定するために前記配布したメッセージ情報と前記記憶した構成情報を分析することと、
少なくとも１つのフェールオーバ候補ノードが障害ノードのサービスを引き継ぐ場合に前記構成情報を更新することをコンピュータに実施させるためのコンピュータ可読プログラム・コード手段を含む製品。
（９）サービスを提供する疎結合ノードのクラスタを有する分散コンピューティング環境で共用ディスク・ファイル・システムに関するデータ管理アプリケーションのフェールオーバを処理するためのシステムにおいて、
フェールオーバ候補ノードに関する構成情報を記憶するためのデータ記憶手段と、
前記フェールオーバ候補ノード間にメッセージ情報を配布するための通信インタフェース手段と、
フェールオーバ候補ノードによって障害ノードのサービスを引き継ぐべきかどうかを判定するために前記メッセージ情報と前記構成情報を分析するための手段と、
少なくとも１つのフェールオーバ候補ノードが障害ノードのサービスを引き継ぐ場合に前記構成情報を更新するための手段とを含むシステム。
（１０）第１のフェールオーバ候補が前記障害ノードから前記ファイルシステムのサブセットを引き継ぐ場合にのみ、少なくとも第２のフェールオーバ候補にフェールオーバ要求を持ち込むフェールオーバ処理をカスケードするための手段をさらに含む、上記（９）に記載のシステム。
（１１）前記データ記憶手段が前記クラスタ内に配置された中央データ記憶域である、上記（９）または（１０）に記載のシステム。
（１２）前記構成情報を更新するための手段が、障害ノードのサービスを引き継ぐフェールオーバ候補ノードに位置する、上記（９）ないし（１１）のいずれか一項に記載のシステム。
【図面の簡単な説明】
【図１】従来技術により非常駐ファイルを読み取るためのＤＭＡｐｉモデル・データ・フローを示す概略データ・フロー図である。
【図２】本発明によるノード・クラスタの初期状態を示す概略ブロック図である。
【図３】障害ノードのサービスを引き継ぐための複数のフェールオーバ候補ノード間の同時性同期を提供する本発明の第１の実施形態を示すタイム・チャートである。
【図４】非同時性同期を提供する実施形態を示す、図３と同様のタイム・チャートである。
【図５】本発明による遠隔データ再呼出し要求の引継ぎを示すブロック図である。
【図６】本発明の実施例を示す他のブロック図である。
【符号の説明】
３００ ＤＭアプリケーション・ノード１
３１０ ＤＭアプリケーション・ノード２
３２０ ＤＭアプリケーション・ノード３
３３０ クラスタ通信サービス
３５０ ＤＭアプリケーション・ノード４
３６０ 作業に専念するかまたはネットワークが使用中
３７０ 非常に最良のキーであるが、タイムアウト後にグローバルに受け取る
３８０ タイムアウト前に最良キーがＨＳＭサービスを始動する
３９０ ＨＳＭサービスを始動しようと試みることができるが、ファイルシステム所有者を分析するとすぐに、アクティブ・ノードがすでにそのファイルシステムを管理していることをノードが認識する

Claims (11)

1. 分散ファイルシステムを制御するデータ管理アプリケーションのフェールオーバを処理する方法であって、
   前記データ管理アプリケーションのサービスを提供できる複数のノードが互いに疎結合してクラスタを構成しており、
   前記分散ファイルシステムは、前記クラスタと、各ノード障害に影響されず、前記クラスタのノード間における通信を実施し、前記ノードの障害回復のために用いるメッセージ情報を配布する専用クラスタ通信インタフェース手段を有し、
   前記分散ファイルシステムを管理するユーザの操作に応答して、前記サービスを提供するノードが所定の条件に基づいて適格である前記クラスタの所与のノードをフェールオーバ候補ノードとして定義するステップと、
   前記サービスを提供するノードが自己に関する構成情報と前記クラスタ内のすべてのフェールオーバ候補ノードに関する構成情報とを共有構成データとして各ノードと独立した中央データ記憶域に記憶するステップと、
   前記サービスを提供するノードに障害が発生した際、前記専用クラスタ通信インタフェース手段が前記フェールオーバ候補ノードに、障害を通知する前記メッセージ情報を配布するステップと、
   前記フェールオーバ候補ノードの各々が前記サービスを引き継ぐべきかどうかを判定するための優先順位キーを作業負荷に基づき決定するステップと、
   前記フェールオーバ候補ノードの各々が前記専用クラスタ通信インタフェース手段を介して前記優先順位キーを含む前記メッセージ情報を他のフェールオーバ候補ノードに送信するステップと、
   前記フェールオーバ候補ノードの各々が前記優先順位キーを含むメッセージ情報の受信に応答して、前記共有構成データと前記優先順位キーを含むメッセージ情報とを分析し、その結果に応じて障害ノードの前記サービスを引き継ぐべきかを判定するステップと、
   前記障害ノードの前記サービスを引き継ぐとされた前記フェールオーバ候補ノードが前記共有構成データを更新するステップと、を含む方法。
2. 第１のフェールオーバ候補が前記障害ノードから前記分散ファイルシステムのサブセットを引き継ぐ場合にのみ、少なくとも第２のフェールオーバ候補にフェールオーバ要求を持ち込む、請求項１に記載の方法。
3. 前記中央データ記憶域が前記クラスタ内に配置されたシステム・データ・リポジトリである、請求項１または２に記載の方法。
4. 前記配布された障害を通知するメッセージ情報が少なくとも１つのノードの障害レポートを含む、請求項１ないし３のいずれか一項に記載の方法。
5. 前記フェールオーバ候補ノードが、前記配布された優先順位キーを含むメッセージ情報を受け取るステップと、
   前記フェールオーバ候補ノードが、他のフェールオーバ候補ノードから受け取ったそれぞれの優先順位キーに基づき最良優先順位キーを決定するステップと、
   前記フェールオーバ候補ノードの優先順位キーと前記最良優先順位キーが同じである場合、前記サービスを引き継ぐ権利を勝ち取るステップと、を含む、請求項１ないし４のいずれか一項に記載の方法。
6. 前記共有構成データの更新がロック・メカニズムにより処理される、請求項１ないし５のいずれか一項に記載の方法。
7. 分散ファイルシステムを制御するデータ管理アプリケーションのフェールオーバを処理する方法をコンピュータシステムに実行させるためのプログラムを記憶した記憶媒体であって、
   前記データ管理アプリケーションのサービスを提供できる複数のノードが互いに疎結合してクラスタを構成しており、
   前記分散ファイルシステムは、前記クラスタと、各ノード障害に影響されず、前記クラスタのノード間における通信を実施し、前記ノードの障害回復のために用いるメッセージ情報を配布する専用クラスタ通信インタフェース手段を有し、
   前記分散ファイルシステムを管理するユーザの操作に応答して、前記サービスを提供するノードが所定の条件に基づいて適格である前記クラスタの所与のノードをフェールオーバ候補ノードとして定義するステップと、
   前記サービスを提供するノードが自己に関する構成情報と前記クラスタ内のすべてのフェールオーバ候補ノードに関する構成情報とを共有構成データとして各ノードと独立した中央データ記憶域に記憶するステップと、
   前記サービスを提供するノードに障害が発生した際、前記専用クラスタ通信インタフェース手段が前記フェールオーバ候補ノードに、障害を通知する前記メッセージ情報を配布するステップと、
   前記フェールオーバ候補ノードの各々が前記サービスを引き継ぐべきかどうかを判定するための優先順位キーを作業負荷に基づき決定するステップと、
   前記フェールオーバ候補ノードの各々が前記専用クラスタ通信インタフェース手段を介して前記優先順位キーを含む前記メッセージ情報を他のフェールオーバ候補ノードに送信するステップと、
   前記フェールオーバ候補ノードの各々が前記優先順位キーを含むメッセージ情報の受信に応答して、前記共有構成データと前記優先順位キーを含むメッセージ情報とを分析し、その結果に応じて障害ノードの前記サービスを引き継ぐべきかを判定するステップと、
   前記障害ノードの前記サービスを引き継ぐとされた前記フェールオーバ候補ノードが前記共有構成データを更新するステップと、を含む方法を実行させるためのプログラムを記憶した記憶媒体。
8. 分散ファイルシステムを制御するデータ管理アプリケーションのフェールオーバを処理するシステムであって、
   前記データ管理アプリケーションのサービスを提供できる複数のノードが互いに疎結合してクラスタを構成しており、
   前記分散ファイルシステムは、前記クラスタと、各ノード障害に影響されず、前記クラスタのノード間における通信を実施し、前記ノードの障害回復のために用いるメッセージ情報を配布する専用クラスタ通信インタフェース手段を備え、
   前記サービスを提供するノードは、前記分散ファイルシステムを管理するユーザの操作に応答して、前記サービスを提供するノードが所定の条件に基づいて適格である前記クラスタの所与のノードをフェールオーバ候補ノードとして定義し、前記サービスを提供するノードが自己に関する構成情報と前記クラスタ内のすべてのフェールオーバ候補ノードに関する構成情報とを共有構成データとして各ノードと独立した中央データ記憶域に記憶し、前記サービスを提供するノードに障害が発生した際、前記専用クラスタ通信インタフェース手段が前記フェールオーバ候補ノードに、障害を通知する前記メッセージ情報を配布し、前記フェールオーバ候補ノードの各々は、前記サービスを引き継ぐべきかどうかを判定するための優先順位キーを作業負荷に基づき決定して、前記専用クラスタ通信インタフェース手段を介して前記優先順位キーを含む前記メッセージ情報を他のフェールオーバ候補ノードに送信し、
   さらに、前記フェールオーバ候補ノードの各々は、前記優先順位キーを含むメッセージ情報の受信に応答して、前記共有構成データと前記優先順位キーを含むメッセージ情報とを分析し、その結果に応じて障害ノードの前記サービスを引き継ぐべきかを判定し、
   前記障害ノードの前記サービスを引き継ぐとされた前記フェールオーバ候補ノードは前記共有構成データを更新するシステム。
9. 第１のフェールオーバ候補が前記障害ノードから前記分散ファイルシステムのサブセットを引き継ぐ場合にのみ、少なくとも第２のフェールオーバ候補にフェールオーバ要求を持ち込むフェールオーバ処理をカスケードするための手段をさらに含む、請求項８に記載のシステム。
10. 前記中央データ記憶域が前記クラスタ内に配置されたシステム・データ・リポジトリである、請求項８または９に記載のシステム。
11. 前記共有構成データを更新するための手段が、障害ノードのサービスを引き継ぐフェールオーバ候補ノードに位置する、請求項８ないし１０のいずれか一項に記載のシステム。

Images