JP2005528691A - サーバ連結環境のための業務継続ポリシー - Google Patents

Abstract

サーバ連結環境において、業務継続ポリシーを確立し維持する方法、コンピュータプログラム製品、およびシステムである。アプリケーションの利用可能性を高めることによって、業務継続を確実にする。アプリケーションが開始され、障害時に再起動され、または過負荷状態により移動される場合、アプリケーションを実行するための要件を満たす最良のシステムが選択される。これらの要件には、アプリケーションによってシステム上に配置される負荷を扱う利用可能容量等のアプリケーション要件を含めることができる。更に、これらの要件には、特定のシステム上で実行できる多くのアプリケーションのシステム制限を引き受ける等のシステム要件を含めることができる。アプリケーションのそれぞれの優先順位を用いて、優先順位の低いアプリケーションを移動して、優先順位の高いアプリケーションを実行するためにリソースを解放できるかどうかを決定できる。

Description

本特許出願書類には、著作権保護を受ける資料が一部含まれている。この著作権保持者は、特許商標局のファイルまたは記録にある特許書類または特許開示を何人がファクシミリ再生しようと異議を唱えないが、それ以外に関しては、如何なるものであってもすべての著作権を留保する。

オープンシステムの使用が広がっているため、数百または数千のサーバを管理する複雑な業務は、益々困難なものとなっている。加えて、サーバ上で実行するアプリケーションの利用可能性をさらに増大させたいという要求が、難問として立ちはだかっている。情報技術（ＩＴ）管理者の多くは、容量的には遙かに余裕はあるが、アプリケーション実行数が多い大量の小型オープンシステムから、容量の限界または容量の限界近くで実行される遙かに数が少ない大規模企業用サーバへ移動するために作業している。ＩＴ業界におけるこの傾向は「サーバ連結」と呼ばれている。

アプリケーションの利用可能性をさらに増大させたいという要求に対する初期の回答の一つは、クリティカルなアプリケーションを実行するサーバ毎に１対１のバックアップを提供することであった。クリティカルなアプリケーションが主サーバで障害を起こした場合、バックアップサーバ上でそのアプリケーションを「障害迂回（failed over）」（再起動）していた。しかしながら、この解決策は、バックアップサーバの遊休化を招くので、非常に費用がかかるとともに、リソースを浪費していた。その上、この解決策は、主サーバとバックアップサーバの両方が連続して障害を起こした場合には対処できなかった。

別の可能性のある解決策は、「Ｎ＋１クラスタ化」であり、１台の企業用クラスのサーバが、動作中の多数のサーバのために冗長性を提供する。Ｎ＋１クラスタ化は、障害が発生したサーバで実行中のアプリケーションを１台のバックアップサーバに移動するため、所定のアプリケーションの集合に対する冗長コストが減少し、障害迂回のためのサーバ選択が単純化される。

しかしながら、Ｎ＋１クラスタ化は、増大するアプリケーション利用可能性の要求に対し、特に、真のサーバ連結環境では、完全な解答にはならない。企業は、多くの障害が連続する場合にも耐え、サーバクラスタの適度な冗長性を維持しつつ、保守管理のために何台かのサーバをオフラインにできる容量も要求している。代表的なクラスタ管理アプリケーションは、数十または数百にもなる可能性をもつアプリケーショングループに対してホストを適切に選定する際に、限られた柔軟性しか提供しない。市販の入手可能なクラスタ管理アプリケーションの例には、VERITAS（登録商標） Global Cluster Manager（商標）、VERITAS（登録商標） Cluster Server、Hewlett-Packard（登録商標） MC/Service Guard、およびMicrosoft（登録商標） Cluster Server（MSCS）がある。

Ｎ対Ｎのクラスタ化は、多数のサーバ上で実行されている多数のアプリケーショングループを参照し、それぞれのアプリケーショングループは、クラスタ内の別のサーバに障害迂回することができる。例えば、４ノードクラスタのサーバは、クリティカルなデータベースインスタンスを３つサポートできる。４ノードのうちの何れかに障害が発生すると、３つの各インスタンスは、３台の他のサーバのうちの一台に過負荷を起こすことなく、３台の他のサーバのそれぞれで実行できる。Ｎ対Ｎのクラスタ化は、Ｎ＋１クラスタ化の考え方を、「バックアップシステム」から、クラスタを形成するサーバ内部の「バックアップ容量」の要件に拡張したものである。

必要とされているのは、アプリケーションを最初に開始し、システムが過負荷の状態に到達した場合にアプリケーションを再配布し、そして障害のあるアプリケーションを再起動するための、適切なシステムを決定することによりクリティカルな業務用アプリケーションが多数の障害にあっても生き残ることができる、という業務継続ポリシー（business continuity policy）である。

本発明は、サーバ連結環境において業務継続ポリシーを確立し維持する方法、システム、およびコンピュータプログラム製品に関する。アプリケーションの利用可能性を高めることによって、業務継続を確実にする。アプリケーションが開始され、障害時に再起動され、または過負荷状態により移動される場合、アプリケーションを実行するための要件を満たす最良のシステムが選択される。これらの要件には、アプリケーションによってシステム上に配置される負荷を扱う利用可能容量等のアプリケーション要件を含めることができる。更に、これらの要件には、特定のシステム上で実行できる多くのアプリケーションのシステム制限を引き受ける等のシステム要件を含めることができる。アプリケーションのそれぞれの優先順位を用いて、優先順位の低いアプリケーションを移動または停止して、優先順位の高いアプリケーションを実行するためにリソースを解放できるかどうかを決定できる。

１つの特徴として、本方法は、システムの集合のうちの各システムが、あるアプリケーションをホストする要件を満たしているクラスタ内のシステムの集合を識別することを含む。選定したシステムが第１のアプリケーションの必要条件を満たす場合、システムの集合の識別は、集合内のその選定したシステムを含めることを意味する。そのアプリケーションが選定システムの制限を超えない場合、システム集合の識別は、集合内のその選定したシステムを含めることを意味する。

そのシステム集合が空の場合、本方法は更に、開放するリソースを識別するために、各アプリケーションの個々の優先順位を用いることを含み、ここで、リソースは複数のリソースの内の１つであり、各リソースは少なくとも１つのシステムと関連付けられている。開放するリソースの識別は、更に、各システムのそれぞれの容量を用いることを含んでもよい。

本方法は、更に、リソースと関連付けられるシステムの１つが、アプリケーションをホストするための要件を満たすようにリソースの開放を含めることができる。本方法は、関連付けられたシステムでアプリケーションを開始することを含んでもよい。リソースの開放は、そのリソースを用いている別のアプリケーションを停止することを含めることができ、別のアプリケーションは、第１のアプリケーションの優先順位よりも低い優先順位を有する。リソースの開放は、別のアプリケーションが第１のアプリケーションのそれぞれの優先順位より低いそれぞれの優先順位を有する場合、そのリソースを用いている別のアプリケーションを、別のシステムに移動することを含めることができる。

本方法は更に、そのアプリケーションを開始すべきであると決定することを含めることができる。これは、アプリケーションが障害を発生したことを検出した場合に決定できる。この決定をする別の方法は、アプリケーションの優先順位を、現在のシステム上で実行されているアプリケーションの各優先順位と比較することである。アプリケーションのそれぞれの優先順位が、システム上で実行されているアプリケーションの優先順位の内の一つより高い場合に、そのアプリケーションを開始すべきである。

本発明の別の特徴として、システム集合内の各システムがアプリケーションをホストするための必要条件を満たすクラスタ内システムの集合を識別するための識別モジュールが、装置には含まれる。本装置は更に、システムの集合がない場合、開放するリソースを識別するために、各アプリケーションのそれぞれの優先順位を用いる優先モジュールを含む。各リソースは少なくとも１つのシステムと関連付けられている。本装置は更に、上記の方法の特徴を実装するモジュールを含めることができる。

上記説明は要約であり、従って、必要に応じて、簡略化、一般化、および細部の省略を含み、その結果、当該技術に精通する者には言うまでもないが、要約は例示に過ぎず、如何なる制限をも意図していない。請求項によってのみ定義されるような、他の局面、発明性のある特徴、および本発明の利点は、以下の限定しない詳細な説明で明らかとなろう。

本発明は、当該技術に精通する者には、添付図面の参照によって正しく理解され、多くの目的、特徴および利点が明らかとなろう。
異なる図面の同じ参照符号の使用は、類似または同一の項目を示している。本発明は、各種の改変および代替形式をとる可能性があるが、特定の実施の形態を図面に例示として示し、本明細書で詳細に説明する。しかしながら、言うまでもないが、図面および詳細な説明が、開示された特定の形態に本発明を限定することは意図していない。逆に、その意図は、添付の請求の範囲により定義されるように、本発明の範囲内にあるすべての改変、等価物、および代替品を含むことである。

本発明の主題を完全に理解するために、添付の請求の範囲を含む以下の詳細な説明を、上で説明した図面と併せて参照されたい。幾つかの実施の形態とともに本発明を説明するが、本発明を本明細書で説明する特定の形態に限定する意図はない。逆に、かかる代替品、改変および等価物は、添付の請求の範囲により定義されるように、本発明の範囲内に理に適って含められる。
以下の記載では、説明のために、本発明の完全な理解を提供するよう多数の特定の詳細について説明する。しかしながら、本発明がこれらの特定の詳細がなくても実施できることは、当該技術に精通する者には言うまでもない。
本明細書で「一実施の形態」または「実施の形態」と称するときは、実施の形態と併せて説明する特定の特長、構造、または特性が、本発明の少なくとも一つの実施の形態に含まれることを意味する。明細書の至る所に出てくる「一実施の形態では」の語句が全て同一の実施の形態を指すとは限らず、他の実施の形態と互いに矛盾する別の、または代替の実施の形態を指示するものでもない。更に、幾つかの実施の形態により示され、他の実施の形態では示されない各種の特長も説明する。同様に、幾つかの実施の形態に対する要件ではあるが、他の実施の形態の要件ではない各種の要件も説明する。

序論
本発明は、サーバクラスタ内のサーバが典型的な、考えられる最良のシステムを積極的に決定して、起動中、過負荷状態のとき、またはアプリケーションかサーバの障害を受けて、アプリケーションをホストする業務継続ポリシーを提供する。本発明がクライアント／サーバ環境の外部で動作するシステムにも適用されるのは、当該技術に精通する者には言うまでもないが、用語サーバおよびシステムは、本明細書では交換可能に用いる。

図１は、本発明の管理システムおよびフレームワークが動作する環境の例を提供する。マウンテンビュー（ＭＶ）サイト１３０Ａのノード１１０Ａおよび１１０Ｂ、および英国（ＵＫ）サイト１３０Ｂのノード１１０Ｃおよび１１０Ｄを、説明のために示す。本発明は、ノードおよび／またはサイトの最小数または最大数を制限していない。用語「サイト」は、ケーブルがノードおよび記憶装置を相互接続できるような、データセンタまたはキャンパスに集中するノードの集約を表すのが普通であるが、地理的な集中は、サイトに対する必要条件ではない。サイトは、一つ以上のノードクラスタを含むことができ、一つ以上のクラスタの仮想集約と見なすことができる。

ＭＶサイト１３０Ａ、およびＵＫサイト１３０Ｂは、典型的には、プライベートの広域ネットワーク、またはインターネット等の公共配布ネットワークに対応するネットワーク１０２を介して接続されるものとして示す。ノード、およびノードクラスタを管理するために用いる共通の管理コンソール１０４を示すが、共通の管理コンソールは、本発明の動作には不要である。

