JP4132738B2

JP4132738B2 - アプリケーション・サーバのアベイラビリティを判別するコンピュータ化された方法

Info

Publication number: JP4132738B2
Application number: JP2001213586A
Authority: JP
Inventors: レイマン・フランク; ローレル・ディーテル
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-07-15
Filing date: 2001-07-13
Publication date: 2008-08-13
Anticipated expiration: 2021-07-13
Also published as: KR20020007160A; CN1156775C; CN1334530A; US20020059423A1; KR100423192B1; US6968381B2; TW536670B; JP2002108817A

Description

【０００１】
【発明の属する技術分野】
本発明は、複数のアプリケーション・クライアントにアプリケーション・サービスを提供する複数のアプリケーション・サーバのアベイラビリティを表示し、判別する方法および手段に関する。
【０００２】
【従来の技術】
企業は、彼らの日ごとの経営を支援するシステムのアベイラビリティに依存する。システムが作動しており、実行中である場合には、システムは使用可能といわれ、正確な結果を作り出している。狭い意味で、システムのアベイラビリティは、システムが使用可能である時間の一部である。ＭＴＢＦは、このようなシステムの平均故障間隔、すなわち、故障が発生するよりも前にシステムが使用可能である平均時間を表す（これは、システムの信頼性である）。ＭＴＴＲは、その平均修理時間、すなわち、故障の後にシステムを修理するのにかかる平均時間を表す（これは、故障のゆえのシステムのダウン時間である）。従って、
【０００３】
【表１】

