以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
実施の形態に係る情報処理システムは、複数の並列に配置されたサーバ群でユーザからのアクセスを処理する。負荷管理装置はその情報処理システムのゲートウエイとして機能し、外部ネットワークから情報処理システム宛に到来する要求の負荷が少ない場合は不必要なサーバ群のOS(operating system)を休眠させたり、サーバ群の電源自体をオフにする。また、サーバ群の電力特性は使用する機種等により異なる場合があるが、情報処理システムの解析装置が電力特性を計測して負荷管理装置に報告する。負荷管理装置は、その報告を受けて例えば電力効率が悪いサーバ群からOSを休眠させたり電源をオフにしたりする。これにより情報処理システムが総合的に省エネ化される。
図1は、実施の形態に係る情報処理システム2を示す概略図である。情報処理システム2は、ネットワーク接続型のデータセンタであり、例えば証券会社のインターネット株取引システムを提供するデータセンタである。情報処理システム2は、解析装置100と、負荷管理装置1010と、情報処理装置1020と、を備える。情報処理装置1020は、第1サーバ群1022aと、第2サーバ群1022bと、第3サーバ群1022cと、第4サーバ群1022dと、第5サーバ群1022eと、を含む。第1サーバ群1022aは、第1フロントエンドサーバ1024aと、第1アプリケーションサーバ1026aと、第1データベースサーバ1028aと、を含む。第2サーバ群1022b、第3サーバ群1022c、第4サーバ群1022d、および第5サーバ群1022eは、それぞれ第1サーバ群1022aと同等の構成を有する。
以下、第1サーバ群1022a、第2サーバ群1022b、第3サーバ群1022c、第4サーバ群1022d、第5サーバ群1022e、はサーバ群1022と総称される場合がある。また、第1フロントエンドサーバ1024a、第2フロントエンドサーバ1024b、第3フロントエンドサーバ1024c、第4フロントエンドサーバ1024d、第5フロントエンドサーバ1024e、はフロントエンドサーバ1024と総称される場合がある。また、第1アプリケーションサーバ1026a、第2アプリケーションサーバ1026b、第3アプリケーションサーバ1026c、第4アプリケーションサーバ1026d、第5アプリケーションサーバ1026e、はアプリケーションサーバ1026と総称される場合がある。また、第1データベースサーバ1028a、第2データベースサーバ1028b、第3データベースサーバ1028c、第4データベースサーバ1028d、第5データベースサーバ1028e、はデータベースサーバと総称される場合がある。
情報処理システム2は、外部ネットワーク1004と接続され同じく外部ネットワーク1004に接続されている少なくともひとつのユーザ端末1006から要求を受ける。ここで要求とは、例えばユーザ端末1006からのアクセスである。アクセスとは、ユーザ端末1006と情報処理システム2のひとつのサーバ群1022とが接続を確立して一連の情報をやりとりすることである。異なるユーザ端末からのアクセスは異なるアクセスであり、同じユーザ端末1006からでも異なるアクセスがなされうる。
外部ネットワーク1004は、例えばLAN(Local Area Network)・WAN(Wide Area Network)・インターネットである。ユーザ端末1006は、ユーザが使用するコンピュータであり、例えば有線で外部ネットワーク1004に接続された家庭用デスクトップコンピュータや、無線で外部ネットワーク1004に接続されたラップトップコンピュータである。
負荷管理装置1010は、外部ネットワーク1004と接続され、また情報処理装置1020に含まれる個々のサーバ群1022と内部ネットワーク3を介して接続される。負荷管理装置1010は、データの流れの観点からは情報処理装置1020と外部ネットワーク1004との間に位置し、外部ネットワーク1004からの情報処理装置1020に対するアクセスを仲介する。
負荷管理装置1010は、解析装置100が算出する情報処理装置1020に含まれる複数のサーバ群1022の稼動状況が示された指標を以下の3通りで使用する。
1.負荷管理装置1010は、外部ネットワーク1004を介してユーザ端末1006から情報処理装置1020に対するアクセスを取得する。負荷管理装置1010は、解析装置100によって算出された指標に基づいて、情報処理装置1020に含まれる複数のサーバ群1022のうちアクセスを受付可能な状態(以下、稼動状態と称する)にあるサーバ群に、取得されたユーザからのアクセスを割り当てる。
2.負荷管理装置1010は、解析装置100によって算出された指標に基づいて、複数のサーバ群1022の状態を制御する。サーバ群1022の状態として、稼動状態と省電力状態とが基本的に規定される。負荷管理装置1010は、外部ネットワーク1004からの負荷を監視する。負荷管理装置1010は、負荷が所定の値より少なくなると、解析装置100によって算出された指標に基づいて、稼動状態にあるサーバ群のうちアクセスの処理に不要なサーバ群を選択し、選択されたサーバ群を稼動状態よりも省電力の省電力状態に設定する。
ここで負荷とは、例えばサーバ群1022が行う仕事の量を表す値であり、単位時間当たりのアクセスの数を基に定められる。例えば負荷は、単位時間当たりのアクセスの数と比例関係などの数学的関係を有する値であってもよい。また、負荷は単位時間当たりのアクセスの数に上限値または下限値若しくはその両方を課した値であってもよい。以下では、負荷の一例が、単に単位時間当たりのアクセスの数(以下、アクセス数と称す)である場合について説明する。
なお、負荷が所定の値以上の場合は負荷管理装置1010は全てのサーバ群1022を稼動状態に設定する。
3.本実施の形態では、負荷管理装置1010は、負荷としてアクセス数以外に、ユーザ端末1006などの外部から負荷管理装置1010に送られるパケットおよび負荷管理装置1010から外部に送られるパケットの総データ量も利用する。負荷管理装置1010は、解析装置100によって算出されるその総データ量を監視する。
情報処理装置1020は、外部ネットワーク1004からのアクセスを処理する。情報処理装置1020は、複数のサーバ群1022を含み、そのそれぞれのサーバ群1022はアクセスの処理単位である要求処理ユニットとして機能する。
本実施の形態では、TCP(Transmission Control Protocol)/IP(Internet Protocol)プロトコルにしたがった通信が行われる場合を考える。
サーバ群1022はいわゆる3階層のサーバ群であり、これら1セットでアクセスの処理単位を構成する。フロントエンドサーバ1024は、WEBサーバとも呼ばれ、HTTP(HyperText Transfer Protocol)に則り、ユーザ端末1006のWEBブラウザに対して、HTML(HyperText Markup Language)や画像などのオブジェクトの表示を提供するサービスが動作するサーバコンピュータである。アプリケーションサーバ1026は、フロントエンドサーバ1024からジャバサーブレット(Java Servlet、ジャバは登録商標)の処理などのアプリケーションに関する機能を切り出して実現するサーバコンピュータである。データベースサーバ1028は、アプリケーションサーバ1026のアプリケーションが使用するデータが格納されるサーバコンピュータである。フロントエンドサーバ1024、アプリケーションサーバ1026、およびデータベースサーバ1028は、公知の情報処理技術を使用して実現される。本実施の形態では、フロントエンドサーバ1024とアプリケーションサーバ1026とデータベースサーバ1028とは別個のサーバであり、この順に直列に接続されている。
サーバ群1022のフロントエンドサーバ1024は内部ネットワーク3を介して負荷管理装置1010と接続される。
なお、個々のサーバ群1022に含まれるサーバは個々にもしくは全体としてOSに管理されている。個々のサーバ群の稼動状態は、ユーザからのアクセスを即時処理可能な状態である。この状態は、サーバ群1022がユーザからのアクセスを処理しつつ新たなアクセスを処理可能である状態と、ユーザからのアクセスがなく仕事が発生していないアイドル状態と、を含む。稼動状態では、たとえアイドル状態であっても少なくとも基本OS機能とネットワークモニタリングのタスクは稼動しており、その分電力を消費する。本発明者の当業者としての経験から、このアイドル状態での消費電力は、サーバ機器の種類によってピークアクセス数での稼動時のおよそ30%から70%の範囲にある。特に、最新のブレードサーバでは、その高密度な回路構成と狭いスペースに多くの半導体素子が設置されている都合上、アイドル状態でも消費電力は大きくなる。一部のブレードサーバではアイドル状態においてピークアクセス数での稼動時の70%もの電力を消費しているものも存在する。また、標準的なサーバ機器を用いる場合は60%程度である。ここでピークアクセス数とは、サーバ群1022がその処理速度を落とさずに稼動できるアクセス数の範囲の上限値であり、サーバ群1022ごとにその仕様を基に予め定められている。ここで処理速度とは、サーバ群1022におけるユーザからのアクセスの処理速度である。
個々のサーバ群1022の省電力状態は、ユーザからのアクセスを即時処理できない状態である。この状態は、サーバ群1022へ電源は供給されているがそのサーバ群1022はユーザからのアクセスを処理できないOS休眠状態を含む。サーバ群1022は負荷管理装置1010から休眠導入信号を受信するとOS休眠状態となる。このOS休眠状態では、サーバ群1022のOSは休眠(ハイボネート)しており、ユーザからのアクセスがあってもそれを受け付けない。OS休眠状態にあるサーバ群1022は負荷管理装置1010から休眠解除信号を受信すると、稼動状態に復帰する。OS休眠状態から稼動状態に復帰するためには通常数秒から数十秒かかる。また本発明者の当業者としての経験から、OS休眠状態におけるサーバ群1022の消費電力は、ピークアクセス数での稼働時のおよそ5%から10%である。
サーバ群1022の省電力状態はさらに、サーバ群1022への電源が遮断されている電源オフ状態を含む。サーバ群1022は負荷管理装置1010から電源オフ信号を受信すると電源オフ状態となる。サーバ群1022は負荷管理装置1010からWOL(Wake Up on LAN)信号などの電源オン信号を受信すると、稼動状態に復帰する。電源オフ状態から稼動状態に復帰するためには通常数分かかる。
本実施の形態ではサーバ群1022が省電力状態から稼動状態に復帰するためにかかる時間(以下、オーバヘッドと称す)と、省電力状態で低減される消費電力とのかねあいで、省電力状態とされるサーバ群の数が決定される。つまり、現在のアクセス数を処理するのに必要なぎりぎりの数のサーバ群だけを稼動状態としていると、突然のアクセス数の増大に対して対処できなくなる可能性がある。一方で稼動状態のサーバ群の数が多いほど待機電力由来の消費電力も大きくなる。そこでそれらの影響が拮抗するように、省電力状態とされるサーバ群の数が決定される。
解析装置100は、外部ネットワーク1004、負荷管理装置1010、内部ネットワーク3、のそれぞれを通過するパケットを傍受する。また解析装置100は、各サーバ群1022の内部でやりとりされるパケットも傍受する。これは例えば、フロントエンドサーバ1024とアプリケーションサーバ1026とを接続するサブネットや、アプリケーションサーバ1026とデータベースサーバ1028とを接続するサブネットに解析装置100が接続されることによって実現される。
「傍受する」ことは、傍受対象のパケットを消滅させることなくその内容を取得することであってもよく、例えばパケットをそれに含まれる終点IPアドレスによらずに取得することであってもよい。
解析装置100は、傍受したパケットの内容を蓄積し、IPアドレスでソートすることで各IPアドレスに対応するサーバや負荷管理装置1010における仕事の内訳を導出する。
解析装置100は、例えば各サーバに電力を供給するバスバー方式のテーブルタップ型のPDUから、各サーバに供給された電力の計測値を取得し蓄積する。解析装置100は、蓄積された電力の計測値および上記の仕事の内訳から、サーバ群1022の稼働状況が示された指標、例えばサーバ群1022における単位有効仕事量あたりの消費電力を算出する。
図2は、図1におけるアクセスの流れを説明するための説明図である。以下、1回のアクセスにおいて、少なくともひとつのパケットがユーザ端末1006とアクセスが割り当てられたサーバ群との間でやりとりされる場合について説明する。このパケットは、送信元のIPアドレスである始点IPアドレスと、受信先のIPアドレスである終点IPアドレスと、シーケンス番号と、ポート番号と、タイムスタンプと、を含む。多くの場合において一回のアクセスにつき複数個のパケットがユーザ端末1006とサーバ群との間を行き来する。図2では第3サーバ群1022cがアクセスに割り当てられたとする。ユーザ端末1006のIPアドレスを「175.34.11.21」、負荷管理装置1010のIPアドレスを「100.10.10.10」、第3サーバ群1022cに含まれる第3フロントエンドサーバ1024cのIPアドレスを「121.21.15.3」とする。
負荷管理装置1010は、ユーザ端末1006に対して仮想サーバとして働く。つまり、外部ネットワーク1004では、ユーザが情報処理装置1020が有する情報資源にアクセスしようとする場合、かかる情報資源のURL(Uniform Resource Locator)が負荷管理装置1010のIPアドレス「100.10.10.10」に名前解決されるよう設定されている。
まずユーザは、ユーザ端末1006のウェブブラウザに対して情報処理装置1020が有する情報資源のURLを指定する。ユーザ端末1006のウェブブラウザによって始点IPアドレスを「175.34.11.21」、終点IPアドレスを「100.10.10.10」とした第1パケットP1が生成され、外部ネットワーク1004に送られる。負荷管理装置1010は第1パケットP1を受信し、稼動状態にあるサーバ群のなかから第3サーバ群1022cを選択してこのアクセスを割り当てる。負荷管理装置1010は、第1パケットP1の始点IPアドレスはそのままにして終点IPアドレスを「121.21.15.3」とした第2パケットP2を内部ネットワーク3に送出する。第3サーバ群1022cの第3フロントエンドサーバ1024cは自己宛の第2パケットP2を受信し、第2パケットP2のポート番号やそのパケットに搭載されるデータに基づき処理を行う。その処理の結果ユーザ端末1006へ戻すべき情報は、始点IPアドレスを「121.21.15.3」、終点IPアドレスを「175.34.11.21」とした第3パケットP3に含められ、第3フロントエンドサーバ1024cから内部ネットワーク3に送出される。負荷管理装置1010は第3パケットP3を受信する。負荷管理装置1010は、第3パケットP3の終点IPアドレスはそのままにして始点IPアドレスを「100.10.10.10」とした第4パケットP4を外部ネットワーク1004に送る。ユーザ端末1006は自己宛の第4パケットP4を外部ネットワーク1004から受信する。
以下、ユーザ端末1006から負荷管理装置1010に送られるパケット(第1パケットP1)を総称して行きパケット、負荷管理装置1010から情報処理装置1020へ送られるパケット(第2パケットP2)を総称して割当パケットという。
以下ではまず解析装置100について説明し、次いで負荷管理装置1010について説明する。
(解析装置100)
図3は、解析装置100の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのCPU(central processing unit)をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
解析装置100は、ネットワークインタフェース部102と、通信情報保持部104と、分類部132と、集計部130と、第1指標保持部108と、係数保持部114と、第1解析部116と、使用状況取得部110と、使用状況保持部112と、第2指標保持部118と、第2解析部152と、第3指標保持部158と、指標送信部154と、表示制御部120と、を備える。
ネットワークインタフェース部102は、傍受部122と、抽出部124と、フィルタ部126と、登録部128と、を含む。
傍受部122は、外部ネットワーク1004と内部ネットワーク3とからパケットを傍受する。内部ネットワーク3は、各サーバ群1022のサーバを相互接続するサブネットを含む。抽出部124は、傍受部122によって傍受されたパケットから始点IPアドレスと終点IPアドレスとポート番号とを抽出する。
以下、負荷管理装置1010またはサーバ群1022またはサーバ群1022のサーバをノードと呼ぶ場合がある。
フィルタ部126は、フィルタ機能がオンとされるフィルタリングモードでは、抽出部124によって抽出された始点IPアドレスおよび終点IPアドレスを基に、計測対象のノードのIPアドレスが含まれたパケットのみを選択して、登録部128に出力する。より具体的にはフィルタ部126は、抽出部124によって抽出された始点IPアドレスおよび終点IPアドレスのうちの少なくとも一方が計測対象のノードのIPアドレスと一致する場合にのみ、抽出元のパケットを登録部128に出力する。
特にフィルタ部126は、計測対象のノードを、情報処理システム2に含まれる複数のノードから順番に選択する。すなわち、フィルタ部126は、計測対象のノードのIPアドレスを、情報処理システム2に含まれる複数のノードのIPアドレスのなかで順番に切り替える。
フィルタ部126は、フィルタ機能がオフとされるフィルタリングオフモードでは、抽出部124によって始点IPアドレスと終点IPアドレスとポート番号とが抽出されたパケットを登録部128に出力する。
登録部128は、フィルタ部126によって出力されたパケットについて、そのパケットに関する時刻と、抽出部124によってそのパケットから抽出された始点IPアドレスと、抽出部124によってそのパケットから抽出された終点IPアドレスと、抽出部124によってそのパケットから抽出されたポート番号に対応する通信用途と、そのパケットのデータ量と、を対応付けて通信情報保持部104に登録する。
図4は、通信情報保持部104に保持されるデータの一例を示すデータ構造図である。通信情報保持部104は、時刻202と、始点IPアドレス204と、終点IPアドレス206と、通信用途208と、データ量210と、を対応付けて保持する。
時刻202は、パケットに関する時刻であり、例えばパケットにタイムスタンプが含まれているのであればそのタイムスタンプで示される時刻である。あるいはまた、傍受部122によってパケットが傍受された時刻であってもよい。
始点IPアドレス204および終点IPアドレス206はそれぞれ、抽出部124によって抽出された始点IPアドレスおよび終点IPアドレスである。
通信用途208は、抽出部124によって抽出されたポート番号に対応する通信用途である。
データ量210は、パケットに搭載されているデータの量をバイト(B)単位で示す。
図3に戻る。分類部132は、抽出部124によって抽出された始点IPアドレスおよび終点IPアドレスのうちの少なくともひとつとポート番号とによってパケットを分類する。以下では分類部132が始点IPアドレスとポート番号とによってパケットを分類する場合について説明する。しかしながら、分類部が終点IPアドレスとポート番号とによってパケットを分類する場合、および分類部が始点および終点IPアドレスとポート番号とによってパケットを分類する場合でも以下と同様の説明が成り立つことは、本明細書に触れた当業者には明らかである。
分類部132は、通信情報保持部104に保持されるデータを始点IPアドレスについてソーティングする。以下、通信情報保持部104に登録されている始点IPアドレスを登録IPアドレスと称す。分類部132は、各登録IPアドレスについて通信用途によってパケットを分類する。特に分類部132は、サーバ情報保持部138を参照し、登録IPアドレスに対応するノード(以下、登録ノードと称す)に対して予め定められた通信用途である本来用途に関する情報を取得する。分類部132は、その本来用途に対応したパケットと、本来用途以外の通信用途である非本来用途に対応したパケットとに分類する。本来用途は、例えば登録ノードがWEBサーバであれば、ポート番号「80」に対応するWEB通信である。非本来用途は、例えば本来用途以外の通信用途であり、登録ノードがWEBサーバであればポート番号「20」に対応するFTP転送などである。
図5は、サーバ情報保持部138に保持されるデータの一例を示すデータ構造図である。サーバ情報保持部138は、ノードのノード名214と、ノードのIPアドレス218と、ノードの用途224と、を対応付けて保持する。
分類部132は、サーバ情報保持部138を参照してあるノードの本来用途に関する情報を取得する際、そのノードの用途を参照して本来用途を取得してもよい。
図3に戻る。集計部130は、少なくともひとつの登録ノードについて、本来用途に対応したパケットを集計する。特に集計部130は、所定の長さの期間すなわち時間帯ごとに、登録ノードの本来用途に対応したパケットのデータ量を集計し、また非本来用途に対応したパケットのデータ量を集計する。
例えば、登録IPアドレス「121.21.15.1」に対応する登録ノードについて、時間帯「02/15/10 11:10:00~11:20:00」で集計する場合について考える。図5のサーバ情報保持部138から登録ノードは第1フロントエンドサーバ1024aでありWEBサーバである。集計部130は、分類部132における分類結果から、始点IPアドレスが「121.21.15.1」であり、通信用途が「WEB通信」であり、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、本来用途に対する集計結果を得る。また、集計部130は、始点IPアドレスが「121.21.15.1」であり、通信用途が「WEB通信」ではなく、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、非本来用途に対する集計結果を得る。
なお、集計部130は、負荷管理装置1010については、外部から負荷管理装置1010に送られるパケットおよび負荷管理装置1010から外部に送られるパケットの総データ量(以下、単に総データ量と称す)を集計する。特に集計部130は、時間帯ごとに、情報処理システム2の外部のIPアドレスを始点IPアドレスとし負荷管理装置1010のIPアドレスを終点IPアドレスとするパケットのデータ量を集計し、負荷管理装置1010のIPアドレスを始点IPアドレスとし情報処理システム2の外部のIPアドレスを終点IPアドレスとするパケットのデータ量を集計し、それぞれの集計結果を足し合わせて総データ量を得る。
集計部130は、集計結果を第1指標保持部108に登録する。
図6は、第1指標保持部108に保持されるデータの一例を示すデータ構造図である。第1指標保持部108は、登録ノードのノード名228と、登録ノードの本来用途230と、本来用途に対応するポート番号である主なポート番号232と、本来用途データ量234と、非本来用途データ量236と、集計部130で使用される所定の長さの期間すなわち時間帯に対応する計測期間238と、を対応付けて保持する。
本来用途データ量234は、登録ノードの本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
非本来用途データ量236は、登録ノードの非本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
なお、負荷管理装置1010については本来用途データ量として総データ量が保持されることは上述の通りである。
図3に戻る。使用状況取得部110は、内部ネットワーク3を通じて所定の時間間隔もしくはリアルタイムで、情報処理システム2のノードから、そのノードの使用状況に関する情報を取得する。ノードの使用状況は、例えばノードがフロントエンドサーバ(WEBサーバ)1024やアプリケーションサーバ1026であれば消費電力(単位はW)や機器の温度(単位は℃)やCPU使用率(単位は%)であり、ノードがデータベースサーバ1028であればデータ転送量(単位はMB/秒)や消費電力や機器の温度であり、ノードが負荷管理装置1010などのネットワーク機器であればデータ転送量や消費電力や機器の温度である。
使用状況取得部110は、サーバの基本OSに搭載されているシステムパフォーマンスモニタのデータを取得してもよい。
使用状況取得部110は、各ノードに電力を供給するバスバー方式のテーブルタップ型のPDUから各ノードに供給された電力の計測値を消費電力として取得してもよい。
使用状況取得部110は、ノードの温度を計測できる市販の装置(温度センサや、光ファイバ方式の温度センサ)と、その温度データを記憶して報告するデータ収集機能(市販されているソフトウエアパッケージ、またはサーバ組み込み型の特殊ハードウエアパッケージ)と、を利用して機器の温度を取得してもよい。
あるいはまた、使用状況取得部110は、米国EPAのEnergy Star for Server 2で登録し認定されるノードからは、下記の3つの報告機能を使用して消費電力と機器の温度とCPU使用率とを取得する。すなわち、米国のEPAが行っているEnergy Star for Server 2では、登録し認定される機器は、3つの報告機能をハードウエア本体のマイクロコード(ファームウエア)のレベルで提供でき、基本OSや他の計測ソフト、アプリケーションや本来のサーバの処理能力(本体のCPU・MPU(Micro Processing Unit))には、影響を与えないハードウエアの管理機能を持つこととされている。この3つの報告機能は、1)サーバの実電力消費数値、2)サーバの本体CPU・MPU等の処理用プロセッサの使用率、3)サーバの実稼動の温度、である。
使用状況取得部110は、取得した使用状況に関する情報と、それを取得した時刻に対応する時間帯と、取得先のノード名と、IPアドレスと、を対応付けて使用状況保持部112に登録する。使用状況取得部110が所定の時間間隔で情報を取得する場合は、時間帯は例えば取得した時刻から所定の時間間隔が経過するまでの期間に設定される。あるいはまた、使用状況取得部110がリアルタイムで情報を取得する場合は、所定の長さを有する期間を時間帯とし、使用状況に関する情報をその期間で時間平均する。
図7は、使用状況保持部112に保持されるデータの一例を示すデータ構造図である。使用状況保持部112は、使用状況取得部110によって使用状況が取得されたノードのノード名244と、IPアドレス245と、使用状況が取得された時刻に対応する記録時間帯246と、取得された消費電力248と、取得された機器温度250と、取得されたCPU使用率252と、取得されたデータ転送量253と、を対応付けて保持する。
一般的に、WEBサーバにおいて、所定の量、例えば1kBのWEB通信用のデータを処理して送るにはどれだけのCPU使用率が必要かは測定できる。つまり、WEBサーバについて、WEB通信用のデータ量とCPU使用率との関係は事前に測定できる。係数保持部114(図8で後述)はその関係を示す係数(例えば、%・分/GBの単位)を保持する。この係数が1である場合、例えば1GB分のWEB通信用のデータを処理して送るためにWEBサーバは1%のCUP使用率で1分間稼動しなければならないことを意味する。
図8は、係数保持部114に保持されるデータの一例を示すデータ構造図である。係数保持部114は、WEBサーバのサーバ名240と、係数242と、を対応付けて保持する。
図3に戻る。第1解析部116は、第1算出部134と、第2算出部136と、第1合成部142と、を含む。
第1算出部134は、第1指標保持部108に登録される登録ノードのうちWEBサーバ(以下、登録WEBサーバと称す)について、本来用途データ量すなわちWEB通信用のデータ量を対応する計測期間の長さ、例えば分を単位とする長さ、で除し、WEB通信用の時間平均データ量(例えば、GB/分の単位)を得る。第1算出部134は、係数保持部114からその登録WEBサーバに対応する係数を取得する。第1算出部134は、その登録WEBサーバについて、WEB通信用の時間平均データ量と係数とを乗算し、乗算の結果得られる値(例えば、%の単位)を、その登録WEBサーバおよび計測期間における、WEB通信に関する処理によるCPU使用率の推測値(以下、第1推測値と称す)とする。
例えば、図6の第1指標保持部108に登録されるノード名「第1フロントエンドサーバ」に着目すると、第1算出部134は、計測期間「02/15/10 11:10:00~11:20:00」におけるWEB通信用のデータ量として「500(GB)」を得る。第1算出部134は、「500(GB)」を計測期間の長さ「10(分)」で除し、WEB通信用の時間平均データ量「50(GB/分)」を得る。第1算出部134は、図8の係数保持部114を参照し、係数「1.5(%・分/GB)」を得る。第1算出部134は、WEB通信用の時間平均データ量「50(GB/分)」と係数「1.5(%・分/GB)」とを乗算し「75(%)」を得る。第1算出部134は、この値「75(%)」をノード名「第1フロントエンドサーバ」のWEBサーバにおける計測期間「02/15/10 11:10:00~11:20:00」中のWEB通信に関する処理による第1推測値とする。
第2算出部136は、第1算出部134における第1推測値の計算で対象とされた登録WEBサーバのサーバ名と計測期間とをキーとして使用状況保持部112を検索し、対応する消費電力と機器温度とCPU使用率とを抽出する。第2算出部136は、第1推測値を使用状況保持部112から抽出したCPU使用率から減じ、WEB通信に関する処理以外の処理によるCPU使用率の推測値(以下、第2推測値と称す)とする。
WEB通信に関する処理以外の処理は、例えば他の通信に関する処理や、ウイルスチェッカーによるウイルススキャンや、ハードディスクドライブへのデータの書き込みである。あるいはまた、アイドル状態にあってなにも仕事をしていないことも考えられる。
第2算出部136は、抽出された消費電力を第1推測値と第2推測値との比に分け、第1推測値に対応する値をWEB通信に関する処理のために使用された電力の推測値、第2推測値に対応する値をそうでない処理のために使用された電力の推測値とする。機器温度についても、機器温度と外気温との差を第1推測値と第2推測値との比に分ける点で同様である。
例えば、図6の第1指標保持部108に登録されるノード名「第1フロントエンドサーバ」に着目すると、第2算出部136は図7に示される使用状況保持部112から、ノード名「第1フロントエンドサーバ」と計測期間「02/15/10 11:10:00~11:20:00」とに対応する消費電力「30(W)」、機器温度「35(℃)」、CPU使用率「80(%)」を抽出する。第2算出部136は、第1推測値「75(%)」をCPU使用率「80(%)」から減じ、第2推測値「5(%)」を得る。第2算出部136は、消費電力「30(W)」を第1推測値「75(%)」と第2推測値「5(%)」との比すなわち15:1に分け、WEB通信に関する処理のために使用された電力の推測値「28(W)」とそれ以外の処理のために使用された電力の推測値「2(W)」と、を得る。
第1合成部142は、時刻およびノード名をキーとして、第1指標保持部108に保持されるデータと、使用状況保持部112に保持されるデータと、第2算出部136による計算結果(登録WEBサーバについての、WEB通信処理由来の消費電力、WEB通信処理由来の上昇温度、WEB通信処理由来のCPU使用率)と、を対応付けて第2指標保持部118に登録する。
図9は、第2指標保持部118に保持されるデータの一例を示すデータ構造図である。第2指標保持部118は、ノード名254と、本来用途256と、主なポート番号258と、本来用途データ量260と、非本来用途データ量262と、計測期間264と、消費電力266と、機器温度268と、CPU使用率270と、データ転送量271と、WEB通信由来消費電力272と、WEB通信由来上昇温度274と、WEB通信由来CPU使用率276と、を対応付けて保持する。
WEB通信由来消費電力272は、第2算出部136によって算出された、WEB通信に関する処理のために使用された電力の推測値である。WEB通信由来上昇温度274は、第2算出部136によって算出された、機器温度と外気温との差のうちWEB通信に関する処理によって上昇したと予測される分である。ここでは外気温は25(℃)とされている。WEB通信由来CPU使用率276は、第1算出部134によって算出された第1推測値である。
図3に戻る。第2解析部152は、第2指標保持部118に保持されるデータのうちWEBサーバ(フロントエンドサーバ1024)に関するデータを、使用状況取得部110における所定の時間間隔よりも長い時間間隔、例えば1ヶ月や半年の時間間隔で統計処理する。
第2解析部152は、第2指標保持部118に登録されているノードのうちWEBサーバについて、消費電力の時間平均である平均消費電力と、統計処理対象の期間内における消費電力の最高値である最高消費電力と、を算出する。
第2解析部152は、第2指標保持部118に登録されているノードのうちWEBサーバについて、WEB通信由来の消費電力の時間平均を本来用途データ量(WEB通信用のデータ量)の時間平均で除した値(例えば、W/GBの単位)を算出する。ここで算出される値は、WEB通信用の単位データ量に対する消費電力を表す電力コストである。例えばこの電力コストが1(W/GB)であることは、WEBサーバにおいて1GB分のWEB通信用のデータを処理するのに1W消費することを示す。WEB通信用のデータ量をWEBサーバに対する負荷と考えると、電力コストは、各WEBサーバにおいて同じ負荷(単位データ量)がかけられた場合にそのWEBサーバで消費される電力を示す。
第2解析部152は、サーバ名と、平均消費電力と、最高消費電力と、電力コストと、を対応付けて第3指標保持部158に登録する。
図10は、第3指標保持部158に保持されるデータの一例を示すデータ構造図である。第3指標保持部158は、サーバ名304と、平均消費電力306と、最高消費電力308と、電力コスト310と、を対応付けて保持する。
図3に戻る。表示制御部120は、第1指標保持部108、第2指標保持部118、第3指標保持部158のうちの少なくともひとつに基づき、ノードごとに各種パラメータを示す画面をモニタ140に表示させる。
指標送信部154は、第3指標保持部158に登録されているデータを負荷管理装置1010に送信する。
上述の解析装置100において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないCPUや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
(負荷管理装置1010)
図11は、負荷管理装置1010の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウェア的には、コンピュータのCPU(central processing unit)をはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
負荷管理装置1010は、稼動履歴保持部1112と、サーバ群状態保持部1114と、接続保持部1116と、要求取得部1120と、要求割当部1130と、負荷検出部1140と、状態設定部1150と、負荷予測部1160と、稼動履歴記録部1180と、を備える。
稼動履歴保持部1112は、情報処理装置1020の過去の稼動履歴を保持する。サーバ群状態保持部1114は、現在のサーバ群1022の状態を保持する。稼動履歴保持部1112およびサーバ群状態保持部1114の詳細は後述する。
接続保持部1116は、同一アクセス内のパケットは同じサーバ群1022へ送られること(以下、アクセスの同一性と称す)を保証するために設けられる。
図12は、接続保持部1116を示すデータ構造図である。接続保持部1116には、後述する接続更新部1138によってアクセスに対応するエントリが生成される。一回のアクセスに対してひとつのエントリが対応する。接続保持部1116のエントリ1118は、アクセスしてきたユーザ端末1006のIPアドレスであるユーザ端末IPアドレス1210と、負荷管理装置1010のIPアドレスである負荷管理装置IPアドレス1212と、負荷管理装置1010によってそのアクセスに割り当てられたサーバ群1022のフロントエンドサーバ1024のIPアドレスである割当サーバ群IPアドレス1214と、ユーザ端末1006が同一の場合にアクセスの異同を判別するためのシーケンス番号1216と、を有する。同一ユーザ端末1006において、異なるアクセスには異なるシーケンス番号が割り振られる。以下、サーバ群1022のフロントエンドサーバ1024のIPアドレスを単にサーバ群1022のIPアドレスと称す。
図11に戻る。要求取得部1120は、外部ネットワーク1004と接続される。要求取得部1120は、外部ネットワーク1004から到来するユーザ端末1006からのアクセスの行きパケットを取得する。この際、要求取得部1120は行きパケットに含まれる終点IPアドレスを基に自己宛のパケットであるか否かを判別する。要求取得部1120は、取得した行きパケットを要求割当部1130に渡す。
なお、本明細書において「渡す」とは、ある機能ブロックからある機能ブロックに情報要素に対する処理が移ることを意味する。要求取得部1120と要求割当部1130との間で言うと、渡すとは、例えば要求取得部1120が図示しない一時メモリを有し、取得した行きパケットをそこに蓄えた上で、要求割当部1130からの要請に応じて適宜行きパケットを一時メモリから要求割当部1130に伝達することである。また渡すとは、負荷管理装置1010が図示しない記憶領域を有し、要求取得部1120は取得した行きパケットをその記憶領域に書き込み、要求割当部1130は適宜その記憶領域から必要な行きパケットを読み出して処理することであってもよい。
要求割当部1130は、ユーザ端末1006からのアクセスの行きパケットを稼動状態にあるサーバ群のうちのひとつに割り当てる。特に傾斜配分モードでは、ユーザ端末1006からのアクセスが新規のアクセスである場合、要求割当部1130は解析装置100から取得する指標に基づいて、その新規のアクセスをサーバ群のうちのひとつに割り当てる。要求割当部1130は、同一接続判断部1132と、サーバ群選択部1134と、アドレス変換部1136と、接続更新部1138と、を含む。
同一接続判断部1132は、要求取得部1120から行きパケットを取得し、その行きパケットが新規のアクセスによるものか否かを判別する。同一接続判断部1132は、取得した行きパケットの始点IPアドレスとシーケンス番号とを読み取る。同一接続判断部1132は、読み取られた始点IPアドレスとシーケンス番号とをキーとして接続保持部1116のエントリを検索し、それらと一致するエントリが存在する場合、そのエントリに含まれる割り当てられたサーバ群の割当サーバ群IPアドレスを取得する。同一接続判断部1132は、この取得された割当サーバ群IPアドレスと行きパケットとをアドレス変換部1136に渡す。
なお、このように一致するエントリが存在する場合は、当該行きパケットは既にあるサーバ群1022(エントリの割当サーバ群IPアドレスで指定されるサーバ群1022)に割り当てられたアクセスのなかのひとつのパケットである。アドレス変換部1136は、渡された行きパケットの終点IPアドレスを、同一接続判断部1132によって接続保持部1116から取得された割当サーバ群IPアドレスに変換する。このように終点IPアドレスが変換された行きパケットはアドレス変換部1136から割当パケットとして内部ネットワーク3に送出される。
一致するエントリが存在しない場合は、同一接続判断部1132は当該行きパケットをサーバ群選択部1134に渡す。この場合は同一接続判断部1132は新規のアクセスを検知したと言うことができる。
サーバ群選択部1134は、同一接続判断部1132から新規のアクセスに対応する行きパケットを受け取ると、サーバ群状態保持部1114を参照してそのアクセスを処理させるサーバ群1022を選択する。
図13は、サーバ群状態保持部1114を示すデータ構造図である。サーバ群状態保持部1114は、サーバ群1022のIPアドレス1202と、サーバ群1022の状態1204と、サーバ群1022の稼働率1206と、を対応付けて保持する。サーバ群1022の稼働率1206は、サーバ群1022のピークアクセス数に対する現在そのサーバ群1022が処理しているアクセス数の割合を%単位で示す。この稼働率は、図示されない稼働率更新部によって、予め定められているサーバ群1022のピークアクセス数と、接続保持部1116から分かるサーバ群1022に現在割り当てられているアクセス数とから演算され更新されてもよい。あるいは、図示されない稼働率更新部が稼動状態にあるサーバ群1022から稼働率を取得し、サーバ群状態保持部1114の稼働率を更新してもよい。
図11に戻る。サーバ群選択部1134は、サーバ群状態保持部1114に登録されたサーバ群のなかからサーバ群の状態を参照して稼動状態にあるサーバ群を抽出する。要求割当部1130が省電力モードに設定されているか通常モードに設定されているか傾斜配分モードに設定されているかによって、サーバ群選択部1134が稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択するアルゴリズムは異なる。以下それぞれの場合について説明する。
1.省電力モード
省電力モードでは、サーバ群選択部1134は、稼動状態にあるサーバ群の稼働率が100%となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する。例えば図13の例では、サーバ群選択部1134は新規のアクセスを処理させるサーバ群として第3サーバ群1022cを選択する。また、例えば第1サーバ群1022a、第2サーバ群1022b、第3サーバ群1022cが稼動状態に設定されており、第1サーバ群1022aの稼働率が100%、第2サーバ群1022bの稼働率が80%、第3サーバ群1022cの稼働率が0%の場合、サーバ群選択部1134は新規のアクセスを処理させるサーバ群として第2サーバ群1022bを選択する。
2.通常モード
通常モードでは、サーバ群選択部1134は、予め情報処理システム2の管理者によって設定されている負荷分散アルゴリズムにしたがって、新規のアクセスを処理させるのに最適なサーバ群を選択する。ここで使用される負荷分散アルゴリズムは、順番にサーバ群1022が選択されるラウンドロビン方式や、処理しているアクセス数が最小のサーバ群を選択する最小接続方式や、1番早く応答しているサーバ群を選択する最速方式などの公知のアルゴリズムである。
3.傾斜配分モード
傾斜配分モードでは、サーバ群選択部1134は、解析装置100の指標送信部154から第3指標保持部158に保持されるデータを受信する。サーバ群選択部1134は受信したデータから、稼動状態にあるサーバ群のフロントエンドサーバの電力コストをそのサーバ群の電力コストとして抽出する。サーバ群選択部1134は、稼動状態にあるサーバ群から、新規のアクセスを処理させるサーバ群として電力コストが小さいサーバ群を優先的に選択する。
サーバ群選択部1134は、選択されたサーバ群のIPアドレスと新規のアクセスに対応する行きパケットとをアドレス変換部1136に渡す。アドレス変換部1136は、渡された行きパケットの終点IPアドレスを、サーバ群選択部1134によって選択されたサーバ群のIPアドレスに変換する。このように終点IPアドレスが変換された行きパケットはアドレス変換部1136から割当パケットとして内部ネットワーク3に送出される。
接続更新部1138は、サーバ群選択部1134で新規のアクセスに対してサーバ群1022の選択が行われる毎に、その選択に関する情報をサーバ群選択部1134から取得し、接続保持部1116に対応するエントリを追加する。この選択に関する情報は、新規のアクセスを行ったユーザのユーザ端末1006のユーザ端末IPアドレスと、負荷管理装置IPアドレスと、新規のアクセスに対して選択されたサーバ群の割当サーバ群IPアドレスと、シーケンス番号と、を含む。
また、接続更新部1138は、適宜不要となったエントリを削除する。
負荷検出部1140は、要求取得部1120によって取得されたアクセスのアクセス数を周期的に検出する。負荷検出部1140は、接続保持部1116を参照してエントリの数をカウントすることで、所定の時間間隔で情報処理装置1020全体へのアクセス数(以下、全アクセス数と称す)を取得する。また負荷検出部1140は、要求取得部1120と要求割当部1130との間の行きパケットの流れを監視し、所定の時間間隔でアクセスの数をカウントし、そのカウント数から単位時間当たりのアクセスの数、つまりアクセス数を導出してもよい。なお、負荷検出部1140は要求取得部1120の前段や要求割当部1130の後段など、負荷管理装置1010の任意の箇所で負荷を監視してもよい。負荷検出部1140は、検出した全アクセス数を状態設定部1150の負荷比較部1152に渡す。
負荷検出部1140における上述の時間間隔は負荷管理装置1010のモードを更新する基準となる時間間隔であり、アクセス数の変動率に基づいて定められる。負荷検出部1140は図示しない時間間隔設定部を有し、時間間隔設定部はアクセス数の変動率を監視し、変動率が大きいほど時間間隔を短く設定する。これにより、より適応的なサーバ群状態の制御が可能となる。また、処理を簡素化するという観点からは時間間隔は情報処理システム2の管理者によって予め定められてもよい。
状態設定部1150は、全アクセス数が所定のアクセスしきい値Moより少ない場合もしくは解析装置100から得られる総データ量が所定のデータ量しきい値Doより少ない場合、情報処理装置1020に含まれる少なくともひとつのサーバ群1022を省電力状態に設定する。
状態設定部1150におけるアクセスしきい値Moまたはデータ量しきい値Doは、情報処理装置1020の性能が落ちない範囲に設定される。ここで性能とは、例えばどれだけのアクセス数をどの程度の速さで処理できるかということである。あるいは性能とは、ひとつのアクセスが処理されるのにかかる時間などのレスポンスタイムであってもよい。また、情報処理装置1020の性能が落ちる、とは、例えばあるサーバ群1022に対してピークアクセス数を越える数のアクセスが割り当てられ、その結果そのサーバ群1022の処理速度が落ちることにより情報処理装置1020全体のアクセスの処理速度が落ちることである。
例えば第1サーバ群1022aから第5サーバ群1022eのピークアクセス数が全て2000であるとする。この場合アクセスしきい値Moを9000に設定すると、全アクセス数が8500であっても少なくともひとつのサーバ群1022を省電力状態に設定しなくてはならない。ここでは第5サーバ群1022eを省電力状態に設定したとする。残りの4つのサーバ群1022a〜1022dのトータルのピークアクセス数は8000であり、全アクセス数9500よりも少ない。したがってこの場合残りの4つのサーバ群1022a〜1022dのうちの少なくともひとつのサーバ群はピークアクセス数以上のアクセスを処理しなくてはならずそのサーバ群の処理速度は低下する。これにより情報処理装置1020全体の処理速度が落ちることとなる。このような状況を避けるために、アクセスしきい値Moまたはデータ量しきい値Doは情報処理装置1020の性能が落ちない範囲に設定される。上述の例ではアクセスしきい値Moは8000以下に設定されればよい。
状態設定部1150は、サーバ群1022の最大性能を発揮せしめる前提で、要求取得部1120によって取得されたアクセスを処理させるサーバ群を選択し、残りのサーバ群を省電力状態に設定する。この場合サーバ群1022の最大性能を発揮せしめる、とは、例えばサーバ群1022にピークアクセス数でアクセス処理を行わせることであり、言い換えるとサーバ群1022を100%の稼働率で使用することである。さらに状態設定部1150は、全アクセス数または総データ量の変動により情報処理装置1020の性能が落ちると予測される場合には、省電力状態に設定されている少なくともひとつのサーバ群を稼動状態に設定する。
サーバ群1022を省電力状態または稼動状態に設定することに関して、状態設定部1150では、稼動状態にするサーバ群の数に応じた全アクセス数の範囲または総データ量の範囲が定められている。状態設定部1150は例えば全アクセス数が0から第1しきい値T1の範囲にあればひとつのサーバ群のみを稼動状態とし、他のサーバ群を省電力状態とする。表1は、状態設定部1150における状態設定に関して、稼動状態とするサーバ群の数と、OS休眠状態とするサーバ群の数と、電源オフ状態とするサーバ群の数と、全アクセス数の範囲と、の関係を示す。T2は第2しきい値、T3は第3しきい値であり、T1<T2<T3である。個々のしきい値は予め情報処理システム2の管理者によって設定される。
第1しきい値T1、第2しきい値T2、第3しきい値T3はそれぞれサーバ群1022を100%の稼働率で使用することを前提に設定される。つまり上述の第1サーバ群1022aから第5サーバ群1022eのピークアクセス数が全て2000であるとする例では、T1=2000、T2=4000、T3=6000である。この場合、全アクセス数のアクセスを処理するのに必要最低限の数のサーバ群が稼動状態とされる。また、例えば第1しきい値T1と第2しきい値T2との間にあった全アクセス数が増大して第2しきい値T2を越えた場合、そのままだと少なくともひとつのサーバ群の稼働率が100%を上回ると予測されるので、稼動状態とするサーバ群の数をひとつ増やして情報処理装置1020の処理速度の低下を回避する。
状態設定部1150は、負荷比較部1152と、稼動サーバ群決定部1154と、状態信号生成部1156と、を含む。
負荷比較部1152は、全アクセス数を使用するアクセス数モードと、総データ量を使用するデータ量モードと、を有する。
負荷比較部1152は、全アクセス数モードでは、負荷検出部1140から取得した全アクセス数と、第1しきい値T1、第2しきい値T2、第3しきい値T3、アクセスしきい値Moとの大小関係を判別する。この大小関係は例えば「T2<全アクセス数<T3」という情報である。負荷比較部1152はこの大小関係に関する情報を稼動サーバ群決定部1154に渡す。
負荷比較部1152は、総データ量モードでは、解析装置100から第1指標保持部108に保持される総データ量を取得する。負荷比較部1152は、取得した総データ量について上記の全アクセス数の場合と同様に大小関係を判別し、判別された大小関係に関する情報を稼動サーバ群決定部1154に渡す。
稼動サーバ群決定部1154は、負荷比較部1152から渡された情報が全アクセス数についての大小関係に関する情報であれば、その情報を基に表1のストラテジにしたがい、サーバ群1022の状態の切替の必要性を判別する。稼動サーバ群決定部1154は、負荷比較部1152から渡された情報が総データ量についての大小関係に関する情報であれば、その情報を基に表1と同様のストラテジにしたがい、サーバ群1022の状態の切替の必要性を判別する。
稼動サーバ群決定部1154は、サーバ群1022の状態の切替が必要な場合には、解析装置100から取得する指標に基づいて、稼動状態とするサーバ群とOS休眠状態とするサーバ群と電源オフ状態とするサーバ群を選択する。
稼動サーバ群決定部1154はこの選択に基づきサーバ群状態保持部1114を更新する。稼動サーバ群決定部1154は、状態の切り替えが必要なサーバ群1022の情報を状態信号生成部1156に渡す。稼動サーバ群決定部1154は、状態の切り替えが必要ない場合には処理を中断または終了し、次の情報を待ち受ける。
稼動サーバ群決定部1154は、全アクセス数についての表1のストラテジまたは総データ量についての同様のストラテジから稼動状態、OS休眠状態および電源オフ状態とするサーバ群の数をまず決める。次に稼動サーバ群決定部1154はサーバ群状態保持部1114を参照し、サーバ群1022の状態を切り替える必要があるか、言い換えると負荷検出部1140が取得した全アクセス数または解析装置100から取得した総データ量に対応する各状態のサーバ群の数とサーバ群状態保持部1114に登録されている現在の各状態のサーバ群の数とが一致するか否かを判断する。そこで一致する場合は稼動サーバ群決定部1154は処理を中断または終了する。
一致しない場合は、稼動サーバ群決定部1154はそれぞれの状態にするサーバ群を決める。稼動サーバ群決定部1154は、解析装置100の指標送信部154から第3指標保持部158に保持されるデータを受信する。稼動サーバ群決定部1154は、受信したデータを基に各サーバ群1022に対して省電力状態とされる順番を示す省エネ停止可能順位を設定する。省エネ停止可能順位は「1」が最も高く、数が増えるにつれて低くなる順位である。
稼動サーバ群決定部1154では、第3指標保持部158に保持されるフロントエンドサーバ1024の平均消費電力、最高消費電力、電力コストを、そのフロントエンドサーバ1024が属するサーバ群1022の平均消費電力、最高消費電力、電力コストのそれぞれとみなす。
表2は、サーバ群1022の電力コストに基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
表2のストラテジでは、サーバ群1022の電力コストが大きいほど優先的にそのサーバ群1022が省電力状態とされるように省エネ停止可能順位が設定される。電力コストが遜色ない2つのサーバ群が存在する場合は、平均消費電力や最高消費電力が高いほうのサーバ群の省エネ停止可能順位をより高く設定する(表2の第4サーバ群と第5サーバ群)。
表3は、サーバ群1022の消費電力に基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
表3のストラテジでは、サーバ群1022の平均消費電力と最高消費電力との和が大きいほど優先的にそのサーバ群1022が省電力状態とされるように省エネ停止可能順位が設定される。
情報処理装置1020において各サーバ群1022が主にWEB通信をおこなっており他の用途の処理は無視できる程度であり、また要求割当部1130において稼動状態にあるサーバ群にアクセスが均等に割り当てられる設定となっている場合は、稼動状態にあるサーバ群には同じ負荷がかけられれていると考えることができる。したがって、稼動状態にある各サーバ群の平均消費電力は、同じ負荷がかけられれている場合に消費される電力の平均値と同一視することができ、また、稼動状態にある各サーバ群の最高消費電力は、同じ負荷がかけられれている場合に消費される電力の最高値と同一視することができる。この場合、表3のストラテジでは、サーバ群1022に同じ負荷がかけられた場合に消費される電力が大きいほど優先的にそのサーバ群1022が省電力状態とされるように省エネ停止可能順位が設定されているといえる。
稼動サーバ群決定部1154は、稼動状態にあるサーバ群のひとつを省電力状態に切り替える必要がある場合、稼動状態にあるサーバ群のうち表2または表3で設定される省エネ停止可能順位が最も高いサーバ群を省電力状態とすべきサーバ群として選択する。
稼動サーバ群決定部1154は、省電力状態にあるサーバ群のひとつを稼動状態に切り替える必要がある場合、省電力状態にあるサーバ群のうち表2または表3で設定される省エネ停止可能順位が最も低いサーバ群を稼動状態とすべきサーバ群として選択する。
なお、稼動サーバ群決定部1154でのサーバ群1022を決める上述のアルゴリズムでは、特に稼動状態を省電力状態に切り替える場合は、アクセスの同一性が考慮されてもよい。つまり、稼動サーバ群決定部1154は、接続保持部1116を参照し、省電力状態に切り替えるべきサーバ群へのアクセスがなくなるまで待機する。稼動サーバ群決定部1154はそのようなアクセスがなくなると、省電力状態に切り替えるべきサーバ群の情報を状態信号生成部1156に渡す。これによりアクセスの同一性が保証されうる。
状態信号生成部1156は、状態の切り替えが必要なサーバ群の情報に基づきそのサーバ群に対して切替に対応する休眠導入信号、休眠解除信号、電源オフ信号、および電源オン信号のうちのいずれかを送る。例えば第3サーバ群1022cを稼動状態(OS休眠状態)からOS休眠状態(稼動状態)とする必要がある場合、状態信号生成部1156は第3サーバ群1022cに対して休眠導入信号(休眠解除信号)を内部ネットワーク3を介して送出する。また、第3サーバ群1022cを稼動状態(電源オフ状態)から電源オフ状態(稼動状態)とする必要がある場合、状態信号生成部1156は第3サーバ群1022cに対して電源オフ信号(電源オン信号)を内部ネットワーク3を介して送出する。
状態信号生成部1156によって省電力状態から稼動状態に設定されたサーバ群は、それが稼動状態であることが稼動サーバ群決定部1154によってサーバ群状態保持部1114に記録されるので、要求割当部1130によって新規のアクセスが割り当てられる。
負荷管理装置1010は、負荷検出部1140で検出された全アクセス数または解析装置100から取得する総データ量を基に状態設定部1150でサーバ群1022の状態を適応的に設定する検出モードの他に、過去の稼動履歴を基に予測されたアクセス数(以下、予測アクセス数と称す)を基に状態設定部1150でサーバ群1022の状態を設定する負荷予測モードを有する。以下、この負荷予測モードについて説明する。
稼動履歴記録部1180は、定期的に情報処理装置1020に含まれるサーバ群1022a〜22eの稼動履歴を稼動履歴保持部1112に記録する。稼動履歴記録部1180は、例えば15分に1度サーバ群状態保持部1114を参照してその時点での各サーバ群1022の状態と稼働率とを取得する。また稼動履歴記録部1180はその時点で負荷検出部1140によって検出された全アクセス数を取得する。稼動履歴記録部1180はそれらの情報を稼動履歴保持部1112に書き込む。
図14は、稼動履歴保持部1112を示すデータ構造図である。稼動履歴保持部1112は、日時1218と、アクセス数1220と、稼動サーバ群の数1222と、平均稼働率1224と、を対応付けて保持する。日時1218は、暦の上での日時である。稼動サーバ群の数1222は、その日時に稼動状態にあったサーバ群の数である。平均稼働率1224は、稼動状態にあったサーバ群の稼働率の平均値である。
図11に戻る。負荷予測部1160は、過去の稼動履歴を基に負荷を予測する。負荷予測部1160は、稼動履歴保持部1112を参照し、予測対象の時間帯に対して一年以上前の同月同日の同じ時間帯の稼動履歴を取得し、これを基に予測対象の時間帯の予測アクセス数を決定する。例えば、負荷予測部1160が2009年7月28日の9:15〜9:30におけるアクセス数を予測する場合、負荷予測部1160は2008年7月28日の9:15〜9:30におけるアクセス数(図14の場合、5400)を稼動履歴保持部1112から取得し、それを予測アクセス数とする。この予測アクセス数の取得は、負荷検出部1140における時間間隔と同様の時間間隔で行われる。
負荷予測部1160は予測アクセス数を負荷比較部1152に渡す。状態設定部1150は、負荷予測部1160から予測アクセス数が負荷比較部1152に渡された場合、この予測アクセス数を全アクセス数と読み替えて上述した処理を行う。
上述の負荷管理装置1010において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないCPUや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
以上の構成による情報処理システム2の動作を説明する。図15は、解析装置100における一連の処理を示すフローチャートである。傍受部122は、ネットワークからパケットを傍受する(S402)。抽出部124は、傍受されたパケットから始点アドレスとポート番号とを抽出する(S404)。登録部128は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部104に登録する(S406)。分類部132は、通信情報保持部104に保持されるデータを始点アドレスでソーティングする(S408)。分類部132は、ソーティングされたデータを本来用途と非本来用途とに分類する(S410)。集計部130は、分類されたデータを集計する(S412)。第2解析部152は、集計結果から各サーバ群1022の電力コストを算出する(S414)。
図16は、負荷管理装置1010における一連の処理を示すフローチャートである。図16では、要求取得部1120と、負荷検出部1140と、状態設定部1150とで行われる処理についてのフローチャートを示すが、それと平行して要求割当部1130がサーバ群状態保持部1114を参照して新規のアクセスのサーバ群1022への割り当てを行っていることは上述の通りである。また、負荷比較部1152ではアクセス数モードが使用される場合を考える。
要求取得部1120は、外部ネットワーク1004からアクセスを取得する(S702)。負荷検出部1140は、全アクセス数を検出する(S704)。状態設定部1150は、全アクセス数とアクセスしきい値Mo、第1しきい値T1、第2しきい値T2、第3しきい値T3との大小比較を行う(S706)。状態設定部1150は、その大小比較を基にサーバ群1022の状態の切替が必要か否かを判断する(S708)。状態の切替が必要でない場合(S708のN)、処理をアクセス取得ステップS702に戻す。状態の切替が必要な場合(S708のY)、状態設定部1150は稼動状態のサーバ群の数を増やすか減らすかを判断する(S710)。減らす必要がある場合(S710の減らす)、状態設定部1150は、省エネ停止可能順位が最も高い稼動状態のサーバ群を省電力状態に設定する(S712)。増やす必要がある場合(S710の増やす)、状態設定部1150は省エネ停止可能順位が最も低い省電力状態のサーバ群を稼動状態に設定する(S714)。負荷管理装置1010はこの処理を所定の時間間隔で繰り返す。
本実施の形態に係る情報処理システム2によると、負荷管理装置1010は全アクセス数または総データ量に応じて適応的に稼動状態とするサーバ群を選択し、残りのサーバ群を省電力状態に設定する。ユーザからのアクセスは稼動状態にあるサーバ群のうちのひとつのサーバ群に割り当てられ、そこで処理される。現時点でのアクセス数を処理するのに不必要なサーバ群は省電力状態とされる。したがって、省電力状態としたサーバ群の待機電力分だけ情報処理システム2全体の消費電力を低減できる。また、アクセス数の増大により情報処理システム2の処理能力を増やす必要が出てくると、負荷管理装置1010は稼動状態とするサーバ群の数を増やす。
これに加えて、解析装置100はネットワークを傍受して各サーバ群1022の特性の違いを示す指標を算出し、負荷管理装置1010は解析装置100によって算出されたこの指標に基づいて、複数のサーバ群1022の状態を制御する。したがって、各サーバ群1022の特性の違い合わせてサーバ群1022の状態が制御できるので、情報処理システム2の省エネ化を一層進めることができる。
また、本実施の形態では、負荷管理装置1010は解析装置100によって計測された総データ量がデータ量しきい値Doより少ない場合、情報処理装置1020に含まれるサーバ群1022のうちの少なくともひとつのサーバ群を省電力状態に設定する。したがって、負荷管理装置1010自身が負荷検出機能を有しない場合でも、解析装置100から負荷を取得できる。
また、本実施の形態では、稼動サーバ群決定部1154は負荷が所定の値より少ない場合、解析装置100によって算出された指標に基づいて、稼動状態に設定されている複数のサーバ群のうちアクセスを処理する必要のない少なくともひとつのサーバ群を選択する。状態信号生成部1156は、稼動サーバ群決定部1154によって選択された少なくともひとつのサーバ群を省電力状態に設定する。
したがって、解析装置100による各サーバ群1022の特性の違いの解析結果を取り入れた形で、稼動状態にあるサーバ群のなかから省電力状態とするサーバ群を選択できる。これにより、全てのサーバ群1022を特性上同等と見なした上で省電力状態とするサーバ群を選択する場合と比べて、選択に各サーバ群1022の特性の違いを反映できるので、省エネの観点からより好適なサーバ群1022の状態制御が可能となる。
また、稼動サーバ群決定部1154は、電力コストが大きいサーバ群を省電力状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム2全体で見たときに有効な仕事をより少ない消費電力で処理できる。
また、本実施の形態では、負荷管理装置1010は、解析装置100によって算出された指標に基づいて、取得されたアクセスを複数のサーバ群1022のうちの少なくともひとつに割り当てる。したがって、解析装置100による各サーバ群1022の特性の違いの解析結果を取り入れた形で、アクセスを分配できる。これにより、全てのサーバ群1022を特性上同等と見なした上でアクセスを割り当てる場合と比べて、割り当てに各サーバ群1022の特性の違いを反映できるので、省エネの観点からより好適な負荷分散が可能となる。
また、負荷管理装置1010は、取得されたアクセスを、電力コストが小さいサーバ群に優先的に割り当てる。したがって、結果としてアクセスがより多く割り当てられるサーバ群の電力コストは、そうでないサーバ群の電力コストよりも小さくなるので、情報処理システム2全体で見たときに有効な仕事をより少ない消費電力で処理できる。
また、本実施の形態では、稼動サーバ群決定部1154は、負荷が所定の値より多くなると予測される場合には、解析装置100によって算出された指標に基づいて、省電力状態に設定されている複数のサーバ群のうちの少なくともひとつのサーバ群を選択する。状態信号生成部1156は、稼動サーバ群決定部1154によって選択された少なくともひとつのサーバ群を稼動状態に設定する。
したがって、解析装置100による各サーバ群1022の特性の違いの解析結果を取り入れた形で、省電力状態にあるサーバ群のなかから稼動状態とするサーバ群を選択できる。これにより、全てのサーバ群を特性上同等と見なした上で稼動状態とするサーバ群を選択する場合と比べて、選択に各サーバ群1022の特性の違いを反映できるので、省エネの観点からより好適なサーバ群1022の状態制御が可能となる。
また、稼動サーバ群決定部1154は、電力コストが小さいサーバ群を稼動状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム2全体で見たときに有効な仕事をより少ない消費電力で処理できる。
図17(a)〜図17(d)は、全アクセス数に対する各サーバ群1022の稼働率の一例を示すグラフである。ここでは、第1サーバ群1022aから第5サーバ群1022eのピークアクセス数が全て2000であるとする。また、稼動サーバ群決定部1154では表2のストラテジが使用され、サーバ群選択部1134では傾斜配分モードが使用される場合を考える。
図17(a)〜図17(d)はそれぞれ全アクセス数が1600、2800、4400、7000の場合に対応する。図17(a)〜図17(d)において「△」はOS休眠状態を示し、「×」は電源オフ状態を示す。
図17(a)では、第1サーバ群1022aのみが稼動状態とされ、第4サーバ群1022dはOS休眠状態とされ、第3サーバ群1022cと、第4サーバ群1022dと、第5サーバ群1022eと、は電源オフ状態とされる。図17(b)では、第5サーバ群1022eはOS休眠状態とされ、第2サーバ群1022bと、第3サーバ群1022cと、は電源オフ状態とされる。図17(c)では、第3サーバ群1022cはOS休眠状態とされ、第2サーバ群1022bは電源オフ状態とされる。図17(d)では、第2サーバ群1022bはOS休眠状態とされる。
本実施の形態に係る情報処理システム2の負荷管理装置1010によると、負荷に応じて情報処理装置1020に含まれるサーバ群1022が省電力状態に設定される。上述した通り稼動状態のサーバ群の消費電力は、アイドル状態であってもピーク時のおよそ60%である。これに対して省電力状態のサーバ群の消費電力はピーク時のおよそ0〜10%である。したがって、本実施の形態では、負荷分散を実現しつつ、負荷が少なくアクセスを処理する必要のないサーバ群がある場合はそれらのサーバ群をアイドル状態ではなく省電力状態としている。これにより、情報処理装置1020全体の消費電力を低減でき、電力の無駄遣いを抑え、省エネ化を図ることができる。
また、稼動サーバ群決定部1154は接続保持部1116を参照してアクセスの同一性を保証し、サーバ群選択部1134はサーバ群状態保持部1114を参照して現在稼動状態にあるサーバ群を判別している。このように本実施の形態では状態切替機能と負荷分散機能とがひとつの負荷管理装置1010で実現されているので、アクセスの同一性が必要な場合はそれをより容易に保証でき、また省電力状態にあるサーバ群に誤ってパケットを送信してしまう可能性を低減できる。
本実施の形態に係る負荷管理装置1010では、全アクセス数<アクセスしきい値Moとなる場合、表1に示される通りOS休眠状態とするサーバ群と電源オフ状態とするサーバ群との両方を設けている。これにより、突然の全アクセス数の増大に対しては、復帰のためのオーバヘッドが小さいOS休眠状態にあるサーバ群を稼動状態に戻すことで対応できる。また、そのように対応できる限りにおいては他のサーバ群は電力を消費しない電源オフ状態とし、情報処理装置1020全体の消費電力をさらに低減している。なお、表1ではOS休眠状態とするサーバ群をひとつだけ確保しているが、この数はオーバヘッドと消費電力とのかねあいで定められればよく、適宜増減可能であることは本明細書に触れた当業者には理解される。
本実施の形態に係る負荷管理装置1010では、状態設定部1150はサーバ群1022の最大性能を発揮せしめる前提で稼動状態とするサーバ群を決定する。このサーバ群1022の決定方式によると、所与の負荷に対してより多くの数のサーバ群1022を省電力状態とすることができる。したがって、情報処理装置1020全体の消費電力をより低減できる。なお、稼働率によってサーバ群1022の消費電力が異なるのも事実ではあるが、上述の通りアイドル状態でもピーク時のおよそ60%の電力が消費されることを考えると、稼働率を下げることによる電力削減効果よりもアイドル状態を省電力状態とすることによる電力削減効果のほうが大きいと考えられる。
また、アクセスしきい値Moは情報処理装置1020の性能が落ちない範囲に設定される。これにより、負荷が多い場合は通常モードで情報処理装置1020の並列処理能力をいかんなく発揮させ、負荷が少なくなると省電力モードに移行させて性能を保ちつつ電力消費量を低減できる。
また、状態設定部1150は負荷の変動により情報処理装置1020の性能が落ちると予測される場合には、省電力状態にあるサーバ群を稼動状態に設定する。これにより、サーバ群1022をピークアクセス数以上で使用しなければならない状況を回避し、アクセス処理の遅滞を避けることができる。
また、負荷予測部1160は過去の稼動履歴を基にアクセス数を予測し、状態設定部1150はその予測値に基づいてサーバ群1022の状態を設定する。つまり負荷管理装置1010は、情報処理システム2の運用の実態を日時、曜日、祭日等のカレンダー区分にて、外部ネットワーク1004側から発生するアクセス数の傾向情報を過去にさかのぼり蓄積し、その情報を元に運用に該当する日時に予測されるアクセス数を算出する学習機能と、その運用時間帯特異のアクセス数の予測を元に必要な稼動状態サーバ群の数を推測し、必要台数のサーバ群を稼動状態にする機能と、を有する。
これらの機能は特に情報処理システム2がネットワーク接続型のデータセンタである場合に有益である。これは以下の本発明者の当業者としての知見に基づく。
日々の運用では、ネットワーク接続型のデータセンタの運用では、運用されているアプリケーションシステムにより、稼働率やアクセス数の傾向が把握できる。これは、例えば、インターネット検索を主としているアプリケーションサーバ群では、平日より休日の利用が多く、平日でも、午前より午後、夕方から夜までの利用が多いと言える。また、証券取引所接続の証券会社のインターネット株取引システムでは、証券取引所の運用時間帯に多くの取引による仕事量があり、取引所が取引を閉じている夕方から朝、土日と祝祭日には仕事量は少ない。取引所が閉まっている時間帯では、証券会社の顧客は主に個々の口座の情報を参照するなどのアクセスを行うので取引時間帯より仕事量は低い。
これらの日々の運用実績のデータを基に、特定の運用日の特定の時間帯に予測される外部ネットワーク1004よりの仕事量が予測出来ることに本発明者は想到した。証券会社の取引システムのサーバ群は、取引所の運用の時間外は、負荷管理装置1010により運用に必要なサーバ群の数を予測し、不必要なサーバ群の電源を切るとかOSを休眠させることで消費電力を低減できる。仮に、この予測に反して仕事量が多くなった場合は、省電力状態(電源オフ状態か、OS休眠状態)のサーバ群をその仕事量に応じて稼動状態とすることにより、多くなった仕事量を分散させる事ができる。
本実施の形態に係る情報処理システム2に含まれる解析装置100によると、パケットをネットワークから傍受し、傍受したパケットを始点IPアドレスとポート番号とで分類する。したがって、始点IPアドレスごとおよびポート番号ごとに通信データ量を計測できる。これにより、所望の解析対象のノードについて、どの通信用途(メール通信やWEB閲覧など)に対応する仕事をどの程度行ったかを、そのノードに直接問い合わせることなしにネットワーク上を流れるパケットから追跡できる。ノードへ問い合わせないので、仕事量の解析に伴うノード側の負担はほとんどない。解析装置100はネットワークの傍受を行うので、解析装置100自身の測定への寄与は小さく、また把握できる。
IPアドレスは仕事の主体を示し、ポート番号は通信用途を示すので、解析装置100ではそれらを用いてノードで行われている仕事の内訳を導出し、特に有効仕事量を計測できる。この点、現実的に有効仕事量の計測が困難であった従来の技術とは大きく異なる。解析装置100によると、ノードにおける仕事量を解析することで、そのノードが有効な仕事をどの程度行ったかを計測でき、情報処理システム2を省エネ化するためのよい指標が得られる。
また、解析装置100では、通信情報保持部104に保持される傍受されたパケットの情報を本来用途と非本来用途とで分類する。したがって、図6の第1指標保持部108に示されるように、所望の解析対象のノードについて、本来用途データ量と非本来用途データ量とを得ることができる。これにより、両者の比率などから解析対象のノードがどの程度本来の用途で使用されているかを追跡できる。これは情報処理システム2を省エネ化するためのよい指標のひとつである。例えば、本来の用途で使用されていないノードを発見し、適切な処置を施すことでデータセンタの効率を向上できる。
また、解析装置100では、第2指標保持部118は、第1指標保持部108と使用状況保持部112とが対応付けられた形となっている。したがって、情報処理システム2の省エネ化を考える際に、ノードにおける仕事量と使用状況とを対応付けて把握できる。すなわち、ノードが何の仕事をいつどれだけ行ったことにより、どれだけのCPUの処理能力を使用し、どれだけの電力を消費し、どれだけの温度上昇があったかを解析できる。
例えば、CPU使用率が100%とされているサーバの仕事量の内訳を見ることにより、実際100%のCPU使用率のうちどれだけが有効な仕事のために使用されたかを知ることができる。100%のCPU使用率でもその大半が有効な仕事のために使用されていなければ、そのサーバは省エネ化のための検討対象とすべきである。PUE(Power Usage Effectiveness)(非特許文献1参照)などを使用する従来の技術では、仕事の内訳が見えないのでこのような判断をすることができなかったが、解析装置100を使用すると可能となる。
また例えば、消費電力および有効仕事量の両者が共に低いサーバがある場合、使用状況だけを見ていると消費電力が低いので省エネ的によいサーバに見え、このサーバに対しては何ら対策がなされない可能性が高い。しかしながら、解析装置100を使用して使用状況と仕事量とが対比可能な形で提示される場合、有効仕事量も低いことが分かるので、データセンタの効率を向上してさらなる省エネ化を進めるために、例えば仮想化により他の高負荷サーバから仕事を回す等の対策を取ることができる。したがって、データセンタの省エネ化への寄与は大きい。
また例えば、有効仕事量的には問題ないが排熱の大きなサーバがある場合にそれを見つけることができる。したがって、そのようなサーバがホットアイルに存在する場合には他の位置に移設したほうがよいことをサーバの持ち主に提案できる。
また、解析装置100では、フィルタ部126は、フィルタリングモードでは、抽出部124によって抽出された始点IPアドレスおよび終点IPアドレスを基に、計測対象のノードのIPアドレスが含まれたパケットのみを選択して、登録部128に出力する。したがって、計測に影響を与えない範囲で通信情報保持部104に保持されるデータの量を低減できる。
また、フィルタ部126は、計測対象のノードを、情報処理システム2に含まれる複数のノードから順番に選択する。つまり、一度に全てのノードを計測対象とするのではなく、例えば月曜日は第1サーバ群1022a、火曜日は第2サーバ群1022b、等のように計測対象のノードを順番に変えてゆく。これにより、計測に影響を与えない範囲で通信情報保持部104に保持されるデータの量を低減した上で、ネットワークの全てのノードを計測対象とすることができる。
仮想化が行なわれているサーバについて考える。従来では主に、親(ホスト)仮想化OSの上での個々のサーバイメージ(個々のゲストOS)のプロセッサ使用率を取得して比較する。そして、ゲストOSを他のプロセッサ使用率的に空いている仮想化ホストOSサーバへ移設させている。しかしながら、このように単にプロセッサ使用率のみを尺度として仮想化サーバ間のゲストOSの移動を行う場合には、実際にゲストOSで行われている仕事の内訳までは考慮されていない。したがって、有効仕事量に基づいた移設が行われているとは言い難い。
解析装置100を使用して仮想化されたサーバにおける仕事を解析する場合、仮想化のプラットフォームごとに仕事量が分かるので、有効仕事量に基づいた精度の高いゲストOSの移設が可能となる。
また、例えば仮想化したことによってどの程度状況が改善されているかを知ることができる。つまり、有効仕事量と消費電力とについて仮想化の前後で比較することで、改善の度合いを知ることができる。また、仮想化後は個々のゲストOSが行っている仕事についてはあまり注意されないのが現状であるが、解析装置100で各ゲストOSについて有効仕事量を追跡することにより、例えば時と共に使用されなくなったゲストOSを特定できる。したがって、そのように特定されたゲストOSを外すことで他のゲストOSの性能を改善できる。これはデータセンタの効率の向上に貢献する。
従来ではシステム運用者は、システムを運用するにあたり、主にサーバのプロセッサ使用率やメモリの利用度を使用してサーバの性能を評価し、その性能評価を軸にして、サーバの統合、アプリケーションの移設、分配、統合、サーバの更新(新しい機器に交換する・買い換える)を行っている。しかしながら、特に昨今の景気低迷期では、サーバのさらなる有効利用やさらなる消費電力の低減によって一段とデータセンタ全体の運用コストを下げることが求められている。
そこで、解析装置100を使用することにより、サーバにおける仕事が内向け(対サーバ)か、外向け(サーバ発)なのかを詳細に解析でき、また、その仕事がデータセンタ外部への仕事なのかデータセンタ内の他のサーバやアプリケーションに対する仕事なのかも解析できる。したがって、この解析を元にして、省エネ化のための精度の高いサーバ統合、分配、アプリケーション統合、分配、機器の更新、増強、廃止などが行える。
以上、実施の形態に係る情報処理システム2の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
実施の形態では、負荷管理装置1010において、ユーザ端末1006からサーバ群1022へのパケットの流れを基に説明したが、サーバ群1022からユーザ端末1006へパケットを返すときも負荷管理装置1010が適宜接続保持部1116を参照してアドレス変換できることは本明細書に触れた当業者には明らかである。
実施の形態では、負荷管理装置1010は内部ネットワーク3を介して情報処理装置1020の各サーバ群1022と通信する場合について説明したが、これに限られない。例えば、各サーバ群1022と負荷管理装置とが1対1で接続され、結果として負荷管理装置がサーバ群側に5つの入出力ポートを有してもよい。この場合、パケットはアドレス変換ではなく直接個々の入出力ポートに振り分けられてもよい。
実施の形態では、アクセスしきい値Mo、第1しきい値T1、第2しきい値T2、および第3しきい値T3が稼動状態のサーバ群の数を決めるしきい値となる場合について説明したが、これに限られない。例えば、それぞれのしきい値にヒステリシスを持たせてもよい。この場合、全アクセス数がしきい値付近で変動しても、しきい値をまたぐ毎にサーバ群1022の状態を切り替えなくてもよいので、状態切替に伴うオーバヘッドを低減できる。その結果情報処理システム2全体のレスポンスが向上しうる。
実施の形態では、サーバ群1022の状態制御について、状態設定部1150において表1に示されるストラテジが使用される場合について説明したが、これに限られない。例えば、省電力状態としてOS休眠状態を使用し、電源オフ状態を使用しなくてもよい。この場合、電源オンオフにかかる比較的長いオーバヘッドがなくなるので、より早いレスポンスが期待できる。また、処理が簡素化される。別の例としては、省電力状態として電源オフ状態を使用し、OS休眠状態を使用しなくてもよい。この場合、消費電力をより低減できる。
実施の形態では、フロントエンドサーバ1024とアプリケーションサーバ1026とデータベースサーバ1028とは別個のサーバであり、この順に直列に接続されている場合について説明したが、これに限られない。個々のサーバ群は少なくともひとつのサーバを含めばよく、例えば、サーバ群はフロントエンドサーバとアプリケーションサーバとデータベースサーバの機能を全て併せ持つ1台のサーバを含んでもよい。また、サーバ群は、それら3つのサーバの機能のうちの任意の2つの機能を併せ持つサーバと、残りの機能を持つサーバと、を含んでもよい。
実施の形態では、負荷予測部1160は予測アクセス数を負荷比較部1152に渡す場合について説明したが、これに限られない。例えば、負荷予測部1160は一年以上前の同月同日の同じ時間帯の稼動サーバ群の数を取得し、その稼動サーバ群の数を稼動サーバ群決定部1154に渡してもよい。この場合、稼動サーバ群決定部1154はこの稼動サーバ群の数を基に稼動状態にするサーバ群を決定する。
実施の形態では、要求処理ユニットがサーバ群である場合について説明したが、これに限られない。本実施の形態に係る技術思想は例えばGSLB(Global Server Load Balance)にも応用されうる。そこでは、要求処理ユニットはそれ自体が複数の並列に配されたサーバ群を有するシステムであってもよい。また、実施の形態では要求はユーザからのアクセスである場合について説明したが、これに限られず、本実施の形態に係る技術思想が適用されるシステムによって異なってもよい。要求とは処理主体への処理の指示であるとも言える。
実施の形態では、負荷管理装置1010と情報処理装置1020とが異なる装置である場合について説明したが、これに限られず、負荷管理装置1010と情報処理装置1020とが一体となっていてもよい。
実施の形態では、サーバ群1022の平均消費電力、最高消費電力、電力コストのそれぞれとして、そのサーバ群1022のフロントエンドサーバ(WEBサーバ)1024の平均消費電力、最高消費電力、電力コストを採用する場合について説明したが、これに限られない。例えば、サーバ群1022に含まれる各サーバの電力コストを算出し、それを平均した値をそのサーバ群1022の電力コストとして採用してもよい。
実施の形態では、例えば図15に示されるように、解析装置100においてパケットの傍受(S402)からデータの集計(S412)が一連の処理として行われる場合について説明したが、これに限られない。例えば、解析装置は、パケットの傍受からデータの分類までを随時行って分類結果のデータを蓄積し、所定の条件が満たされると分類結果のデータを集計してもよい。ここで所定の条件は、例えば前回の集計から所定の期間が経過したこと、もしくは分類結果のデータの量が所定の量に達したことである。
図18は、変形例に係る解析装置における一連の処理を示すフローチャートである。変形例に係る解析装置は、傍受部と、抽出部と、登録部と、通信情報保持部と、分類部と、分類結果保持部と、集計部と、を備える。傍受部は、ネットワークからパケットを傍受する(S502)。抽出部は、傍受されたパケットから始点アドレスとポート番号とを抽出する(S504)。登録部は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部に登録する(S506)。分類部は、通信情報保持部に保持されるデータを始点アドレスでソーティングする(S508)。分類部は、ソーティングされたデータを本来用途と非本来用途とに分類する(S510)。分類部は、分類結果を分類結果保持部に登録する(S512)。所定の条件が満たされていない場合(S514のN)、ステップS502に処理が戻る。これにより、所定の条件が満たされるまで分類結果が分類結果保持部に蓄積されてゆく。所定の条件が満たされた場合(S514のY)、集計部は、分類結果保持部に蓄積されたデータを集計する(S516)。
本変形例によると、所定の条件を変えることにより、集計の母集団として使用する分類結果データの量を調整できる。したがって、集計の結果得られる指標に対して求められている精度に応じて柔軟に分類結果データの量を調整できる。
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。