(57)【特許請求の範囲】
【請求項１】
複数の仮想ホストに処理要求を分散させて振り分ける負荷分散装置において、
前記仮想ホストと該仮想ホストがそれぞれ稼働する物理ホストとを対応付け、処理要求の振り分けに失敗した仮想ホストの統計情報を、該仮想ホストに対応付けた物理ホスト毎に収集して管理する統計情報管理部と、
前記振り分けに失敗した仮想ホストの統計情報が所定の閾値より大きい物理ホスト上で稼働する仮想ホストを、処理要求の振り分け先として閉塞する閉塞管理部と、
を備えたことを特徴とする負荷分散装置。
【請求項２】
前記処理要求に対する仮想ホストからのエラー応答又は応答待ちタイマの満了の発生毎に失敗回数を仮想ホスト毎に累算し、該累算した値が所定の閾値を超えた仮想ホストに対して、処理要求の振り分けに失敗した仮想ホストであることを示す失敗検出フラグを設定し、該失敗検出フラグの設定状況を前記統計情報管理部に通知する負荷分散制御部を備えたことを特徴とする請求項１に記載の負荷分散装置。
【請求項３】
前記閉塞管理部は、同一の物理ホストに対応付けられた仮想ホスト数に対し、前記失敗検出フラグが設定された仮想ホスト数の割合が所定の閾値より大きい物理ホストに対して、該物理ホスト上で稼働する仮想ホストを前記振り分け先として閉塞することを特徴とする請求項２に記載の負荷分散装置。
【請求項４】
前記振り分けに失敗した仮想ホストの統計情報が所定の閾値より大きい物理ホスト上で稼働する仮想ホストに対して、復旧確認要求を示す信号を送信し、該復旧確認要求に対して正常応答を示す信号を受信したとき、該仮想ホストの障害が復旧したと判定し、同一の物理ホストに対応付けられた仮想ホスト数に対し、前記障害が復旧したと判定した仮想ホスト数の割合が所定の閾値より大きい物理ホストに対して、該物理ホスト上で稼働する仮想ホストを障害復旧済みとして設定する復旧確認監視部を備え、
前記閉塞管理部は、前記障害復旧済みとして設定された仮想ホストに対して、前記処理要求の有効な振り分け先として設定することを特徴とする請求項１乃至３の何れかに記載の負荷分散装置。
【請求項５】
複数の仮想ホストに処理要求を分散させて振り分ける負荷分散制御方法において、
前記仮想ホストと該仮想ホストがそれぞれ稼働する物理ホストとを対応付け、処理要求の振り分けに失敗した仮想ホストの統計情報を、該仮想ホストに対応付けた物理ホスト毎に収集して管理するステップと、
前記振り分けに失敗した仮想ホストの統計情報が所定の閾値より大きい物理ホスト上で稼働する仮想ホストを、処理要求の振り分け先として閉塞するステップと、
を含むことを特徴とする負荷分散制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、負荷分散装置及び負荷分散制御方法に関する。本発明は、例えば、仮想ホスト等による処理システムにおいて、処理要求を分散させて振り分ける負荷分散装置及び負荷分散制御方法に適用することができる。
【背景技術】
【０００２】
図９は負荷分散処理を行う処理システムの構成例を示す。負荷分散処理を行う処理システムは、図９に示すように、負荷分散装置１０、処理の分散振り分け先のリアルサーバとなる複数の物理ホスト２１，２２，２３及び複数の端末３１，３２，３ｎを有する。これらは、ネットワーク４０を介して相互に接続される。
【０００３】
各物理ホスト２１，２２，２３は、仮想化実行環境を有し、それぞれ複数の仮想ホストが稼動する。例えば、第１の物理ホスト２１は、仮想ホスト２１−１，２１−２，２１−３の仮想ホスト群が稼動し、第２の物理ホスト２２は、仮想ホスト２２−１，２２−２，２２−３の仮想ホスト群が稼動し、第３の物理ホスト２３は、仮想ホスト２３−１，２３−２，２３−３の仮想ホスト群が稼動する。
【０００４】
負荷分散装置１０は、仮想サーバとしての複数の負荷分散グループ＃１，＃２，＃３を有し、端末３１〜３ｎから処理要求（サーバへのアクセス要求等）を受け付けると、複数の仮想ホスト２１−１〜２３−３の何れかに該処理要求を振り分ける。該処理要求が振り分けられた仮想ホスト２１−１〜２３−３の何れかは、端末３１〜３ｎから要求された処理を実行する。なお、図９に示した負荷分散の処理システムは、Ｗｅｂサーバやアプリケーションサーバ等のほか、その他の負荷分散環境で利用されるサーバシステムに適用される。
【０００５】
ユーザトラフィックが少ない低負荷時のサーバリソースの利用効率化の要求の高まり、及び運用管理技術の向上等により、サーバ仮想化環境の処理システムが普及するものと予想される。また、サーバＣＰＵのマルチコア化及びサーバ仮想化技術の向上等により、物理ホスト上で稼動する仮想ホストの数がますます増えていくものと予想される。
【０００６】
また、ユーザトラフィックは、利用時期や利用時間帯により増減の幅が大きく、ユーザトラフィックの増減により、仮想ホストの増減や配置換えがダイナミックに行われ、物理ホストと仮想ホストとの対応付けの管理は、今後ますます複雑になっていくものと予想される。
【０００７】
ウェブサーバとアプリケーションサーバとが接続されるウェブシステムにおいて、各サーバの負荷状況に基づいてサービス構成を動的に変更する動的構成制御装置及び動的構成制御方法等について、例えば下記の特許文献１等に記載されている。また、負荷分散装置によって端末からの要求を複数のアプリケーションサーバに均等に振り分ける構成については、例えば下記の特許文献２等に記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００３−２８１００７号公報
【特許文献２】特開２００７−１９９８２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
仮想化環境における負荷分散装置では、サーバへの処理要求を、物理ホストではなく仮想ホストを分散処理の振り分け先ホストとして振り分ける。負荷分散装置では、物理ホストと仮想ホストとの対応関係を特に管理しないのが一般である。しかしながら、実際には仮想ホストは物理ホスト上で稼動しているため、物理ホストがハードウェア障害等で機能停止状態となると、該物理ホスト上で稼働する仮想ホストへの処理要求の振り分け動作は、無駄な動作となる。
【００１０】
負荷分散装置は、仮想ホストへの処理要求の振り分けを行った後、該振り分けを行った処理要求に対する無応答を検出することによってしか、振り分け先の仮想ホストの障害を検出することができない。そのため、物理ホストが故障している可能性が高い場合、該物理ホスト上で稼働する仮想ホストへの振り分けが失敗となる可能性が高いにも拘らず、無効な処理要求の振り分けを行ってしまう場合がある。
【００１１】
振り分け先の仮想ホストの障害を検出する方法として、障害検出用の専用モジュールを振り分け先の仮想ホストにインストールし、負荷分散装置と独自連携することで振り分け先の仮想ホストの障害を検出する方法も考えられるが、この場合、振り分け先のホストで利用されるハードウェア、オペレーティングシステム（ＯＳ）、ソフトウェア、又は仮想化実行環境の特定技術に依存してしまうため、種々のホストを対象として汎用的に利用できないという課題がある。
【００１２】
処理要求の振り分け失敗時には、振り分け先の仮想ホストからの応答待ちの処理遅延や振り分けのリトライ動作等が発生するため、処理要求の振り分けの失敗は、アクセスレスポンスの遅延をもたらす等、サービス利用者への影響が発生する。また、振り分け先の仮想ホストからの応答待ちの処理遅延や振り分けのリトライ動作等は、それ自体で負荷分散装置の処理負荷の増大に繋がる。本発明は、処理要求の振り分けに失敗する可能性が高い無駄な振り分け動作を減らし、負荷分散処理の効率化を図ることを目的とする。
【課題を解決するための手段】
【００１３】
上記課題を解決する一形態としての負荷分散装置は、複数の仮想ホストに処理要求を分散させて振り分ける負荷分散装置において、前記仮想ホストと該仮想ホストがそれぞれ稼働する物理ホストとを対応付け、処理要求の振り分けに失敗した仮想ホストの統計情報を、該仮想ホストに対応付けた物理ホスト毎に収集して管理する統計情報管理部と、前記振り分けに失敗した仮想ホストの統計情報が所定の閾値より大きい物理ホスト上で稼働する仮想ホストを、処理要求の振り分け先として閉塞する閉塞管理部と、を備えたものである。
【発明の効果】
【００１４】
失敗する可能性が高い無駄な処理要求の振り分け動作を減らすことができ、処理要求の振り分け失敗によるレスポンスの遅延を低減し、端末（利用者）に対するレスポンスの向上を図ることができる。また、レスポンスの遅延や振り分けのリトライ動作に伴う負荷分散装置の処理負荷を軽減することができる。
【図面の簡単な説明】
【００１５】
【図１】開示の負荷分散装置の構成例を示す図である。
【図２】負荷分散ポリシ情報テーブルの構成例を示す図である。
【図３】統計情報テーブルの構成例を示す図である。
【図４】負荷分散制御部による処理要求の振り分けの失敗検出時の処理フロー例を示す図である。
【図５】閉塞管理部による障害時の仮想ホストの閉塞処理のフロー例を示す図である。
【図６】処理要求の振り分けの動作例を示す図である。
【図７】復旧確認監視部による障害復旧と判断する処理フロー例を示す図である。
【図８】閉塞管理部による仮想ホストの閉塞を解除する処理フロー例を示す図である。
【図９】負荷分散処理を行う処理システムの構成例を示す図である。
【発明を実施するための形態】
【００１６】
開示の負荷分散装置は、仮想ホストと該仮想ホストが稼働する物理ホストとの対応関係を管理し、仮想ホストへの処理要求の振り分け失敗の統計情報を収集し、特定の物理ホスト上で稼動する仮想ホストへの振り分け失敗が多い場合に、該特定の物理ホストに障害が発生していると判断する。そして、障害が発生していると判断された物理ホスト上で稼動する仮想ホスト群への処理要求の振り分けを停止し、無効な振り分け動作を回避する。
【００１７】
上述の動作を行うための手段として、物理ホストと仮想ホストとの対応関係を管理し、仮想ホストへの処理要求の振り分け失敗の統計情報を管理する統計情報管理部と、物理ホスト上で稼動する仮想ホストへの処理要求の振り分け失敗の回数が所定の閾値を超えると、該物理ホスト上で稼働する仮想ホスト群を障害閉塞状態に変更する閉塞管理部とを備える。
【００１８】
開示の負荷分散装置の構成例を図１に示す。図１に示すように、負荷分散装置１０は、仮想サーバ受付部１１、負荷分散制御部１２、負荷分散ポリシ情報格納部１３、統計情報格納部１４、閉塞管理部１５、及び復旧確認監視部１６を備える。
【００１９】
仮想サーバ受付部１１は、仮想サーバＩＰアドレスとポート番号とを負荷分散処理システムの外部に公開し、端末３１〜３ｎからの処理要求（アクセス要求等）を受け付ける。負荷分散制御部１２は、負荷分散ポリシ情報格納部１３に格納された負荷分散ポリシ情報テーブルに従って負荷分散の振り分け制御を行う。
【００２０】
閉塞管理部１５は、統計情報格納部１４に格納された統計情報テーブルを参照し、処理要求の振り分け失敗の傾向を分析する。そして、例えば特定の物理ホスト２２上で稼働する例えば仮想ホスト２２−１への振り分け失敗の割合が所定の閾値を越えると、該特定の物理ホスト２２に障害が発生していると判断する。そして、閉塞管理部１５は、該特定の物理ホスト２２上で稼動する仮想ホスト群２２−１〜２２−３への振り分けを閉塞するよう制御する。
【００２１】
復旧確認監視部１６は、閉塞管理部１５で障害と判断され、振り分け先として閉塞された例えば物理ホスト２２上で稼働する仮想ホスト群２２−１〜２２−３の障害の復旧の確認を行う。
【００２２】
図１では、負荷分散装置１０と物理ホスト２１〜２３とがそれぞれ分離した構成例を示しているが、それらは、部分的に又は全体が１つに統合された構成であってもよい。また、負荷分散装置１０内の各機能ブロックを部分的に別のシステムに分離し、又は全体を別のシステムと統合した構成としてもよい。
【００２３】
図２に負荷分散ポリシ情報テーブルの構成例を示す。負荷分散ポリシ情報格納部１３は、図２に示すように、負荷分散グループ毎に、負荷分散グループ名、負荷分散グループＩＤ、及び仮想サーバＩＰアドレス／ポート番号を対応付けて負荷分散ポリシ情報テーブルに格納する。
【００２４】
該負荷分散ポリシ情報テーブルには更に、各負荷分散グループの各仮想ホストについて、仮想ホストＩＰアドレス／ポート番号が格納され、また、各仮想ホストの稼働状態の情報が設定される。ここで、稼働状態の「オンライン」は、該当する仮想ホストが処理要求の振り分け先として有効な状態に設定されていることを表し、「障害閉塞」は、障害発生のため振り分け先として閉塞状態に設定されていることを表している。また、「保守閉塞」は、保守のために振り分け先として閉塞状態に設定されていることを表している。
【００２５】
図３に統計情報テーブルの構成例を示す。統計情報格納部１４は、図３に示すように、物理ホスト毎に物理ホスト名及び物理ホストＩＰアドレスを対応付けて統計情報テーブルを格納する。そして、該統計情報テーブルには更に、各物理ホスト上で稼働する各仮想ホストの仮想ホスト名、仮想ホストＩＰアドレス／ポート番号、振り分けの失敗を示す失敗検出フラグ、及び復旧確認監視状態の情報が設定される。
【００２６】
ここで、失敗検出フラグの「ＯＦＦ」は、振り分けの失敗が検出されていないことを表し、「ＯＮ」は、振り分けの失敗が検出されたことを表している。また、復旧確認監視状態の「復旧済み」は、障害が復旧したことの確認が済んだことを表し、「未確認」は、障害が復旧したことの確認が未だ済んでいないことを表している。
【００２７】
以下、負荷分散制御部１２による処理要求の振り分け失敗検出時の処理と、閉塞管理部１５による障害の物理ホスト上の仮想ホストを閉塞する処理と、復旧確認監視部１６による障害復旧の判断処理と、閉塞管理部１５による障害復旧物理ホスト上の仮想ホストの閉塞解除の処理について説明する。
【００２８】
＜＜負荷分散制御部による振り分け失敗検出時の処理＞＞
図４は、負荷分散制御部１２による処理要求の振り分けの失敗検出時の処理フロー例を示している。負荷分散制御部１２は、仮想ホスト２１−１〜２３−３に対してアクセス要求等の処理要求を分散させて振り分ける。そして、該振り分けた処理要求に対して仮想ホスト２１−１〜２３−３からエラー応答を受信し、又は仮想ホスト２１〜２３に送信した処理要求の応答待ちタイマの満了を検出したとき（４−１）、内部で保持している仮想ホスト毎の失敗回数を１つ加算（インクリメント）する（４−２）。
【００２９】
失敗回数を加算（インクリメント）した結果、該失敗回数が予め定めたリトライ回数閾値以上か否かを判定する（４−３）。該失敗回数が該リトライ回数閾値より少ない場合は、仮想ホストへの処理要求の振り分けのリトライ処理を実施する（４−４）。該失敗回数が該リトライ回数閾値以上の場合は、統計情報テーブルの失敗検出フラグを「ＯＦＦ」から「ＯＮ」に変更し（４−５）、閉塞管理部１５へ失敗検出フラグを変更したことを通知する（４−６）。
【００３０】
続いて、負荷分散ポリシテーブルを参照し、次ぎの振り分け先候補となる仮想ホストを決定し（４−７）、決定した仮想ホストへ処理要求を送信し、該処理要求に対する応答待ちタイマを起動する（４−８）。
【００３１】
＜＜閉塞管理部による仮想ホストの障害閉塞の処理＞＞
図５は、閉塞管理部１５による障害時の仮想ホストの閉塞処理のフロー例を示す。閉塞管理部１５は、負荷分散制御部１２から失敗検出フラグ更新を受信すると（５−１）、各物理ホスト上で稼働する仮想ホスト群毎に、失敗検出フラグＯＮの数の割合を算出し、予め定めた物理ホスト障害判断閾値（例えば５０％）以上か否かを判定する（５−２）。
【００３２】
失敗検出フラグＯＮの数の割合が物理ホスト障害判断閾値以上の場合、当該仮想ホスト群の物理ホストに何らかの障害が発生していると判断し（５−３）、当該物理ホスト上で稼働する仮想ホストに対して、負荷分散ポリシ情報テーブルの稼動状態を「オンライン」から「障害閉塞」に変更する（５−４）。
【００３３】
閉塞管理部１５は、負荷分散ポリシ情報テーブルの稼動状態を「障害閉塞」に変更した後、障害が発生していると判断した物理ホストの復旧確認を実施させるために、復旧確認障害が発生していると判断した物理ホストの復旧監視の要求を、復旧確認監視部１６に通知する（５−５）。
【００３４】
図６に処理要求の振り分けの動作例を示す。図６に示すように、仮想ホスト２２−１と仮想ホスト２２−２に対する処理要求の振分けが失敗（ＮＧ）だったとすると、物理ホスト２２が障害発生中であると判断する。そして、負荷分散ポリシ情報を基に、物理ホスト２２上で稼働する仮想ホスト２２−１〜２２−３の稼動状態を「障害閉塞」に変更する。こうすることにより、仮想ホスト２２−１〜２２−３が負荷分散制御部１２による処理要求の振り分け先の選択対象から外され、振り分け失敗となる可能性が高い仮想ホスト２２−３への振り分け動作が実施されなくなる。
【００３５】
＜＜復旧確認監視部による障害復旧と判断する処理＞＞
図７に復旧確認監視部１６による障害復旧と判断する処理フロー例を示す。復旧確認監視部１６は、閉塞管理部１５から障害と判定した物理ホストの復旧監視要求の通知を受信すると（７−１）、統計情報テーブルの当該物理ホスト上で稼働する各仮想ホストの復旧確認監視状態を「未確認」に変更する（７−２）。
【００３６】
統計情報テーブルの仮想ホストの中から、復旧確認監視状態が「未確認」の仮想ホストを選択し（７−３）、選択した仮想ホストに対して復旧確認要求を示す信号を送信し、該復旧確認要求に対する応答待ちタイマを起動する（７−４）。復旧確認監視の具体的な手段としては、通信プロトコルによる復旧確認監視のほか、Ｐｉｎｇ応答監視、ＴＣＰポート応答監視、ＵＤＰポート応答監視、アプリケーションレベル応答監視（ＨＴＴＰ、ＦＴＰ、ＳＩＰ、ＴＥＬＮＥＴ、ＳＳＬ  等）、ＳＮＭＰ監視等を用いることができる。
【００３７】
復旧確認監視部１６は、仮想ホストから復旧確認要求に対する正常応答が受信されるか判定する（７−５）。正常応答が受信されず、仮想ホストからエラー応答を受信し、又は応答待ちタイマが満了すると（７−６）、一定時間待機した後（７−７）、仮想ホストに対し復旧確認要求の信号を送信し、応答待ちタイマを起動する（７−８）。この動作を、仮想ホストから正常応答を受信するまで繰り返す（７−５）。復旧確認要求の信号を繰り返して送信する際の送信先仮想ホストは、同一の仮想ホストとしても良いが、他の未確認中の仮想ホストに変更しても良い。
【００３８】
仮想ホストから復旧確認要求に対する正常応答を受信すると、該仮想ホストの障害が復旧したと判断し、統計情報テーブルの復旧確認監視状態を「復旧済み」に変更する（７−９）。そして、「復旧済み」に変更した仮想ホストが稼働する物理ホストの仮想ホスト群の中で、復旧確認監視状態が「復旧済み」となっている仮想ホスト数の割合を算出する。「復旧済み」の仮想ホスト数の割合が、予め定めた物理ホスト復旧判断閾値（例えば５０％）以上か否かを判定する（７−１０）。
【００３９】
「復旧済み」の仮想ホスト数の割合が、該物理ホスト復旧判断閾値（例えば５０％）以上の場合は、該当する物理ホストが復旧したと判断し（７−１１）、負荷分散ポリシ情報テーブルの該当する物理ホスト上で稼働する仮想ホストの復旧確認監視状態を「復旧済み」に変更する（７−１２）。復旧確認監視部１６は、その後、閉塞管理部１５へ、復旧したと判断した物理ホストの復旧監視応答を通知する（７−１３）。
【００４０】
一方、前述の処理フロー７−１０の判定において、「復旧済み」の仮想ホスト数の割合が、予め定めた物理ホスト復旧判断閾値（例えば５０％）より少ない場合は、該「復旧済み」の仮想ホスト数の割合が、予め定めた物理ホスト復旧判断閾値（例えば５０％）以上となるまで、処理フロー７−３に戻り、同様の処理を繰り返す。
【００４１】
＜＜閉塞管理部による仮想ホストの閉塞を解除する処理＞＞
図８は、復旧確認監視部１６が復旧したと判断した物理ホストに対して、閉塞管理部１５により該物理ホスト上で稼働する仮想ホストの閉塞を解除し、「オンライン状態」に設定する処理フロー例を示す。
【００４２】
閉塞管理部１５では、復旧確認監視部１６から障害が復旧したと判断した物理ホストの復旧監視応答を受信すると（８−１）、統計情報テーブルを参照して、障害が復旧したと判断した物理ホスト上で稼働する仮想ホストを抽出する（８−２）。そして、抽出した仮想ホストの負荷分散ポリシ情報テーブルにおける稼動状態を「障害閉塞」から「オンライン」に変更する（８−３）。
【００４３】
負荷分散ポリシ情報テーブルの稼動状態を「障害閉塞」から「オンライン」に変更することにより、「オンライン」に変更された仮想ホストが、負荷分散制御部１２による処理要求の振り分け先候補の選択に組み込まれるようになる。また、稼動状態を「障害閉塞」から「オンライン」に変更した仮想ホストであって、統計情報の失敗検出フラグが「ＯＮ」となっているものに対して、該失敗検出フラグを「ＯＦＦ」に設定する（８−４）。
【００４４】
上述の実施形態では、仮想ホスト上に１つのサービスが稼動する形態を示したが、仮想ホスト上で稼動するサービスは１つに限定されることはなく、仮想ＩＰアドレスやポート番号を複数設けることにより、仮想ホスト上に複数のサービスが稼動するシステムに適用することもできる。
【００４５】
また、上述の実施形態では、物理ホストの障害判断閾値や復旧判断閾値として、システム毎に予め一定の値に定めておく形態を示したが、物理ホスト障害が多発している場合は、復旧判断閾値を下げるなど、物理ホスト障害が発生している状況に応じて判断閾値を動的に変更する構成とすることができる。
【００４６】
また、負荷分散トラヒックの増大により、振り分け先のリソースの空きが少なくなった場合は復旧判断閾値を下げ、負荷分散トラヒックが少なく、余裕があるときは、障害判断閾値を下げてより厳密に障害状況を確認するなど、システム全体の稼働状況に応じて障害判断閾値又は復旧判断閾値を動的に変更する構成とすることができる。
【００４７】
上述の負荷分散装置における閉塞制御方式は、処理要求の振り分け先のホストで利用されるハードウェア、オペレーティングシステム（ＯＳ）、ソフトウェア、又は仮想化実行環境の特定技術に依存しないため、種々のホストを対象として汎用的に利用可能である。
【符号の説明】
【００４８】
１０  負荷分散装置
１１  仮想サーバ受付部
１２  負荷分散制御部
１３  負荷分散ポリシ情報格納部
１４  統計情報格納部
１５  閉塞管理部
１６  復旧確認監視部
２１〜２３  物理ホスト
２１−１〜２３−３  仮想ホスト
３１〜３ｎ  端末
４０  ネットワーク
【図１】
0005549374.tif 000002
【図２】
0005549374.tif 000003
【図３】
0005549374.tif 000004
【図４】
0005549374.tif 000005
【図５】
0005549374.tif 000006
【図６】
0005549374.tif 000007
【図７】
0005549374.tif 000008
【図８】
0005549374.tif 000009
【図９】
0005549374.tif 000010