クラスタ１２０Ａは、冗長なクラスタ接続１１５ＡＢ−１、および１１５ＡＢ−２を介して接続されるＭＶサイト１３０Ａのノード１１０Ａおよび１１０Ｂを含む。唯一つのクラスタをＭＶサイト１３０Ａに示すが、サイトには任意の数のクラスタが含まれていてもよい。ノード１１０Ａは、ノード１１０Ｂと、共通のストレージ１４０Ａを共有している。ノード１１０Ａは、相互接続１１２Ａを介してストレージ１４０Ａと相互接続し、ノード１１０Ｂは、相互接続１１２Ｂを介してストレージ１４０Ａと相互接続する。

同様に、クラスタ１２０Ｂは、冗長なクラスタ接続１１５ＣＤ−１、および１１５ＣＤ−２を介して接続されるＵＫサイト１３０Ｂのノード１１０Ｃおよび１１０Ｄを含む。ノード１１０Ｃは、ノード１１０Ｄと、共通のストレージ１４０Ｂを共有する。ノード１１０Ｃは、相互接続１１２Ｃを介してストレージ１４０Ｂと相互接続し、ノード１１０Ｄは、相互接続１１２Ｄを介してストレージ１４０Ｂと相互接続する。

図２は、トレージエリアネットワークでの利用可能性が高くなるよう構成されるクラスタの例を示す。クラスタサーバ２１０Ａおよび２１０Ｂは、同じアプリケーションプログラムのためのサーバとして構成され、互いに障害迂回ターゲットとして働く。冗長な相互接続２１６Ａおよび２１６Ｂは、２つのノードがクラスタを形成する場合、冗長なネットワークインターフェースカード（ＮＩＣ）間のクロスオーバーケーブルを経由する冗長なハートビートプライベートネットワーク接続であってもよい。３つ以上のノードがクラスタを形成する場合、プライベートネットワーク接続は、ハブを用いることもできる。プライベートネットワークは、障害迂回ソフトウェアに、システムまたは処理が障害を起こした場合を認識させることができる。各クラスタ２１０Ａおよび２１０Ｂは、クラスタサーバ２１０Ａのための公共ネットワーク接続２４２Ａおよび２４４Ａ、およびクラスタサーバ２１０Ｂのための公共ネットワーク接続２４２Ｂおよび２４４Ｂ等の、冗長な公共ネットワーク接続を有して、インターネット等の公共ネットワーク２４０を介して通信する。

クラスタサーバ２１０Ａは、ファイバースイッチ２２０Ａへのファイバーチャンネル接続２１２Ａを介して、および、ファイバースイッチ２２０Ｂへのファイバーチャンネル接続２１４Ａを介して、ファイバーチャンネルストレージエリアネットワークへの冗長接続を有する。同様に、クラスタサーバ２１０Ｂは、ファイバースイッチ２２０Ｂへのファイバーチャンネル接続２１２Ｂを介して、および、ファイバースイッチ２２０Ａへのファイバーチャンネル接続２１４Ｂを介して、ファイバーチャンネルストレージエリアネットワークへ接続される。

ファイバーチャンネルストレージエリアネットワークは、共有ストレージアレイ２３０Ａおよび２３０Ｂそれぞれへの、クラスタサーバ２１０Ａおよび２１０Ｂによるアクセスを提供する。ストレージアレイ２３０Ａおよび２３０Ｂは、例えば、ファイバーチャンネルＲＡＩＤアレイと対応してもよい。ファイバースイッチ２２０Ａは、ストレージアレイ２３０Ａにファイバーチャンネル接続２２２Ａを介して接続し、ストレージアレイ２３０Ｂにファイバーチャンネル接続２２４Ａを介して接続する。同様に、ファイバースイッチ２２０Ｂは、ストレージアレイ２３０Ｂにファイバーチャンネル接続２２２Ｂを介して接続し、ストレージアレイ２３０Ａにファイバーチャンネル接続２２４Ｂを介して接続する。クラスタサーバからスイッチへ、およびスイッチからストレージアレイへの冗長接続により確実になるのは、各クラスタサーバ２１０Ａおよび２１０Ｂが、ファイバーチャンネルネットワーク上の記憶装置の集約への接続を有する、ということである。また、冗長電力源（不図示）を含めて、電力障害発生に際してバックアップ電力源を提供することもできる。

クラスタ管理
ハードウェアまたはソフトウェア障害が発生したとしても、災害復旧を確実にするには、データ損失を防ぎ、整合性のあるデータを維持しなければならない。特定のアプリケーションに対するデータでは、そのアプリケーションや対応するアプリケーションデータが、ネットワークまたはノードの障害により整合性がないか使用不可能な状態になることを許容しない。

クラスタ管理アプリケーションは、単一のアプリケーションにより、多数の別々のクラスタを管理者が管理できるようにする。クラスタ内のイベントおよびそれに対する処置を協調させることにより、クラスタ管理アプリケーションは、災害復旧を管理するための有用なツールを提供する。例えば、主クラスタ内のどのノードもアプリケーションを実行できない場合に、第２クラスタは、主クラスタで実行するアプリケーションを引き継ぐことができる。市販の入手可能なクラスタ管理アプリケーションの例には、VERITAS（登録商標） Global Cluster Manager（商標）、Hewlett-Packard（登録商標） MC/Service Guard、およびMicrosoft（登録商標） Cluster Server（MSCS）が含まれる。

クラスタ管理アプリケーションによっては、サイト毎のサイトマスターと呼ばれる処理を、サイト内の一つ以上のサイトスレーブ処理に接続できる。サイトマスターは、そのサイトのクラスタおよびノードすべてについての全情報を収集する。更に、各サイトマスターを分散システム内の他のすべてのサイトマスターに接続して、全サイトマスターが分散システム全体についての情報を有するように、情報を共有してもよい。各サイトが本発明の動作のための自身のマスターを有することは必要条件ではないが、マスターは、そのサイトのハードウェアおよびソフトウェアのリソースの状態について詳細な情報、時には、ソフトウェア処理レベルの情報まで有していなければならない。用語マスターは、サイトマスターを指し、本明細書ではマスター処理とも称する。

典型的には、クラスタ管理アプリケーションは、常に、多数のクラスタのソフトウェアアプリケーションの状態を監視し、そのサイトのクラスタのどのノードもソフトウェアアプリケーションを実行するのに利用できないような、サイト全体が利用不可能となるのを判定できる。クラスタ管理アプリケーションは、主サイトが利用不可能となる状況にも影響されない第２サイトでソフトウェアアプリケーションを開始できる。クラスタ管理アプリケーションは、ユーザがユーザインターフェースを介して制御してもよく、あるいは、クラスタ管理アプリケーションが自動的に動作するよう構成してもよい。

主データセンタが被害を受けた場合、アプリケーションデータを直ちに別のサイトで利用可能とし、アプリケーションを他のサイトで直ちに開始しなければならない。この利用可能性のレベルでは、主サイトから他のサイトへのデータ複製が必要である。VERITAS（登録商標） Volume Repricator（商標）(VVR)、EMC（登録商標） CorporationによるSymmetrix Remote Data Facility(SRDF（登録商標）)、Hitachi（登録商標） Asynchronous Remote Copy(HARC)、Sybase（登録商標） Replication、およびHewlett-Packard（登録商標）によるContinuous Accessを含む様々なデータ複製アプリケーションが、サイト間のデータを複製するために利用できる。

アプリケーションの最初の起動または再起動のために「最良の」サーバを決定する際に含まれる因子には、サーバ容量およびリソース利用可能性が含まれる。本明細書で説明する実施の形態では、クラスタ管理アプリケーションの一部として、業務継続ポリシーを実装する。

障害迂回ポリシー
業務継続ポリシーの一部は、“障害迂回ポリシー”である。様々な“障害迂回ポリシー”を採ることが可能であり、“優先順位”、“ラウンドロビン”、および本発明に含まれる“負荷障害迂回”ポリシーがある。
“優先順位障害迂回ポリシー”は、最も基本的な方策である。稼働中のサイトで最も優先順位の低いサーバシステムを、障害迂回ターゲットとして選択する。「障害迂回ターゲット」は、再起動しなければならないアプリケーショングループをホストするよう選択されるシステムである。例えば、優先順位は、SystemList={server1,server2}等の“システムリスト”の順位により暗黙裏に、または、SystemList={server1=0,server2=1}等と、“システムリスト”で優先順位を設定することにより明示的に設定できる。“優先順位障害迂回ポリシー”の方策は、単純な２ノードクラスタ、または少数のアプリケーショングループを有する小さなクラスタでは十分に機能する。

“ラウンドロビン障害迂回ポリシー”は、障害迂回ターゲットとして最小数のアプリケーショングループを実行しているサーバシステムを選択する。“ラウンドロビン障害迂回ポリシー”は、基本的に同一のサーバ負荷特性を有する多数のアプリケーショングループを実行している、より大きなクラスタ（例えば、類似のデータベースまたはアプリケーションを実行しているサーバ）で用いられることが多い。

本発明で説明する“負荷障害迂回ポリシー”は、データセンタのサーバ連結のフレームワークを可能にする。好適な実施の形態では、“負荷障害迂回ポリシー”は、“システム容量”、“アプリケーショングループ負荷”、“システム限界”、および“アプリケーショングループ必要条件”を考慮に入れる。

負荷障害迂回ポリシー：容量および負荷
一実施の形態では、システムのためのシステム“容量”変数、本明細書では“容量”とも称する、は、システムの負荷対応容量を表す固定値に設定する。アプリケーションのためのアプリケーショングループ“負荷”変数、本明細書では“負荷”とも称する、は、アプリケーショングループによりプロセッサ上に配置される固定された要求（“負荷”）に設定する。例えば、２台の１６プロセッササーバ、および２台の８プロセッササーバから成る４ノードクラスタを考える。管理者は、１６ＣＰＵサーバの“容量”値を２００に、８ＣＰＵサーバを１００に設定する。これらの“容量値”は、任意に割り当てることができるが、各システムの容量差を反映させなければならない。
同様に、システムで実行している各アプリケーショングループは、所定の“負荷”値を有する。アプリケーショングループがオンラインにできる場合は、アプリケーショングループの“負荷”を、システムの利用可能容量から減算する。

一実施の形態では、クラスタ管理アプリケーションは、各システムに対する“利用可能容量”変数を用いて、クラスタ内のすべてのシステムの利用可能容量の追跡を継続する。“利用可能容量”は、システム上のオンラインのすべてのアプリケーショングループ（アプリケーショングループが完全に、または部分的にオンラインである場合は、そのアプリケーショングループをオンラインと見なす）の“負荷”を、システムの“容量”から減算して決定する。障害迂回が発生した場合、クラスタ管理アプリケーションは、最大の“利用可能容量”を有するシステムを決定し、そのシステム上でアプリケーショングループを開始する。多数のアプリケーショングループが関わる障害迂回状況が発生している間は、障害迂回決定を順次行って、適切な負荷に基づく選択を容易にするが、代替システム上にオンラインアプリケーションをもたらすオンライン操作は、並列に実行できる。
“容量”は、“利用可能容量”の値がゼロ未満になることもあることを示す緩やかな制約である。障害が連続して発生する状況では、“利用可能容量”は負になることもある。

負荷障害迂回ポリシー：静的負荷対動的負荷
サーバの動的な負荷は、公式“利用可能容量＝容量−（全オンラインアプリケーショングループの負荷合計）”を用いて計算できる。動的負荷を決定するための代替の方策は、VERITAS（商標）クラスタサーバ（Cluster Server）(略称VCS)の、VCS 2.0以前の初期バージョンを含む幾つかのクラスタ管理アプリケーションにより提供される。これらのクラスタ管理アプリケーションにより、管理者は、外部の監視プログラムでサーバの動的負荷を決定し、“動的負荷”変数を設定して決定値を反映させることができる。管理者は、所望の任意の監視パッケージプログラムを実行し、次いで、推定負荷をクラスタ管理アプリケーションに提供できる。そのように“動的負荷”を提供した場合、“負荷”計算値をオーバーライドして、この値を用いることができる。例えば、“利用可能容量”は、公式“利用可能容量＝容量−動的負荷”を用いて計算できる。この計算により、管理者は、推定アプリケーショングループ負荷を用いるよりも正確にシステム負荷を制御できる。

