JP2012185577A - アプリケーションサーバ及びその監視プログラム - Google Patents

Abstract

【課題】マルチサーバシステムにおいて、クライアント端末からの要求に対してアプリケーションサーバが誤ったサービスを提供するのを未然に防ぐ。
【解決手段】アプリケーションサーバは、対外部死活監視ポートと、監視手段と、死活反映手段とを備える。対外部死活監視ポートは、ネットワークで接続された外部から自サーバの死活状態を判定させるためのものである。監視手段は、自サーバに実装されている監視対象アプリケーションが正しく動作しているか否かを監視する。死活反映手段は、監視手段による監視結果を対外部死活監視ポートに反映させる。
【選択図】 図３

Description

本発明の実施形態は、同等の機能を有する複数のアプリケーションサーバを連結してなるマルチサーバシステムのアプリケーションサーバ及びその監視プログラムに関する。

クライアント・サーバシステムにおいては、クライアント端末の数が増加すると、サーバの負荷が増大する。このため、サーバの処理速度が低下する懸念がある。そこで従来、同等の機能を有する複数のアプリケーションサーバを連結し、全体で１台のサーバであるかのように見せることで、サーバの負荷を分散する技術がある。

ただし、各サーバが同等の機能を有していても、全てのサーバのアプリケーションプログラムが正しく動作しているとは限らない。アプリケーションプログラムが正しく動作していないサーバにクライアント端末からの要求が与えられて、サーバから誤ったサービスがクライアントに提供される可能性がある。

特開２００９−２９４７３６号公報

本発明が解決しようとする課題は、同等の機能を有する複数のアプリケーションサーバを連結してなるマルチサーバシステムにおいて、クライアント端末からの要求に対してアプリケーションサーバが誤ったサービスを提供するのを未然に防ぐことにある。

一実施形態によれば、アプリケーションサーバは、対外部死活監視ポートと、監視手段と、死活反映手段とを備える。対外部死活監視ポートは、ネットワークで接続された外部から自サーバの死活状態を判定させるためのものである。監視手段は、自サーバに実装されている監視対象アプリケーションが正しく動作しているか否かを監視する。死活反映手段は、監視手段による監視結果を対外部死活監視ポートに反映させる。

一実施形態におけるマルチサーバシステムの全体構成図。 同実施形態におけるアプリケーションサーバのハードウェア構成を示すブロック図。 同実施形態におけるアプリケーションサーバの要部構成を示すブロック図。 同実施形態におけるアプリケーションサーバのＣＰＵが監視プログラムに従って実行する処理手順を示す流れ図。

以下、マルチサーバシステムを構成するアプリケーションサーバの一実施形態について、図面を用いて説明する。なお、この実施形態は、負荷分散装置であるロードバランサを用いてマルチサーバシステムを構築した場合である。

図１は、本実施形態におけるマルチサーバシステム１の全体構成図である。マルチサーバシステム１は、同等の機能を有する２台のアプリケーションサーバ１０Ａ，１０Ｂと、データベース２１の管理に特化したデータベースサーバ２０と、前記ロードバランサ３０とを備え、各アプリケーションサーバ１０Ａ，１０Ｂとロードバランサ３０とを、専用の通信回線４０で連結している。また、マルチサーバシステム１は、ロードバランサ３０を例えばインターネットのような汎用のネットワーク５０に接続している。ネットワーク５０には、多数のクライアント端末６０が接続されている。

かかる構成のマルチサーバシステム１は、クライアント端末６０から所望のサービスに対する処理要求が送出されると、この処理要求は、ネットワーク５０を介してロードバランサ３０に与えられる。ロードバランサ３０は、クライアント端末６０からの処理要求をアプリケーションサーバ１０Ａ，１０Ｂに配分する。アプリケーションサーバ１０Ａ，１０Ｂは、クライアント端末６０からの処理要求に応じた処理を実行する。このとき、アプリケーションサーバ１０Ａ，１０Ｂは、必要に応じてデータベースサーバ２０にアクセスして、データベース２１に対するデータの書込みや読出しを行う。アプリケーションサーバ１０Ａ，１０Ｂは、処理結果であるサービス情報を、ロードバランサ３０経由で要求元のクライアント端末６に提供する。

