JP5557590B2

JP5557590B2 - 負荷分散装置及びシステム

Info

Publication number: JP5557590B2
Application number: JP2010106087A
Authority: JP
Inventors: 真理子中山; 敦也熊谷; 公徳菅内; 邦彦東村
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2010-05-06
Filing date: 2010-05-06
Publication date: 2014-07-23
Anticipated expiration: 2030-05-06
Also published as: US8656406B2; JP2011237844A; US20110276982A1

Description

本発明は、仮想化環境のリクエスト処理システムにおいて、システムへのリクエストを複数の仮想サーバに振り分ける負荷分散装置および方法に関する。

ハードウェアの高性能化により、１台の物理サーバを複数の仮想サーバに論理的に分割するサーバ仮想化技術が注目されている。サーバ仮想化技術では、ＣＰＵ、メモリ、ハードディスク、ネットワーク等の物理サーバの有するリソースの中から、仮想サーバが利用可能なリソースを自由に割り当てることができる。また、割り当てたリソースに対して、複数の仮想サーバでシェアを設定し、リソースを共有することもできる。複数の仮想サーバにシェアを設定した場合、一方の仮想サーバが割り当てられたリソースを使い切った場合でも、シェアが設定された他の仮想サーバが割り当てたリソースを使い切っていなければ、複数の仮想サーバで合算した割当量までリソースを使用することができる。

ＷＥＢシステムでは、スケールアウトの手法を用いてシステムの処理性能を向上させている。スケールアウトとは、同一の処理を行うサーバを複数台並べ、負荷分散装置を用いてリクエストを分散させて処理させることで、システム全体の処理性能を向上させる手法である。

複数のサーバからリクエストを処理させるサーバを決定する負荷分散アルゴリズムには、リーストコネクション（Least Connection）方式やリーストプロセシング（Least Processing）方式等がある。

リーストコネクション方式は、負荷分散装置とサーバ間に確立しているコネクションの数が一番小さいサーバへのリクエストを振り分ける方式である。

リーストプロセシング方式は、サーバにＣＰＵ（Central Processing Unit）使用率を監視するエージェントをインストールし、監視したＣＰＵ使用率が一番低いサーバへリクエストを振り分ける方式である。

特開２００９−０８７２１３号公報（特許文献１）には、ＭＩＰＳ値等の計算機固有の性能値と、計算機のＣＰＵ使用率、ＣＰＵ使用率の閾値から、各計算機の余力を計算し、余力の一番大きな計算機にジョブを割り当てる方式が開示されている。

特開２００９−０８７２１３号公報

リーストコネクション方式を利用して負荷分散した場合、負荷分散装置は、振り分け先のサーバの状態がわからないため、サーバの処理能力を超える数のリクエストをサーバに転送する可能性がある。コネクション数に予め上限を設定することは可能である。しかし、仮想環境において１台の仮想サーバが処理可能な最大リクエスト数は、仮想サーバに割当てられたＣＰＵリソース量や、シェアが設定されている他の仮想サーバのＣＰＵ使用率、また、負荷分散装置とＡＰサーバ間を接続するネットワークの状況に応じて変化する。そのため、変動する最大リクエスト数に追従した上限設定機構が必要となる。

リーストプロセシング方式を利用して負荷分散した場合、仮想サーバ上にインストールしたエージェントが検出できるＣＰＵ使用率は、「仮想サーバの使用率／仮想サーバへ割り当てられたＣＰＵ使用率」となるため、ＣＰＵリソースに一番余裕のある仮想サーバに振り分けられない可能性がある。また、物理サーバのＣＰＵ利用率をもとに振り分けた場合、仮想サーバは設定されている割当率以上のＣＰＵリソースを使用できないため、仮想サーバのＣＰＵリソースに一番余裕のある仮想サーバに振り分けられない可能性がある。

特開２００９−０８７２１３号公報に記載された技術を利用して仮想サーバの余力を計算した場合、ＣＰＵリソースのシェア設定を考慮した場合と、考慮しない場合では計算結果が異なり、複数の仮想サーバグループにＣＰＵリソースのシェアが設定されている場合は、適切な仮想サーバに振り分けられない可能性がある。

また、仮想環境では、物理サーバのネットワークＩＦ（Interface）で受信したイーサフレームを複数の仮想サーバに振り分けるための仮想スイッチが存在する。仮想スイッチは、物理サーバのＣＰＵリソースを利用してソフトウェアで処理されるため、ハードウェアで処理する物理スイッチに比べて転送性能が低い。すなわち、１Ｇ対応のネットワークＩＦを物理サーバに備えた場合でも、１Ｇ以下のパケットレートの通信でパケットロスが発生する。ＴＣＰで通信した場合、セッションを維持しつつ再送が行われるためリクエスト処理時間が長くなる。そのため、仮想サーバが利用可能なＣＰＵリソースが同じ場合でも、処理可能なリクエスト数は少なくなる。

また、仮想スイッチの性能限界を超える入力レートで物理サーバにパケットが入力された場合、仮想スイッチでほぼ１００％のパケットが廃棄され、リクエストが仮想サーバに到達しなくなる。この場合、仮想サーバはリクエストを処理しないためＣＰＵ使用率は低くなる。ＣＰＵリソースを基にリクエストを振り分けた場合、リクエストが到達しない仮想サーバはＣＰＵリソースに余裕があるように見え、この仮想サーバに多くのリクエストが振り分けられるようになる。しかし、実際のリクエストは仮想スイッチで廃棄され、仮想サーバにリクエストは届かない。そのため、この状態の仮想サーバはＣＰＵリソースには余裕があるが、リクエストを外部から振り向けもて、実際には処理することはできない。

そこで本発明は、各仮想サーバと外部とを接続する仮想スイッチのパケットロスによる処理能力低下をも加味した仮想サーバの実質の余剰処理能力に基づいて適切な仮想サーバにリクエストを転送することができ、結果的に、より多くのリクエストをシステム全体で処理可能とする負荷分散装置、および負荷分散方法を提供することを目的とする。

本発明の更なる目的は、複数の仮想サーバ間でＣＰＵリソース割当をシェアする設定に対応して各仮想サーバの余剰処理能力を適正に導出し、適切なリクエスト転送先を選べる負荷分散装置、および方法を提供するにある。

負荷分散装置に、仮想サーバのＣＰＵリソースの割当率、使用率、シェア設定、物理サーバのＣＰＵ使用率、仮想スイッチのパケットロス率を監視する手段を設け、ＣＰＵリソースと仮想スイッチのパケットロス率に応じて、リクエストを転送する仮想サーバを決定する。

負荷分散装置は、仮想スイッチで発生するパケットロスの影響を考慮し、より多くのリクエストを処理できる仮想サーバにリクエストを振り分けることができる。