【０００４】
は、システムのアベイラビリティである。理想的には、システムのアベイラビリティは１である。今日、システムのアベイラビリティがおよそ９９.９９９％である場合には、システムは、高いアベイラビリティを主張することができる（システムのアベイラビリティが、およそ９９.９９％である場合には、システムは、耐障害といわれる）。Ｊ.ＧｒａｙおよびＡ.Ｒｅｕｔｅｒ,“Ｔｒａｎｓａｃｔｉｏｎｐｒｏｃｅｓｓｉｎｇ：ＣｏｎｃｅｐｔｓａｎｄＴｅｃｈｎｉｑｕｅｓ”，ＳａｎＭａｔｅｏ，カリフォルニア州：ＭｏｒｇａｎＫａｕｆｍａｎｎ１９９３は、これらの側面に関して更に詳細に説明する。一定のシステムまたはアプリケーションのアベイラビリティは、少なくとも２つの側面を有する。すなわち、第１の狭い意味において、アベイラビリティは、一定のシステムが、そのサービスの全ての提供においてアクティブか否かという問題に関し、第２のより広い意味において、アベイラビリティは、十分な応答性を提供するタイムリな方法でこのサービスが提供されたか否か、という問題に関する。
【０００５】
アベイラビリティを改善する一つの基本的なメカニズムは、“冗長度”に基づく。すなわち、ハードウェアのアベイラビリティは、マシンのクラスタを作成することによって改良され、ソフトウェアのアベイラビリティは、複数のアドレス・スペースにおいて同一のソフトウェアを実行することによって改善される。
【０００６】
分散システムの出現と共に、同一のソフトウェアを実行する異なるマシン上で２以上のアドレス・スペースを使用して、アベイラビリティを改善する手法（しばしば、アクティブ・レプリケーションといわれる）が考案された。これらの側面に関する更なる詳細は、Ｓ．Ｍｕｌｌｅｎｄｅｒ，“ＤｉｓｔｒｉｂｕｔｅｄＳｙｓｔｅｍｓ”，ＡＣＭＰｒｅｓｓ，１９９３において得ることができる。共用インプット・キューからその要求を得る同一のソフトウェアを実行する同一のマシン上で２以上のアドレス・スペースを使用する際に、ウォーム・バックアップの手法は、ホット・プール手法によって一般化される。
【０００７】
Ｃ．Ｒ．Ｇｅｈｒら“ＤｙｎａｍｉｃＳｅｒｖｅｒＳｗｉｔｃｈｉｎｇｆｏｒＭａｘｉｍｕｍＳｅｒｖｅｒＡｖａｉｌａｂｉｌｉｔｙａｎｄＬｏａｄＢａｌａｎｃｉｎｇ”，米国特許第５，８２８，８４７号公報は、先に定義されたアベイラビリティの狭い意味に関連するダイナミック・サーバ・スイッチング・システムを教示する。ダイナミック・サーバ・スイッチング・システムは、クライアントのための１次サーバおよび優先通信方法、そして引き続いて２次サーバおよび通信方法対の階層を識別する静的かつ事前定義されたリスト（プロファイルの一種）を各クライアント内に保持する。クライアントが、指定された１次サーバ、または指定された通信方法によって提供された要求を有さないというイベントにおいて、システムは、リストをトラバースして、第１の使用可能代替サーバ−通信方法対のＩＤを得る。このシステムは、クライアントが、反応しないサーバから事前定義代替サーバへ要求を転送するのを可能にする。このように、システムは、サービス・アベイラビリティのためのリアクティブ・サーバ・スイッチングを提供する。
【０００８】
先に定義された狭い意味におけるアベイラビリティの改良にもかかわらず、この教示はいくつかの欠点を伴う。Ｇｅｈｒの教示は、１次サーバに全く到達できない場合にだけ、リアクティブ・レスポンスを与える。クライアントが非応答的サーバからサービスを要求するということをそれまでに予防する事前の対策を講じた要素が存在しない。１次および代替サーバのリストは、静的に事前定義されているので、そこにおいて得られ得るサーバが一つもない、あるいは、そこにおいていくつかの非応答的代替サーバがテストされるよりも前にサーバが得られることはないという状態が存在し得る。クライアントおよびサーバがネットワークに永続的に入るまたは出る、そしてサーバへのアクセス・パターンが刻々と変化し得る、高度にダイナミックな，世界的なオペレーティング・ネットワーク状態において、Ｇｅｈｒの教示は、適切ではない。
【０００９】
本発明と同じ発明者による“ＩｍｐｒｏｖｅｄＡｖａｉｌａｂｉｌｉｔｙｉｎＣｌｕｓｔｅｒｅｄＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒｓ”と呼ばれる欧州特許出願ＥＰ９９１０９９２６．８は、また、アベイラビリティ問題に関する。しかし、この教示は、アプリケーション・クライアントの面にもっぱら集中する。一定のアプリケーション要求が、使用可能なアプリケーション・サーバによって処理されているということを確かめるために、少なくとも一つの使用可能なアプリケーション・サーバがこの要求を受信できるということを仮定する複数の並列アプリケーション・サーバへ、マルチキャスト（ｍｕｌｔｉ−ｃａｓｔｉｎｇ）・ステップでこのアプリケーション要求を、送ることが提案される。この教示は、一定のアプリケーション・サーバのアベイラビリティの表し方の手法に関して全く一言も触れていない。
【００１０】
同一の発明者に基づく、“ＩｍｐｒｏｖｉｎｇＡｖａｉｌａｂｉｌｉｔｙａｎｄＳｃａｌａｂｉｌｉｔｙｉｎＣｌｕｓｔｅｒｅｄＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒｓ”と呼ばれる、さらなる欧州特許出願ＥＰ９９１２２９１４．７が知られている。この出願において、アプリケーション・サーバのアベイラビリティを判別するための手法の存在が開始点としてすでに想定される。この教示は、次に、アプリケーション要求を処理する一定のアプリケーション・サーバを選択することにより、いかなる方法でアプリケーション・クライアントがワークロード平衡化を実行できるのかの手法に集中する。
【００１１】
これらの進歩の全てにもかかわらず、誰かが一定のアプリケーション・サーバのアクセスに興味を有し得るあらゆる時点での、世界的なコンピュータ・ネットワークのユービクィティの理由から、彼らのアプリケーションのアベイラビリティを増加させ、そして７（日）*２４（時間）ベースの電子ビジネスの要求に備えている企業を支援するために、さらなる改良が緊急に必要とされる。
【００１２】
【発明が解決しようとする課題】
本発明は、アプリケーション要求を受け入れるアプリケーション・サーバのアベイラビリティを表す改良された方法および手段を提供し、そして、アプリケーション・サーバのアベイラビリティをアプリケーション・クライアントによって判別する改良された方法および手段を提供する目的に基づく。
【００１３】
本発明のさらなる目的は、ネットワーク内部の個々のアプリケーション・サーバのアベイラビリティのダイナミックな変更に高度に応答するテクノロジを提供することにより、アベイラビリティを増大させることである。
【００１４】
【課題を解決するための手段】
本発明の目的は、独立のクレイムによって解決される。本発明のさらに有益な構成および実施形態は、それぞれのサブクレイムにおいて説明される。
【００１５】
提示された方法は、アプリケーション・サーバの各々について、アベイラビリティ信号の反復期間のための時間制限の上限（ upper time limit ）を定義する通知期間をアベイラビリティ・データベースに挿入する第１のステップを含み、アベイラビリティ信号は、アプリケーション・サーバが使用可能である間は繰り返される。第２のステップにおいて、各アベイラビリティ信号については、その対応するタイム・スタンプが、アベイラビリティ・タイムとしてアベイラビリティ・データベースに挿入される。前記通知期間と比較される、現在時刻と最近のアベイラビリティ・タイムとの差異は、アプリケーション・サーバのアベイラビリティの基準（ availability measure ）を表す。
【００１６】
提示されたテクノロジは、複数のアプリケーション・クライアントへサービスを提供する複数のアプリケーション・サーバのアベイラビリティおよびスケーラビリティを増大させる。本発明は、アプリケーション・クライアントが、非応答的サーバからサービスを要求する誤った要求ルーティングを生成することを予防する事前の策を講じたテクノロジを提供する。継続している処理を有する動的手法は、クライアントおよびサーバがネットワークに永続的に入るまたは出るという動的ネットワーク状態に高度に応答する。このようにして、本発明は、サーバ・マシンのホット・プラグインを、アプリケーション・クラスタに収容することができ、従って、環境のスケーラビリティをさらに増加させることができる。アプリケーション・クライアントをアプリケーション・サーバと関係づけるための複雑な管理努力は、完全に回避される。
【００１７】
【発明の実施の形態】
本発明は、ハードウェア，ソフトウェア，またはハードウェアおよびソフトウェアの組み合わせにおいて実現可能である。あらゆる種類のコンピュータ・システム、あるいは、この中で述べられる方法の実行に適応した他の装置が適している。ハードウェアおよびソフトウェアの典型的な組み合わせは、ロードされ実行される時に、コンピュータシステムを制御してこの中で述べられる方法を実行するコンピュータ・プログラムを有する汎用コンピュータ・システムであり得る。本発明は、また、この中で述べられる方法の実施を可能にする全ての特徴を含み、コンピュータ・システムにロードされた時にこれらの方法を実行することができるコンピュータ・プログラム製品において実現可能である。
【００１８】
本コンテキストにおいてコンピュータ・プログラム手段あるいはコンピュータ・プログラムとは、情報処理能力を有するシステムに、特定の機能を直接、またはａ）他の言語，コードまたは表記への変換、ｂ）異なる具体的な形式における複製、のいずれか一方もしくは双方の後に、実行させることが意図された一組の命令のあらゆる言語，コードまたは表記でのあらゆる表現を意味する。
【００１９】
本明細書がアプリケーションに言及している場合に、アプリケーションは、いかなる特定のタイプまたは実施態様にも限定されないあらゆる種類のコンピュータ・プログラムであり得る。用語アプリケーション・クライアントおよびアプリケーション・サーバは、いくつかのタイプの“実例”に関連がある論理的な見地のみから解される必要がある。これらの用語は、異なるアドレス・スペースを、あるいは異なるコンピュータ・システムでさえも、必ずしも識別するとは限らない。
【００２０】
本発明は、アプリケーション・クライアントおよびアプリケーション・サーバ間の一定の通信パスを想定しており、これは、本発明が一定の通信パラダイムに限定されるということを意味するものではない。
【００２１】
また、本明細書が“データベース”に言及している場合に、その用語は、実際のデータベース（関係，階層データベース等のような）だけでなく単純ファイル等をも含む広い意味において解されるべきである。言い替えれば、用語データベースは、あらゆるタイプの永続的ストレージを指す。
【００２２】
導入および課題
企業は、彼らの日ごとの経営を支援するシステムのアベイラビリティに依存する。システムが作動しており、実行中である場合には、システムは使用可能といわれ、正確な結果を作り出している。狭い意味で、システムのアベイラビリティは、システムが使用可能である時間の一部である。第２のより広い意味において、アベイラビリティは、十分な応答性を提供するタイムリな方法でアプリケーション・サービスが提供されたか否か、という問題に関する。
【００２３】
最も好適な実施の形態において、本発明は、図１においても示される以下の概念に基づく“アプリケーション・クラスタ”といわれる環境に関する。
【００２４】
アプリケーション・サーバ（１１０，１１１または１１２）は、関連しているサービスの集合−例えば、共用リモート・データベース（１００）へのアクセスを含む−を実行可能に実施している。ホット・プール（１１０，１１１，１１２）は、アドレス・スペースの集合であり、アドレス・スペースの各々は、同一のアプリケーション・サーバを実行し、これらのアプリケーション・サーバの各々は、入力キュー（１２５）から要求を受信し、入力キューは、ホット・プール・メンバ間で共用される。サーバ・マシン（１０１，１０２または１０３）については、アプリケーション・サーバのホット・プールをホストする一定の物理的なマシンを意味する。アプリケーション・クラスタ（１２０）は、独立して障害が起こるサーバの集合であり、各サーバは、同種のアプリケーション・サーバのホット・プールをホストする。
【００２５】
アプリケーション（１３０）は、アプリケーション・クライアントを経てアプリケーション・サーバからサービスを要求する。アプリケーションと同じマシン上で実行し、アプリケーションに代わってサーバと通信するアプリケーション・クライアント（１３１）が、実行可能である。アプリケーション・クライアントおよびサーバ間の通信が、（非同期）高信頼性メッセージ交換に基づく場合には、アプリケーション・サーバは、メッセージ・ベースであるといわれる。以下において、アプリケーション・クライアントおよびアプリケーション・サーバ間のメッセージ・ベースの通信を想定する。もちろん、他のパラダイムが代わりに使用可能であるので、本発明は、メッセージ・ベースの通信パラダイムに限定されない。結果として、アプリケーション・クライアントは、特定のマシン上の関連アプリケーション・サーバのホット・プールの入力キューへ対応するメッセージを送信することにより一定のサービスのパフォーマンスを要求する。
【００２６】
クライアントは、サーバ障害から自身を保護し、従って、欧州特許出願ＥＰ９９１０９９２６．８と共に既に上述したように、その要求を単純にマルチキャストすることによって全体の環境のアベイラビリティを増加させることができる。しかしながら、これは、アプリケーション・サーバの特殊な実施を必要とし、あるいはそれは、べき等の要求に制限される。さらに、それは、ファクタによって送信されるメッセージの数を増加させる。
【００２７】
メッセージの数が問題である場合には、ホット・プールへ要求を送信する各クライアントは、このホット・プールが障害を起こしたということを検出しなければならない（これは容易である、すなわち、対応するＰＵＴコマンドが、メッセージ・ミドルウェアによってクライアントへ否定的に応答され得る）。クライアントが、同一のアプリケーション・サーバの他のホット・プール（すなわち、障害ホット・プールがメンバであるアプリケーション・クラスタのサーバ・マシン）を認める時、クライアントは、クラスタの異なるサーバ上の他のホット・プールへその要求を送信できる。そうすることで、クライアントは、ホット・プール自身間の引継ぎを実現できる。
【００２８】
従って、問題は、要求を受け入れるためにいまだに使用可能であるサーバを検出することである（いわゆるアベイラビリティ・モニタリング）。この目的のために、いわゆるウォッチドッグが使用可能であり、単一マシン上のホット・プールを監視して障害を起こしたサーバを検出できる。その上、ウォッチドッグは、ウォッチドッグが監視するホット・プールの障害を起こしたアプリケーション・サーバを自動的にリスタートし得る。上述した欧州特許出願ＥＰ９９１２２９１４．７と共に、ウォッチドッグ・モニタリングの概念が、アプリケーション・クラスタにおいて障害を起こしたサーバ・マシンを検出するために検討されてきた。この概念は、使用可能なアプリケーション・サーバの組を監視し、判別するウォッチドッグ間の特定の通信プロトコルに基づく。
【００２９】
典型として、メッセージは、分散アプリケーションのパーツ間のネットワークを経て送信され、そのコンポーネントの全体の状態を維持する。監視されるウォッチドッグの集合をこのような分散アプリケーションとみなす（その唯一の目的は、その分散コンポーネントの活性（ｌｉｖｅｌｉｎｅｓｓ）についての問い合わせに応答することであり得る）と、このようなネットワーク・ベースのメッセージ受け渡しスキームが使用可能である。しかしながら、ネットワーク・ベースのメッセージ受け渡しプロトコルは、数個の固有の問題（多少困難な）を有する。例えば、
【００３０】
送信されるメッセージが、ある状態で許容できないネットワーク上に追加的な負荷を加えることもあるという単純な事実。
【００３１】
より複雑なアルゴリズムが、障害の単一点を回避するために実施されなければならず（識別されたウォッチドッグが参加者である他のウォッチドッグを単に監視する“集中”モニタリングにおけるのと同様に）、これは、より一層の開発努力に帰する。さらに、このような実施は、“チェッカ検査（ｃｈｅｃｋｔｈｅｃｈｅｃｋｅｒ）”、すなわち、これらのチェック・インスタンス自身がいかなる障害も引き起こさないということを確かめるために特定のプログラミング手法が活用されなければならないという問題を起こす。
【００３２】
到達可能性プロパティは確保されなければならず（例えば、中央ウォッチドッグは、“集中モニタリング”において全ての他のウォッチドッグに到達できなければならず、あるいは、各ウォッチドッグは、“分散モニタリング”において全ての他のウォッチドッグに到達できなければならない）、到達可能性プロパティは、環境を適切にセットアップして管理タスクを達成することが難しいと同時に、発生し得るものであり、処理されなければならないネットワーク分割化（すなわち、接続損失のために、ネットワークが分離したサブネットに分離する）の場合には処理することが困難である。
【００３３】
結果として、本発明の目的は、これらの大規模ネットワーク・ベースのメッセージ受け渡しプロトコルを必要とするようなメカニズムを克服することである。しかしながら、同時に、これらの問題に対する望ましい解決法は、クラスタに入る（ホット・プラグイン）あるいは出るアプリケーション・サーバを自動的に判別する事前の対策を講じたテクノロジを提供することと思われる。
【００３４】
解決法の基本的思想
本発明の中心思想は、図２に反映される。本発明の中心的な所見は、中央および共用データベースの導入が、上述のネットワーク・メッセージ・トラフィック問題を著しく削減し得るということである。アプリケーション・サーバの活性（ｌｉｖｅｌｉｎｅｓｓ）についての状態を交換する通信媒体として監視される全てのウォッチドッグによって共用されるデータベースを使用することが提案される。この新しいデータベースは、ライフ（ｌｉｆｅ）・データベースあるいはアベイラビリティ・データベース２００と称される。本発明の好適な実施の形態において、クラスタ２０２の対応するアプリケーション・サーバの各ウォッチドッグ２０１は、“Ｉａｍａｌｉｖｅ！”２０３レコードを、ライフ・データベースに周期的に書き込み、このレコードは、対応するアプリケーション・サーバのアベイラビリティ信号として解され、アプリケーション・サービス要求を受け入れるためにアプリケーション・サーバが作動可能であることを表す。ウォッチドッグ概念の導入は、すでに付加的な改良である。もちろん、各アプリケーション・サーバ自身が、アベイラビリティ信号をアベイラビリティ・データベースに挿入することに責任を負うということが可能であり得る。
【００３５】
見本の実施の形態として、アプリケーション・クラスタのライフ・データベースをホストする関係データベース・システムが想定される。これが本発明にとって中心とならない、すなわち、あらゆる他の永続的ストア（例えば、ファイル・システム、またはｅｎｔｅｒｐｒｉｓｅＪａｖａ（Ｒ）ｂｅａｎｓエンティティ・コンテナ）がこのために使用可能であるということに留意されたい。とりわけ、アプリケーション・クラスタがそのシステム管理のために使用できるトポロジ・データベースは、ライフ・データベースに相当する適切なテーブルによって拡張され得る。
【００３６】
アプリケーション・クラスタのライフ・データベースにアクセス可能なあらゆるソフトウェア（例えば、アプリケーション・サービスを要求することに関心のあるアプリケーション・クライアント）は、使用可能なサーバ、および障害を起こし現在は使用できないサーバを判別できる。
【００３７】
一定のアプリケーション・サーバまたはそのウォッチドッグに対して、対応するアベイラビリティ信号がアベイラビリティ・データベースに一度だけ入力され得るということは、十分ではない。このイベントの後に、アプリケーション・サーバがクラッシュした場合には、アベイラビリティ・データベースは、現在の状態との同期がなくなり得る。この問題を処理するために、本発明は、ライフ・データベースが、各ウォッチドッグが“Ｉａｍａｌｉｖｅ！”レコードをデータベースに書き込むことに同意した期間に関する情報をも含まなければならないということを、この目的のために提案する。従って、通知期間を含むさらなるデータ要素が、アベイラビリティ・データベースに挿入される。通知期間は、対応するウォッチドッグ（またはアプリケーション・サーバ）が使用可能である間はアベイラビリティ信号が繰り返される際の時間制限の上限を定義する。
【００３８】
見本の実施の形態として、図３は、個々の通知期間を格納する期間テーブルを示す。期間テーブルは、アベイラビリティ信号を繰り返すウォッチドッグ（アプリケーション・クラスタを表す）／アプリケーション・サーバのＩＤ３００、そして通知期間３０１を含むということが提案される。アベイラビリティ・モニタリングに関係する各ウォッチドッグ／アプリケーション・サーバは、このようなレコードを、アベイラビリティ・データベースに入力し得る。ウォッチドッグがそれと共に“Ｉａｍａｌｉｖｅ！”メッセージを書き込む期間を、このテーブルからＳＱＬによって取り出す方法は、この技術分野のあらゆる当業者にとって明白である。同様に、アプリケーション・クラスタによって包含された全てのウォッチドッグは、ＳＱＬによってこのテーブルから取り出されることが可能である。
【００３９】
見本の実施の形態として、図４は、ウォッチドッグの“Ｉａｍａｌｉｖｅ！”レコードを表すために使用されるＡｌｉｖｅ＿Ｓｉｇｎａｌテーブルを示す。すなわち、ウォッチドッグから受信された各アベイラビリティ信号に対して、このようなレコードが、アベイラビリティ・データベースに入力され得る。期間テーブルと同様に、Ａｌｉｖｅ＿Ｓｉｇｎａｌテーブルが、アベイラビリティ信号を送信した対応するウォッチドッグ／アプリケーション・サーバのＩＤ４００を含むということが提案される。さらに、Ａｌｉｖｅ＿Ｔｉｍｅｓｔａｍｐフィールド４０１は、タイムスタンプ、従って、最も最近のアベイラビリティ信号のアベイラビリティ・タイムを格納する。
【００４０】
これらの２つのテーブル、すなわち期間テーブルおよびＡｌｉｖｅ＿Ｓｉｇｎａｌテーブルに含まれる情報は、アプリケーション・サーバのアベイラビリティの正確なピクチャを反映する。一般的にいえば、各アプリケーション・サーバに対して、アベイラビリティ基準は、特定のアプリケーション・サーバの通知期間と比較した、現在の時刻（例えば、アベイラビリティ・データベースに問い合わせる時刻）と最も最近のアベイラビリティ・タイムとの差異によって定義される。さらに一般的には、現在のアベイラビリティ・タイムと直前のアベイラビリティ・タイムとの間の他の差異がアベイラビリティ基準に加えられ得る。以下の特定のアベイラビリティ基準がサクセスフルであると証明された。
【００４１】
１．現在の時刻と、最も最近のアベイラビリティ・タイムとの差異が、通知期間を越える場合には、対応するアプリケーション・サーバは、使用不可能であるとして扱われる。これは、アプリケーション・サーバが、少なくとも通知期間以内にアベイラビリティ信号を繰り返すことを約束したからである。そうでなければ、アプリケーション・サーバは、使用可能であるとみなされる。
【００４２】
２．Ａｌｉｖｅ＿Ｓｉｇｎａｌテーブルに基づいて、特定のウォッチドッグによって書き込まれた最後の２つの“Ｉａｍａｌｉｖｅ！”レコードの挿入の間に経過した時間が定義可能である。すなわち、最も最近のアベイラビリティ・タイムと直前のアベイラビリティ・タイムとの間の時間の差異が定義される。この期間が、このウォッチドッグが“Ｉａｍａｌｉｖｅ！”メッセージを挿入することに同意した通知期間を越える場合には、ウォッチドッグは、障害を起こした候補となる。このアベイラビリティ基準は、最後の２つのアベイラビリティ信号が予定された通知期間以内でない場合には、これは、アプリケーション・サーバが現在は問題を経験しており、従って回避されるべきであるというしるしであるという仮定に基づく。
【００４３】
３．典型として、このようなタイムアウト・ベースの障害判別メカニズムは、ウォッチドッグが、単に忙し過ぎて、アベイラビリティ信号をアベイラビリティ・データベースに書き込むことができないが、なおも使用可能であるというような状態を処理しなければならない。このような状態を処理できるアベイラビリティ基準は、現在の時刻と直前のアベイラビリティ・タイムとの間の差異が、Ｎのファクタだけ通知期間を越える場合には、アプリケーション・サーバを使用不可能であるとして扱うことによって達成される。
【００４４】
他方において、アベイラビリティ・データベース（ライフ・データベース）に基づいて、どのウォッチドッグ／アプリケーション・サーバが障害を起こしているのか、そしてどのウォッチドッグ／アプリケーション・サーバがなおも使用可能であるのかが判別可能である。とりわけ、ライフ・データベースにアクセスできるあらゆるプログラムがこのチェックを実行できる。すなわち、プログラムとは、各ウォッチドッグ，この環境のために構築され得る分離管理コンポーネントおよび、もちろんアプリケーション・サービス要求を運ぶための使用可能なアプリケーション・サーバを捜す各アプリケーション・クライアントである。各アプリケーション・クライアントは、アベイラビリティ・データベースに問い合わせ、上述のアベイラビリティ基準を利用して少なくとも一つの使用可能アプリケーション・サーバを判別し、判別した使用可能アプリケーション・サーバにアプリケーション・サービス要求を送信することができる。
【００４５】
本発明のさらに有益な実施の形態は、ウォッチドッグまたはアプリケーション・サーバがそれらの通知期間を動的に調整する場合に達成可能である。この動的調整が、アプリケーション・サーバによって処理されるワークロードの総量に従属する場合には、アベイラビリティ基準は、ワークロード・インディケータをも表すことによって新しい性質になる。ワークロードの総量が増加する場合には、通知期間を増加させることにより、そして、ワークロードの総量が減少する場合には、通知期間を減少させることにより、通知期間は、アプリケーション・サーバの応答性を表現するワークロード・インディケータを（同時に）表す。このインディケータは、平行をなす一組のアプリケーション・サーバのためのアベイラビリティ基準を判別することにより、アプリケーション・クライアントによって活用され得る。この状態において、アベイラビリティ基準は、使用可能なアプリケーション・サーバのサブセットを判別するために使用され得るだけでなく（これは、２分決定、すなわち“使用可能”／“使用不可能”のみを表すこととなる）、アベイラビリティ基準は、アプリケーション・クライアントによって実行されるワークロード平衡化決定のための基礎を形成することも可能である。パラメータである現在の通知期間によって多少影響を受けるアベイラビリティ基準の数値的値は、ワークロード・インディケータでもある。アプリケーション・クライアントは、そのアプリケーション・サービス要求を、最低のワークロードを有する使用可能なアプリケーション・サーバ、すなわち、このさらなるアプリケーション要求については、最大のアベイラビリティ基準を有するアプリケーション・サーバへ発行し得る。
【００４６】
図５は、ワークロード状態に従属する通知期間に適応する動的側面をも含むアベイラビリティを表す方法を説明するフロー図である。アプリケーション・サーバまたはウォッチドッグによるアベイラビリティ・モニタリングのプロセスは、ステップ５０１内で開始される。次のステップ５０２内で、現在のワークロード状態と比較して高すぎず、あるいは低すぎない通知期間を算出するために現在のワークロード状態が判別される。この算出された通知期間は、ステップ５０３内でアベイラビリティ・データベースに（もちろん）入力されなければならない。通知期間によってセットされた時間フレーム以内に、現在のアベイラビリティ信号はアベイラビリティ・データベースに入力されなければばらない。これは、ステップ５０４において反映される。通知期間は、アベイラビリティ信号の反復のための時間制限の上限を定義する。ワークロードに従属して、アプリケーション・サーバ／ウォッチドッグは、アベイラビリティ信号をより頻繁に発行するよう試み得る。ステップ５０４の後（または、このステップよりも前に代替の実施形態として）、ステップ５０５内で現在のワークロード状態が分析される。通知期間を再調整することを必要とする方法で、現在のワークロード状態が変化した場合には、制御パス５０６を選択して、通知期間を判別するプロセス・ステップが再び開始される。現在のワークロード状態が大きくは変化しなかった場合には、パス５０７を選択してアベイラビリティ信号発行の反復が繰り返される。
【００４７】
その期間テーブル（図３において説明された），そのアベイラビリティ・テーブル（図４において説明された）を有するアベイラビリティ・データベースの構造およびレイアウトは、概念的な面のみから解釈される必要がある。もちろん、アベイラビリティ・データベースの構造は、以下のような、なおいっそうの改良の対象となり得る。
【００４８】
１．新しい通知期間、または新しいアベイラビリティ信号の各挿入は、新しいレコードをデータベースに導入し得る。アベイラビリティ・データベースが永続的に大きくなり得ることを予防するために、もはや有用でない古いデータベース・レコードを除去するというプロセスが提案される。例えば、一定のウォッチドッグ／アプリケーション・サーバの各レコード・タイプについては、最も最新のおよび直前のレコードだけがデータベース内部に維持される。このようなプロセスの実現のために、“ストアド・プロシージャ”のテクノロジが有益に活用可能である。このような適応ストアド・プロシージャは、もはや必要とされないレコードを削除するバックグラウンドにおいてデータベース内で実行可能である。
【００４９】
２．通知期間とアベイラビリティ信号とを異なるデータベース・レコード内に格納することは、もちろん本発明にとって本質ではない。双方のデータ要素を一つのデータベース・レコード内部に含む方法の例が、図６において視覚化される。図６から認められるように、ウォッチドッグＩＤ／アプリケーション・サーバＩＤ６００および通知期間６０１のほかに、複数のアベイラビリティ信号が２つのエントリだけに縮小される。現在のアベイラビリティ信号６０２が新しいアベイラビリティ信号によって更新される時はいつでも、その内容は、直前のアベイラビリティ信号６０３を格納するフィールドに転送される。その後、新しいアベイラビリティ信号が、現在のアベイラビリティ信号６０２のフィールドに挿入される。この手法を用いて、アベイラビリティ・データベースは、各ウォッチドッグ／アプリケーション・サーバについては、単一データベース・レコードが保持されなければならないだけである適度なサイズに限定される。
【００５０】
本発明の利点
提案されたテクノロジは、複数のアプリケーション・クライアントへサービスを提供する複数のアプリケーション・サーバのアベイラビリティおよびスケーラビリティを増加させる。本発明は、クライアントが、非応答的サーバからサービスを要求する誤った要求ルーティングを生成するということを予防する事前の対策を講じたテクノロジを提供する。クライアントおよびサーバが永続的にネットワークに入るまたは出るところの動的ネットワーク状態に高度に応答する継続しているプロセスが提案される。こうして、本発明は、サーバ・マシンのホット・プラグインをアプリケーション・クラスタに収容し、環境のスケーラビリティをさらに増加させることができる。アプリケーション・クライアントをアプリケーション・サーバと関係づけるための複雑な（すなわち、当然に支払われるべきその絶対的に受け入れがたい複雑性）管理努力は完全に回避される。
【００５１】
本発明は、どのようなネットワーク・ベースのメッセージ受け渡しも想定しないので、このようなメカニズムの全ての障害（上述の所見を参照されたい）が回避される。唯一のシステム条件は、共用データベースである。今日のデータベース管理システムは極めて堅固であり、従って、ライフ・データベースを障害の単一点とみなす必要はない。さらに、大抵のアプリケーション・サーバは、データベース・システムのトップに構築される。こうして、共用データベースの前提条件が多くの状態において自動的に満たされる。ホット・プールをホストすることにより、各サーバ・マシンは共用データベースにアクセスできるので、到達可能性は全然問題にならない。最後に、ウォッチドッグ・モニタリング手法は、ライフ・データベースを関係ＤＢＭＳに入れる際にＳＱＬによって容易に実現できる。
【図面の簡単な説明】
【図１】アプリケーション・サーバ，ホット・プール，アプリケーション・クラスタおよびアプリケーション・クライアントの概念を反映する図である。
【図２】そのアベイラビリティ状況を表すための通信媒体である各アプリケーション・サーバ／対応するウォッチドッグによって維持される、本発明に従って提案されたアベイラビリティ・データベースを反映する図である。
【図３】個々の通知期間を含む、本発明に従う期間テーブルのレコード様式を示す図である。
【図４】個々のアベイラビリティ信号を格納するアベイラビリティ・データベース内部のレコード様式を視覚化する図である。
【図５】ワークロード状態に従属する通知期間に適応する動的側面をも含む本発明に従ってアベイラビリティを表す方法を説明するフロー図である。
【図６】期間テーブルおよびアベイラビリティ信号テーブルを結合して単一テーブルだけにする実施例を示す図である。
【符号の説明】
１００共用リモート・データベース
１０１〜１０３サーバ・マシン
１１０〜１１８アプリケーション・サーバ
１２０アプリケーション・クラスタ
１２５入力キュー
１３０アプリケーション
１３１アプリケーション・クライアント
２００ライフ・データベース
２０１ウォッチドッグ
２０２クラスタ
２０３レコード