しかし、管理者は、クラスタ管理アプリケーションに加えて、負荷推定パッケージプログラムを組み込んで保守管理しなければならない。“負荷障害迂回ポリシー”を用いる幾つかのクラスタ管理アプリケーションでは、“動的負荷”変数の最小値を有するシステムを、障害迂回ターゲットとして選択する。
要約すると、アプリケーショングループをホストする全システムの利用可能容量は、以下の公式を用いて計算できる：
システムの“利用可能容量＝容量−現在のシステム負荷”
ここで、
“現在のシステム負荷”＝動的システム負荷変数が指定されている場合は、“動的な”システム負荷
または、システム上のすべてのオンラインアプリケーショングループの“負荷”合計

負荷障害迂回ポリシー：限界および必要条件
システム“限界”、およびアプリケーショングループ“必要条件”も、業務継続ポリシーで用いることができる。管理者は、各システムで利用可能な、共有メモリセグメント、セマフォ、および他のリソース等の有限リソース（“限界”）を提供できる。例えば、特定のサーバは、２つ以下のデータベースアプリケーションのみをホストすることが可能であってもよい。更に、それぞれが利用可能なシステムリソースおよび／または容量と対応する一組の“必要条件”を、アプリケーショングループ毎に確立できる。例えば、特定のデータベースアプリケーションは、５つの共有メモリセグメントと２０のセマフォを示す“必要条件”を必要とし、かつ有してもよい。

一実施の形態では、アプリケーショングループの、一組の“必要条件”で指定されるすべての“必要条件”を満たしてから、アプリケーショングループを開始しなければならない。一実施の形態では、システムが既に許容“限界”に達した場合に、システムが障害迂回ターゲットとして選択されることがないように、システム“限界”はオーバーライドされない。

本発明の業務継続ポリシーのもとでは、障害を起こしたアプリケーショングループの“必要条件”を満たし、アプリケーショングループの“負荷”に対応できる適格な一組のシステム集合を識別する。この一組のシステムは、障害発生したアプリケーショングループを受入れ、システム“限界”内に留めるための十分な“利用可能容量”をも有するこれらのシステムだけに限ることができる。この一組の適格なシステムから、最小負荷のシステムを、障害迂回ターゲットとして選択できる。アプリケーショングループの全ての“必要条件”を満たさないシステムは、障害迂回ターゲットとして選択できない。アプリケーショングループを特定システム上でオンラインにするという決定が成された場合、アプリケーショングループが必要とするシステムリソースの一組の“必要条件”変数の値を、システムの“現在の限界”から減算して、これらのシステムリソースが既に割り当てられていることを示す。

本発明の一実施の形態では、管理者は最初にアプリケーショングループの“必要条件”を定義し、次いで、各システムの対応する“限界”を定義する。本実施の形態では、各システムは、異なる“限界”を有することができ、各アプリケーショングループおよびシステムに適用可能な“必要条件”および“限界”だけが定義を必要とする。所定のシステムリソースについて定義した“限界”をシステムが有していない場合、既定値０を想定できる。同様に、“必要条件”が所定のシステムリソースについて定義されていない場合、既定値０を想定できる。

“必要条件”および“限界”変数の定義の例として、所定の時点で以下の構成を確立して、システム上にただ一つのグループをオンラインにできる：
“必要条件”＝｛“グループ重み付け”＝１｝
“限界”＝｛“グループ重み付け”＝１｝
“必要条件のグループ重み付け”１を指定することにより、唯一つのアプリケーショングループを所定の時点でオンラインにすることができる。更に、システム毎に“グループ重み付けの限界”値１を指定することにより、システム毎に、ある時点で唯一つのアプリケーショングループを有することができる。“グループ重み付け”値は、オンラインにできるアプリケーショングループの数を表すと考えることができる。“グループ重み付け”値がゼロの場合、その特定システム上に、それ以上のアプリケーショングループをオンラインにできない。例えば、２つのシステムＳ１、Ｓ２を有するシステムを考える。それぞれは“グループ重み付けの限界”＝１に指定する。また、システムは、３つのアプリケーショングループＧ１、Ｇ２、およびＧ３も有する。グループＧ１およびＧ２は、“グループ重み付けの必要条件”＝１を有し、グループＧ３は“必要条件”を持たない。Ｇ１およびＧ２に対する“グループ重み付け”＝１の“必要条件”が示すのは、Ｇ１およびＧ２それぞれは、オンラインにする“グループ重み付け”のひとつの「単位」を必要とする、ということである。Ｇ１をＳ１でオンライン化する場合、Ｓ１の“現在の限界”は“グループ重み付け”＝０となり、従って、Ｇ２が同様にＳ１上でオンライン化されるのを妨げる。“必要条件”を持たないＧ３は、Ｓ１またはＳ２上でオンライン化できる。

“必要条件”および“限界”を用いて、障害迂回中または起動したときにアプリケーショングループを開始できる一組の適格なシステムを決定できる。一旦、“必要条件”および“限界”を満たしている一組の適格なシステムを識別すると、確立された“障害迂回ポリシー”は、適格システムのどの組を障害迂回ターゲットとして選択するかを指示する。

実施例システムおよびアプリケーショングループ属性
下記の表１は、本発明の業務継続ポリシーを実装するために用いることができるシステム属性を含む一実施の形態の例を提供する。表２は、アプリケーショングループ属性の実施例を提供する。

アプリケーショングループおよびシステム構成の達成
以下の構成ファイルmain.cfは、システム定義およびアプリケーショングループ定義を示す。

容量および必要条件の使用
“容量”および“必要条件”をともに用いると、適切な障害迂回システムの決定が可能である。一実施の形態では、所定のアプリケーショングループに対する“必要条件”を満たし、最大の“利用可能容量”を有するシステムが選択される。多数のシステムが所定のアプリケーショングループに対する“必要条件”を満足し、同じ“利用可能容量”を有する場合は、“システムリスト”の最初のシステムを選択できる。注意すべきは、システム“限界”が既に満たされている場合、アプリケーショングループの“必要条件”を満たすシステムは、アプリケーショングループをホストするのに適格でないこともある、ということである。システムの“現在の限界”が、所定のアプリケーショングループの“必要条件”を満たす十分なリソースを可能にする場合、システムの“限界”は既に満たされている。
先に説明したように、一実施の形態では、“容量”は緩やかな制限である。アプリケーショングループをシステム上で開始する場合に、負の“利用可能容量”値が生成されたとしても、最大の“利用可能容量”値を有するシステムを選択することができる。

過負荷警告
一実施の形態では、“負荷障害迂回ポリシー”の一部として過負荷警告が提供される。サーバが、“負荷時間閾値”変数で設定した所定時間の間、“負荷警告レベル”変数で設定する所定負荷レベルを保持する場合、過負荷警告が開始される。過負荷警告は、ユーザ定義スクリプト、または所定の企業の“障害迂回負荷ポリシー”を実装するよう設計したアプリケーションにより提供できる。例えば、ユーザ定義スクリプトは、オペレータのコンソール上にメッセージを提供してもよいし、あるいはユーザ定義スクリプトは、ユーザ定義の優先値に基づいてアプリケーショングループを移動または終了してもよい。例えば、業務にクリティカルなデータベースを実行しているサーバ上の“負荷”が限界に達し、かつユーザ定義閾値を超えたまま留まる場合、オペレータは直ちに通知を受けることが可能である。次いで、ユーザ定義スクリプトは、内部の“人的リソース”アプリケーション等の、そのデータベースより優先順位が低い任意のアプリケーショングループについてシステムを精査でき、優先順位の低いアプリケーションを終了するか、またはより小さい現在の“負荷”をもつシステムに移動させることができる。

システム領域
一実施の形態では、“システム領域”を用いて、最初の障害迂回決定で選択するシステムの好適なサブセットを示す。業務継続ポリシーを実装するクラスタ管理アプリケーションは、別の領域のシステムを選択する前に、アプリケーショングループ領域内のアプリケーショングループの再起動を試みる。例えば、ウェブサーバ、アプリケーションサーバ、およびデータベースサーバを有する典型的な３層構造のアプリケーションインフラストラクチャを考える。アプリケーションおよびデータベースのサーバは、単一クラスタで構成できる。“システム領域”を用いると、別のアプリケーション領域サーバが利用可能な場合、アプリケーショングループのクラスタ管理アプリケーションが、別のアプリケーション領域サーバに障害迂回しようと試みるのが可能になる。別のアプリケーション領域サーバが利用不可能な場合は、クラスタ管理アプリケーションは“負荷”および“限界”に基づくデータベース領域に障害迂回しようと試みることが可能である。この構成では、データベース領域で利用可能な過剰“容量”および“限界”は、データベース障害迂回のより大きな負荷のために予約される一方で、アプリケーションサーバは、アプリケーション領域のアプリケーショングループの“負荷”を扱う。障害が連続している間、クラスタの過剰な容量はアプリケーショングループに利用可能なまま残る。“システム領域”の特長は、アプリケーション障害迂回決定を精緻に調整することを可能にし、必要であればクラスタのどこにでも障害迂回する柔軟性を依然として保持する。

負荷に基づく自動開始
一実施の形態では、“負荷障害迂回ポリシー”の考え方を用いて、クラスタを最初に開始する場合、アプリケーショングループを取り上げる場所を決定できる。管理者は“自動開始ポリシー”変数を“負荷”に設定でき、クラスタ管理アプリケーションに、アプリケーショングループを開始する最良のシステムを決定させることができる。クラスタ管理アプリケーションが利用可能システムを決定する場合、負荷に基づいて起動するための“自動開始”待ち行列にアプリケーショングループを入れることができる。障害迂回と同様に、“必要条件および限界”を満たすシステムの一サブセットが最初に作成され、次いで、これらのシステムのうち、最高の“利用可能容量”をもつシステムが選択できる。
“自動開始ポリシー”＝“負荷”および“システム領域”をともに用いることにより、管理者が、クラスタの好適システムリストを確立して、最初にアプリケーショングループを実行することが可能になる。上記のように、３層構造で、管理者が指示できるのは、アプリケーショングループは最初にアプリケーション領域で開始し、データベースグループはデータベース領域で開始する、ということである。

負荷障害迂回ポリシーと併せたアプリケーション優先順位の使用
上記の“負荷障害迂回ポリシー”をアプリケーション優先順位と組み合わせることにより、ミッションクリティカルな、または業務上クリティカルなアプリケーションの真の自動化業務継続ポリシーが提供される。この業務継続ポリシーは、必要な業務情報をクラスタフレームワークに追加して、障害発生した時に各ポリシーを駆使した決定を行い、クリティカルなアプリケーションおよびアプリケーション実行を最良状態に維持する。

アプリケーショングループ“優先順位”は、あるアプリケーションの重要性が相対的に他のアプリケーショングループの重要性を超えていることを管理者が特定できるようにする。何らかの障害が発生している間、クラスタ管理アプリケーションは、アプリケーショングループ“優先順位”、“負荷”および“限界”に基づいて、適切な障害迂回システムを決定できる。大部分の単一アプリケーショングループまたは単一サーバの障害では、クラスタは十分な予備の容量を有するのがほとんどである。しかし、“災害復旧”イベント後の多数の障害、またはクラスタ容量減少を含む状況では、さらに困難な決定の必要に迫られる。