第１の実施の形態のリクエスト処理システムの構成図である。第１の実施の形態のリクエスト処理システムの論理構成図である。第１の実施の形態の負荷分散装置の構成を示すブロック図である。第１の実施の形態の物理サーバの物理構成を示すブロック図である。第１の実施の形態の物理サーバの論理構成を示すブロック図である。第１の実施の形態のシステム構成管理テーブルの構成例である。第１の実施の形態のリソース監視処理のフローチャートである。第１の実施の形態の中継装置のリソース管理テーブルの構成例である。第１の実施の形態の物理サーバのリソース管理テーブルの構成例である。第１の実施の形態の仮想スイッチの特性管理テーブルの構成例である。第１の実施の形態のパケットロス率推定処理のフローチャートである。第１の実施の形態のパケットロス測定テーブルの構成例である。第１の実施の形態のサーバ選択処理のフローチャートである。第２の実施の形態のリクエスト数変換テーブルの構成例である。第２の実施の形態のサーバ選択処理のフローチャートである。第３の実施の形態のリクエスト数変換テーブルの構成例である。第３の実施の形態のサーバ選択処理のフローチャートである。

（第１の実施の形態）
図１は、本発明の第１の実施の形態のリクエスト処理システムの構成である。第１の実施の形態のリクエスト処理システムは、負荷分散装置１、中継装置２、物理サーバ３〜５、物理サーバ３内の仮想サーバ３１〜３３、物理サーバ４内の仮想サーバ４１〜４３、物理サーバ５内の仮想サーバ５１〜５３、負荷分散装置と中継装置とを接続するネットワーク６を備える。

負荷分散装置１は、ＷＥＢシステムを構成する仮想サーバの中から適切な仮想サーバへリクエストを転送する装置である。中継装置２は、負荷分散装置１と物理サーバを接続するネットワーク６を構成する中継装置の中で、物理サーバ３〜５と直接接続する中継装置である。直接接続することで、中継装置２が物理サーバ３〜５に送信したＩＰパケットやフレームを、物理サーバがすべて受信するとみなすことができる。このような状況が保証できる接続形態であれば、中継装置２と物理サーバ３〜５とをスイッチやルータ等の他の中継装置を介して接続してもよい。
物理サーバ３内には、仮想サーバ３１〜３３が形成され/る。仮想サーバは、物理サーバが備えるＣＰＵ、メモリ、ハードディスク、ネットワーク等のリソースを論理的に分割して使用するサーバである。同様に物理サーバ４には、仮想サーバ４１〜４３が形成され、物理サーバ５には、仮想サーバ５１〜５３が形成される。

図２は、仮想サーバによって構成される論理的なシステム構成である。ＷＥＢシステム７は負荷分散装置１と仮想サーバ３１、３２、４１、４２、５１、から構成される。
仮想サーバ３１、４１、５１は、クライアント端末からのリクエストに応じてアプリケーションソフトウェアを実行し、結果をＨＴＭＬ（Hyper Text Markup Language）文章等にして転送する仮想サーバである。以後、アプリケーションソフトウェアを実行するサーバをＡＰサーバと記す。ＷＥＢシステムの構成において、ＨＴＭＬ文章や画像等の静的なコンテンツのみをクライアント端末からのリクエストに応じて送信するＷＥＢサーバとＡＰサーバを区別する場合もある。しかし、負荷分散装置が行う転送処理は、ＷＥＢサーバとＡＰサーバの違いはなく、同様の処理で、ＷＥＢサーバへの負荷分散も同様の処理で行うことができる。そのため、ここでは、ＷＥＢサーバとＡＰサーバとを総称してＡＰサーバと記す。
仮想サーバ３２、４２は本システムにおいてデータベースの操作、管理等を行う仮想サーバである。以後、データベースの操作、管理を行うサーバをＤＢサーバと記す。

負荷分散装置１は複数のＷＥＢシステムへのリクエストを受信し、適切なＡＰサーバを選択してリクエストを転送する。ＡＰサーバはリクエストを処理し、必要に応じてＤＢサーバへ要求を行い、データベースの操作を行う。仮想サーバ３３、４３、５２、５３はＷＥＢシステム７以外のＷＥＢシステムを構成したり、仮想サーバ単体で処理を行うため、各々の仮想サーバが使用するＣＰＵ、ネットワーク等のリソースは変動する。

図３は、本発明の第１の実施の形態の負荷分散装置１の構成を示すブロック図である。

負荷分散装置１は、ＣＰＵ１１、メモリ１２、インタフェース１３を備える。

ＣＰＵ１１は、ＯＳ（Operating System）及び各種アプリケーションプログラムを実行する。メモリ１２は、ＣＰＵ１１によって実行される各種のアプリケーションプログラムモジュールおよび各種のテーブルを格納する。ＣＰＵ１１とメモリ１２とインタフェース１３とは、バス１４によって接続される。

リソース監視処理モジュール１５は、物理サーバ３〜５のＣＰＵ使用率を取得し、また各物理サーバのＣＰＵについて、個々の仮想サーバ３１〜３３、４１〜４３、５１〜５３のＣＰＵ使用率（分配使用率）を取得してそれら情報を管理する。さらに各物理サーバのＣＰＵについて、個々の仮想サーバのＣＰＵ割当率、および複数仮想サーバ間のシェア設定を保持する。また、中継装置２が備えるインタフェースの入力パケットレート及びビットレートを取得して監視する。つまり、物理サーバ３〜５の個々の入力パケットレート、入力ビットレートを取得して監視する。

パケットロス率推定処理モジュール１６は、負荷分散装置１とＡＰサーバ間で発生するパケットロスを監視してパケットロス率を推定する。

サーバ選択処理モジュール１７は、仮想サーバが利用可能なリソースやパケットロス率の推定状況を基に、リクエストを転送する仮想サーバを決定する。

システム構成管理テーブル１８では、負荷分散装置の管理対象であるＷＥＢシステムのシステム構成が記録管理される。リソース管理テーブル１９は中継装置、物理サーバのＣＰＵなどの計算機リソースごとに設けられ、リソースの割当状況や使用状況を記録管理する。特性管理テーブル２０は各物理サーバに形成される仮想スイッチごと設けられる。これらについては後にそれぞれ図を参照して詳述する。

図４は物理サーバ３の構成を示すブロック図である。物理サーバ３は、ＣＰＵ３４、メモリ３５、ディスク３６、インタフェース３７を備える。

