(58)【調査した分野】(Int.Cl.,DB名)
前記CPU使用率取得手段により取得した前記平均CPU使用率が前記CPU使用率上限値より小さい場合、前記負荷分散手段による前記負荷分散処理と、前記特定手段による前記特定処理と、を行うことを特徴とする請求項5に記載の負荷分散装置。
複数のサーバ全体で処理可能な処理量を示す全体性能値と前記複数のサーバそれぞれの性能に応じた重み付け値とに基づいて、前記複数のサーバそれぞれの性能を示す性能値を求める性能値取得ステップと、
クライアントと前記複数のサーバとの間の通信量を示す通信値を測定する測定ステップと、
前記複数のサーバにおける休止サーバと稼働サーバとの組合せのパターンの中で現在設定されているパターンの稼働サーバの性能値の合計である性能閾値と、前記測定した通信値と、を比較し、前記性能閾値が前記通信値よりも小さい場合、その通信値よりも大きい性能閾値のパターンを前記組合せのパターンの中から特定する特定ステップと、
前記現在設定されているパターンを前記特定したパターンに更新して、その更新したパターンの稼働サーバの重み付け値の比率に従って、前記クライアントからのリクエストを前記更新したパターンの稼働サーバに振り分けて負荷分散を行う負荷分散ステップと、を備えたことを特徴とする負荷分散方法。
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかし、特許文献1に記載の重み付けラウンドロビン制御方式では、パケットを各サーバに送信するため、全てのサーバを稼動しておく必要があり、各サーバの消費電力が高くなるという問題があった。
【0006】
そこで、この発明は、上記問題に鑑みてなされたものであって、ネットワークに接続された複数のサーバの省電力化を図ることが可能な負荷分散装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
上記目的を達成するため、この発明の第1の観点に係る負荷分散装置は、
クライアントと複数のサーバとにネットワークを介して接続される負荷分散装置であって、
前記複数のサーバ全体で処理可能な処理量を示す全体性能値を記憶する全体性能値記憶手段と、
前記複数のサーバそれぞれの性能に応じた重み付け値を記憶する重み付け値記憶手段と、
前記全体性能値と前記サーバ毎の重み付け値とに基づいて、各サーバの性能を示す性能値を求める性能値取得手段と、
前記複数のサーバにおける休止サーバと稼働サーバとの組合せのパターン毎に、前記稼働サーバの性能値の合計である性能閾値と該稼働サーバの重み付け値とを記憶するパターン記憶手段と、
前記組合せのパターンのうち、予め設定されたパターンの稼働サーバの重み付け値を、前記パターン記憶手段が記憶しているパターン毎の稼働サーバの重み付け値を参照して特定し、その特定した稼働サーバの重み付け値の比率に従って、前記クライアントからのリクエストを前記予め設定されたパターンの稼働サーバに振り分ける負荷分散処理を行う負荷分散手段と、
前記クライアントと前記複数のサーバとの間の通信量を示す通信値を測定する測定手段と、
現在設定されているパターンの性能閾値を、前記パターン記憶手段が記憶しているパターン毎の性能閾値を参照して特定し、その特定した性能閾値と前記測定手段により測定した通信値とを比較し、前記性能閾値が前記通信値よりも小さい場合、その通信値よりも大きい性能閾値のパターンを前記組合せのパターンの中から特定する特定処理を行う特定手段と、を備え、
前記負荷分散手段は、前記現在設定されているパターンを前記特定手段により特定したパターンに更新することを特徴とする。
【0008】
また、前記特定手段は、前記通信値よりも大きい性能閾値のパターンの中で、最小の性能閾値のパターンを前記組合せのパターンの中から特定することが望ましい。
【0009】
また、前記特定手段は、前記最小の性能閾値のパターンが複数ある場合、休止サーバの台数が多いパターンを前記組合せのパターンの中から特定することが望ましい。
【0010】
また、第1の観点に係る負荷分散装置は、
前記複数のサーバの平均CPU使用率を取得するCPU使用率取得手段と、
前記組合せのパターンのうち少なくとも1つの所定のパターンについて、その所定のパターンと、その所定のパターンの稼働サーバの性能閾値と、その性能閾値における稼働サーバの基準平均CPU使用率と、所定の閾値と、を対応付けて記憶する基準平均CPU使用率記憶手段と、
前記測定手段により測定された通信値が、前記所定のパターンの稼働サーバの性能閾値になった場合、前記CPU使用率取得手段より取得した平均CPU使用率と前記所定のパターンと対応する基準平均CPU使用率との差の絶対値が、前記所定のパターンと対応する所定の閾値以上か否か判断する判断手段と、
該判断手段により、前記差の絶対値が、前記所定の閾値以上であると判断すると、前記差の絶対値の大きさに応じて、前記所定のパターンの稼働サーバの性能閾値を補正する補正手段と、を備えるのが望ましい。
【0011】
また、第1の観点に係る負荷分散装置は、
前記複数のサーバの平均CPU使用率を取得するCPU使用率取得手段と、
前記平均CPU使用率の上限値であるCPU使用率上限値を記憶する上限値記憶手段と、
前記CPU使用率取得手段により取得した前記平均CPU使用率が前記CPU使用率上限値以上の場合、前記現在設定されているパターンの稼働サーバの台数よりも稼働サーバ台数が多いパターンを特定し、その特定したパターンに更新する更新処理を行う更新手段と、を備え、
該更新手段は、前記更新処理を、前記平均CPU使用率が前記CPU使用率上限値よりも小さくなるまで繰り返すことが望ましい。
【0012】
また、前記CPU使用率取得手段により取得した前記平均CPU使用率が前記CPU使用率上限値より小さい場合、前記負荷分散手段による前記負荷分散処理と、前記特定手段による前記特定処理と、を行うことが望ましい。
【0013】
上記目的を達成するため、この発明の第2の観点に係る負荷分散方法は、
複数のサーバ全体で処理可能な処理量を示す全体性能値と前記複数のサーバそれぞれの性能に応じた重み付け値とに基づいて、前記複数のサーバそれぞれの性能を示す性能値を求める性能値取得ステップと、
クライアントと前記複数のサーバとの間の通信量を示す通信値を測定する測定ステップと、
前記複数のサーバにおける休止サーバと稼働サーバとの組合せのパターンの中で現在設定されているパターンの稼働サーバの性能値の合計である性能閾値と、前記測定した通信値と、を比較し、前記性能閾値が前記通信値よりも小さい場合、その通信値よりも大きい性能閾値のパターンを前記組合せのパターンの中から特定する特定ステップと、
前記現在設定されているパターンを前記特定したパターンに更新して、その更新したパターンの稼働サーバの重み付け値の比率に従って、前記クライアントからのリクエストを前記更新したパターンの稼働サーバに振り分けて負荷分散を行う負荷分散ステップと、を備えたことを特徴とする。
【0014】
上記目的を達成するため、この発明の第3の観点に係るプログラムは、
クライアントと複数のサーバとにネットワークを介して接続されるコンピュータを、
前記複数のサーバ全体で処理可能な処理量を示す全体性能値を記憶する全体性能値記憶手段、
前記複数のサーバそれぞれの性能に応じた重み付け値を記憶する重み付け値記憶手段、
前記全体性能値と前記サーバ毎の重み付け値とに基づいて、各サーバの性能を示す性能値を求める性能値取得手段、
前記複数のサーバにおける休止サーバと稼働サーバとの組合せのパターン毎に、前記稼働サーバの性能値の合計である性能閾値と該稼働サーバの重み付け値とを記憶するパターン記憶手段、
前記組合せのパターンのうち、予め設定されたパターンの稼働サーバの重み付け値を、前記パターン記憶手段が記憶しているパターン毎の稼働サーバの重み付け値を参照して特定し、その特定した稼働サーバの重み付け値の比率に従って、前記クライアントからのリクエストを前記予め設定されたパターンの稼働サーバに振り分ける負荷分散処理を行う負荷分散手段、
前記クライアントと前記複数のサーバとの間の通信量を示す通信値を測定する測定手段、
現在設定されているパターンの性能閾値を、前記パターン記憶手段が記憶しているパターン毎の性能閾値を参照して特定し、その特定した性能閾値と前記測定手段により測定した通信値とを比較し、前記性能閾値が前記通信値よりも小さい場合、その通信値よりも大きい性能閾値のパターンを前記組合せのパターンの中から特定する特定処理を行う特定手段、として機能させ、
前記負荷分散手段は、前記現在設定されているパターンを前記特定手段により特定したパターンに更新することを特徴とする。
【発明の効果】
【0015】
この発明によれば、ネットワークに接続された複数のサーバの省電力化を図ることができる。
【発明を実施するための形態】
【0017】
(第1実施形態)
以下、この発明の第1実施形態を図面に基づいて説明する。
図1に示すように、サーバクライアントシステムは、負荷分散装置100と、サーバ200、210及び220と、複数のクライアント300と、管理クライアント400と、を備える。
なお、複数のクライアント300それぞれのハードウェア構成及び機能は同じである。
【0018】
負荷分散装置100は、ネットワークを介して送信される複数のクライアント300からのリクエストを、各サーバに振り分ける装置である。この負荷分散装置100の負荷分散処理については後述する。なお、ネットワークとしては、LAN(ローカルエリアネットワーク)又はインターネットなど有線無線を問わず任意の通信経路を採用可能である。
【0019】
サーバ200、210及び220は、複数のクライアント300からのリクエストに応じて、HTML文書や画像などのデータを提供するウェブサーバである。この実施形態において、サーバ200、210及び220の性能は、それぞれ異なるものとする。また、サーバ200、210及び220それぞれを特段特定する必要がない場合には、代表してサーバ200により以下説明する。
【0020】
複数のクライアント300はそれぞれ、キーボード又はマウスなどからユーザの入力操作を受け付けてリクエストを送信するPC(パーソナルコンピュータ)である。そして、複数のクライアント300はそれぞれ、リクエストの応答としてサーバ200から提供されるデータに基づいて、ディスプレイなどの表示手段にHTML文書や画像などを表示する。ここで、リクエストとしては、例えば、セッションの接続リクエスト及びhttpリクエストなどがある。
【0021】
管理クライアント400は、負荷分散装置100に後述するパラメータを送信するためのPCである。パラメータの入力は、負荷分散装置100を管理する管理ユーザが、管理クライアント400のキーボート等から行う。具体的に管理ユーザは、管理クライアント400のウェブブラウザ又はTelnetなどを用いてパラメータを送信する。
【0022】
次に、
図2を参照しながら、負荷分散装置100のハードウェア構成について説明する。
図2に示すように、負荷分散装置100は、CPU101とフラッシュROM102とRAM103とネットワークI/F104と、を備える。
このうち、CPU101は、負荷分散装置100全体を制御する中央演算装置である。
フラッシュROM102は、CPU101が実行するプログラムを格納している不揮発性メモリである。
【0023】
RAM103は、CPU101が実行するプログラムを一時的に展開し、CPU101が各種処理を行う際の作業領域として使用する記憶手段である。
RAM103は、各種データを記憶する。各種データとしては、例えば、後述する重み付けテーブル、性能テーブル及び閾値テーブルなどである。
ネットワークI/F104は、この負荷分散装置100が、サーバ200、複数のクライアント300及び管理クライアント400とネットワークを介して通信を行うためのインタフェースである。
【0024】
ここで、CPU101は、フラッシュROM102内の各種プログラムを読み出し、RAM103に展開した後、その各種プログラムに従って負荷分散装置100を制御することで、
図3に示すような各部の機能を発揮することができる。機能としては、
図3に示すように、全体性能値受付部110、重み付け値受付部120、サーバ性能値取得部130、閾値テーブル生成部140、測定部150、パターン特定部160及び負荷分散制御部170を備える。なお、各部の機能の実行主体はCPU101であるが、説明の便宜上、各部の機能を実行主体として説明する。
【0025】
まず、全体性能値受付部110は、サーバ200、210及び220全体で処理可能な処理量を示す全体性能値を受け付ける手段である。
具体的には、全体性能値受付部110は、ネットワークI/F104を介して、管理クライアント400より送信された全体性能値のパラメータを受け付けて、RAM103に記憶する。ここで、全体性能値とは、例えば、サーバ200、210及び220全体で処理可能な毎秒あたりのセッション数(セッション/秒)及び毎秒あたりのパケット数(パケット/秒)などである。
【0026】
この実施形態では、一例として、管理ユーザが管理クライアント400にサーバ200、210及び220の全体性能値として60万セッション/秒のパラメータを入力したものとする。すると、全体性能値受付部110は、管理クライアント400よりネットワークを介して送信される全体性能値のパラメータである60万セッション/秒を受け付けて、RAM103に記憶する。
【0027】
次に、重み付け値受付部120は、サーバ200、210及び220それぞれの性能に応じた重み付け値を受け付ける手段である。
具体的には、重み付け値受付部120は、ネットワークI/F104を介して、管理クライアント400より送信された重み付け値のパラメータを受け付けて、RAM103に記憶する。重み付け値のパラメータは、管理クライアント400の管理ユーザが、サーバ200、210及び220の性能に応じて入力する。この実施形態では、一例として、管理ユーザが管理クライアント400にサーバ200、210及び220それぞれの重み付け値として2、3及び1のパラメータを入力したものとする。すると、重み付け値受付部120は、上記パラメータを受け付けて、
図4に示すような重み付けテーブルを生成し、RAM103に記憶する。
【0028】
次に、サーバ性能値取得部130は、全体性能値と、サーバ200、210及び220それぞれの重み付け値とに基づいて、サーバ200、210及び220それぞれの性能を示す性能値を求める性能値取得手段である。
具体的には、サーバ性能値取得部130は、まずRAM103に記憶された重み付けテーブルのサーバ200、210及び220それぞれの重み付け値が、全体の重み付け値に占める割合を算出する。ここで、例えば、サーバ200の重み付け値の全体に占める割合は、2(サーバ200の重み付け値)/6(重み付け値の合計値)となる。次に、サーバ性能値取得部130は、RAM103に記憶された最大性能値である60万セッション/秒と、2(サーバ200の重み付け値)/6(重み付け値の合計値)とを乗算することにより、サーバ200の性能値である20万セッション/秒を求める。サーバ性能値取得部130は、同様にサーバ210及び220についても、性能値を30万セッション/秒と10万セッション/秒とそれぞれ求める。これら各性能値は、各サーバが毎秒あたりに維持できる最大のセッション数を示している。
【0029】
そして、サーバ性能値取得部130は、求めた各サーバの性能値を、サーバ稼動状態に対応付けて、
図5に示す性能テーブルを生成し、RAM103に記憶する。このサーバ稼動状態には、省電力状態である休止サーバを含む。なお、休止サーバを除く、残りのサーバを稼動サーバと称して以下説明する。例えば、
図5の性能テーブルのサーバ稼働状態のうち、サーバ200休止の場合、稼動サーバはサーバ210及び220である。また、サーバ210及び220休止の場合、稼動サーバはサーバ200である。
【0030】
次に、閾値テーブル生成部140は、サーバ200、210及び220における休止サーバと稼働サーバの組合せのパターン毎に、稼働サーバの性能値の合計である性能閾値と、その稼働サーバの重み付け値とを対応付けた閾値テーブルを生成する手段である。
具体的には、閾値テーブル生成部140は、まず
図5の性能テーブルを参照し、サーバ稼動状態と対応する各サーバの性能値を合計して、性能閾値であるセッション閾値をそれぞれ算出する。そして、閾値テーブル生成部140は、
図6に示すように、サーバ稼動状態の組合せパターン毎に、稼動サーバのセッション閾値と、稼動サーバの重み付け値と、を対応付けた閾値テーブルを生成し、RAM103に記憶する。
【0031】
なお、この閾値テーブルにおいて、重み付け値「0」のサーバは、負荷分散装置100の負荷分散の対象外の休止サーバであり、負荷分散装置100が複数のクライアント300からのリクエストを振り分けることはない。
【0032】
図3に戻って、測定部150は、複数のクライアント300とサーバ200、210及び220との間の通信量を示す通信値を測定する測定手段である。
具体的には、測定部150は、サーバ200、サーバ210及び220と複数のクライアント300との間の通信量を示すセッション数を毎秒カウントする。
【0033】
パターン特定部160は、現在設定されているパターンの性能閾値を、RAM103が記憶している閾値テーブルを参照して特定し、その特定した性能閾値と測定部150により測定した通信値とを比較し、性能閾値が通信値よりも小さい場合、その通信値よりも大きい性能閾値のパターンを、閾値テーブルを参照して特定する特定手段である。
具体的には、パターン特定部160は、現在設定されているパターンのセッション閾値を、閾値テーブルを参照して特定し、その特定したセッション閾値と測定部150によりカウントしたセッション数とを比較し、セッション閾値がカウントしたセッション数よりも小さい場合、そのカウントしたセッション数よりも大きいセッション閾値のパターンの中で、最小の性能閾値のパターンを、閾値テーブルを参照して特定する。
【0034】
次に、負荷分散制御部170は、パターン1乃至7のうち、予め設定されたパターンの稼働サーバの重み付け値を、RAM103が記憶している閾値テーブルを参照して特定し、その特定した稼働サーバの重み付け値の比率に従って、複数のクライアント300からのリクエストを設定されたパターンの稼働サーバに振り分ける負荷分散手段である。
また、負荷分散制御部170は、パターン特定部160が、カウントしたセッション数よりも大きいセッション閾値のパターンを特定した場合、現在設定されているパターンを特定したパターンに更新する。この更新の具体的な手法については、後述する。
なお、負荷分散制御部170は、現在設定(又は更新後に設定)されたパターンの稼働サーバが1台である場合は、複数のクライアント300からのリクエストをその稼働サーバに振り分ける。
【0035】
以上、
図1乃至
図6を参照しながら説明した負荷分散装置100において、例えば、一つの特徴的な点は、受け付けた全体性能値と重み付け値とから休止サーバを含む性能テーブルを自動的に生成する。この性能テーブルから閾値テーブルを生成し、現在設定されているパターンのセッション閾値がカウントしたセッション数より小さい場合は、閾値テーブルを参照することにより、カウントしたセッション数よりも大きいパターンを特定し、その特定したパターンの重み付け値に動的に変更することでパターンを更新する点である。そこで、以下この点に関連する第1の負荷分散処理の流れについて、
図7のフローチャートを参照しながら説明する。
なお、この
図7のフローチャートは、CPU101が、フラッシュROM102に記憶された各種プログラムを実行して
図3に示した各部の機能を発揮することにより実施する。
【0036】
また、CPU101は、
図7の処理を、所定時間毎(例えば、毎秒)実施する。また、閾値テーブルのパターン1乃至7のうち、初期パターンとして設定されるパターンは、パターン7とする。これは、パターン7は、休止サーバ台数が多いので消費電力削減の観点から好ましい。また、複数のクライアント300からのセッションの接続リクエストに基づき、各サーバとの間でセッションが確立された後に維持されるセッションの数は、各サーバと複数のクライアント300とを負荷分散装置100を介してネットワーク接続した直後は少ないことが想定され、パターン7はセッション閾値が最小だからである。
なお、初期パターンの設定は、管理ユーザが管理クライアント400から行っても構わないし、CPU101が、休止サーバ台数が多く、かつセッション閾値が最小のパターンを特定して設定してもよい。また、この実施形態において、サーバ200、210及び220は、負荷分散装置100より所定時間リクエストの送信がないことを検知すると、自動的に稼働状態から休止状態になる。
【0037】
まず、
図7の処理において、CPU101は、セッション数をカウントする(S11)。具体的には、CPU101は、サーバ200、210及び220と、複数のクライアント300と、の間のセッション数をカウントする。
【0038】
次に、CPU101は、現在設定されているパターンのセッション閾値が、S11でカウントしたセッション数よりも大きいか否か判断する(S12)。具体的には、CPU101は、現在設定されているパターン7のセッション閾値を、閾値テーブルを参照して100,000と特定し、その特定したセッション閾値100,000が、S11でカウントしたセッション数よりも大きいか否か判断する。
【0039】
ここで、CPU101は、現在設定されているパターン7のセッション閾値100,000が、S11でカウントしたセッション数よりも大きいと判断すると(S12のYes方向)、パターンの重み付け値に従って負荷分散を行う(S17)。具体的には、CPU101は、複数のクライアント300からのリクエストを稼働サーバであるサーバ220に振り分ける。
【0040】
一方、CPU101は、現在設定されているパターン7のセッション閾値100,000が、S11でカウントしたセッション数よりも小さいと判断すると(S12のNo方向)、S11でカウントしたセッション数よりも大きいセッション閾値のパターンが閾値テーブルにあるか否か判断する(S13)。
ここで、例えば、S11でカウントしたセッション数が150,000である場合、CPU101は、パターン7のセッション閾値100,000が、セッション数150,000よりも小さいと判断する(S12のNo方向)。その後、CPU101は、カウントしたセッション数150,000よりも大きいセッション閾値のパターン1乃至6が閾値テーブルにあると判断する(S13のYes方向)。
【0041】
次に、CPU101は、S11でカウントしたセッション数よりも大きいセッション閾値のパターンのうち、休止サーバの台数が多いパターンを特定する(S14)。具体的には、CPU101は、セッション数150,000よりも大きいセッション閾値のパターン1乃至6のうち、休止サーバの台数が多いパターン4及び6を特定する。
次に、CPU101は、S14で特定したパターンが2以上か否かについて判断する(S15)。ここで、S15でYesの場合、CPU101は、休止サーバの台数が多いパターンのうち、最小のセッション閾値のパターンを特定する(S18)。具体的には、CPU101は、休止サーバの台数が多いパターンが4及び6であるためS15において2以上であると判断し(S15のYes方向)、休止サーバの台数が多いパターン4及び6のうち、最小のセッション閾値のパターン6を特定する(S18)。
【0042】
次に、CPU101は、S18で特定したパターンに更新するために、現在設定されているパターンの重み付け値を特定したパターンの重み付け値に変更する(S19)。ここで、CPU101は、S18で特定したパターン6に更新するために、パターン7の重み付け値をパターン6の重み付け値に変更する。具体的には、CPU101は、閾値テーブルを参照して、サーバ220の重み付け値を「1」から「0」に変更し、かつサーバ200の重み付け値を「0」から「2」に変更する。そして、CPU101は、複数のクライアント300からのリクエストを稼働サーバであるサーバ200に振り分ける(S17)。
【0043】
一方、S15でNoの場合(休止サーバの台数が多いパターンが一つの場合)、CPU101は、S14で特定したパターンに更新するために、現在設定されているパターンの重み付け値を特定したパターンの重み付け値に変更して(S16)、そのパターンの重み付け値に従って負荷分散を行う(S17)。
また、S13に戻って、CPU101は、S11でカウントしたセッション数よりも大きいセッション閾値のパターンが閾値テーブルにないと判断すると(S13のNo方向)、セッション閾値が最大のパターンに更新するために、現在設定されているパターンの重み付け値を変更する(S20)。
【0044】
ここで、例えば、S11でカウントしたセッション数が700,000であった場合、その700,000よりも大きいセッション閾値のパターンが閾値テーブルにない(S13のNo方向)。この場合、CPU101は、セッション閾値が最大のパターン1に更新するために、パターン7の重み付け値を変更する。具体的には、CPU101は、サーバ200の重み付け値を「0」から「2」に変更し、かつサーバ210の重み付け値を「0」から「3」に変更する。そして、CPU101は、パターン1の重み付け値の比率に従って負荷分散を行う(S17)。なお、S13において、S11でカウントしたセッション数よりも大きいセッション閾値のパターンが閾値テーブルにない場合に(S11でカウントしたセッション数が600,000を超えるような場合に)、セッション閾値が最大の600,000のパターン1の重み付け値に補正するのは、セッション数が600,000を超えた場合であってもパターン1で対応せざるを得ないからである。
また、
図7においてCPU101が実施した各処理のうち、S11は測定部150の機能に、S12、13、14、15及び18はパターン特定部160の機能に、S16、17、19、及び20は負荷分散制御部170の機能に、それぞれ対応する。
【0045】
以上、
図7の処理では、負荷分散装置100は、パターン特定部160及び負荷分散制御部170の機能を備えることにより、セッション閾値がカウントしたセッション数より小さい場合は、閾値テーブルを参照して、セッション閾値がカウントしたセッション数よりも大きく、かつ休止サーバの台数が多いパターンを特定し、その特定したパターンの重み付け値に動的に変更してパターンの更新をする。このことにより、負荷分散装置100は、所定時間毎(例えば、毎秒)カウントするセッション数がセッション閾値を超えないようにしつつ、稼働サーバに複数のクライアント300からのリクエストを振り分けるので、休止サーバについては省電力化を図ることができる。
【0046】
また、初期パターンは、パターン7としたが、他のパターンを初期パターンとしてもよいことはもちろんである。また、負荷分散装置100は、S20の処理に代えて、管理クライアント400に、カウントしたセッション数よりも大きいセッション閾値のパターンがない旨を通知してもよい。また、
図7の処理では、各サーバは、負荷分散装置100より所定時間リクエストの送信がないことを検知すると、自動的に稼働状態から休止状態になることとしたが、負荷分散装置100が能動的に各サーバを休止させてもよい。例えば、負荷分散装置100の負荷分散制御部170は、各サーバの重み付け値を「1」、「2」又は「3」から「0」にする際に、あわせて休止信号をサーバに送信してサーバを稼働状態から休止状態にしてもよい。
【0047】
(第2実施形態)
次に、この発明の第2実施形態を
図8乃至11を参照しながら説明する。
第2実施形態では、負荷分散装置100が、上述した
図7の処理に加えて、平均CPU使用率に基づいて、閾値テーブルのセッション閾値を補正する点が第1実施形態と異なる。そこで、この異なる点を中心に以下説明する。
なお、第2実施形態において、サーバクライアントシステムの構成は、第1実施形態の
図1に示した構成と同じである。また、負荷分散装置100のハードウェア構成は、第1実施形態の
図2に示した構成と同じである。また、負荷分散装置100の機能については、
図3に示した各部の機能に加えて、
図8に示す以下の機能を備える。
【0048】
まず、平均CPU使用率取得部181は、サーバ200、210及び220の平均CPU使用率を取得するCPU使用率取得手段である。具体的には、平均CPU使用率取得部181は、サーバ200、210及び220それぞれのCPU使用率を取得し、その取得したそれぞれのCPU使用率から平均CPU使用率を算出する。各サーバよりCPU使用率を取得する手法としては、例えば、各サーバに予めSNMP(Simple Network Management Protocol)エージェントと呼ばれるサーバ監視用のモジュールをインストールしておき、そのSNMPエージェントに対して負荷分散装置100がSNMPゲットのコマンドを発行することによりCPU使用率を取得できる。なお、別の手法により、CPU使用率を取得しても構わない。
【0049】
次に、CPU使用率テーブル生成部182は、パターン1乃至7のうち少なくとも1つの所定のパターンについて、その所定のパターンと、その所定のパターンの稼働サーバのセッション閾値と、そのセッション閾値における稼働サーバの基準平均CPU使用率と、所定の閾値と、を対応付けたCPU使用率テーブルを生成する手段である。
具体的には、CPU使用率テーブル生成部182は、
図9に示すように、例えばパターン5については、パターン5と、そのパターン5のセッション閾値300,000と、そのセッション閾値300,000における稼働サーバであるサーバ200及び220の基準平均CPU使用率50%と、所定の閾値10%とを対応付けたCPU使用率テーブルを生成し、RAM103に記憶する。なお、閾値は、管理クライアント400の管理ユーザが任意に設定する。また、基準平均CPU使用率については、カウントしたセッション数がセッション閾値になったときの稼働サーバ(上述の場合、サーバ200及び220)の平均CPU使用率を予め測定しておき設定する。
【0050】
次に、判断部183は、測定部150によりカウントした通信値であるセッション数が所定のパターンのセッション閾値になった場合、平均CPU使用率取得部181により取得した平均CPU使用率と所定のパターンと対応する基準平均CPU使用率との差の絶対値を算出する。そして、判断部183は、その差の絶対値が、所定の閾値以上か否か判断する。
次に、閾値テーブル補正部184は、判断部183により差の絶対値が、所定の閾値以上であると判断すると、その差の絶対値の大きさに応じて、閾値テーブルの所定のパターンのセッション閾値を補正する補正手段である。
【0051】
次に、
図10を参照しながら、第2実施形態に係る第2の負荷分散処理の流れについて説明する。なお、CPU101は、
図10の処理を、
図7の処理と同様に、所定時間毎(例えば、毎秒)に実施する。
まず、CPU101は、セッション数をカウントする(S31)。
次に、CPU101は、現在設定されているパターンが所定のパターンか否か判断する(S32)。具体的には、CPU101は、
図9に示したCPU使用率テーブルを参照して、現在設定されているパターンが所定のパターンか否か判断する。
ここで、CPU101は、現在設定されているパターンが所定のパターンでない場合(S32のNo方向)、
図7で説明したS12乃至S20の負荷分散処理を実施して処理を終了する。
一方、CPU101は、現在設定されているパターンが所定のパターン(例えば、現在設定されているパターンがパターン5)の場合(S32のYes方向)、S31でカウントしたセッション数が、所定のパターンのセッション閾値になったか否か判断する(S33)。具体的には、CPU101は、カウントしたセッション数が、パターン5のセッション閾値300,000になったか否か判断する。
【0052】
ここで、CPU101は、カウントしたセッション数が、設定されたパターン5のセッション閾値300,000になっていないと判断すると(S33のNo方向)、
図7で説明したS12乃至S20の負荷分散処理を実施して処理を終了する。なお、この負荷分散処理を実施する場合、S12で用いるカウントしたセッション数は、S31でカウントしたセッション数を用いる。
【0053】
一方、CPU101は、カウントしたセッション数が、設定されたパターン5のセッション閾値300,000になったと判断すると(S33のYes方向)、パターン5の稼働サーバであるサーバ200及び220の平均CPU使用率を取得する(S34)。
【0054】
次に、CPU101は、平均CPU使用率取得部181により取得した平均CPU使用率とパターン5と対応する基準平均CPU使用率との差の絶対値が、閾値以上か否か判断する(S35)。ここで、例えば、S34で取得した平均CPU使用率が40%の場合、基準平均CPU使用率50%との差の絶対値は10%となって、閾値である10%以上となる(S35でYes方向)。この場合、S36に進む。
【0055】
S36では、CPU101は、閾値テーブルのセッション閾値の補正を行う。具体的には、CPU101は、差の絶対値の大きさに応じて、閾値テーブルの所定のパターンのセッション閾値を補正する。上述の例の場合、差の絶対値は10%なので、比例計算により補正後のセッション閾値375,000を算出する。計算式は、300,000(セッション閾値):40%(平均CPU使用率)=補正後のセッション閾値:50%(基準平均CPU使用率)である。そして、CPU101は、
図11に示すように、パターン5のセッション閾値300,000を補正後のセッション閾値375,000に補正する。その後、S12乃至S20の負荷分散処理を実施して処理を終了する。
【0056】
一方、例えば、S34で取得した平均CPU使用率が60%の場合、基準平均CPU使用率50%との差の絶対値は10%となって、閾値である10%以上となる(S35のYes方向)。そして、CPU101は、比例計算により補正後のセッション閾値250,000を算出し、その算出した補正後のセッション閾値になるように設定されたパターン5のセッション閾値を補正する。その後、S12乃至S20の負荷分散処理を実施して処理を終了する。
【0057】
一方、例えば、S34で取得した平均CPU使用率が45%の場合、基準平均CPU使用率50%との差の絶対値は5%となって、閾値である10%以上にならない(S35のNo方向)。この場合、CPU101は、閾値テーブルの補正を行わない。S35の後は、S12乃至S20の負荷分散処理を実施して処理を終了する。
【0058】
なお、
図10においてCPU101が実施した各処理のうち、S31は測定部150の機能に、S32、33及び35は判断部183の機能に、S34は平均CPU使用率取得部181の機能に、S36は閾値テーブル補正部184の機能に、それぞれ対応する。
また、
図10の処理においては、パターン5を例にとって説明したが、他のパターンについても
図9と同様に、セッション閾値と基準平均CPU使用率と所定の閾値とを対応付けてRAM103に記憶しておき、
図10のS31乃至36の処理を実施してもよいことはもちろんである。
【0059】
以上、
図10の処理では、負荷分散装置100が平均CPU使用率取得部181、CPU使用率テーブル生成部182、判断部183、閾値テーブル補正部184の各機能を備えることにより、基準平均CPU使用率と取得した平均CPU使用率との差の絶対値が閾値以上の場合は、その差の絶対値の大きさに応じて、閾値テーブルの現在設定されているパターンのセッション閾値を補正する。このことにより、取得した平均CPU使用率が基準平均CPU使用率より大きくずれる場合は、その差であるずれ量に応じてセッション閾値を補正できるので、平均CPU使用率を加味したセッション閾値を用いて、精度の高い
図7の負荷分散処理を実施することができる。
【0060】
(第3実施形態)
次に、この発明の第3実施形態を
図12乃至
図15を参照しながら説明する。
まず、
図12は、CPU使用率と消費電力の関係の一例を示している。この
図12では、サーバ休止時からCPU使用率が低い間の傾きが急であるため、消費電力の変化量を考慮すると、CPU使用率を低く抑えた状態でサーバを運用した方が好ましい。
また、
図13は、CPU使用率と消費電力の関係の別例を示す図である。この
図13において、斜線部分は、消費電力が一定にならない区間である。また、この
図13では、CPU使用率が50%を超えると、急激にサーバの消費電力が増加する。このような場合、サーバのCPU使用率を、30%よりも小さく抑えた状態でサーバを運用した方がサーバの消費電力の観点から好ましい。
【0061】
そこで、第3実施形態では、負荷分散装置100が、上述した
図7の処理を、平均CPU使用率の上限値を超えないように行う。この点が実施形態1と異なる。以下、この異なる点を中心に説明する。
なお、第3実施形態において、サーバクライアントシステムの構成は、実施形態1の
図1に示した構成と同じである。また、負荷分散装置100のハードウェア構成は、実施形態1の
図2に示した構成と同じである。また、負荷分散装置100の機能については、
図3に示した各部の機能に加えて、
図14に示す以下の機能を備える。なお、平均CPU使用率取得部181は、第2実施形態の
図8の平均CPU使用率取得部181と同じなので、説明を省略する。
【0062】
まず、CPU上限値受付部191は、サーバ200、210及び220の平均CPU使用率の上限値であるCPU使用率上限値を受け付けてRAM103に記憶する手段である。具体的には、まず管理ユーザが管理クライアント400にCPU使用率上限値を入力する。次に、CPU上限値受付部191は、管理クライアント400からネットワークを介して送信されるCPU使用率上限値を受け付け、RAM103に記憶する。
【0063】
次に、更新部192は、平均CPU使用率取得部181により取得した平均CPU使用率がCPU使用率上限値以上の場合、現在設定されているパターンの稼働サーバの台数よりも稼働サーバ台数が多いパターンを特定する。そして、更新部192は、その特定したパターンに更新するために、現在設定されているパターンの重み付け値を特定したパターンの重み付け値に変更して、パターンを更新する更新手段である。
【0064】
次に、
図15を参照しながら、第3実施形態に係る第3の負荷分散処理の流れについて説明する。なお、CPU101は、
図15の処理を、
図7の処理と同様に、所定時間毎(例えば、毎秒)に実施する。
まず、CPU101は、現在設定されているパターンの稼働サーバの平均CPU使用率を取得する(S41)。そして、CPU101は、S41で取得した平均CPU使用率が、CPU使用率上限値よりも小さいか否か判断する(S42)。
【0065】
ここで、CPU101は、S41で取得した平均CPU使用率が、CPU使用率上限値よりも小さい場合(S42でYes方向)、S11乃至S20の負荷分散処理を行って処理を終了する。
一方、CPU101は、S41で取得した平均CPU使用率が、CPU使用率上限値以上の場合(S42でNo方向)、閾値テーブルを参照して、現在設定されているパターンの稼働サーバ台数よりも、稼働サーバ台数が多いパターンがあるか否か判断する(S43)。
ここで、CPU101は、現在設定されているパターンの稼働サーバ台数よりも、稼働サーバ台数が多いパターンがなければ(S43のNo方向)、S11乃至S20の負荷分散処理を行って処理を終了する。
【0066】
一方、CPU101は、現在設定されているパターンの稼働サーバ台数よりも、稼働サーバ台数が多いパターンがあれば(S43のYes方向)、現在設定されているパターンの稼働サーバ台数よりも、1台稼働サーバ台数が多いパターンを特定する(S44)。そして、CPU101は、S44で特定したパターンに更新するために、現在設定されているパターンの重み付け値を特定したパターンの重み付け値に変更する(S45)。そして、CPU101は、更新後に設定されているパターンの稼働サーバの平均CPU使用率を再度取得し、S42乃至S45の処理を繰り返す。
なお、
図15においてCPU101が実施した各処理のうち、S41は平均CPU使用率取得部181の機能に、S42乃至45は更新部192の機能に、それぞれ対応する。
【0067】
以上、
図15の処理では、負荷分散装置100が平均CPU使用率取得部181、CPU上限値受付部191及び更新部192を備えることにより、S41乃至S45の処理を、取得した平均CPU使用率がCPU使用率上限値よりも小さくなるまで繰り返す。そして、取得した平均CPU使用率がCPU使用率上限値より小さい場合、S11乃至S20の負荷分散処理を行う。このことにより、稼働サーバの平均CPU使用率がCPU使用率上限値を超えない場合に、S11乃至S20の負荷分散処理を行えるので、各サーバの省電力化を図ることができる。
【0068】
以上で各実施形態の説明を終了するが、負荷分散装置100の具体的な構成や処理の内容等が上述の各実施形態で説明したものに限られないことはもちろんである。
例えば、第1の実施形態の
図7のフローチャートでは、CPU101は、S14において、カウントしたセッション数よりも大きいセッション閾値のパターンのうち、休止サーバの台数が多いパターンを特定し、その特定したパターンが2以上の場合(S15のYes方向)、その2以上のパターンのうち最小のセッション閾値のパターンを特定したが(S18)、パターンの特定方法はこれに限られない。
例えば、カウントしたセッション数よりも大きいセッション閾値のパターンの中で、最小のセッション閾値のパターンを特定し、その特定したパターンが2以上の場合、その2以上のパターンのうち休止サーバの台数が多いパターンを特定してもよい。
【0069】
第1乃至第3実施形態では、パターンを更新する手法として現在設定されているパターンの重み付け値を特定したパターンの重み付け値に変更するようにしたが、他の手法によりパターンの更新をしてもよい。例えば、重み付け値を変更することなく、単に現在設定されているパターンの重み付け値を用いずに、更新後のパターンの重み付け値を用いて負荷分散を行ってもよい。
また、各実施形態における閾値テーブルの性能閾値としては、セッション閾値を用いたが、他の性能閾値を用いてもよい。例えば、毎秒あたりに処理できるパケット数をパケット閾値として用いてもよい。この場合、管理ユーザは、管理クライアント400にサーバ200、210及び220全体の性能値として最大パケット数を入力する。サーバ性能値取得部130は、最大パケット数と、各サーバの重み付け値とに基づいて、各サーバのパケット閾値を算出する。そして、
図7、10及び15の各フローチャートの処理にあたっては、測定部150は、通信値として複数のクライアント300から送信されるパケット数をカウントする。
【0070】
また、負荷分散装置100にカレンダー機能を持たせ、負荷の状況によって閾値テーブルの重み付け値を動的に切り替えるようにしてもよい。
例えば、
図16及び
図17にそれぞれ示すように、パターン1における高負荷時と低負荷時の切り替え用重み付け値を予め用意しておき、日、曜日又は時間帯に応じて重み付け値を切り替えるようにする。
【0071】
ここで、フラグは、「0」又は「1」の2値で表され、「0」は重み付け値を切り替えないことを示し、「1」は重み付け値を切り替えることを示している。この
図16及び
図17の例では、高負荷時は重み付け値を切り替えないようにし、低負荷時はサーバ200の重み付け値を2から0に切り替え、休止させるようにしている。
CPU101は、例えば高負荷時の夜間の時間帯は
図16に示す重み付け値を用いる。一方、CPU101は、例えば低負荷時の朝方及び昼間の時間帯は
図17に示す切り替え用重み付け値になるように、
図6の閾値テーブルのパターン1のサーバ200の重み付け値を切り替える。
【0072】
このように、負荷分散装置100がカレンダー機能を備えることで、例えば低負荷時には休止サーバの台数を増やして運用できるので、サーバの省電力化を図ることできる。また、このカレンダー機能は、定期メンテナンスの日時にあわせてサーバを計画停止する際にも好適である。なお、
図16及び
図17では、パターン1を例にとって説明したが、パターン毎に、切り替え用重み付け値のテーブルを用意しても構わない。また、
図6に示した閾値テーブルを日、曜日又は時間帯毎に用意しても構わない。
【0073】
なお、この発明の負荷分散装置100は、通常のPC等のコンピュータによっても実現することができる。
具体的には、上記各実施形態では、負荷分散装置100のプログラムが、フラッシュROM102に予め記憶されているものとして説明した。しかし、フラッシュROM102のプログラムをコンピュータにインストールして、上述の各部機能を実行することができるコンピュータを構成してもよい。なお、プログラムは、フラッシュROM102に限らず、その他のコンピュータ読み取り可能な記録媒体(例えば、フレキシブルディスク、CD−ROM、DVD及びMO等)に格納してコンピュータに配布してもよいことはもちろんである。
【0074】
また、プログラムをインターネット等の通信ネットワーク上のサーバ装置が有するディスク装置等に格納しておき、例えば、コンピュータにダウンロード等するようにしてもよい。さらに、通信ネットワークを介してプログラムを転送しながら起動実行することによっても、上述の負荷分散装置100の処理を達成することができる。