アプリケーショングループの“優先順位”は、優先順位決定を提供するクラスタメカニズムを効果的に提供する。ほとんどのクリティカルなアプリケーショングループは、優先順位の低いアプリケーションを犠牲にする可能性があるが、依然として適切な実行レベルで機能する。

一実施の形態では、以下の特性がアプリケーショングループに割り当てられる：
優先順位１−ミッションクリティカル
“優先順位”１のアプリケーショングループは、障害時に、オンラインに留まり、直ちに再起動されなければならない。クラスタ管理アプリケーションは、アプリケーショングループが特に障害を受けるか、またはオペレータが介入しない限り、“優先順位”１のアプリケーショングループを停止したり移動することを避けるよう構成できる。“優先順位”１のアプリケーショングループは、アプリケーショングループを再起動するのに必要な稼働停止時間だけは避けることができない。

優先順位２−業務クリティカル
“優先順位”２のアプリケーショングループは、“優先順位”１のアプリケーショングループより若干重要性が低い。クラスタ管理アプリケーションは、これらのアプリケーショングループをオンラインに維持しなければならないが、“優先順位”２のアプリケーショングループの別のサーバへの切り換え、移動を実行してクラスタ“負荷”特性を維持してもよい。

優先順位３−タスククリティカル
“優先順位”３のアプリケーショングループは、クラスタ負荷を維持するために自由に移動してよい。“優先順位”３のアプリケーショングループは、移動が不可能な場合においてのみ、クラスタの容量を扱う適当な“負荷”を維持するために停止させてもよい。

優先順位４−タスク非クリティカル
“優先順位”４のアプリケーショングループは、検査アプリケーションまたは各種の内部サポートプログラム等の、基本的でないアプリケーションである。これらのアプリケーショングループは、クラスタ負荷を維持するために自由に停止してよい。何らかのクラスタ再構成の間は、クラスタ管理アプリケーションは、すべての“優先順位”４のアプリケーショングループを計算から除外し、再構成のために最良の提案をすることができる。“優先順位”４のアプリケーションは、クラスタに十分な負荷容量が残っているとクラスタ管理アプリケーションが決定した場合、クラスタにオンラインでのみもたらされてもよい。

図３は、サーバ連結環境に業務継続ポリシーを実装するための方法のフローチャートである。その方法は、ここではアプリケーショングループＸと呼ばれる所定のアプリケーショングループの起動時または障害時に、“アプリケーショングループＸの起動または障害”ステップ３１０で開始される。アプリケーショングループＸをホストする一組の適格システムは、“アプリケーショングループＸをホストする適格システム集合を決定する”ステップ３２０で識別される。判断点３２２の“集合サイズ＞０”で、どの適格システムを識別するかの決定が成される。決定したら、制御は“ホストシステムを選択する”３２４に進み、アプリケーショングループＸを実行するためのホストシステム（起動時または障害迂回ターゲット設定時の最初のシステム）を選択する。例えば、最大の“利用可能容量”を有する適格なシステムとして、ホストシステムを選択できる。他のポリシーを用いて、業務継続ポリシーを実装する業務の必要性に基づいて、ホストシステムを選択することもできる。次いで、制御は、“ホストシステム上のアプリケーショングループＸを開始する”ステップ３５０に進み、選択されたホストシステム上のアプリケーショングループＸを開始する。

判断点３２２の“集合サイズ＞０”で、集合が、アプリケーショングループＸをホストするための適格なシステムを含まない場合、制御は、“アプリケーショングループＸの優先順位を決定する”ステップ３３０に進む。クラスタ上で実行されるすべてのアプリケーショングループの間でアプリケーショングループＸに対する各優先順位が決定される。所定のアプリケーショングループの優先順位は、構成可能であり、サーバ連結環境の管理者により割り当てることができる。例えば、アプリケーショングループＸの各優先順位を決定するために、サーバ連結環境におけるクラスタを管理するクラスタ管理アプリケーション用に格納されるデータから、優先順位を検索できる。

“アプリケーショングループＸの優先順位を決定する”ステップ３３０から、制御は、“クラスタ内の低優先順位アプリケーショングループ”判断点３３２に進む。低優先順位アプリケーションが実行されていなければ、制御は、“アプリケーショングループＸが開始できないことを管理者に通知する”ステップ３３６に進む。適格なシステムがアプリケーショングループＸに対して存在しないので、アプリケーショングループＸは、同一か、またはより高い優先順位の別のアプリケーションに代わって開始することはできない。管理者は、“アプリケーショングループＸ”が取って代わられるべきかどうかを決定できる。一実施の形態では、アプリケーショングループが再起動できない状況を扱うための処理は、クラスタ管理アプリケーション内に構成可能であり、ユーザ定義スクリプトとして提供される。

“クラスタ内の低優先順位アプリケーショングループ”判断点３３２で、低優先順位アプリケーショングループが実行されている場合、制御は、判断点３３８の“十分な容量およびリソースを解放して、アプリケーショングループＸを受入れることができるか”に進む。判断点３３８の“十分な容量およびリソースを解放して、アプリケーショングループＸを受入れることができるか”では、クラスタのシステム内の利用可能リソースの評価が成される。図５を参照して、この評価をさらに詳細に説明する。

十分な容量およびリソースが解放できない場合、制御は、“アプリケーショングループＸが開始できないことを管理者に通知する”ステップ３３６に進む。十分な容量およびリソースが解放できる場合は、制御は、“ホストシステムの十分な容量およびリソースを解放する”ステップ３４０に進む。
“ホストシステムの十分な容量およびリソースを解放する”ステップ３４０では、容量およびリソースが一つ以上のシステムで解放され、アプリケーショングループＸに十分なリソースが所定のホストシステムで実行できるようにする。“ホストシステムの十分な容量およびリソースを解放する”ステップ３４０から、制御は、“ホストシステム上でアプリケーショングループＸを開始する”ステップ３５０に進む。

図４は、図３の“アプリケーショングループＸをホストする一組の適格システムを決定する”ステップ３２０のフローチャートである。“クラスタからシステムを選択する”ステップ４１０で、前に評価されていないシステムのクラスタ内の１システムは、システムが適格であるかどうかを決定するよう選択される。次いで、制御は、“選択したシステムがアプリケーション要件を満たすか”の判断点４１２に進む。選択したシステムが、アプリケーショングループＸの必要条件等の、アプリケーショングループＸの要件を満たさない場合、制御は、“残るとは考えられないシステム”判断点４２２に進み、別のシステムが評価に利用可能かどうか決定する。

選択したシステムがアプリケーショングループＸの要件を満たす場合、制御は、“選択システムはシステム要件を満たすか”の判断点４１４に進む。例えば、選択したシステムがその“限界”内にあるかどうかの決定は、システムの“現在の限界”を“アプリケーショングループＸ”の“必要条件”に加えることにより成される。その合計は、“限界”基準を満たすために、選択したシステムの“限界”未満でなければならない。別の例として、システム要件は、特定ＣＰＵがある利用率未満のままであるということであってもよい。選択したシステムがそのシステム要件を満たさない場合、制御は、“残るとは考えられないシステム”判断点４２２に進み、別のシステムが評価に利用可能かどうかを決定する。

選択したシステムが、“選択システムはシステム要件を満たすか”の判断点４１４でのシステム要件を満たさない場合、制御は、“選択システムを一組の適格システムに加える”ステップ４２０に進む。次いで、制御は、”残るとは考えられないシステム”判断点４２２に進み、別のシステムが評価に利用可能かどうかを決定する。
”残るとは考えられないシステム”判断点４２２では、どのシステムもクラスタに残るとは考えられていないかどうかの決定が成される。ＹＥＳであれば、“システムを選択する”ステップ４１０に進んで、別のシステムを選択する。ＮＯであれば、適格システムの集合は完全であり、制御は、図３の“集合サイズ＞０”の判断点３２２に戻る。

図５は、図３の“十分な容量およびリソースを解放して、アプリケーショングループＸを受入れることができるか”の判断点３３８のフローチャートである。最初の決定は、判断点５１０の“優先順位４の十分なリソースは停止できるか”で成される。優先順位４の十分なリソースが停止できる場合、制御は、“ホストシステムおよび優先順位４のリソースを選択して解放する”ステップ５２０に進む。このステップでは、優先順位４の十分なリソースを有するシステムをシステムとして選択して、アプリケーショングループＸをホストする。制御は、“十分なリソースが解放できることを示す”ステップ５６５に進む。図５のフローチャートは終了し、十分なリソースが解放できることが示される。

“優先順位４の十分なリソースは停止できるか”の判断点５１０で、優先順位４の十分なリソースが解放できない場合、制御は、判断点５３０の“優先順位４の十分なリソースが停止でき、かつ優先順位３のリソースが移動できるか”に進む。優先順位４のアプリケーションが停止でき、かつ優先順位３のアプリケーションを他のシステムに移動することにより、システム上にアプリケーショングループＸのための十分なリソースが解放できる場合、制御は、“適切な優先順位３および４のリソースを解放するよう決定し、ホストシステムを選択する”ステップ５４０に進む。“適切な優先順位３および４のリソースを解放するよう決定し、ホストシステムを選択する”ステップ５４０で、優先順位４のどのアプリケーションを停止し、優先順位３のどのアプリケーションを移動させるかを決定する。幾つかの異なるシナリオにより必要なリソースが解放できる場合、最小数のリソースを停止し、および／または優先順位が高い最大数のアプリケーションを実行可能に移動するように、構成を選択できることが好ましい。次いで、制御は、“十分なリソースが解放できることを示す”ステップ５６５に進む。図５のフローチャートは終了し、十分なリソースが解放できることが示される。

“優先順位４の十分なリソースが停止でき、かつ優先順位３のリソースが移動できるか”の判断点５３０で、十分なリソースが利用不可能な場合、制御は、判断点５５０の“優先順位４の十分なリソースが停止でき、かつ優先順位２および３のリソースが移動できるか”に進む。ＹＥＳであれば、制御は、“適切な優先順位２、３および４のリソースを解放するよう決定し、ホストシステムを選択する”ステップ５６０に進む。繰り返すが、最小数のリソースを停止し、優先順位が高い最大数のアプリケーションを実行可能に移動することが好ましい。次いで、制御は、“十分なリソースが解放できることを示す”ステップ５６５に進む。図５のフローチャートは終了し、十分なリソースが解放できることが示される。
“適切な優先順位２、３および４のリソースを解放するよう決定し、ホストシステムを選択する”ステップ５６０で、十分なリソースがクラスタ内に利用不可能な場合、制御は“十分なリソースが解放できないことを示す”ステップ５７０に進む。図５のフローチャートは終了し、十分なリソースが解放できないことが示される。

図６〜図１６は、本発明の業務継続ポリシーの範囲内にある多数のシナリオを説明する。
図６は、サーバ連結環境におけるサーバクラスタのための利用可能容量の計算を示す。サーバ６１０Ａ、６１０Ｂ、６１０Ｃ、および６１０Ｄは、クラスタを形成する。サーバ６１０Ａ、６１０Ｂ、および６１０Ｃはそれぞれ容量３００を有し、サーバ６１０Ｄは、容量１５０を有する。サーバ６１０Ａは、サーバ６１０Ａ上に“負荷”１００を配置するMicrosoft Exchange（XCH）バージョン５．５を実行している。また、サーバ６１０Ａは、サーバ６１０Ａ上に“負荷”１５０を配置するデータベースアプリケーショングループ、Oracle 8iも実行していて、合計“負荷”は２５０である。サーバ６１０Ｂは、サーバ６１０Ｂ上に“負荷”１２５を配置するSQL2000サーバを実行している。サーバ６１０Ｃは、サーバ６１０Ｃ上に“負荷”７５を配置するファイル共有アプリケーショングループFileShare1を実行している。サーバ６１０Ｄは、サーバ６１０Ｄ上に負荷１５０を配置する２つのファイル共有アプリケーショングループFileShare2、およびFileShare3を実行している。所定のサーバ上で実行している各アプリケーショングループのそれぞれの“負荷”を、所定のサーバの“容量”から減算することにより、“利用可能容量”は、サーバ６１０Ａでは５０、サーバ６１０Ｂでは１７５、サーバ６１０Ｃでは２２５、そしてサーバ６１０Ｄではゼロと計算される。利用可能容量２２５を有するサーバ６１０Ｃは、クラスタ内で最大の利用可能容量を有する。