ＣＰＵ３４は、メモリ３５に備えられた仮想化ＯＳ（Operating System）を実行する。仮想化ＯＳ３９は、物理サーバ３のＣＰＵ３４、メモリ３５、ディスク３６、インタフェース３７等の物理リソースを複数の仮想サーバに論理的に分割する。ＣＰＵ３４、メモリ３５、ディスク３６、インタフェース３７はバス３８によって接続される。図５は、物理サーバ３の論理構成を示すブロック図である。物理サーバ３は、仮想化ＯＳ３９によって、仮想サーバ３１〜３３に論理的に分割される。仮想サーバ３１は、仮想ＣＰＵ３１１、仮想メモリ３１２、仮想ディスク３１３、仮想ネットワークインタフェース３１４を仮想的に備える。仮想サーバが仮想的に備える各リソースは、仮想サーバからみると物理的に備えるのと同様に見えるため、単に、仮想サーバのＣＰＵ、メモリ、ディスク、ネットワークインタフェースと称す。
仮想サーバ３２、３３も仮想サーバ３１と同様の構成である。仮想サーバ３３は図５では省略されている。物理サーバ３内の仮想サーバ３１〜３３は、仮想化ＯＳ３９が提供する仮想スイッチ４０によって接続される。仮想サーバ３１〜３３は仮想スイッチ４０を介して通信を行う。また、仮想スイッチ４０を介して、物理サーバ３外部の中継装置２及び他の物理サーバ４、５内の仮想サーバ４１〜４３、５１〜５３と接続する。
物理サーバ４、５の物理構成及び論理構成は、物理サーバ３と同様である。
＜負荷分散装置＞
負荷分散装置１は、負荷分散装置１が構成を管理するＷＥＢシステムへのリクエストを受信し、適切なＡＰサーバへリクエストを転送する装置である。

負荷分散装置１は、初期設定としてシステム構成管理テーブル１８の設定を行う。システム構成管理テーブル１８は、負荷分散装置１がリクエストを転送するＡＰサーバをＷＥＢシステムごとに管理するテーブルである。図６にシステム構成管理テーブル１８の構成例を示す。システム構成管理テーブル１８では、リクエストの転送先となるＡＰサーバ、ＡＰサーバが属する物理サーバ、物理サーバのインタフェースが接続する中継装置及び中継装置のインタフェースが特定可能な情報を含む。図６の例では、ＷＥＢシステム７のＡＰサーバは、仮想サーバ３１、４１、５１であること、各仮想サーバが属する物理サーバは物理サーバ３、４、５であること、各物理サーバが接続されるのはそれぞれ中継装置Ａのインタフェース1/3、1/4、1/5であることが特定可能である。

次に、負荷分散装置１のリソース監視処理モジュール１５について説明する。負荷分散装置１は、定期的またはリクエスト受信時や設定変更時に、リソース監視処理モジュール１５を起動し、ＷＥＢシステムを構成する仮想サーバ、物理サーバ及び中継装置のリソース状況を監視する。
リソース監視処理モジュール１５による処理フローを図７に示す。ステップ７０１では、負荷分散装置１は物理サーバや中継装置等、監視対象となる機器へリソースの状況報告要求を送信する。監視対象機器からの応答がない場合（ステップ７０２でＮｏ）は、応答を受信するまで待機する。監視対象機器からの応答を受信（ステップ７０２でＹｅｓ）の場合は、応答した機器を特定し（ステップ７０３）、該当機器のリソース管理テーブル１９に、取得した情報を設定する（ステップ７０４）。
図８に中継装置のリソース管理テーブルの構成例を示す。リソース監視処理モジュール１５は、中継装置２から、各インタフェースから物理サーバへ出力されるパケットレート及びビットレートを取得し、中継装置のリソース管理テーブルに設定する。パケットレートは、単位時間に出力されるイーサフレームまたはＩＰパケットの数であり、ビットレートは、単位時間に出力されるイーサフレームまたはＩＰパケットの情報量である。
図９に物理サーバのリソース管理テーブルの構成例を示す。リソース監視処理モジュール１５は、物理サーバ３〜５からＣＰＵリソースの状況を取得し、物理サーバのリソース管理テーブルに設定する。物理サーバから取得する情報は、仮想化ＯＳ及び各仮想サーバに割り当てられたＣＰＵリソースの上限値（割当率）、仮想化ＯＳ及び各仮想サーバの使用率、仮想サーバ間のシェア設定の有無である。シェアとは、仮想サーバ間でＣＰＵリソースを共有できる設定であり、シェアを設定する一方の仮想サーバが割当率までＣＰＵリソースを使用した場合でも、他方の仮想サーバがＣＰＵリソースを使用していなければ、合算した割当率までＣＰＵリソースを使用することができる。
図９に示す例では、仮想サーバ３１と３２にはシェアが設定されており、仮想サーバ３１、３２の双方が割当率までＣＰＵリソースを使用した場合は、仮想サーバ３１は５０％、仮想サーバ３２は２５％まで使用できる。また、仮想サーバ３１がＣＰＵリソースを割当率まで使用せず、２５％まで使用している状況において、仮想サーバ３２は、５０％まで使用することができる。このように、仮想環境では、仮想サーバにＣＰＵ割当率を設定した場合でも、シェアを設定した場合は他の仮想サーバの使用率に応じて、使用できるＣＰＵリソースの最大値が異なる。
次に、負荷分散装置１のパケットロス率推定処理モジュール１６による処理について説明する。パケットロス率推定処理モジュール１６は、物理サーバ３〜５の各仮想スイッチ４０で発生するパケットロスの発生率（パケットロス率）をパケットレートなどの観測データから推定するプログラムモジュールである。
仮想スイッチ４０は、仮想化ＯＳ３９によるソフトウェア処理で提供される。そのため、物理サーバへの入力パケットレートが一定の閾値を越えると、スイッチ処理が間に合わず仮想スイッチ４０にパケットロスが発生する。パケットロス発生後は、入力パケットレートと物理サーバのＣＰＵ使用率の増加に伴ってパケットロスが増加する。さらに、仮想スイッチの性能限界を超えるパケットレートで入力された場合は、仮想スイッチで多くのパケットまたはフレームを廃棄し、仮想サーバへパケットまたはフレームが入力されなくなる。この場合、物理サーバのＣＰＵ使用率が低い場合でも、リクエストが仮想サーバへ転送されないため、仮想サーバでリクエストの処理が実行できなくなる。
このような仮想スイッチ４０の性能特性を管理するため、負荷分散装置１は、特性管理テーブル２０を仮想スイッチ毎に備える。図１０に仮想スイッチの特性管理テーブル２０の構成例を示す。特性管理テーブル２０は、仮想スイッチのパケットロス率の特性が変化するパケットレートと、性能特性の変化に対応したパケットロス率の推定方法を示すテーブルである。
パケットロスが発生し始める入力パケットレートをα、仮想スイッチの性能限界となる入力パケットレートをβ、物理サーバへの入力パケットレートをＲ、仮想スイッチでのパケットロス率をＬとすると、物理サーバへの入力パケットレートＲが、パケットロス発生の閾値α以下の場合、パケットロスは発生しないため、以下の式で表せる。
Ｌ＝０（ただし、Ｒ＜α）・・・(数１)
また、物理サーバへの入力パケットレートＲが、パケットロス発生の閾値α以上、仮想スイッチの性能限界以下の場合、パケットロス率は入力パケットレートと物理サーバのＣＰＵ使用率に比例するため、以下の式で表せる。