なお、ロードバランサ３０は、クライアント端末６０からの処理要求を、アプリケーションサーバ１０Ａ，１０Ｂの能力に応じて配分する。すなわち、両サーバ１０Ａ，１０Ｂの能力が同じで有れば均等に配分し、異なるので有ればサーバ１０Ａ，１０Ｂの反応速度に応じて配分する。

図２は、一方のアプリケーションサーバ１０Ａのハードウェア構成を示すブロック図である。なお、他方のアプリケーションサーバ１０Ｂもアプリケーションサーバ１０Ａと同一構成であるので、その説明は省略する。

アプリケーションサーバ１０Ａは、制御部本体としてＣＰＵ（Central Processing Unit）１１を搭載している。またアプリケーションサーバ１０Ａは、主記憶部を構成するＲＯＭ（Read Only Memory）１２及びＲＡＭ（Random Access Memory）１３と、補助記憶部を構成するＨＤＤ（Hard Disk Drive）１４と、タイマ１５と、通信回線４０を介して送受信されるデータ信号を入出力するＩ／Ｏポート１６と、前記データベースサーバ２０との間のデータ通信を司るインターフェース１７とを搭載している。そして、ＣＰＵ１１と、ＲＯＭ１２、ＲＡＭ１３と、ＨＤＤ１４、タイマ１５、Ｉ／Ｏポート１６及びインターフェース１７とを、アドレスバス，データバス等のバスライン１８で接続している。

かかる構成のアプリケーションサーバ１０Ａ，１０Ｂは、図３に示すように、クライアント端末６０からの要求に応じたサービスを提供するための同一のアプリケーションプログラム７１Ａ及び７１Ｂを実装している。またアプリケーションサーバ１０Ａ，１０Ｂは、上記アプリケーションプログラム７１Ａ，７１Ｂをそれぞれ監視対象とする監視プログラム７２Ａ，７２Ｂを実装している。これらのアプリケーションプログラム７１Ａ，７１Ｂ及び監視プログラム７２は、前記ＲＯＭ１２またはＨＤＤ１４に保存されている。

アプリケーションサーバ１０Ａ，１０Ｂは、Ｉ／Ｏポート１６として、対外部死活監視ポート７３Ａ，７３Ｂと、対サーバ死活監視ポート７４Ａ，７４Ｂを含む。対外部死活監視ポート７３Ａ，７３Ｂは、ロードバランサ３０からの信号を受付ける。対サーバ死活監視ポート７４Ａ，７４Ｂは、相手側のアプリケーションサーバ１０Ａ．１０Ｂからの信号を受付ける。

図４は、一方のアプリケーションサーバ１０Ａに実装された監視プログラム７２Ａに従い、同アプリケーションサーバ１０ＡのＣＰＵ１１が実行する処理手順を示す流れ図である。なお、他方のアプリケーションサーバ１０Ｂに実装された監視プログラム７２Ｂに従い、同アプリケーションサーバ１０ＢのＣＰＵ１１が実行する処理手順もこれと同一なので、ここでの説明を省略する。

監視プログラム７２Ａが起動すると、ＣＰＵ１１は、先ず、異常フラグＦを“０”にリセットする（ＳＴ１）。異常フラグＦは、ＲＡＭ１３で記憶する。次いで、ＣＰＵ１１は、自らが実装するアプリケーションプログラム７１Ａの状態をチェックする。例えばＣＰＵ１１は、仮想的にアプリケーションプログラム７１Ａを動かして正常に処理が進むか否かを監視する（ＳＴ２：監視手段）。

アプリケーションプログラム７１Ａが正常な場合（ＳＴ３のＮＯ）、ＣＰＵ１１は、異常フラグＦが“１”にセットされているか否かをチェックする（ＳＴ４）。異常フラグＦが“１”にセットされていない場合（ＳＴ４のＮＯ）、対外部死活判定ポート７３Ａ及び対サーバ死活判定ポート７４Ａは、いずれも開状態にある。この場合、ＣＰＵ１１は、ステップＳＴ１０の処理に進む。

