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