(57)【要約】【課題】縮退可能サーバを高い信頼性で検出すること。【解決手段】サーバ１０（＃１，＃２，・・・＃ｎ）の各々について、アプリケーションａに関する負荷情報をロードバランサ１２を介して取得し、負荷情報と、他のアプリケーションとの依存関係とから、処理停止が可能と推定されるサーバ１０（＃１）を決定し、サーバ１０（＃１）をロードバランサ１２による制御から切り離す。その後、アプリケーションａによる処理を待機させ、待機後、サーバ１０（＃２，・・・＃ｎ）の処理負荷に基づいて、サーバ１０（＃１）によるアプリケーションａの処理停止が可能かを判定し、可能な場合には、サーバ１（＃１）によるアプリケーションａの処理を停止させ、不可な場合には、サーバ１０（＃１）を、ロードバランサ１２によって制御されるように復帰させる。【選択図】      図１
2008234356.tif 000002
【特許請求の範囲】
【請求項１】
複数のサーバと、前記複数のサーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように前記複数のサーバを制御する負荷分散装置とを備えた負荷分散クラスタシステムに適用され、前記複数のサーバのうち、前記アプリケーションによる処理を停止させることが可能なサーバを検出するシステムであって、
前記複数のサーバのおのおのについて、前記アプリケーションによる処理に関する負荷情報を前記負荷分散装置を介して取得する取得手段と、
前記取得手段によって取得された負荷情報と、他のアプリケーションとの依存関係とから、前記処理を停止させることが可能であると推定されるサーバを決定する推定手段と、
前記推定手段によって決定されたサーバを、前記負荷分散装置による制御から切り離す切離手段と、
前記切離手段による切り離し後、前記複数のサーバのうち、前記切り離されたサーバ以外のサーバの処理負荷が安定するまで前記アプリケーションによる処理を待機させる待機手段と、
前記待機手段による待機後、前記切り離されたサーバ以外のサーバの処理負荷に基づいて、前記切り離されたサーバによる前記アプリケーションの処理を停止することが可能であるかを判定する判定手段と、
前記判定手段によって停止可能と判定された場合には、前記切り離されたサーバによる前記アプリケーションの処理を停止させる停止手段と、
前記判定手段によって停止不可と判定された場合には、前記切り離されたサーバを、前記負荷分散装置によって制御されるように復帰させる復帰手段と
を備えたサーバ検出システム。
【請求項２】
１又は複数のサーバからなる複数のサーバ層と、前記複数のサーバ層に含まれる各サーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように前記各サーバ層にそれぞれ設けられ、前記複数のサーバを制御する複数の負荷分散装置とを備えた負荷分散クラスタシステムに適用され、前記複数のサーバのうち、前記アプリケーションによる処理を停止させることが可能なサーバを検出するシステムであって、
前記複数のサーバのおのおのについて、前記アプリケーションによる処理に関する負荷情報を前記各負荷分散装置を介して取得する取得手段と、
前記取得手段によって取得された負荷情報から、前記サーバ層毎の処理負荷の平均値を求め、前記平均値が最も低いサーバ層を決定する決定手段と、
前記決定手段によって決定されたサーバ層に含まれるサーバのうち、前記取得手段によって取得された負荷情報と、他のアプリケーションとの依存関係とから、前記処理を停止させることが可能であると推定されるサーバを決定する推定手段と、
前記推定手段によって決定されたサーバを、前記負荷分散装置による制御から切り離す切離手段と、
前記切離手段による切り離し後、前記切り離されたサーバが属するサーバ層に属する複数のサーバのうち、前記切り離されたサーバ以外のサーバの処理負荷が安定するまで前記アプリケーションによる処理を待機させる待機手段と、
前記待機手段による待機後、前記切り離されたサーバ以外のサーバの処理負荷に基づいて、前記切り離されたサーバによる前記アプリケーションの処理を停止することが可能であるかを判定する判定手段と、
前記判定手段によって停止可能と判定された場合には、前記切り離されたサーバによる前記アプリケーションの処理を停止させる停止手段と、
前記判定手段によって停止不可と判定された場合には、前記切り離されたサーバを、前記負荷分散装置によって制御されるように復帰させる復帰手段とを備え、
前記復帰手段によって前記サーバが前記負荷分散装置によって制御されるように復帰された場合には、前記決定手段は、前記平均値が次に低いサーバ層を決定し、前記推定手段、前記切離手段、前記待機手段、前記判定手段、前記停止手段、及び前記復帰手段は、前記決定手段によって決定された平均値が次に低いサーバ層を対象とした処理を行うことを繰り返すようにしたサーバ検出システム。
【請求項３】
前記判定手段は、前記処理負荷が、予め定めた閾値を超えない場合に、前記切り離されたサーバによる前記アプリケーションの処理を停止することが可能であると判定する請求項１又は請求項２のサーバ検出システム。
【請求項４】
複数のサーバと、前記複数のサーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように前記複数のサーバを制御する負荷分散装置とを備えた負荷分散クラスタシステムに適用され、前記複数のサーバのうち、前記アプリケーションによる処理を停止させることが可能なサーバを検出するプログラムであって、
前記複数のサーバのおのおのについて、前記アプリケーションによる処理に関する負荷情報を前記負荷分散装置を介して取得する機能、
前記取得された負荷情報と、他のアプリケーションとの依存関係とから、前記処理を停止させることが可能であると推定されるサーバを決定する機能、
前記決定されたサーバを、前記負荷分散装置による制御から切り離す機能、
前記切り離し後、前記複数のサーバのうち、前記切り離されたサーバ以外のサーバの処理負荷が安定するまで前記アプリケーションによる処理を待機させる機能、
前記待機後、前記切り離されたサーバ以外のサーバの処理負荷に基づいて、前記切り離されたサーバによる前記アプリケーションの処理を停止することが可能であるかを判定する機能、
停止可能と判定された場合には、前記切り離されたサーバによる前記アプリケーションの処理を停止させる機能、
停止不可と判定された場合には、前記切り離されたサーバを、前記負荷分散装置によって制御されるように復帰させる機能
をコンピュータに実現させるためのプログラム。
【請求項５】
１又は複数のサーバからなる複数のサーバ層と、前記複数のサーバ層に含まれる各サーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように前記各サーバ層にそれぞれ設けられ、前記複数のサーバを制御する複数の負荷分散装置とを備えた負荷分散クラスタシステムに適用され、前記複数のサーバのうち、前記アプリケーションによる処理を停止させることが可能なサーバを検出するプログラムであって、
前記複数のサーバのおのおのについて、前記アプリケーションにより処理に関する負荷情報を前記各負荷分散装置を介して取得する機能、
前記取得された負荷情報から、前記サーバ層毎の処理負荷の平均値を求め、前記平均値が最も低いサーバ層を決定する機能、
前記決定されたサーバ層に含まれるサーバのうち、前記取得された負荷情報と、他のアプリケーションとの依存関係とから、前記処理を停止させることが可能であると推定されるサーバを決定する機能、
前記決定されたサーバを、前記負荷分散装置による制御から切り離す機能、
前記切り離し後、前記切り離されたサーバが属するサーバ層に属する複数のサーバのうち、前記切り離されたサーバ以外のサーバの処理負荷が安定するまで前記アプリケーションによる処理を待機させる機能、
前記待機後、前記切り離されたサーバ以外のサーバの処理負荷に基づいて、前記切り離されたサーバによる前記アプリケーションの処理を停止することが可能であるかを判定する機能、
停止可能と判定された場合には、前記切り離されたサーバによる前記アプリケーションの処理を停止させる機能、
停止不可と判定された場合には、前記切り離されたサーバを、前記負荷分散装置によって制御されるように復帰させる機能をコンピュータに実現させ、
前記サーバが前記負荷分散装置によって制御されるように復帰された場合には、前記平均値が次に低いサーバ層を対象に前記各機能を繰り返すプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサーバと、前記複数のサーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させる負荷分散クラスタシステムに適用され、前記複数のサーバのうち、前記アプリケーションによる処理を停止させることが可能なサーバ、すなわち縮退可能サーバを検出するシステム及びプログラムに関する。
【背景技術】
【０００２】
負荷分散クラスタシステムとは、複数のサーバから構成され、同じアプリケーションを複数のサーバで同時並列に稼動させて、負荷を分散させるシステムである。この負荷分散クラスタシステムにおいて、各サーバのアプリケーションの負荷状態を監視し、負荷状態に応じて、サービスの開始、停止、リセット（強制停止）を制御する機能をワークロード管理と呼ぶ。ここで、サービスとは、アプリケーション、共有ディスク、ＩＰアドレスなどを運用するために必要な制御対象を総称している。
【０００３】
この種のワークロード管理におけるサービスの制御は、例えば特許文献１や特許文献２により知られており、従来、アプリケーションの監視を行うモジュールは、アプリケーションの負荷状態を判断するための情報として、各サーバ（または負荷分散装置）からアプリケーションが使用しているＣＰＵ、メモリ、ディスクＩ／Ｏ、コネクション数、レスポンスタイムなどを収集している（対象アプリケーションにより収集情報は異なる）。ワークロード管理では、収集した負荷情報から、高負荷であると判断したら、サービスを実行しているノード数（サービス実行ノード数）を増加させ、低負荷であると判断したら、サービスを実行しているノード数を減少させる処理を行う。このワークロード管理により、アプリケーションが使用するサーバ資源を有効利用し、高いサービスレベルの維持を実現する。サービス実行サーバ数の増減方法には、大きく以下の２通りある。
【０００４】
１）ＯＳが起動している状態で、サービスの開始・停止を行う。  
２）サービスの開始・停止に加え、ＯＳの起動・シャットダウンまで行う。
【特許文献１】特開２００２−１６３２４１号公報
【特許文献２】特開２００５−３４６２０４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、このような従来のワークロード管理におけるサービスの制御では、以下のような問題がある。
【０００６】
すなわち、従来方式では、あるサーバを低負荷であると判断し、縮退処理（サービスを停止させてサービス実行サーバ数を減少させる処理）を行った場合、他のサーバにクライアントからのリクエストが分散され、他のサーバが高負荷になり、負荷を減少させるために再びサーバの追加（サービスを開始させてサービス実行サーバ数を増加させる）が行われる。これは、従来収集している負荷情報からは、サーバの縮退による別のサーバへの影響が正確に判断できないためである。
【０００７】
このようなケースでは、サービスの開始、停止が繰り返されることになり、アプリケーションの開始、停止や共有ディスクの制御などを行うため、エラーが発生する可能性がある処理を頻繁に実行することになる。そのため、短い期間でサービスの開始、停止を繰り返し行うと、アプリケーションの開始、停止エラーやディスクの制御エラーにより、障害が発生する可能性が高くなる。特に、ＯＳの起動・シャットダウンまで行う場合には、障害発生の確率が大きくなり、サービス停止時間が長くなる。
【０００８】
上記問題は、縮退処理を行う前に、他サーバに最も影響を及ぼさないサーバを検出することにより解決できる。このような縮退可能サーバが検出できれば、縮退処理を実行後に他のサーバが高負荷になる可能性が低くなるため、再びサーバの追加処理が発生しなくなる。
【０００９】
本発明はこのような事情に鑑みてなされたものであり、低負荷であると推定されるサーバを一時的に切り離すことにより、高い信頼性で、縮退可能サーバを検出することが可能なサーバ検出システム及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するために、本発明では、以下のような手段を講じる。
【００１１】
すなわち、請求項１の発明は、複数のサーバと、複数のサーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように複数のサーバを制御する負荷分散装置とを備えた負荷分散クラスタシステムに適用され、複数のサーバのうち、アプリケーションによる処理を停止させることが可能なサーバを検出するシステムである。このシステムは、複数のサーバのおのおのについて、アプリケーションによる処理に関する負荷情報を負荷分散装置を介して取得する取得手段と、取得手段によって取得された負荷情報と、他のアプリケーションとの依存関係とから、処理を停止させることが可能であると推定されるサーバを決定する推定手段と、推定手段によって決定されたサーバを、負荷分散装置による制御から切り離す切離手段と、切離手段による切り離し後、複数のサーバのうち、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷が安定するまでアプリケーションによる処理を待機させる待機手段と、待機手段による待機後、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷に基づいて、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止することが可能であるかを判定する判定手段と、判定手段によって停止可能と判定された場合には、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止させる停止手段と、判定手段によって停止不可と判定された場合には、負荷分散装置から切り離されたサーバを、負荷分散装置によって制御されるように復帰させる復帰手段とを備える。
【００１２】
請求項２の発明は、１又は複数のサーバからなる複数のサーバ層と、複数のサーバ層に含まれる各サーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように各サーバ層にそれぞれ設けられ、複数のサーバを制御する複数の負荷分散装置とを備えた負荷分散クラスタシステムに適用され、複数のサーバのうち、アプリケーションによる処理を停止させることが可能なサーバを検出するシステムである。このシステムは、複数のサーバのおのおのについて、アプリケーションにより処理に関する負荷情報を各負荷分散装置を介して取得する取得手段と、取得手段によって取得された負荷情報から、サーバ層毎の処理負荷の平均値を求め、平均値が最も低いサーバ層を決定する決定手段と、決定手段によって決定されたサーバ層に含まれるサーバのうち、取得手段によって取得された負荷情報と、他のアプリケーションとの依存関係とから、処理を停止させることが可能であると推定されるサーバを決定する推定手段と、推定手段によって決定されたサーバを、負荷分散装置による制御から切り離す切離手段と、切離手段による切り離し後、切り離されたサーバが属するサーバ層に属する複数のサーバのうち、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷が安定するまでアプリケーションによる処理を待機させる待機手段と、待機手段による待機後、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷に基づいて、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止することが可能であるかを判定する判定手段と、判定手段によって停止可能と判定された場合には、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止させる停止手段と、判定手段によって停止不可と判定された場合には、負荷分散装置から切り離されたサーバを、負荷分散装置によって制御されるように復帰させる復帰手段とを備える。そして、復帰手段によってサーバが負荷分散装置によって制御されるように復帰された場合には、決定手段は、平均値が次に低いサーバ層を決定し、推定手段、切離手段、待機手段、判定手段、停止手段、及び復帰手段は、決定手段によって決定された平均値が次に低いサーバ層を対象とした処理を行うことを繰り返すようにしている。
【００１３】
請求項３の発明は、判定手段は、処理負荷が、予め定めた閾値を超えない場合に、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止することが可能であると判定する請求項１又は請求項２のサーバ検出システムである。
【００１４】
請求項４の発明は、複数のサーバと、複数のサーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように複数のサーバを制御する負荷分散装置とを備えた負荷分散クラスタシステムに適用され、複数のサーバのうち、アプリケーションによる処理を停止させることが可能なサーバを検出するプログラムである。このプログラムは、複数のサーバのおのおのについて、アプリケーションにより処理に関する負荷情報を負荷分散装置を介して取得する機能、取得された負荷情報と、他のアプリケーションとの依存関係とから、処理を停止させることが可能であると推定されるサーバを決定する機能、決定されたサーバを、負荷分散装置による制御から切り離す機能、切り離し後、複数のサーバのうち、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷が安定するまでアプリケーションによる処理を待機させる機能、待機後、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷に基づいて、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止することが可能であるかを判定する機能、停止可能と判定された場合には、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止させる機能、停止不可と判定された場合には、負荷分散装置から切り離されたサーバを、負荷分散装置によって制御されるように復帰させる機能をコンピュータに実現させるためのプログラムである。
【００１５】
請求項５の発明は、１又は複数のサーバからなる複数のサーバ層と、複数のサーバ層に含まれる各サーバにおいて同時並列して動作するアプリケーションによる処理負荷を分散させるように各サーバ層にそれぞれ設けられ、複数のサーバを制御する複数の負荷分散装置とを備えた負荷分散クラスタシステムに適用され、複数のサーバのうち、アプリケーションによる処理を停止させることが可能なサーバを検出するプログラムである。このプログラムは、複数のサーバのおのおのについて、アプリケーションによる処理に関する負荷情報を各負荷分散装置を介して取得する機能、取得された負荷情報から、サーバ層毎の処理負荷の平均値を求め、平均値が最も低いサーバ層を決定する機能、決定されたサーバ層に含まれるサーバのうち、取得された負荷情報と、他のアプリケーションとの依存関係とから、処理を停止させることが可能であると推定されるサーバを決定する機能、決定されたサーバを、負荷分散装置による制御から切り離す機能、切り離し後、切り離されたサーバが属するサーバ層に属する複数のサーバのうち、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷が安定するまでアプリケーションによる処理を待機させる機能、待機後、負荷分散装置から切り離されたサーバ以外のサーバの処理負荷に基づいて、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止することが可能であるかを判定する機能、停止可能と判定された場合には、負荷分散装置から切り離されたサーバによるアプリケーションの処理を停止させる機能、停止不可と判定された場合には、負荷分散装置から切り離されたサーバを、負荷分散装置によって制御されるように復帰させる機能をコンピュータに実現させ、サーバが負荷分散装置によって制御されるように復帰された場合には、平均値が次に低いサーバ層を対象に各機能を繰り返すプログラムである。
【発明の効果】
【００１６】
本発明によれば、低負荷であると推測されるサーバを一時的に切り離すことにより、高い信頼性で、縮退可能サーバを検出することが可能なサーバ検出システム及びプログラムを実現することができる。
【発明を実施するための最良の形態】
【００１７】
以下に、本発明を実施するための最良の形態について図面を参照しながら説明する。
【００１８】
（第１の実施の形態）
図１は、本発明の第１の実施の形態に係るサーバ検出システムが適用される負荷分散クラスタシステムの構成例を示す機能ブロック図である。このブロック図では、一例として、単一のアプリケーションａにより処理がなされる場合を示している。
【００１９】
すなわち、本実施の形態に係るサーバ検出システムは、図１に示すように、複数のサーバ（以下、「ノード」とも称する）１０（＃１，＃２，・・・，＃ｎ）と、これら複数のノード１０（＃１，＃２，・・・，＃ｎ）において同時並列して動作するアプリケーションａによる処理負荷を分散させるように各ノード１０（＃１，＃２，・・・，＃ｎ）を制御するロードバランサ１２とを備えた負荷分散クラスタシステム１４に適用され、複数のノード１０（＃１，＃２，・・・，＃ｎ）のうち、アプリケーションａによる処理を停止させることが可能なノード（縮退可能サーバ）を検出するサーバ検出システムであり、図１におけるノード１０（＃Ａ）に備えられる。各ノード１０（＃１，＃２，・・・，＃ｎ）の負荷制御及び負荷情報の取得を行うロードバランサ１２及びノード１０（＃Ａ）は、通信ネットワーク１６に接続されている。この通信ネットワーク１６は、イーサネット（登録商標）等のＬＡＮ、あるいは公衆回線や専用回線を介して複数のＬＡＮが接続されるＷＡＮ等からなる。ＬＡＮの場合には、必要に応じてルータを介した多数のサブネットから構成される。また、ＷＡＮの場合には、公衆回線に接続するためのファイアウォール等を適宜備えているが、ここではその図示及び詳細説明を省略する。
【００２０】
この負荷分散クラスタシステム１４では、負荷が低下した場合、サーバ検出システムによって、ノード１０（＃１，＃２，・・・，＃ｎ）のうちの何れかが停止される。
【００２１】
これを実現するために、各ノード１０（＃１，＃２，・・・，＃ｎ）及びノード１０（＃Ａ）は、それぞれ図２及び図３に示すような構成をしている。
【００２２】
まず図２に示すように、各ノード１０（＃１，＃２，・・・，＃ｎ）はそれぞれ、サービス制御部２２を実行させるクラスタデーモン２０と、クラスタデーモン２０による制御の下、サービス制御を行うサービス制御部２２とから構成している。サービスの制御対象としては、例えば、監視対象のアプリケーションａと、そのアプリケーションａで使用するＩＰアドレス（仮想ＩＰアドレス）ｂがある。
【００２３】
一方、図３に示すように、ノード１０（＃Ａ）は、クラスタデーモン３０と、負荷情報取得部３２と、負荷情報分析部３４と、縮退可能サーバ分析部３６とから構成している。
【００２４】
クラスタデーモン３０は、負荷情報取得部３２及び負荷情報分析部３４を実行させる。
【００２５】
負荷情報取得部３２は、クラスタデーモン３０によって実行され、対象とするアプリケーションａの負荷情報をロードバランサ１２を介して取得し、負荷情報分析部３４に通知する。負荷情報の取得は、ロードバランサ１２が収集した各ノード１０（＃１，＃２，・・・，＃ｎ）の負荷情報を取得する他に、各ノード１０（＃１，＃２，・・・，＃ｎ）のアプリケーションａから直接取得するようにしても良い。
【００２６】
負荷情報分析部３４は、クラスタデーモン３０によって実行され、負荷情報取得部３２からノード１０（＃１，＃２，・・・，＃ｎ）毎の負荷情報を受け取り、負荷情報からノード１０（＃１，＃２，・・・，＃ｎ）全体の負荷状態を分析する。そして、ノード１０（＃１，＃２，・・・，＃ｎ）全体が高負荷となる閾値（あらかじめユーザが設定しておく）を超えた場合は高負荷であると判断し、負荷分散クラスタシステム１４にサービス実行ノード数の増加リクエストを行う。
【００２７】
一方、ノード全体が低負荷となる閾値（あらかじめユーザが設定しておく）を下回った場合は、各ノード１０（＃１，＃２，・・・，＃ｎ）の負荷情報や他のアプリケーションとの依存関係などから縮退可能サーバと推定されるノードを指定して、縮退可能サーバ分析部３６を呼び出す（通常、ロードバランサ１２によって負荷が分散されているため、各ノード１０（＃１，＃２，・・・，＃ｎ）の負荷はほぼ均一になっていると考えられるが、最も負荷が低いノードを選択するものとする。）。そして、縮退可能サーバ分析部３６の分析結果により、指定したノードが縮退可能ならば、そのノードのサービスを停止させ、縮退不可能ならば、低負荷と判断する閾値が高い可能性あるため、閾値を下げる。
【００２８】
縮退可能サーバ分析部３６は、負荷情報分析部３４から実行され、図４に示すような処理を行い、指定されたノード（以下、例としてノード１０（＃１）として説明する）が縮退可能であるかを分析する。すなわち、図４に示すように、負荷情報分析部３４は、先ず指定されたノード１０（＃１）のＩＰアドレスをダウンさせる（ステップＳ１)。これによって、指定されたノード１０（＃１）を、ロードバランサ１２による制御から切り離す。ただし、このＩＰアドレスは、アプリケーションａ用の仮想ＩＰアドレスであり、負荷分散クラスタシステム１４との通信で使用するＩＰアドレスとは異なるため、負荷分散クラスタシステム１４からは、このノード１０(＃１)にアクセスすることができる。
【００２９】
このように、１台のノード１０（＃１）をロードバランサ１２から切り離すことにより、このノード１０（＃１）で処理されていたクライアントからのリクエストが他のノード１０（＃２，・・・＃ｎ）に分散されるため、切り離し直後はこれらノード１０（＃２，・・・＃ｎ）による負荷変動が大きくなる。そのため、縮退可能サーバ分析部３６は、他のノード１０（＃２，・・・＃ｎ）で実行しているアプリケーションａの負荷が安定するまでスリープする（ステップＳ２）。どれくらいの時間で負荷が安定するかは、サーバのスペックやアプリケーションの種類によって異なり、一概には言えない。したがって、ここでは、一例として、ユーザがあらかじめ設定しておいた時間スリープするものとする。
【００３０】
次に、ステップＳ２のスリープ後、負荷が安定した段階で、ロードバランサ１２から切り離されたノード１０（＃１）以外のノード１０(＃２，・・・＃ｎ)の処理負荷に基づいて、ノード１０（＃１）によるアプリケーションａの処理を停止することが可能であるかを判定する。この判定基準としては、例えば、高負荷と判定される閾値を予め定めておき、処理負荷が、この閾値を超えていない場合（ステップＳ３：Ｙｅｓ）には縮退可能と判定し（ステップＳ４）、ノード１０（＃１）によるアプリケーションａの処理を停止させる。
【００３１】
一方、閾値を超えた場合（ステップＳ３：Ｎｏ）には、縮退不可能と判定し、ノード１０（＃１）のＩＰアドレスを元に戻し、ノード１０（＃１）を、ロードバランサ１２によって再び制御されるように復帰させる（ステップＳ５）。
【００３２】
このようなサーバ検出システムは、例えば磁気ディスク等の記録媒体に記録されたプログラムや、インターネット等の通信ネットワークを介してダウンロードしたプログラムを読み込み、このプログラムによって動作が制御されるコンピュータによって実現される。
【００３３】
また、このプログラムは、コンピュータに実行させることができるものであって、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハ一ドディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記録媒体に格納し、またインターネット等の通信媒体により伝送して頒布することもできる。
【００３４】
なお、記録媒体に格納されるプログラムは、コンピュータに実行させるソフトウエア手段（実行プログラムのみならずテーブルやデータ構造も含む）をコンピュータ内に構成させる設定プログラムをも含む。
【００３５】
また、このプログラムは、記録媒体から、あるいは通信媒体からコンピュータに読み込まれると、このコンピュータを動作させることによって上述した処理を実行させる。
【００３６】
次に、以上のように構成した本実施の形態に係るサーバ検出システムの動作について図５のフローチャートを用いて説明する。
【００３７】
まず、ノード１０（＃１，＃２，・・・＃ｎ）のうち、予め設定されたノードに対するサービスがクラスタデーモン２０によって開始され、運用状態とされる（ステップＳ１１）。
【００３８】
次に、サーバ検出システムとして動作するノード１０（＃Ａ）において、クラスタデーモン３０によって、負荷情報取得部３２および負荷情報分析部３４が実行される（ステップＳ１２）。
【００３９】
次のステップＳ１３では、負荷情報取得部３２および負荷情報分析部３４において、負荷分散クラスタシステム１４から停止要求を受け取るまで、下記ステップＳ１４〜ステップＳ１９の処理が繰り返される。
【００４０】
そして、ステップＳ１４では、負荷情報取得部３２によって、対象とするアプリケーションａの負荷情報がロードバランサ１２を介して取得され、更に、負荷情報分析部３４に通知される。負荷情報の取得は、ロードバランサ１２が収集した各ノード１０（＃１，＃２，・・・，＃ｎ）の負荷情報を取得する他に、各ノード１０（＃１，＃２，・・・，＃ｎ）のアプリケーションａから直接取得するようにしても良い。また、負荷情報分析部３４では、負荷情報取得部３２からのノード１０（＃１，＃２，・・・，＃ｎ）毎の負荷情報が受け取られ、受け取られた負荷情報からノード１０（＃１，＃２，・・・，＃ｎ）全体の負荷状態が分析される。
【００４１】
そして、ノード１０（＃１，＃２，・・・，＃ｎ）全体が高負荷となる閾値（あらかじめユーザが設定しておく）を超えた場合（ステップＳ１５：高負荷）には高負荷であると判断され、ステップＳ１６の処理に進み、その後、ステップＳ１７において、次の監視時間まで待機し、しかる後にステップＳ１３の処理に戻る。
【００４２】
また、ステップＳ１５において、高負荷でも低負荷でもない状態、つまり負荷が正常な範囲にある場合（ステップＳ１５：正常）には、ステップＳ１７に進み、次の監視時間まで待機し（ステップＳ１７）、しかる後にステップＳ１３の処理に戻る。
【００４３】
一方、ノード１０（＃１，＃２，・・・，＃ｎ）全体が低負荷となる閾値（あらかじめユーザが設定しておく）を下回った場合（ステップＳ１５：低負荷）には、ステップＳ１８の処理に進み、図６に示すような低負荷時における処理が縮退可能サーバ分析部３６によってなされ、その後、ステップＳ１９において、次の監視時間まで待機し、しかる後にステップＳ１３の処理に戻る。
【００４４】
ステップＳ１８では、図６に示すように、先ず、負荷情報分析部３４によって、各ノード１０（＃１，＃２，・・・，＃ｎ）の負荷情報や他のアプリケーションとの依存関係などから縮退可能サーバであると推定されるノードが指定され（通常は、ロードバランサ１２により負荷が分散されているため、各ノードの負荷は均一になっていると考えられるが、例えば、最も負荷が低いノード１０が選択される）（ステップＳ２１）、縮退可能サーバ分析部３６が呼び出される（ステップＳ２２）。
【００４５】
そして、縮退可能サーバ分析部３６によって、指定されたノード（以下、例としてノード１０（＃１）として説明する）のＩＰアドレスがダウンされる（ステップＳ２３)。これによって、指定されたノード１０（＃１）が、ロードバランサ１２による制御から切り離され、サービスを停止させたときと同じ状態になる。ただし、このＩＰアドレスは、アプリケーションａ用の仮想ＩＰアドレスであり、負荷分散クラスタシステム１４との通信で使用するＩＰアドレスとは異なるため、負荷分散クラスタシステム１４からは、このノード１０(＃１)に依然としてアクセスすることができる。
【００４６】
次に、この切り離し後、切り離されたノード１０（＃１）以外のノード１０(＃２，・・・＃ｎ)の処理負荷が安定するまでアプリケーションａによる処理を待機（スリープ）させる（ステップＳ２４）。どれくらいの時間で負荷が安定するかは、サーバのスペックやアプリケーションの種類によって異なり、一概には言えない。したがって、ここでは、一例として、ユーザがあらかじめ設定しておいた時間スリープするものとする。
【００４７】
次に、ステップＳ２４のスリープ後、ロードバランサ１２から切り離されたノード１０（＃１）以外のノード１０(＃２，・・・＃ｎ)の処理負荷に基づいて、ノード１０（＃１）によるアプリケーションａの処理を停止することが可能であるかが判定される。この判定基準としては、例えば、高負荷と判定される閾値を予め定めておき、処理負荷が、この閾値を超えているか否かに基づいて判定される。そして、処理負荷が、閾値を超えていない場合（ステップＳ２５：Ｙｅｓ）には、縮退可能と判定され（ステップＳ２７：Ｙｅｓ）、ノード１０（＃１）によるアプリケーションａのサービスが停止される（ステップＳ２８）。その後ステップＳ１９の処理に戻る。
【００４８】
一方、ステップＳ２５において閾値を超えた場合（ステップＳ２５：Ｎｏ）には、縮退不可能と判定され、ノード１０（＃１）のＩＰアドレスが元に戻され、ノード１０（＃１）が、ロードバランサ１２によって再び制御されるように復帰され（ステップＳ２６）、しかる後にステップＳ２７を介してステップＳ２９に移行する。
【００４９】
低負荷と判定される閾値が高すぎる可能性もあるために、ステップＳ２９では、同じような縮退可能サーバ分析処理を繰り返さないように、低負荷と判定される閾値が下げられた後にステップＳ１９の処理に戻る。
【００５０】
上述したように、本実施の形態に係るサーバ検出システムにおいては、上記のような作用により、サービスを停止させる代わりに、ＩＰアドレスを停止させてノード１０（＃１）を切り離しているため、アプリケーションａに与える影響が少ない。
【００５１】
また、縮退可能なノード１０（＃１）を分析して、低負荷と判定される閾値を動的に変更するために、低負荷と判定される閾値を適切な値に設定することができる。
【００５２】
更に、低負荷であると推定されるノード１０（＃１）を一時的にロードバランサ１２から切り離すことにより縮退可能なノード１０（＃１）を検出しているため、縮退後にアプリケーションａが高負荷になる可能性を低くすることが可能となる。これにより、縮退後に仮に高負荷になった場合であっても、サービスの開始、停止処理による障害の発生を阻止することができる。
【００５３】
更にまた、ＯＳの起動やシャットダウンまでを行う場合であっても、障害発生の確率の上昇と、これによるサービス停止時間の長期化とを回避することも可能となる。
【００５４】
（第２の実施の形態）
図７は、本発明の第２の実施の形態に係るサーバ検出システムが適用される負荷分散クラスタシステムの構成例を示す機能ブロック図である。
【００５５】
すなわち、本実施の形態に係るサーバ検出システムは、複数の異なるアプリケーションを実行するノードが、アプリケーション毎の複数の層状に構成されてなる負荷分散クラスタシステム４０に適用されるものである。図７では、Ｗｅｂサーバ層と、アプリケーションサーバ層と、データベースサーバ層とによる３層構造からなる負荷分散クラスタシステム４０を示しているが、もちろんこれは一例であって、３層構造に限定されるものではない。
【００５６】
図７に示す例では、Ｗｅｂサーバ層にはＷｅｂサーバである複数のノード５０（＃１，＃２，・・・＃ｎ）が存在し、アプリケーションサーバ層にはアプリケーションサーバである複数のノード６０（＃１，＃２，・・・＃ｎ）が存在し、データベースサーバ層にはデータベースサーバである複数のノード７０（＃１，＃２，・・・＃ｎ）がそれぞれ存在する。
【００５７】
各サーバ層に存在するノードにはそれぞれロードバランサ１２（＃１，＃２，＃３）が設けられ、通信ネットワーク１６（＃１，＃２，＃３）を介して互いに、かつノード１０（＃Ａ）と通信可能となっている。
【００５８】
これらノード５０，６０，７０、ロードバランサ１２（＃１，＃２，＃３）、及びノード１０（＃Ａ）の構成についてはそれぞれ、第１の実施の形態で説明したノード１０（＃１，＃２，・・・＃ｎ）が、ロードバランサ１２、及びノード１０（＃Ａ）と同じであるので、重複説明を避ける。また、以下の説明においても、第１の実施の形態と異なる点について説明する。
【００５９】
このような複数の層構造の何れかに属するノードの縮退の可否を判定する場合、本実施の形態に係るサーバ検出システムでは、負荷情報取得部３２が、複数のノード５０，６０，７０（＃１，＃２，・・・＃ｎ）のおのおのについて、各アプリケーションに関する負荷情報を各ロードバランサ１２（＃１，＃２，＃３）を介して取得する。
【００６０】
そして、負荷情報分析部３４は、負荷情報取得部３２から各ノード５０，６０，７０（＃１，＃２，・・・，＃ｎ）毎の負荷情報を受け取り、負荷情報から、サーバ層毎の処理負荷の平均値を求め、平均値が最も低いサーバ層（例えば、Ｗｅｂサーバ層）を決定する。
【００６１】
更に、負荷情報分析部３４は、平均値が最も低いと決定されたサーバ層に含まれるノード（例えば、Ｗｅｂサーバ層に属するノード５０（＃１，＃２，・・・＃ｎ））のうち、負荷情報と、他のアプリケーションとの依存関係とから、処理を停止させることが可能であると推定されるノード（例えば、ノード５０（＃１））を決定する。
【００６２】
その後は、第１の実施の形態と同様に、負荷情報分析部３４が、推定されたノード（以下、例えば、ノード５０（＃１）として説明する）を、ロードバランサ１２（＃１）による制御から切り離す。
【００６３】
縮退可能サーバ分析部３６は、第１の実施の形態と同様に、処理負荷が安定するまでスリープがなされた後に、ノード５０（＃１）による処理の停止が可能であるか、すなわち縮退可能であるかを判定し、停止可能と判定した場合には、ノード５０（＃１）によるアプリケーションの処理を停止させる。一方、停止不可と判定した場合には、縮退不可能と判定し、ノード５０（＃１）のＩＰアドレスを元に戻し、ノード５０（＃１）を、ロードバランサ１２（＃１）によって再び制御されるように復帰させる。
【００６４】
このように、ノード５０（＃１）がロードバランサ１２（＃１）によって制御されるように復帰された場合には、負荷情報分析部３４は、負荷情報取得部３２から受け取った負荷情報に基づいて、サーバ層の処理負荷の平均値が、次に低いサーバ層（例えば、アプリケーションサーバ層）を決定し、このサーバ層を対象として、上述した処理を繰り返すことによって、ノード（例えば、ノード６０（＃１））の縮退の可否を判定する。次に低いサーバ層（例えば、アプリケーションサーバ層）でも縮退可能なノード６０が得られない場合には、サーバ層の処理負荷の平均値が、その次に低いサーバ層（例えば、データベースサーバ層）を決定し、このサーバ層を対象として、上述した処理を繰り返すことによって、ノード（例えば、ノード７０（＃１））の縮退の可否の判定を繰り返す。
【００６５】
次に、以上のように構成した本実施の形態に係るサーバ検出システムの動作について説明する。
【００６６】
本実施の形態に係るサーバ検出システムの全体動作もまた、図５のフローチャートに示す通りであるが、ステップＳ１８における詳細動作は、図６のフローチャートとは一部異なる図８のフローチャートに示す通りとなる。従って、ここでは、図８のフローチャートを用いて、図５におけるステップＳ１８における動作を簡単に説明する。
【００６７】
まず、負荷情報分析部３４において、負荷情報取得部３２から各ノード５０，６０，７０（＃１，＃２，・・・，＃ｎ）毎の負荷情報が受け取られ、システム全体の負荷が、閾値より低くなった場合には、負荷情報から、サーバ層毎の処理負荷の平均値が求められ、平均値が最も低いサーバ層（例えば、Ｗｅｂサーバ層）が決定される（ステップＳ３１）。
【００６８】
更に、縮退可能サーバ分析部３６では、平均値が最も低いと決定されたサーバ層に含まれるノード（例えば、ノード５０（＃１，＃２，・・・＃ｎ））のうち、負荷情報と、他のアプリケーションとの依存関係とから、縮退可能であると推定されるノード（例えば、ノード５０（＃１））が決定され（ステップＳ３２）、縮退可能サーバ分析部３６が呼び出される（ステップＳ３３）。
【００６９】
そして、縮退可能サーバ分析部３６によって、指定されたノード（以下、ノード５０（＃１）として説明する）のＩＰアドレスがダウンされる（ステップＳ３４）。これによって、指定されたノード５０（＃１）が、ロードバランサ１２（＃１）から切り離され、サービスを停止させたときと同じ状態になる。ただし、このＩＰアドレスは、例えばＷｅｂアプリケーションのようなアプリケーション用の仮想ＩＰアドレスであり、負荷分散クラスタシステム４０との通信で使用するＩＰアドレスとは異なるため、負荷分散クラスタシステム４０からは、このノード５０（＃１）に依然としてアクセスすることができる。
【００７０】
このようにして１台のノード５０（＃１）をロードバランサ１２（＃１）から切り離すことにより、このノード５０（＃１）で処理されていたクライアントからのリクエストが他のノード５０（＃２，・・・＃ｎ）に分散されるため、切り離し直後は負荷変動が大きくなる。そのため、縮退可能サーバ分析部３６によって、他のノード５０（＃２，・・・＃ｎ）で実行されているアプリケーションの負荷が安定するまでスリープされる（ステップＳ３５）。
【００７１】
スリープ後、負荷が安定したら、縮退可能サーバ分析部３６によって、負荷情報取得部３２からの負荷情報に基づいて、高負荷となる閾値を超えていないかが確認される（ステップＳ３６）。閾値を超えていない場合（ステップＳ３６：Ｙｅｓ）には、指定されたノード５０（＃１）は、縮退可能（ステップＳ３８：Ｙｅｓ）となり、閾値を超えた場合（ステップＳ３６：Ｎｏ）は、縮退不可能となる。
【００７２】
縮退不可能な場合（ステップＳ３６：Ｎｏ）、縮退可能サーバ分析部３６から負荷分散クラスタシステム４０へリクエストが出され、切り離されたＩＰアドレスが元に戻され（ステップＳ３７）、その後ステップＳ３８（ステップＳ３８：Ｎｏ）を経由してステップＳ４０に移行する。
【００７３】
縮退可能な場合（ステップＳ３８：Ｙｅｓ）、縮退可能サーバ分析部３６の処理結果にしたがって、負荷情報分析部３４によって、ノード５０（＃１）によるサービスが停止させられ、ノード５０（＃１）が縮退される（ステップＳ３９）。
【００７４】
ステップＳ４０では、ステップＳ３２〜ステップＳ３９で行われた処理が未だになされていないサーバ層がある場合（ステップＳ４０：Ｎｏ）には、他のサーバ層（例えば、アプリケーションサーバ層又はデータベースサーバ層）が縮退対象となる可能性があるため、ステップＳ３１の処理と同様にして、次に平均負荷が低いサーバ層（例えば、アプリケーションサーバ層）が負荷情報分析部３４によって決定され（ステップＳ４２）、ステップＳ３２〜ステップＳ４０までの処理が繰り返される。
【００７５】
一方、ステップＳ４０では、ステップＳ３１〜ステップＳ３９の処理が全てのサーバ層に対して行われている場合（ステップＳ４０：Ｙｅｓ）には、低負荷と判定される閾値が高すぎる可能性もあるために、同じような縮退可能サーバ分析処理を繰り返さないように、低負荷と判定される閾値が下げられた後に処理を終了する。
【００７６】
上述したように、本実施の形態に係るサーバ検出システムは、各サーバ層毎に縮退可能サーバを判定するため、第１の実施の形態に係るサーバ検出システムによって奏される作用効果に加えて、更に、複数の異なるアプリケーションが連携して動作する負荷分散クラスタシステム４０に対しても縮退可能なサーバを検出することが可能となる。
【００７７】
以上、本発明を実施するための最良の形態について、添付図面を参照しながら説明したが、本発明はかかる構成に限定されない。特許請求の範囲の発明された技術的思想の範疇において、当業者であれば、各種の変更例及び修正例に想到し得るものであり、それら変更例及び修正例についても本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【００７８】
【図１】第１の実施の形態に係るサーバ検出システムが適用される負荷分散クラスタシステムの構成例を示す機能ブロック図。
【図２】アプリケーションの処理を行うノードの構成例を示す機能ブロック図。
【図３】サーバ検出システムが備えられたノードの構成例を示す機能ブロック図。
【図４】縮退可能サーバ分析部によってなされる処理手順を示すフローチャート。
【図５】第１の実施の形態に係るサーバ検出システムの動作を示すフローチャート。
【図６】第１の実施の形態における縮退可能判定のための処理手順を示すフローチャート。
【図７】第２の実施の形態に係るサーバ検出システムが適用される負荷分散クラスタシステムの構成例を示す機能ブロック図。
【図８】第２の実施の形態における縮退可能判定のための処理手順を示すフローチャート。
【符号の説明】
【００７９】
１０…ノード（サーバ）、１２…ロードバランサ、１４…負荷分散クラスタシステム、１６…通信ネットワーク、２０…クラスタデーモン、２２…サービス制御部、３０…クラスタデーモン、３２…負荷情報取得部、３４…負荷情報分析部、３６…縮退可能サーバ分析部、４０…負荷分散クラスタシステム、５０，６０，７０…ノード（サーバ）
【図１】
2008234356.tif 000003
【図２】
2008234356.tif 000004
【図３】
2008234356.tif 000005
【図４】
2008234356.tif 000006
【図５】
2008234356.tif 000007
【図６】
2008234356.tif 000008
【図７】
2008234356.tif 000009
【図８】
2008234356.tif 000010