図７は、図６のサーバの一つに障害が発生したときのアプリケーションの移動、およびその結果クラスタ内に生じる利用可能な容量を示す。サーバ６１０Ｄが障害を起こし、ファイル共有アプリケーションFileShare1およびFileShare2を放棄するので、可能なら、クラスタ内の他のサーバに再配布する。図７は、サーバ６１０ＣへのFileShare2の移動を示す。サーバ６１０Ｃが選択されるのは、サーバ６１０Ｃが最大の利用可能容量を提供するからである。サーバ６１０ＣへFileShare2が移動した結果、サーバ６１０Ｃの“負荷”は１５０に増大し、サーバ６１０Ｃの利用可能容量は、１５０に低下する。利用可能容量１７５のサーバ６１０Ｂが、今度はクラスタ中で最大利用可能容量を有することになる。

図８は、図７の障害のシナリオでの別のアプリケーションの移動を示す。FileShare3は、サーバ６１０Ｄから、最大利用可能容量を有するサーバ、サーバ６１０Ｂに移動される。この移動の結果、サーバ６１０Ｂに配置される“負荷”は、２００に増大し、サーバ６１０Ｂの利用可能容量は１００に減少する。

図９は、図６のクラスタにおけるデータベースアプリケーションの構成例を示し、サーバ６１０Ａから６１０Ｄはそれぞれ容量３００で構成されている。サーバ６１０Ａは２つのSQL2000データベースアプリケーショングループ、SQL2000データベースＡ、およびSQL2000データベースＢ、を実行している。SQL2000データベースＡ、およびSQL2000データベースＢはそれぞれ、サーバ６１０Ａに負荷１００を配置している。サーバ６１０Ａは、SQL限界２で構成され、サーバ６１０Ａが、同時に２つ以上のSQLデータベースを実行することができないことを示す。サーバ６１０Ａの利用可能容量は３００−２００＝１００である。

同様に、サーバ６１０Ｂは、SQL限界２を有し、SQL2000データベースＣを実行していて、サーバ６１０Ｂに負荷１００を配置している。サーバ６１０Ｂは、利用可能容量２００を有する。サーバ６１０Ｃは、SQL2000データベースＥを実行していて、サーバ６１０Ｃに負荷１００を配置している。同様に、サーバ６１０Ｃは、利用可能容量２００を有する。サーバ６１０Ｄは、SQL限界３を有し、SQL2000データベースＤを実行していて、サーバ６１０Ｄに“負荷”１５０を配置している。サーバ６１０Ｄは、利用可能容量１５０を有する。

図１０は、図９の構成における障害のシナリオでのデータベースアプリケーションの移動を示す。サーバ６１０Ｃが障害を発生し、SQL2000データベースＥを放棄して、別のサーバ上で再起動させる。SQL2000データベースＥは、サーバ上の“負荷”１００を配置する。サーバ６１０Ａが、既に限界２のサーバSQLアプリケーションに達しているので、サーバ６１０Ａは、SQL2000データベースＥをホストすることができない。サーバ６１０Ｂまたはサーバ６１０Ｄはいずれも、ホスト可能なSQLアプリケーション数の限界に達せず、サーバ６１０Ｂおよびサーバ６１０Ｄはともに、SQL2000データベースＥを実行する十分な利用可能容量を有する。示されるシナリオの例では、サーバ６１０Ｂが選択される。なぜなら、２つの適格システムのうちでサーバ６１０Ｂが最大の利用可能容量を有しているからである。SQL2000データベースＥを移動した後、サーバ６１０Ｂに配置される負荷は２００に増大し、サーバ６１０Ｂの利用可能容量は１００に減少する。

図１１は、限界および必要条件を用いる管理アプリケーショングループ例を示す。この例では、アプリケーショングループＧ１のファイル共有アプリケーション、アプリケーショングループＧ２の検査アプリケーション、アプリケーショングループＧ３のMicrosoft Exchangeアプリケーション、およびアプリケーショングループＧ４のSQLサーバアプリケーショングループを含む４つのアプリケーショングループを考える。優先順位３のアプリケーショングループであるアプリケーショングループＧ１に必要なことは、サーバに対する“グループ重み付け”変数が値１を有してから、アプリケーショングループＧ１をそのサーバ上で実行できる、ということである。優先順位４のアプリケーショングループであるアプリケーショングループＧ２に必要なことは、サーバに対する“グループ重み付け”変数が値２を有してから、アプリケーショングループＧ２をそのサーバ上で実行できる、ということである。優先順位１のアプリケーショングループであるアプリケーショングループＧ３に必要なことは、サーバに対する“グループ重み付け”変数が値２を有してから、アプリケーショングループＧ３をそのサーバ上で実行できる、ということである。最後に、優先順位２のアプリケーショングループであるアプリケーショングループＧ４に必要なことは、サーバに対する“グループ重み付け”変数が値２を有してから、アプリケーショングループＧ４をそのサーバ上で実行できる、ということである。

サーバ６１０Ａからサーバ６１０Ｄは、アプリケーションＧ１からＧ４をそれぞれ実行している。これらの実行しているアプリケーショングループにより、サーバ６１０Ａから６１０Ｄは、それぞれ“限界”２、３、２および３を有する。サーバ６１０Ａから６１０Ｄは、“現在の限界”値１、１、０および１をそれぞれ有する。

図１２は、アプリケーショングループが障害迂回できない障害のシナリオを示す。サーバ６１０Ｃが障害を発生し、どのサーバも、別のサーバ上で開始すべきアプリケーショングループＧ３に対する必要条件である“現在の限界”値２を有していない。アプリケーショングループが障害迂回できない場合、実行しているアプリケーションの優先順位を検査して、十分なリソースがクラスタ内に解放でき、アプリケーショングループが実行できるかどうかを決定する。アプリケーショングループＧ３は、優先順位１のアプリケーションであり、アプリケーショングループＧ２からＧ４のそれぞれは、より低い優先順位のアプリケーショングループである。最初に、優先順位４の十分なリソースが、アプリケーショングループＧ３に十分なリソースを解放するよう存在するかどうかの決定が成される。アプリケーショングループＧ２は、優先順位４のリソースであり、２つの“グループ重み付け”単位を消費する。アプリケーショングループＧ２が解放される場合、アプリケーショングループＧ３を実行するのに必要な２つの“グループ重み付け”単位が解放され、アプリケーショングループＧ３は、サーバ６１０Ｂ上で開始できる。

図１３は、優先順位が低いアプリケーショングループを停止して十分なリソースを解放し、優先順位が高いアプリケーショングループを利用可能なままとすることを示す。図１２のシナリオで、アプリケーショングループＧ２は、アプリケーショングループＧ３を実行可能にする十分なリソースを提供するよう決定された。アプリケーショングループＧ２は停止され、アプリケーショングループＧ３はサーバ６１０Ｂに移動される。サーバ６１０Ｂの“現在の限界値”は再計算されて、ここで値１を有する。

図１４は、図１２および図１３の構成に対する別の障害迂回シナリオを示す。仮定するのは、今度はサーバ６１０Ｄが障害を発生し、再起動すべきアプリケーションＧ４を放棄する。アプリケーショングループＧ４は、別のサーバで開始されるように“グループ重み付け”値２を必要とする。残っているサーバ６１０Ａまたは６１０Ｂは何れも“グループ重み付け”値２を提供しない。従って、アプリケーショングループＧ４を利用可能のままとするよう十分なリソースを解放できるかどうかの決定が成される。優先順位が低いリソースを検査してこの決定を行う。

図１５は、十分なリソースを解放して優先順位が高いアプリケーショングループを利用可能なままにするための低優先順位アプリケーショングループの移動を示す。優先順位３のアプリケーションであるアプリケーショングループＧ１は、優先順位２のアプリケーショングループＧ４より優先順位が低い。さらにアプリケーショングループＧ１を移動することにより、サーバ６１０Ａの“グループ重み付け”値は、アプリケーショングループＧ４の必要条件を満たす２まで上昇できる。アプリケーショングループＧ１の必要条件は、サーバ６１０Ｂが提供する“グループ重み付け”値１である。アプリケーショングループＧ１は、サーバ６１０Ｂに移動してサーバ６１０Ａ上のリソースを解放する。移動した結果、サーバ６１０Ａは“グループ重み付け”値２を有し、サーバ６１０Ｂは“グループ重み付け”値０を有する。

図１６は、図１５に示す対応の結果として、解放されたリソースを用いるための高優先順位アプリケーショングループの移動を示す。アプリケーショングループＧ１の移動後、サーバ６１０Ａは、十分なリソースを有してアプリケーショングループＧ４をホストする。“グループ重み付け”が値２を有するアプリケーショングループＧ４の必要条件は、真である。アプリケーショングループＧ４の移動後、サーバ６１０Ａは、“グループ重み付け”値０を有する。

上記のシナリオは、本明細書で説明する業務継続ポリシーにより扱うことができる多数の障害状況の例である。これらのシナリオの多くの改変、および業務継続ポリシーを実装するための代替の変形は、本発明の一部と考えられ、本発明の範囲内にある。さらに、本明細書の“追加の実施例”セクションで、実施例のシナリオを提供する。

リソース管理統合
主要なオペレーティングシステムのほとんどは、Solarisリソースマネージャ、HPプロセスリソースマネージャ、およびA1Xリソースマネージャ等の、対応するリソースマネージャを有する。本明細書ではまとめてｘＲＭと呼ぶこれらのリソースマネージャは、ＣＰＵおよびメモリ利用を管理者が制御できるようにする。しかしながら、ｘＲＭパッケージは、ｘＲＭパッケージを実行しているシステムだけを認識し、クラスタ内の他のシステムは認識しないのが普通である。本発明の業務継続ポリシーをサポートするクラスタ管理アプリケーションを、ｘＲＭパッケージとともに統合し、クラスタ内の全システムのリソース利用、つまり“負荷”、を制御するのが好ましい。

各オペレーティングシステムのベンダーは、異なるインターフェースおよび異なる能力のプラットフォームのリソースマネージャを提供している。例えば、Solaris9は、「タスクＩＤ」の考え方をサポートし、その考え方は、タスクＩＤのもとで起動した特定プロセスを、「プロジェクト」データベースに課された制限と結びつける。同一のオペレーティングシステムプラットフォームを横断する柔軟性を最大に維持し、操作を保持するために、クラスタ管理アプリケーションは、ＡＰＩ階層を提供して、各種のｘＲＭパッケージと通信する。少なくとも、“負荷障害迂回ポリシー”は用いることができる。クラスタ管理アプリケーションが、ｘＲＭ統合能力をもつオペレーティングシステムプラットフォーム上でも実行されている場合、“負荷”および“限界”を完全に強化することが可能である。

一実施の形態では、管理者は、個々のシステムではなく、クラスタ定義において一回だけリソース利用パラメータを構成できる。クラスタ管理アプリケーションは、アプリケーショングループをシステム上で開始する場合、各システム上のｘＲＭ特有のエージェントと協働して、特定アプリケーショングループへのリソースの割り当てを制御する。これにより、単一点管理、およびクラスタ内の負荷分配制御をさらに強力にすることが可能になる。