Ｌ＝Ｌ_Ｒ × Ｃ_Ｃ／Ｃ_Ｒ（ただし、α＜Ｒ＜β）・・・(数２)
ただし、Ｌ_Ｒは入力パケットレートＲの場合に計測したパケットロス率、Ｃ_Ｒは入力パケットレートＲの場合に計測した物理サーバのＣＰＵ使用率、Ｃ_Ｃはリソース管理テーブルから取得した現時点の物理サーバのＣＰＵ使用率である。
Ｌ_Ｒ、Ｃ_Ｒは、仮想スイッチのパケットロス率を推定する基準となる性能特性を予め計測した測定値である。すなわち、物理サーバ上で稼動する仮想サーバやアプリケーションの数等の負荷条件を一定に保った上で、仮想スイッチへの入力パケットレートＲに対する、物理サーバのＣＰＵ使用率Ｃ_Ｒの対応関係、仮想スイッチでのパケットロス率Ｌ_Ｒの対応関係を計測して得られる値である。ただし、本実施の形態では、α＜Ｒ＜βの範囲内の入力パケットレートＲの複数の代表値についてのみＬ_Ｒ、Ｃ_Ｒの値を計測し、図１２に示すパケットロス計測テーブルに予め保存しておく。実際に観測される入力パケットレートＲの値は上記の代表値と必ずしも一致しないので、その場合は、２つ以上のパケットレート代表値に対応する測定値を用いて補完演算により算出したＬ_Ｒ、Ｃ_Ｒの値を得る。このようにして取得したＬ_Ｒ、Ｃ_Ｒの値と、リソース管理テーブルから取得した現時点のＣＰＵ使用率Ｃ_Ｃを用いて（数２）の補正演算を行うことでパケットロス率が推定される。
さらに、物理サーバへの入力パケットレートＲが、仮想スイッチの性能限界β以上の場合、ほぼすべてのパケットが仮想スイッチで廃棄されるため、以下の式で表せる。

Ｌ＝ 1 （ただし、Ｒ＞β）・・・(数３)
パケットロス率推定処理モジュール１６による処理フローを図１１に示す。パケットロス率推定処理モジュール１６が起動すると、負荷分散装置はステップ１１０１で構成管理テーブル１８を参照し、各物理サーバに接続する中継装置及びインタフェースを取得する。また、リソース管理テーブル１９を参照し、中継装置のインタフェースへの入力パケットレートを取得する。次にステップ１１０２では、ステップ１１０１で取得した情報から、各物理サーバへの入力パケットレートを取得する。次に仮想スイッチの特性管理テーブル２０を取得し（ステップ１１０３）、物理サーバへの入力パケットレートに対応するパケットロス率の推定方法を取得する（１１０４）。すなわち、ステップ１１０２で取得した各物理サーバへの入力パケットレートの値をキーにそれぞれ特性管理テーブルを参照して、それぞれの物理サーバに形成された仮想スイッチのパケットロス率の推定法方法を決定する。ステップ１１０５では、ステップ１１０４で取得したパケット率の推定方法に従い、仮想スイッチで発生するパケットロス率を推定する。とくに、仮想スイッチを形成する物理サーバの入力パケットレートＲがα＜Ｒ＜βの範囲であり、ステップ１１０４で（数２）による推定方法が決定された場合は、入力パケットレートＲの値でパケットロス計測テーブルを引いて測定値Ｌ_Ｒ、測定値Ｃ_Ｒを取得する。もしくはパケットロス計測テーブルから取得される複数の測定値Ｌ_Ｒ、Ｃ_Ｒからそれぞれ補間演算により上記入力パケットレートＲの値に対応した測定値Ｌ_Ｒ、Ｃ_Ｒをそれぞれ算出する。得られたＬ_Ｒ、Ｃ_Ｒと、リソース管理テーブル１９を参照して得たＣＰＵ使用率Ｃ_Ｃを(数２)に代入してパケットロス率Ｌを推定する。
次に、負荷分散装置１のサーバ選択処理モジュール１７について説明する。サーバ選択処理モジュール１７は、物理サーバや仮想サーバのリソース状況から、リクエストを転送する仮想サーバを選択するプログラムモジュールである。
図１３に、サーバ選択処理モジュール１７による処理フローを示す。
負荷分散装置１は、クライアント端末からのリクエストを受信する（ステップ１３００）。次に、ステップ１３０１では、リクエストメッセージに含まれる情報又は、ＩＰアドレス等から転送先となるＷＥＢシステムを特定し、ＷＥＢシステムの構成管理テーブル１８を参照してリクエスト転送先の候補となる仮想サーバ、それが属する物理サーバの情報を取得する。例として、ＷＥＢシステム７が特定されたとする。構成管理テーブル１８から、ＷＥＢシステム７の中のＡＰサーバである仮想サーバ３１、４１、５１、これら仮想サーバが属する物理サーバ３、４、５、これら物理サーバが接続する中継装置及びそのインタフェースの情報を取得する（ステップ１３０２）。
ステップ１３０３以降では、リクエスト転送先の候補である各仮想サーバの余剰処理能力を、候補番号ｉ＝１から順に算出する。まず、算出対象の仮想サーバが属する物理サーバのリソース管理テーブルを取得し、さらに中継装置のリソース管理テーブルを取得する（ステップ１３０４）。ステップ１３０５では、前記物理サーバのリソース管理テーブルから、算出対象の仮想サーバのＣＰＵ割当率（Ｃ_Ａ）及び使用率（Ｃ_Ｕ）、およびＣＰＵ使用率の合計（Ｃ_Ｐ）を取得する。ＣＰＵ使用率の合計（Ｃ_Ｐ）は、物理サーバ内の全仮想サーバと仮想化ＯＳのＣＰＵ使用率の合計であり、つまり計算対象の仮想サーバが属する物理サーバのＣＰＵ使用率である。また、中継装置のリソース管理テーブルからは、物理サーバの入力パケットレートの情報を取得する。
次に、算出対象の仮想サーバに他の仮想サーバとシェア（リソース共有）が設定されている場合は（ステップ１３０６でＹｅｓ）、設定されたリソース共有仮想サーバのそれぞれのＣＰＵ割当率（Ｃ_Ａ）及び使用率（Ｃ_Ｕ）を取得する（ステップ１３０７）。
次にパケットロス率推定処理モジュール１６を起動し（ステップ１３０８）、算出対象の仮想サーバが接続する仮想スイッチで発生するパケットロス率を推定する（ステップ１３０９）。