ステップＳＴ４において、異常フラグＦが“１”にセットされていた場合（ＳＴ４のＹＥＳ）、対外部死活判定ポート７３Ａ及び対サーバ死活判定ポート７４Ａは、いずれも閉状態にある。この場合、ＣＰＵ１１は、対外部死活判定ポート７３Ａ及び対サーバ死活判定ポート７４Ａをいずれも開状態とする（ＳＴ５：死活反映手段）。またＣＰＵ１１は、異常フラグＦを“０”にリセットする（ＳＴ６）。しかる後、ＣＰＵ１１は、ステップＳＴ１０の処理に進む。

一方、ステップＳＴ３において、アプリケーションプログラム７１Ａに異常が見つかった場合（ＳＴ３のＹＥＳ）、ＣＰＵ１１は、異常フラグＦが“０”にリセットされているか否かをチェックする（ＳＴ７）。異常フラグＦが“０”にリセットされていない場合（ＳＴ７のＮＯ）、対外部死活判定ポート７３Ａ及び対サーバ死活判定ポート７４Ａは、いずれも閉状態にある。この場合、ＣＰＵ１１は、ステップＳＴ１０の処理に進む。

ステップＳＴ７において、異常フラグＦが“０”にリセットされていた場合（ＳＴ７のＹＥＳ）、対外部死活判定ポート７３Ａ及び対サーバ死活判定ポート７４Ａは、いずれも開状態にある。この場合、ＣＰＵ１１は、対外部死活判定ポート７３Ａ及び対サーバ死活判定ポート７４Ａをいずれも閉状態とする（ＳＴ８：死活反映手段）。またＣＰＵ１１は、異常フラグＦを“１”にセットする（ＳＴ９）。しかる後、ＣＰＵ１１は、ステップＳＴ１０の処理に進む。

ステップＳＴ１０では、ＣＰＵ１１は、通信回線４０を介して相手側のアプリケーションサーバ１０Ｂの対サーバ死活監視ポート７４Ｂに問合せ信号を送出する。そして、タイマ１５をスタートさせ（ＳＴ１１）、アプリケーションサーバ１０Ｂからの応答を待機する（ＳＴ１２：判定手段）。ここで、タイマ１５がタイムアウトする前に（ＳＴ１３のＮＯ）、アプリケーションサーバ１０Ｂから応答があった場合には（ＳＴ１２のＹＥＳ）、監視プログラム７２Ａが終了する。

これに対し、アプリケーションサーバ１０Ｂから応答がないまま（ＳＴ１２のＮＯ）、タイマ１５がタイムアウトした場合には（ＳＴ１３のＹＥＳ）、ＣＰＵ１１は、相手側のアプリケーションサーバ１０Ｂが異常である旨のデータを、データベース２１に記録する（ＳＴ１４：記録手段）。以上で、監視プログラム７２Ａが終了する。

監視プログラム７２Ａ，７２Ｂは、周期的に起動する。あるいは、監視プログラム７２Ａ，７２Ｂは、アトランダムに起動してもよい。各アプリケーションサーバ１０Ａ，１０ＢのＣＰＵ１１は、監視プログラム７２Ａ，７２Ｂが起動する毎に、図４の流れ図に示した手順の処理を実行する。

したがって、各アプリケーションサーバ１０Ａ，１０Ｂにそれぞれ実装されているアプリケーションプログラム７１Ａ，７１Ｂがいずれも正常なときには、アプリケーションサーバ１０Ａの対外部死活監視ポート７３Ａ及び対サーバ死活監視ポート７４Ａと、アプリケーションサーバ１０Ｂの対外部死活監視ポート７３Ｂ及び対サーバ死活監視ポート７４Ｂは、いずれも開状態にある。

