(57)【要約】【課題】  アプリケーションサーバ上で活動するプロセス等の機能に問題が生じた場合の対応を図ることを目的とする。【解決手段】  ネットワーク環境に接続されたクライアントがディスパッチャを経由して、複数のアプリケーションサーバに処理を投入する構成を持つシステム装置において、該アプリケーションサーバの少なくともひとつに障害が発生している場合は、該ディスパッチャは処理を障害のあるアプリケーションに投入することを自動的に停止するとともに該障害が回復次第該アプリケーションサーバーへの処理の投入を自動的に再開する手段と、投入停止と投入再開に関する一連の情報をシステム装置の管理者に自動で通知する手段を備えたことを特徴とするクラスタ構成システム等、を提供する。【選択図】  図１
2005346258.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク環境に接続されたクライアントがディスパッチャを経由して、複数のアプリケーションサーバに処理を投入する構成を持つシステム装置において、
該アプリケーションサーバの少なくともひとつに障害が発生している場合は、該ディスパッチャは処理を障害のあるアプリケーションに投入することを自動的に停止するとともに該障害が回復次第該アプリケーションサーバーへの処理の投入を自動的に再開する手段と、
投入停止と投入再開に関する一連の情報をシステム装置の管理者に自動で通知する手段と、
備えたことを特徴とするクラスタ構成システム。
【請求項２】
クライアントは、インターネット技術に対応したアプリケーションを想定し、インターネットブラウザを搭載していることを特徴とする請求項１に記載のクラスタ構成システム。
【請求項３】
ディスパッチャは、該クライアントから要求された処理が、ある特定のアプリケーションサーバに集中的に投入され、高負荷とならないように、該複数のアプリケーションサーバに平均的に処理を振り分けることを特徴とする請求項１に記載のクラスタ構成システム。
【請求項４】
複数のアプリケーションサーバは、同一のアプリケーションシステムを搭載し、該クライアントから、該ディスパッチャ経由で、投入された処理を実行することを特徴とする請求項１に記載のクラスタ構成システム。
【請求項５】
該ディスパッチャは、処理を障害のあるアプリケーションに投入することを自動的に停止するに当たり、該アプリケーションサーバから通知された障害情報を認識し、自動的に該アプリケーションサーバに該クライアントから要求された処理の投入を停止することを特徴とする請求項１に記載のクラスタ構成システム。
【請求項６】
該アプリケーションサーバから通知された障害情報を認識するに当たり、該アプリケーションサーバが、常にその装置内の障害発生状況をその処理に適した方法で検査する機能を有し、異常が発生したと認識された時点で、自動的に該ディスパッチャに障害発生の情報を送信し、該ディスパッチャは該障害情報を受信し、該当するアプリケーションサーバの識別を行うことを特徴とする請求項５に記載のクラスタ構成システム。
【請求項７】
該障害の回復のために、該アプリケーションサーバが、その装置内で発生した該障害を、その処理に適した方法で自動的に回復が行われる措置、及びその機能を有することを特徴とする請求項１に記載のクラスタ構成システム。
【請求項８】
該ディスパッチャは、該アプリケーションサーバーへの処理の投入を自動的に再開するに当たり、該アプリケーションサーバから通知された障害回復情報を認識し、自動的に該アプリケーションサーバに該クライアントから要求された処理の投入を再開することを特徴とする請求項１に記載のクラスタ構成システム。
【請求項９】
該アプリケーションサーバから通知された障害回復情報を認識するに当たり、該アプリケーションサーバが、常にその装置内の障害回復状況をその処理に適した方法で検査する機能を有し、異常が回復したと認識された時点で、自動的に該ディスパッチャに障害回復の情報を送信し、該ディスパッチャは該障害回復情報を受信し、該当するアプリケーションサーバの識別を行うことを特徴とする請求項８に記載のクラスタ構成システム。
【請求項１０】
システム装置の管理者に自動で通知するに当たり、障害が発生したアプリケーションサーバの識別情報と、投入停止を行う主旨の情報、及び該システムの障害回復措置後に、処理投入の再開を行う主旨の情報を、システム装置を管理する者に対し、電子的な手段を用いて通知することを特徴とする請求項１に記載のクラスタ構成システム。
【請求項１１】
電子的な手段を用いて通知するに当たり、公知の電子メールの仕組みか、ないしは、それに準ずる機能を有する内部的に用意された手段の、いずれか所望の方法を利用して、該システム装置管理者に通知することを特徴とする請求項１０に記載のクラスタ構成システム。
【請求項１２】
ネットワーク環境に接続されたクライアントがディスパッチャを経由して、複数のアプリケーションサーバに処理を投入する構成を持つシステムにおける障害管理方法において、
該アプリケーションサーバの少なくともひとつに障害が発生している場合は、該ディスパッチャは処理を障害のあるアプリケーションに投入することを自動的に停止するとともに該障害が回復次第該アプリケーションサーバーへの処理の投入を自動的に再開する工程と、
投入停止と投入再開に関する一連の情報をシステム装置の管理者に自動で通知する工程と、
を備えたことを特徴とする障害管理方法。
【請求項１３】
請求項１２に記載の方法の各工程をコンピュータにて実現するプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションサーバ内の監視と問題検出時の対応方法を講じた、耐故障性が要求されるクラスタ構成システムに関する。
【背景技術】
【０００２】
従来、耐故障性が求められるシステムにおいては、複数のアプリケーションサーバを並列に配置したクラスタ構成が提案されており、たとえばトランザクション処理サーバの状態を解析して負荷分散を行い、障害発生時のリカバリを容易にする方法などが公開されている（例えば特許文献１参照。）。図５は、このような、ひとつのアプリケーション処理サーバに障害が発生した場合でも他の正常なアプリケーションサーバにおいてトランザクション処理を続けることができる、ウェブアプリケーションシステムでのクラスタ構成を示したシステム構成図である。
【０００３】
図５に示すが如く、クラスタ構成はブラウザ１１、〜、ブラウザ１ｎ（ｎは自然数）と、ネットワーク５１、５２、５３と、ディスパッチャ２と、アプリケーションサーバ３１、３２と、データベースサーバ４とにより構成される。
【０００４】
以上の構成において、まず、ブラウザからのトランザクション処理要求が出された場合のトランザクション処理データの流れについて説明する。
【０００５】
例えば、ブラウザ１１よりトランザクション処理要求が出されたとすると該トランザクション処理要求は、図５に示すトランザクション要求データ１１０として、ネットワーク５１を介して、ディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３１のＩＰアドレスに変換し送信する（振り分けプログラムは振り分け先リストにある宛先を順に選択するものとし、宛先リストにはアプリケーションサーバ３１とアプリケーションサーバ３２が登録され、まずアプリケーションサーバ３１が選択されたものとする）。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３１へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１１へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【０００６】
さらに、ブラウザ１２よりトランザクション処理要求が出されたとすると該トランザクション処理要求は図５に示すトランザクション処理データ１２０として、ネットワーク５１を介して、ディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３２のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３２へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１２へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【０００７】
このようにディスパッチャの振り分け機能によって複数のアプリケーションサーバにトランザクション処理要求が振り分けられる。
【０００８】
次に、アプリケーションサーバが障害等によりダウンした場合のトランザクション処理データの流れについての説明を行う。
【０００９】
図６（図５と同一の構成については同一の符号を付すため、説明は省略する）は、複数のアプリケーションサーバを並列に配置したクラスタ構成によるオンライン処理システムで、アプリケーションサーバ障害時におけるトランザクション処理データの流れを示した図である。
【００１０】
図６の構成において、アプリケーションサーバ３２が障害等によりダウンしているとする。この時、ディスパッチャ２はアプリケーションサーバ３２の障害を検知し振り分け先リストから該アプリケーションサーバであるアプリケーションサーバ３２を除くよう振舞う（一般的にディスパッチャはアプリケーションサーバのダウン等を検出する機能を有しており、例えばアプリケーションサーバに対し定期的にＨＴＴＰリクエストを要求するなどして、その応答状況からアプリケーションサーバの障害やＨＴＴＰサーバの異常を認識できる）。この状態で、ブラウザ１１よりトランザクション処理要求が出されたとすると該トランザクション処理要求は、図６に示すトランザクション要求データ１１０として、ネットワーク５１を介して、ディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３１のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３１へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１１へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【００１１】
さらに、ブラウザ１２よりトランザクション処理要求が出されたとすると該トランザクション処理要求は図６に示すトランザクション処理データ１２０として、ネットワーク５１を介して、ディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３１のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３１へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１２へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【００１２】
このようにダウンしているアプリケーションサーバを回避して正常なアプリケーションサーバにのみトランザクション処理要求が振り分けられる。
【００１３】
次に、アプリケーションサーバ上で活動するあるプロセスに問題が発生した場合のトランザクション処理データの流れについての説明を行う。
【００１４】
図７（図５と同一の構成については同一の符号を付すため、説明は省略する）は、複数のアプリケーションサーバを並列に配置したクラスタ構成によるオンライン処理システムで、アプリケーションサーバ上で活動する業務アプリケーション上重要なプロセスに問題が発生し該プロセスが応答しなくなった時におけるトランザクション処理データの流れを示した図である。
【００１５】
図７の構成において、アプリケーションサーバ３２上で活動するプロセス３２０が何らかの原因で外からの要求に対し応答しなくなったとする。この時、ディスパッチャ２はアプリケーションサーバ３２が正常であると認識し振り分け先リストには該アプリケーションサーバであるアプリケーションサーバ３２が保持されている。この状態で、ブラウザ１１よりトランザクション処理要求が出されたとすると該トランザクション処理要求は、図７に示すトランザクション要求データ１１０として、ネットワーク５１を介して、ディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３１のＩＰアドレスに変換し送信する（振り分けプログラムは振り分け先リストにある宛先を順に選択するものとし、宛先リストにはアプリケーションサーバ３１とアプリケーションサーバ３２が登録され、まずアプリケーションサーバ３１が選択されたものとする）。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３１へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１１へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【００１６】
さらに、ブラウザ１２よりトランザクション処理要求が出されたとすると該トランザクション処理要求は図７に示すトランザクション処理データ１２０として、ネットワーク５１を介して、ディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３２のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３２へ到着しトランザクション処理要求に従った手続きを行おうとするが手続きを進める上でプロセス３２０が応答しないため処理が不可能となり、ブラウザ１２へ結果が戻ることもない。
【００１７】
このようにアプリケーションサーバ上のプロセスが応答しなくなった場合、該アプリケーションサーバへ振り分けられたトランザクション要求データは処理が不可能となる。
【００１８】
【特許文献１】特開２０００−２５９５３９号公報（第２−３頁、第１図）
【発明の開示】
【発明が解決しようとする課題】
【００１９】
以上説明したように、上記従来技術には、アプリケーションサーバ上で活動するプロセス等の機能に問題が生じた場合、ブラウザからのトランザクション要求データの処理が不可能となり、クラスタ構成のシステム装置でありながら結果的にブラウザから要求された処理が実行されない、という事態を招く問題があった。
【００２０】
ここでは、クラスタ構成を活かして、いかなる事態であっても、該処理を停止させない自動的な仕組みが必要とされる。
【００２１】
本発明は、こうした問題を鑑みてなされたもので、障害が発生しても、そのアプリケーションサーバに処理を投入時の自動リカバリを実現するため、クラスタ構成システムにおけるアプリケーションサーバ内の監視と問題検出時の対応方法を提供することを目的とする。
【課題を解決するための手段】
【００２２】
本発明は上記課題を解決するために、ネットワーク環境に接続されたクライアントがディスパッチャを経由して、複数のアプリケーションサーバに処理を投入する構成を持つシステム装置において、該アプリケーションサーバの少なくともひとつに障害が発生している場合は、該ディスパッチャは処理を障害のあるアプリケーションに投入することを自動的に停止するとともに該障害が回復次第該アプリケーションサーバーへの処理の投入を自動的に再開する手段と、投入停止と投入再開に関する一連の情報をシステム装置の管理者に自動で通知する手段を備えたことを特徴とするクラスタ構成システム等、を提供する。
【発明の効果】
【００２３】
本発明を実施することにより、従来技術では、アプリケーションサーバ上で活動するプロセス等の機能に問題が生じた場合、ブラウザからのトランザクション要求データの処理が不可能となり、クラスタ構成のシステム装置にありながら、結果的にブラウザから要求された処理が実行されない、という事態を招く問題は解決され、クラスタ構成を活かして、いかなる事態であっても、該処理を停止させず、非常に耐故障性に優れたクラスタ構成システムを提供することができる。
【発明を実施するための最良の形態】
【００２４】
以下、本発明の実施の形態について図面に基づいて詳細に説明する。
【００２５】
図１は、本発明のクラスタ構成システムにおけるアプリケーションサーバ内監視と問題検出時の対応方法の実施の形態を示したシステム構成図である。
【００２６】
図１に示すが如く、本発明のクラスタ構成システムにおけるアプリケーションサーバ内監視と問題検出時の対応方法は、ブラウザ１１、〜、ブラウザ１ｎ（ｎは自然数）と、ネットワーク５１、５２、５３と、ディスパッチャ２と、アプリケーションサーバ３１、３２と、データベースサーバ４とにより構成される。
【００２７】
ブラウザ１１、〜、ブラウザ１ｎは、それぞれネットワーク５１を介して、ディスパッチャ２と接続されていて、ディスパッチャ２は、ネットワーク５２を介して、アプリケーションサーバ３１、３２と接続されていて、アプリケーションサーバ３１、３２は、ネットワーク５３を介して、データベースサーバ４と接続されている。
【００２８】
上記ディスパッチャ２は、ブラウザからのトランザクション処理要求をアプリケーションサーバへ振り分ける機能（以降、振り分けプログラムともいう）を有するものとする。また、ディスパッチャ２は振り分け先リストを保持し、予め振り分け先リストに登録されているアプリケーションサーバのいずれかにトランザクション処理要求を送信するものとする。ここではアプリケーションサーバ３１、３２のふたつが振り分け先リストに登録されているものとする。また、本実施の形態では、ディスパッチャ２は、アプリケーションサーバがダウンしていた場合には該アプリケーションサーバへの送信を行わないよう振舞う機能を有するものとする。
【００２９】
各アプリケーションサーバには汎用的なアプリケーションや業務アプリケーションなどの様々なプロセスが活動しているが、本実施の形態では、ブラウザからのトランザクション処理要求を実施する上で、必ず正常に活動していなければならないプロセスとして、プロセス３１０、３２０があるものとする。
【００３０】
尚、本実施の形態においては、ネットワーク５１、５２、５３の３つのネットワークにわけて説明を行っているが、同一のネットワークであっても良い。また、２台のアプリケーションサーバを想定して説明を行っているが、３台以上のアプリケーションサーバであっても良い。また、アプリケーションサーバ内で必ず正常に活動していなければならないプロセスの数は各アプリケーションサーバにひとつとしているが、２つ以上のプロセスであっても良い。
【００３１】
次に、図２（図１と同一の構成については同一の符号を付すため、説明は省略する）のシステム構成図と図４の監視手段処理動作を参照して、プロセス３１０、３２０が正常な状態での監視手段３１１、３２１の動作と、前動作のもとでブラウザ１１、１２からトランザクション処理要求が出された場合におけるトランザクション処理動作について説明を行う。
【００３２】
まず、監視手段の動作について説明を行う。
【００３３】
アプリケーションサーバ３１内の監視手段３１１は、同一アプリケーションサーバ内のプロセス３１０の状態が正常か否かを確認する手段を実行し（Ｓ０１）、プロセス３１０の状態が正常か否かを判定する（Ｓ０２）。ここではプロセス３１０の状態は正常であることから、予め定められた一定時間を待って（Ｓ０３）、再びプロセス３１０が正常か否かを確認する手段（Ｓ０１）を実行する。
【００３４】
アプリケーションサーバ３２内の監視手段３２１も同様に、同一アプリケーションサーバ内のプロセス３２０の状態が正常か否かを確認する手段を実行し（Ｓ０１）、プロセス３２０の状態が正常か否かを判定する（Ｓ０２）。ここではプロセス３２０の状態が正常であることから、予め定められた一定時間を待って（Ｓ０３）、再びプロセス３２０が正常か否かを確認する手段（Ｓ０１）を実行する。
【００３５】
上記監視手段３１１、３２１の動作から、ディスパッチャ２の振り分け先リストにはアプリケーションサーバ３１、３２のふたつが登録されているままとなっている。
【００３６】
続いてブラウザからのトランザクション処理動作について説明を行う。
【００３７】
ブラウザ１１から出されたトランザクション処理要求は、図２が示すトランザクション要求データ１１０として、ネットワーク５１を経由してディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３１のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３１へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１１へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【００３８】
ブラウザ１２から出されたトランザクション処理要求は、図２が示すトランザクション要求データ１２０として、ネットワーク５１を経由してディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３２のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３２へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１２へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【００３９】
次に、図３（図２と同一の構成については同一の符号を付すため、説明は省略する）のシステム構成図と図４の監視手段処理動作を参照して、プロセス３１０が正常な状態、プロセス３２０が異常な状態での監視手段３１１、３２１の動作と、前動作のもとでブラウザ１１、１２からトランザクション処理要求が出された場合におけるトランザクション処理動作について説明を行う。
【００４０】
まず、監視手段の動作について説明を行う。
【００４１】
アプリケーションサーバ３１内の監視手段３１１は、同一アプリケーションサーバ内のプロセス３１０の状態が正常か否かを確認する手段を実行し（Ｓ０１）、プロセス３１０の状態が正常か否かを判定する（Ｓ０２）。ここではプロセス３１０の状態は正常であることから、予め定められた一定時間を待って（Ｓ０３）、再びプロセス３１０が正常か否かを確認する手段（Ｓ０１）を実行する。
【００４２】
アプリケーションサーバ３２内の監視手段３２１も同様に、同一アプリケーションサーバ内のプロセス３２０の状態が正常か否かを確認する手段を実行し（Ｓ０１）、プロセス３２０の状態が正常か否かを判定する（Ｓ０２）。ここではプロセス３２０の状態が異常であることが検出され、トランザクション要求データが自アプリケーションサーバへ振り分けられないようにする手段を実行し（Ｓ０４）、システム保守要員へメール通知を行う（Ｓ０５）。
【００４３】
ここまでの上記監視手段３１１、３２１の動作から、ディスパッチャ２の振り分け先リストにはアプリケーションサーバ３１のみが登録された状態となっている。
【００４４】
この状態でブラウザからのトランザクション処理動作について説明を行う。
【００４５】
ブラウザ１１から出されたトランザクション処理要求は、図２が示すトランザクション要求データ１１０として、ネットワーク５１を経由してディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３１のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３１へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１１へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【００４６】
ブラウザ１２から出されたトランザクション処理要求は、図２が示すトランザクション要求データ１２０として、ネットワーク５１を経由してディスパッチャ２に到着する。ディスパッチャ２では、振り分けプログラムが到着したトランザクション要求データの宛先ＩＰアドレスを振り分け先リストを参照して登録されていたアプリケーションサーバ３１のＩＰアドレスに変換し送信する。送信されたトランザクション処理要求はネットワーク５２を介してアプリケーションサーバ３１へ到着しトランザクション処理要求に従った手続きを行い、結果がブラウザ１２へ戻る。ここでデータベースの検索や更新を行う場合にはネットワーク５３を介してデータベースサーバ４で処理が行われることになる。
【００４７】
次に、監視手段の動作の続きについて説明を行う。
【００４８】
アプリケーションサーバ３２内の監視手段３２１は、システム保守要員へのメール通知（Ｓ０５）のあと、異常な状態のプロセス３２０を再起動する手段を実行する（Ｓ０６）。さらに前再起動が完了したか否かを確認する手段を実行し（Ｓ０７）、プロセス３２０が正常か否かを判定する（Ｓ０８）。異常であることが検出されれば再起動が完了していないことなり、予め定められた時間を待って（Ｓ０９）、再び再起動が完了したか否かを確認する手段を実行し（Ｓ０７）、プロセス３２０が正常か否かを判定する（Ｓ０８）。正常であることが確認できれば、トランザクション要求データが自アプリケーションサーバへ振り分けられるようにする手段を実行し（Ｓ１０）、システム保守要員へメール通知を行い（Ｓ１１）、再びプロセス３２０が正常か否かを確認する手段を実行する（Ｓ０１）。
【００４９】
上記監視手段３２１の動作から、ディスパッチャ２の振り分け先リストにはアプリケーションサーバ３１、３２のふたつが登録されることとなり、以降、ブラウザからのトランザクション処理要求は、図２のシステム構成図と図４の監視手段処理動作を参照して前述したトランザクション処理動作と同様のものとなる。
【００５０】
このように、本発明の実施の形態によれば、従来のシステムでは、図７に示すが如くに、アプリケーションサーバ上のプロセスが機能しなくなった場合に該アプリケーションサーバ宛てに振り分けられたトランザクション要求データが処理されないのに対し、本発明では、図３に示すが如くに、他の正常なアプリケーションサーバに振り分けることによって、トランザクション要求データを処理することができる。
【００５１】
さらに、アプリケーションサーバ上の機能しなくなったプロセスの再起動を行い、再びプロセスを正常な状態に回復させた上で、トランザクション要求データを該アプリケーションサーバ宛てに振り分けることができるようになり、非常に耐故障性に優れたクラスタ構成システムを提供することができる。
【００５２】
尚、プロセスが正常か否かを確認する手段（Ｓ０１）の具体的な方法について、ＯＳ等が提供するシステム管理ツールのステータスを使用するという方法もあるが、該ステータスは正常でも実態は異常であるケースもあることから、実際にプロセスに対し何らかの要求を行い、その結果を評価するという方法が望ましい。
【００５３】
また、ディスパッチャが自アプリケーションサーバへ振り分けないようにする手段（Ｓ０４）や、振り分けるようにする手段（Ｓ１０）の具体的な方法について、ディスパッチャ内の振り分け先情報を直接操作する方法もあるが、例えばディスパッチャがアプリケーションサーバの稼動を監視する手段としてＨＴＴＰリクエストを定期的に要求しているのであれば、アプリケーションサーバ内のＨＴＴＰサーバを停止したり起動したりすることでディスパッチャに認識させるという方法もあり、マルチベンダやマルチプラットフォームの環境ではこうした手順の方が容易である。
【００５４】
なお、本発明の実施形態は、例えばコンピュータがプログラムを実行することによって実現することができる。また、プログラムをコンピュータに供給するための手段、例えばかかるプログラムを記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体又はかかるプログラムを伝送するインターネット等の伝送媒体も本発明の実施形態として適用することができる。また、上記のプログラムも本発明の実施形態として適用することができる。上記のプログラム、記録媒体、伝送媒体及びプログラムプロダクトは、本発明の範疇に含まれる。
【図面の簡単な説明】
【００５５】
【図１】本発明のクラスタ構成システムにおけるアプリケーションサーバ内監視と問題検出時の対応方法の実施の形態を示したシステム構成図である。
【図２】本実施の形態におけるプロセス３１０、３２０が正常な状態でブラウザ１１、１２からトランザクション処理要求が出された場合のトランザクション要求データの流れを示したシステム構成図である。
【図３】本実施の形態におけるプロセス３１０が正常で、プロセス３２０が異常な状態でブラウザ１１、１２からトランザクション処理要求が出された場合のトランザクション要求データの流れを示したシステム構成図である。
【図４】本実施の形態におけるプロセスの監視を行う監視手段の処理動作を表したフローチャートである。
【図５】従来の複数のアプリケーションサーバを並列に配置したクラスタ構成で、全てのアプリケーションサーバが正常な状態におけるトランザクション要求データの流れを示したシステム構成図である。
【図６】従来の複数のアプリケーションサーバを並列に配置したクラスタ構成で、一部のアプリケーションサーバがダウンした状態におけるトランザクション要求データの流れを示したシステム構成図である。
【図７】従来の複数のアプリケーションサーバを並列に配置したクラスタ構成で、一部のアプリケーションサーバ内で活動するプロセスが応答しなくなった状態におけるトランザクション要求データの流れを示したシステム構成図である。
【符号の説明】
【００５６】
１１，１２，１３，１４，１５，〜，１ｎ・・・ブラウザ
１１０，１２０・・・トランザクション要求データ
２・・・ディスパッチャ
３１，３２・・・アプリケーションサーバ
３１０，３２０・・・プロセス
３１１，３２１・・・監視手段
４・・・データベースサーバ
５１，５２，５３・・・ネットワーク
【図１】
2005346258.tif 000003
【図２】
2005346258.tif 000004
【図３】
2005346258.tif 000005
【図４】
2005346258.tif 000006
【図５】
2005346258.tif 000007
【図６】
2005346258.tif 000008
【図７】
2005346258.tif 000009