推定されたパケットロス率の値が０％である場合（ステップ１３１０でＹｅｓ）は、はステップ１３１１に進み、当該仮想サーバが利用可能なＣＰＵリソースの値をそのまま余剰処理能力Ｐｉとする。またパケットロス率の値が閾値以上である場合（ステップ１３１２でＹｅｓ）は当該仮想サーバを転送先の選択から除外する(ステップ１３１３)。リクエストパケットが仮想スイッチで廃棄され、ＣＰＵ使用率は低いがリクエストを処理できない仮想サーバが転送先に選ばれるのを防止するためである。パケットロス率の値が上記の閾値未満であれば（ステップ１３１２でＮｏ）、ステップ１３１４に進み、当該仮想サーバが利用可能なＣＰＵリソースの値をパケットロス率で補正して余剰処理能力Ｐｉの値を得る。

ここで、ステップ１３１１、ステップ１３１４のそれぞれにおける仮想サーバの余剰処理能力Ｐｉの算出方法について、例を用いて説明する。

仮想サーバiが利用可能なリソース量をＣ_iは、仮想サーバへのＣＰＵ割当率をＣ_Ａi、と、仮想サーバの実際のＣＰＵ使用率Ｃ_Ｕiとの差であり、以下の（数４）式で表せる。

Ｃ_i ＝Ｃ_Ａi − Ｃ_Ｕi ・・・（数４）
また、仮想サーバiと仮想サーバｊにシェア（リソース共有）が設定されている場合は、仮想サーバiが利用可能なＣＰＵリソース量は、リソース共有仮想サーバｊへのＣＰＵ割当率をＣ_Ａｊ、その実際のＣＰＵ使用率をＣ_Ｕｊとして以下の（数５）式で表せる。
Ｃ_i ＝Ｃ_Ａi＋Ｃ_Ａｊ − （Ｃ_Ｕi＋Ｃ_Ｕｊ）・・・（数５）
図９のように、仮想サーバ３１の割当率は５０％、使用率は２５％とすると、Ｃ_３１＝０．５ − ０．２５＝０．２５（２５％）
であり、仮想サーバ３１が単独で利用可能なＣＰＵリソースは２５％である。さらに、仮想サーバ３１と３２にはシェア設定がされているため、シェアを考慮すると、仮想サーバ３１がさらに利用可能なＣＰＵリソースは、
Ｃ_３１＝０．５＋０．２５ −（０．２５＋０．２）＝０．３（３０％）
となる。ステップ１３１１では、上記のように（数４）もしくは（数５）により算出した利用可能なＣＰＵリソース量Ｃ_iの値をそのまま仮想サーバが現在持っている余剰処理能力Ｐ_iとする
仮想スイッチでパケットロスが発生する場合、パケットロスにより、負荷分散装置１から仮想サーバへリクエストを転送する時間が長くなるため、仮想サーバが利用可能なＣＰＵリソース量が同じ場合でも、仮想サーバで処理可能なリクエスト数及びリクエスト処理時間が異なる。そこで、ステップ１３１４では、上述の仮想サーバが利用可能なＣＰＵリソース量Ｃ_iに、パケットロス率の逆数（パケット生存率）を乗算して、仮想サーバの余剰処理能力Ｐ_ｉとする。すなわち、仮想サーバiに他の仮想サーバとリソース共有が設定されていない場合は、仮想スイッチにおけるパケットロス率をＬとして以下の(数６)式により仮想サーバiの余剰処理能力Ｐ_ｉを算出する。

Ｐ_ｉ＝Ｃ_ｉ ×（１−Ｌ）＝（Ｃ_Ａi−Ｃ_Ｕi）（１−Ｌ）・・・(数６)
ただし、Ｃ_iは仮想サーバiがさらに利用可能なリソース量、仮想サーバへのＣＰＵ割当率をＣ_Ａi、仮想サーバのＣＰＵ使用率Ｃ_Ｕiである。また、仮想サーバiと仮想サーバｊにシェア（リソース共有）が設定されている場合は、仮想サーバiの余剰処理能力Ｐ_ｉは、以下の(数７)式により仮想サーバiの余剰処理能力Ｐ_ｉを算出する。
Ｐ_i ＝Ｃ_i×（１−Ｌ）＝｛Ｃ_Ａi＋Ｃ_Ａｊ −（Ｃ_Ｕi＋Ｃ_Ｕｊ）｝（１−Ｌ）・・・（数７）
例えば、仮想サーバ３１のＣＰＵリソースの割当及び使用率が図９に示す値の場合、仮想サーバ３１が単独でさらに処理可能なＣＰＵリソース量Ｃ_３１＝２５％、シェア設定を考慮した場合は３０％である。仮想スイッチで１％のパケットロスが発生している場合、仮想サーバ３１の余剰処理能力Ｐ３１は以下となる。

Ｐ_３１＝０．２５（１ − ０．０１）＝０．２４８（２４．８％）
ステップ１３１１もしくは１３１４のいずれかで余剰処理能力が算出されるか、もしくはステップ１３１３で転送先の選択からの除外が決定されると、次にステップ１３１６で候補番号iを更新してステップ１３０４にもどり、次の仮想サーバについて余剰処理能力を算出する。この動作は、転送先候補の仮想サーバ全てについての余剰処理算能力の算出完了がステップ１３１５で確認されるまで繰り返えされる。ステップ１３１７では、以上のようにして算出された転送先候補の各仮想サーバの余剰処理能力を比較し、その値が最も大きい仮想サーバをリクエストの転送先に決定する。

以上に示した処理により、リクエストの転送先の決定を行い、リクエスト分配を行うリクエスト処理システムでは、転送先候補となる仮想サーバに他の仮想サーバとのＣＰＵリソースのシェア（リソース共有）が設定されている場合でも、利用可能なＣＰＵリソースが最も多い仮想サーバにリクエストを転送することが可能となる。また、負荷分散装置とＡＰサーバ間のネットワークにパケットロスが発生する場合のパケットロスによる処理能力低下を加味した仮想サーバの実質の余剰処理能力に基づいて転送先を選択するので、最も適切な仮想サーバにリクエストを転送することが可能となる。
（第２の実施の形態）
第１の実施の形態では、リクエスト転送先の候補の各仮想サーバについて、パケットロスによる処理能力低下を加味した指標を得るために、ＣＰＵ割当率と実際のＣＰＵ使用率との差から得る利用可能なＣＰＵリソース量の値にパケットロス率の逆数を乗じるという方法を採用した。第２の実施の形態では、転送先の候補の各仮想サーバについて、ＣＰＵ割当率とパケットロス率のそれぞれ複数の値の組み合わせに対応するリクエスト処理数のデータを予めテーブルに保持し、各仮想サーバの指標をそれぞれテーブルから取得することで上記第１の実施の態様と同等のリクエスト転送先選択を実現する。本実施の態様のリクエスト処理システムの物理構成、主要論理構成は第１の実施の形態と同様である。

