(57)【特許請求の範囲】
【請求項１】
コンピュータ・ネットワークにおいて１つ以上のソフトウェアを中断なく実行するソフトウェア実行方法であって、前記コンピュータ・ネットワークは、それぞれ前記ソフトウェアの内の１つ以上を実行しうる複数のコンピュータと、これら複数のコンピュータにより用いられる資源とを含み、
各ソフトウェアに対して定義される規則に従って、ソフトウェアと、当該ソフトウェアに関係する資源と、当該資源に関係する他のソフトウェア及び当該他のソフトウェアに関係する資源とを含む資源グループをコンピュータにより自動的に作成するステップと、
前記資源グループの前記資源の制御権を有するコンピュータによる前記ソフトウェアの実行に影響を与える事象の発生を判定するステップと、
前記ソフトウェアの実行に影響を与える事象が発生した場合に、前記資源グループの前記資源の制御権をバックアップ・コンピュータに移行するステップと
を含むソフトウェア実行方法。
【請求項２】
前記各ソフトウェアについて、ソフトウェアをその時点で実行しているコンピュータで故障が発生した場合に、前記ソフトウェアと並置しなければならない資源のセットをユーザに識別させるステップと
をさらに含む請求項１記載のソフトウェア実行方法。
【請求項３】
前記ソフトウェアと前記資源とを含む所定のＧＵＩ画像を表示するステップと、
前記表示されたＧＵＩ画像に対する操作に応じて、前記資源と前記ソフトウェアとを対応付けるステップと
をさらに含む請求項１または２に記載のソフトウェア実行方法。
【請求項４】
前記資源は区画に分けられた記憶装置を含み、
前記規則は、同一の記憶装置内の区画を同じ資源グループに含めるようにする規則を含む
請求項１〜３のいずれかに記載のソフトウェア実行方法。
【請求項５】
前記ソフトウェアに対して定義される規則は、ユーザにより定義される規則である、請求項１記載のソフトウェア実行方法。
【請求項６】
コンピュータ・ネットワークにおいて１つ以上のソフトウェアを中断なく実行
するソフトウェア実行装置であって、前記コンピュータ・ネットワークは、それ
ぞれ前記ソフトウェアの内の１つ以上を実行しうる複数のコンピュータと、これ
ら複数のコンピュータにより用いられる資源とを含み、
各ソフトウェアに対して定義される規則に従って、ソフトウェアと、当該ソフトウェアに関係する資源と、当該資源に関係する他のソフトウェア及び当該他のソフトウェアに関係する資源とを含む資源グループをコンピュータにより自動的に作成する資源グループ作成手段と、
前記資源グループの前記資源の制御権を有するコンピュータによる前記ソフトウェアの実行に影響を与える事象の発生を判定する事象発生判定手段と、
前記ソフトウェアの実行に影響を与える事象が発生した場合に、前記資源グループの前記資源の制御権をバックアップ・コンピュータに移行する制御権移行手段と
を含むソフトウェア実行装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般にフォールト・トレラント・コンピュータ・ネットワークに関し、より詳細には、これらのネットワーク中の資源のセットを、それらが「グループ」として利用可能なままであって、ソフトウェア・アプリケーションの中断のない処理が実現されるように管理する技術に関する。
【０００２】
【従来の技術】
ネットワーク中のある種のコンピュータ資源をフォルト・トレラントとなるように冗長方式で実施することは当技術分野で周知である。このような技術の１つに、ネットワークの所与のノードおよびそれが関連する資源（例えばそのプロセッサやディスク・ドライブ）が基本的に「ミラー化」されて冗長性を確保する、いわゆる「クラスタ」構成がある。「高可用性」クラスタは通常、１対のノードＡおよびＢを含み、これらは同時に活動作業の実行中であることができる。どちらかのノードで故障が発生した場合には、もう一方のノードが故障したノードの作業の一部または全てを引き継ぐことができる。完全冗長クラスタ構成は、ノード、データ、およびネットワーク自体が可用性のために複製されるため、クラスタ構成内に故障点が１つも存在しない構成である。
【０００３】
クラスタ構成を管理するツールも当技術分野で周知である。通常、クラスタは一般に「資源グループ」と呼ばれる構成を使用して管理される。資源グループは、アプリケーションやネットワーク・アドレスやディスクなど、主コンピュータで故障が発生した際にバックアップ・コンピュータによって引き継がれることが期待される、高可用性資源のセットである。これらの資源は、調整のとれた形で一緒に同じバックアップ・システムに移動させる必要があるので、「グループ」になっていると言われる。換言すれば、資源グループ中の資源は、常に同じコンピュータ上に「一緒に滞在する」または「集合する」必要がある。通常は、ユーザは資源グループの内容を定義するよう求められる。しかし、このアプローチでは重大な問題が生じる。ユーザによる資源グループの管理に伴う１つの主な問題は、ユーザが特定の資源グループのメンバシップを常に正しく定義しているとは限らないことである。全てのアプリケーションおよびそれらが関係する資源は、それらが何らかの資源を共有する場合に同じ資源グループ中にあることが不可欠である。例として、コンピュータ・ネットワークが、ＤＢ／２TMおよびＬｏｔｕｓ  Ｎｏｔｅｓ(R)を実行するいくつかのワークステーションを含むものと想定する。特定のＩＰアドレスを異なる２つのコンピュータが引き継ぐことはできないので、これらのプログラムは、同じＩＰアドレスを共有する場合、同じ資源グループ中にある必要がある。それにはアプリケーション間の共有関係を作成することが必要であるが、そのことをユーザが知らない可能性がある。クラスタ構成自体が、資源グループを作成するユーザに分かりにくい何らかのタイプの人為的共有を強制する時には、さらに微妙な問題がある。その一例は、実施態様によって、単一のコンピュータしかディスクの制御権（およびアクセス権）を持つことができないようにディスクの引継ぎが制限される場合である。この例では、構成自体が、そのディスク上の全ての区画をこのコンピュータしか引き継ぐことができないとその結果、このディスク上に常駐する区画を使用するアプリケーション間に「人為的共有」が存在する。このため、これらのアプリケーションは、それらが最初は何も共有しているように見えなくても強制的に並置される。資源グループを定義する管理者がこの要件に気付いていない場合には、資源グループを定義する際に、正しい条件下で引継ぎの障害が発生することになる。
【０００４】
クラスタ構成中の様々な資源の保守では、しばしばこの問題が大きくなる。例えば、どの区画がどのディスクに適合するかをシステム管理者が再編成する場合、または様々なアプリケーションで使用するＩＰアドレスを管理者が変更する場合には、このような処置が、１つまたは複数の以前に定義した資源グループの内容に影響を及ぼす可能性がある。いずれかの資源グループが改変されていることが、これらの保守作業を実行する者には分からないこともある。しかし、適当な環境下で、必要なときに重要資源が適当な資源グループ中にないこともあり、これは受け入れることができない。
【０００５】
【発明が解決しようとする課題】
したがって、本発明の主目的は、高可用性クラスタ・ネットワーク構成中の資源グループを定義する「自動」機構を提供することである。
【０００６】
本発明の他の目的は、システム管理者が手動で介入することなく、資源グループを生成し再構成することである。
【０００７】
本発明の他の目的は、クラスタ構成についての資源グループの定義が妥当であり、ネットワークの構成が変化するときにより容易かつ安全にそれらが保守されるようにすることである。
【０００８】
したがってより一般的な目的は、管理ツールを提供して資源グループの定義をさらに容易にする、高可用性クラスタ・ネットワーク構成を提供することである。
【０００９】
本発明の他の重要な目的は、高可用性クラスタ・ネットワーク構成でのシステム管理者の管理作業を簡単にすることである。
【００１０】
本発明の他の目的は、高可用性複数クラスタ・コンピュータのネットワーク環境のサポートに関連する保守コストを削減することである。
【００１１】
本発明の他の一般的な目的および副産物は、資源グループの形成および保守の改善により、消費者のソフトウェア・アプリケーションの可用性をさらに大きくすることである。
【００１２】
【課題を解決するための手段】
本発明の上記その他の目的は、クラスタ構成について資源グループを自動的に生成し保守する機構によって実現される。本明細書においては、資源グループが「自動的に」生成されると言われるのは、どの資源がある特定の資源グループに入るかを定義することにシステム管理者が直接関わらないことが好ましいからである。そうではなく、管理者は単に、所与のアプリケーションをその時に実行しているコンピュータで故障が発生した場合に、そのアプリケーションと並置しなければならない資源のセットを識別するだけである。この場合、本明細書に記載のシステム・ツールは、１組のコロケーション「制約」または規則を使用して１つまたは複数の資源グループを自動的に生成する。第１のコロケーション制約は、所与のアプリケーションについて任意のユーザ定義コロケーションを実施することが好ましく、第２の制約は、同一の物理ディスク上に常駐するディスク区画資源を並置する。このようにして生成された資源グループは効果的なフォールト・トレラントな動作を確保し、容易に保守される。具体的に言うと、クラスタ規模の資源の任意の再構成に応答して、このツールはこの再構成が既存のいずれかの資源グループに影響を与えるかどうかを評価する。影響を与える場合には、システム管理者に訂正処置をとるよう通知が行われ、または自動的に訂正処置が実行される。
【００１３】
本発明のより具体的なもう１つの態様によれば、コンピュータ・ネットワーク中のクラスタ規模の資源を使用する方法も記載される。コンピュータ・ネットワークは、完全にまたは少なくとも部分的に冗長なノード、データ、およびネットワーク接続を有するクラスタとして構成されることが好ましい。この方法は、資源グループの生成から始まる。具体的に言えば、その処理を中断なしにする複数のアプリケーションのそれぞれについて、ユーザ（システム管理者など）は、このようなアプリケーションをその時に実行しているコンピュータで故障が発生した場合に、そのアプリケーションのそれぞれと並置しなければならない資源のセットを識別する。次いで上記のようにコロケーション規則を使用して、システム管理者が直接入力を行うことなく１つまたは複数の資源グループが生成される。各資源グループは複数のアプリケーションおよびそれらが関係する資源を、１つまたは複数含むことが好ましい。次いで、所与の障害が発生した直後に、この方法は資源グループの資源の制御権をバックアップ・コンピュータに移す。
【００１４】
【発明の実施の形態】
次に図１を参照すると、ブロック・ダイアグラムは本発明を実施する高可用性クラスタ構成を示している。図１に示す構成は「完全冗長」になるようになされており、このことはこの構成内には障害点が１つも存在しないことを意味する。完全冗長性は、ノード、データ、およびネットワーク接続のそれぞれが可用性のために複製されることを意味する。この目的のために、図１の構成は、二重共有ＳＣＳＩバス１８および１９を介して接続された二重ネットワーク１０および１２、ノードＡおよびＢ、ならびに１対のミラー化ディスク１４および１６を含む。ノードＡは関連するディスク記憶装置２０を有し、ノードＢは関連するディスク記憶装置２２を有する。「相互引継ぎ」方式では、両ノードＡおよびＢはともに活動状態になり作業を行うことができる。どちらかのノードで故障が発生した場合には、もう一方のノードが故障したノード作業の一部または全てを引き継ぐことができる。この方式では、故障したノードは、回復した時にクラスタとして再統合することができ、次いで再結合ポリシーによって作業負荷の再分配が決定される。別法として「待機」方式では、引継ぎまたは冗長ノードは他の作業を行わず、専用となって主ノードのジョブの実行に備えている。この使用モードでは、専用の待機資源が必要になるという欠点があるが、待機ノードがその引継ぎの役割に備えることが可能になるという利点もある。例えば、引継ぎアプリケーションが既に始動していて、ディスクおよびネットワーク接続がある程度まで使用可能になっている可能性がある。これにより、引継ぎ時間を短縮することができる。このように準備ができていることは、時に待機ノードの「ウォーム状態」と呼ばれる。真のフォールト・トレラント構成では、待機ノードはこのように準備され、時には「ホット」待機と呼ばれる。
【００１５】
本発明によれば、各ノードは、ＡＩＸ（拡張対話式エグゼクティブＶｅｒｓｉｏｎ  ４．１以上）を実行するＩＢＭ  ＲＩＳＣ  Ｓｙｓｔｅｍ／６０００コンピュータ（縮小命令セットのいわゆるＲＩＳＣベースのワークステーション）や、Ｗｉｎｄｏｗｓ  ＮＴまたはＯＳ／２(R)オペレーティング・システムを実行するＩｎｔｅｌベースのプロセッサ・システムなどのコンピュータを含むことができる。このコンピュータは、マネージメントおよび管理のためにグラフィカル・ユーザ・インタフェース（ＧＵＩ）を含む。ＲＩＳＣベースのコンピュータの様々なモデルは、ＩＢＭ  Ｃｏｒｐｏｒａｔｉｏｎの多くの出版物、例えばＲＩＳＣ  Ｓｙｓｔｅｍ／６０００，７０１３  ａｎｄ  ７０１６  ＰＯＷＥＲｓｔａｔｉｏｎ  ａｎｄ  ＰＯＷＥＲｓｅｒｖｅｒ  Ｈａｒｄｗａｒｅ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｆｅｒｅｎｃｅ、資料番号ＳＡ２３−２６４４−００などに記載されている。ＡＩＸ  ＯＳは、ＩＢＭから出版されたＡＩＸ  Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｆｅｒｅｎｃｅの初版（１９８５年１１月）、およびその他の出版物に記載されている。上記のプラットフォームが有用であるが、その他任意の適当なハードウェア／オペレーティング・システムの組合せを使用することができる。したがって、例えば、適当な代替マシンには下記のものが含まれる。Ｎｏｖｅｌｌ  ＵｎｉｘＷａｒｅ  ２．０を実行するＩＢＭ互換ＰＣ４８６またはその上位機種、ＡＴ＆Ｔ  ＵＮＩＸ  ＳＶＲ４  ＭＰ−ＲＡＳ  Ｒｅｌｅａｓｅ  ２．０２以上を実行するＡＴ＆Ｔ  ３０００シリーズ、ＤＧ／ＵＸ  ｖｅｒｓｉｏｎ  ５．４Ｒ３．００以上を実行するＤａｔａＧｅｎｅｒａｌ  ＡＶｉｉＯＮシリーズ、ＨＰ／ＵＸ  ９．００ないしＨＰ／ＵＸ  ９．０５を実行するＨＰ９０００／７００および８００シリーズ、ＳＶＲ４  ｖｅｒｓｉｏｎ  Ｒ４０Ｖ４．２を実行するＭｏｔｏｒｏｌａ  ８８Ｋシリーズ、Ｓｏｌａｒｉｓ  ２．３または２．４を実行するＳｕｎ  ＳＰＡＲＣシリーズ、あるいはＳｕｎＯＳ４．１．２または４．１．３を実行するＳｕｎ  ＳＰＡＲＣシリーズ。
【００１６】
本発明によれば、上記で論じたように複数のクラスタ規模の「資源」がいわゆる「資源グループ」を構成する。具体的にいえば、好ましい実施態様には、３種の基本的な「資源」タイプ、すなわちアプリケーション、ＩＰアドレス、およびディスク区画が含まれる。その他の「タイプ」の資源をこれらの代用とする、またはこれらとともに使用することも可能である。本発明においては、資源はいわゆる「コロケーション」を介してその他の資源と関連付けられる。コロケーション・リンクはアプリケーション（それ自体が資源である）と別の資源（例えばＩＰアドレスやディスク区画など）の間の２進リンクである。図２は、アプリケーションＡ、Ｂ、Ｃ、ＩＰアドレスＩＰ１およびＩＰ２、ならびにディスク区画Ｐ＿Ｆを有する例示的な資源グループを示す図である。この図で識別される直線は、以下に記載する本発明によれば、システム管理者が最初に指定したコロケーション要件を表す。図３はアプリケーションＤ、ＩＰアドレスＩＰ３、およびディスク区画Ｐ＿Ｇを含む別の例示的な資源グループである。この場合も、直線はユーザが指定したコロケーション要件を表す。ただし、図２および図３は、本発明に従って完全に「構成」されてはいない、例示的な資源グループを表すものであることを理解されたい。
【００１７】
この目的のために、本発明では、好ましくは以下に述べる１対のコロケーション「制約」または規則を実施することによって、資源から資源グループを「自動的に構成する」。
（ａ）並置された資源は同一の資源グループとなる。
（ｂ）同一ディスク内の区画は同一の資源グループとなる。
規則（ａ）および（ｂ）は限定的なものではなく、１つまたは複数のその他の制約または規則を追加または代用することもできる。したがって、例えば制約は、あるアプリケーションがパフォーマンス考慮事項に基づいてグループ中で保守されるように、「パフォーマンス」ベースにすることもできる。別のタイプの制約は、何らかのハードウェア依存性を実施することもできる、など。分かるように、上記の規則（ａ）は、任意のユーザ定義コロケーションが確実に実施されるようにする。上記のように図２または図３は、規則（ａ）のみが実施されているかどうかを資源グループがどのようにして調べるか示す図である。
【００１８】
図４は、コンピュータの表示画面に表示されるユーザ・インタフェース・メニューを示す図である。このメニューは、システム管理者がクラスタ規模の資源を特定のアプリケーションに関連付けることができるように、複数のテキスト・ボックス、テキスト・フレーム、およびテキスト制御を含んでいる。この特定の管理画面のレイアウトは例示的なものにすぎない。動作に際して、管理者は、Ａｐｐｌｉｃａｔｉｏｎ名フィールド３０にアプリケーション名（この場合は「ｗｅｂ＿ｓｅｒｖｅｒ」）を入力する。「Ｏｐｔｉｏｎａｌ  Ｃｏｍｍｅｎｔ」フィールド３２にコメントを入力することもできる。管理者は、コマンド・フィールド３４および３６に開始コマンドおよび停止コマンドを入力することができる。本発明によれば、次いで管理者は、そのアプリケーションと並置しようとする１つまたは複数の資源の識別を入力する。この動作は、それだけに限定されるのではないが、最初に管理者に、「Ａｌｌ  Ａｐｐｌｉｃａｔｉｏｎｓ」メニュー３８中のエントリを強調表示させることによって実施することができる。このメニューは、管理しようとする全てのクラスタ・アプリケーションを含む。ｗｅｂ＿ｓｅｒｖｅｒアプリケーションは資源グループの一部分であるので、ユーザはこのエントリをメニュー３８中で強調表示し、これを自動的にＡｐｐｌｉｃａｔｉｏｎ  Ｃｏｌｌｏｃａｔｉｏｎメニュー４０中に複写させる。別法として、行３０のアプリケーション・エントリをＣｏｌｌｏｃａｔｉｏｎメニュー４０のデフォルト・エントリにすることもできる。同様にして、ユーザは次いで、並置するためのＩＰアドレスを「Ａｌｌ  ＩＰ  Ａｄｄｒｅｓｓｅｓ」メニュー４２から、またディスク区画を「Ａｌｌ  Ｄｉｓｋ  Ｐａｒｔｉｔｉｏｎｓ」メニュー４４から選択することができる。選択されたエントリは、次いで図のようにＣｏｌｌｏｃａｔｉｏｎメニュー４０に複写される。このようにして、図４に示すように、システム管理者は、所与のアプリケーションと並置しようとする資源を定義する。ただし、管理者は、資源グループ自体を直接定義するわけではない。
【００１９】
次に図５を参照すると、ここでは自動的に資源グループを生成する助けとするためにどのようにコロケーション制約を使用するかが分かる。管理者は、図４のインタフェース技術を使用して、上記で「ｗｅｂ＿ｓｅｒｖｅｒ」とした第１アプリケーション「Ａｐｐ＿１」に対するコロケーション要件を生成するものと想定する。このアプリケーションは「ｄｕｃｋｈｏｒｎ」と呼ばれるＩＰアドレス（ＩＰ１）、および「ｓｄ１＿１」と呼ばれるディスク区画（ＤＰ＿Ｅ）を有する。また、管理者は、ＩＰ２およびＤＰ＿Ｆを含む第２アプリケーション「Ａｐｐ＿２」に対するコロケーション要件を作成したものと想定する。ディスク区画ＥおよびＦが図５に示すように同一の物理ディスク上にある場合には、上記で論じたコロケーション制約（ｂ）は、次に図示の全ての資源を含む新規の資源グループの生成を強制する。分かるように、アプリケーションＡｐｐ＿１およびＡｐｐ＿２は、それらが論理資源を共有しない場合でも、強制的に同一の資源グループに入れられる。
【００２０】
資源グループを自動的に形成するプロセスについて、以下にさらに詳細に説明する。このプロセスでは下記の定義を使用する。
資源リスト（ＲＬ）：最初は全ての資源のセット。
資源グループｎ（Ｒｇｎ）：資源グループｎを構成する資源のセット。
必要資源リスト（Ｒｑｄ）：資源グループ中に既存の何らかの資源が必要とすることが分かった資源のセット。
全体のプロセスは図６のフローチャートに示すようにして開始する。段階１００で、資源リストに全ての資源のリストが記入される。次いでルーチンは段階１０２に進み、次の資源グループ（Ｒｇｎ）を作成する。この方法については下記で図７に関して説明する。段階１０２の後、ルーチンは段階１０４で試験を行って、資源リストＲＬ中に資源が残っているかどうかを判定する。段階１０４の試験の結果が肯定であれば、ルーチンは段階１０２に戻ってこれを繰り返す。これによって次の資源グループが作成される。しかし、段階１０４の試験の結果が否定であれば、資源リスト中に資源が残っていないことを意味し、したがってルーチンはブロック１０６で示すように終了する。
【００２１】
次の資源グループを作成する段階（すなわち図６の段階１０２）を、図７のフローチャートにさらに詳細に図示する。このルーチンは、段階１０８で空の次の資源グループＲｇｎのデータ構造を作成することから開始する。段階１１０で、ルーチンは資源リストから資源を取り出し、これをその資源グループの必要資源リストＲｑｄに入れる。選択される資源はアプリケーション資源であることが好ましいが、これは必ずしも必要ではない。段階１１４で、ルーチンは次いでＲｑｄリストから取り出した資源が必要とする資源を見つける。「必要資源を見つける」と呼ばれるこのサブステップでは、任意の資源が必要とする資源のサブツリーを見つけるが、これについては下記で図８に関してさらに詳細に説明する。段階１１４の後、段階１１６で試験を行って、Ｒｑｄリストがその時点で空であるかどうか、すなわちそのリスト中の全てのエントリ処理済みであるかどうかを判定する。段階１１６での試験の結果が否定であれば、追加のエントリが依然としてＲｑｄリスト中に存在し、したがってルーチンは分岐して段階１１４に戻り、再循環する。しかし、段階１１６での試験の結果が肯定であれば、Ｒｑｄリスト中にはそれ以上の追加エントリは存在せず、したがってルーチンは続行する。具体的にいうと、必要とする側の資源を見つけるために段階１２０が次いで実行される。この段階では、下記で図９に関してさらに詳細に説明するように、この資源グループ中のいずれかの資源を必要とする、資源グループ中の現在知られている資源以外の任意の即時資源を見つける。段階１２０の後、段階１２２で再度試験を行って、Ｒｑｄリストが空であるかどうか判定する。空でない場合には、ルーチンは再度分岐して段階１１２に戻り、再循環する。しかし、段階１２２での試験の結果が、必要とする側の資源について処理するエントリがそれ以上のＲｑｄリスト中に存在しないことを示す場合には、ブロック１２４に示すようにルーチンは戻る。
【００２２】
次に図８を参照すると、必要とする側の資源を見つけるルーチンが示されている。上記のように、このルーチンはいずれかの資源が必要とする資源のサブツリーを見つける。好ましい実施の形態では、通常はアプリケーション資源は全ての資源を必要とするので、アプリケーション資源のみを選び出すとこのプロセスは最適化される。このルーチンは段階１２６で、Ｒｑｄリストから資源を取り出してこれをＲｇｎデータ構造に入れることから開始する。このルーチンは段階１２８に進み、必要とする任意の資源をＲｑｄリストに追加して、資源リストからこれらを除去する。次いでルーチンは、段階１３０でＲｑｄリストが空であるかどうか試験する。段階１３０での試験の結果が否定である、すなわち処理を必要とするエントリがさらに存在する場合には、ルーチンは段階１２６に戻って再循環する。しかし、段階１３０での試験の結果が肯定であれば、全てのエントリは処理済みであり、ブロック１３２に示すようにルーチンは戻る。
【００２３】
必要とする側の資源を見つけるルーチンを、図９のフローチャートに示す。上記のように、このルーチンは、このグループ中のいずれかの資源を必要とする、資源グループ中の現在知られている資源以外の任意の即時資源を見つける。このルーチンは、所有および交差ツリーまたは資源を反復して見つける。これは段階１３４で、資源リストをチェック・リスト（Ｃｈｋ）データ構造に複写することから開始する。段階１３６で、ルーチンはＣｈｋから資源を取り出す。次いで段階１３８で試験を行って、その資源がＲｇｎ中のいずれかの資源を必要とするかどうかを判定する。この段階で上述のコロケーション制約を使用する。段階１３８での試験の結果が肯定であれば、ルーチンは分岐して段階１４０に進み、そこでルーチンはこの資源をＲｑｄに追加し、資源リストからそれを除去する。しかし、段階１３８での試験の結果が否定である場合、または段階１４０の後で、ルーチンは段階１４２で、Ｃｈｋが空であるかどうか、すなわちその中の全てのエントリが処理済みであるかどうかを調べる。段階１４２での試験の結果が否定であれば、まだ他のエントリを分析しなければならず、したがってルーチンは段階１３６に戻って再循環する。しかし、段階１４２での試験の結果が肯定であれば、ルーチンはブロック１４４に示すように戻る。これで高水準処理は完了する。
【００２４】
本発明ではこのようにして資源グループの自動生成を構想する。「自動生成」とは、本発明で、形成される資源グループができる限り小さく、（コロケーション要件によって）並置する必要のある資源の各セットが１つの資源グループ内に完全に含まれるという制約を受けるような形で、各資源をある資源グループに計算によって割り当てることを意味する。したがって、このプロセスへの人間の関与は、コロケーション要件の指定に限定されることが好ましい。
【００２５】
上記のフローチャートは、「資源中心」方式での自動資源グループ生成を実施するものであることをさらに理解されたい。当業者なら、「コロケーション中心」方式で資源グループの自動生成を実施することも可能であることに気付くであろう。後者の場合、この実施態様では、資源をループし、次いで関連するコロケーションおよび場合によっては関連するディスク区画をループするのではなく、コロケーションを、かつ同じ複数のディスク（ディスク・コロケーションと呼ばれることもある）上に常駐するディスク区画のリストをループする。このようにして、コロケーション（ディスク・コロケーションも含む）を処理してコロケーション中に挙げられる資源に資源グループ名を割り当てることによって、資源グループを計算し保守することができる。
【００２６】
下記の疑似コードは、コロケーション関係を使用して資源グループの形成を最適化する、本発明に従って実施される様々な方法を説明するものである。一般に資源グループは、そのメンバ資源のそれぞれに同一の名前を割り当てることによって形成される。新規のコロケーションに応答して、第１グループの名前を第２グループの全てのメンバに割り当てる（かつ資源グループの名前のリストから第２グループの名前を削除する）ことによって、資源グループをマージすることが必要になることもある。コロケーションが除去されると、コロケーションによって関係付けられたエレメントがメンバである資源グループを再計算する必要がある。これを行う最も簡単な方法は、その資源グループの全てのメンバに新規の名前を割り当てて全てのコロケーションを再処理し、必要に応じてグループをマージすることである。
【００２７】
この第１命令セットは、新規のコロケーション・リンク（Ａ、Ｂ）の追加に応答する。
0003737686.tif 000002
中括弧｛｝の間の論理は、２つの資源グループが同一物理ディスク上の区画を共有するかどうかを判定する試験である。共有する場合には、資源グループは図５に示すようにマージされる。
【００２８】
以下の命令はコロケーション・リンク（Ａ，Ｂ）の除去に応答する。
0003737686.tif 000003
上記において、資源グループのクローンは同じポリシーおよびユーザから与えられたコメントを有する別の資源グループであることに留意されたい。
【００２９】
上記で参照した「Ｍｅｒｇｅ（ｒｇａ，ｒｇｂ）」サブルーチンは、ｒｇｂの全てのオカレンスをｒｇａで置き換え、資源グループｒｇｂを削除する効果を有する。そのポリシーおよびコメントはその時点で失われる。パフォーマンス上の理由から、何らかのアプリケーションと並置されない全ての非アプリケーション資源に、ＮＵＬＬ資源グループを割り当てることが望ましいことがある。Ｍｅｒｇｅ（ｒｇａ，ｒｇｂ）を適用した時にｒｇｂがＮＵＬＬになる場合、これはｒｇａで置き換えるだけでよい（大域置換は必要でない）。ＮＵＬＬは、Ｍｅｒｇｅへの引数として許されず、したがってＭｅｒｇｅの呼出しの代わりに、適当な置換を実行しなければならない。以下の疑似コードは、やはりコロケーション関係を使用して資源グループの形成を最適化する、パフォーマンス最適化である。新規のコロケーション・リンク（Ａ，Ｂ）の追加に応答する。
0003737686.tif 000004
0003737686.tif 000005
【００３０】
図１０は、本発明による、クラスタ規模の資源を使用してソフトウェア・アプリケーションの中断のない処理を実現する方法を示す簡略化したフローチャートである。段階１５０で、最初に試験を行って、ユーザによる全てのコロケーション指定がアプリケーションに対してなされているかどうかを判定する。段階１５０での試験の結果が否定であれば、ルーチンは段階１５２に進む。この段階で、所与のアプリケーションについて、ユーザは、並置しなければならないネットワーク資源のセットを識別する。ルーチンは次いで段階１５４戻り、資源グループを自動的に生成する。段階１５６で試験を行って、ネットワーク中でアプリケーションに影響を及ぼす障害イベントが発生したかどうか判定する。段階１５６での試験の結果が否定であれば、ルーチンは循環する。しかし、段階１５６での試験の結果が肯定であれば、ルーチンは段階１５８に進み、資源グループの資源の制御権をバックアップ・コンピュータに移す。
【００３１】
本発明はこのようにして、ＡＩＸオペレーティング・システム環境用のＨＡ／ＣＭＰなどの従来技術のクラスタ構成に関するいくつかの問題を解決する。本発明によれば、システム管理者は一般に、資源グループの内容を直接定義することを禁止される。そうではなく、ユーザは単に、各アプリケーションについて、そのアプリケーションと「並置」しなければならないと分かっている他の資源（ＩＰアドレス、区画、その他のアプリケーション）をシステムに（従来のＧＵＩを使用して）告げるだけである。したがってユーザはアプリケーションにのみ集中すればよいか、これは資源グループというより抽象的な概念よりもユーザには理解しやすいと予想される。クラスタ構成ルーチンは、全てのアプリケーション定義における直接および間接の（人為的）資源共有を検査し、それらのアプリケーションと、何らかのタイプの依存性（実施態様により定義されるものも含む）を有するそれらが関係する資源とからなる資源グループを自動的に形成する。したがってこの動作は、全ての資源のコロケーション依存性の遷移的閉止を実施する。ユーザが後で何らかの再構成（例えばＩＰアドレスや、ディスク／区画内容、コロケーション要件の変更など）を行う場合には、本発明は資源グループへの影響を評価し、その影響をユーザに通知し、クラスタを保守するために何を行わなければならないかを管理者に指令することができる。したがって、例えば、管理者に、「You no longer need to have DB/2 and Lotus Notes in the same resource group. Do you want to let them be in their own groups now?」などのメッセージ照会が与えられる。その応答によって、本発明は影響を受ける資源グループを再構成する。
【００３２】
本発明の１つの好ましい実施態様は、コンピュータのランダム・アクセス・メモリに常駐のコード・モジュール中の命令のセット（プログラム・コード）である。コンピュータが必要とするまで、この命令セットは別のコンピュータ・メモリ、例えばハード・ディスク・ドライブ、または光ディスク（最終的にはＣＤ  ＲＯＭで使用する）やフロッピー・ディスク（最終的にはフロッピー・ディスク・ドライブで使用する）などの取外し可能メモリに記憶する、あるいはインターネットその他のコンピュータ・ネットワークを介してダウンロードすることができる。さらに、上記の様々な方法は、ソフトウェアによって選択的に活動化または再構成される汎用コンピュータで都合良く実施されるが、当業者なら、ハードウェア、ファームウェア、または必要とされる方法の各段階を実行するように構築されたさらに専門化された装置で上記方法を実行できることにも気付くであろう。
【図面の簡単な説明】
【図１】本発明をその中で実施する代表的な高可用性クラスタ構成を示す図である。
【図２】ユーザのコロケーション要件によって確立される代表的な資源グループを示すブロック・ダイアグラムである。
【図３】ユーザのコロケーション要件によって確立される代表的な資源グループを示すブロック・ダイアグラムである。
【図４】特定のアプリケーションに関連する資源のコロケーションを定義するためにシステム管理者が使用する、代表的なユーザ・インタフェースの一部分を示す図である。
【図５】２つのユーザ定義コロケーションが同一ディスク上のディスク区画に含まれる結果としての、資源グループの形成を示すブロック・ダイアグラムである。
【図６】本発明による資源グループの自動形成手順を示すフローチャートである。
【図７】図６のフローチャートの「次の資源グループを作成する」サブルーチンを示すフローチャートである。
【図８】図７のフローチャートの「必要とされる資源を見つける」サブルーチンを示すフローチャートである。
【図９】図７のフローチャートの「必要とする側の資源を見つける」サブルーチンを示すフローチャートである。
【図１０】本発明による、資源グループ中のクラスタ資源をバックアップ・コンピュータに移す方法を示すフローチャートである。
【符号の説明】
１０  二重ネットワーク
１２  二重共有ＳＣＳＩバス
１４  ミラー化ディスク
１６  ミラー化ディスク
１８  二重共有ＳＣＳＩバス
１９  二重共有ＳＣＳＩバス
２０  ディスク記憶装置
２２  ディスク記憶装置
【図１】
0003737686.tif 000006
【図２】
0003737686.tif 000007
【図３】
0003737686.tif 000008
【図４】
0003737686.tif 000009
【図５】
0003737686.tif 000010
【図６】
0003737686.tif 000011
【図７】
0003737686.tif 000012
【図８】
0003737686.tif 000013
【図９】
0003737686.tif 000014
【図１０】
0003737686.tif 000015