運用管理装置および情報処理システム
【課題】並列処理を行うサーバ群の消費電力を低減する。
【解決手段】運用管理装置１０１０は、複数のサーバ群がネットワークで接続されることによって構成された情報処理装置に対する総アクセス数の履歴を保持する負荷履歴保持部１１１２と、負荷履歴保持部１１１２を参照して今後発生する総アクセス数を予測する負荷予測部１１３４と、負荷予測部１１３４によって予測された総アクセス数がアクセスしきい値より少ない場合、少なくともひとつのサーバ群を省電力状態に設定する状態設定部１１４０と、ネットワークから得られる情報から、複数のサーバ群の稼動状況が示された指標を算出する指標算出部１００と、を備える。状態設定部１１４０は、指標算出部１００によって算出された指標に基づいて、省電力状態に設定するサーバ群を選択する。
【解決手段】運用管理装置１０１０は、複数のサーバ群がネットワークで接続されることによって構成された情報処理装置に対する総アクセス数の履歴を保持する負荷履歴保持部１１１２と、負荷履歴保持部１１１２を参照して今後発生する総アクセス数を予測する負荷予測部１１３４と、負荷予測部１１３４によって予測された総アクセス数がアクセスしきい値より少ない場合、少なくともひとつのサーバ群を省電力状態に設定する状態設定部１１４０と、ネットワークから得られる情報から、複数のサーバ群の稼動状況が示された指標を算出する指標算出部１００と、を備える。状態設定部１１４０は、指標算出部１００によって算出された指標に基づいて、省電力状態に設定するサーバ群を選択する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、運用管理装置および情報処理システムに関する。
【背景技術】
【０００２】
地球温暖化と言う問題が、昨今聞かれる。地球温暖化対策の一つとしては電力需要を減らすことがある。電力は一般的に水力発電、太陽光発電、風力発電、地熱発電などの自然由来の発電や、原子力を使う原子力発電や、ガス、石油、石炭などを燃料として燃やし発電を行う火力発電によって供給されている。この中でも特に火力発電は地球温暖化を進める大きな要因となっている。電力需要を減らせば火力発電の発電量も減らすことができるので、その分地球温暖化も抑止されうる。
【０００３】
ＩＴ（Information Technology）やＩＣＴ（Information and Communication Technology）の分野でも、コンピュータやネットワーク機器、データセンタ機器が消費する電力を低減する必要性が指摘され始めている。
【０００４】
近年のインターネットの普及により、多くのデータセンタは、ネットワーク接続型の形態を有しており、インターネットなどの外部のネットワークからの仕事要求を受けて処理を行う。これらのデータセンタのなかには、一度に多くのアクセスを処理するために複数の並列に配置されたサーバを備える構成を採用したものがある（特許文献１参照）。
【０００５】
このようなデータセンタを管理する運用管理システムとしては、株式会社野村総合研究所が提供する千手（登録商標）や株式会社日立製作所が提供するＯｐｅｎＴＰ１００１（登録商標）や富士通株式会社が提供するシステムウォーカーがある。
また、ネットワーク接続装置の消費電力低減装置が知られている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００８−２２５７９３号公報
【特許文献２】特開２００７−９７１２６号公報
【非特許文献】
【０００７】
【非特許文献１】The Green Grid Association、［online］、インターネット＜URL：http://www.thegreengrid.org＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
現行の運用管理システムはロードバランサを備え、アクセス数が少ない場合でも個々のサーバに要求を分散させる。そのようなロードバランサには、それに接続されているサーバに均等にアクセスを分配するものが多い。この場合、各サーバの処理能力や省エネの度合いは無視された形でアクセスが分配されうる。
【０００９】
サーバの特性について、製造年月日や機器の種類やメーカや装備（メモリ、ディスク）や電源ユニットなどの違いにより、処理能力や省エネの度合いはサーバごとに異なる場合が多い。例えば、同じＷＥＢ（World Wide Web）サーバで同じプロセスを走らせた場合でも、メーカが異なればそのプロセスで消費される電力は異なりうる。したがって、現行の運用管理システムにおけるアクセスの分配の方法は、省エネ化の観点からは必ずしも最適な方法とは言えない。
【００１０】
本発明はこうした課題に鑑みてなされたものであり、その目的は、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる運用管理技術の提供にある。
【課題を解決するための手段】
【００１１】
本発明のある態様は運用管理装置に関する。この運用管理装置は、複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求の負荷の履歴を保持する負荷履歴保持部と、負荷履歴保持部を参照して今後発生する負荷を予測する負荷予測部と、負荷予測部によって予測された負荷が所定の第１しきい値より少ない場合、少なくともひとつの要求処理ユニットを、要求を受付可能な第１状態よりも省電力の第２状態に設定する状態設定部と、ネットワークから得られる情報から、複数の要求処理ユニットの稼動状況が示された指標を算出する指標算出部と、を備える。状態設定部は、指標算出部によって算出された指標に基づいて、第２状態に設定する要求処理ユニットを選択する。
【００１２】
「要求」とは、例えば情報処理装置に対する処理の要求であってもよい。
「負荷」とは、例えば要求の量を示す値であってもよい。
【００１３】
この態様によると、指標算出部によって算出された指標に基づいて、第２状態に設定する要求処理ユニットを選択できる。
【００１４】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１５】
本発明によれば、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる。
【図面の簡単な説明】
【００１６】
【図１】実施の形態に係る運用管理装置を備える情報処理システムを示す概略図である。
【図２】図１におけるアクセスの流れを説明するための説明図である。
【図３】図１のロードバランサの機能および構成を示すブロック図である。
【図４】図３の接続保持部を示すデータ構造図である。
【図５】図３の第１サーバ群状態保持部を示すデータ構造図である。
【図６】図１の運用管理装置の機能および構成を示すブロック図である。
【図７】図６の通信情報保持部に保持されるデータの一例を示すデータ構造図である。
【図８】図６のサーバ情報保持部に保持されるデータの一例を示すデータ構造図である。
【図９】図６の第１指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１０】図６の使用状況保持部に保持されるデータの一例を示すデータ構造図である。
【図１１】図６の係数保持部に保持されるデータの一例を示すデータ構造図である。
【図１２】図６の第２指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１３】図６の第３指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１４】図６の負荷履歴保持部を示すデータ構造図である。
【図１５】図１５（ａ）〜（ｄ）は、ステータス画面の代表画面図である。
【図１６】警告画面の代表画面図である。
【図１７】状態設定画面の代表画面図である。
【図１８】図６の指標算出部における一連の処理を示すフローチャートである。
【図１９】図６の学習部および状態設定部における一連の処理を時系列に沿って示すチャートである。
【図２０】図１の情報処理システムが証券会社のインターネット株取引システムを提供するデータセンタとして使用される場合の、負荷履歴保持部の一例を示すデータ構造図である。
【図２１】図１の情報処理システムが検索サービスを提供するデータセンタとして使用される場合の、負荷履歴保持部の一例を示すデータ構造図である。
【図２２】ある実施の形態を大学の共用データセンタに適用した場合の負荷履歴保持部を示すデータ構造図である。
【図２３】変形例に係る指標算出部における一連の処理を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１８】
実施の形態に係る運用管理装置は、複数の並列に配置されたサーバ群でユーザからのアクセスを処理している情報処理システムの管理サーバとして好適に利用される。運用管理装置は、ネットワークから情報処理システム宛に到来する要求の負荷を過去の運用実績から予測し、その予測値が少ない場合は不必要なサーバ群のＯＳを休眠させたり、サーバ群の電源自体をオフにする。また、サーバ群の電力特性は使用する機種等により異なる場合があるが、運用管理装置はネットワークを傍受することにより各サーバ群の電力特性を計測する。これにより例えば電力効率が悪いサーバ群からＯＳを休眠させたり電源をオフにしたりすることができ、情報処理システムが総合的に省エネ化される。
【００１９】
図１は、実施の形態に係る運用管理装置１０１０を備える情報処理システム２を示す概略図である。情報処理システム２は、ネットワーク接続型のデータセンタであり、例えば証券会社のインターネット株取引システムを提供するデータセンタである。情報処理システム２は、運用管理装置１０１０と、情報処理装置１０２０と、ロードバランサ１０３０と、を備える。情報処理装置１０２０は、第１サーバ群１０２２ａと、第２サーバ群１０２２ｂと、第３サーバ群１０２２ｃと、第４サーバ群１０２２ｄと、第５サーバ群１０２２ｅと、を含む。第１サーバ群１０２２ａは、第１フロントエンドサーバ１０２４ａと、第１アプリケーションサーバ１０２６ａと、第１データベースサーバ１０２８ａと、を含む。第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、および第５サーバ群１０２２ｅは、それぞれ第１サーバ群１０２２ａと同等の構成を有する。
【００２０】
以下、第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、第５サーバ群１０２２ｅ、はサーバ群１０２２と総称される場合がある。また、第１フロントエンドサーバ１０２４ａ、第２フロントエンドサーバ１０２４ｂ、第３フロントエンドサーバ１０２４ｃ、第４フロントエンドサーバ１０２４ｄ、第５フロントエンドサーバ１０２４ｅ、はフロントエンドサーバ１０２４と総称される場合がある。また、第１アプリケーションサーバ１０２６ａ、第２アプリケーションサーバ１０２６ｂ、第３アプリケーションサーバ１０２６ｃ、第４アプリケーションサーバ１０２６ｄ、第５アプリケーションサーバ１０２６ｅ、はアプリケーションサーバ１０２６と総称される場合がある。また、第１データベースサーバ１０２８ａ、第２データベースサーバ１０２８ｂ、第３データベースサーバ１０２８ｃ、第４データベースサーバ１０２８ｄ、第５データベースサーバ１０２８ｅ、はデータベースサーバと総称される場合がある。
【００２１】
情報処理システム２は、外部ネットワーク１００４と接続され同じく外部ネットワーク１００４に接続されている少なくともひとつのユーザ端末１００６から要求を受ける。ここで要求とは、例えばユーザ端末１００６からのアクセスである。アクセスとは、ユーザ端末１００６と情報処理システム２のひとつのサーバ群１０２２とが接続を確立して一連の情報をやりとりすることである。異なるユーザ端末からのアクセスは異なるアクセスであり、同じユーザ端末１００６からでも異なるアクセスがなされうる。
外部ネットワーク１００４は、例えばＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネットである。ユーザ端末１００６は、ユーザが使用するコンピュータであり、例えば有線で外部ネットワーク１００４に接続された家庭用デスクトップコンピュータや、無線で外部ネットワーク１００４に接続されたラップトップコンピュータである。
【００２２】
ロードバランサ１０３０は、外部ネットワーク１００４と接続され、また情報処理装置１０２０に含まれる個々のサーバ群１０２２と内部ネットワーク３を介して接続される。ロードバランサ１０３０は、データの流れの観点からは情報処理装置１０２０と外部ネットワーク１００４との間に位置し、外部ネットワーク１００４からの情報処理装置１０２０に対するアクセスを仲介する。
ロードバランサ１０３０はさらに、情報処理装置１０２０に含まれる複数のサーバ群１０２２のうちアクセスを受付可能な状態（以下、稼動状態と称する）に設定されたサーバ群に、ユーザからのアクセスを割り当てる。なお、サーバ群１０２２の状態として、稼動状態と省電力状態とが基本的に規定される。
【００２３】
運用管理装置１０１０は、情報処理装置１０２０およびロードバランサ１０３０を管理する管理サーバである。運用管理装置１０１０は以下で説明する負荷予測機能などの他に、例えば株式会社野村総合研究所が提供する先手（登録商標）と同様のサーバ運用管理のための機能を搭載する。
【００２４】
運用管理装置１０１０は、外部ネットワーク１００４、ロードバランサ１０３０、内部ネットワーク３、のそれぞれを通過するパケットを傍受する。また運用管理装置１０１０は、各サーバ群１０２２の内部でやりとりされるパケットも傍受する。これは例えば、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とを接続するサブネットや、アプリケーションサーバ１０２６とデータベースサーバ１０２８とを接続するサブネットに解析装置１００が接続されることによって実現される。内部ネットワーク３は、各サーバ群１０２２のサーバを相互接続するこれらのサブネットを含む。
「傍受する」ことは、傍受対象のパケットを消滅させることなくその内容を取得することであってもよく、例えばパケットをそれに含まれる終点ＩＰアドレスによらずに取得することであってもよい。
運用管理装置１０１０は、傍受したパケットの内容を蓄積し、ＩＰアドレスでソートすることで各ＩＰアドレスに対応するサーバやロードバランサ１０３０における仕事の内訳を導出する。
【００２５】
運用管理装置１０１０は、例えば各サーバに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから、各サーバに供給された電力の計測値を取得し蓄積する。運用管理装置１０１０は、蓄積された電力の計測値および上記の仕事の内訳から、サーバ群１０２２の稼働状況が示された指標、例えばサーバ群１０２２における単位有効仕事量あたりの消費電力を算出する。
【００２６】
運用管理装置１０１０は、外部ネットワーク１００４から情報処理装置１０２０へのアクセスによる負荷を算出し記録する一方、過去に要求された負荷をもとに今後発生する負荷を予測する。運用管理装置１０１０は、その予測された負荷が所定の値より少なくなると、算出されたサーバ群１０２２の稼働状況が示された指標に基づいて、稼動状態にあるサーバ群のうちアクセスの処理に不要なサーバ群を選択し、選択されたサーバ群を稼動状態よりも省電力の省電力状態に設定する。
【００２７】
ここで負荷とは、例えばサーバ群１０２２が行う仕事の量を表す値であり、単位時間当たりのアクセスの数を基に定められる。例えば負荷は、単位時間当たりのアクセスの数と比例関係などの数学的関係を有する値であってもよい。また、負荷は単位時間当たりのアクセスの数に上限値または下限値若しくはその両方を課した値であってもよい。以下では、負荷が単に単位時間当たりのアクセスの数（以下、アクセス数と称す）である場合について説明する。
なお、負荷が所定の値以上の場合は運用管理装置１０１０は全てのサーバ群１０２２を稼動状態に設定する。
【００２８】
情報処理装置１０２０は、外部ネットワーク１００４からのアクセスを処理する。情報処理装置１０２０は、複数のサーバ群１０２２を含み、そのそれぞれのサーバ群１０２２はアクセスの処理単位である要求処理ユニットとして機能する。
本実施の形態では、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）プロトコルにしたがった通信が行われる場合を考える。
【００２９】
サーバ群１０２２はいわゆる３階層のサーバ群であり、これら１セットでアクセスの処理単位を構成する。フロントエンドサーバ１０２４は、ＷＥＢサーバとも呼ばれ、ＨＴＴＰ（HyperText Transfer Protocol）に則り、ユーザ端末１００６のＷＥＢブラウザに対して、ＨＴＭＬ（HyperText Markup Language）や画像などのオブジェクトの表示を提供するサービスが動作するサーバコンピュータである。アプリケーションサーバ１０２６は、フロントエンドサーバ１０２４からジャバサーブレット（Java Servlet、ジャバは登録商標）の処理などのアプリケーションに関する機能を切り出して実現するサーバコンピュータである。データベースサーバ１０２８は、アプリケーションサーバ１０２６のアプリケーションが使用するデータが格納されるサーバコンピュータである。フロントエンドサーバ１０２４、アプリケーションサーバ１０２６、およびデータベースサーバ１０２８は、公知の情報処理技術を使用して実現される。本実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている。
【００３０】
サーバ群１０２２のフロントエンドサーバ１０２４は内部ネットワーク３を介して運用管理装置１０１０およびロードバランサ１０３０と接続される。各サーバ群１０２２は運用管理装置１０１０によって管理されている。
【００３１】
なお、個々のサーバ群１０２２に含まれるサーバは個々にもしくは全体としてＯＳに管理されている。個々のサーバ群の稼動状態は、ユーザからのアクセスを即時処理可能な状態である。この状態は、サーバ群１０２２がユーザからのアクセスを処理しつつ新たなアクセスを処理可能である状態と、ユーザからのアクセスがなく仕事が発生していないアイドル状態と、を含む。稼動状態では、たとえアイドル状態であっても少なくとも基本ＯＳ機能とネットワークモニタリングのタスクは稼動しており、その分電力を消費する。本発明者の当業者としての経験から、このアイドル状態での消費電力は、サーバ機器の種類によってピークアクセス数での稼動時のおよそ３０％から７０％の範囲にある。特に、最新のブレードサーバでは、その高密度な回路構成と狭いスペースに多くの半導体素子が設置されている都合上、アイドル状態でも消費電力は大きくなる。一部のブレードサーバではアイドル状態においてピークアクセス数での稼動時の７０％もの電力を消費しているものも存在する。また、標準的なサーバ機器を用いる場合は６０％程度である。ここでピークアクセス数とは、サーバ群１０２２がその処理速度を落とさずに稼動できるアクセス数の範囲の上限値であり、サーバ群１０２２ごとにその仕様を基に予め定められている。ここで処理速度とは、サーバ群１０２２におけるユーザからのアクセスの処理速度である。
【００３２】
個々のサーバ群１０２２の省電力状態は、ユーザからのアクセスを即時処理できない状態である。この状態は、サーバ群１０２２へ電源は供給されているがそのサーバ群１０２２はユーザからのアクセスを処理できないＯＳ休眠状態を含む。サーバ群１０２２は運用管理装置１０１０から休眠導入信号を受信するとＯＳ休眠状態となる。このＯＳ休眠状態では、サーバ群１０２２のＯＳは休眠（ハイボネート）しており、ユーザからのアクセスがあってもそれを受け付けない。ＯＳ休眠状態にあるサーバ群１０２２は運用管理装置１０１０から休眠解除信号を受信すると、稼動状態に復帰する。ＯＳ休眠状態から稼動状態に復帰するためには通常数秒から数十秒かかる。また本発明者の当業者としての経験から、ＯＳ休眠状態におけるサーバ群１０２２の消費電力は、ピークアクセス数での稼働時のおよそ５％から１０％である。
【００３３】
サーバ群１０２２の省電力状態はさらに、サーバ群１０２２への電源が遮断されている電源オフ状態を含む。サーバ群１０２２は運用管理装置１０１０から電源オフ信号を受信すると電源オフ状態となる。サーバ群１０２２は運用管理装置１０１０からＷＯＬ（Wake Up on LAN）信号などの電源オン信号を受信すると、稼動状態に復帰する。電源オフ状態から稼動状態に復帰するためには通常数分かかる。
本実施の形態ではサーバ群１０２２が省電力状態から稼動状態に復帰するためにかかる時間（以下、オーバヘッドと称す）と、省電力状態で低減される消費電力とのかねあいで、省電力状態とされるサーバ群の数が決定される。つまり、現在のアクセス数を処理するのに必要なぎりぎりの数のサーバ群だけを稼動状態としていると、突然のアクセス数の増大に対して対処できなくなる可能性がある。一方で稼動状態のサーバ群の数が多いほど待機電力由来の消費電力も大きくなる。そこでそれらの影響が拮抗するように、省電力状態とされるサーバ群の数が決定される。
【００３４】
図２は、図１におけるアクセスの流れを説明するための説明図である。以下、１回のアクセスにおいて、少なくともひとつのパケットがユーザ端末１００６とアクセスが割り当てられたサーバ群との間でやりとりされる場合について説明する。このパケットは、送信元のＩＰアドレスである始点ＩＰアドレスと、受信先のＩＰアドレスである終点ＩＰアドレスと、シーケンス番号と、ポート番号と、タイムスタンプと、を含む。多くの場合において一回のアクセスにつき複数個のパケットがユーザ端末１００６とサーバ群との間を行き来する。図２では第３サーバ群１０２２ｃがアクセスに割り当てられたとする。ユーザ端末１００６のＩＰアドレスを「１７５．３４．１１．２１」、ロードバランサ１０３０のＩＰアドレスを「１００．１０．１０．１０」、第３サーバ群１０２２ｃに含まれる第３フロントエンドサーバ１０２４ｃのＩＰアドレスを「１２１．２１．１５．３」とする。
【００３５】
ロードバランサ１０３０は、ユーザ端末１００６に対して仮想サーバとして働く。つまり、外部ネットワーク１００４では、ユーザが情報処理装置１０２０が有する情報資源にアクセスしようとする場合、かかる情報資源のＵＲＬ（Uniform Resource Locator）がロードバランサ１０３０のＩＰアドレス「１００．１０．１０．１０」に名前解決されるよう設定されている。
【００３６】
まずユーザは、ユーザ端末１００６のウェブブラウザに対して情報処理装置１０２０が有する情報資源のＵＲＬを指定する。ユーザ端末１００６のウェブブラウザによって始点ＩＰアドレスを「１７５．３４．１１．２１」、終点ＩＰアドレスを「１００．１０．１０．１０」とした第１パケットＰ１が生成され、外部ネットワーク１００４に送られる。ロードバランサ１０３０は第１パケットＰ１を受信し、稼動状態にあるサーバ群のなかから第３サーバ群１０２２ｃを選択してこのアクセスを割り当てる。ロードバランサ１０３０は、第１パケットＰ１の始点ＩＰアドレスはそのままにして終点ＩＰアドレスを「１２１．２１．１５．３」とした第２パケットＰ２を内部ネットワーク３に送出する。第３サーバ群１０２２ｃの第３フロントエンドサーバ１０２４ｃは自己宛の第２パケットＰ２を受信し、第２パケットＰ２のポート番号やそのパケットに搭載されるデータに基づき処理を行う。その処理の結果ユーザ端末１００６へ戻すべき情報は、始点ＩＰアドレスを「１２１．２１．１５．３」、終点ＩＰアドレスを「１７５．３４．１１．２１」とした第３パケットＰ３に含められ、第３フロントエンドサーバ１０２４ｃから内部ネットワーク３に送出される。ロードバランサ１０３０は第３パケットＰ３を受信する。ロードバランサ１０３０は、第３パケットＰ３の終点ＩＰアドレスはそのままにして始点ＩＰアドレスを「１００．１０．１０．１０」とした第４パケットＰ４を外部ネットワーク１００４に送る。ユーザ端末１００６は自己宛の第４パケットＰ４を外部ネットワーク１００４から受信する。
以下、ユーザ端末１００６からロードバランサ１０３０に送られるパケット（第１パケットＰ１）を総称して行きパケット、ロードバランサ１０３０から情報処理装置１０２０へ送られるパケット（第２パケットＰ２）を総称して割当パケットという。
【００３７】
図３は、ロードバランサ１０３０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００３８】
ロードバランサ１０３０は、第１サーバ群状態保持部１３２２と、接続保持部１３２４と、要求取得部１０３４と、要求割当部１０３６と、を備える。
第１サーバ群状態保持部１３２２は、現在設定されているであろうサーバ群１０２２の状態を記憶するテーブルである。第１サーバ群状態保持部１３２２の詳細は後述する。
【００３９】
接続保持部１３２４は、同一アクセス内のパケットは同じサーバ群へ送られること（以下、アクセスの同一性と称す）を保証するためのテーブルである。図４は、接続保持部１３２４を示すデータ構造図である。接続保持部１３２４には、後述する接続更新部１３６８によってアクセスに対応するエントリ１１１８が生成される。一回のアクセスに対してひとつのエントリが対応する。接続保持部１３２４のエントリ１１１８は、アクセスしてきたユーザ端末１００６のＩＰアドレスであるユーザ端末ＩＰアドレス１２１０と、ロードバランサ１０３０のＩＰアドレスであるロードバランサＩＰアドレス１２１２と、ロードバランサ１０３０によってそのアクセスに割り当てられたサーバ群のフロントエンドサーバのＩＰアドレスである割当サーバ群ＩＰアドレス１２１４と、ユーザ端末１００６が同一の場合にアクセスの異同を判別するためのシーケンス番号１２１６と、を有する。同一ユーザ端末において、異なるアクセスには異なるシーケンス番号が割り振られる。以下、サーバ群のフロントエンドサーバのＩＰアドレスを単にサーバ群のＩＰアドレスと称す。
【００４０】
図３に戻る。要求取得部１０３４は、外部ネットワーク１００４と接続される。要求取得部１０３４は、外部ネットワーク１００４から到来するユーザ端末１００６からのアクセスの行きパケットを取得する。この際、要求取得部１０３４は行きパケットに含まれる終点ＩＰアドレスを基に自己宛のパケットであるか否かを判別する。要求取得部１０３４は、取得した行きパケットを要求割当部１０３６に渡す。
【００４１】
なお、本明細書において「渡す」とは、ある機能ブロックからある機能ブロックに情報要素に対する処理が移ることを意味する。要求取得部１０３４と要求割当部１０３６との間で言うと、渡すとは、例えば要求取得部１０３４が図示しない一時メモリを有し、取得した行きパケットをそこに蓄えた上で、要求割当部１０３６からの要請に応じて適宜行きパケットを一時メモリから要求割当部１０３６に伝達することである。また渡すとは、第１記憶装置１０３２が図示しない記憶領域を有し、要求取得部１０３４は取得した行きパケットをその記憶領域に書き込み、要求割当部１０３６は適宜その記憶領域から必要な行きパケットを読み出して処理することであってもよい。
【００４２】
要求割当部１０３６は、ユーザ端末１００６からのアクセスの行きパケットを稼動状態にあるサーバ群のうちのひとつに割り当てる。特に傾斜配分モードでは、ユーザ端末１００６からのアクセスが新規のアクセスである場合、要求割当部１０３６は運用管理装置１０１０から取得する指標に基づいて、その新規のアクセスをサーバ群のうちのひとつに割り当てる。要求割当部１０３６は、同一接続判断部１３６２と、サーバ群選択部１３６４と、アドレス変換部１３６６と、接続更新部１３６８と、を含む。
【００４３】
同一接続判断部１３６２は、要求取得部１０３４から行きパケットを取得し、その行きパケットが新規のアクセスによるものか否かを判別する。同一接続判断部１３６２は、取得した行きパケットの始点ＩＰアドレスとシーケンス番号とを読み取る。同一接続判断部１３６２は、読み取られた始点ＩＰアドレスとシーケンス番号とをキーとして接続保持部１３２４のエントリを検索し、それらと一致するエントリが存在する場合、そのエントリに含まれる割り当てられたサーバ群の割当サーバ群ＩＰアドレスを取得する。同一接続判断部１３６２は、この取得された割当サーバ群ＩＰアドレスと行きパケットとをアドレス変換部１３６６に渡す。
【００４４】
なお、このように一致するエントリが存在する場合は、当該行きパケットは既にあるサーバ群１０２２（エントリの割当サーバ群ＩＰアドレスで指定されるサーバ群１０２２）に割り当てられたアクセスのなかのひとつのパケットである。アドレス変換部１３６６は、渡された行きパケットの終点ＩＰアドレスを、同一接続判断部１３６２によって接続保持部１３２４から取得された割当サーバ群ＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１３６６から割当パケットとして内部ネットワーク３に送出される。
【００４５】
一致するエントリが存在しない場合は、同一接続判断部１３６２は当該行きパケットをサーバ群選択部１３６４に渡す。この場合は同一接続判断部１３６２は新規のアクセスを検知したと言うことができる。
【００４６】
サーバ群選択部１３６４は、同一接続判断部１３６２から新規のアクセスに対応する行きパケットを受け取ると、第１サーバ群状態保持部１３２２を参照してそのアクセスを処理させるサーバ群１０２２を選択する。第１サーバ群状態保持部１３２２は、運用管理装置１０１０におけるアクセス数の予測および算出される指標に基づき運用管理装置１０１０によって更新される。
【００４７】
図５は、第１サーバ群状態保持部１３２２を示すデータ構造図である。第１サーバ群状態保持部１３２２は、サーバ群１０２２のＩＰアドレス１２０２と、サーバ群１０２２の状態１２０４と、サーバ群１０２２の稼働率１２０６と、サーバ群１０２２の電力コスト１２０７と、を対応付けて保持する。
【００４８】
サーバ群１０２２の稼働率１２０６は、サーバ群１０２２のピークアクセス数に対する現在そのサーバ群１０２２が処理しているアクセス数の割合を％単位で示す。この稼働率は、図示されない稼働率更新部によって、予め定められているサーバ群１０２２のピークアクセス数と、接続保持部１３２４から分かるサーバ群１０２２に現在割り当てられているアクセス数とから演算され更新されてもよい。あるいは、図示されない稼働率更新部が稼動状態にあるサーバ群１０２２から稼働率を取得し、第１サーバ群状態保持部１３２２の稼働率を更新してもよい。あるいはまた、第１サーバ群状態保持部１３２２の稼働率は運用管理装置１０１０によって更新されてもよい。
【００４９】
サーバ群１０２２の電力コスト１２０７は、ＷＥＢ通信用の単位仕事量に対する消費電力を表す。単位仕事量は、例えば単位データ量であってもよく、１つのアクセスであってもよい。サーバ群１０２２の電力コストがＷＥＢ通信用の単位データ量に対する消費電力を表す場合、この電力コストが１（Ｗ／ＧＢ）であることは、ＷＥＢサーバにおいて１ＧＢ分のＷＥＢ通信用のデータを処理するのに１Ｗ消費することを示す。ＷＥＢ通信用のデータ量をＷＥＢサーバに対する負荷と考えると、電力コストは、各ＷＥＢサーバにおいて同じ負荷（単位データ量）がかけられた場合にそのＷＥＢサーバで消費される電力を示す。
第１サーバ群状態保持部１３２２の電力コストの値は、運用管理装置１０１０によって更新される。
【００５０】
図３に戻る。サーバ群選択部１３６４は、第１サーバ群状態保持部１３２２に登録されたサーバ群のなかからサーバ群の状態を参照して稼動状態にあるサーバ群を抽出する。要求割当部１０３６が省電力モードに設定されているか通常モードに設定されているか傾斜配分モードに設定されているかによって、サーバ群選択部１３６４が稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択するアルゴリズムは異なる。以下それぞれの場合について説明する。
【００５１】
１．省電力モード
省電力モードでは、サーバ群選択部１３６４は、稼動状態にあるサーバ群の稼働率が１００％となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する。例えば図５の例では、サーバ群選択部１３６４は新規のアクセスを処理させるサーバ群として第３サーバ群１０２２ｃを選択する。また、例えば第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃが稼動状態に設定されており、第１サーバ群１０２２ａの稼働率が１００％、第２サーバ群１０２２ｂの稼働率が８０％、第３サーバ群１０２２ｃの稼働率が０％の場合、サーバ群選択部１３６４は新規のアクセスを処理させるサーバ群として第２サーバ群１０２２ｂを選択する。
【００５２】
２．通常モード
通常モードでは、サーバ群選択部１３６４は、予め情報処理システム２の管理者によって設定されている負荷分散アルゴリズムにしたがって、新規のアクセスを処理させるのに最適なサーバ群を選択する。ここで使用される負荷分散アルゴリズムは、順番にサーバ群１０２２が選択されるラウンドロビン方式や、処理しているアクセス数が最小のサーバ群を選択する最小接続方式や、１番早く応答しているサーバ群を選択する最速方式などの公知のアルゴリズムである。
【００５３】
３．傾斜配分モード
傾斜配分モードでは、サーバ群選択部１３６４は、第１サーバ群状態保持部１３２２を参照し、稼動状態にあるサーバ群から、新規のアクセスを処理させるサーバ群として電力コストが小さいサーバ群を優先的に選択する。
【００５４】
サーバ群選択部１３６４は、は、選択されたサーバ群のＩＰアドレスと新規のアクセスに対応する行きパケットとをアドレス変換部１３６６に渡す。アドレス変換部１３６６は、渡された行きパケットの終点ＩＰアドレスを、サーバ群選択部１３６４によって選択されたサーバ群のＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１３６６から割当パケットとして内部ネットワーク３に送出される。
【００５５】
接続更新部１３６８は、サーバ群選択部１３６４で新規のアクセスに対してサーバ群１０２２の選択が行われる毎に、その選択に関する情報をサーバ群選択部１３６４から取得し、接続保持部１３２４に対応するエントリを追加する。この選択に関する情報は、新規のアクセスを行ったユーザのユーザ端末１００６のユーザ端末ＩＰアドレスと、ロードバランサＩＰアドレスと、新規のアクセスに対して選択されたサーバ群の割当サーバ群ＩＰアドレスと、シーケンス番号と、を含む。
また、接続更新部１３６８は、適宜不要となったエントリを削除する。
【００５６】
図６は、運用管理装置１０１０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００５７】
運用管理装置１０１０は、指標算出部１００と、指標送信部１５４と、表示制御部１２０と、負荷履歴保持部１１１２と、第２サーバ群状態保持部１１１４と、学習部１１３０と、状態設定部１１４０と、乖離判定部１１５０と、オーバライド部１１６０と、を備える。
【００５８】
指標算出部１００は、外部ネットワーク１００４、ロードバランサ１０３０および内部ネットワーク３から得られる情報から、複数のサーバ群１０２２の稼動状況が示された指標を算出する。
指標算出部１００は、ネットワークインタフェース部１０２と、通信情報保持部１０４と、分類部１３２と、集計部１３０と、第１指標保持部１０８と、係数保持部１１４と、第１解析部１１６と、使用状況取得部１１０と、使用状況保持部１１２と、第２指標保持部１１８と、第２解析部１５２と、第３指標保持部１５８と、を含む。
【００５９】
ネットワークインタフェース部１０２は、傍受部１２２と、抽出部１２４と、フィルタ部１２６と、登録部１２８と、を含む。
傍受部１２２は、外部ネットワーク１００４とロードバランサ１０３０と内部ネットワーク３とからパケットを傍受する。抽出部１２４は、傍受部１２２によって傍受されたパケットから始点ＩＰアドレスと終点ＩＰアドレスとポート番号とシーケンス番号とを抽出する。
【００６０】
以下、ロードバランサ１０３０またはサーバ群１０２２またはサーバ群１０２２のサーバをノードと呼ぶ場合がある。
フィルタ部１２６は、フィルタ機能がオンとされるフィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。より具体的にはフィルタ部１２６は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくとも一方が計測対象のノードのＩＰアドレスと一致する場合にのみ、抽出元のパケットを登録部１２８に出力する。
【００６１】
特にフィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。すなわち、フィルタ部１２６は、計測対象のノードのＩＰアドレスを、情報処理システム２に含まれる複数のノードのＩＰアドレスのなかで順番に切り替える。
フィルタ部１２６は、フィルタ機能がオフとされるフィルタリングオフモードでは、抽出部１２４によって始点ＩＰアドレスと終点ＩＰアドレスとポート番号とシーケンス番号とが抽出されたパケットを登録部１２８に出力する。
【００６２】
登録部１２８は、フィルタ部１２６によって出力されたパケットについて、そのパケットに関する時刻と、抽出部１２４によってそのパケットから抽出された始点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出された終点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出されたポート番号に対応する通信用途と、そのパケットのデータ量と、抽出部１２４によってそのパケットから抽出されたシーケンス番号と、を対応付けて通信情報保持部１０４に登録する。
【００６３】
図７は、通信情報保持部１０４に保持されるデータの一例を示すデータ構造図である。通信情報保持部１０４は、時刻２０２と、始点ＩＰアドレス２０４と、終点ＩＰアドレス２０６と、通信用途２０８と、データ量２１０と、シーケンス番号２１１と、を対応付けて保持する。
時刻２０２は、パケットに関する時刻であり、例えばパケットにタイムスタンプが含まれているのであればそのタイムスタンプで示される時刻である。あるいはまた、傍受部１２２によってパケットが傍受された時刻であってもよい。
始点ＩＰアドレス２０４および終点ＩＰアドレス２０６およびシーケンス番号２１１はそれぞれ、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスおよびシーケンス番号である。
通信用途２０８は、抽出部１２４によって抽出されたポート番号に対応する通信用途である。
データ量２１０は、パケットに搭載されているデータの量をバイト（Ｂ）単位で示す。
【００６４】
図６に戻る。分類部１３２は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくともひとつとポート番号とによってパケットを分類する。以下では分類部１３２が始点ＩＰアドレスとポート番号とによってパケットを分類する場合について説明する。しかしながら、分類部が終点ＩＰアドレスとポート番号とによってパケットを分類する場合、および分類部が始点および終点ＩＰアドレスとポート番号とによってパケットを分類する場合でも以下と同様の説明が成り立つことは、本明細書に触れた当業者には明らかである。
【００６５】
分類部１３２は、通信情報保持部１０４に保持されるデータを始点ＩＰアドレスについてソーティングする。以下、通信情報保持部１０４に登録されている始点ＩＰアドレスを登録ＩＰアドレスと称す。分類部１３２は、各登録ＩＰアドレスについて通信用途によってパケットを分類する。特に分類部１３２は、サーバ情報保持部１３８を参照し、登録ＩＰアドレスに対応するノード（以下、登録ノードと称す）に対して予め定められた通信用途である本来用途に関する情報を取得する。分類部１３２は、その本来用途に対応したパケットと、本来用途以外の通信用途である非本来用途に対応したパケットとに分類する。本来用途は、例えば登録ノードがＷＥＢサーバであれば、ポート番号「８０」に対応するＷＥＢ通信である。非本来用途は、例えば本来用途以外の通信用途であり、登録ノードがＷＥＢサーバであればポート番号「２０」に対応するＦＴＰ転送などである。
【００６６】
図８は、サーバ情報保持部１３８に保持されるデータの一例を示すデータ構造図である。サーバ情報保持部１３８は、ノードのノード名２１４と、ノードのＩＰアドレス２１８と、ノードの用途２２４と、を対応付けて保持する。
分類部１３２は、サーバ情報保持部１３８を参照してあるノードの本来用途に関する情報を取得する際、そのノードの用途を参照して本来用途を取得してもよい。
【００６７】
図６に戻る。集計部１３０は、少なくともひとつの登録ノードについて、本来用途に対応したパケットを集計する。特に集計部１３０は、所定の長さの期間すなわち時間帯ごとに、登録ノードの本来用途に対応したパケットのデータ量を集計し、また非本来用途に対応したパケットのデータ量を集計する。
例えば、登録ＩＰアドレス「121.21.15.1」に対応する登録ノードについて、時間帯「02/15/10 11:10:00~11:20:00」で集計する場合について考える。図８のサーバ情報保持部１３８から登録ノードは第１フロントエンドサーバ１０２４ａでありＷＥＢサーバである。集計部１３０は、分類部１３２における分類結果から、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」であり、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、本来用途に対する集計結果を得る。また、集計部１３０は、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」ではなく、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、非本来用途に対する集計結果を得る。
【００６８】
集計部１３０は、少なくともひとつの登録ノードについて、始点ＩＰアドレスと終点ＩＰアドレスとシーケンス番号とを参照して時間帯ごとのアクセスの数を算出する。集計部１３０は算出されたアクセスの数を時間帯の長さで除すことで、その登録ノードにおけるその時間帯でのアクセス数を算出する。
なお、集計部１３０は、ロードバランサ１０３０については、情報処理システム２の外部から情報処理装置１０２０全体へのアクセス数（以下、総アクセス数と称す）を算出する。つまり、集計部１３０は、情報処理システム２の外部の端末のＩＰアドレスを始点ＩＰアドレスとし、ロードバランサ１０３０のＩＰアドレスを終点ＩＰアドレスとするパケットを集計することで、ロードバランサ１０３０についての総アクセス数を算出する。
集計部１３０は、集計結果および算出結果を第１指標保持部１０８に登録する。
【００６９】
図９は、第１指標保持部１０８に保持されるデータの一例を示すデータ構造図である。第１指標保持部１０８は、登録ノードのノード名２２８と、登録ノードの本来用途２３０と、本来用途に対応するポート番号である主なポート番号２３２と、本来用途データ量２３４と、非本来用途データ量２３６と、集計部１３０で使用される所定の長さの期間すなわち時間帯に対応する計測期間２３８と、アクセス数２３９と、を対応付けて保持する。
本来用途データ量２３４は、登録ノードの本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
非本来用途データ量２３６は、登録ノードの非本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
【００７０】
図６に戻る。使用状況取得部１１０は、内部ネットワーク３を通じて所定の時間間隔もしくはリアルタイムで、情報処理システム２のノードから、そのノードの使用状況に関する情報を取得する。ノードの使用状況は、例えばノードがフロントエンドサーバ（ＷＥＢサーバ）１０２４やアプリケーションサーバ１０２６であれば消費電力（単位はＷ）や機器の温度（単位は℃）やＣＰＵ使用率（単位は％）であり、ノードがデータベースサーバ１０２８であればデータ転送量（単位はＭＢ／秒）や消費電力や機器の温度であり、ノードがロードバランサ１０３０などのネットワーク機器であればデータ転送量や消費電力や機器の温度である。
【００７１】
使用状況取得部１１０は、サーバの基本ＯＳに搭載されているシステムパフォーマンスモニタのデータを取得してもよい。
使用状況取得部１１０は、各ノードに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから各ノードに供給された電力の計測値を消費電力として取得してもよい。
使用状況取得部１１０は、ノードの温度を計測できる市販の装置（温度センサや、光ファイバ方式の温度センサ）と、その温度データを記憶して報告するデータ収集機能（市販されているソフトウエアパッケージ、またはサーバ組み込み型の特殊ハードウエアパッケージ）と、を利用して機器の温度を取得してもよい。
【００７２】
あるいはまた、使用状況取得部１１０は、米国ＥＰＡのEnergy Star for Server 2で登録し認定されるノードからは、下記の３つの報告機能を使用して消費電力と機器の温度とＣＰＵ使用率とを取得する。すなわち、米国のＥＰＡが行っているEnergy Star for Server 2では、登録し認定される機器は、３つの報告機能をハードウエア本体のマイクロコード（ファームウエア）のレベルで提供でき、基本ＯＳや他の計測ソフト、アプリケーションや本来のサーバの処理能力（本体のＣＰＵ・ＭＰＵ（Micro Processing Unit））には、影響を与えないハードウエアの管理機能を持つこととされている。この３つの報告機能は、１）サーバの実電力消費数値、２）サーバの本体ＣＰＵ・ＭＰＵ等の処理用プロセッサの使用率、３）サーバの実稼動の温度、である。
【００７３】
使用状況取得部１１０は、取得した使用状況に関する情報と、それを取得した時刻に対応する時間帯と、取得先のノード名と、ＩＰアドレスと、を対応付けて使用状況保持部１１２に登録する。使用状況取得部１１０が所定の時間間隔で情報を取得する場合は、時間帯は例えば取得した時刻から所定の時間間隔が経過するまでの期間に設定される。あるいはまた、使用状況取得部１１０がリアルタイムで情報を取得する場合は、所定の長さを有する期間を時間帯とし、使用状況に関する情報をその期間で時間平均する。
【００７４】
図１０は、使用状況保持部１１２に保持されるデータの一例を示すデータ構造図である。使用状況保持部１１２は、使用状況取得部１１０によって使用状況が取得されたノードのノード名２４４と、ＩＰアドレス２４５と、使用状況が取得された時刻に対応する記録時間帯２４６と、取得された消費電力２４８と、取得された機器温度２５０と、取得されたＣＰＵ使用率２５２と、取得されたデータ転送量２５３と、を対応付けて保持する。
【００７５】
一般的に、ＷＥＢサーバにおいて、所定の量、例えば１ｋＢのＷＥＢ通信用のデータを処理して送るにはどれだけのＣＰＵ使用率が必要かは測定できる。つまり、ＷＥＢサーバについて、ＷＥＢ通信用のデータ量とＣＰＵ使用率との関係は事前に測定できる。係数保持部１１４はその関係を示す係数（例えば、％・分／ＧＢの単位）を保持する。この係数が１である場合、例えば１ＧＢ分のＷＥＢ通信用のデータを処理して送るためにＷＥＢサーバは１％のＣＵＰ使用率で１分間稼動しなければならないことを意味する。
【００７６】
図１１は、係数保持部１１４に保持されるデータの一例を示すデータ構造図である。係数保持部１１４は、ＷＥＢサーバのサーバ名２４０と、係数２４２と、を対応付けて保持する。
【００７７】
図６に戻る。第１解析部１１６は、第１算出部１３４と、第２算出部１３６と、第１合成部１４２と、を含む。
第１算出部１３４は、第１指標保持部１０８に登録される登録ノードのうちＷＥＢサーバ（以下、登録ＷＥＢサーバと称す）について、本来用途データ量すなわちＷＥＢ通信用のデータ量を対応する計測期間の長さ、例えば分を単位とする長さ、で除し、ＷＥＢ通信用の時間平均データ量（例えば、ＧＢ／分の単位）を得る。第１算出部１３４は、係数保持部１１４からその登録ＷＥＢサーバに対応する係数を取得する。第１算出部１３４は、その登録ＷＥＢサーバについて、ＷＥＢ通信用の時間平均データ量と係数とを乗算し、乗算の結果得られる値（例えば、％の単位）を、その登録ＷＥＢサーバおよび計測期間における、ＷＥＢ通信に関する処理によるＣＰＵ使用率の推測値（以下、第１推測値と称す）とする。
【００７８】
例えば、図９の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第１算出部１３４は、計測期間「02/15/10 11:10:00~11:20:00」におけるＷＥＢ通信用のデータ量として「５００（ＧＢ）」を得る。第１算出部１３４は、「５００（ＧＢ）」を計測期間の長さ「１０（分）」で除し、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」を得る。第１算出部１３４は、図１１の係数保持部１１４を参照し、係数「１．５（％・分／ＧＢ）」を得る。第１算出部１３４は、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」と係数「１．５（％・分／ＧＢ）」とを乗算し「７５（％）」を得る。第１算出部１３４は、この値「７５（％）」をノード名「第１フロントエンドサーバ」のＷＥＢサーバにおける計測期間「02/15/10 11:10:00~11:20:00」中のＷＥＢ通信に関する処理による第１推測値とする。
【００７９】
第２算出部１３６は、第１算出部１３４における第１推測値の計算で対象とされた登録ＷＥＢサーバのサーバ名と計測期間とをキーとして使用状況保持部１１２を検索し、対応する消費電力と機器温度とＣＰＵ使用率とを抽出する。第２算出部１３６は、第１推測値を使用状況保持部１１２から抽出したＣＰＵ使用率から減じ、ＷＥＢ通信に関する処理以外の処理によるＣＰＵ使用率の推測値（以下、第２推測値と称す）とする。
ＷＥＢ通信に関する処理以外の処理は、例えば他の通信に関する処理や、ウイルスチェッカーによるウイルススキャンや、ハードディスクドライブへのデータの書き込みである。あるいはまた、アイドル状態にあってなにも仕事をしていないことも考えられる。
【００８０】
第２算出部１３６は、抽出された消費電力を第１推測値と第２推測値との比に分け、第１推測値に対応する値をＷＥＢ通信に関する処理のために使用された電力の推測値、第２推測値に対応する値をそうでない処理のために使用された電力の推測値とする。機器温度についても、機器温度と外気温との差を第１推測値と第２推測値との比に分ける点で同様である。
【００８１】
例えば、図９の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第２算出部１３６は図１０に示される使用状況保持部１１２から、ノード名「第１フロントエンドサーバ」と計測期間「02/15/10 11:10:00~11:20:00」とに対応する消費電力「３０（Ｗ）」、機器温度「３５（℃）」、ＣＰＵ使用率「８０（％）」を抽出する。第２算出部１３６は、第１推測値「７５（％）」をＣＰＵ使用率「８０（％）」から減じ、第２推測値「５（％）」を得る。第２算出部１３６は、消費電力「３０（Ｗ）」を第１推測値「７５（％）」と第２推測値「５（％）」との比すなわち１５：１に分け、ＷＥＢ通信に関する処理のために使用された電力の推測値「２８（Ｗ）」とそれ以外の処理のために使用された電力の推測値「２（Ｗ）」と、を得る。
【００８２】
第１合成部１４２は、時刻およびノード名をキーとして、第１指標保持部１０８に保持されるデータと、使用状況保持部１１２に保持されるデータと、第２算出部１３６による計算結果（登録ＷＥＢサーバについての、ＷＥＢ通信処理由来の消費電力、ＷＥＢ通信処理由来の上昇温度、ＷＥＢ通信処理由来のＣＰＵ使用率）と、を対応付けて第２指標保持部１１８に登録する。
【００８３】
図１２は、第２指標保持部１１８に保持されるデータの一例を示すデータ構造図である。第２指標保持部１１８は、ノード名２５４と、本来用途２５６と、主なポート番号２５８と、本来用途データ量２６０と、非本来用途データ量２６２と、計測期間２６４と、消費電力２６６と、機器温度２６８と、ＣＰＵ使用率２７０と、データ転送量２７１と、ＷＥＢ通信由来消費電力２７２と、ＷＥＢ通信由来上昇温度２７４と、ＷＥＢ通信由来ＣＰＵ使用率２７６と、を対応付けて保持する。
ＷＥＢ通信由来消費電力２７２は、第２算出部１３６によって算出された、ＷＥＢ通信に関する処理のために使用された電力の推測値である。ＷＥＢ通信由来上昇温度２７４は、第２算出部１３６によって算出された、機器温度と外気温との差のうちＷＥＢ通信に関する処理によって上昇したと予測される分である。ここでは外気温は２５（℃）とされている。ＷＥＢ通信由来ＣＰＵ使用率２７６は、第１算出部１３４によって算出された第１推測値である。
【００８４】
図６に戻る。第２解析部１５２は、第２指標保持部１１８に保持されるデータのうちＷＥＢサーバ（フロントエンドサーバ１０２４）に関するデータを、使用状況取得部１１０における所定の時間間隔よりも長い時間間隔、例えば１ヶ月や半年の時間間隔で統計処理する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、消費電力の時間平均である平均消費電力と、統計処理対象の期間内における消費電力の最高値である最高消費電力と、を算出する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、ＷＥＢ通信由来の消費電力の時間平均を本来用途データ量（ＷＥＢ通信用のデータ量）の時間平均で除し、電力コスト（例えば、Ｗ／ＧＢの単位）を算出する。
第２解析部１５２は、サーバ名と、平均消費電力と、最高消費電力と、電力コストと、を対応付けて第３指標保持部１５８に登録する。
【００８５】
図１３は、第３指標保持部１５８に保持されるデータの一例を示すデータ構造図である。第３指標保持部１５８は、サーバ名３０４と、平均消費電力３０６と、最高消費電力３０８と、電力コスト３１０と、を対応付けて保持する。
【００８６】
図６に戻る。表示制御部１２０は、第１指標保持部１０８、第２指標保持部１１８、第３指標保持部１５８のうちの少なくともひとつに基づき、ノードごとに各種パラメータを示す画面をモニタ１４０に表示させる。
【００８７】
指標送信部１５４は、第１サーバ群状態保持部１３２２の更新のために、第３指標保持部１５８に登録されている電力コストに関する情報をロードバランサ１０３０に送信する。
【００８８】
学習部１１３０は、更新部１１３２と、負荷予測部１１３４と、を含む。学習部１１３０は、更新部１１３２によって総アクセス数の履歴を負荷履歴保持部１１１２に記憶し、その記憶をふまえて負荷予測部１１３４によって今後発生しうる総アクセス数を予測する。これにより、運用実績が長いほど省エネの観点からより賢くなる運用管理が可能となる。
【００８９】
更新部１１３２は、第１指標保持部１０８から総アクセス数を取得する。更新部１１３２は、取得した総アクセス数をもとに負荷履歴保持部１１１２を更新する。負荷履歴保持部１１１２はしたがって、総アクセス数の履歴すなわち過去に要求された総アクセス数を保持する。
【００９０】
図１４は、負荷履歴保持部１１１２を示すデータ構造図である。負荷履歴保持部１１１２は、時間帯１２１８と、その時間帯が属する属性１２２０と、その時間帯に取得された総アクセス数１２２２と、その時間帯に稼動状態に設定される稼動サーバ群の数１２２４と、その時間帯の平均稼動率１２２６と、を対応付けて記憶する。時間帯が属する属性１２２０とは、例えば月曜日、火曜日などの曜日や、平日休日の別や、年末年始とそれ以外の別や、午前午後の別や、それらの任意の組み合わせである。平均稼働率１２２６は、稼動状態に設定されるサーバ群の稼働率の平均値である。
更新部１１３２は、稼動状態に設定される稼動サーバ群の数１２２４を取得するために第２サーバ群状態保持部１１１４を参照してもよい。
時間帯１２１８は、運用管理装置１０１０のモードを更新する基準となる時間間隔を有する期間である。
【００９１】
図６に戻る。負荷予測部１１３４は、過去に要求された総アクセス数をもとに今後発生する総アクセス数を予測する。負荷予測部１１３４は、未来の時間帯ごとに総アクセス数を予測する。後述の状態設定部１１４０もまた、この時間帯ごとに必要に応じてサーバ群１０２２の状態を設定する。特に負荷予測部１１３４は、総アクセス数予測の対象となる時間帯（以下、予測対象の時間帯と称す）について負荷履歴保持部１１１２を参照して総アクセス数を予測する。以下、負荷予測部１１３４によって予測される総アクセス数を予測総アクセス数と称す。
【００９２】
負荷予測部１１３４では、情報処理システム２が使用される目的に応じた総アクセス数の傾向（トレンド）を負荷履歴保持部１１１２から抽出する処理と、抽出された傾向に基づいて予測対象の時間帯の総アクセス数を予測する処理とが行われる。特に負荷予測部１１３４では、時間帯の属性をキーとして総アクセス数の傾向が抽出される。
【００９３】
負荷予測部１１３４は予測対象の時間帯が属する属性に対応する総アクセス数を負荷履歴保持部１１１２から取得してその時間帯に対する予測総アクセス数とする。
例えば、曜日がキーとして設定された場合、負荷予測部１１３４は負荷履歴保持部１１１２を参照し、曜日毎の総アクセス数の平均値を演算する。負荷予測部１１３４は、これらの平均値のうち予測対象の時間帯の曜日にマッチする曜日の平均値を予測総アクセス数とする。また、例えば平日休日の別がキーとして設定された場合、負荷予測部１１３４は負荷履歴保持部１１１２を参照し、平日の総アクセス数の平均値と休日の総アクセス数の平均値を演算する。負荷予測部１１３４は、これらの平均値のうち予測対象の時間帯が平日であれば平日の、休日であれば休日の平均値を予測総アクセス数とする。
なお、ここでは一例として平均値を用いたが、代表値などの他の統計的なパラメータであってもよい。
【００９４】
負荷予測部１１３４は予測総アクセス数を乖離判定部１１５０および状態設定部１１４０の負荷比較部１１４２に渡す。
【００９５】
状態設定部１１４０は、予測総アクセス数が所定のアクセスしきい値Ｍｏより少ない場合、予測対象の時間帯において情報処理装置１０２０に含まれる少なくともひとつのサーバ群１０２２を省電力状態に設定する。
【００９６】
状態設定部１１４０におけるモアクセスしきい値Ｍｏは、情報処理装置１０２０の性能が落ちない範囲に設定される。ここで性能とは、例えばどれだけのアクセス数をどの程度の速さで処理できるかということである。あるいは性能とは、ひとつのアクセスが処理されるのにかかる時間などのレスポンスタイムであってもよい。また、情報処理装置１０２０の性能が落ちる、とは、例えばあるサーバ群１０２２に対してピークアクセス数を越える数のアクセスが割り当てられ、その結果そのサーバ群１０２２の処理速度が落ちることにより情報処理装置１０２０全体のアクセスの処理速度が落ちることである。
【００９７】
例えば第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。この場合アクセスしきい値Ｍｏを９０００に設定すると、予測総アクセス数が８５００であっても予測対象の時間帯で少なくともひとつのサーバ群を省電力状態に設定しなくてはならない。ここでは第５サーバ群１０２２ｅを省電力状態に設定したとする。残りの４つのサーバ群１０２２ａ〜２２ｄのトータルのピークアクセス数は８０００であり、予測総アクセス数９５００よりも少ない。したがってこの場合、予測対象の時間帯が到来したときに、残りの４つのサーバ群１０２２ａ〜２２ｄのうちの少なくともひとつのサーバ群がピークアクセス数以上のアクセスを処理しなくてはならなくなる可能性が高くなり、その場合そのサーバ群の処理速度は低下する。これにより情報処理装置１０２０全体の処理速度が落ちる可能性がある。このような状況を避けるために、アクセスしきい値Ｍｏは情報処理装置１０２０の性能が落ちない範囲に設定される。上述の例ではアクセスしきい値Ｍｏは８０００以下に設定されればよい。
【００９８】
状態設定部１１４０は、サーバ群１０２２の最大性能を発揮せしめる前提で、アクセスを処理させるサーバ群を決定し、予測対象の時間帯において残りのサーバ群を省電力状態に設定する。この場合サーバ群１０２２の最大性能を発揮せしめる、とは、例えばサーバ群１０２２にピークアクセス数でアクセス処理を行わせることであり、言い換えるとサーバ群を１００％の稼働率で使用することである。さらに状態設定部１１４０は、予測総アクセス数の変動により情報処理装置１０２０の性能が落ちると予測される場合には、予測対象の時間帯において省電力状態に設定されている少なくともひとつのサーバ群を稼動状態に設定する。
【００９９】
サーバ群１０２２を省電力状態または稼動状態に設定することに関して、状態設定部１１４０では、予測対象の時間帯において稼動状態にするサーバ群の数に応じた予測総アクセス数の範囲が定められている。状態設定部１１４０は例えば予測総アクセス数が０から第１しきい値Ｔ１の範囲にあれば予測対象の時間帯においてひとつのサーバ群のみを稼動状態とし、他のサーバ群を省電力状態とする。表１は、状態設定部１１４０における状態設定に関して、稼動状態とするサーバ群の数と、ＯＳ休眠状態とするサーバ群の数と、電源オフ状態とするサーバ群の数と、予測総アクセス数の範囲と、の関係を示す。Ｔ２は第２しきい値、Ｔ３は第３しきい値であり、Ｔ１＜Ｔ２＜Ｔ３である。個々のしきい値は予め情報処理システム２の管理者によって設定される。
【表１】
【０１００】
第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３はそれぞれサーバ群１０２２を１００％の稼働率で使用することを前提に設定される。つまり上述の第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする例では、Ｔ１＝２０００、Ｔ２＝４０００、Ｔ３＝６０００である。この場合、予測総アクセス数のアクセスを処理するのに必要最低限の数のサーバ群が予測対象の時間帯において稼動状態とされる。また、例えば第１しきい値Ｔ１と第２しきい値Ｔ２との間にあった予測総アクセス数が増大して第２しきい値Ｔ２を越えた場合、そのままだと予測対象の時間帯において少なくともひとつのサーバ群の稼働率が１００％を上回ると予測されるので、予測対象の時間帯において稼動状態とするサーバ群の数をひとつ増やして情報処理装置１０２０の処理速度の低下を回避する。
【０１０１】
状態設定部１１４０は、負荷比較部１１４２と、稼動サーバ群決定部１１４４と、状態信号生成部１１４６と、を含む。
負荷比較部１１４２は、負荷予測部１１３４から取得した予測総アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、アクセスしきい値Ｍｏとの大小関係を判別する。この大小関係は例えば「Ｔ２＜予測総アクセス数＜Ｔ３」という情報である。負荷比較部１１４２はこの大小関係に関する情報を稼動サーバ群決定部１１４４に渡す。
【０１０２】
稼動サーバ群決定部１１４４は、この情報を基に表１のストラテジにしたがい、次の時間帯における状態の切替の必要性を判定する。稼動サーバ群決定部１１４４は、状態の切替が必要な場合には、指標算出部１００から取得する指標に基づいて、稼動状態とするサーバ群とＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群を決定する。稼動サーバ群決定部１１４４は次の時間帯の到来に合わせて、この決定に基づき第２サーバ群状態保持部１１１４およびロードバランサ１０３０の第１サーバ群状態保持部１３２２を更新する。稼動サーバ群決定部１１４４は、次の時間帯の到来に合わせて、状態の切り替えが必要なサーバ群の情報を状態信号生成部１１４６に渡す。稼動サーバ群決定部１１４４は、状態の切り替えが必要ない場合には処理を中断または終了し、次の情報を待ち受ける。
第２サーバ群状態保持部１１１４は図５に示される第１サーバ群状態保持部１３２２と同様のテーブルである。なお、運用管理装置１０１０またはロードバランサ１０３０のいずれか一方がサーバ群状態テーブルを備え、そのテーブルを備えない方が備える方のテーブルを参照する構成としてもよい。
【０１０３】
稼動サーバ群決定部１１４４は、表１のストラテジから稼動状態、ＯＳ休眠状態および電源オフ状態とするサーバ群の数をまず決める。次に稼動サーバ群決定部１１４４は第２サーバ群状態保持部１１１４を参照し、次の時間帯でサーバ群の状態を切り替える必要があるか、言い換えると負荷予測部１１３４が予測した次の時間帯での予測総アクセス数に対応する各状態のサーバ群の数と第２サーバ群状態保持部１１１４に登録されている現在の各状態のサーバ群の数とが一致するか否かを判断する。そこで一致する場合は稼動サーバ群決定部１１４４は処理を中断または終了する。
【０１０４】
一致しない場合は、稼動サーバ群決定部１１４４は次の時間帯でそれぞれの状態にするサーバ群を決める。稼動サーバ群決定部１１４４は、指標算出部１００の第３指標保持部１５８に保持されるデータを取得する。稼動サーバ群決定部１１４４は、取得したデータを基に各サーバ群１０２２に対して省電力状態とされる順番を示す省エネ停止可能順位を設定する。省エネ停止可能順位は「１」が最も高く、数が増えるにつれて低くなる順位である。
稼動サーバ群決定部１１４４では、第３指標保持部１５８に保持されるフロントエンドサーバ１０２４の平均消費電力、最高消費電力、電力コストを、そのフロントエンドサーバ１０２４が属するサーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとみなす。
【０１０５】
表２は、サーバ群１０２２の電力コストに基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表２】
表２のストラテジでは、サーバ群１０２２の電力コストが大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。電力コストが遜色ない２つのサーバ群が存在する場合は、平均消費電力や最高消費電力が高いほうのサーバ群の省エネ停止可能順位をより高く設定する（表２の第４サーバ群と第５サーバ群）。
【０１０６】
表３は、サーバ群１０２２の消費電力に基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表３】
表３のストラテジでは、サーバ群１０２２の平均消費電力と最高消費電力との和が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。
情報処理装置１０２０において各サーバ群１０２２が主にＷＥＢ通信をおこなっており他の用途の処理は無視できる程度であり、またロードバランサ１０３０において稼動状態にあるサーバ群にアクセスが均等に割り当てられる設定となっている場合は、稼動状態にあるサーバ群には同じ負荷がかけられれていると考えることができる。したがって、稼動状態にある各サーバ群の平均消費電力は、同じ負荷がかけられれている場合に消費される電力の平均値と同一視することができ、また、稼動状態にある各サーバ群の最高消費電力は、同じ負荷がかけられれている場合に消費される電力の最高値と同一視することができる。この場合、表３のストラテジでは、サーバ群１０２２に同じ負荷がかけられた場合に消費される電力が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定されているといえる。
【０１０７】
稼動サーバ群決定部１１４４は、稼動状態にあるサーバ群のひとつを省電力状態に切り替える必要がある場合、稼動状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も高いサーバ群を省電力状態とすべきサーバ群として選択する。
稼動サーバ群決定部１１４４は、省電力状態にあるサーバ群のひとつを稼動状態に切り替える必要がある場合、省電力状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も低いサーバ群を稼動状態とすべきサーバ群として選択する。
【０１０８】
なお、稼動サーバ群決定部１１４４でのサーバ群１０２２を決める上述のアルゴリズムでは、特に稼動状態を省電力状態に切り替える場合は、アクセスの同一性が考慮されてもよい。例えば、稼動サーバ群決定部１１４４は、稼動状態を省電力状態に切り替える場合、次の時間帯の到来に合わせて第２サーバ群状態保持部１１１４および第１サーバ群状態保持部１３２２を更新して省電力状態に切り替えるべきサーバ群への新規アクセスの割り当てを制限する一方、ロードバランサ１０３０の接続保持部１３２４を参照し、省電力状態に切り替えるべきサーバ群へのアクセスがなくなったことを確認してから状態の切り替えが必要なサーバ群の情報を状態信号生成部１１４６に渡してもよい。これによりアクセスの同一性が保証されうる。
【０１０９】
状態信号生成部１１４６は内部ネットワーク３を介して第１サーバ群１０２２ａ〜第５サーバ群１０２２ｅに接続される。
状態信号生成部１１４６は、状態の切り替えが必要なサーバ群の情報に基づきそのサーバ群に対して切替に対応する休眠導入信号、休眠解除信号、電源オフ信号、および電源オン信号のうちのいずれかを送る。例えば第３サーバ群１０２２ｃを稼動状態（ＯＳ休眠状態）からＯＳ休眠状態（稼動状態）とする必要がある場合、状態信号生成部１１４６は第３サーバ群１０２２ｃに対して休眠導入信号（休眠解除信号）を送出する。また、第３サーバ群１０２２ｃを稼動状態（電源オフ状態）から電源オフ状態（稼動状態）とする必要がある場合、状態信号生成部１１４６は第３サーバ群１０２２ｃに対して電源オフ信号（電源オン信号）を送出する。
状態信号生成部１１４６によって省電力状態から稼動状態に設定されたサーバ群は、それが稼動状態であることが稼動サーバ群決定部１１４４によってロードバランサ１０３０の第１サーバ群状態保持部１３２２に記録されるので、ロードバランサ１０３０の要求割当部１０３６によって新規のアクセスが割り当てられる。
【０１１０】
運用管理装置１０１０は、予測総アクセス数を基に状態設定部１１４０でサーバ群１０２２の状態を設定する上述の負荷予測モードの他に、第１指標保持部１０８に保持される総アクセス数を基に状態設定部１１４０でサーバ群１０２２の状態を適応的に設定する適応モードを有する。以下、この適応モードについて説明する。
【０１１１】
乖離判定部１１５０は、予測された総アクセス数と実際の総アクセス数との差が大きい、つまりその差の絶対値が所定の乖離値よりも大きい場合、状態設定部１１４０に実際の総アクセス数に基づいてサーバ群の状態を設定せしめる。
乖離判定部１１５０は、第１指標保持部１０８から現在の時間帯に対応する総アクセス数を取得する。また乖離判定部１１５０は負荷予測部１１３４から現在の時間帯に対して予測された予測総アクセス数も取得する。そして乖離判定部１１５０は、両者の差を演算する。その差の絶対値が乖離値より大きい場合は、乖離判定部１１５０は状態設定部１１４０の負荷比較部１１４２に、予測総アクセス数の代わりに第１指標保持部１０８からの総アクセス数を使用させる。この場合負荷比較部１１４２は、第１指標保持部１０８からの総アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、アクセスしきい値Ｍｏとの大小関係を判別する。状態設定部１１４０はかかる大小関係を使用して上述の処理と同様の処理を行う。これにより状態設定部１１４０は、予測された総アクセス数と実際の総アクセス数との差が大きい場合に、実際の総アクセス数に応じて適応的にサーバ群１０２２の状態を設定することができる。
【０１１２】
また、運用管理装置１０１０は、情報処理システム２の管理者がマニュアルでサーバ群１０２２の状態を設定できるマニュアル設定モードも有する。
オーバライド部１１６０は、運用管理装置１０１０に付随するキーボードなどの入力装置１０１２から管理者によるマニュアル設定を受け付ける。オーバライド部１１６０はこのマニュアル設定を受け付けると状態設定部１１４０に、このマニュアル設定に基づいてサーバ群１０２２の状態を設定せしめる。これにより急激な使用環境の変化にも対応可能となる。
【０１１３】
表示制御部１２０は、第１指標保持部１０８から現在の時間帯における総アクセス数を、第２サーバ群状態保持部１１１４から現在のサーバ群１０２２の状態を、取得する。表示制御部１２０は、運用管理装置１０１０に付随するモニタ１４０に総アクセス数とサーバ群１０２２の状態とを示すステータス画面１４００ａ〜１４００ｄを表示させる。また、表示制御部１２０は、乖離判定部１１５０において予測された総アクセス数と実際の総アクセス数との差の絶対値が乖離値よりも大きいと判断された場合、モニタ１４０に警告画面１４０２を表示させる。また、表示制御部１２０は、管理者によるマニュアル設定のための状態設定画面１４０４をモニタ１４０に表示させる。
【０１１４】
図１５（ａ）〜（ｄ）は、ステータス画面１４００ａ〜１４００ｄの代表画面図である。ここでは、第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。また、稼動サーバ群決定部１１４４では表２のストラテジが使用され、サーバ群選択部１３６４では傾斜配分モードが使用される場合を考える。図１５（ａ）〜図１５（ｄ）はそれぞれ現在の時間帯における総アクセス数が１６００、２８００、４４００、７０００の場合に対応する。
図１５（ａ）は、現在の時間帯における総アクセス数が１６００の場合に対応するステータス画面１４００ａの代表画面図である。ステータス画面１４００ａは、総アクセス数領域１４０６と、グラフ１４０８と、オーバライドボタン１４１０と、を含む。総アクセス数領域１４０６は、現在の時間帯における総アクセス数を示す。グラフ１４０８は、各サーバ群１０２２の稼働率を示す。グラフ１４０８において「△」はＯＳ休眠状態を示し、「×」は電源オフ状態を示す。オーバライドボタン１４１０は、押し下げられるとオーバライド部１１６０をトリガする。オーバライドボタン１４１０が押し下げられると表示制御部１２０は状態設定画面１４０４をモニタ１４０に表示させる。図１５（ｂ）〜図１５（ｄ）についても同様である。
【０１１５】
図１６は、警告画面１４０２の代表画面図である。
図１７は、状態設定画面１４０４の代表画面図である。状態設定画面１４０４は、設定領域１４１２と、設定ボタン１４１４と、を含む。状態設定画面１４０４を開いた直後の状態では、設定領域１４１２には各サーバ群の現在の状態がラジオボタン方式で示されている。設定領域１４１２では第１サーバ群１０２２ａ〜第５サーバ群１０２２ｅはそれぞれサーバ群Ａ〜サーバ群Ｅという名称で表示されている。管理者はマウスなどの入力装置１０１２を使用して各サーバ群の状態を選択し、設定ボタン１４１４を押し下げる。すると設定領域１４１２に設定された各サーバ群１０２２の状態が所望のマニュアル設定としてオーバライド部１１６０に送られる。これにより、第１サーバ群１０２２ａ〜第５サーバ群１０２２ｅのそれぞれを稼動状態とするか、ＯＳ休眠状態とするか、または電源オフ状態とするかを設定できる。
【０１１６】
上述のロードバランサ１０３０や運用管理装置１０１０において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【０１１７】
以上の構成による運用管理装置１０１０の動作を説明する。図１８は、指標算出部１００における一連の処理を示すフローチャートである。傍受部１２２は、ネットワークからパケットを傍受する（Ｓ４０２）。抽出部１２４は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ４０４）。登録部１２８は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部１０４に登録する（Ｓ４０６）。分類部１３２は、通信情報保持部１０４に保持されるデータを始点アドレスでソーティングする（Ｓ４０８）。分類部１３２は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ４１０）。集計部１３０は、分類されたデータを集計する（Ｓ４１２）。第２解析部１５２は、集計結果から各サーバ群１０２２の電力コストを算出する（Ｓ４１４）。
【０１１８】
図１９は、学習部１１３０および状態設定部１１４０における一連の処理を時系列に沿って示すチャートである。更新部１１３２が第１指標保持部１０８から総アクセス数を取得する時間間隔は１５分間隔である場合を考える。２００９年９月１６日の９：１５に、更新部１１３２は第１指標保持部１０８から総アクセス数を取得する（Ｓ５０２）。更新部１１３２は、取得された総アクセス数をもとに負荷履歴保持部１１１２を更新する（Ｓ５０４）。一方、２００９年９月１６日の９：１５−９：３０の時間帯内でステップＳ５０４の負荷履歴保持部１１１２更新と重ならないときに、負荷予測部１１３４は負荷履歴保持部１１１２を参照して次の時間帯（１００９：３０−９：４５）の総アクセス数を予測する（Ｓ５０６）。状態設定部１１４０は、予測総アクセス数とアクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３との大小比較を行う（Ｓ５０８）。状態設定部１１４０は、その大小比較を基に次の時間帯においてサーバ群１０２２の状態の切替が必要か否かを判断する（Ｓ５１０）。状態の切替が必要でない場合（Ｓ５１０のＮ）、次の時間帯が到来してもサーバ群１０２２の状態の設定は行わない。状態の切替が必要な場合（Ｓ５１０のＹ）、状態設定部１１４０は省エネ停止可能順位に基づき、次の時間帯におけるサーバ群１０２２の状態を決定する（Ｓ５１２）。次の時間帯が到来すると、つまり２００９年９月１６日の９：３０になると、状態設定部１１４０はサーバ群の状態をステップＳ５１２で決定されたように設定する。また、状態設定部１１４０は平行して第２サーバ群状態保持部１１１４およびロードバランサ１０３０の第１サーバ群状態保持部１３２２を更新する（Ｓ５１４）。運用管理装置１０１０はこの処理を時間帯単位で繰り返す。
【０１１９】
本実施の形態に係る運用管理装置１０１０によると、データセンタなどの情報処理システム２が使用される目的、例えば証券業務や検索エンジンなど、に応じた総アクセス数の傾向を把握し、それを用いて今後発生しうる総アクセス数を予測できる。そしてこの予測総アクセス数が少ない場合は、予測対象の時間帯において少なくともひとつのサーバ群が省電力状態に設定される。
【０１２０】
上述した通り稼動状態のサーバ群の消費電力は、アイドル状態であってもピーク時のおよそ６０％である。これに対して省電力状態のサーバ群の消費電力はピーク時のおよそ０〜１０％である。本実施の形態では、アクセス数が少ないと予測され、したがってアクセスを処理する必要がないと予測されるサーバ群がある場合はそれらのサーバ群をアイドル状態ではなく省電力状態としている。これにより、情報処理装置１０２０全体の消費電力を低減でき、電力の無駄遣いを抑え、省エネ化を図ることができる。
【０１２１】
また本実施の形態に係る運用管理装置１０１０では、情報処理システム２が使用される目的に応じた総アクセス数の傾向を把握し、それを用いて今後発生しうる総アクセス数を予測しているので、個々の使用目的に対して最適な消費電力低減化、省エネ化を実現できる。
【０１２２】
さらに、本実施の形態に係る運用管理装置１０１０によると、指標算出部１００はネットワークを傍受して各サーバ群１０２２の特性の違いを示す指標を算出する。状態設定部１１４０は、少なくともひとつのサーバ群１０２２を省電力状態に設定する際、指標算出部１００によって算出されたこの指標に基づいて、省電力状態に設定するサーバ群を選択する。したがって、各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、稼動状態にあるサーバ群のなかから省電力状態とするサーバ群を選択できる。これにより、全てのサーバ群１０２２を特性上同等と見なした上で省電力状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。その結果、情報処理システム２の省エネ化を一層進めることができる。
【０１２３】
また、稼動サーバ群決定部１１４４は、電力コストが大きいサーバ群を省電力状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２４】
また、本実施の形態に係る運用管理装置１０１０によると、パケットをネットワークから傍受し、傍受したパケットを始点ＩＰアドレスとポート番号とで分類する。したがって、始点ＩＰアドレスごとおよびポート番号ごとに通信データ量を計測できる。これにより、所望の解析対象のノードについて、どの通信用途（メール通信やＷＥＢ閲覧など）に対応する仕事をどの程度行ったかを、そのノードに直接問い合わせることなしにネットワーク上を流れるパケットから追跡できる。ノードへ問い合わせないので、仕事量の解析に伴うノード側の負担はほとんどない。運用管理装置１０１０はネットワークの傍受を行うので、運用管理装置１０１０自身の測定への寄与は小さく、また把握できる。
【０１２５】
さらに本実施の形態では、更新部１１３２は指標算出部１００によって算出された総アクセス数に基づいて負荷履歴保持部１１１２を更新する。したがって、総アクセス数を予測するための履歴データを、サーバ側の負担をほとんど増やすことなしに得ることができる。
【０１２６】
また、本実施の形態では、稼動サーバ群決定部１１４４は、予測総アクセス数が所定の値より多くなると予測される場合には、指標算出部１００によって算出された指標に基づいて、省電力状態に設定されている複数のサーバ群のうちの少なくともひとつのサーバ群を選択する。状態信号生成部１１４６は、稼動サーバ群決定部１１４４によって選択された少なくともひとつのサーバ群を稼動状態に設定する。これにより、まず、サーバ群１０２２をピークアクセス数以上で使用しなければならない状況を回避し、アクセス処理の遅滞を避けることができる。さらに、各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、省電力状態にあるサーバ群のなかから稼動状態とするサーバ群を選択できる。これにより、全てのサーバ群を特性上同等と見なした上で稼動状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。
【０１２７】
また、稼動サーバ群決定部１１４４は、電力コストが小さいサーバ群を稼動状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２８】
また、本実施の形態では、ロードバランサ１０３０は、取得されたアクセスを、電力コストが小さいサーバ群に優先的に割り当てる。したがって、結果としてアクセスがより多く割り当てられるサーバ群の電力コストは、そうでないサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２９】
また、本実施の形態に係る運用管理装置１０１０では、負荷履歴保持部１１１２は、取得された総アクセス数と、その総アクセス数が取得された時間帯が属する属性と、を対応付けて記憶する。したがって、総アクセス数の傾向を属性を基準にして把握することができる。さらに運用管理装置１０１０では、予測対象の時間帯が属する属性に対応する総アクセス数を負荷履歴保持部１１１２から取得してその時間帯に対して予測される総アクセス数とする。したがって、属性を情報処理システム２の使用目的に応じて適切に設定することにより、予測される総アクセス数の精度を向上することができる。
【０１３０】
図２０は、本実施の形態に係る情報処理システム２が証券会社のインターネット株取引システムを提供するデータセンタとして使用される場合の、負荷履歴保持部１１１２ａの一例を示すデータ構造図である。ここでは稼動サーバ群の数および平均稼動率は説明を明瞭とするため省略される。この場合の総アクセス数の傾向としては、証券取引所の取引時間内にアクセスが集中することがある。また、証券取引所が閉まってからしばらくはいわゆるバッチ処理を行うためにいくらかの仕事が発生する。それ以外で証券取引所が閉まっている時間帯、例えば休日などにはアクセスはほとんどない。あっても証券会社の顧客が自己の口座の情報を参照する程度である。したがって、図２０に示されるように、時間帯の属性として、証券取引所の取引時間にあたる時間帯に「取引時間」という属性を、バッチ処理が行われる時間帯に「バッチ処理」という属性を、それ以外の時間帯に「時間外」もしくは土日祝日の場合は「休日」を、それぞれ与えてもよい。このような属性を付与することで、証券会社のインターネット株取引システムを提供するデータセンタに発生する総アクセス数をより適切に予測することができる。
【０１３１】
図２１は、本実施の形態に係る情報処理システム２が検索サービスを提供するデータセンタとして使用される場合の、負荷履歴保持部１１１２ｂの一例を示すデータ構造図である。ここでは稼動サーバ群の数および平均稼動率は説明を明瞭とするため省略される。この場合の総アクセス数の傾向としては、平日よりも休日の方が利用が多く、また平日でも午前よりも午後の方が利用が多いことがある。したがって、図２１に示されるように、時間帯の属性として、平日休日の別と午前午後の別との組み合わせを与えてもよい。このような属性を付与することで、検索サービスを提供するデータセンタに発生する総アクセス数をより適切に予測することができる。
【０１３２】
本実施の形態に係る運用管理装置１０１０では、省電力モード（予測総アクセス数＜アクセスしきい値Ｍｏ）においては、表１に示される通りＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群との両方を設けている。これにより、予測対象の時間帯において突然総アクセス数が増大した場合は、適応モードに移行した後復帰のためのオーバヘッドが小さいＯＳ休眠状態にあるサーバ群を稼動状態に戻すことで対応できる。また、そのように対応できる限りにおいては他のサーバ群は電力を消費しない電源オフ状態とし、情報処理装置１０２０全体の消費電力をさらに低減している。なお、表１ではＯＳ休眠状態とするサーバ群をひとつだけ確保しているが、この数はオーバヘッドと消費電力とのかねあいで定められればよく、適宜増減可能であることは本明細書に触れた当業者には理解される。
【０１３３】
本実施の形態に係る運用管理装置１０１０では、状態設定部１１４０はサーバ群の最大性能を発揮せしめる前提で、予測対象の時間帯において稼動状態とするサーバ群を決定する。このサーバ群の決定方式によると、所与の予測総アクセス数に対してより多くの数のサーバ群を省電力状態とすることができる。したがって、情報処理装置１０２０全体の消費電力をより低減できる。なお、稼働率によってサーバ群の消費電力が異なるのも事実ではあるが、上述の通りアイドル状態でもピーク時のおよそ６０％の電力が消費されることを考えると、稼働率を下げることによる電力削減効果よりもアイドル状態を省電力状態とすることによる電力削減効果のほうが大きいと考えられる。
【０１３４】
また、アクセスしきい値Ｍｏは情報処理装置１０２０の性能が落ちない範囲に設定される。これにより、予測総アクセス数が多い場合は通常モードで情報処理装置１０２０の並列処理能力をいかんなく発揮させ、予測総アクセス数が少なくなると省電力モードに移行させて性能を保ちつつ電力消費量を低減できる。
【０１３５】
また、本実施の形態に係る運用管理装置１０１０では、ＩＰアドレスは仕事の主体を示し、ポート番号は通信用途を示すので、それらを用いてノードで行われている仕事の内訳を導出し、特に有効仕事量を計測できる。この点、現実的に有効仕事量の計測が困難であった従来の技術とは大きく異なる。運用管理装置１０１０によると、ノードにおける仕事量を解析することで、そのノードが有効な仕事をどの程度行ったかを計測でき、情報処理システム２を省エネ化するためのよい指標が得られる。
【０１３６】
また、本実施の形態に係る運用管理装置１０１０では、通信情報保持部１０４に保持される傍受されたパケットの情報を本来用途と非本来用途とで分類する。したがって、図９の第１指標保持部１０８に示されるように、所望の解析対象のノードについて、本来用途データ量と非本来用途データ量とを得ることができる。これにより、両者の比率などから解析対象のノードがどの程度本来の用途で使用されているかを追跡できる。これは情報処理システム２を省エネ化するためのよい指標のひとつである。例えば、本来の用途で使用されていないノードを発見し、適切な処置を施すことで情報処理システム２の効率を向上できる。
【０１３７】
また、運用管理装置１０１０では、第２指標保持部１１８は、第１指標保持部１０８と使用状況保持部１１２とが対応付けられた形となっている。したがって、情報処理システム２の省エネ化を考える際に、ノードにおける仕事量と使用状況とを対応付けて把握できる。すなわち、ノードが何の仕事をいつどれだけ行ったことにより、どれだけのＣＰＵの処理能力を使用し、どれだけの電力を消費し、どれだけの温度上昇があったかを解析できる。
【０１３８】
例えば、ＣＰＵ使用率が１００％とされているサーバの仕事量の内訳を見ることにより、実際１００％のＣＰＵ使用率のうちどれだけが有効な仕事のために使用されたかを知ることができる。１００％のＣＰＵ使用率でもその大半が有効な仕事のために使用されていなければ、そのサーバは省エネ化のための検討対象とすべきである。ＰＵＥ（Power Usage Effectiveness）（非特許文献１参照）などを使用する従来の技術では、仕事の内訳が見えないのでこのような判断をすることができなかったが、運用管理装置１０１０を使用すると可能となる。
【０１３９】
また例えば、消費電力および有効仕事量の両者が共に低いサーバがある場合、使用状況だけを見ていると消費電力が低いので省エネ的によいサーバに見え、このサーバに対しては何ら対策がなされない可能性が高い。しかしながら、運用管理装置１０１０を使用して使用状況と仕事量とが対比可能な形で提示される場合、有効仕事量も低いことが分かるので、データセンタの効率を向上してさらなる省エネ化を進めるために、例えば仮想化により他の高負荷サーバから仕事を回す等の対策を取ることができる。したがって、データセンタの省エネ化への寄与は大きい。
【０１４０】
また例えば、有効仕事量的には問題ないが排熱の大きなサーバがある場合にそれを見つけることができる。したがって、そのようなサーバがホットアイルに存在する場合には他の位置に移設したほうがよいことをサーバの持ち主に提案できる。
【０１４１】
また、運用管理装置１０１０では、フィルタ部１２６は、フィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。したがって、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減できる。
【０１４２】
また、フィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。つまり、一度に全てのノードを計測対象とするのではなく、例えば月曜日は第１サーバ群１０２２ａ、火曜日は第２サーバ群１０２２ｂ、等のように計測対象のノードを順番に変えてゆく。これにより、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減した上で、ネットワークの全てのノードを計測対象とすることができる。
【０１４３】
仮想化が行なわれているサーバについて考える。従来では主に、ＶＭＯＴＩＯＮ機能等を使用して、親（ホスト）仮想化ＯＳの上での個々のサーバイメージ（個々のゲストＯＳ）のプロセッサ使用率を取得して比較する。そして、ゲストＯＳを他のプロセッサ使用率的に空いている仮想化ホストＯＳサーバへ移設させている。しかしながら、このように単にプロセッサ使用率のみを尺度として仮想化サーバ間のゲストＯＳの移動を行う場合には、実際にゲストＯＳで行われている仕事の内訳までは考慮されていない。したがって、有効仕事量に基づいた移設が行われているとは言い難い。
【０１４４】
運用管理装置１０１０を使用して仮想化されたサーバにおける仕事を解析する場合、仮想化のプラットフォームごとに仕事量が分かるので、有効仕事量に基づいた精度の高いゲストＯＳの移設が可能となる。
また、例えば仮想化したことによってどの程度状況が改善されているかを知ることができる。つまり、有効仕事量と消費電力とについて仮想化の前後で比較することで、改善の度合いを知ることができる。また、仮想化後は個々のゲストＯＳが行っている仕事についてはあまり注意されないのが現状であるが、解析装置１００で各ゲストＯＳについて有効仕事量を追跡することにより、例えば時と共に使用されなくなったゲストＯＳを特定できる。したがって、そのように特定されたゲストＯＳを外すことで他のゲストＯＳの性能を改善できる。これはデータセンタの効率の向上に貢献する。
【０１４５】
従来ではシステム運用者は、システムを運用するにあたり、主にサーバのプロセッサ使用率やメモリの利用度を使用してサーバの性能を評価し、その性能評価を軸にして、サーバの統合、アプリケーションの移設、分配、統合、サーバの更新（新しい機器に交換する・買い換える）を行っている。しかしながら、特に昨今の景気低迷期では、サーバのさらなる有効利用やさらなる消費電力の低減によって一段とデータセンタ全体の運用コストを下げることが求められている。
そこで、運用管理装置１０１０を使用することにより、サーバにおける仕事が内向け（対サーバ）か、外向け（サーバ発）なのかを詳細に解析でき、また、その仕事がデータセンタ外部への仕事なのかデータセンタ内の他のサーバやアプリケーションに対する仕事なのかも解析できる。したがって、この解析を元にして、省エネ化のための精度の高いサーバ統合、分配、アプリケーション統合、分配、機器の更新、増強、廃止などが行える。
【０１４６】
以上、実施の形態に係る運用管理装置１０１０の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１４７】
実施の形態では、ユーザ端末１００６からサーバ群１０２２へのパケットの流れを基に説明したが、サーバ群１０２２からユーザ端末１００６へパケットを返すときもロードバランサ１０３０が適宜接続保持部１３２４を参照してアドレス変換できることは本明細書に触れた当業者には明らかである。
【０１４８】
実施の形態では、アクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、および第３しきい値Ｔ３が稼動状態のサーバ群の数を決めるしきい値となる場合について説明したが、これに限られない。例えば、それぞれのしきい値にヒステリシスを持たせてもよい。この場合、予測総アクセス数がしきい値付近で変動しても、しきい値をまたぐ毎にサーバ群の状態を切り替えなくてもよいので、状態切替に伴うオーバヘッドを低減できる。その結果情報処理システム２全体のレスポンスが向上しうる。
【０１４９】
実施の形態では、サーバ群１０２２をどの状態に置くかについて、状態設定部１１４０において表１に示されるストラテジが使用される場合について説明したが、これに限られない。例えば、省電力状態としてＯＳ休眠状態を使用し、電源オフ状態を使用しなくてもよい。この場合、電源オンオフにかかる比較的長いオーバヘッドがなくなるので、より早いレスポンスが期待できる。また、処理が簡素化される。別の例としては、省電力状態として電源オフ状態を使用し、ＯＳ休眠状態を使用しなくてもよい。この場合、消費電力をより低減できる。
【０１５０】
実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている場合について説明したが、これに限られない。個々のサーバ群は少なくともひとつのサーバを含めばよく、例えば、サーバ群はフロントエンドサーバとアプリケーションサーバとデータベースサーバの機能を全て併せ持つ１台のサーバを含んでもよい。また、サーバ群は、それら３つのサーバの機能のうちの任意の２つの機能を併せ持つサーバと、残りの機能を持つサーバと、を含んでもよい。
【０１５１】
実施の形態では、負荷予測部１１３４は属性をキーとする場合について説明したが、時間帯であってもよい。負荷予測部１１３４は、負荷履歴保持部１１１２を参照し、予測対象の時間帯に対して過去の同月同日の同じ時間帯の負荷履歴を取得し、これを基に予測対象の時間帯の予測総アクセス数を決定する。例えば、負荷予測部１１３４が２００９年７月２８日の９：１５〜９：３０における総アクセス数を予測する場合、負荷予測部１１３４は２００８年７月２８日の９：１５〜９：３０における総アクセス数（図１４の場合、５４００）を負荷履歴保持部１１１２から取得し、それを予測総アクセス数とする。
【０１５２】
実施の形態では、情報処理システム２が使用される例として証券業務や検索エンジンを挙げたが、これに限られない。本実施の形態に係る技術的思想は、例えば不特定多数のユーザが利用するコンピュータセンタの機器の管理に適用されうる。このコンピュータセンタの例としては、大学等の学術関係で、多くの生徒や研究者が利用するサーバとストレージのシステムがある。
図２２は、本発明のある実施の形態を大学の共用データセンタに適用した場合の負荷履歴保持部１１１２ｃを示すデータ構造図である。この場合、仕事量の傾向をより正確に把握するために大学のスケジュールに応じた属性が選択されることが望ましい。
【０１５３】
実施の形態では、要求処理ユニットがサーバ群である場合について説明したが、これに限られない。本実施の形態に係る技術思想は例えばＧＳＬＢ（Global Server Load Balance）にも応用されうる。そこでは、要求処理ユニットはそれ自体が複数の並列に配されたサーバ群を有するシステムであってもよい。また、実施の形態では要求はユーザからのアクセスである場合について説明したが、これに限られず、本実施の形態に係る技術思想が適用されるシステムによって異なってもよい。要求とは処理主体への処理の指示であるとも言える。
【０１５４】
実施の形態では、サーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとして、そのサーバ群１０２２のフロントエンドサーバ（ＷＥＢサーバ）１０２４の平均消費電力、最高消費電力、電力コストを採用する場合について説明したが、これに限られない。例えば、サーバ群１０２２に含まれる各サーバの電力コストを算出し、それを平均した値をそのサーバ群１０２２の電力コストとして採用してもよい。
【０１５５】
実施の形態では、例えば図１８に示されるように、指標算出部１００においてパケットの傍受（Ｓ４０２）からデータの集計（Ｓ４１２）が一連の処理として行われる場合について説明したが、これに限られない。例えば、指標算出部は、パケットの傍受からデータの分類までを随時行って分類結果のデータを蓄積し、所定の条件が満たされると分類結果のデータを集計してもよい。ここで所定の条件は、例えば前回の集計から所定の期間が経過したこと、もしくは分類結果のデータの量が所定の量に達したことである。
【０１５６】
図２３は、変形例に係る指標算出部における一連の処理を示すフローチャートである。変形例に係る指標算出部は、傍受部と、抽出部と、登録部と、通信情報保持部と、分類部と、分類結果保持部と、集計部と、を備える。傍受部は、ネットワークからパケットを傍受する（Ｓ５０２）。抽出部は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ５０４）。登録部は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部に登録する（Ｓ５０６）。分類部は、通信情報保持部に保持されるデータを始点アドレスでソーティングする（Ｓ５０８）。分類部は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ５１０）。分類部は、分類結果を分類結果保持部に登録する（Ｓ５１２）。所定の条件が満たされていない場合（Ｓ５１４のＮ）、ステップＳ５０２に処理が戻る。これにより、所定の条件が満たされるまで分類結果が分類結果保持部に蓄積されてゆく。所定の条件が満たされた場合（Ｓ５１４のＹ）、集計部は、分類結果保持部に蓄積されたデータを集計する（Ｓ５１６）。
本変形例によると、所定の条件を変えることにより、集計の母集団として使用する分類結果データの量を調整できる。したがって、集計の結果得られる指標に対して求められている精度に応じて柔軟に分類結果データの量を調整できる。
【０１５７】
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。
【符号の説明】
【０１５８】
２ 情報処理システム、 １００ 指標算出部、 １０２ ネットワークインタフェース部、 １０４ 通信情報保持部、 １０８ 第１指標保持部、 １１０ 使用状況取得部、 １１２ 使用状況保持部、 １１４ 係数保持部、 １１６ 第１解析部、 １１８ 第２指標保持部、 １２０ 表示制御部、 １３０ 集計部、 １３２ 分類部、 １３８ ノード情報保持部、 １４０ モニタ、 １５２ 第２解析部、 １５８ 第３指標保持部、 １００６ ユーザ端末、 １０１０ 運用管理装置、 １０２０ 情報処理装置、 １０３０ ロードバランサ、 １１３０ 学習部、 １１４０ 状態設定部、 １１５０ 乖離判定部、 １１６０ オーバライド部。
【技術分野】
【０００１】
本発明は、運用管理装置および情報処理システムに関する。
【背景技術】
【０００２】
地球温暖化と言う問題が、昨今聞かれる。地球温暖化対策の一つとしては電力需要を減らすことがある。電力は一般的に水力発電、太陽光発電、風力発電、地熱発電などの自然由来の発電や、原子力を使う原子力発電や、ガス、石油、石炭などを燃料として燃やし発電を行う火力発電によって供給されている。この中でも特に火力発電は地球温暖化を進める大きな要因となっている。電力需要を減らせば火力発電の発電量も減らすことができるので、その分地球温暖化も抑止されうる。
【０００３】
ＩＴ（Information Technology）やＩＣＴ（Information and Communication Technology）の分野でも、コンピュータやネットワーク機器、データセンタ機器が消費する電力を低減する必要性が指摘され始めている。
【０００４】
近年のインターネットの普及により、多くのデータセンタは、ネットワーク接続型の形態を有しており、インターネットなどの外部のネットワークからの仕事要求を受けて処理を行う。これらのデータセンタのなかには、一度に多くのアクセスを処理するために複数の並列に配置されたサーバを備える構成を採用したものがある（特許文献１参照）。
【０００５】
このようなデータセンタを管理する運用管理システムとしては、株式会社野村総合研究所が提供する千手（登録商標）や株式会社日立製作所が提供するＯｐｅｎＴＰ１００１（登録商標）や富士通株式会社が提供するシステムウォーカーがある。
また、ネットワーク接続装置の消費電力低減装置が知られている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００８−２２５７９３号公報
【特許文献２】特開２００７−９７１２６号公報
【非特許文献】
【０００７】
【非特許文献１】The Green Grid Association、［online］、インターネット＜URL：http://www.thegreengrid.org＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
現行の運用管理システムはロードバランサを備え、アクセス数が少ない場合でも個々のサーバに要求を分散させる。そのようなロードバランサには、それに接続されているサーバに均等にアクセスを分配するものが多い。この場合、各サーバの処理能力や省エネの度合いは無視された形でアクセスが分配されうる。
【０００９】
サーバの特性について、製造年月日や機器の種類やメーカや装備（メモリ、ディスク）や電源ユニットなどの違いにより、処理能力や省エネの度合いはサーバごとに異なる場合が多い。例えば、同じＷＥＢ（World Wide Web）サーバで同じプロセスを走らせた場合でも、メーカが異なればそのプロセスで消費される電力は異なりうる。したがって、現行の運用管理システムにおけるアクセスの分配の方法は、省エネ化の観点からは必ずしも最適な方法とは言えない。
【００１０】
本発明はこうした課題に鑑みてなされたものであり、その目的は、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる運用管理技術の提供にある。
【課題を解決するための手段】
【００１１】
本発明のある態様は運用管理装置に関する。この運用管理装置は、複数の要求処理ユニットがネットワークで接続されることによって構成された情報処理装置に対する要求の負荷の履歴を保持する負荷履歴保持部と、負荷履歴保持部を参照して今後発生する負荷を予測する負荷予測部と、負荷予測部によって予測された負荷が所定の第１しきい値より少ない場合、少なくともひとつの要求処理ユニットを、要求を受付可能な第１状態よりも省電力の第２状態に設定する状態設定部と、ネットワークから得られる情報から、複数の要求処理ユニットの稼動状況が示された指標を算出する指標算出部と、を備える。状態設定部は、指標算出部によって算出された指標に基づいて、第２状態に設定する要求処理ユニットを選択する。
【００１２】
「要求」とは、例えば情報処理装置に対する処理の要求であってもよい。
「負荷」とは、例えば要求の量を示す値であってもよい。
【００１３】
この態様によると、指標算出部によって算出された指標に基づいて、第２状態に設定する要求処理ユニットを選択できる。
【００１４】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１５】
本発明によれば、複数の要求処理ユニットで並列的に要求を処理する際の消費電力を低減できる。
【図面の簡単な説明】
【００１６】
【図１】実施の形態に係る運用管理装置を備える情報処理システムを示す概略図である。
【図２】図１におけるアクセスの流れを説明するための説明図である。
【図３】図１のロードバランサの機能および構成を示すブロック図である。
【図４】図３の接続保持部を示すデータ構造図である。
【図５】図３の第１サーバ群状態保持部を示すデータ構造図である。
【図６】図１の運用管理装置の機能および構成を示すブロック図である。
【図７】図６の通信情報保持部に保持されるデータの一例を示すデータ構造図である。
【図８】図６のサーバ情報保持部に保持されるデータの一例を示すデータ構造図である。
【図９】図６の第１指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１０】図６の使用状況保持部に保持されるデータの一例を示すデータ構造図である。
【図１１】図６の係数保持部に保持されるデータの一例を示すデータ構造図である。
【図１２】図６の第２指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１３】図６の第３指標保持部に保持されるデータの一例を示すデータ構造図である。
【図１４】図６の負荷履歴保持部を示すデータ構造図である。
【図１５】図１５（ａ）〜（ｄ）は、ステータス画面の代表画面図である。
【図１６】警告画面の代表画面図である。
【図１７】状態設定画面の代表画面図である。
【図１８】図６の指標算出部における一連の処理を示すフローチャートである。
【図１９】図６の学習部および状態設定部における一連の処理を時系列に沿って示すチャートである。
【図２０】図１の情報処理システムが証券会社のインターネット株取引システムを提供するデータセンタとして使用される場合の、負荷履歴保持部の一例を示すデータ構造図である。
【図２１】図１の情報処理システムが検索サービスを提供するデータセンタとして使用される場合の、負荷履歴保持部の一例を示すデータ構造図である。
【図２２】ある実施の形態を大学の共用データセンタに適用した場合の負荷履歴保持部を示すデータ構造図である。
【図２３】変形例に係る指標算出部における一連の処理を示すフローチャートである。
【発明を実施するための形態】
【００１７】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１８】
実施の形態に係る運用管理装置は、複数の並列に配置されたサーバ群でユーザからのアクセスを処理している情報処理システムの管理サーバとして好適に利用される。運用管理装置は、ネットワークから情報処理システム宛に到来する要求の負荷を過去の運用実績から予測し、その予測値が少ない場合は不必要なサーバ群のＯＳを休眠させたり、サーバ群の電源自体をオフにする。また、サーバ群の電力特性は使用する機種等により異なる場合があるが、運用管理装置はネットワークを傍受することにより各サーバ群の電力特性を計測する。これにより例えば電力効率が悪いサーバ群からＯＳを休眠させたり電源をオフにしたりすることができ、情報処理システムが総合的に省エネ化される。
【００１９】
図１は、実施の形態に係る運用管理装置１０１０を備える情報処理システム２を示す概略図である。情報処理システム２は、ネットワーク接続型のデータセンタであり、例えば証券会社のインターネット株取引システムを提供するデータセンタである。情報処理システム２は、運用管理装置１０１０と、情報処理装置１０２０と、ロードバランサ１０３０と、を備える。情報処理装置１０２０は、第１サーバ群１０２２ａと、第２サーバ群１０２２ｂと、第３サーバ群１０２２ｃと、第４サーバ群１０２２ｄと、第５サーバ群１０２２ｅと、を含む。第１サーバ群１０２２ａは、第１フロントエンドサーバ１０２４ａと、第１アプリケーションサーバ１０２６ａと、第１データベースサーバ１０２８ａと、を含む。第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、および第５サーバ群１０２２ｅは、それぞれ第１サーバ群１０２２ａと同等の構成を有する。
【００２０】
以下、第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃ、第４サーバ群１０２２ｄ、第５サーバ群１０２２ｅ、はサーバ群１０２２と総称される場合がある。また、第１フロントエンドサーバ１０２４ａ、第２フロントエンドサーバ１０２４ｂ、第３フロントエンドサーバ１０２４ｃ、第４フロントエンドサーバ１０２４ｄ、第５フロントエンドサーバ１０２４ｅ、はフロントエンドサーバ１０２４と総称される場合がある。また、第１アプリケーションサーバ１０２６ａ、第２アプリケーションサーバ１０２６ｂ、第３アプリケーションサーバ１０２６ｃ、第４アプリケーションサーバ１０２６ｄ、第５アプリケーションサーバ１０２６ｅ、はアプリケーションサーバ１０２６と総称される場合がある。また、第１データベースサーバ１０２８ａ、第２データベースサーバ１０２８ｂ、第３データベースサーバ１０２８ｃ、第４データベースサーバ１０２８ｄ、第５データベースサーバ１０２８ｅ、はデータベースサーバと総称される場合がある。
【００２１】
情報処理システム２は、外部ネットワーク１００４と接続され同じく外部ネットワーク１００４に接続されている少なくともひとつのユーザ端末１００６から要求を受ける。ここで要求とは、例えばユーザ端末１００６からのアクセスである。アクセスとは、ユーザ端末１００６と情報処理システム２のひとつのサーバ群１０２２とが接続を確立して一連の情報をやりとりすることである。異なるユーザ端末からのアクセスは異なるアクセスであり、同じユーザ端末１００６からでも異なるアクセスがなされうる。
外部ネットワーク１００４は、例えばＬＡＮ（Local Area Network）・ＷＡＮ（Wide Area Network）・インターネットである。ユーザ端末１００６は、ユーザが使用するコンピュータであり、例えば有線で外部ネットワーク１００４に接続された家庭用デスクトップコンピュータや、無線で外部ネットワーク１００４に接続されたラップトップコンピュータである。
【００２２】
ロードバランサ１０３０は、外部ネットワーク１００４と接続され、また情報処理装置１０２０に含まれる個々のサーバ群１０２２と内部ネットワーク３を介して接続される。ロードバランサ１０３０は、データの流れの観点からは情報処理装置１０２０と外部ネットワーク１００４との間に位置し、外部ネットワーク１００４からの情報処理装置１０２０に対するアクセスを仲介する。
ロードバランサ１０３０はさらに、情報処理装置１０２０に含まれる複数のサーバ群１０２２のうちアクセスを受付可能な状態（以下、稼動状態と称する）に設定されたサーバ群に、ユーザからのアクセスを割り当てる。なお、サーバ群１０２２の状態として、稼動状態と省電力状態とが基本的に規定される。
【００２３】
運用管理装置１０１０は、情報処理装置１０２０およびロードバランサ１０３０を管理する管理サーバである。運用管理装置１０１０は以下で説明する負荷予測機能などの他に、例えば株式会社野村総合研究所が提供する先手（登録商標）と同様のサーバ運用管理のための機能を搭載する。
【００２４】
運用管理装置１０１０は、外部ネットワーク１００４、ロードバランサ１０３０、内部ネットワーク３、のそれぞれを通過するパケットを傍受する。また運用管理装置１０１０は、各サーバ群１０２２の内部でやりとりされるパケットも傍受する。これは例えば、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とを接続するサブネットや、アプリケーションサーバ１０２６とデータベースサーバ１０２８とを接続するサブネットに解析装置１００が接続されることによって実現される。内部ネットワーク３は、各サーバ群１０２２のサーバを相互接続するこれらのサブネットを含む。
「傍受する」ことは、傍受対象のパケットを消滅させることなくその内容を取得することであってもよく、例えばパケットをそれに含まれる終点ＩＰアドレスによらずに取得することであってもよい。
運用管理装置１０１０は、傍受したパケットの内容を蓄積し、ＩＰアドレスでソートすることで各ＩＰアドレスに対応するサーバやロードバランサ１０３０における仕事の内訳を導出する。
【００２５】
運用管理装置１０１０は、例えば各サーバに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから、各サーバに供給された電力の計測値を取得し蓄積する。運用管理装置１０１０は、蓄積された電力の計測値および上記の仕事の内訳から、サーバ群１０２２の稼働状況が示された指標、例えばサーバ群１０２２における単位有効仕事量あたりの消費電力を算出する。
【００２６】
運用管理装置１０１０は、外部ネットワーク１００４から情報処理装置１０２０へのアクセスによる負荷を算出し記録する一方、過去に要求された負荷をもとに今後発生する負荷を予測する。運用管理装置１０１０は、その予測された負荷が所定の値より少なくなると、算出されたサーバ群１０２２の稼働状況が示された指標に基づいて、稼動状態にあるサーバ群のうちアクセスの処理に不要なサーバ群を選択し、選択されたサーバ群を稼動状態よりも省電力の省電力状態に設定する。
【００２７】
ここで負荷とは、例えばサーバ群１０２２が行う仕事の量を表す値であり、単位時間当たりのアクセスの数を基に定められる。例えば負荷は、単位時間当たりのアクセスの数と比例関係などの数学的関係を有する値であってもよい。また、負荷は単位時間当たりのアクセスの数に上限値または下限値若しくはその両方を課した値であってもよい。以下では、負荷が単に単位時間当たりのアクセスの数（以下、アクセス数と称す）である場合について説明する。
なお、負荷が所定の値以上の場合は運用管理装置１０１０は全てのサーバ群１０２２を稼動状態に設定する。
【００２８】
情報処理装置１０２０は、外部ネットワーク１００４からのアクセスを処理する。情報処理装置１０２０は、複数のサーバ群１０２２を含み、そのそれぞれのサーバ群１０２２はアクセスの処理単位である要求処理ユニットとして機能する。
本実施の形態では、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）プロトコルにしたがった通信が行われる場合を考える。
【００２９】
サーバ群１０２２はいわゆる３階層のサーバ群であり、これら１セットでアクセスの処理単位を構成する。フロントエンドサーバ１０２４は、ＷＥＢサーバとも呼ばれ、ＨＴＴＰ（HyperText Transfer Protocol）に則り、ユーザ端末１００６のＷＥＢブラウザに対して、ＨＴＭＬ（HyperText Markup Language）や画像などのオブジェクトの表示を提供するサービスが動作するサーバコンピュータである。アプリケーションサーバ１０２６は、フロントエンドサーバ１０２４からジャバサーブレット（Java Servlet、ジャバは登録商標）の処理などのアプリケーションに関する機能を切り出して実現するサーバコンピュータである。データベースサーバ１０２８は、アプリケーションサーバ１０２６のアプリケーションが使用するデータが格納されるサーバコンピュータである。フロントエンドサーバ１０２４、アプリケーションサーバ１０２６、およびデータベースサーバ１０２８は、公知の情報処理技術を使用して実現される。本実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている。
【００３０】
サーバ群１０２２のフロントエンドサーバ１０２４は内部ネットワーク３を介して運用管理装置１０１０およびロードバランサ１０３０と接続される。各サーバ群１０２２は運用管理装置１０１０によって管理されている。
【００３１】
なお、個々のサーバ群１０２２に含まれるサーバは個々にもしくは全体としてＯＳに管理されている。個々のサーバ群の稼動状態は、ユーザからのアクセスを即時処理可能な状態である。この状態は、サーバ群１０２２がユーザからのアクセスを処理しつつ新たなアクセスを処理可能である状態と、ユーザからのアクセスがなく仕事が発生していないアイドル状態と、を含む。稼動状態では、たとえアイドル状態であっても少なくとも基本ＯＳ機能とネットワークモニタリングのタスクは稼動しており、その分電力を消費する。本発明者の当業者としての経験から、このアイドル状態での消費電力は、サーバ機器の種類によってピークアクセス数での稼動時のおよそ３０％から７０％の範囲にある。特に、最新のブレードサーバでは、その高密度な回路構成と狭いスペースに多くの半導体素子が設置されている都合上、アイドル状態でも消費電力は大きくなる。一部のブレードサーバではアイドル状態においてピークアクセス数での稼動時の７０％もの電力を消費しているものも存在する。また、標準的なサーバ機器を用いる場合は６０％程度である。ここでピークアクセス数とは、サーバ群１０２２がその処理速度を落とさずに稼動できるアクセス数の範囲の上限値であり、サーバ群１０２２ごとにその仕様を基に予め定められている。ここで処理速度とは、サーバ群１０２２におけるユーザからのアクセスの処理速度である。
【００３２】
個々のサーバ群１０２２の省電力状態は、ユーザからのアクセスを即時処理できない状態である。この状態は、サーバ群１０２２へ電源は供給されているがそのサーバ群１０２２はユーザからのアクセスを処理できないＯＳ休眠状態を含む。サーバ群１０２２は運用管理装置１０１０から休眠導入信号を受信するとＯＳ休眠状態となる。このＯＳ休眠状態では、サーバ群１０２２のＯＳは休眠（ハイボネート）しており、ユーザからのアクセスがあってもそれを受け付けない。ＯＳ休眠状態にあるサーバ群１０２２は運用管理装置１０１０から休眠解除信号を受信すると、稼動状態に復帰する。ＯＳ休眠状態から稼動状態に復帰するためには通常数秒から数十秒かかる。また本発明者の当業者としての経験から、ＯＳ休眠状態におけるサーバ群１０２２の消費電力は、ピークアクセス数での稼働時のおよそ５％から１０％である。
【００３３】
サーバ群１０２２の省電力状態はさらに、サーバ群１０２２への電源が遮断されている電源オフ状態を含む。サーバ群１０２２は運用管理装置１０１０から電源オフ信号を受信すると電源オフ状態となる。サーバ群１０２２は運用管理装置１０１０からＷＯＬ（Wake Up on LAN）信号などの電源オン信号を受信すると、稼動状態に復帰する。電源オフ状態から稼動状態に復帰するためには通常数分かかる。
本実施の形態ではサーバ群１０２２が省電力状態から稼動状態に復帰するためにかかる時間（以下、オーバヘッドと称す）と、省電力状態で低減される消費電力とのかねあいで、省電力状態とされるサーバ群の数が決定される。つまり、現在のアクセス数を処理するのに必要なぎりぎりの数のサーバ群だけを稼動状態としていると、突然のアクセス数の増大に対して対処できなくなる可能性がある。一方で稼動状態のサーバ群の数が多いほど待機電力由来の消費電力も大きくなる。そこでそれらの影響が拮抗するように、省電力状態とされるサーバ群の数が決定される。
【００３４】
図２は、図１におけるアクセスの流れを説明するための説明図である。以下、１回のアクセスにおいて、少なくともひとつのパケットがユーザ端末１００６とアクセスが割り当てられたサーバ群との間でやりとりされる場合について説明する。このパケットは、送信元のＩＰアドレスである始点ＩＰアドレスと、受信先のＩＰアドレスである終点ＩＰアドレスと、シーケンス番号と、ポート番号と、タイムスタンプと、を含む。多くの場合において一回のアクセスにつき複数個のパケットがユーザ端末１００６とサーバ群との間を行き来する。図２では第３サーバ群１０２２ｃがアクセスに割り当てられたとする。ユーザ端末１００６のＩＰアドレスを「１７５．３４．１１．２１」、ロードバランサ１０３０のＩＰアドレスを「１００．１０．１０．１０」、第３サーバ群１０２２ｃに含まれる第３フロントエンドサーバ１０２４ｃのＩＰアドレスを「１２１．２１．１５．３」とする。
【００３５】
ロードバランサ１０３０は、ユーザ端末１００６に対して仮想サーバとして働く。つまり、外部ネットワーク１００４では、ユーザが情報処理装置１０２０が有する情報資源にアクセスしようとする場合、かかる情報資源のＵＲＬ（Uniform Resource Locator）がロードバランサ１０３０のＩＰアドレス「１００．１０．１０．１０」に名前解決されるよう設定されている。
【００３６】
まずユーザは、ユーザ端末１００６のウェブブラウザに対して情報処理装置１０２０が有する情報資源のＵＲＬを指定する。ユーザ端末１００６のウェブブラウザによって始点ＩＰアドレスを「１７５．３４．１１．２１」、終点ＩＰアドレスを「１００．１０．１０．１０」とした第１パケットＰ１が生成され、外部ネットワーク１００４に送られる。ロードバランサ１０３０は第１パケットＰ１を受信し、稼動状態にあるサーバ群のなかから第３サーバ群１０２２ｃを選択してこのアクセスを割り当てる。ロードバランサ１０３０は、第１パケットＰ１の始点ＩＰアドレスはそのままにして終点ＩＰアドレスを「１２１．２１．１５．３」とした第２パケットＰ２を内部ネットワーク３に送出する。第３サーバ群１０２２ｃの第３フロントエンドサーバ１０２４ｃは自己宛の第２パケットＰ２を受信し、第２パケットＰ２のポート番号やそのパケットに搭載されるデータに基づき処理を行う。その処理の結果ユーザ端末１００６へ戻すべき情報は、始点ＩＰアドレスを「１２１．２１．１５．３」、終点ＩＰアドレスを「１７５．３４．１１．２１」とした第３パケットＰ３に含められ、第３フロントエンドサーバ１０２４ｃから内部ネットワーク３に送出される。ロードバランサ１０３０は第３パケットＰ３を受信する。ロードバランサ１０３０は、第３パケットＰ３の終点ＩＰアドレスはそのままにして始点ＩＰアドレスを「１００．１０．１０．１０」とした第４パケットＰ４を外部ネットワーク１００４に送る。ユーザ端末１００６は自己宛の第４パケットＰ４を外部ネットワーク１００４から受信する。
以下、ユーザ端末１００６からロードバランサ１０３０に送られるパケット（第１パケットＰ１）を総称して行きパケット、ロードバランサ１０３０から情報処理装置１０２０へ送られるパケット（第２パケットＰ２）を総称して割当パケットという。
【００３７】
図３は、ロードバランサ１０３０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００３８】
ロードバランサ１０３０は、第１サーバ群状態保持部１３２２と、接続保持部１３２４と、要求取得部１０３４と、要求割当部１０３６と、を備える。
第１サーバ群状態保持部１３２２は、現在設定されているであろうサーバ群１０２２の状態を記憶するテーブルである。第１サーバ群状態保持部１３２２の詳細は後述する。
【００３９】
接続保持部１３２４は、同一アクセス内のパケットは同じサーバ群へ送られること（以下、アクセスの同一性と称す）を保証するためのテーブルである。図４は、接続保持部１３２４を示すデータ構造図である。接続保持部１３２４には、後述する接続更新部１３６８によってアクセスに対応するエントリ１１１８が生成される。一回のアクセスに対してひとつのエントリが対応する。接続保持部１３２４のエントリ１１１８は、アクセスしてきたユーザ端末１００６のＩＰアドレスであるユーザ端末ＩＰアドレス１２１０と、ロードバランサ１０３０のＩＰアドレスであるロードバランサＩＰアドレス１２１２と、ロードバランサ１０３０によってそのアクセスに割り当てられたサーバ群のフロントエンドサーバのＩＰアドレスである割当サーバ群ＩＰアドレス１２１４と、ユーザ端末１００６が同一の場合にアクセスの異同を判別するためのシーケンス番号１２１６と、を有する。同一ユーザ端末において、異なるアクセスには異なるシーケンス番号が割り振られる。以下、サーバ群のフロントエンドサーバのＩＰアドレスを単にサーバ群のＩＰアドレスと称す。
【００４０】
図３に戻る。要求取得部１０３４は、外部ネットワーク１００４と接続される。要求取得部１０３４は、外部ネットワーク１００４から到来するユーザ端末１００６からのアクセスの行きパケットを取得する。この際、要求取得部１０３４は行きパケットに含まれる終点ＩＰアドレスを基に自己宛のパケットであるか否かを判別する。要求取得部１０３４は、取得した行きパケットを要求割当部１０３６に渡す。
【００４１】
なお、本明細書において「渡す」とは、ある機能ブロックからある機能ブロックに情報要素に対する処理が移ることを意味する。要求取得部１０３４と要求割当部１０３６との間で言うと、渡すとは、例えば要求取得部１０３４が図示しない一時メモリを有し、取得した行きパケットをそこに蓄えた上で、要求割当部１０３６からの要請に応じて適宜行きパケットを一時メモリから要求割当部１０３６に伝達することである。また渡すとは、第１記憶装置１０３２が図示しない記憶領域を有し、要求取得部１０３４は取得した行きパケットをその記憶領域に書き込み、要求割当部１０３６は適宜その記憶領域から必要な行きパケットを読み出して処理することであってもよい。
【００４２】
要求割当部１０３６は、ユーザ端末１００６からのアクセスの行きパケットを稼動状態にあるサーバ群のうちのひとつに割り当てる。特に傾斜配分モードでは、ユーザ端末１００６からのアクセスが新規のアクセスである場合、要求割当部１０３６は運用管理装置１０１０から取得する指標に基づいて、その新規のアクセスをサーバ群のうちのひとつに割り当てる。要求割当部１０３６は、同一接続判断部１３６２と、サーバ群選択部１３６４と、アドレス変換部１３６６と、接続更新部１３６８と、を含む。
【００４３】
同一接続判断部１３６２は、要求取得部１０３４から行きパケットを取得し、その行きパケットが新規のアクセスによるものか否かを判別する。同一接続判断部１３６２は、取得した行きパケットの始点ＩＰアドレスとシーケンス番号とを読み取る。同一接続判断部１３６２は、読み取られた始点ＩＰアドレスとシーケンス番号とをキーとして接続保持部１３２４のエントリを検索し、それらと一致するエントリが存在する場合、そのエントリに含まれる割り当てられたサーバ群の割当サーバ群ＩＰアドレスを取得する。同一接続判断部１３６２は、この取得された割当サーバ群ＩＰアドレスと行きパケットとをアドレス変換部１３６６に渡す。
【００４４】
なお、このように一致するエントリが存在する場合は、当該行きパケットは既にあるサーバ群１０２２（エントリの割当サーバ群ＩＰアドレスで指定されるサーバ群１０２２）に割り当てられたアクセスのなかのひとつのパケットである。アドレス変換部１３６６は、渡された行きパケットの終点ＩＰアドレスを、同一接続判断部１３６２によって接続保持部１３２４から取得された割当サーバ群ＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１３６６から割当パケットとして内部ネットワーク３に送出される。
【００４５】
一致するエントリが存在しない場合は、同一接続判断部１３６２は当該行きパケットをサーバ群選択部１３６４に渡す。この場合は同一接続判断部１３６２は新規のアクセスを検知したと言うことができる。
【００４６】
サーバ群選択部１３６４は、同一接続判断部１３６２から新規のアクセスに対応する行きパケットを受け取ると、第１サーバ群状態保持部１３２２を参照してそのアクセスを処理させるサーバ群１０２２を選択する。第１サーバ群状態保持部１３２２は、運用管理装置１０１０におけるアクセス数の予測および算出される指標に基づき運用管理装置１０１０によって更新される。
【００４７】
図５は、第１サーバ群状態保持部１３２２を示すデータ構造図である。第１サーバ群状態保持部１３２２は、サーバ群１０２２のＩＰアドレス１２０２と、サーバ群１０２２の状態１２０４と、サーバ群１０２２の稼働率１２０６と、サーバ群１０２２の電力コスト１２０７と、を対応付けて保持する。
【００４８】
サーバ群１０２２の稼働率１２０６は、サーバ群１０２２のピークアクセス数に対する現在そのサーバ群１０２２が処理しているアクセス数の割合を％単位で示す。この稼働率は、図示されない稼働率更新部によって、予め定められているサーバ群１０２２のピークアクセス数と、接続保持部１３２４から分かるサーバ群１０２２に現在割り当てられているアクセス数とから演算され更新されてもよい。あるいは、図示されない稼働率更新部が稼動状態にあるサーバ群１０２２から稼働率を取得し、第１サーバ群状態保持部１３２２の稼働率を更新してもよい。あるいはまた、第１サーバ群状態保持部１３２２の稼働率は運用管理装置１０１０によって更新されてもよい。
【００４９】
サーバ群１０２２の電力コスト１２０７は、ＷＥＢ通信用の単位仕事量に対する消費電力を表す。単位仕事量は、例えば単位データ量であってもよく、１つのアクセスであってもよい。サーバ群１０２２の電力コストがＷＥＢ通信用の単位データ量に対する消費電力を表す場合、この電力コストが１（Ｗ／ＧＢ）であることは、ＷＥＢサーバにおいて１ＧＢ分のＷＥＢ通信用のデータを処理するのに１Ｗ消費することを示す。ＷＥＢ通信用のデータ量をＷＥＢサーバに対する負荷と考えると、電力コストは、各ＷＥＢサーバにおいて同じ負荷（単位データ量）がかけられた場合にそのＷＥＢサーバで消費される電力を示す。
第１サーバ群状態保持部１３２２の電力コストの値は、運用管理装置１０１０によって更新される。
【００５０】
図３に戻る。サーバ群選択部１３６４は、第１サーバ群状態保持部１３２２に登録されたサーバ群のなかからサーバ群の状態を参照して稼動状態にあるサーバ群を抽出する。要求割当部１０３６が省電力モードに設定されているか通常モードに設定されているか傾斜配分モードに設定されているかによって、サーバ群選択部１３６４が稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択するアルゴリズムは異なる。以下それぞれの場合について説明する。
【００５１】
１．省電力モード
省電力モードでは、サーバ群選択部１３６４は、稼動状態にあるサーバ群の稼働率が１００％となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する。例えば図５の例では、サーバ群選択部１３６４は新規のアクセスを処理させるサーバ群として第３サーバ群１０２２ｃを選択する。また、例えば第１サーバ群１０２２ａ、第２サーバ群１０２２ｂ、第３サーバ群１０２２ｃが稼動状態に設定されており、第１サーバ群１０２２ａの稼働率が１００％、第２サーバ群１０２２ｂの稼働率が８０％、第３サーバ群１０２２ｃの稼働率が０％の場合、サーバ群選択部１３６４は新規のアクセスを処理させるサーバ群として第２サーバ群１０２２ｂを選択する。
【００５２】
２．通常モード
通常モードでは、サーバ群選択部１３６４は、予め情報処理システム２の管理者によって設定されている負荷分散アルゴリズムにしたがって、新規のアクセスを処理させるのに最適なサーバ群を選択する。ここで使用される負荷分散アルゴリズムは、順番にサーバ群１０２２が選択されるラウンドロビン方式や、処理しているアクセス数が最小のサーバ群を選択する最小接続方式や、１番早く応答しているサーバ群を選択する最速方式などの公知のアルゴリズムである。
【００５３】
３．傾斜配分モード
傾斜配分モードでは、サーバ群選択部１３６４は、第１サーバ群状態保持部１３２２を参照し、稼動状態にあるサーバ群から、新規のアクセスを処理させるサーバ群として電力コストが小さいサーバ群を優先的に選択する。
【００５４】
サーバ群選択部１３６４は、は、選択されたサーバ群のＩＰアドレスと新規のアクセスに対応する行きパケットとをアドレス変換部１３６６に渡す。アドレス変換部１３６６は、渡された行きパケットの終点ＩＰアドレスを、サーバ群選択部１３６４によって選択されたサーバ群のＩＰアドレスに変換する。このように終点ＩＰアドレスが変換された行きパケットはアドレス変換部１３６６から割当パケットとして内部ネットワーク３に送出される。
【００５５】
接続更新部１３６８は、サーバ群選択部１３６４で新規のアクセスに対してサーバ群１０２２の選択が行われる毎に、その選択に関する情報をサーバ群選択部１３６４から取得し、接続保持部１３２４に対応するエントリを追加する。この選択に関する情報は、新規のアクセスを行ったユーザのユーザ端末１００６のユーザ端末ＩＰアドレスと、ロードバランサＩＰアドレスと、新規のアクセスに対して選択されたサーバ群の割当サーバ群ＩＰアドレスと、シーケンス番号と、を含む。
また、接続更新部１３６８は、適宜不要となったエントリを削除する。
【００５６】
図６は、運用管理装置１０１０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
【００５７】
運用管理装置１０１０は、指標算出部１００と、指標送信部１５４と、表示制御部１２０と、負荷履歴保持部１１１２と、第２サーバ群状態保持部１１１４と、学習部１１３０と、状態設定部１１４０と、乖離判定部１１５０と、オーバライド部１１６０と、を備える。
【００５８】
指標算出部１００は、外部ネットワーク１００４、ロードバランサ１０３０および内部ネットワーク３から得られる情報から、複数のサーバ群１０２２の稼動状況が示された指標を算出する。
指標算出部１００は、ネットワークインタフェース部１０２と、通信情報保持部１０４と、分類部１３２と、集計部１３０と、第１指標保持部１０８と、係数保持部１１４と、第１解析部１１６と、使用状況取得部１１０と、使用状況保持部１１２と、第２指標保持部１１８と、第２解析部１５２と、第３指標保持部１５８と、を含む。
【００５９】
ネットワークインタフェース部１０２は、傍受部１２２と、抽出部１２４と、フィルタ部１２６と、登録部１２８と、を含む。
傍受部１２２は、外部ネットワーク１００４とロードバランサ１０３０と内部ネットワーク３とからパケットを傍受する。抽出部１２４は、傍受部１２２によって傍受されたパケットから始点ＩＰアドレスと終点ＩＰアドレスとポート番号とシーケンス番号とを抽出する。
【００６０】
以下、ロードバランサ１０３０またはサーバ群１０２２またはサーバ群１０２２のサーバをノードと呼ぶ場合がある。
フィルタ部１２６は、フィルタ機能がオンとされるフィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。より具体的にはフィルタ部１２６は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくとも一方が計測対象のノードのＩＰアドレスと一致する場合にのみ、抽出元のパケットを登録部１２８に出力する。
【００６１】
特にフィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。すなわち、フィルタ部１２６は、計測対象のノードのＩＰアドレスを、情報処理システム２に含まれる複数のノードのＩＰアドレスのなかで順番に切り替える。
フィルタ部１２６は、フィルタ機能がオフとされるフィルタリングオフモードでは、抽出部１２４によって始点ＩＰアドレスと終点ＩＰアドレスとポート番号とシーケンス番号とが抽出されたパケットを登録部１２８に出力する。
【００６２】
登録部１２８は、フィルタ部１２６によって出力されたパケットについて、そのパケットに関する時刻と、抽出部１２４によってそのパケットから抽出された始点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出された終点ＩＰアドレスと、抽出部１２４によってそのパケットから抽出されたポート番号に対応する通信用途と、そのパケットのデータ量と、抽出部１２４によってそのパケットから抽出されたシーケンス番号と、を対応付けて通信情報保持部１０４に登録する。
【００６３】
図７は、通信情報保持部１０４に保持されるデータの一例を示すデータ構造図である。通信情報保持部１０４は、時刻２０２と、始点ＩＰアドレス２０４と、終点ＩＰアドレス２０６と、通信用途２０８と、データ量２１０と、シーケンス番号２１１と、を対応付けて保持する。
時刻２０２は、パケットに関する時刻であり、例えばパケットにタイムスタンプが含まれているのであればそのタイムスタンプで示される時刻である。あるいはまた、傍受部１２２によってパケットが傍受された時刻であってもよい。
始点ＩＰアドレス２０４および終点ＩＰアドレス２０６およびシーケンス番号２１１はそれぞれ、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスおよびシーケンス番号である。
通信用途２０８は、抽出部１２４によって抽出されたポート番号に対応する通信用途である。
データ量２１０は、パケットに搭載されているデータの量をバイト（Ｂ）単位で示す。
【００６４】
図６に戻る。分類部１３２は、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスのうちの少なくともひとつとポート番号とによってパケットを分類する。以下では分類部１３２が始点ＩＰアドレスとポート番号とによってパケットを分類する場合について説明する。しかしながら、分類部が終点ＩＰアドレスとポート番号とによってパケットを分類する場合、および分類部が始点および終点ＩＰアドレスとポート番号とによってパケットを分類する場合でも以下と同様の説明が成り立つことは、本明細書に触れた当業者には明らかである。
【００６５】
分類部１３２は、通信情報保持部１０４に保持されるデータを始点ＩＰアドレスについてソーティングする。以下、通信情報保持部１０４に登録されている始点ＩＰアドレスを登録ＩＰアドレスと称す。分類部１３２は、各登録ＩＰアドレスについて通信用途によってパケットを分類する。特に分類部１３２は、サーバ情報保持部１３８を参照し、登録ＩＰアドレスに対応するノード（以下、登録ノードと称す）に対して予め定められた通信用途である本来用途に関する情報を取得する。分類部１３２は、その本来用途に対応したパケットと、本来用途以外の通信用途である非本来用途に対応したパケットとに分類する。本来用途は、例えば登録ノードがＷＥＢサーバであれば、ポート番号「８０」に対応するＷＥＢ通信である。非本来用途は、例えば本来用途以外の通信用途であり、登録ノードがＷＥＢサーバであればポート番号「２０」に対応するＦＴＰ転送などである。
【００６６】
図８は、サーバ情報保持部１３８に保持されるデータの一例を示すデータ構造図である。サーバ情報保持部１３８は、ノードのノード名２１４と、ノードのＩＰアドレス２１８と、ノードの用途２２４と、を対応付けて保持する。
分類部１３２は、サーバ情報保持部１３８を参照してあるノードの本来用途に関する情報を取得する際、そのノードの用途を参照して本来用途を取得してもよい。
【００６７】
図６に戻る。集計部１３０は、少なくともひとつの登録ノードについて、本来用途に対応したパケットを集計する。特に集計部１３０は、所定の長さの期間すなわち時間帯ごとに、登録ノードの本来用途に対応したパケットのデータ量を集計し、また非本来用途に対応したパケットのデータ量を集計する。
例えば、登録ＩＰアドレス「121.21.15.1」に対応する登録ノードについて、時間帯「02/15/10 11:10:00~11:20:00」で集計する場合について考える。図８のサーバ情報保持部１３８から登録ノードは第１フロントエンドサーバ１０２４ａでありＷＥＢサーバである。集計部１３０は、分類部１３２における分類結果から、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」であり、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、本来用途に対する集計結果を得る。また、集計部１３０は、始点ＩＰアドレスが「121.21.15.1」であり、通信用途が「ＷＥＢ通信」ではなく、時刻が時間帯「02/15/10 11:10:00~11:20:00」に含まれるパケットのデータ量を足し合わせて、非本来用途に対する集計結果を得る。
【００６８】
集計部１３０は、少なくともひとつの登録ノードについて、始点ＩＰアドレスと終点ＩＰアドレスとシーケンス番号とを参照して時間帯ごとのアクセスの数を算出する。集計部１３０は算出されたアクセスの数を時間帯の長さで除すことで、その登録ノードにおけるその時間帯でのアクセス数を算出する。
なお、集計部１３０は、ロードバランサ１０３０については、情報処理システム２の外部から情報処理装置１０２０全体へのアクセス数（以下、総アクセス数と称す）を算出する。つまり、集計部１３０は、情報処理システム２の外部の端末のＩＰアドレスを始点ＩＰアドレスとし、ロードバランサ１０３０のＩＰアドレスを終点ＩＰアドレスとするパケットを集計することで、ロードバランサ１０３０についての総アクセス数を算出する。
集計部１３０は、集計結果および算出結果を第１指標保持部１０８に登録する。
【００６９】
図９は、第１指標保持部１０８に保持されるデータの一例を示すデータ構造図である。第１指標保持部１０８は、登録ノードのノード名２２８と、登録ノードの本来用途２３０と、本来用途に対応するポート番号である主なポート番号２３２と、本来用途データ量２３４と、非本来用途データ量２３６と、集計部１３０で使用される所定の長さの期間すなわち時間帯に対応する計測期間２３８と、アクセス数２３９と、を対応付けて保持する。
本来用途データ量２３４は、登録ノードの本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
非本来用途データ量２３６は、登録ノードの非本来用途に対応したパケットのデータ量を計測期間内で足し合わせた結果のデータ量である。
【００７０】
図６に戻る。使用状況取得部１１０は、内部ネットワーク３を通じて所定の時間間隔もしくはリアルタイムで、情報処理システム２のノードから、そのノードの使用状況に関する情報を取得する。ノードの使用状況は、例えばノードがフロントエンドサーバ（ＷＥＢサーバ）１０２４やアプリケーションサーバ１０２６であれば消費電力（単位はＷ）や機器の温度（単位は℃）やＣＰＵ使用率（単位は％）であり、ノードがデータベースサーバ１０２８であればデータ転送量（単位はＭＢ／秒）や消費電力や機器の温度であり、ノードがロードバランサ１０３０などのネットワーク機器であればデータ転送量や消費電力や機器の温度である。
【００７１】
使用状況取得部１１０は、サーバの基本ＯＳに搭載されているシステムパフォーマンスモニタのデータを取得してもよい。
使用状況取得部１１０は、各ノードに電力を供給するバスバー方式のテーブルタップ型のＰＤＵから各ノードに供給された電力の計測値を消費電力として取得してもよい。
使用状況取得部１１０は、ノードの温度を計測できる市販の装置（温度センサや、光ファイバ方式の温度センサ）と、その温度データを記憶して報告するデータ収集機能（市販されているソフトウエアパッケージ、またはサーバ組み込み型の特殊ハードウエアパッケージ）と、を利用して機器の温度を取得してもよい。
【００７２】
あるいはまた、使用状況取得部１１０は、米国ＥＰＡのEnergy Star for Server 2で登録し認定されるノードからは、下記の３つの報告機能を使用して消費電力と機器の温度とＣＰＵ使用率とを取得する。すなわち、米国のＥＰＡが行っているEnergy Star for Server 2では、登録し認定される機器は、３つの報告機能をハードウエア本体のマイクロコード（ファームウエア）のレベルで提供でき、基本ＯＳや他の計測ソフト、アプリケーションや本来のサーバの処理能力（本体のＣＰＵ・ＭＰＵ（Micro Processing Unit））には、影響を与えないハードウエアの管理機能を持つこととされている。この３つの報告機能は、１）サーバの実電力消費数値、２）サーバの本体ＣＰＵ・ＭＰＵ等の処理用プロセッサの使用率、３）サーバの実稼動の温度、である。
【００７３】
使用状況取得部１１０は、取得した使用状況に関する情報と、それを取得した時刻に対応する時間帯と、取得先のノード名と、ＩＰアドレスと、を対応付けて使用状況保持部１１２に登録する。使用状況取得部１１０が所定の時間間隔で情報を取得する場合は、時間帯は例えば取得した時刻から所定の時間間隔が経過するまでの期間に設定される。あるいはまた、使用状況取得部１１０がリアルタイムで情報を取得する場合は、所定の長さを有する期間を時間帯とし、使用状況に関する情報をその期間で時間平均する。
【００７４】
図１０は、使用状況保持部１１２に保持されるデータの一例を示すデータ構造図である。使用状況保持部１１２は、使用状況取得部１１０によって使用状況が取得されたノードのノード名２４４と、ＩＰアドレス２４５と、使用状況が取得された時刻に対応する記録時間帯２４６と、取得された消費電力２４８と、取得された機器温度２５０と、取得されたＣＰＵ使用率２５２と、取得されたデータ転送量２５３と、を対応付けて保持する。
【００７５】
一般的に、ＷＥＢサーバにおいて、所定の量、例えば１ｋＢのＷＥＢ通信用のデータを処理して送るにはどれだけのＣＰＵ使用率が必要かは測定できる。つまり、ＷＥＢサーバについて、ＷＥＢ通信用のデータ量とＣＰＵ使用率との関係は事前に測定できる。係数保持部１１４はその関係を示す係数（例えば、％・分／ＧＢの単位）を保持する。この係数が１である場合、例えば１ＧＢ分のＷＥＢ通信用のデータを処理して送るためにＷＥＢサーバは１％のＣＵＰ使用率で１分間稼動しなければならないことを意味する。
【００７６】
図１１は、係数保持部１１４に保持されるデータの一例を示すデータ構造図である。係数保持部１１４は、ＷＥＢサーバのサーバ名２４０と、係数２４２と、を対応付けて保持する。
【００７７】
図６に戻る。第１解析部１１６は、第１算出部１３４と、第２算出部１３６と、第１合成部１４２と、を含む。
第１算出部１３４は、第１指標保持部１０８に登録される登録ノードのうちＷＥＢサーバ（以下、登録ＷＥＢサーバと称す）について、本来用途データ量すなわちＷＥＢ通信用のデータ量を対応する計測期間の長さ、例えば分を単位とする長さ、で除し、ＷＥＢ通信用の時間平均データ量（例えば、ＧＢ／分の単位）を得る。第１算出部１３４は、係数保持部１１４からその登録ＷＥＢサーバに対応する係数を取得する。第１算出部１３４は、その登録ＷＥＢサーバについて、ＷＥＢ通信用の時間平均データ量と係数とを乗算し、乗算の結果得られる値（例えば、％の単位）を、その登録ＷＥＢサーバおよび計測期間における、ＷＥＢ通信に関する処理によるＣＰＵ使用率の推測値（以下、第１推測値と称す）とする。
【００７８】
例えば、図９の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第１算出部１３４は、計測期間「02/15/10 11:10:00~11:20:00」におけるＷＥＢ通信用のデータ量として「５００（ＧＢ）」を得る。第１算出部１３４は、「５００（ＧＢ）」を計測期間の長さ「１０（分）」で除し、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」を得る。第１算出部１３４は、図１１の係数保持部１１４を参照し、係数「１．５（％・分／ＧＢ）」を得る。第１算出部１３４は、ＷＥＢ通信用の時間平均データ量「５０（ＧＢ／分）」と係数「１．５（％・分／ＧＢ）」とを乗算し「７５（％）」を得る。第１算出部１３４は、この値「７５（％）」をノード名「第１フロントエンドサーバ」のＷＥＢサーバにおける計測期間「02/15/10 11:10:00~11:20:00」中のＷＥＢ通信に関する処理による第１推測値とする。
【００７９】
第２算出部１３６は、第１算出部１３４における第１推測値の計算で対象とされた登録ＷＥＢサーバのサーバ名と計測期間とをキーとして使用状況保持部１１２を検索し、対応する消費電力と機器温度とＣＰＵ使用率とを抽出する。第２算出部１３６は、第１推測値を使用状況保持部１１２から抽出したＣＰＵ使用率から減じ、ＷＥＢ通信に関する処理以外の処理によるＣＰＵ使用率の推測値（以下、第２推測値と称す）とする。
ＷＥＢ通信に関する処理以外の処理は、例えば他の通信に関する処理や、ウイルスチェッカーによるウイルススキャンや、ハードディスクドライブへのデータの書き込みである。あるいはまた、アイドル状態にあってなにも仕事をしていないことも考えられる。
【００８０】
第２算出部１３６は、抽出された消費電力を第１推測値と第２推測値との比に分け、第１推測値に対応する値をＷＥＢ通信に関する処理のために使用された電力の推測値、第２推測値に対応する値をそうでない処理のために使用された電力の推測値とする。機器温度についても、機器温度と外気温との差を第１推測値と第２推測値との比に分ける点で同様である。
【００８１】
例えば、図９の第１指標保持部１０８に登録されるノード名「第１フロントエンドサーバ」に着目すると、第２算出部１３６は図１０に示される使用状況保持部１１２から、ノード名「第１フロントエンドサーバ」と計測期間「02/15/10 11:10:00~11:20:00」とに対応する消費電力「３０（Ｗ）」、機器温度「３５（℃）」、ＣＰＵ使用率「８０（％）」を抽出する。第２算出部１３６は、第１推測値「７５（％）」をＣＰＵ使用率「８０（％）」から減じ、第２推測値「５（％）」を得る。第２算出部１３６は、消費電力「３０（Ｗ）」を第１推測値「７５（％）」と第２推測値「５（％）」との比すなわち１５：１に分け、ＷＥＢ通信に関する処理のために使用された電力の推測値「２８（Ｗ）」とそれ以外の処理のために使用された電力の推測値「２（Ｗ）」と、を得る。
【００８２】
第１合成部１４２は、時刻およびノード名をキーとして、第１指標保持部１０８に保持されるデータと、使用状況保持部１１２に保持されるデータと、第２算出部１３６による計算結果（登録ＷＥＢサーバについての、ＷＥＢ通信処理由来の消費電力、ＷＥＢ通信処理由来の上昇温度、ＷＥＢ通信処理由来のＣＰＵ使用率）と、を対応付けて第２指標保持部１１８に登録する。
【００８３】
図１２は、第２指標保持部１１８に保持されるデータの一例を示すデータ構造図である。第２指標保持部１１８は、ノード名２５４と、本来用途２５６と、主なポート番号２５８と、本来用途データ量２６０と、非本来用途データ量２６２と、計測期間２６４と、消費電力２６６と、機器温度２６８と、ＣＰＵ使用率２７０と、データ転送量２７１と、ＷＥＢ通信由来消費電力２７２と、ＷＥＢ通信由来上昇温度２７４と、ＷＥＢ通信由来ＣＰＵ使用率２７６と、を対応付けて保持する。
ＷＥＢ通信由来消費電力２７２は、第２算出部１３６によって算出された、ＷＥＢ通信に関する処理のために使用された電力の推測値である。ＷＥＢ通信由来上昇温度２７４は、第２算出部１３６によって算出された、機器温度と外気温との差のうちＷＥＢ通信に関する処理によって上昇したと予測される分である。ここでは外気温は２５（℃）とされている。ＷＥＢ通信由来ＣＰＵ使用率２７６は、第１算出部１３４によって算出された第１推測値である。
【００８４】
図６に戻る。第２解析部１５２は、第２指標保持部１１８に保持されるデータのうちＷＥＢサーバ（フロントエンドサーバ１０２４）に関するデータを、使用状況取得部１１０における所定の時間間隔よりも長い時間間隔、例えば１ヶ月や半年の時間間隔で統計処理する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、消費電力の時間平均である平均消費電力と、統計処理対象の期間内における消費電力の最高値である最高消費電力と、を算出する。
第２解析部１５２は、第２指標保持部１１８に登録されているノードのうちＷＥＢサーバについて、ＷＥＢ通信由来の消費電力の時間平均を本来用途データ量（ＷＥＢ通信用のデータ量）の時間平均で除し、電力コスト（例えば、Ｗ／ＧＢの単位）を算出する。
第２解析部１５２は、サーバ名と、平均消費電力と、最高消費電力と、電力コストと、を対応付けて第３指標保持部１５８に登録する。
【００８５】
図１３は、第３指標保持部１５８に保持されるデータの一例を示すデータ構造図である。第３指標保持部１５８は、サーバ名３０４と、平均消費電力３０６と、最高消費電力３０８と、電力コスト３１０と、を対応付けて保持する。
【００８６】
図６に戻る。表示制御部１２０は、第１指標保持部１０８、第２指標保持部１１８、第３指標保持部１５８のうちの少なくともひとつに基づき、ノードごとに各種パラメータを示す画面をモニタ１４０に表示させる。
【００８７】
指標送信部１５４は、第１サーバ群状態保持部１３２２の更新のために、第３指標保持部１５８に登録されている電力コストに関する情報をロードバランサ１０３０に送信する。
【００８８】
学習部１１３０は、更新部１１３２と、負荷予測部１１３４と、を含む。学習部１１３０は、更新部１１３２によって総アクセス数の履歴を負荷履歴保持部１１１２に記憶し、その記憶をふまえて負荷予測部１１３４によって今後発生しうる総アクセス数を予測する。これにより、運用実績が長いほど省エネの観点からより賢くなる運用管理が可能となる。
【００８９】
更新部１１３２は、第１指標保持部１０８から総アクセス数を取得する。更新部１１３２は、取得した総アクセス数をもとに負荷履歴保持部１１１２を更新する。負荷履歴保持部１１１２はしたがって、総アクセス数の履歴すなわち過去に要求された総アクセス数を保持する。
【００９０】
図１４は、負荷履歴保持部１１１２を示すデータ構造図である。負荷履歴保持部１１１２は、時間帯１２１８と、その時間帯が属する属性１２２０と、その時間帯に取得された総アクセス数１２２２と、その時間帯に稼動状態に設定される稼動サーバ群の数１２２４と、その時間帯の平均稼動率１２２６と、を対応付けて記憶する。時間帯が属する属性１２２０とは、例えば月曜日、火曜日などの曜日や、平日休日の別や、年末年始とそれ以外の別や、午前午後の別や、それらの任意の組み合わせである。平均稼働率１２２６は、稼動状態に設定されるサーバ群の稼働率の平均値である。
更新部１１３２は、稼動状態に設定される稼動サーバ群の数１２２４を取得するために第２サーバ群状態保持部１１１４を参照してもよい。
時間帯１２１８は、運用管理装置１０１０のモードを更新する基準となる時間間隔を有する期間である。
【００９１】
図６に戻る。負荷予測部１１３４は、過去に要求された総アクセス数をもとに今後発生する総アクセス数を予測する。負荷予測部１１３４は、未来の時間帯ごとに総アクセス数を予測する。後述の状態設定部１１４０もまた、この時間帯ごとに必要に応じてサーバ群１０２２の状態を設定する。特に負荷予測部１１３４は、総アクセス数予測の対象となる時間帯（以下、予測対象の時間帯と称す）について負荷履歴保持部１１１２を参照して総アクセス数を予測する。以下、負荷予測部１１３４によって予測される総アクセス数を予測総アクセス数と称す。
【００９２】
負荷予測部１１３４では、情報処理システム２が使用される目的に応じた総アクセス数の傾向（トレンド）を負荷履歴保持部１１１２から抽出する処理と、抽出された傾向に基づいて予測対象の時間帯の総アクセス数を予測する処理とが行われる。特に負荷予測部１１３４では、時間帯の属性をキーとして総アクセス数の傾向が抽出される。
【００９３】
負荷予測部１１３４は予測対象の時間帯が属する属性に対応する総アクセス数を負荷履歴保持部１１１２から取得してその時間帯に対する予測総アクセス数とする。
例えば、曜日がキーとして設定された場合、負荷予測部１１３４は負荷履歴保持部１１１２を参照し、曜日毎の総アクセス数の平均値を演算する。負荷予測部１１３４は、これらの平均値のうち予測対象の時間帯の曜日にマッチする曜日の平均値を予測総アクセス数とする。また、例えば平日休日の別がキーとして設定された場合、負荷予測部１１３４は負荷履歴保持部１１１２を参照し、平日の総アクセス数の平均値と休日の総アクセス数の平均値を演算する。負荷予測部１１３４は、これらの平均値のうち予測対象の時間帯が平日であれば平日の、休日であれば休日の平均値を予測総アクセス数とする。
なお、ここでは一例として平均値を用いたが、代表値などの他の統計的なパラメータであってもよい。
【００９４】
負荷予測部１１３４は予測総アクセス数を乖離判定部１１５０および状態設定部１１４０の負荷比較部１１４２に渡す。
【００９５】
状態設定部１１４０は、予測総アクセス数が所定のアクセスしきい値Ｍｏより少ない場合、予測対象の時間帯において情報処理装置１０２０に含まれる少なくともひとつのサーバ群１０２２を省電力状態に設定する。
【００９６】
状態設定部１１４０におけるモアクセスしきい値Ｍｏは、情報処理装置１０２０の性能が落ちない範囲に設定される。ここで性能とは、例えばどれだけのアクセス数をどの程度の速さで処理できるかということである。あるいは性能とは、ひとつのアクセスが処理されるのにかかる時間などのレスポンスタイムであってもよい。また、情報処理装置１０２０の性能が落ちる、とは、例えばあるサーバ群１０２２に対してピークアクセス数を越える数のアクセスが割り当てられ、その結果そのサーバ群１０２２の処理速度が落ちることにより情報処理装置１０２０全体のアクセスの処理速度が落ちることである。
【００９７】
例えば第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。この場合アクセスしきい値Ｍｏを９０００に設定すると、予測総アクセス数が８５００であっても予測対象の時間帯で少なくともひとつのサーバ群を省電力状態に設定しなくてはならない。ここでは第５サーバ群１０２２ｅを省電力状態に設定したとする。残りの４つのサーバ群１０２２ａ〜２２ｄのトータルのピークアクセス数は８０００であり、予測総アクセス数９５００よりも少ない。したがってこの場合、予測対象の時間帯が到来したときに、残りの４つのサーバ群１０２２ａ〜２２ｄのうちの少なくともひとつのサーバ群がピークアクセス数以上のアクセスを処理しなくてはならなくなる可能性が高くなり、その場合そのサーバ群の処理速度は低下する。これにより情報処理装置１０２０全体の処理速度が落ちる可能性がある。このような状況を避けるために、アクセスしきい値Ｍｏは情報処理装置１０２０の性能が落ちない範囲に設定される。上述の例ではアクセスしきい値Ｍｏは８０００以下に設定されればよい。
【００９８】
状態設定部１１４０は、サーバ群１０２２の最大性能を発揮せしめる前提で、アクセスを処理させるサーバ群を決定し、予測対象の時間帯において残りのサーバ群を省電力状態に設定する。この場合サーバ群１０２２の最大性能を発揮せしめる、とは、例えばサーバ群１０２２にピークアクセス数でアクセス処理を行わせることであり、言い換えるとサーバ群を１００％の稼働率で使用することである。さらに状態設定部１１４０は、予測総アクセス数の変動により情報処理装置１０２０の性能が落ちると予測される場合には、予測対象の時間帯において省電力状態に設定されている少なくともひとつのサーバ群を稼動状態に設定する。
【００９９】
サーバ群１０２２を省電力状態または稼動状態に設定することに関して、状態設定部１１４０では、予測対象の時間帯において稼動状態にするサーバ群の数に応じた予測総アクセス数の範囲が定められている。状態設定部１１４０は例えば予測総アクセス数が０から第１しきい値Ｔ１の範囲にあれば予測対象の時間帯においてひとつのサーバ群のみを稼動状態とし、他のサーバ群を省電力状態とする。表１は、状態設定部１１４０における状態設定に関して、稼動状態とするサーバ群の数と、ＯＳ休眠状態とするサーバ群の数と、電源オフ状態とするサーバ群の数と、予測総アクセス数の範囲と、の関係を示す。Ｔ２は第２しきい値、Ｔ３は第３しきい値であり、Ｔ１＜Ｔ２＜Ｔ３である。個々のしきい値は予め情報処理システム２の管理者によって設定される。
【表１】
【０１００】
第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３はそれぞれサーバ群１０２２を１００％の稼働率で使用することを前提に設定される。つまり上述の第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする例では、Ｔ１＝２０００、Ｔ２＝４０００、Ｔ３＝６０００である。この場合、予測総アクセス数のアクセスを処理するのに必要最低限の数のサーバ群が予測対象の時間帯において稼動状態とされる。また、例えば第１しきい値Ｔ１と第２しきい値Ｔ２との間にあった予測総アクセス数が増大して第２しきい値Ｔ２を越えた場合、そのままだと予測対象の時間帯において少なくともひとつのサーバ群の稼働率が１００％を上回ると予測されるので、予測対象の時間帯において稼動状態とするサーバ群の数をひとつ増やして情報処理装置１０２０の処理速度の低下を回避する。
【０１０１】
状態設定部１１４０は、負荷比較部１１４２と、稼動サーバ群決定部１１４４と、状態信号生成部１１４６と、を含む。
負荷比較部１１４２は、負荷予測部１１３４から取得した予測総アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、アクセスしきい値Ｍｏとの大小関係を判別する。この大小関係は例えば「Ｔ２＜予測総アクセス数＜Ｔ３」という情報である。負荷比較部１１４２はこの大小関係に関する情報を稼動サーバ群決定部１１４４に渡す。
【０１０２】
稼動サーバ群決定部１１４４は、この情報を基に表１のストラテジにしたがい、次の時間帯における状態の切替の必要性を判定する。稼動サーバ群決定部１１４４は、状態の切替が必要な場合には、指標算出部１００から取得する指標に基づいて、稼動状態とするサーバ群とＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群を決定する。稼動サーバ群決定部１１４４は次の時間帯の到来に合わせて、この決定に基づき第２サーバ群状態保持部１１１４およびロードバランサ１０３０の第１サーバ群状態保持部１３２２を更新する。稼動サーバ群決定部１１４４は、次の時間帯の到来に合わせて、状態の切り替えが必要なサーバ群の情報を状態信号生成部１１４６に渡す。稼動サーバ群決定部１１４４は、状態の切り替えが必要ない場合には処理を中断または終了し、次の情報を待ち受ける。
第２サーバ群状態保持部１１１４は図５に示される第１サーバ群状態保持部１３２２と同様のテーブルである。なお、運用管理装置１０１０またはロードバランサ１０３０のいずれか一方がサーバ群状態テーブルを備え、そのテーブルを備えない方が備える方のテーブルを参照する構成としてもよい。
【０１０３】
稼動サーバ群決定部１１４４は、表１のストラテジから稼動状態、ＯＳ休眠状態および電源オフ状態とするサーバ群の数をまず決める。次に稼動サーバ群決定部１１４４は第２サーバ群状態保持部１１１４を参照し、次の時間帯でサーバ群の状態を切り替える必要があるか、言い換えると負荷予測部１１３４が予測した次の時間帯での予測総アクセス数に対応する各状態のサーバ群の数と第２サーバ群状態保持部１１１４に登録されている現在の各状態のサーバ群の数とが一致するか否かを判断する。そこで一致する場合は稼動サーバ群決定部１１４４は処理を中断または終了する。
【０１０４】
一致しない場合は、稼動サーバ群決定部１１４４は次の時間帯でそれぞれの状態にするサーバ群を決める。稼動サーバ群決定部１１４４は、指標算出部１００の第３指標保持部１５８に保持されるデータを取得する。稼動サーバ群決定部１１４４は、取得したデータを基に各サーバ群１０２２に対して省電力状態とされる順番を示す省エネ停止可能順位を設定する。省エネ停止可能順位は「１」が最も高く、数が増えるにつれて低くなる順位である。
稼動サーバ群決定部１１４４では、第３指標保持部１５８に保持されるフロントエンドサーバ１０２４の平均消費電力、最高消費電力、電力コストを、そのフロントエンドサーバ１０２４が属するサーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとみなす。
【０１０５】
表２は、サーバ群１０２２の電力コストに基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表２】
表２のストラテジでは、サーバ群１０２２の電力コストが大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。電力コストが遜色ない２つのサーバ群が存在する場合は、平均消費電力や最高消費電力が高いほうのサーバ群の省エネ停止可能順位をより高く設定する（表２の第４サーバ群と第５サーバ群）。
【０１０６】
表３は、サーバ群１０２２の消費電力に基づき省エネ停止可能順位を定める場合の、サーバ群名と平均消費電力と最高消費電力と電力コストと省エネ停止可能順位との関係を示す。
【表３】
表３のストラテジでは、サーバ群１０２２の平均消費電力と最高消費電力との和が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定される。
情報処理装置１０２０において各サーバ群１０２２が主にＷＥＢ通信をおこなっており他の用途の処理は無視できる程度であり、またロードバランサ１０３０において稼動状態にあるサーバ群にアクセスが均等に割り当てられる設定となっている場合は、稼動状態にあるサーバ群には同じ負荷がかけられれていると考えることができる。したがって、稼動状態にある各サーバ群の平均消費電力は、同じ負荷がかけられれている場合に消費される電力の平均値と同一視することができ、また、稼動状態にある各サーバ群の最高消費電力は、同じ負荷がかけられれている場合に消費される電力の最高値と同一視することができる。この場合、表３のストラテジでは、サーバ群１０２２に同じ負荷がかけられた場合に消費される電力が大きいほど優先的にそのサーバ群１０２２が省電力状態とされるように省エネ停止可能順位が設定されているといえる。
【０１０７】
稼動サーバ群決定部１１４４は、稼動状態にあるサーバ群のひとつを省電力状態に切り替える必要がある場合、稼動状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も高いサーバ群を省電力状態とすべきサーバ群として選択する。
稼動サーバ群決定部１１４４は、省電力状態にあるサーバ群のひとつを稼動状態に切り替える必要がある場合、省電力状態にあるサーバ群のうち表２または表３で設定される省エネ停止可能順位が最も低いサーバ群を稼動状態とすべきサーバ群として選択する。
【０１０８】
なお、稼動サーバ群決定部１１４４でのサーバ群１０２２を決める上述のアルゴリズムでは、特に稼動状態を省電力状態に切り替える場合は、アクセスの同一性が考慮されてもよい。例えば、稼動サーバ群決定部１１４４は、稼動状態を省電力状態に切り替える場合、次の時間帯の到来に合わせて第２サーバ群状態保持部１１１４および第１サーバ群状態保持部１３２２を更新して省電力状態に切り替えるべきサーバ群への新規アクセスの割り当てを制限する一方、ロードバランサ１０３０の接続保持部１３２４を参照し、省電力状態に切り替えるべきサーバ群へのアクセスがなくなったことを確認してから状態の切り替えが必要なサーバ群の情報を状態信号生成部１１４６に渡してもよい。これによりアクセスの同一性が保証されうる。
【０１０９】
状態信号生成部１１４６は内部ネットワーク３を介して第１サーバ群１０２２ａ〜第５サーバ群１０２２ｅに接続される。
状態信号生成部１１４６は、状態の切り替えが必要なサーバ群の情報に基づきそのサーバ群に対して切替に対応する休眠導入信号、休眠解除信号、電源オフ信号、および電源オン信号のうちのいずれかを送る。例えば第３サーバ群１０２２ｃを稼動状態（ＯＳ休眠状態）からＯＳ休眠状態（稼動状態）とする必要がある場合、状態信号生成部１１４６は第３サーバ群１０２２ｃに対して休眠導入信号（休眠解除信号）を送出する。また、第３サーバ群１０２２ｃを稼動状態（電源オフ状態）から電源オフ状態（稼動状態）とする必要がある場合、状態信号生成部１１４６は第３サーバ群１０２２ｃに対して電源オフ信号（電源オン信号）を送出する。
状態信号生成部１１４６によって省電力状態から稼動状態に設定されたサーバ群は、それが稼動状態であることが稼動サーバ群決定部１１４４によってロードバランサ１０３０の第１サーバ群状態保持部１３２２に記録されるので、ロードバランサ１０３０の要求割当部１０３６によって新規のアクセスが割り当てられる。
【０１１０】
運用管理装置１０１０は、予測総アクセス数を基に状態設定部１１４０でサーバ群１０２２の状態を設定する上述の負荷予測モードの他に、第１指標保持部１０８に保持される総アクセス数を基に状態設定部１１４０でサーバ群１０２２の状態を適応的に設定する適応モードを有する。以下、この適応モードについて説明する。
【０１１１】
乖離判定部１１５０は、予測された総アクセス数と実際の総アクセス数との差が大きい、つまりその差の絶対値が所定の乖離値よりも大きい場合、状態設定部１１４０に実際の総アクセス数に基づいてサーバ群の状態を設定せしめる。
乖離判定部１１５０は、第１指標保持部１０８から現在の時間帯に対応する総アクセス数を取得する。また乖離判定部１１５０は負荷予測部１１３４から現在の時間帯に対して予測された予測総アクセス数も取得する。そして乖離判定部１１５０は、両者の差を演算する。その差の絶対値が乖離値より大きい場合は、乖離判定部１１５０は状態設定部１１４０の負荷比較部１１４２に、予測総アクセス数の代わりに第１指標保持部１０８からの総アクセス数を使用させる。この場合負荷比較部１１４２は、第１指標保持部１０８からの総アクセス数と、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３、アクセスしきい値Ｍｏとの大小関係を判別する。状態設定部１１４０はかかる大小関係を使用して上述の処理と同様の処理を行う。これにより状態設定部１１４０は、予測された総アクセス数と実際の総アクセス数との差が大きい場合に、実際の総アクセス数に応じて適応的にサーバ群１０２２の状態を設定することができる。
【０１１２】
また、運用管理装置１０１０は、情報処理システム２の管理者がマニュアルでサーバ群１０２２の状態を設定できるマニュアル設定モードも有する。
オーバライド部１１６０は、運用管理装置１０１０に付随するキーボードなどの入力装置１０１２から管理者によるマニュアル設定を受け付ける。オーバライド部１１６０はこのマニュアル設定を受け付けると状態設定部１１４０に、このマニュアル設定に基づいてサーバ群１０２２の状態を設定せしめる。これにより急激な使用環境の変化にも対応可能となる。
【０１１３】
表示制御部１２０は、第１指標保持部１０８から現在の時間帯における総アクセス数を、第２サーバ群状態保持部１１１４から現在のサーバ群１０２２の状態を、取得する。表示制御部１２０は、運用管理装置１０１０に付随するモニタ１４０に総アクセス数とサーバ群１０２２の状態とを示すステータス画面１４００ａ〜１４００ｄを表示させる。また、表示制御部１２０は、乖離判定部１１５０において予測された総アクセス数と実際の総アクセス数との差の絶対値が乖離値よりも大きいと判断された場合、モニタ１４０に警告画面１４０２を表示させる。また、表示制御部１２０は、管理者によるマニュアル設定のための状態設定画面１４０４をモニタ１４０に表示させる。
【０１１４】
図１５（ａ）〜（ｄ）は、ステータス画面１４００ａ〜１４００ｄの代表画面図である。ここでは、第１サーバ群１０２２ａから第５サーバ群１０２２ｅのピークアクセス数が全て２０００であるとする。また、稼動サーバ群決定部１１４４では表２のストラテジが使用され、サーバ群選択部１３６４では傾斜配分モードが使用される場合を考える。図１５（ａ）〜図１５（ｄ）はそれぞれ現在の時間帯における総アクセス数が１６００、２８００、４４００、７０００の場合に対応する。
図１５（ａ）は、現在の時間帯における総アクセス数が１６００の場合に対応するステータス画面１４００ａの代表画面図である。ステータス画面１４００ａは、総アクセス数領域１４０６と、グラフ１４０８と、オーバライドボタン１４１０と、を含む。総アクセス数領域１４０６は、現在の時間帯における総アクセス数を示す。グラフ１４０８は、各サーバ群１０２２の稼働率を示す。グラフ１４０８において「△」はＯＳ休眠状態を示し、「×」は電源オフ状態を示す。オーバライドボタン１４１０は、押し下げられるとオーバライド部１１６０をトリガする。オーバライドボタン１４１０が押し下げられると表示制御部１２０は状態設定画面１４０４をモニタ１４０に表示させる。図１５（ｂ）〜図１５（ｄ）についても同様である。
【０１１５】
図１６は、警告画面１４０２の代表画面図である。
図１７は、状態設定画面１４０４の代表画面図である。状態設定画面１４０４は、設定領域１４１２と、設定ボタン１４１４と、を含む。状態設定画面１４０４を開いた直後の状態では、設定領域１４１２には各サーバ群の現在の状態がラジオボタン方式で示されている。設定領域１４１２では第１サーバ群１０２２ａ〜第５サーバ群１０２２ｅはそれぞれサーバ群Ａ〜サーバ群Ｅという名称で表示されている。管理者はマウスなどの入力装置１０１２を使用して各サーバ群の状態を選択し、設定ボタン１４１４を押し下げる。すると設定領域１４１２に設定された各サーバ群１０２２の状態が所望のマニュアル設定としてオーバライド部１１６０に送られる。これにより、第１サーバ群１０２２ａ〜第５サーバ群１０２２ｅのそれぞれを稼動状態とするか、ＯＳ休眠状態とするか、または電源オフ状態とするかを設定できる。
【０１１６】
上述のロードバランサ１０３０や運用管理装置１０１０において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【０１１７】
以上の構成による運用管理装置１０１０の動作を説明する。図１８は、指標算出部１００における一連の処理を示すフローチャートである。傍受部１２２は、ネットワークからパケットを傍受する（Ｓ４０２）。抽出部１２４は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ４０４）。登録部１２８は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部１０４に登録する（Ｓ４０６）。分類部１３２は、通信情報保持部１０４に保持されるデータを始点アドレスでソーティングする（Ｓ４０８）。分類部１３２は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ４１０）。集計部１３０は、分類されたデータを集計する（Ｓ４１２）。第２解析部１５２は、集計結果から各サーバ群１０２２の電力コストを算出する（Ｓ４１４）。
【０１１８】
図１９は、学習部１１３０および状態設定部１１４０における一連の処理を時系列に沿って示すチャートである。更新部１１３２が第１指標保持部１０８から総アクセス数を取得する時間間隔は１５分間隔である場合を考える。２００９年９月１６日の９：１５に、更新部１１３２は第１指標保持部１０８から総アクセス数を取得する（Ｓ５０２）。更新部１１３２は、取得された総アクセス数をもとに負荷履歴保持部１１１２を更新する（Ｓ５０４）。一方、２００９年９月１６日の９：１５−９：３０の時間帯内でステップＳ５０４の負荷履歴保持部１１１２更新と重ならないときに、負荷予測部１１３４は負荷履歴保持部１１１２を参照して次の時間帯（１００９：３０−９：４５）の総アクセス数を予測する（Ｓ５０６）。状態設定部１１４０は、予測総アクセス数とアクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、第３しきい値Ｔ３との大小比較を行う（Ｓ５０８）。状態設定部１１４０は、その大小比較を基に次の時間帯においてサーバ群１０２２の状態の切替が必要か否かを判断する（Ｓ５１０）。状態の切替が必要でない場合（Ｓ５１０のＮ）、次の時間帯が到来してもサーバ群１０２２の状態の設定は行わない。状態の切替が必要な場合（Ｓ５１０のＹ）、状態設定部１１４０は省エネ停止可能順位に基づき、次の時間帯におけるサーバ群１０２２の状態を決定する（Ｓ５１２）。次の時間帯が到来すると、つまり２００９年９月１６日の９：３０になると、状態設定部１１４０はサーバ群の状態をステップＳ５１２で決定されたように設定する。また、状態設定部１１４０は平行して第２サーバ群状態保持部１１１４およびロードバランサ１０３０の第１サーバ群状態保持部１３２２を更新する（Ｓ５１４）。運用管理装置１０１０はこの処理を時間帯単位で繰り返す。
【０１１９】
本実施の形態に係る運用管理装置１０１０によると、データセンタなどの情報処理システム２が使用される目的、例えば証券業務や検索エンジンなど、に応じた総アクセス数の傾向を把握し、それを用いて今後発生しうる総アクセス数を予測できる。そしてこの予測総アクセス数が少ない場合は、予測対象の時間帯において少なくともひとつのサーバ群が省電力状態に設定される。
【０１２０】
上述した通り稼動状態のサーバ群の消費電力は、アイドル状態であってもピーク時のおよそ６０％である。これに対して省電力状態のサーバ群の消費電力はピーク時のおよそ０〜１０％である。本実施の形態では、アクセス数が少ないと予測され、したがってアクセスを処理する必要がないと予測されるサーバ群がある場合はそれらのサーバ群をアイドル状態ではなく省電力状態としている。これにより、情報処理装置１０２０全体の消費電力を低減でき、電力の無駄遣いを抑え、省エネ化を図ることができる。
【０１２１】
また本実施の形態に係る運用管理装置１０１０では、情報処理システム２が使用される目的に応じた総アクセス数の傾向を把握し、それを用いて今後発生しうる総アクセス数を予測しているので、個々の使用目的に対して最適な消費電力低減化、省エネ化を実現できる。
【０１２２】
さらに、本実施の形態に係る運用管理装置１０１０によると、指標算出部１００はネットワークを傍受して各サーバ群１０２２の特性の違いを示す指標を算出する。状態設定部１１４０は、少なくともひとつのサーバ群１０２２を省電力状態に設定する際、指標算出部１００によって算出されたこの指標に基づいて、省電力状態に設定するサーバ群を選択する。したがって、各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、稼動状態にあるサーバ群のなかから省電力状態とするサーバ群を選択できる。これにより、全てのサーバ群１０２２を特性上同等と見なした上で省電力状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。その結果、情報処理システム２の省エネ化を一層進めることができる。
【０１２３】
また、稼動サーバ群決定部１１４４は、電力コストが大きいサーバ群を省電力状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２４】
また、本実施の形態に係る運用管理装置１０１０によると、パケットをネットワークから傍受し、傍受したパケットを始点ＩＰアドレスとポート番号とで分類する。したがって、始点ＩＰアドレスごとおよびポート番号ごとに通信データ量を計測できる。これにより、所望の解析対象のノードについて、どの通信用途（メール通信やＷＥＢ閲覧など）に対応する仕事をどの程度行ったかを、そのノードに直接問い合わせることなしにネットワーク上を流れるパケットから追跡できる。ノードへ問い合わせないので、仕事量の解析に伴うノード側の負担はほとんどない。運用管理装置１０１０はネットワークの傍受を行うので、運用管理装置１０１０自身の測定への寄与は小さく、また把握できる。
【０１２５】
さらに本実施の形態では、更新部１１３２は指標算出部１００によって算出された総アクセス数に基づいて負荷履歴保持部１１１２を更新する。したがって、総アクセス数を予測するための履歴データを、サーバ側の負担をほとんど増やすことなしに得ることができる。
【０１２６】
また、本実施の形態では、稼動サーバ群決定部１１４４は、予測総アクセス数が所定の値より多くなると予測される場合には、指標算出部１００によって算出された指標に基づいて、省電力状態に設定されている複数のサーバ群のうちの少なくともひとつのサーバ群を選択する。状態信号生成部１１４６は、稼動サーバ群決定部１１４４によって選択された少なくともひとつのサーバ群を稼動状態に設定する。これにより、まず、サーバ群１０２２をピークアクセス数以上で使用しなければならない状況を回避し、アクセス処理の遅滞を避けることができる。さらに、各サーバ群１０２２の特性の違いの解析結果を取り入れた形で、省電力状態にあるサーバ群のなかから稼動状態とするサーバ群を選択できる。これにより、全てのサーバ群を特性上同等と見なした上で稼動状態とするサーバ群を選択する場合と比べて、選択に各サーバ群１０２２の特性の違いを反映できるので、省エネの観点からより好適なサーバ群１０２２の状態制御が可能となる。
【０１２７】
また、稼動サーバ群決定部１１４４は、電力コストが小さいサーバ群を稼動状態とするサーバ群として優先的に選択する。したがって、結果として稼動状態とされるサーバ群の電力コストは、省電力状態とされるサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２８】
また、本実施の形態では、ロードバランサ１０３０は、取得されたアクセスを、電力コストが小さいサーバ群に優先的に割り当てる。したがって、結果としてアクセスがより多く割り当てられるサーバ群の電力コストは、そうでないサーバ群の電力コストよりも小さくなるので、情報処理システム２全体で見たときに有効な仕事をより少ない消費電力で処理できる。
【０１２９】
また、本実施の形態に係る運用管理装置１０１０では、負荷履歴保持部１１１２は、取得された総アクセス数と、その総アクセス数が取得された時間帯が属する属性と、を対応付けて記憶する。したがって、総アクセス数の傾向を属性を基準にして把握することができる。さらに運用管理装置１０１０では、予測対象の時間帯が属する属性に対応する総アクセス数を負荷履歴保持部１１１２から取得してその時間帯に対して予測される総アクセス数とする。したがって、属性を情報処理システム２の使用目的に応じて適切に設定することにより、予測される総アクセス数の精度を向上することができる。
【０１３０】
図２０は、本実施の形態に係る情報処理システム２が証券会社のインターネット株取引システムを提供するデータセンタとして使用される場合の、負荷履歴保持部１１１２ａの一例を示すデータ構造図である。ここでは稼動サーバ群の数および平均稼動率は説明を明瞭とするため省略される。この場合の総アクセス数の傾向としては、証券取引所の取引時間内にアクセスが集中することがある。また、証券取引所が閉まってからしばらくはいわゆるバッチ処理を行うためにいくらかの仕事が発生する。それ以外で証券取引所が閉まっている時間帯、例えば休日などにはアクセスはほとんどない。あっても証券会社の顧客が自己の口座の情報を参照する程度である。したがって、図２０に示されるように、時間帯の属性として、証券取引所の取引時間にあたる時間帯に「取引時間」という属性を、バッチ処理が行われる時間帯に「バッチ処理」という属性を、それ以外の時間帯に「時間外」もしくは土日祝日の場合は「休日」を、それぞれ与えてもよい。このような属性を付与することで、証券会社のインターネット株取引システムを提供するデータセンタに発生する総アクセス数をより適切に予測することができる。
【０１３１】
図２１は、本実施の形態に係る情報処理システム２が検索サービスを提供するデータセンタとして使用される場合の、負荷履歴保持部１１１２ｂの一例を示すデータ構造図である。ここでは稼動サーバ群の数および平均稼動率は説明を明瞭とするため省略される。この場合の総アクセス数の傾向としては、平日よりも休日の方が利用が多く、また平日でも午前よりも午後の方が利用が多いことがある。したがって、図２１に示されるように、時間帯の属性として、平日休日の別と午前午後の別との組み合わせを与えてもよい。このような属性を付与することで、検索サービスを提供するデータセンタに発生する総アクセス数をより適切に予測することができる。
【０１３２】
本実施の形態に係る運用管理装置１０１０では、省電力モード（予測総アクセス数＜アクセスしきい値Ｍｏ）においては、表１に示される通りＯＳ休眠状態とするサーバ群と電源オフ状態とするサーバ群との両方を設けている。これにより、予測対象の時間帯において突然総アクセス数が増大した場合は、適応モードに移行した後復帰のためのオーバヘッドが小さいＯＳ休眠状態にあるサーバ群を稼動状態に戻すことで対応できる。また、そのように対応できる限りにおいては他のサーバ群は電力を消費しない電源オフ状態とし、情報処理装置１０２０全体の消費電力をさらに低減している。なお、表１ではＯＳ休眠状態とするサーバ群をひとつだけ確保しているが、この数はオーバヘッドと消費電力とのかねあいで定められればよく、適宜増減可能であることは本明細書に触れた当業者には理解される。
【０１３３】
本実施の形態に係る運用管理装置１０１０では、状態設定部１１４０はサーバ群の最大性能を発揮せしめる前提で、予測対象の時間帯において稼動状態とするサーバ群を決定する。このサーバ群の決定方式によると、所与の予測総アクセス数に対してより多くの数のサーバ群を省電力状態とすることができる。したがって、情報処理装置１０２０全体の消費電力をより低減できる。なお、稼働率によってサーバ群の消費電力が異なるのも事実ではあるが、上述の通りアイドル状態でもピーク時のおよそ６０％の電力が消費されることを考えると、稼働率を下げることによる電力削減効果よりもアイドル状態を省電力状態とすることによる電力削減効果のほうが大きいと考えられる。
【０１３４】
また、アクセスしきい値Ｍｏは情報処理装置１０２０の性能が落ちない範囲に設定される。これにより、予測総アクセス数が多い場合は通常モードで情報処理装置１０２０の並列処理能力をいかんなく発揮させ、予測総アクセス数が少なくなると省電力モードに移行させて性能を保ちつつ電力消費量を低減できる。
【０１３５】
また、本実施の形態に係る運用管理装置１０１０では、ＩＰアドレスは仕事の主体を示し、ポート番号は通信用途を示すので、それらを用いてノードで行われている仕事の内訳を導出し、特に有効仕事量を計測できる。この点、現実的に有効仕事量の計測が困難であった従来の技術とは大きく異なる。運用管理装置１０１０によると、ノードにおける仕事量を解析することで、そのノードが有効な仕事をどの程度行ったかを計測でき、情報処理システム２を省エネ化するためのよい指標が得られる。
【０１３６】
また、本実施の形態に係る運用管理装置１０１０では、通信情報保持部１０４に保持される傍受されたパケットの情報を本来用途と非本来用途とで分類する。したがって、図９の第１指標保持部１０８に示されるように、所望の解析対象のノードについて、本来用途データ量と非本来用途データ量とを得ることができる。これにより、両者の比率などから解析対象のノードがどの程度本来の用途で使用されているかを追跡できる。これは情報処理システム２を省エネ化するためのよい指標のひとつである。例えば、本来の用途で使用されていないノードを発見し、適切な処置を施すことで情報処理システム２の効率を向上できる。
【０１３７】
また、運用管理装置１０１０では、第２指標保持部１１８は、第１指標保持部１０８と使用状況保持部１１２とが対応付けられた形となっている。したがって、情報処理システム２の省エネ化を考える際に、ノードにおける仕事量と使用状況とを対応付けて把握できる。すなわち、ノードが何の仕事をいつどれだけ行ったことにより、どれだけのＣＰＵの処理能力を使用し、どれだけの電力を消費し、どれだけの温度上昇があったかを解析できる。
【０１３８】
例えば、ＣＰＵ使用率が１００％とされているサーバの仕事量の内訳を見ることにより、実際１００％のＣＰＵ使用率のうちどれだけが有効な仕事のために使用されたかを知ることができる。１００％のＣＰＵ使用率でもその大半が有効な仕事のために使用されていなければ、そのサーバは省エネ化のための検討対象とすべきである。ＰＵＥ（Power Usage Effectiveness）（非特許文献１参照）などを使用する従来の技術では、仕事の内訳が見えないのでこのような判断をすることができなかったが、運用管理装置１０１０を使用すると可能となる。
【０１３９】
また例えば、消費電力および有効仕事量の両者が共に低いサーバがある場合、使用状況だけを見ていると消費電力が低いので省エネ的によいサーバに見え、このサーバに対しては何ら対策がなされない可能性が高い。しかしながら、運用管理装置１０１０を使用して使用状況と仕事量とが対比可能な形で提示される場合、有効仕事量も低いことが分かるので、データセンタの効率を向上してさらなる省エネ化を進めるために、例えば仮想化により他の高負荷サーバから仕事を回す等の対策を取ることができる。したがって、データセンタの省エネ化への寄与は大きい。
【０１４０】
また例えば、有効仕事量的には問題ないが排熱の大きなサーバがある場合にそれを見つけることができる。したがって、そのようなサーバがホットアイルに存在する場合には他の位置に移設したほうがよいことをサーバの持ち主に提案できる。
【０１４１】
また、運用管理装置１０１０では、フィルタ部１２６は、フィルタリングモードでは、抽出部１２４によって抽出された始点ＩＰアドレスおよび終点ＩＰアドレスを基に、計測対象のノードのＩＰアドレスが含まれたパケットのみを選択して、登録部１２８に出力する。したがって、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減できる。
【０１４２】
また、フィルタ部１２６は、計測対象のノードを、情報処理システム２に含まれる複数のノードから順番に選択する。つまり、一度に全てのノードを計測対象とするのではなく、例えば月曜日は第１サーバ群１０２２ａ、火曜日は第２サーバ群１０２２ｂ、等のように計測対象のノードを順番に変えてゆく。これにより、計測に影響を与えない範囲で通信情報保持部１０４に保持されるデータの量を低減した上で、ネットワークの全てのノードを計測対象とすることができる。
【０１４３】
仮想化が行なわれているサーバについて考える。従来では主に、ＶＭＯＴＩＯＮ機能等を使用して、親（ホスト）仮想化ＯＳの上での個々のサーバイメージ（個々のゲストＯＳ）のプロセッサ使用率を取得して比較する。そして、ゲストＯＳを他のプロセッサ使用率的に空いている仮想化ホストＯＳサーバへ移設させている。しかしながら、このように単にプロセッサ使用率のみを尺度として仮想化サーバ間のゲストＯＳの移動を行う場合には、実際にゲストＯＳで行われている仕事の内訳までは考慮されていない。したがって、有効仕事量に基づいた移設が行われているとは言い難い。
【０１４４】
運用管理装置１０１０を使用して仮想化されたサーバにおける仕事を解析する場合、仮想化のプラットフォームごとに仕事量が分かるので、有効仕事量に基づいた精度の高いゲストＯＳの移設が可能となる。
また、例えば仮想化したことによってどの程度状況が改善されているかを知ることができる。つまり、有効仕事量と消費電力とについて仮想化の前後で比較することで、改善の度合いを知ることができる。また、仮想化後は個々のゲストＯＳが行っている仕事についてはあまり注意されないのが現状であるが、解析装置１００で各ゲストＯＳについて有効仕事量を追跡することにより、例えば時と共に使用されなくなったゲストＯＳを特定できる。したがって、そのように特定されたゲストＯＳを外すことで他のゲストＯＳの性能を改善できる。これはデータセンタの効率の向上に貢献する。
【０１４５】
従来ではシステム運用者は、システムを運用するにあたり、主にサーバのプロセッサ使用率やメモリの利用度を使用してサーバの性能を評価し、その性能評価を軸にして、サーバの統合、アプリケーションの移設、分配、統合、サーバの更新（新しい機器に交換する・買い換える）を行っている。しかしながら、特に昨今の景気低迷期では、サーバのさらなる有効利用やさらなる消費電力の低減によって一段とデータセンタ全体の運用コストを下げることが求められている。
そこで、運用管理装置１０１０を使用することにより、サーバにおける仕事が内向け（対サーバ）か、外向け（サーバ発）なのかを詳細に解析でき、また、その仕事がデータセンタ外部への仕事なのかデータセンタ内の他のサーバやアプリケーションに対する仕事なのかも解析できる。したがって、この解析を元にして、省エネ化のための精度の高いサーバ統合、分配、アプリケーション統合、分配、機器の更新、増強、廃止などが行える。
【０１４６】
以上、実施の形態に係る運用管理装置１０１０の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【０１４７】
実施の形態では、ユーザ端末１００６からサーバ群１０２２へのパケットの流れを基に説明したが、サーバ群１０２２からユーザ端末１００６へパケットを返すときもロードバランサ１０３０が適宜接続保持部１３２４を参照してアドレス変換できることは本明細書に触れた当業者には明らかである。
【０１４８】
実施の形態では、アクセスしきい値Ｍｏ、第１しきい値Ｔ１、第２しきい値Ｔ２、および第３しきい値Ｔ３が稼動状態のサーバ群の数を決めるしきい値となる場合について説明したが、これに限られない。例えば、それぞれのしきい値にヒステリシスを持たせてもよい。この場合、予測総アクセス数がしきい値付近で変動しても、しきい値をまたぐ毎にサーバ群の状態を切り替えなくてもよいので、状態切替に伴うオーバヘッドを低減できる。その結果情報処理システム２全体のレスポンスが向上しうる。
【０１４９】
実施の形態では、サーバ群１０２２をどの状態に置くかについて、状態設定部１１４０において表１に示されるストラテジが使用される場合について説明したが、これに限られない。例えば、省電力状態としてＯＳ休眠状態を使用し、電源オフ状態を使用しなくてもよい。この場合、電源オンオフにかかる比較的長いオーバヘッドがなくなるので、より早いレスポンスが期待できる。また、処理が簡素化される。別の例としては、省電力状態として電源オフ状態を使用し、ＯＳ休眠状態を使用しなくてもよい。この場合、消費電力をより低減できる。
【０１５０】
実施の形態では、フロントエンドサーバ１０２４とアプリケーションサーバ１０２６とデータベースサーバ１０２８とは別個のサーバであり、この順に直列に接続されている場合について説明したが、これに限られない。個々のサーバ群は少なくともひとつのサーバを含めばよく、例えば、サーバ群はフロントエンドサーバとアプリケーションサーバとデータベースサーバの機能を全て併せ持つ１台のサーバを含んでもよい。また、サーバ群は、それら３つのサーバの機能のうちの任意の２つの機能を併せ持つサーバと、残りの機能を持つサーバと、を含んでもよい。
【０１５１】
実施の形態では、負荷予測部１１３４は属性をキーとする場合について説明したが、時間帯であってもよい。負荷予測部１１３４は、負荷履歴保持部１１１２を参照し、予測対象の時間帯に対して過去の同月同日の同じ時間帯の負荷履歴を取得し、これを基に予測対象の時間帯の予測総アクセス数を決定する。例えば、負荷予測部１１３４が２００９年７月２８日の９：１５〜９：３０における総アクセス数を予測する場合、負荷予測部１１３４は２００８年７月２８日の９：１５〜９：３０における総アクセス数（図１４の場合、５４００）を負荷履歴保持部１１１２から取得し、それを予測総アクセス数とする。
【０１５２】
実施の形態では、情報処理システム２が使用される例として証券業務や検索エンジンを挙げたが、これに限られない。本実施の形態に係る技術的思想は、例えば不特定多数のユーザが利用するコンピュータセンタの機器の管理に適用されうる。このコンピュータセンタの例としては、大学等の学術関係で、多くの生徒や研究者が利用するサーバとストレージのシステムがある。
図２２は、本発明のある実施の形態を大学の共用データセンタに適用した場合の負荷履歴保持部１１１２ｃを示すデータ構造図である。この場合、仕事量の傾向をより正確に把握するために大学のスケジュールに応じた属性が選択されることが望ましい。
【０１５３】
実施の形態では、要求処理ユニットがサーバ群である場合について説明したが、これに限られない。本実施の形態に係る技術思想は例えばＧＳＬＢ（Global Server Load Balance）にも応用されうる。そこでは、要求処理ユニットはそれ自体が複数の並列に配されたサーバ群を有するシステムであってもよい。また、実施の形態では要求はユーザからのアクセスである場合について説明したが、これに限られず、本実施の形態に係る技術思想が適用されるシステムによって異なってもよい。要求とは処理主体への処理の指示であるとも言える。
【０１５４】
実施の形態では、サーバ群１０２２の平均消費電力、最高消費電力、電力コストのそれぞれとして、そのサーバ群１０２２のフロントエンドサーバ（ＷＥＢサーバ）１０２４の平均消費電力、最高消費電力、電力コストを採用する場合について説明したが、これに限られない。例えば、サーバ群１０２２に含まれる各サーバの電力コストを算出し、それを平均した値をそのサーバ群１０２２の電力コストとして採用してもよい。
【０１５５】
実施の形態では、例えば図１８に示されるように、指標算出部１００においてパケットの傍受（Ｓ４０２）からデータの集計（Ｓ４１２）が一連の処理として行われる場合について説明したが、これに限られない。例えば、指標算出部は、パケットの傍受からデータの分類までを随時行って分類結果のデータを蓄積し、所定の条件が満たされると分類結果のデータを集計してもよい。ここで所定の条件は、例えば前回の集計から所定の期間が経過したこと、もしくは分類結果のデータの量が所定の量に達したことである。
【０１５６】
図２３は、変形例に係る指標算出部における一連の処理を示すフローチャートである。変形例に係る指標算出部は、傍受部と、抽出部と、登録部と、通信情報保持部と、分類部と、分類結果保持部と、集計部と、を備える。傍受部は、ネットワークからパケットを傍受する（Ｓ５０２）。抽出部は、傍受されたパケットから始点アドレスとポート番号とを抽出する（Ｓ５０４）。登録部は、抽出された始点アドレスとポート番号とパケットのデータ量とを通信情報保持部に登録する（Ｓ５０６）。分類部は、通信情報保持部に保持されるデータを始点アドレスでソーティングする（Ｓ５０８）。分類部は、ソーティングされたデータを本来用途と非本来用途とに分類する（Ｓ５１０）。分類部は、分類結果を分類結果保持部に登録する（Ｓ５１２）。所定の条件が満たされていない場合（Ｓ５１４のＮ）、ステップＳ５０２に処理が戻る。これにより、所定の条件が満たされるまで分類結果が分類結果保持部に蓄積されてゆく。所定の条件が満たされた場合（Ｓ５１４のＹ）、集計部は、分類結果保持部に蓄積されたデータを集計する（Ｓ５１６）。
本変形例によると、所定の条件を変えることにより、集計の母集団として使用する分類結果データの量を調整できる。したがって、集計の結果得られる指標に対して求められている精度に応じて柔軟に分類結果データの量を調整できる。
【０１５７】
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。
【符号の説明】
【０１５８】
２ 情報処理システム、 １００ 指標算出部、 １０２ ネットワークインタフェース部、 １０４ 通信情報保持部、 １０８ 第１指標保持部、 １１０ 使用状況取得部、 １１２ 使用状況保持部、 １１４ 係数保持部、 １１６ 第１解析部、 １１８ 第２指標保持部、 １２０ 表示制御部、 １３０ 集計部、 １３２ 分類部、 １３８ ノード情報保持部、 １４０ モニタ、 １５２ 第２解析部、 １５８ 第３指標保持部、 １００６ ユーザ端末、 １０１０ 運用管理装置、 １０２０ 情報処理装置、 １０３０ ロードバランサ、 １１３０ 学習部、 １１４０ 状態設定部、 １１５０ 乖離判定部、 １１６０ オーバライド部。
【特許請求の範囲】
【請求項１】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求の負荷の履歴を保持する負荷履歴保持部と、
前記負荷履歴保持部を参照して今後発生する負荷を予測する負荷予測部と、
前記負荷予測部によって予測された負荷が所定の第１しきい値より少ない場合、少なくともひとつのサーバを、要求を受付可能な第１状態よりも省電力の第２状態に設定する状態設定部と、
ネットワークから得られる情報から、サーバの温度を取得する使用状況取得部と、を備え、
前記状態設定部は、前記使用状況取得部によって取得された温度が高いサーバを、前記第２状態に設定するサーバとして優先的に選択することを特徴とする運用管理装置。
【請求項２】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求の負荷の履歴を保持する負荷履歴保持部と、
前記負荷履歴保持部を参照して今後発生する負荷を予測する負荷予測部と、
前記負荷予測部によって予測された負荷が所定の第１しきい値より少ない場合、少なくともひとつのサーバを、要求を受付可能な第１状態よりも省電力の第２状態に設定する状態設定部と、
ネットワークから得られる情報から、サーバの仕事の量をサーバに対して予め定められた本来用途用の仕事の量と本来用途以外の用途である非本来用途用の仕事の量とに分類し、本来用途用の仕事の一単位の処理に起因するサーバの温度の上昇値を算出する指標算出部と、を備え、
前記状態設定部は、前記指標算出部によって算出された上昇値が大きいサーバを、前記第２状態に設定するサーバとして優先的に選択することを特徴とする運用管理装置。
【請求項３】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数のサーバのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、
ネットワークから得られる情報から、サーバの温度を取得する解析装置と、を備え、
前記解析装置は、
複数のサーバのうち要求に対応した処理の実行が不要な少なくともひとつのサーバを選択するユニット選択部と、
前記ユニット選択部によって選択された少なくともひとつのサーバを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するユニット設定部と、を含み、
前記ユニット選択部は、前記解析装置によって取得された温度が高いほど優先的に省電力状態に設定されるように、各サーバに対して省電力状態とされる順番を設定し、
前記ユニット選択部は、要求の負荷が所定の値より少ない場合、稼動状態にあるサーバのうち省電力状態とされる順番が最も高いサーバを、要求に対応した処理の実行が不要なサーバとして選択することを特徴とする情報処理システム。
【請求項４】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数のサーバのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、
ネットワークから得られる情報から、サーバごとに、サーバの仕事の量をサーバに対して予め定められた本来用途用の仕事の量と本来用途以外の用途である非本来用途用の仕事の量とに分類し、本来用途用の仕事の一単位の処理に起因するサーバの温度の上昇値を算出する解析装置と、を備え、
前記解析装置は、
複数のサーバのうち要求に対応した処理の実行が不要な少なくともひとつのサーバを選択するユニット選択部と、
前記ユニット選択部によって選択された少なくともひとつのサーバを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するユニット設定部と、を含み、
前記ユニット選択部は、前記解析装置によって算出された上昇値が大きいほど優先的に省電力状態に設定されるように、各サーバに対して省電力状態とされる順番を設定し、
前記ユニット選択部は、要求の負荷が所定の値より少ない場合、稼動状態にあるサーバのうち省電力状態とされる順番が最も高いサーバを、要求に対応した処理の実行が不要なサーバとして選択することを特徴とする情報処理システム。
【請求項１】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求の負荷の履歴を保持する負荷履歴保持部と、
前記負荷履歴保持部を参照して今後発生する負荷を予測する負荷予測部と、
前記負荷予測部によって予測された負荷が所定の第１しきい値より少ない場合、少なくともひとつのサーバを、要求を受付可能な第１状態よりも省電力の第２状態に設定する状態設定部と、
ネットワークから得られる情報から、サーバの温度を取得する使用状況取得部と、を備え、
前記状態設定部は、前記使用状況取得部によって取得された温度が高いサーバを、前記第２状態に設定するサーバとして優先的に選択することを特徴とする運用管理装置。
【請求項２】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求の負荷の履歴を保持する負荷履歴保持部と、
前記負荷履歴保持部を参照して今後発生する負荷を予測する負荷予測部と、
前記負荷予測部によって予測された負荷が所定の第１しきい値より少ない場合、少なくともひとつのサーバを、要求を受付可能な第１状態よりも省電力の第２状態に設定する状態設定部と、
ネットワークから得られる情報から、サーバの仕事の量をサーバに対して予め定められた本来用途用の仕事の量と本来用途以外の用途である非本来用途用の仕事の量とに分類し、本来用途用の仕事の一単位の処理に起因するサーバの温度の上昇値を算出する指標算出部と、を備え、
前記状態設定部は、前記指標算出部によって算出された上昇値が大きいサーバを、前記第２状態に設定するサーバとして優先的に選択することを特徴とする運用管理装置。
【請求項３】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数のサーバのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、
ネットワークから得られる情報から、サーバの温度を取得する解析装置と、を備え、
前記解析装置は、
複数のサーバのうち要求に対応した処理の実行が不要な少なくともひとつのサーバを選択するユニット選択部と、
前記ユニット選択部によって選択された少なくともひとつのサーバを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するユニット設定部と、を含み、
前記ユニット選択部は、前記解析装置によって取得された温度が高いほど優先的に省電力状態に設定されるように、各サーバに対して省電力状態とされる順番を設定し、
前記ユニット選択部は、要求の負荷が所定の値より少ない場合、稼動状態にあるサーバのうち省電力状態とされる順番が最も高いサーバを、要求に対応した処理の実行が不要なサーバとして選択することを特徴とする情報処理システム。
【請求項４】
複数のサーバがネットワークで接続されることによって構成された情報処理装置に対する要求を外部から取得し、複数のサーバのうちの少なくともひとつに、取得された要求を割り当てる負荷管理装置と、
ネットワークから得られる情報から、サーバごとに、サーバの仕事の量をサーバに対して予め定められた本来用途用の仕事の量と本来用途以外の用途である非本来用途用の仕事の量とに分類し、本来用途用の仕事の一単位の処理に起因するサーバの温度の上昇値を算出する解析装置と、を備え、
前記解析装置は、
複数のサーバのうち要求に対応した処理の実行が不要な少なくともひとつのサーバを選択するユニット選択部と、
前記ユニット選択部によって選択された少なくともひとつのサーバを、要求を受付可能な稼動状態から、稼動状態よりも省電力の省電力状態に設定するユニット設定部と、を含み、
前記ユニット選択部は、前記解析装置によって算出された上昇値が大きいほど優先的に省電力状態に設定されるように、各サーバに対して省電力状態とされる順番を設定し、
前記ユニット選択部は、要求の負荷が所定の値より少ない場合、稼動状態にあるサーバのうち省電力状態とされる順番が最も高いサーバを、要求に対応した処理の実行が不要なサーバとして選択することを特徴とする情報処理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１２−５３８９９（Ｐ２０１２−５３８９９Ａ）
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願番号】特願２０１１−２３４８９８（Ｐ２０１１−２３４８９８）
【出願日】平成２３年１０月２６日（２０１１．１０．２６）
【分割の表示】特願２０１０−７２５４７（Ｐ２０１０−７２５４７）の分割
【原出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２４年３月１５日（２０１２．３．１５）
【国際特許分類】
【出願日】平成２３年１０月２６日（２０１１．１０．２６）
【分割の表示】特願２０１０−７２５４７（Ｐ２０１０−７２５４７）の分割
【原出願日】平成２２年３月２６日（２０１０．３．２６）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]