一方、ロードバランサ３０は、クライアント端末６０から処理要求を受ける毎に、例えばアプリケーションサーバ１０Ａ，アプリケーションサーバ１０Ｂ，アプリケーションサーバ１０Ａ，アプリケーションサーバ１０Ｂの順に交互に転送する。このとき、アプリケーションサーバ１０Ａ，１０Ｂの各外部死活監視ポート７３Ａ，７３Ｂはいずれも開状態なので、クライアント端末６０からの処理要求はアプリケーションサーバ１０Ａ，１０ＢのＣＰＵ１１に届く。その結果、ＣＰＵ１１は、処理要求に応じたアプリケーションプログラム７１Ａ，７１Ｂを実行し、その処理結果であるサービス情報をロードバランサ３０経由で要求元のクライアント端末６に提供する。したがって、クライアント端末６０側からは、あたかも１台のアプリケーションサーバからサービスの提供を受けているように見える。

このような状況下で、今、何らかの理由により、一方のアプリケーションサーバ１０Ａに実装されているアプリケーションプログラム７１Ａが異常を来たしたとする。その場合、そのアプリケーションサーバ１０Ａの監視プログラム７２Ａに従ったＣＰＵ１１の機能により、当該アプリケーションサーバ１０Ａの対外部死活監視ポート７３Ａと対サーバ死活監視ポート７４Ａとがいずれも閉状態となる。

したがって、クライアント端末６０からの処理要求を受けたロードバランサ３０が、その要求をアプリケーションサーバ１０Ａに転送しても、対外部死活監視ポート７３Ａが閉状態にあるので、要求はアプリケーションサーバ１０ＡのＣＰＵ１１に届かない。ロードバランサ３０は、アプリケーションサーバ１０Ａの対外部死活監視ポート７３Ａが閉状態にあることから、要求を他方のアプリケーションサーバ１０Ｂに転送する。このとき、アプリケーションサーバ１０Ｂの対外部死活監視ポート７３Ａは開状態にあるので、要求はアプリケーションサーバ１０ＢのＣＰＵ１１に届く。その結果、アプリケーションサーバ１０Ｂにおいて、要求に応じた処理が正しく実行されて、サービス情報が要求元のクライアント端末６０に提供される。したがって、クライアント端末６０からの要求に対してアプリケーションサーバ１０Ａ，１０Ｂが誤ったサービスを提供するのを未然に防ぐことができる。

また、本実施形態において、アプリケーションサーバ１０Ａは、定期的あるいはアトランダムに、相手側のアプリケーションサーバ１０Ｂに問合せ信号を送出している。この問合せ信号は、アプリケーションサーバ１０Ｂの対サーバ死活監視ポート７４Ｂを経て、アプリケーションサーバ１０ＢのＣＰＵ１１に届く。そして、アプリケーションサーバ１０Ａに応答が返される。同様に、アプリケーションサーバ１０Ｂは、定期的あるいはアトランダムに、相手側のアプリケーションサーバ１０Ａに問合せ信号を送出している。この問合せ信号は、アプリケーションサーバ１０Ａの対サーバ死活監視ポート７４Ａを経て、アプリケーションサーバ１０ＡのＣＰＵ１１に届く。そして、アプリケーションサーバ１０Ｂに応答が返される。

したがって、前述したようにアプリケーションサーバ１０Ａの対サーバ死活監視ポート７４Ａが閉状態になると、アプリケーションサーバ１０Ｂからの問合せ信号に対してアプリケーションサーバ１０Ａからの応答がなくなる。その結果、アプリケーションサーバ１０Ｂは、アプリケーションサーバ１０Ａのアプリケーションプログラム７１Ａに異常が発生したことを認識できる。このとき、アプリケーションサーバ１０ＢのＣＰＵ１１は、アプリケーションサーバ１０Ａが異常である旨の情報をデータベース２１に記録する。

したがって、マルチサーバシステム１のユーザは、アプリケーションサーバ１０Ｂからの情報により、アプリケーションサーバ１０Ａに異常が発生したことを迅速に知ることができる。また、ユーザは、データベース２１の情報からその異常がいつ発生したのかと言うような詳細な情報を容易に知ることができる。