アプリケーショングループの“負荷”の値を変更することにより、管理者は、アプリケーショングループがシステム上に配置すると期待される全負荷、およびアプリケーショングループが受け取ると期待されるシステムの共有の両方を設定する。例えば、“負荷”２００をもつ３つのアプリケーショングループがそれぞれ、容量８００をもつサーバ上で実行されている場合、各アプリケーショングループは、利用可能リソースの１／３を効率的に受け取る。このシナリオでは、特定アプリケーショングループの“負荷”値を４００に上げると、幾つかのことが達成される。最初に、負荷値を上げると、修正したアプリケーショングループに対するリソースの割り当てを増加する。このアプリケーショングループは、利用可能なＣＰＵおよびメモリの５０％を受け取り、残りの２つのアプリケーショングループが、それぞれ２５％を受け取る。第２に、“負荷値”を上げると、サーバを１００％負荷レベルに置き、“利用可能容量”を０に減少させる。この状況は過負荷警告を生じる。“負荷値”を上げることは、システム負荷がもっと重くなるとクラスタ管理アプリケーションに伝えるだけでなく、アプリケーションの性能を増大させるよう機能する。

モデル化およびシミュレーションエンジン
モデル化およびシミュレーションエンジン（ＭＳＥ）は、クラスタ管理アプリケーションの能力を提供して、「仮説検証（What-if）」モデルに基づき、アプリケーショングループの考えられる限り最高の構成を決定できる。現在の負荷および限界だけに基づいてシステムを選択するのではなく、クラスタ管理アプリケーションが、クラスタを再構成して、考えられる限り最高の性能をもつアプリケーショングループを提供する方法を決定する。再構成は、各種のアプリケーショングループ特性を考慮して、移動できるアプリケーショングループ、および移動できないアプリケーショングループを決定する。「最高性能」および「最小切り換え」等の各種パラメータをＭＳＥに与えて、クラスタ管理アプリケーションに、クラスタ再構成を実行して、アプリケーショングループの性能を最高にするか、または稼働停止時間を最小にするかどうかを決定させることもできる。

ＭＳＥは、シミュレーション能力を含んで、管理者に、任意のクラスタ再構成について、仮説検証の完全なシナリオを実行させることもできる。例えば：
クラスタから３２ＣＰＵのサーバ１を選択したらどうなるか？最高性能の再構成モデルは何か？どのアプリケーションが稼働停止により停止するか？再構成移動によって、どのアプリケーションを停止させるか？この展開中に優先順位１を移動させるとどうなるか？等である。
４台の１６ＣＰＵの追加のコモディティサーバを自分のクラスタ、およびストレージエリアネットワークに追加するとどうなるか？最高性能の構成は何か？どのアプリケーションを移動中に停止させるか？この構成が提供する予備の容量は幾つか？
大規模なデータベースをオンラインにしたい。最良の配置をどこにすればよいか？どの再構成が最良の適合を提供するか？

ＭＳＥは、“負荷”および“限界”の現在の考え方を堅固に強化でき、また、“障害迂回ポリシー”の利用をさらに良好にする再構成を可能にする。例えば、大規模なデータベース（共有メモリおよびセマフォＸ２）を加える再構成等であり、どのシステムも“限界”内に十分な容量をもたず、提案された障害迂回ポリシーはエラーとなる。ＭＳＥが決定できるのは、２つのシステムが利用可能な十分なリソースを提供する、ということであるが、それぞれは小さなデータベース（共有メモリおよびセマフォ）を実行している。クラスタ管理アプリケーションは、２つの小さなデータベースを一つのサーバに連結して、大規模データベースのために第２サーバを解放することを提案できる。

クラスタ再構成
クラスタ再構成は、手動または自動のいずれであれ、クラスタ管理アプリケーションにより提供される能力を参照して、アプリケーショングループ、ひいてはクラスタを横断する負荷を再割り当てし、システム“負荷”のバランスを良好にする。この再構成は、障害、サーバ追加および削除、またはアプリケーショングループ追加または削除に応じて行うことができる。クラスタ管理アプリケーションのＭＳＥ要素によりクラスタ再構成を実行して、固定したクラスタリソースを割り当てることができる。優先順位３および優先順位４のアプリケーショングループを移動する場合、クラスタ再構成モジュールは自動的に実行できるようにでき、特定パラメータを設定すれば、優先順位２のアプリケーショングループに関して自動的に実行できる可能性があり、優先順位１のグループに対しては、手動（オペレータ応答）である。

クラスタ再構成能力は、オンラインまたは切り換えの手動アプリケーショングループが要求される場合には、介入できる。オンラインのアプリケーショングループを移動または持ってくるようユーザが要求する場合、ＭＳＥはそれが可能であるということをユーザに通知でき、再構成シーケンスを推奨して良好なリソースの割り当てを行う。

追加実施例
以下の実施例は“限界”および“必要条件”を用いて、システム上で実行できるアプリケーショングループの全数を制御する。クラスタは４台の類似のサーバから成る。５つのアプリケーショングループがあり、各アプリケーショングループがシステムに要求する処理パワーの要件、および“負荷”の量は、ほぼ等しい。各サーバは、２つのかかるアプリケーショングループをホストできる。この実施例は、アプリケーショングループ“負荷”およびシステム“容量”を用いない。また、アプリケーショングループは、既定の“自動開始ポリシー”および“障害迂回ポリシー”を用いる。

限界を有する構成ファイル実施例

自動開始動作
この実施例は、既定の“自動開始ポリシー”＝“順位”を用いる。アプリケーショングループは、“自動開始リスト”にある利用可能な第１のシステム上にオンラインとなる。この方法では、Ｇ１はＳｖｒ１上、Ｇ２はＳｖｒ２上で開始され、以下同様である。Ｇ５はＳｖｒ２上で開始される。

通常動作
クラスタ構成実施例（全システムが実行されていると仮定する）を以下に示す：

障害シナリオ
第１の障害シナリオで、Ｓｖｒ２が障害を発生していると仮定する。アプリケーショングループＧ２およびＧ５は同一の“システムリスト”により構成されているので、両アプリケーショングループともに任意のシステム上で実行できる。クラスタ管理アプリケーションは、２つのグループの障害迂回のノードの選択を順番に行うことができる。標準では最初となるＧ２は、“システムリスト”で最低の優先順位であるＳｖｒ１上で開始され、それにより、Ｓｖｒ１の“限界”を使い果たす。次いで、Ｇ５は、グループＧ５の“システムリスト”の順で次のシステム上で開始される。Ｇ５はＳｖｒ３上でオンラインで実行される。最初の障害に続いてクラスタはここで次のようになる：

連続障害
Ｓｖｒ２が直ちに修理できない場合、クラスタはＳｖｒ２またはＳｖｒ３上の個々のアプリケーショングループの障害を許容できるが、それ以上のノード障害には不可能である。

負荷に基づく実施例
下記のクラスタ見本は、単純な負荷に基づく起動および障害迂回の使用を示す。“システム領域”、“限界”、および“必要条件”は用いない。
クラスタは４つの同一のシステムから成り、それぞれは同一の容量を有する。様々な負荷をもつ８つのアプリケーショングループ、Ｇ１〜Ｇ８がクラスタ中で実行されている。

構成ファイル例

自動開始動作
上記のように、アプリケーショングループは、システム上で開始されると直ぐに待ち行列に配置される。本実施例では、アプリケーショングループは、アプリケーショングループＧ１〜Ｇ８が記述されるのと同じ順序で待ち行列に配置される。

Ｇ１は最大の“利用可能容量”をもつシステム上で開始される。システムは同等なので、標準では最初であるＳｖｒ１が選択される。Ｇ２〜Ｇ４は、Ｓｖｒ２からＳｖｒ４上で開始される。この時点で、最初の４グループの起動決定が成されるので、クラスタは以下のようになる：

残りのアプリケーショングループは、オンラインとなり、Ｇ５は、最大の“利用可能容量”をもつので、Ｓｖｒ４上で開始される。Ｇ６は、残り８０を持つＳｖｒ１上で開始される。Ｇ７は“利用可能容量”＝７０を持つＳｖｒ３上で開始される。Ｇ８は“利用可能容量”＝６０を持つＳｖｒ２上で開始される。

通常動作
最終的なクラスタ構成（Ｇ１〜Ｇ８の元の待ち行列を仮定している）を以下に示す：

この構成では、Ｓｖｒ２が既定の“負荷警告レベル”８０％を有するので、既定値の９００秒後に、過負荷警告がＳｖｒ２に提供される。

障害シナリオ
最初の障害シナリオで、Ｓｖｒ４が障害を発生したと仮定すると、障害決定のためにＧ４およびＧ５を直ちに待ち行列に入れる。Ｇ４は、Ｓｖｒ１およびＳｖｒ３が“利用可能容量”＝５０をもち、Ｓｖｒ１が標準では最初なので、Ｓｖｒ１上で開始される。Ｇ５はＳｖｒ３上でオンラインで実行される。Ｓｖｒ１の“障害決定”は、連続的に成され、実際のオンラインおよびオフラインの動作は成されない。障害迂回選択を連続的にすることにより、完全な負荷に基づく制御が可能となり、一実施の形態では、全体の障害迂回時間に１秒未満を加える。

最初の障害に続いて、クラスタ構成を以下に示す：

この構成では、過負荷警告は、Ｓｖｒ３に提供され、Ｓｖｒ３が過負荷であるとオペレータまたは管理者に通知される。オペレータは、Ｇ７をＳｖｒ１に切り換えてＧ１およびＧ３を横断する負荷をバランスさせる。Ｓｖｒ４の修理が済むと、Ｓｖｒ４は、“利用可能容量”＝１００をもつクラスタに再び加わる。次いで、Ｓｖｒ４は、さらなる障害のための障害迂回ターゲットとして役立つ。

連続障害
Ｓｖｒ４が直ちに修理できないと仮定すると、さらに障害が発生する可能性がある。この例として、今度はＳｖｒ３が障害を発生すると仮定する。各アプリケーショングループＧ３、Ｇ５およびＧ７は、それぞれサーバＳｖｒ１、Ｓｖｒ２およびＳｖｒ１上で再起動される。これらの再起動は結果的に以下の構成を生じる：

この例は、“利用可能容量”が緩やかな制限であることを示し、ゼロ未満になることもある。

複雑な４システムの実施例
下記の実施例は、多数のシステム“容量”および各種の“限界”を用いる４システムのクラスタを示す。クラスタは２つの“企業用”サーバ（ＬｇＳｖｒ１およびＬｇＳｖｒ２）、および２つの“中規模”サーバ（ＭｅｄＳｖｒ１およびＭｅｄＳｖｒ２）から成っている。４つのアプリケーショングループＧ１〜Ｇ４が、各種の“負荷”および“必要条件”を提供される。Ｇ１およびＧ２は、特定の共有メモリおよびセマフォの要件をもつデータベースアプリケーショングループである。Ｇ３およびＧ４は、特定の共有メモリまたはセマフォの要件をもたず、単純に所定のシステムに負荷を加えるだけの中級アプリケーショングループである。

構成ファイルの実施例

自動開始動作
以下は、上記のmain.cfの例を用いた“自動開始”動作の可能性のある結果である：
G1-LgSvr1
G2-LgSvr2
G3-MedSvr1
G4-MedSvr2

すべてのアプリケーショングループは、クラスタが開始されるとシステムに割り当てられる。アプリケーショングループＧ１およびＧ２は、ＬｇＳｖｒ１およびＬｇＳｖｒ２の“自動開始リスト”を有する。Ｇ１およびＧ２は、１番高い“利用可能容量”に基づいてこれらのサーバの１つの上でオンラインで実行するよう待ち行列に入れられる。Ｇ１が最初に開始されると仮定すると、Ｇ１はＬｇＳｖｒ１上で開始される。なぜなら、ＬｇＳｖｒ１およびＬｇＳｖｒ２はともに、初期の“利用可能容量”２００を有し、ＬｇＳｖｒ１が語彙的に最初だからである。
アプリケーショングループＧ３およびＧ４は、それぞれＭｅｄＳｖｒ１およびＭｅｄＳｖｒ２上で開始される。