図１４は、本実施の態様で各ＡＰサーバ（リクエスト転送先の候補となる仮想サーバ）について予め作成するテーブルであるリクエスト数変換テーブル２１の構成例を示す。リクエスト数変換テーブル２１の横軸は各仮想サーバへのＣＰＵ割当率（Ｃ_Ａ）であり、縦軸は仮想スイッチにおけるパケットロス率（Ｌ）である。テーブルのカラム、ローの各交点にはそれぞれのＣ_Ａ、Ｌの値に対応した仮想サーバのリクエスト処理数（Ｒ_Ｃ）のデータが保持される。このリクエスト処理数Ｒ_Ｃのデータは、計測によって得ても、シミュレーションによって得てもよい。

リクエスト数変換テーブル２１はサーバ選択処理モジュール１７のサーバ選択処理にて参照する。本実施の態様でのサーバ選択処理は、個々の転送先候補の仮想サーバの指標算出のための手順中の仮想スイッチにおけるパケットロス率を取得する処理（ステップ１３０９）までは図１３に示す第１の実施の形態と同様である。ステップ１３０９以降の処理フローは図１５に示すとおりとなる。

仮想スイッチで発生するパケットロス率が閾値を越える場合（ステップ１５０１でＹｅｓ）、閾値以上のパケットロスが発生する仮想スイッチに接続した仮想サーバをリクエストの転送先候補から除外する（ステップ１５０２）。パケットロス率が閾値以下の場合（１５０１でＮｏ）、算出対象の仮想サーバに関するリクエスト数変換テーブル２１を参照する（ステップ１５０３）。ステップ１５０４では図１３のステップ１３０５、で取得した仮想サーバのＣＰＵ割当率（Ｃ_Ａ）とステップ１３０９で取得した仮想スイッチのパケットロス率（Ｌ）から仮想サーバがさらに処理可能なリクエスト数を取得する。具体的には、まず、リクエスト数変換テーブル２１を参照し、ＣＰＵ割当率（Ｃ_Ａ）とパケットロス率（Ｌ）の交点から処理可能なリクエスト数（Ｒ_Ｃ）を取得する。リクエスト数変換テーブル２１で管理するリクエスト数は、仮想サーバのＣＰＵ割当に対応する処理可能なリクエスト数である。そのため、稼働中の仮想サーバがさらに処理可能なリクエスト数（Ｒ_Ｎ）を計算するためには、既に仮想サーバが処理しているリクエスト数（処理中のリクエスト数）を減算する必要がある。そこで、負荷分散装置１と算出対象の仮想サーバとの間の確立済みのコネクション数Ｒ_ＰＮとを用い、（数８）により仮想サーバがさらに処理可能なリクエスト数（Ｒ_Ｎ）を算出する。
Ｒ_Ｎ＝Ｒ_Ｃ − Ｒ_ＰＮ・・・（数８）
負荷分散装置とＡＰサーバとの間の確立済のコネクション数は通常、負荷分散装置で管理している。しかし、これが取得できない場合は、Ｒ_ＰＮに代えて、リクエスト数変換テーブル２１から読み出した処理中のリクエスト数を用い、（数８）の減算を行えばよい。すなわち、仮想サーバのＣＰＵ割当率（Ｃ_Ａ）の値ではなくＣＰＵ使用率（Ｃ_Ｕ）によりカラムを特定し、仮想スイッチにおけるパケットロス率（Ｌ）によりローを特定してリクエスト数変換テーブル２１を参照すれば仮想サーバが処理中のリクエスト数を取得でき、これを（数８）の計算に用いることができる。

ステップ１５０４で仮想サーバのさらに処理可能なリクエスト数の算出が終わると、ステップ１５０６で転送先候補番号ｉを更新し、図１３のステップ１３０５に戻って、次の転送先候補についての処理可能なリクエスト数の算出に進む。その動作は、ステップ１５０５で全ての転送先候補の仮想サーバについて処理可能なリクエスト数の算出が確認されるまで繰り返えされる。その後、ステップ１５０７では、以上のようにして算出された転送先候補の各仮想サーバの処理可能なリクエスト数（Ｒ_Ｎ）を比較し、その値が最も大きい仮想サーバを、リクエストを転送する仮想サーバと決定する。ステップ１５０８ではリクエストを決定した仮想サーバに転送する。

以上により、負荷分散装置１は、リクエスト数変換テーブル２１を用いて仮想サーバがさらに処理可能なリクエスト数を比較し、より多くのリクエストを処理可能な仮想サーバにリクエストを転送することが可能となる。リクエスト数変換テーブル２１は、予め測定した計測値をもとに各仮想サーバが処理可能なリクエスト数に変換できるため、仮想サーバが属する物理サーバの性能が異なる場合でも、適切な仮想サーバを選択することができる。
（第３の実施の形態）
第３の実施の形態では、リクエストを転送する仮想サーバを選択する際に、仮想スイッチのパケットロス率を取得せず、サーバのＣＰＵリソースから直接仮想サーバが処理可能なリクエスト数に変換して、リクエストを転送する仮想サーバを選択する。本実施の態様のリクエスト処理システムの物理構成、主要論理構成は第１の実施の形態と同様である。

仮想スイッチ４０におけるパケットロスは、物理サーバ全体でのＣＰＵ使用率と、物理サーバへの入力パケットレートに依存して発生する。したがって、仮想サーバのＣＰＵ割当率と仮想スイッチのパケットロス率の種々の値に対するリクエスト処理数のデータを保持するテーブルに代え、仮想サーバのＣＰＵ割当率と物理サーバのＣＰＵ使用率の種々の値に対するリクエスト処理数のデータ保持するテーブルを用いても、仮想サーバが処理可能なリクエスト数を取得することができる。図１６は第３の実施の態様で用いるリクエスト数変換テーブル２１ｂの構成を示す。リクエスト数変換テーブル２１ｂは、仮想サーバへのＣＰＵ割当率（Ｃ_Ａ）及び、仮想サーバが属する物理サーバのＣＰＵ使用率（Ｃ_Ｐ）に対応した仮想サーバのリクエスト処理数（Ｒ_Ｃ）を示すテーブルである。負荷分散装置１は、ＷＥＢシステムを構成するＡＰサーバごとに、つまりリクエストの転送先候補となる仮想サーバごとに本テーブルを備える。

また、本実施の形態における特性管理テーブル２０ｂは、仮想スイッチへの入力パケットレートと、入力パケットレートに対応して仮想スイッチで発生する現象を管理する。特に、仮想スイッチでパケットロスが発生し始める入力パケットレートαと仮想スイッチパケットロスが仮想サーバへの転送を停止する仮想スイッチの性能限界となる入力パケットレートβを管理する。