以下、前記実施形態の変形例について説明する。
例えば前記実施形態では、同等の機能を有するアプリケーションサーバの台数を２台としたが、３台以上のアプリケーションサーバを連結してなるマルチサーバシステムに対しても、本発明を適用することは可能である。

また、前記実施形態では、ロードバランサ３０を用いてマルチサーバシステムを構築した場合を示したが、クラスタリング機能を利用して各アプリケーションサーバをクラスタ化してなるマルチサーバシステムに対しても、本発明を適用できる。

さらに、前記実施形態は、サーバ内部のプログラム記憶部であるＲＯＭ１２またはＨＤＤ１４に発明の機能を実現させる監視プログラムが予め記録されているものとした。しかしこれに限らず、同様のプログラムがネットワークからアプリケーションサーバにダウンロードされてもよい。あるいは、記録媒体に記録された同様のプログラムが、アプリケーションサーバにインストールされてもよい。記録媒体は、ＣＤ−ＲＯＭ，メモリカード等のようにプログラムを記憶でき、かつ装置が読み取り可能であれば、その形態は問わない。また、プログラムのインストールやダウンロードにより得る機能は、装置内部のＯＳ（オペレーティング・システム）等と協働してその機能を実現させるものであってもよい。

この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…マルチサーバシステム、１０Ａ，１０Ｂ…アプリケーションサーバ、２０…データベースサーバ、３０…ロードバランサ、６０…クライアント、７１Ａ，７１Ｂ…アプリケーションプログラム、７２Ａ，７２Ｂ…監視プログラム、７３Ａ，７３Ｂ…対外部死活監視ポート、７４Ａ，７４Ｂ…対サーバ死活監視ポート。

Claims (6)

1. 同等の機能を有する複数台のアプリケーションサーバを連結してなるマルチサーバシステムのアプリケーションサーバであって、
   ネットワークで接続された外部から自サーバの死活状態を判定させるための対外部死活監視ポートと、
   自サーバに実装されている監視対象アプリケーションが正しく動作しているか否かを監視する監視手段と、
   この監視手段による監視結果を前記対外部死活監視ポートに反映させる死活反映手段と、
   を具備したことを特徴とするアプリケーションサーバ。
2. 連結された相手サーバから自サーバの死活状態を判定させるための対サーバ死活監視ポートと、
   連結された相手サーバの前記対サーバ死活監視ポートの状態により前記相手サーバの死活状況を判定する判定手段と、
   をさらに具備し、
   前記死活反映手段は、前記監視手段による監視結果を前記対外部死活監視ポートと前記対サーバ死活監視ポートとに反映させることを特徴とする請求項１記載のアプリケーションサーバ。
3. 前記判定手段により判定される相手サーバの死活状況をデータベースに記録する記録手段、
   をさらに具備したことを特徴とする請求項２記載のアプリケーションサーバ。
4. 同等の機能を有する複数台のアプリケーションサーバを連結してなるマルチサーバシステムのアプリケーションサーバに、
   自サーバに実装されている監視対象アプリケーションが正しく動作しているか否かを監視する監視機能と、
   ネットワークで接続された外部から自サーバの死活状態を判定させるための対外部死活監視ポートに前記監視結果を反映させる死活反映機能と、
   を実現させるための監視プログラム。
5. 前記死活反映機能は、前記対外部死活監視ポートに加えて、連結された相手サーバから自サーバの死活状態を判定させるための対サーバ死活監視ポートに前記反映結果を反映させるものであり、さらに、前記アプリケーションサーバに、
   連結された相手サーバの前記対サーバ死活監視ポートの状態により前記相手サーバの死活状況を判定する判定機能を実現させるための請求項４記載の監視プログラム。
6. さらに、前記アプリケーションサーバに、
   前記判定機能により判定される相手サーバの死活状況をデータベースに記録する機能を実現させるための請求項５記載の監視プログラム。

Images