通常動作
アプリケーショングループＧ１〜Ｇ４を開始した後、結果として生じる構成を以下に示す：

障害シナリオ
最初の障害の例では、システムＬｇＳｖｒ２が障害を発生していると仮定する。クラスタ管理アプリケーションは、ＬｇＳｖｒ２と同じ“システム領域”グループを有するＧ２の“システムリスト”内で利用可能システムを精査する。次いで、クラスタ管理アプリケーションは、アプリケーショングループの“必要条件”を満たすシステムのサブセットを作成する。この場合、ＬｇＳｖｒ１は、すべての必要な“限界”を満たす。Ｇ２は、ＬｇＳｖｒ１上でオンラインとなり、以下の構成を結果として生じる：

１０分後（“負荷時間閾値”＝６００）、“負荷警告レベル”が９０％を超えるので、ＬｇＳｖｒ１の過負荷警告が与えられる。

連続障害シナリオ
このシナリオでは、各システムが残りの“限界”を十分に有して、ピアシステム上で実行されるアプリケーショングループに対処するので、システムのさらなる障害が許容される。

例えば、障害がＭｅｄＳｖｒ１またはＭｅｄＳｖｒ２の何れかで発生した場合、障害が発生したシステム上で実行されていたアプリケーショングループは、それぞれの“システム領域”内にＭｅｄＳｖｒ１およびＭｅｄＳｖｒ２を有するので、他のシステムが、障害迂回ターゲットとして選択される。
障害が、それに代わって、まだオフラインのＬｇＳｖｒ１、ＬｇＳｖｒ２により発生した場合、アプリケーショングループＧ１およびＧ２の障害迂回は、障害迂回決定処理に対して順番に行われる。この場合、データベース領域にはシステムは存在しない。標準ではＧ１となる最初のグループは、ＭｅｄＳｖｒ２が、すべての“限界”を満たし、かつ最大の“利用可能容量”を有するので、ＭｅｄＳｖｒ２上で開始される。グループＧ２は、残りのシステムではＭｅｄＳｖｒ１だけが“限界”を満たすので、ＭｅｄＳｖｒ１上で開始される。

サーバ連結実施例
以下の実施例は、多数のアプリケーションおよび幾つかの大規模データベースを実行している複雑な８ノードクラスタを示す。データベースサーバは、すべて大規模な企業用システムのＬｇＳｖｒ１、ＬｇＳｖｒ２、およびＬｇＳｖｒ３である。多数のアプリケーションを実行している中級サーバは、ＭｅｄＳｖｒ１、ＭｅｄＳｖｒ２、ＭｅｄＳｖｒ３、ＭｅｄＳｖｒ４、およびＭｅｄＳｖｒ５である。

構成ファイル実施例

自動開始動作
上記の構成ファイル実施例を用いて、以下の“自動開始シーケンス”が可能である：
データベース１−ＬｇＳｖｒ１
データベース２−ＬｇＳｖｒ２
データベース３−ＬｇＳｖｒ３
アプリケーション１−ＭｅｄＳｖｒ１
アプリケーション２−ＭｅｄＳｖｒ２
アプリケーション３−ＭｅｄＳｖｒ３
アプリケーション４−ＭｅｄＳｖｒ４
アプリケーション５−ＭｅｄＳｖｒ５

通常動作
上記構成を仮定すると、以下が決定できる：

障害シナリオ
上記構成は、“障害迂回ポリシー”＝“負荷”および“システム領域”を示す。データベース領域（“システム領域”ゼロ）は、２つの障害まで扱うことができる。各サーバは、適度な“限界”を有し、３つまでのデータベースアプリケーショングループをサポートする（すべてのデータベースアプリケーショングループが１台のサーバ上で実行される場合、性能低下が予想される）。同様に、アプリケーション領域は、各システムに組み込まれた過剰な容量を有している。

この実施例では、ＭｅｄＳｖｒ１〜ＭｅｄＳｖｒ５のそれぞれは、１つのデータベースをサポートする“限界”を指定しているが、アプリケーショングループＧ４〜Ｇ８は“必要条件”を指定していない。この構成では、やむを得ない場合に、データベースが“システム領域”を横断する障害を起こすことがあるが、最小負荷のアプリケーション領域マシン上で実行できる。

最初の障害の例では、システムＭｅｄＳｖｒ３が障害を発生していると仮定する。クラスタ管理アプリケーションは、“データベース２”の“システムリスト”にあるすべての利用可能なシステムを、ＭｅｄＳｖｒ３と同じ“システム領域”グループ化により精査する。次いで、クラスタ管理アプリケーションはアプリケーショングループの“必要条件”を満たすシステムのサブセットを作成する。この場合は、ＬｇＳｖｒ１およびＬｇＳｖｒ２がすべての必要な“限界”を満たし、“データベース１”がＬｇＳｖｒ１上でオンラインとなる。データベース領域に対する以下の構成が生成される：

このシナリオでは、各システムが残りの“限界”を十分に有して、ピアシステム上で実行されるデータベースアプリケーショングループに対処するので、データベースのさらなる障害が許容される。

連続する障害シナリオ
２つのデータベースグループが１台のサーバ上で実行されていて（または３つのデータベースが第２の障害に続いて）、特定データベースの性能が許容できない場合、“システム領域ポリシー”は別の有用な効果を有する。データベースグループをアプリケーション領域に入れる障害は、好適な領域をリセットする効果を有する。例えば、上記シナリオで、“データベース１”はＬｇＳｖｒ１に移動している。管理者は、アプリケーション領域を再構成して２つのアプリケーショングループを１つのシステムに移動できる。次いで、データベースアプリケーションを空のアプリケーションサーバ（ＭｅｄＳｖｒ１〜ＭｅｄＳｖｒ５）に切り換えることができる。これは、“データベース１”を“領域１”（アプリケーション領域）に配置することになる。障害が“データベース１”で生じている場合、“必要条件”を満たすアプリケーション領域内の最小負荷のサーバが、障害迂回ターゲットとして選択される。

本発明を実装するために適したシステム
図１７は、本発明を実装するために適したコンピュータシステム１０のブロック図を示す。コンピュータシステム１０は、バス１２を含み、そのバスは、中央プロセッサ１４、システムメモリ１６（典型的にはＲＡＭであるが、ＲＯＭ、フラッシュＲＡＭ等を含んでもよい）、入出力コントローラ１８、オーディオ出力インターフェース２２を介するスピーカーシステム２０等の外部オーディオ装置、ディスプレイアダプタ２６を介するディスプレイスクリーン２４等の外部装置、シリアルポート２８および３０、キーボード３２（キーボードコントローラ３３によりインターフェースされる）、ストレージインターフェース３４、フロッピーディスク３８を受け取って動作可能なフロッピーディスクドライブ３６、およびＣＤ−ＲＯＭ４２を受け取って動作可能なＣＤ−ＲＯＭドライブ４０等の、コンピュータシステム１０の主要なサブシステムを相互接続している。また、マウス４６（または、シリアルポート２８を介してバス１２に接続される他のポイントアンドクリックデバイス）、モデム４７（シリアルポート３０を介してバス１２に接続される）、およびネットワークインターフェース４８（バス１２に直接接続される）をも含む。

バス１２は、中央プロセッサ１４とシステムメモリ１６との間のデータ通信を可能にし、システムメモリは、先に記したように、リードオンリーメモリ（ＲＯＭ）、またはフラッシュメモリ（いずれも不図示）、およびランダムアクセスメモリ（ＲＡＭ）（不図示）をともに含んでもよい。ＲＡＭは、一般に、オペレーティングシステムおよびアプリケーションプログラムがロードされ、少なくとも１６ＭＢのメモリ空間を与えるのが代表的なメインメモリである。ＲＯＭまたはフラッシュメモリは、コードの中でもとりわけ基本入出力システム（ＢＩＯＳ）を含むことができ、ＢＩＯＳは、周辺機器との相互作用等の基本的なハードウェア動作を制御する。コンピュータシステム１０とともに常駐するアプリケーションは一般に、ハードディスクドライブ（例えば、固定ディスク４４）、光ドライブ（例えば、ＣＤ−ＲＯＭドライブ４０）、フロッピーディスクユニット３６、または他の記憶媒体等の、コンピュータ可読媒体を介して格納され、アクセスされる。さらに、アプリケーションは、ネットワークモデム４７またはインターフェース４８を介してアクセスされる場合は、アプリケーションおよびデータ通信技術に基づいて変調される電子信号の形でもよい。

コンピュータシステム１０の他のストレージインターフェースと同様に、ストレージインターフェース３４は、情報の格納および／または検索のために、固定ディスクドライブ４４等の標準のコンピュータ可読媒体に接続してもよい。固定ディスクドライブ４４は、コンピュータシステム１０の一部であってもよく、または分離して、他のインターフェースシステムを通じてアクセスしてもよい。シリアルポート２８を介してバス１２に接続されるマウス４６、シリアルポート３０を介してバス１２に接続されるモデム４７、およびバス１２に直接接続されるネットワークインターフェース４８等の、多くの他の装置が接続できる。モデム４７は、電話接続を介してリモートサーバへ、またはインターネットサービスプロバイダ（ＩＰＳ）を介してインターネットへ直接接続を提供してもよい。ネットワークインターフェース４８は、ＰＯＰ（ポイントオブプレゼンス）を介して、インターネットへの直接ネットワーク接続を介してリモートサーバに直接接続を提供してもよい。ネットワークインターフェース４８は、無線技術を用いてこのような接続を提供してもよく、デジタル式携帯電話接続、セル方式デジタルパケットデータ（ＣＤＰＤ）接続、デジタル衛星データ接続等を含む。

多数の他の装置またはサブシステム（不図示）を、同様の方法（例えば、バーコードリーダー、文書スキャナ、デジタルカメラ等）で接続してもよい。逆に、本発明を実施するために、図１７に示す全ての装置が存在する必要はない。装置およびサブシステムは、図１７に示すのとは異なる方法で相互接続してもよい。図１７に示すようなコンピュータシステムの動作は、従来技術で既に知られているので、本明細書では詳細な説明はしない。本発明を実装するためのコードは、一つ以上のシステムメモリ１６、固定ディスク４４、ＣＤ−ＲＯＭ４２、またはフロッピーディスク３８等の、コンピュータ可読記憶媒体に格納してもよい。さらに、コンピュータシステム１０は任意の種類の計算装置でもよく、従って、個人データアシスタント（ＰＤＡ）、ネットワーク家電、Ｘウインドウ端末、または他のかかる計算装置を含む。コンピュータシステム１０上に提供されるオペレーティングシステムは、MS-DOS（登録商標）、MS-WINDOWS（登録商標）、OS/2（登録商標）、UNIX（登録商標）、Linux（登録商標）、または他の既知のオペレーティングシステムでよい。コンピュータシステム１０はまた、幾つかのインターネットアクセスツールもサポートし、例えば、Netscape Navigator（登録商標）3.0、Microsoft Explorer（登録商標）3.0等の、JavaScriptインタープリタを有するＨＴＴＰ準拠のウェブブラウザを含む。