第３の実施の形態におけるサーバ選択処理モジュール１７のサーバ選択処理について以下に説明をする。このサーバ選択処理のフローは、個々の転送先候補の仮想サーバの指標算出のための手順中の、リソース共有仮想サーバのＣＰＵ割当率、使用率を取得する処理（ステップ１３０７）までは、図１３に示す第1の実施の形態のサーバ選択処理と同様である。ただし、ステップ１３０５では、算出対象の仮想サーバのＣＰＵ割当率、使用率、物理サーバの入力パケットレートに加えて、物理サーバのＣＰＵ使用率も取得する。ステップ１３０７より後の処理フローは本実施例に特有であり、図１７に示すとおりとなる。

ステップ１７０１では特性管理テーブル２０ｂを取得する（ステップ１７０１）。物理サーバへの入力パケットレートが仮想スイッチの性能限界βを超える（ステップ１７０２でＹｅｓ）場合は、仮想スイッチに接続する仮想サーバをリクエスト転送先候補から除外する（ステップ１７０３）。

物理サーバへの入力パケットレートが、仮想スイッチでパケットロスが発生する閾値αを超える場合（ステップ１７０４でＹｅｓ）は、リクエスト数変換テーブル２１ｂを参照し、仮想サーバのＣＰＵ割当率及び使用率、仮想サーバが属する物理サーバの合計ＣＰＵ使用率から仮想サーバが処理可能なリクエスト処理数を取得する（ステップ１７０５）。具体的には、まず、リクエスト数変換テーブル２１ｂ、仮想サーバのＣＰＵ割当率（Ｃ_Ａ）の値、物理サーバのＣＰＵ使用率（Ｃ_Ｐ）の値でカラムとローをそれぞれ特定してリクエスト数変換テーブル２１ｂを参照し、仮想サーバが処理可能なリクエスト数（Ｒ_Ｃ）を取得する。リクエスト数変換テーブル２１ｂで管理するリクエスト数は、第２の実施の態様のテーブル２１と同じく、仮想サーバのＣＰＵ割当に対応する処理可能なリクエスト数である。そこで、次に（数８）の減算をおこなって、稼働中の仮想サーバがさらに処理可能なリクエスト数（Ｒ_Ｎ）を算出する。

Ｒ_Ｎ＝Ｒ_Ｃ − Ｒ_ＰＮ・・・（数８）
Ｒ_ＰＮは負荷分散装置と算出対象の仮想サーバとの間の確立済のコネクション数である。確立済のコネクション数が取得できない場合は、仮想サーバのＣＰＵ使用率（Ｃ_Ｕ）と物理サーバのＣＰＵ使用率（Ｃ_Ｐ）からリクエスト数変換テーブル２１ｂを参照し、仮想サーバが処理中のリクエスト数を取得し、Ｒ_ＰＮに代えて（数８）の減算に使用する。
物理サーバへの入力パケットレートが、仮想スイッチでパケットロスが発生する閾値αを超えない場合（ステップ１７０４でＮｏ）は、リクエスト数変換テーブル２１ｂを参照し、仮想サーバのＣＰＵ割当率及び使用率から仮想サーバが処理可能なリクエスト処理数を取得する（ステップ１７０６）。

ステップ１７０６での処理を具体的に説明する。物理サーバへの入力パケットレートが、仮想スイッチでパケットロスが発生する閾値αを超えない場合は、仮想スイッチで発生するパケットロスの影響を考慮する必要がない。すなわち、物理サーバのＣＰＵ使用率を考慮する必要がない。そこで、仮想サーバのＣＰＵ割当率（Ｃ_Ａ）のみから、それに対応する処理可能なリクエスト数（Ｒ_Ｃ）を取得する。この場合、算出対象の仮想サーバのみが物理サーバのＣＰＵリソースを使用するとみなし、物理サーバのＣＰＵ使用率（Ｃ_Ｐ）＝仮想サーバのＣＰＵ割当率（Ｃ_Ａ）とする。つまり、カラム、ローともに（Ｃ_Ａ）の値で特定してリクエスト数変換テーブル２１ｂを参照し、仮想サーバが処理可能なリクエスト数（Ｒ_Ｃ）を取得する。次に、ステップ１７０５と同様に、負荷分散装置と算出対象の仮想サーバとの間の確立済のコネクション数Ｒ_ＰＮを取得し、（数８）の演算で、仮想サーバがさらに処理可能なリクエスト数（Ｒ_Ｎ）を取得する。負荷分散装置と算出対象の仮想サーバとの間の確立済のコネクション数Ｒ_ＰＮを取得できない場合は、カラム、ローともに仮想サーバのＣＰＵ使用率（Ｃ_Ａ）の値で特定してリクエスト数変換テーブル２１ｂを参照して処理中のリクエスト数を取得し、（数８）の演算に用いるという構成としてもよい。
以上に述べた、算出対象の仮想サーバがさらに処理可能なリクエスト数を算出する処理は、ステップ１７０９で全ての転送先候補についての算出が終わったことを確認するまで繰り返される。ステップ１７０８は繰り返しループ中で、候補番号ｉを更新するステップである。全ての転送先候補について、さらに処理可能なリクエスト数（Ｒ_Ｎ）の算出が終わったら、処理可能なリクエスト数（Ｒ_Ｎ）が一番多い仮想サーバを、リクエストを転送する仮想サーバとして選択し（ステップ１７０９）、リクエストを仮想サーバに転送する（ステップ１７１０）。
以上により、負荷分散装置１は、リクエスト数変換テーブル２１ｂを用いて、仮想スイッチのパケットロス率の推定をせず、仮想サーバ及び物理サーバのＣＰＵリソースから直接仮想サーバが処理可能なリクエスト数を比較し、より多くのリクエストを処理可能な仮想サーバにリクエストを転送することが可能となる。仮想スイッチのパケットロス率を推定する必要がないため、パケットロス率を推定する場合に比べ、負荷分散装置での処理量を削減することができる。また、仮想スイッチにおけるパケットロス率を推定する手段を備えない場合でも、負荷分散装置とＡＰサーバ間のパケットロスの影響を考慮し、より多くのリクエストを処理可能な仮想サーバを選択することができる。

１負荷分散装置
２中継装置
物理サーバ
６ネットワーク
７ＷＥＢシステム
１１、３４ＣＰＵ
１２、３５メモリ
１３、３７インタフェース
１４、３８バス
１５リソース監視モジュール
１６パケットロス率推定モジュール
１７サーバ選択モジュール
１８構成管理テーブル
１９リソース管理テーブル
２０、２０ｂ特性管理テーブル
２１、２１ｂリクエスト数変換テーブル
３１、３２、３３、４１、４２、４３、５１、５２、５３仮想サーバ
３６ディスク
３１１、３２１仮想ＣＰＵ
３１２、３２２仮想メモリ
３１３、３２３仮想ディスク
３１４、３２４仮想インタフェース
４０仮想スイッチ