Claims

アプリケーション・クライアントからのアプリケーション・サービス要求を受け入れる１または複数のアプリケーション・サーバのアベイラビリティを判別するコンピュータ化された方法であって、
各アプリケーション・サーバに対応する通知期間を含む第１のデータ要素（３０１，６０１）を、アベイラビリティ・データベース（２００）に挿入する第１のステップ（５０３）を含み、
前記通知期間は、当該各アプリケーション・サーバが使用可能である間は繰り返されるアベイラビリティ信号の反復期間の時間制限の上限を定義し、
さらに、各アプリケーション・サーバに対応する最近のアベイラビリティ信号のための、最近のアベイラビリティ・タイムであるその対応するタイム・スタンプを含む第２のデータ要素（４０１，６０２）を、前記アベイラビリティ・データベースに挿入する第２のステップ（５０４）と、
各アプリケーション・サーバのワークロードの総量が増加するかまたは減少する場合は、当該各アプリケーション・サーバに対応する前記通知期間を増加させるかまたは減少させることにより、当該各アプリケーション・サーバのワークロードの総量に従属して前記通知期間を更新する第３のステップ（５０５）と、
前記アベイラビリティ・データベースに対して、各アプリケーション・サーバに対応する前記第１および前記第２のデータ要素を、前記アプリケーション・クライアントによって問い合わせる第４のステップと、
現在時刻と各アプリケーション・サーバに対応する前記第２のデータ要素のうちの前記最近のアベイラビリティ・タイムとの第１の差異を、当該各アプリケーション・サーバに対応する第１のデータ要素のうちの前記通知期間と比較することにより、当該アプリケーション・サーバのアベイラビリティの基準を判別する第５のステップと、
前記第１の差異が前記通知期間を越えない場合には、前記アベイラビリティの基準が、それに対応するアプリケーション・サーバのアベイラビリティを表すものとして、前記アプリケーション・クライアントからのアプリケーション・サービス要求を、当該対応するアプリケーション・サーバだけに発行する第６のステップとを含む、方法。
前記第１および前記第２のステップにおいて、さらに、各アプリケーション・サーバのＩＤ（３００，４００，６００）が、前記アベイラビリティ・データベースに挿入され、当該各アプリケーション・サーバに対応する前記第１および前記第２のデータ要素と関係づけられる、請求項１に記載の方法。
前記第１の差異が前記通知期間を越える場合には、前記アベイラビリティの基準は、それに対応するアプリケーション・サーバのアンアベイラビリティを表す、請求項２に記載の方法。
前記第２のステップにおいて、さらに、各アプリケーション・サーバに対応する直前のアベイラビリティ信号のための直前のアベイラビリティ・タイムを含む第３のデータ要素（６０３）が、前記アベイラビリティ・データベースに挿入され、
前記第４のステップにおいて、さらに、各アプリケーション・サーバに対応する前記第３のデータ要素を問い合わせ、
前記第５のステップにおいて、さらに、第２の差異である、各アプリケーション・サーバに対応する前記第２のデータ要素のうちの前記最近のアベイラビリティ・タイムと当該各アプリケーション・サーバに対応する前記第３のデータ要素のうちの前記直前のアベイラビリティ・タイムとの差異が、前記アベイラビリティの基準に含まれる、請求項１乃至３の何れか１項に記載の方法。