さらに、本明細書で説明したメッセージおよび／またはデータ信号に関して、当該技術に精通する者には言うまでもないが、信号は、第１ブロックから第２ブロックに直接送信してもよく、またはブロック間で修正（例えば、増幅、減衰、遅延、ラッチ、バッファ、反転、フィルタ、または他の修正）を行ってもよい。上記説明の実施の形態の信号は、あるブロックから次のブロックに送信されることを特徴とするが、本発明の他の実施の形態は、信号の情報および／または機能 的な局面をブロック間で送信する限り、このような直接送信信号の代わりに修正した信号を含んでいてもよい。ある程度までは、第２ブロックの信号入力は、（例えば、何らかの減衰および遅延は避けられない）関与する回路の物理的制限により第１ブロックからの第１信号出力から導かれる第２信号として概念的に説明できる。従って、本明細書で用いるように、第１信号から導かれる第２信号は、第１信号または第１信号への任意の修正を含み、この修正は、回路制限によるか、または第１信号の情報的および／または最終的な機能局面を変更しない他の回路要素の通過によるかどうかに関わらない。

他の実施の形態
本発明は、説明した利点、および本質的な他の利点を取得するよう十分適合している。本発明の特定の実施の形態を参照することにより、本発明を図示し、説明し、そして定義したが、かかる参照は、本発明の制限を意味せず、かかる制限を推測すべきではない。本発明は、関連技術に普通に精通する者なら思い浮かぶように、形状および機能において、多くの改変、代替、および等価物が可能である。図示し、説明した実施の形態は単に例示に過ぎず、本発明の範囲を網羅してはいない。

上記説明の実施の形態は、他の要素内に含まれる要素を含む。かかる構造が例示に過ぎず、事実、同じ機能性を達成する多くの他の構造が実装できるのは、言うまでもない。抽象的ではあるが、依然明確な意味において、同じ機能性を達成するための任意の要素の編成は、所望の機能性を達成するように、効率的に「関連付け」られる。故に、特定の機能性を達成するために組み合わされた任意の２つの要素は、アーキテクチャまたは中間の要素とは無関係に所望の機能性が達成できるように、互いに「関連付け」られていると見なされる。同様に、そのように関連付けられた任意の２つの要素は、所望の機能性を達成するために、互いに「動作可能に接続され」、または「動作可能に結合され」ていると見なすことができる。

上記の詳細な説明は、ブロック図、フローチャート、および例示を用いて、本発明の各種の実施の形態を述べた。当該技術に精通する者には言うまでもないが、例示を用いて説明したブロック図要素、フローチャートステップ、動作および／または要素のそれぞれは、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せの広い範囲により、個々におよび／または集合的に実装できる。

本発明を完全に機能するコンピュータシステムの文脈で説明したが、当該技術に精通する者には言うまでもないが、本発明は、多様な形態のプログラム製品として配布することができ、本発明は、配布を実際に実行するために用いる特定種類の信号を担う媒体とは無関係に等しく適用される。信号を担う媒体の例は、フロッピーディスクおよびＣＤ−ＲＯＭ等の記録可能媒体、デジタルおよびアナログ通信接続等の送信型媒体、および将来開発される媒体ストレージおよび配布システムを含む。

上記説明の実施の形態は特定タスクを実行するソフトウェアモジュールにより実装してもよい。本明細書で説明するソフトウェアモジュールは、スクリプト、バッチ、または他の実行可能なファイルを含んでもよい。ソフトウェアモジュールは、ディスクドライブ等の、マシン可読、またはコンピュータ可読の記憶媒体に格納してもよい。本発明の実施の形態に基づくソフトウェアモジュールを格納するために用いる記憶装置は、磁気フロッピーディスク、ハードディスク、または、例えばＣＤ−ＲＯＭまたはＣＤ−Ｒ等の光ディスクであってもよい。本発明の実施の形態に基づくファームウェアまたはハードウェアモジュールを格納するために用いる記憶装置は、マイクロプロセッサ／メモリシステムに恒久的、リムーバブル、またはリモートに結合される半導体に基づくメモリを含んでいてもよい。従って、モジュールをコンピュータシステムメモリ内に格納して、コンピュータシステムを構成し、モジュールの機能を実行してもよい。新規および各種の他の種類のコンピュータ可読記憶媒体を用いて、本明細書で説明するモジュールを格納してもよい。

上記説明は、本発明の例示を意図しているので、制限するものと考えてはならない。本発明の範囲内の他の実施の形態が可能である。当該技術に精通する者は、本明細書で開示された構造および方法を提供するのに必要なステップを直ちに実装するであろうが、言うまでもなく、プロセスパラメータおよびステップシーケンスは例示だけのために与えられており、本発明の範囲内にある所望の構造、および改変を達成できるように変更できる。本明細書で開示した変更および改変は、本発明の範囲を逸脱することなく、本明細書で述べた説明に基づいて成すことができる。
結果的に、本発明は、すべての点で等価物に完全な認識を与える添付の請求の範囲によってのみ制限されることを意図している。

本発明の管理システムおよびフレームワークが動作する環境の例を示す。 利用可能性が高いストレージエリアネットワーク内のクラスタ構成の例を示す。 サーバ連結環境における業務継続ポリシーを実装するための方法のフローチャートである。 図３のフローチャートの“アプリケーショングループＸをホストする適格なシステムの集合を決定する”ステップのフローチャートである。 図３のフローチャートの“十分な容量およびリソースを解放して、アプリケーショングループＸを受入れることができるか”の判断点のフローチャートである。 本発明の方法およびシステムにより処理される構成および障害シナリオの例を示す図であって、サーバ連結環境におけるサーバクラスタのために利用可能な容量の計算を示す。 図６のサーバの一台に障害が発生したときのアプリケーションの移動、およびその結果生じるクラスタ内の利用可能な容量を示す。 図７の障害シナリオにおける別のアプリケーションの移動を示す。 図６のクラスタにおけるデータベースアプリケーションの構成例を示す。 図９の構成における障害シナリオでのデータベースアプリケーションの移動を示す。 図１１は、限界および必要条件を用いてアプリケーショングループを管理する例を示す。 アプリケーショングループが障害迂回できない場合の障害シナリオを示す。 優先順位の低いアプリケーショングループを停止して十分なリソースを解放し、優先順位の高いアプリケーションを利用可能なままにできることを示す。 図１２および図１３の構成のための別の障害シナリオを示す。 優先順位の低いアプリケーショングループを移動して十分なリソースを解放し、優先順位の高いアプリケーショングループを利用可能なままにできることを示す 図１５に示す対処の結果として、解放されたリソースを用いるための優先順位の高いアプリケーショングループの移動を示す。 本発明の実施の形態を実装するために適したコンピュータシステムを説明するブロック図である。

Claims (22)

1. 複数のシステムから成る一群のシステムを識別するステップであって、前記一群のシステムにおける各システムが複数のアプリケーションのうちの第１のアプリケーションをホストするための要件を満たし、前記システムが少なくとも一つのクラスタを形成するものと；
   前記一群のシステムが空の場合、解放するリソースを識別するために前記各アプリケーションの各自の優先順位を用いるステップであって、該リソースは複数のリソースのうちの一つであり、各リソースは前記システムのうちの少なくとも一つと関連付けられているものと；
   を具備する方法。
2. 前記リソースを識別することは、更に、該リソースを識別するために前記各システムのそれぞれの容量を用いることを含む請求項１の方法。
3. 更に、前記システムのうちの関係付けられたシステムが、前記第１のアプリケーションをホストするための前記要件を満たすように前記リソースを解放するステップを具備する請求項１の方法。
4. 更に、前記関連付けられたシステム上で前記第１のアプリケーションを開始するステップを具備する請求項３の方法。
5. 前記リソースを解放するステップが、前記リソースを用いている第２のアプリケーションを停止するステップを具備し、前記第２のアプリケーションは、前記第１のアプリケーションの各自優先順位よりも下位の各自優先順位を有する請求項３の方法。
6. 前記リソースを解放するステップが、前記リソースを用いている第２のアプリケーションを、前記システム内の第２のシステムに移動するステップを具備し、前記第２のアプリケーションは、前記第１のアプリケーションの各自優先順位よりも下位の各自優先順位を有する、請求項３の方法。
7. 更に、前記第１のアプリケーションを開始すべきであることを決定するステップを具備する請求項１の方法。
8. 前記第１のアプリケーションを開始すべきであることを決定するステップは、前記第１のアプリケーションが障害を起こしていることを検出するステップを具備する請求項７の方法。
9. 前記第１のアプリケーションを開始すべきであることを決定するステップは、
   前記第１のアプリケーションの各自の優先順位を、前記システム上で実行されているアプリケーション群の各優先順位群と比較するステップと；
   前記第１のアプリケーションの各自の優先順位が、前記システム上で実行されている前記アプリケーション群の前記各優先順位群のうちの一つより上位である場合に、前記第１のアプリケーションを開始すべきであることを決定するステップと、
   を具備する請求項７の方法。
10. 前記一群のシステムを識別するステップは、或る選択されたシステムが前記第１のアプリケーションの必要条件を満たす場合、前記一群のシステム中に該選択されたシステムを含めるようにすることを含む、請求項１の方法。
11. 前記一群のシステムを識別するステップは、前記第１のアプリケーションが、或る選択されたシステムの限界を超えない場合、前記一群のシステム中に該選択されたシステムを含めるようにすることを含む、請求項１の方法。
12. 複数のシステムから成る一群のシステムを識別する識別モジュールであって、前記一群のシステムにおける各システムが複数のアプリケーションのうちの第１のアプリケーションをホストするための要件を満たし、前記システムが少なくとも一つのクラスタを形成するものと；
    前記一群のシステムが空の場合、解放するリソースを識別するために前記各アプリケーションの各自の優先順位を用いる優先順位モジュールであって、該リソースは複数のリソースのうちの一つであり、各リソースは前記システムのうちの少なくとも一つと関連付けられているものと；
    を備える装置。
13. 前記優先順位モジュールは、更に、前記リソースを識別するために前記各システムのそれぞれの容量を用いることを含む請求項１２の装置。
14. 更に、前記システムのうちの関連付けられたシステムが、前記第１のアプリケーションをホストするための要件を満たすように前記リソースを解放する解放モジュールを備える請求項１２の装置。
15. 更に、前記関連付けられたシステム上で前記第１のアプリケーションを開始する開始モジュールを備える請求項１４の装置。
16. 前記解放モジュールは、前記リソースを用いている第２のアプリケーションを停止する停止モジュールを備え、前記第２のアプリケーションは、前記第１のアプリケーションの各自優先順位よりも下位の各自優先順位を有する請求項１４の装置。
17. 前記解放モジュールは、前記リソースを用いている第２のアプリケーションを前記システム内の第２のシステムに移動する移動モジュールを備え、前記第２のアプリケーションは、前記第１のアプリケーションの各自優先順位よりも下位の各自優先順位を有する、請求項１４の装置。
18. 更に、前記第１のアプリケーションを開始すべきであることを決定する決定モジュールを備える請求項１２の装置。
19. 前記決定モジュールは、前記第１のアプリケーションが障害を起こしていることを検出する検出モジュールを備える、請求項１８の装置。
20. 前記決定モジュールは、
    前記第１のアプリケーションの各自の優先順位を、前記システム上で実行されているアプリケーション群の各優先順位群と比較する比較モジュールを備え、
    前記第１のアプリケーションの各自の優先順位が、前記システム上で実行されている前記アプリケーション群の前記各優先順位群のうちの一つより上位である場合に、前記決定モジュールは、前記第１のアプリケーションを開始すべきであることを決定する、
    請求項１８の装置。
21. 前記識別モジュールは、或る選択されたシステムが前記第１のアプリケーションの必要条件を満たす場合、前記一群のシステム中に該選択されたシステムを含めるようにする包含モジュールを備える、請求項１２の装置。
22. 前記識別モジュールは、前記第１のアプリケーションが、或る選択されたシステムの限界を超えない場合、前記一群のシステム中に該選択されたシステムを含めるようにする包含モジュールを備える、請求項１２の装置。

Images