Claims

装備された仮想化ＯＳによって複数の仮想サーバが稼働する１または複数の物理サーバに対して配備され、管理下の複数の仮想サーバにリクエストを分配する負荷分散装置において、
前記物理サーバの各々について、各仮想サーバのＣＰＵ使用率及び物理サーバのＣＰＵ使用率を監視するリソース監視処理部と、
前記複数の仮想サーバの各々に関して、当該仮想サーバに設定されたＣＰＵ割当率と、当該仮想サーバとリソースを共有する他の仮想サーバの指定とを少なくとも保持するリソース管理テーブルと、
転送すべきリクエストがあった場合に、該リクエストの転送先候補の仮想サーバの各々について、当該仮想サーバ及び当該仮想サーバとリソースを共用すると指定されたリソース共用仮想サーバのＣＰＵ使用率の合計と、当該仮想サーバ及び前記リソース共用仮想サーバに設定されたＣＰＵ割当率の合計とを基に、当該仮想サーバが利用可能なＣＰＵリソース量を算出し、各転送先候補の仮想サーバについて算出した利用可能なＣＰＵリソース量に基づいて、リクエストを転送する仮想サーバを選択するサーバ選択処理部と、
各物理サーバに形成され、前記物理サーバ内の各仮想サーバと外部とを接続する仮想スイッチのパケットロス率を推定するパケットロス率推定処理部を有し、
前記サーバ選択処理部は、前記パケットロス率推定処理部で推定されたパケットロス率に対応して、仮想サーバの選択方法を変更する機能を備えることを特徴とする負荷分散装置。
装備された仮想化ＯＳによって複数の仮想サーバが稼働する１または複数の物理サーバに対して配備され、管理下の複数の仮想サーバにリクエストを分配する負荷分散装置において、
前記物理サーバの各々について、各仮想サーバのＣＰＵ使用率及び物理サーバのＣＰＵ使用率を監視するリソース監視処理部と、
前記複数の仮想サーバの各々に関して、当該仮想サーバに設定されたＣＰＵ割当率と、当該仮想サーバとリソースを共有する他の仮想サーバの指定とを少なくとも保持するリソース管理テーブルと、
転送すべきリクエストがあった場合に、該リクエストの転送先候補の仮想サーバの各々について、当該仮想サーバ及び当該仮想サーバとリソースを共用すると指定されたリソース共用仮想サーバのＣＰＵ使用率の合計と、当該仮想サーバ及び前記リソース共用仮想サーバに設定されたＣＰＵ割当率の合計とを基に、当該仮想サーバが利用可能なＣＰＵリソース量を算出し、各転送先候補の仮想サーバについて算出した利用可能なＣＰＵリソース量に基づいて、リクエストを転送する仮想サーバを選択するサーバ選択処理部と、
各物理サーバに形成され、前記物理サーバ内の各仮想サーバと外部とを接続する仮想スイッチのパケットロス率を推定するパケットロス率推定処理部を有し、
前記サーバ選択処理部は、各転送先候補の仮想サーバについて算出した前記利用可能なＣＰＵリソース量に、該仮想サーバに接続する仮想スイッチについて推定されたパケットロス率の逆数をそれぞれ乗算することで、各転送先候補の仮想サーバの処理能力を算出し、算出した処理能力に基づきクエストを転送する仮想サーバを選択することを特徴とする負荷分散装置。
請求項１または２のいずれかに記載の負荷分散装置において、
前記パケットロス率推定処理部は、前記物理サーバのＣＰＵ使用率と、前記物理サーバへの入力パケットレートに基づいて、パケットロス率を計算することを特徴とする負荷分散装置。
請求項１または２のいずれかに記載の負荷分散装置において、
前記パケットロス率推定処理部は、前記物理サーバへの入力パケットレートと、前記物理サーバのＣＰＵ使用率と、前記仮想スイッチで発生するパケットロス率との対応関係を保持し、前記対応関係に基づいて、前記仮想スイッチのパケットロス率を計算することを特徴とする負荷分散装置。
請求項１または２のいずれかに記載の負荷分散装置において、
前記パケットロス率推定処理部は、前記物理サーバへの入力パケットレートと、前記物理サーバのＣＰＵ使用率と、前記仮想スイッチで発生するパケットロス率との対応関係を保持し、前記対応関係から取得したパケットロス率に、前記物理サーバの現在のＣＰＵ使用率に応じた補正値を乗ずることにより、前記仮想スイッチのパケットロス率を計算することを特徴とする負荷分散装置。
請求項１または２のいずれかに記載の負荷分散装置において、
前記サーバ選択処理部は、前記仮想サーバのＣＰＵ割当率と、前記パケットロス率推定処理部で算出した前記仮想スイッチのパケットロス率から前記仮想サーバが処理可能なリクエスト数を計算し、リクエストの転送先候補の各仮想サーバについて計算した処理可能なリクエスト数を比較してリクエストを転送する仮想サーバを選択することを特徴とする負荷分散装置。
装備された仮想化ＯＳによって複数の仮想サーバが稼働する１または複数の物理サーバに対して配備され、管理下の複数の仮想サーバにリクエストを分配する負荷分散装置において、
前記物理サーバの各々について、各仮想サーバのＣＰＵ使用率及び物理サーバのＣＰＵ使用率を監視するリソース監視処理部と、
前記複数の仮想サーバの各々に関して、当該仮想サーバに設定されたＣＰＵ割当率と、当該仮想サーバとリソースを共有する他の仮想サーバの指定とを少なくとも保持するリソース管理テーブルと、
転送すべきリクエストがあった場合に、該リクエストの転送先候補の仮想サーバの各々について、当該仮想サーバ及び当該仮想サーバとリソースを共用すると指定されたリソース共用仮想サーバのＣＰＵ使用率の合計と、当該仮想サーバ及び前記リソース共用仮想サーバに設定されたＣＰＵ割当率の合計とを基に、当該仮想サーバが利用可能なＣＰＵリソース量を算出し、各転送先候補の仮想サーバについて算出した利用可能なＣＰＵリソース量に基づいて、リクエストを転送する仮想サーバを選択するサーバ選択処理部を有し、
前記サーバ選択処理部は、前記仮想サーバのＣＰＵ割当率と、前記物理サーバのＣＰＵ使用率から前記仮想サーバが処理可能なリクエスト数を計算し、リクエストの転送先候補の各仮想サーバについて計算した処理可能なリクエスト数を比較してリクエストを転送する仮想サーバを選択することを特徴とする負荷分散装置。