JP2011076468A - 負荷管理装置、情報処理システムおよび負荷管理方法 - Google Patents

負荷管理装置、情報処理システムおよび負荷管理方法 Download PDF

Info

Publication number
JP2011076468A
JP2011076468A JP2009228702A JP2009228702A JP2011076468A JP 2011076468 A JP2011076468 A JP 2011076468A JP 2009228702 A JP2009228702 A JP 2009228702A JP 2009228702 A JP2009228702 A JP 2009228702A JP 2011076468 A JP2011076468 A JP 2011076468A
Authority
JP
Japan
Prior art keywords
request
state
unit
server group
load
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2009228702A
Other languages
English (en)
Inventor
Tomoo Misaki
友雄 三崎
Kazuhiko Matsusei
和彦 松政
Shinya Oki
真也 沖
Toshihiro Koda
敏宏 幸田
Hajime Kobayashi
甫 小林
Satoshi Okano
諭 岡野
Takeshi Horo
毅 保呂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nomura Research Institute Ltd
Original Assignee
Nomura Research Institute Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nomura Research Institute Ltd filed Critical Nomura Research Institute Ltd
Priority to JP2009228702A priority Critical patent/JP2011076468A/ja
Publication of JP2011076468A publication Critical patent/JP2011076468A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Power Sources (AREA)

Abstract

【課題】並列処理を行うサーバ群の消費電力を低減する。
【解決手段】負荷管理装置10において、要求取得部120はネットワーク4からの情報処理装置に対するアクセスを取得する。負荷検出部140は、要求取得部120によって取得されたアクセスのアクセス数を検出する。状態設定部150は、負荷検出部140によって検出されたアクセスがモード切替値より少ない場合、情報処理装置に含まれる少なくともひとつのサーバ群を、アクセスを受付可能な稼動状態よりも省電力の省電力状態に設定する。要求割当部130は、要求取得部120によって取得されたアクセスを情報処理装置に含まれる他のサーバ群に割り当てる。
【選択図】図3

Description

本発明は、並列処理における負荷管理装置、方法およびその装置を備える情報処理システムに関する。
地球温暖化と言う問題が、昨今聞かれる。地球温暖化対策の一つとしては電力需要を減らすことがある。電力は一般的に水力発電、太陽光発電、風力発電、地熱発電などの自然由来の発電や、原子力を使う原子力発電や、ガス、石油、石炭などを燃料として燃やし発電を行う火力発電によって供給されている。この中でも特に火力発電は地球温暖化を進める大きな要因となっている。電力需要を減らせば火力発電の発電量も減らすことができるので、その分地球温暖化も抑止されうる。
IT(Information Technology)やICT(Information and Communication Technology)の分野でも、コンピュータやネットワーク機器、データセンタ機器が消費する電力を低減する必要性が指摘され始めている。
近年のインターネットの普及により、多くのデータセンタは、ネットワーク接続型の形態を有しており、インターネットなどの外部のネットワークからの仕事要求を受けて処理を行う。これらのデータセンタのなかには、一度に多くのアクセスを処理するために複数の並列に配置されたサーバを備える構成を採用したものがある(特許文献1参照)。このようなデータセンタは、一般に「ロードバランサ」と呼ばれる負荷分散を行う装置を有する。このロードバランサはネットワーク側の通信機器とサーバとの間に配置され、ネットワークから到来するアクセスを個々のサーバに均等に近い形で分散させている。
また、ネットワーク接続装置の消費電力低減装置が知られている(特許文献2参照)。
特開2008−225793号公報 特開2007−97126号公報
現行のロードバランサでは、アクセス数が少ない場合でも個々のサーバに要求を分散させる。アクセス数によっては一部のサーバに要求が振られない場合もあり、そのようなサーバはアイドル状態で要求を待ち受けることになる。しかしながら、ユーザからのアクセスがなく仕事が発生していないアイドル状態でも、基本OS(operating system)機能とネットワークモニタリング等のタスクが稼動しており相当の電力が消費されている。サーバ機器にもよるが、アイドル状態の消費電力は、概ね最大性能発揮時の消費電力の30%から70%であると考えられる。省エネの観点から見ると、サーバをアイドル状態に置いておくことは電力の無駄使いと言える。
本発明はこうした課題に鑑みてなされたものであり、その目的は、要求の並列処理において消費電力を低減できる負荷管理装置の提供にある。
本発明のある態様は負荷管理装置に関する。この負荷管理装置は、ネットワークからの情報処理装置に対する要求を取得する要求取得部と、要求取得部によって取得された要求の負荷を検出する負荷検出部と、負荷検出部によって検出された負荷が所定の値より少ない場合、情報処理装置に含まれる少なくともひとつの要求処理ユニットを、要求を受付可能な第1状態よりも省電力の第2状態に設定する状態設定部と、要求取得部によって取得された要求を情報処理装置に含まれる他の要求処理ユニットに割り当てる要求割当部と、を備える。
「要求」とは、例えば情報処理装置に対する処理の要求であってもよい。
「負荷」とは、例えば要求の量を示す値であってもよい。
この態様によると、負荷検出部によって検出された負荷が少ない場合、少なくともひとつの要求処理ユニットを省電力の第2状態に設定することで、消費電力を低減できる。
本発明の別の態様は、情報処理システムである。この情報処理システムは、ネットワークからの要求を処理する情報処理装置と、ネットワークと接続され、ネットワークからの情報処理装置に対する要求を情報処理装置に送る負荷管理装置と、を備える。情報処理装置は、それぞれが要求の処理単位である複数の要求処理ユニットを含む。負荷管理装置は、ネットワークからの情報処理装置に対する要求を取得する要求取得部と、要求取得部によって取得された要求の負荷を検出する負荷検出部と、負荷検出部によって検出された負荷が所定の値より少ない場合、情報処理装置に含まれる少なくともひとつの要求処理ユニットを、要求を受付可能な第1状態よりも省電力の第2状態に設定する状態設定部と、要求取得部によって取得された要求を情報処理装置に含まれる他の要求処理ユニットに割り当てる要求割当部と、を含む。
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
本発明によれば、要求の並列処理において消費電力を低減できる。
実施の形態に係る負荷管理装置を備える情報処理システムおよびその周辺を示す概略図である。 図1におけるアクセスの流れを説明するための説明図である。 実施の形態に係る負荷管理装置の機能および構成を示すブロック図である。 接続テーブルを示すデータ構造図である。 サーバ群状態テーブルを示すデータ構造図である。 稼動履歴テーブルを示すデータ構造図である。 負荷管理装置における一連の処理を示すフローチャートである。 図8(a)〜図8(d)は、全アクセス数に対する各サーバ群の稼働率を示すグラフである。 オーバヘッドと性能のかねあいを説明するための、各サーバ群の稼働率を示すグラフである。
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
本実施の形態に係る負荷管理装置は、複数の並列に配置されたサーバ群でユーザからのアクセスを処理している情報処理システムのゲートウエイとして利用される。負荷管理装置は、ネットワークから情報処理システム宛に到来する要求の負荷が少ない場合は不必要なサーバ群のOSを休眠させたり、サーバ群の電源自体をオフにする。そして残りのサーバ群に要求を割り当てる。これにより無駄な待機電力を削り情報処理システム全体の消費電力を低減できる。
図1は、実施の形態に係る負荷管理装置10を備える情報処理システム2およびその周辺を示す概略図である。情報処理システム2は、ネットワーク接続型のデータセンタであり、例えば証券会社のインターネット株取引システムを提供するデータセンタである。情報処理システム2は、ネットワーク4と接続され同じくネットワーク4に接続されている少なくともひとつのユーザ端末6から要求を受ける。ここで要求とは、例えばネットワーク4のユーザからのアクセスである。アクセスとは、ユーザ端末6と情報処理システム2のひとつのサーバ群とが接続を確立して一連の情報をやりとりすることである。異なるユーザ端末からのアクセスは異なるアクセスであり、同じユーザ端末からでも異なるアクセスがなされうる。
ネットワーク4は、例えばLAN(Local Area Network)・WAN(Wide Area Network)・インターネットである。ユーザ端末6は、ユーザが使用するコンピュータであり、例えば有線でネットワーク4に接続された家庭用デスクトップコンピュータや、無線でネットワーク4に接続されたラップトップコンピュータである。
情報処理システム2は、本実施の形態に係る負荷管理装置10と、情報処理装置20と、を備える。負荷管理装置10は、ネットワーク4と接続され、また情報処理装置20に含まれる個々のサーバ群とバスBUSを介して接続される。負荷管理装置10は、データの流れの観点からは情報処理装置20とネットワーク4との間に位置し、ネットワーク4からの情報処理装置20に対するアクセスを仲介する。
負荷管理装置10はさらに、情報処理装置20に含まれる複数のサーバ群のうちアクセスを受付可能な状態(以下、稼動状態と称する)にあるサーバ群に、ユーザからのアクセスを割り当てる。また、負荷管理装置10は、ネットワーク4からの負荷を監視し、負荷が所定のモード切替値Moより少なくなると省電力モードに入る。この省電力モードでは負荷管理装置10は、アクセスの処理に不要なサーバ群を稼動状態よりも省電力の状態(以下、省電力状態と称する)に設定する。ここで負荷とは、例えばサーバ群が行う仕事の量を表す値であり、単位時間当たりのアクセスの数を基に定められる。例えば負荷は、単位時間当たりのアクセスの数と比例関係などの数学的関係を有する値であってもよい。また、負荷は単位時間当たりのアクセスの数に上限値または下限値若しくはその両方を課した値であってもよい。以下では、負荷が単に単位時間当たりのアクセスの数(以下、アクセス数と称す)である場合について説明する。
なお、負荷がモード切替値Mo以上の場合は負荷管理装置10は全てのサーバ群を稼動状態に設定する。このモードを通常モードと呼ぶ。
情報処理装置20は、ネットワーク4からのアクセスを処理する。情報処理装置20は、複数のサーバ群を含み、そのそれぞれのサーバ群はアクセスの処理単位である要求処理ユニットとして機能する。本実施の形態では情報処理装置20は、第1サーバ群22aと、第2サーバ群22bと、第3サーバ群22cと、第4サーバ群22dと、第5サーバ群22eと、を含む。しかしながら情報処理装置20が2つ以上の任意の数のサーバ群を含んでよいことは本明細書に触れた当業者には理解される。
第1サーバ群22aは、第1フロントエンドサーバ24aと、第1アプリケーションサーバ26aと、第1データベースサーバ28aと、を含む。これはいわゆる3階層のサーバ群であり、これら1セットでアクセスの処理単位を構成する。第1フロントエンドサーバ24aは、ウェブサーバとも呼ばれ、HTTP(HyperText Transfer Protocol)に則り、ユーザ端末6のウェブブラウザに対して、HTML(HyperText Markup Language)や画像などのオブジェクトの表示を提供するサービスが動作するサーバコンピュータである。第1アプリケーションサーバ26aは、第1フロントエンドサーバ24aからジャバサーブレット(Java Servlet、ジャバは登録商標)の処理などのアプリケーションに関する機能を切り出して実現するサーバコンピュータである。第1データベースサーバ28aは、第1アプリケーションサーバ26aのアプリケーションが使用するデータが格納されるサーバコンピュータである。第1フロントエンドサーバ24a、第1アプリケーションサーバ26a、および第1データベースサーバ28aは、公知の情報処理技術を使用して実現される。本実施の形態では、第1フロントエンドサーバ24aと第1アプリケーションサーバ26aと第1データベースサーバ28aとは別個のサーバであり、この順に直列に接続されている。
第2サーバ群22b、第3サーバ群22c、第4サーバ群22d、および第5サーバ群22eは、それぞれ第1サーバ群22aと同等の構成を有する。情報処理装置20では、第1サーバ群22a〜第5サーバ群22eのアクセスの処理能力はほぼ等しく設定される。第1サーバ群22a〜第5サーバ群22eの第1フロントエンドサーバ24a〜第5フロントエンドサーバ24eはそれぞれバスBUSを介して負荷管理装置10と接続される。
なお、個々のサーバ群に含まれるサーバは個々にもしくは全体としてOSに管理されている。個々のサーバ群の稼動状態は、ユーザからのアクセスを即時処理可能な状態である。この状態は、サーバ群がユーザからのアクセスを処理しつつ新たなアクセスを処理可能である状態と、ユーザからのアクセスがなく仕事が発生していないアイドル状態と、を含む。稼動状態では、たとえアイドル状態であっても少なくとも基本OS機能とネットワークモニタリングのタスクは稼動しており、その分電力を消費する。本発明者の当業者としての経験から、このアイドル状態での消費電力は、サーバ機器の種類によってピークアクセス数での稼動時のおよそ30%から70%の範囲にある。特に標準的なサーバ機器を用いる場合は60%程度である。ここでピークアクセス数とは、サーバ群がその処理速度を落とさずに稼動できるアクセス数の範囲の上限値であり、サーバ群ごとにその仕様を基に予め定められている。ここで処理速度とは、サーバ群におけるユーザからのアクセスの処理速度である。
個々のサーバ群の省電力状態は、ユーザからのアクセスを即時処理できない状態である。この状態は、サーバ群へ電源は供給されているがそのサーバ群はユーザからのアクセスを処理できないOS休眠状態を含む。サーバ群は負荷管理装置10から休眠導入信号を受信するとOS休眠状態となる。このOS休眠状態では、サーバ群のOSは休眠(ハイボネート)しており、ユーザからのアクセスがあってもそれを受け付けない。OS休眠状態にあるサーバ群は負荷管理装置10から休眠解除信号を受信すると、稼動状態に復帰する。OS休眠状態から稼動状態に復帰するためには通常数秒から数十秒かかる。また本発明者の当業者としての経験から、OS休眠状態におけるサーバ群の消費電力は、ピークアクセス数での稼働時のおよそ5%から10%である。
サーバ群の省電力状態はさらに、サーバ群への電源が遮断されている電源オフ状態を含む。サーバ群は負荷管理装置10から電源オフ信号を受信すると電源オフ状態となる。サーバ群は負荷管理装置10からWOL(Wake Up on LAN)信号などの電源オン信号を受信すると、稼動状態に復帰する。電源オフ状態から稼動状態に復帰するためには通常数分かかる。
詳細は後述するが、本実施の形態ではサーバ群が省電力状態から稼動状態に復帰するためにかかる時間(以下、オーバヘッドと称す)と、省電力状態で低減される消費電力とのかねあいで、省電力状態とされるサーバ群の数が決定される。つまり、現在のアクセス数を処理するのに必要なぎりぎりの数のサーバ群だけを稼動状態としていると、突然のアクセス数の増大に対して対処できなくなる可能性がある。一方で稼動状態のサーバ群の数が多いほど待機電力由来の消費電力も大きくなる。そこでそれらの影響が拮抗するように、省電力状態とされるサーバ群の数が決定される。
図2は、図1におけるアクセスの流れを説明するための説明図である。以下、1回のアクセスにおいて、少なくともひとつのパケットがユーザ端末6とアクセスが割り当てられたサーバ群との間でやりとりされる場合について説明する。このパケットは、送信元のIPアドレスであるソースIPアドレスSrcと、受信先のIPアドレスであるあて先IPアドレスDstと、後述するシーケンス番号と、を含む。多くの場合において一回のアクセスにつき複数個のパケットがユーザ端末6とサーバ群との間を行き来する。図2では第3サーバ群22cがアクセスに割り当てられたとする。ユーザ端末6のIPアドレスを「175.34.11.21」、負荷管理装置10のIPアドレスを「100.10.10.10」、第3サーバ群22cに含まれる第3フロントエンドサーバ24cのIPアドレスを「121.21.15.3」とする。
負荷管理装置10は、ユーザ端末6に対して仮想サーバとして働く。つまり、ネットワーク4では、ユーザが情報処理装置20が有する情報資源にアクセスしようとする場合、かかる情報資源のURL(Uniform Resource Locator)が負荷管理装置10のIPアドレス「100.10.10.10」に名前解決されるよう設定されている。
まずユーザは、ユーザ端末6のウェブブラウザに対して情報処理装置20が有する情報資源のURLを指定する。ユーザ端末6のウェブブラウザによってソースIPアドレスSrcを「175.34.11.21」、あて先IPアドレスDstを「100.10.10.10」とした第1パケットP1が生成され、ネットワーク4に送られる。負荷管理装置10は第1パケットP1を受信し、稼動状態にあるサーバ群のなかから第3サーバ群22cを選択してこのアクセスを割り当てる。負荷管理装置10は、第1パケットP1のソースIPアドレスSrcはそのままにしてあて先IPアドレスDstを「121.21.15.3」とした第2パケットP2をバスBUSに送出する。第3サーバ群22cの第3フロントエンドサーバ24cは自己宛の第2パケットP2を受信し、第2パケットP2の指示にしたがい処理を行う。その処理の結果ユーザ端末6へ戻すべき情報は、ソースIPアドレスSrcを「121.21.15.3」、あて先IPアドレスDstを「175.34.11.21」とした第3パケットP3に含められ、第3フロントエンドサーバ24cからバスBUSに送出される。負荷管理装置10は第3パケットP3を受信する。負荷管理装置10は、第3パケットP3のあて先IPアドレスDstはそのままにしてソースIPアドレスSrcを「100.10.10.10」とした第4パケットP4をネットワーク4に送る。ユーザ端末6は自己宛の第4パケットP4をネットワーク4から受信する。
以下、ユーザ端末6から負荷管理装置10に送られるパケット(第1パケットP1)を総称して行きパケット、負荷管理装置10から情報処理装置20へ送られるパケット(第2パケットP2)を総称して割当パケットという。
図3は、実施の形態に係る負荷管理装置10の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウェア的には、コンピュータのCPU(central processing unit)をはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
負荷管理装置10は、記憶装置110と、要求取得部120と、要求割当部130と、負荷検出部140と、状態設定部150と、負荷予測部160と、稼動履歴記録部180と、を備える。
記憶装置110は、稼動履歴テーブル112と、サーバ群状態テーブル114と、接続テーブル116と、を含む。稼動履歴テーブル112は、情報処理装置20の過去の稼動履歴を記憶するテーブルである。サーバ群状態テーブル114は、現在のサーバ群の状態を記憶するテーブルである。稼動履歴テーブル112およびサーバ群状態テーブル114の詳細は後述する。
接続テーブル116は、同一アクセス内のパケットは同じサーバ群へ送られること(以下、アクセスの同一性と称す)を保証するためのテーブルである。図4は、接続テーブル116を示すデータ構造図である。接続テーブル116には、後述する接続テーブル更新部138によってアクセスに対応するエントリ118が生成される。一回のアクセスに対してひとつのエントリが対応する。接続テーブル116のエントリ118は、アクセスしてきたユーザ端末6のIPアドレスであるユーザ端末IPアドレス210と、負荷管理装置10のIPアドレスである負荷管理装置IPアドレス212と、負荷管理装置10によってそのアクセスに割り当てられたサーバ群のフロントエンドサーバのIPアドレスである割当サーバ群IPアドレス214と、ユーザ端末6が同一の場合にアクセスの異同を判別するためのシーケンス番号216と、を有する。同一ユーザ端末6において、異なるアクセスには異なるシーケンス番号216が割り振られる。以下、サーバ群のフロントエンドサーバのIPアドレスを単にサーバ群のIPアドレスと称す。
図3に戻る。要求取得部120は、ネットワーク4と接続される。要求取得部120は、ネットワーク4から到来するユーザ端末6からのアクセスの行きパケットを取得する。この際、要求取得部120は行きパケットに含まれるあて先IPアドレスDstを基に自己宛のパケットであるか否かを判別する。要求取得部120は、取得した行きパケットを要求割当部130に渡す。
なお、本明細書において「渡す」とは、ある機能ブロックからある機能ブロックに情報要素に対する処理が移ることを意味する。要求取得部120と要求割当部130との間で言うと、渡すとは、例えば要求取得部120が図示しない一時メモリを有し、取得した行きパケットをそこに蓄えた上で、要求割当部130からの要請に応じて適宜行きパケットを一時メモリから要求割当部130に伝達することである。また渡すとは、記憶装置110が図示しない記憶領域を有し、要求取得部120は取得した行きパケットをその記憶領域に書き込み、要求割当部130は適宜その記憶領域から必要な行きパケットを読み出して処理することであってもよい。
要求割当部130は、ユーザ端末6からのアクセスの行きパケットを稼動状態にあるサーバ群のうちのひとつに割り当てる。要求割当部130は、同一接続判断部132と、サーバ群選択部134と、アドレス変換部136と、接続テーブル更新部138と、を含む。
同一接続判断部132は、要求取得部120から行きパケットを取得し、その行きパケットが新規のアクセスによるものか否かを判別する。同一接続判断部132は、取得した行きパケットのソースIPアドレスSrcとシーケンス番号とを読み取る。同一接続判断部132は、読み取られたソースIPアドレスSrcとシーケンス番号とをキーとして接続テーブル116のエントリ118を検索し、それらと一致するエントリ118が存在する場合、そのエントリ118に含まれる割り当てられたサーバ群の割当サーバ群IPアドレス214を取得する。同一接続判断部132は、この取得された割当サーバ群IPアドレス214と行きパケットとをアドレス変換部136に渡す。
なお、このように一致するエントリ118が存在する場合は、当該行きパケットは既にあるサーバ群(エントリ118の割当サーバ群IPアドレス214で指定されるサーバ群)に割り当てられたアクセスのなかのひとつのパケットである。アドレス変換部136は、渡された行きパケットのあて先IPアドレスDstを、同一接続判断部132によって接続テーブル116から取得された割当サーバ群IPアドレス214に変換する。このようにあて先IPアドレスDstが変換された行きパケットはアドレス変換部136から割当パケットとしてバスBUSに送出される。
一致するエントリ118が存在しない場合は、同一接続判断部132は当該行きパケットをサーバ群選択部134に渡す。この場合は同一接続判断部132は新規のアクセスを検知したと言うことができる。
サーバ群選択部134は、同一接続判断部132から新規のアクセスに対応する行きパケットを受け取ると、サーバ群状態テーブル114を参照してそのアクセスを処理させるサーバ群を選択する。
図5は、サーバ群状態テーブル114を示すデータ構造図である。サーバ群状態テーブル114は、サーバ群のIPアドレス202と、サーバ群の状態204と、サーバ群の稼働率206と、を対応付けて記憶する。サーバ群の稼働率206は、サーバ群のピークアクセス数に対する現在そのサーバ群が処理しているアクセス数の割合を%単位で示す。この稼働率206は、図示されない稼働率更新部によって、予め定められているサーバ群のピークアクセス数と、接続テーブル116から分かるサーバ群に現在割り当てられているアクセス数とから演算され更新されてもよい。あるいは、図示されない稼働率更新部が稼動状態にあるサーバ群から稼働率を取得し、サーバ群状態テーブル114の稼働率206を更新してもよい。
図3に戻る。サーバ群選択部134は、サーバ群状態テーブル114に登録されたサーバ群のなかからサーバ群の状態204を参照して稼動状態にあるサーバ群を抽出する。後述する状態設定部150によって負荷管理装置10が省電力モードに設定されているか通常モードに設定されているかによって、サーバ群選択部134が稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択するアルゴリズムは異なる。以下それぞれの場合について説明する。
1.省電力モード
省電力モードでは、サーバ群選択部134は、稼動状態にあるサーバ群の稼働率が100%となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する。例えば図5の例では、サーバ群選択部134は新規のアクセスを処理させるサーバ群として第3サーバ群22cを選択する。また、例えば第1サーバ群22a、第2サーバ群22b、第3サーバ群22cが稼動状態に設定されており、第1サーバ群22aの稼働率が100%、第2サーバ群22bの稼働率が80%、第3サーバ群22cの稼働率が0%の場合、サーバ群選択部134は新規のアクセスを処理させるサーバ群として第2サーバ群22bを選択する。
2.通常モード
通常モードでは、全てのサーバ群が稼動状態にある。サーバ群選択部134は、予め情報処理システム2の管理者によって設定されている負荷分散アルゴリズムにしたがって、新規のアクセスを処理させるのに最適なサーバ群を選択する。ここで使用される負荷分散アルゴリズムは、順番にサーバ群が選択されるラウンドロビン方式や、処理しているアクセス数が最小のサーバ群を選択する最小接続方式や、1番早く応答しているサーバ群を選択する最速方式などの公知のアルゴリズムである。
サーバ群選択部134は、選択されたサーバ群のIPアドレスと新規のアクセスに対応する行きパケットとをアドレス変換部136に渡す。アドレス変換部136は、渡された行きパケットのあて先IPアドレスDstを、サーバ群選択部134によって選択されたサーバ群のIPアドレスに変換する。このようにあて先IPアドレスDstが変換された行きパケットはアドレス変換部136から割当パケットとしてバスBUSに送出される。
接続テーブル更新部138は、サーバ群選択部134で新規のアクセスに対してサーバ群の選択が行われる毎に、その選択に関する情報をサーバ群選択部134から取得し、接続テーブル116に対応するエントリを追加する。この選択に関する情報は、新規のアクセスを行ったユーザのユーザ端末6のユーザ端末IPアドレス210と、負荷管理装置IPアドレス212と、新規のアクセスに対して選択されたサーバ群の割当サーバ群IPアドレス214と、シーケンス番号216と、を含む。
また、接続テーブル更新部138は、適宜不要となったエントリを削除する。
負荷検出部140は、要求取得部120によって取得されたアクセスのアクセス数を周期的に検出する。負荷検出部140は、接続テーブル116を参照してエントリ118の数をカウントすることで、所定の時間間隔で情報処理装置20全体へのアクセス数(以下、全アクセス数と称す)を取得する。また負荷検出部140は、要求取得部120と要求割当部130との間の行きパケットの流れを監視し、所定の時間間隔でアクセスの数をカウントし、そのカウント数から単位時間当たりのアクセスの数、つまりアクセス数を導出してもよい。なお、負荷検出部140は要求取得部120の前段や要求割当部130の後段など、負荷管理装置10の任意の箇所で負荷を監視してもよい。負荷検出部140は、検出した全アクセス数を状態設定部150の負荷比較部152に渡す。
負荷検出部140における上述の時間間隔は負荷管理装置10のモードを更新する基準となる時間間隔であり、アクセス数の変動率に基づいて定められる。負荷検出部140は図示しない時間間隔設定部を有し、時間間隔設定部はアクセス数の変動率を監視し、変動率が大きいほど時間間隔を短く設定する。これにより、より適応的なサーバ群状態の制御が可能となる。また、処理を簡素化するという観点からは時間間隔は情報処理システム2の管理者によって予め定められてもよい。
状態設定部150は、全アクセス数がモード切替値Moより少ない場合、情報処理装置20に含まれる少なくともひとつのサーバ群を省電力状態に設定し、負荷管理装置10を省電力モードに設定する。なお、負荷管理装置10は、状態設定部150によって省電力モードに設定されなければ、通常モードで動作するよう設定されている。
状態設定部150におけるモード切替値Moは、情報処理装置20の性能が落ちない範囲に設定される。ここで性能とは、例えばどれだけのアクセス数をどの程度の速さで処理できるかということである。あるいは性能とは、ひとつのアクセスが処理されるのにかかる時間などのレスポンスタイムであってもよい。また、情報処理装置20の性能が落ちる、とは、例えばあるサーバ群に対してピークアクセス数を越える数のアクセスが割り当てられ、その結果そのサーバ群の処理速度が落ちることにより情報処理装置20全体のアクセスの処理速度が落ちることである。
例えば第1サーバ群22aから第5サーバ群22eのピークアクセス数が全て2000であるとする。この場合モード切替値Moを9000に設定すると、全アクセス数が8500であっても少なくともひとつのサーバ群を省電力状態に設定しなくてはならない。ここでは第5サーバ群22eを省電力状態に設定したとする。残りの4つのサーバ群22a〜22dのトータルのピークアクセス数は8000であり、全アクセス数8500よりも少ない。したがってこの場合残りの4つのサーバ群22a〜22dのうちの少なくともひとつのサーバ群はピークアクセス数以上のアクセスを処理しなくてはならずそのサーバ群の処理速度は低下する。これにより情報処理装置20全体の処理速度が落ちることとなる。このような状況を避けるために、モード切替値Moは情報処理装置20の性能が落ちない範囲に設定される。上述の例ではモード切替値Moは8000以下に設定されればよい。
状態設定部150は、サーバ群の最大性能を発揮せしめる前提で、要求取得部120によって取得されたアクセスを処理させるサーバ群を決定し、残りのサーバ群を省電力状態に設定する。この場合サーバ群の最大性能を発揮せしめる、とは、例えばサーバ群にピークアクセス数でアクセス処理を行わせることであり、言い換えるとサーバ群を100%の稼働率で使用することである。さらに状態設定部150は、全アクセス数の変動により情報処理装置20の性能が落ちると予測される場合には、省電力状態に設定されている少なくともひとつのサーバ群を稼動状態に設定する。
サーバ群を省電力状態または稼動状態に設定することに関して、状態設定部150では、稼動状態にするサーバ群の数に応じた全アクセス数の範囲が定められている。状態設定部150は例えば全アクセス数が0から第1しきい値T1の範囲にあればひとつのサーバ群のみを稼動状態とし、他のサーバ群を省電力状態とする。表1は、状態設定部150における状態設定に関して、稼動状態とするサーバ群の数と、OS休眠状態とするサーバ群の数と、電源オフ状態とするサーバ群の数と、全アクセス数の範囲と、の関係を示す。T2は第2しきい値、T3は第3しきい値であり、T1<T2<T3である。個々のしきい値は予め情報処理システム2の管理者によって設定される。
Figure 2011076468
第1しきい値T1、第2しきい値T2、第3しきい値T3はそれぞれサーバ群を100%の稼働率で使用することを前提に設定される。つまり上述の第1サーバ群22aから第5サーバ群22eのピークアクセス数が全て2000であるとする例では、T1=2000、T2=4000、T3=6000である。この場合、全アクセス数のアクセスを処理するのに必要最低限の数のサーバ群が稼動状態とされる。また、例えば第1しきい値T1と第2しきい値T2との間にあった全アクセス数が増大して第2しきい値T2を越えた場合、そのままだと少なくともひとつのサーバ群の稼働率が100%を上回ると予測されるので、稼動状態とするサーバ群の数をひとつ増やして情報処理装置20の処理速度の低下を回避する。
状態設定部150は、負荷比較部152と、稼動サーバ群決定部154と、状態信号生成部156と、を含む。
負荷比較部152は、負荷検出部140から取得した全アクセス数と、第1しきい値T1、第2しきい値T2、第3しきい値T3、モード切替値Moとの大小関係を判別する。この大小関係は例えば「T2<全アクセス数<T3」という情報である。負荷比較部152はこの大小関係に関する情報を稼動サーバ群決定部154に渡す。
稼動サーバ群決定部154は、この情報を基に表1のストラテジにしたがい、状態の切替が必要な場合には、稼動状態とするサーバ群とOS休眠状態とするサーバ群と電源オフ状態とするサーバ群を決定する。稼動サーバ群決定部154はこの決定に基づきサーバ群状態テーブル114を更新する。稼動サーバ群決定部154は、状態の切り替えが必要なサーバ群の情報を状態信号生成部156に渡す。稼動サーバ群決定部154は、状態の切り替えが必要ない場合には処理を中断または終了し、次の情報を待ち受ける。
稼動サーバ群決定部154は、表1のストラテジから稼動状態、OS休眠状態および電源オフ状態とするサーバ群の数をまず決める。次に稼動サーバ群決定部154はサーバ群状態テーブル114を参照し、サーバ群の状態を切り替える必要があるか、言い換えると負荷検出部140が取得した全アクセス数に対応する各状態のサーバ群の数とサーバ群状態テーブル114に登録されている現在の各状態のサーバ群の数とが一致するか否かを判断する。そこで一致する場合は稼動サーバ群決定部154は処理を中断または終了する。
一致しない場合は、稼動サーバ群決定部154はそれぞれの状態にするサーバ群を決める。ここでそれぞれの状態にするサーバ群を決めるアルゴリズムは、例えば稼動状態、OS休眠状態、電源オフ状態の順番で第1サーバ群22aから第5サーバ群22eに順番に割り当てる方式である。言い換えると、サーバ群の状態を切り替える必要がある場合、稼動状態にあるサーバ群はなるべく稼動状態のままでおいておく方式である。この場合、サーバ群の状態を切り替える回数が少なくてすみ、切り替えに伴うオーバヘッドの低減、レスポンスの高速化に寄与する。また、オーバヘッドが気にならない間隔(例えば、一週間や一月)でランダムに設定してもよい。この場合、サーバ機器のHDD(Hard Disk Drive)などの消耗品の耐用年数を平均化できる。また、サーバ群の性能が異なる場合は、その異なる性能に基づき決めてもよい。
なお、稼動サーバ群決定部154でのサーバ群を決める上述のアルゴリズムでは、特に稼動状態を省電力状態に切り替える場合は、アクセスの同一性が考慮される。つまり、稼動サーバ群決定部154は、接続テーブル116を参照し、省電力状態に切り替えるべきサーバ群へのアクセスがなくなるまで待機する。稼動サーバ群決定部154はそのようなアクセスがなくなると、省電力状態に切り替えるべきサーバ群の情報を状態信号生成部156に渡す。これによりアクセスの同一性が保証されうる。
状態信号生成部156は、状態の切り替えが必要なサーバ群の情報に基づきそのサーバ群に対して切替に対応する休眠導入信号、休眠解除信号、電源オフ信号、および電源オン信号のうちのいずれかを送る。例えば第3サーバ群22cを稼動状態(OS休眠状態)からOS休眠状態(稼動状態)とする必要がある場合、状態信号生成部156は第3サーバ群22cに対して休眠導入信号(休眠解除信号)をバスBUSを介して送出する。また、第3サーバ群22cを稼動状態(電源オフ状態)から電源オフ状態(稼動状態)とする必要がある場合、状態信号生成部156は第3サーバ群22cに対して電源オフ信号(電源オン信号)をバスBUSを介して送出する。
状態信号生成部156によって省電力状態から稼動状態に設定されたサーバ群は、それが稼動状態であることが稼動サーバ群決定部154によってサーバ群状態テーブル114に記録されるので、要求割当部130によって新規のアクセスが割り当てられる。
負荷管理装置10は、負荷検出部140で検出された全アクセス数を基に状態設定部150でサーバ群の状態を適応的に設定する検出モードの他に、過去の稼動履歴を基に予測されたアクセス数(以下、予測アクセス数と称す)を基に状態設定部150でサーバ群の状態を設定する負荷予測モードを有する。以下、この負荷予測モードについて説明する。
稼動履歴記録部180は、定期的に情報処理装置20に含まれるサーバ群22a〜22eの稼動履歴を稼動履歴テーブル112に記録する。稼動履歴記録部180は、例えば15分に1度サーバ群状態テーブル114を参照してその時点での各サーバ群の状態と稼働率とを取得する。また稼動履歴記録部180はその時点で負荷検出部140によって検出された全アクセス数を取得する。稼動履歴記録部180はそれらの情報を稼動履歴テーブル112に書き込む。図6は、稼動履歴テーブル112を示すデータ構造図である。稼動履歴テーブル112は、日時218と、アクセス数220と、稼動サーバ群の数222と、平均稼働率224と、を対応付けて記憶する。日時218は、暦の上での日時である。稼動サーバ群の数222は、その日時に稼動状態にあったサーバ群の数である。平均稼働率224は、稼動状態にあったサーバ群の稼働率の平均値である。
図3に戻る。負荷予測部160は、過去の稼動履歴を基に負荷を予測する。負荷予測部160は、稼動履歴テーブル112を参照し、予測対象の時間帯に対して一年以上前の同月同日の同じ時間帯の稼動履歴を取得し、これを基に予測対象の時間帯の予測アクセス数を決定する。例えば、負荷予測部160が2009年7月28日の9:15〜9:30におけるアクセス数を予測する場合、負荷予測部160は2008年7月28日の9:15〜9:30におけるアクセス数(図6の場合、5400)を稼動履歴テーブル112から取得し、それを予測アクセス数とする。この予測アクセス数の取得は、負荷検出部140における時間間隔と同様の時間間隔で行われる。
負荷予測部160は予測アクセス数を負荷比較部152に渡す。状態設定部150は、負荷予測部160から予測アクセス数が負荷比較部152に渡された場合、この予測アクセス数を全アクセス数と読み替えて上述した処理を行う。
図7は、負荷管理装置10における一連の処理を示すフローチャートである。図7では、要求取得部120と、負荷検出部140と、状態設定部150とで行われる処理についてのフローチャートを示すが、それと平行して要求割当部130がサーバ群状態テーブル114を参照して新規のアクセスのサーバ群への割り当てを行っていることは上述の通りである。
要求取得部120は、ネットワーク4からアクセスを取得する(S702)。負荷検出部140は、全アクセス数を検出する(S704)。状態設定部150は、全アクセス数とモード切替値Mo、第1しきい値T1、第2しきい値T2、第3しきい値T3との大小比較を行う(S706)。状態設定部150は、その大小比較を基にサーバ群の状態の切替が必要か否かを判断する(S708)。状態の切替が必要でない場合(S708のN)、処理をアクセス取得ステップS702に戻す。状態の切替が必要な場合(S708のY)、状態設定部150は稼動状態のサーバ群の数を増やすか減らすかを判断する(S710)。減らす必要がある場合(S710の減らす)、状態設定部150は稼動状態のサーバ群を省電力状態に設定する(S712)。増やす必要がある場合(S710の増やす)、状態設定部150は省電力状態のサーバ群を稼動状態に設定する(S714)。負荷管理装置10はこの処理を所定の時間間隔で繰り返す。
以上の構成による負荷管理装置10および情報処理システム2の動作を説明する。情報処理システム2は例えばインターネット上のデータセンタであり、ユーザはユーザ端末6を使用してこの情報処理システム2にあるウェブページなどの情報資源にアクセスする。負荷管理装置10はこのようなアクセスのアクセス数に応じて適応的に稼動状態とするサーバ群を選択し、残りのサーバ群を省電力状態に設定する。ユーザからのアクセスは稼動状態にあるサーバ群のうちのひとつのサーバ群に割り当てられ、そこで処理される。現時点でのアクセス数を処理するのに不必要なサーバ群は省電力状態とされる。したがって、省電力状態としたサーバ群の待機電力分だけ情報処理システム2全体の消費電力を低減できる。また、アクセス数の増大により情報処理システム2の処理能力を増やす必要が出てくると、負荷管理装置10は稼動状態とするサーバ群の数を増やす。
図8(a)〜図8(d)は、全アクセス数に対する各サーバ群の稼働率を示すグラフである。ここでは、第1サーバ群22aから第5サーバ群22eのピークアクセス数が全て2000であるとする。図8(a)〜図8(d)はそれぞれ全アクセス数が1600、2800、4400、7000の場合に対応する。図8(a)〜図8(d)において「△」はOS休眠状態を示し、「×」は電源オフ状態を示す。
図8(a)では、第2サーバ群22bはOS休眠状態とされ、第3サーバ群22cと、第4サーバ群22dと、第5サーバ群22eと、は電源オフ状態とされる。図8(b)では、第3サーバ群22cはOS休眠状態とされ、第4サーバ群22dと、第5サーバ群22eと、は電源オフ状態とされる。図8(c)では、第4サーバ群22dはOS休眠状態とされ、第5サーバ群22eは電源オフ状態とされる。図8(d)では、第5サーバ群22eはOS休眠状態とされる。
上述の実施の形態において、記憶装置110の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないCPUや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
本実施の形態に係る負荷管理装置10によると、省電力モードではアクセス数に応じて情報処理装置20に含まれるサーバ群が省電力状態に設定される。上述した通り稼動状態のサーバ群の消費電力は、アイドル状態であってもピーク時のおよそ60%である。これに対して省電力状態のサーバ群の消費電力はピーク時のおよそ0〜10%である。したがって、本実施の形態では、負荷分散を実現しつつ、アクセス数が少なくアクセスを処理する必要のないサーバ群がある場合はそれらのサーバ群をアイドル状態ではなく省電力状態としている。これにより、情報処理装置20全体の消費電力を低減でき、電力の無駄遣いを抑え、省エネ化を図ることができる。
また、稼動サーバ群決定部154は接続テーブル116を参照してアクセスの同一性を保証し、サーバ群選択部134はサーバ群状態テーブル114を参照して現在稼動状態にあるサーバ群を判別している。このように本実施の形態では状態切替機能と負荷分散機能とがひとつの負荷管理装置10で実現されているので、アクセスの同一性が必要な場合はそれをより容易に保証でき、また省電力状態にあるサーバ群に誤ってパケットを送信してしまう可能性を低減できる。
本実施の形態に係る負荷管理装置10では、省電力モード(全アクセス数<モード切替値Mo)においては、表1に示される通りOS休眠状態とするサーバ群と電源オフ状態とするサーバ群との両方を設けている。これにより、突然の全アクセス数の増大に対しては、復帰のためのオーバヘッドが小さいOS休眠状態にあるサーバ群を稼動状態に戻すことで対応できる。また、そのように対応できる限りにおいては他のサーバ群は電力を消費しない電源オフ状態とし、情報処理装置20全体の消費電力をさらに低減している。なお、表1ではOS休眠状態とするサーバ群をひとつだけ確保しているが、この数はオーバヘッドと消費電力とのかねあいで定められればよく、適宜増減可能であることは本明細書に触れた当業者には理解される。
本実施の形態に係る負荷管理装置10では、状態設定部150はサーバ群の最大性能を発揮せしめる前提で稼動状態とするサーバ群を決定する。このサーバ群の決定方式によると、所与の全アクセス数に対してより多くの数のサーバ群を省電力状態とすることができる。したがって、情報処理装置20全体の消費電力をより低減できる。なお、稼働率によってサーバ群の消費電力が異なるのも事実ではあるが、上述の通りアイドル状態でもピーク時のおよそ60%の電力が消費されることを考えると、稼働率を下げることによる電力削減効果よりもアイドル状態を省電力状態とすることによる電力削減効果のほうが大きいと考えられる。
また、モード切替値Moは情報処理装置20の性能が落ちない範囲に設定される。これにより、全アクセス数が多い場合は通常モードで情報処理装置20の並列処理能力をいかんなく発揮させ、全アクセス数が少なくなると省電力モードに移行させて性能を保ちつつ電力消費量を低減できる。
また、状態設定部150は全アクセス数の変動により情報処理装置20の性能が落ちると予測される場合には、省電力状態にあるサーバ群を稼動状態に設定する。これにより、サーバ群をピークアクセス数以上で使用しなければならない状況を回避し、アクセス処理の遅滞を避けることができる。
また、負荷予測部160は過去の稼動履歴を基にアクセス数を予測し、状態設定部150はその予測値に基づいてサーバ群の状態を設定する。つまり負荷管理装置10は、情報処理システム2の運用の実態を日時、曜日、祭日等のカレンダー区分にて、ネットワーク4側から発生するアクセス数の傾向情報を過去にさかのぼり蓄積し、その情報を元に運用に該当する日時に予測されるアクセス数を算出する学習機能と、その運用時間帯特異のアクセス数の予測を元に必要な稼動状態サーバ群の数を推測し、必要台数のサーバ群を稼動状態にする機能と、を有する。
これらの機能は特に情報処理システム2がネットワーク接続型のデータセンタである場合に有益である。これは以下の本発明者の当業者としての知見に基づく。
日々の運用では、ネットワーク接続型のデータセンタの運用では、運用されているアプリケーションシステムにより、稼働率やアクセス数の傾向が把握できる。これは、例えば、インターネット検索を主としているアプリケーションサーバ群では、平日より休日の利用が多く、平日でも、午前より午後、夕方から夜までの利用が多いと言える。また、証券取引所接続の証券会社のインターネット株取引システムでは、証券取引所の運用時間帯に多くの取引による仕事量があり、取引所が取引を閉じている夕方から朝、土日と祝祭日には仕事量は少ない。取引所が閉まっている時間帯では、証券会社の顧客は主に個々の口座の情報を参照するなどのアクセスを行うので取引時間帯より仕事量は低い。
これらの日々の運用実績のデータを基に、特定の運用日の特定の時間帯に予測されるネットワーク4よりの仕事量が予測出来ることに本発明者は想到した。証券会社の取引システムのサーバ群は、取引所の運用の時間外は、負荷管理装置10により運用に必要なサーバ群の数を予測し、不必要なサーバ群の電源を切るとかOSを休眠させることで消費電力を低減できる。仮に、この予測に反して仕事量が多くなった場合は、省電力状態(電源オフ状態か、OS休眠状態)のサーバ群をその仕事量に応じて稼動状態とすることにより、多くなった仕事量を分散させる事ができる。
以上、実施の形態に係る負荷管理装置10およびそれを含む情報処理システム2の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
実施の形態では、ユーザ端末6からサーバ群へのパケットの流れを基に説明したが、サーバ群からユーザ端末6へパケットを返すときも負荷管理装置10が適宜接続テーブル116を参照してアドレス変換できることは本明細書に触れた当業者には明らかである。
実施の形態では、負荷管理装置10はバスBUSを介して情報処理装置20の各サーバ群と通信する場合について説明したが、これに限られない。例えば、各サーバ群と負荷管理装置とが1対1で接続され、結果として負荷管理装置がサーバ群側に5つの入出力ポートを有してもよい。この場合、パケットはアドレス変換ではなく直接個々の入出力ポートに振り分けられてもよい。
実施の形態では、モード切替値Mo、第1しきい値T1、第2しきい値T2、および第3しきい値T3が稼動状態のサーバ群の数を決めるしきい値となる場合について説明したが、これに限られない。例えば、それぞれのしきい値にヒステリシスを持たせてもよい。つまり状態設定部は、通常モードから省電力モードへ移行する第1モード切替値Mo1と、省電力モードから通常モードへ移行する第2モード切替値Mo2とを有し、Mo1<Mo2であってもよい。第1しきい値T1、第2しきい値T2、第3しきい値T3についても同様である。この場合、全アクセス数がしきい値付近で変動しても、しきい値をまたぐ毎にサーバ群の状態を切り替えなくてもよいので、状態切替に伴うオーバヘッドを低減できる。その結果情報処理システム2全体のレスポンスが向上しうる。なお、第1モード切替値Mo1と第2モード切替値Mo2とは、やはりオーバヘッドと処理速度とのかねあいで定めればよい。
図9は、オーバヘッドと性能のかねあいを説明するための、各サーバ群の稼働率を示すグラフである。ここでは、第1サーバ群22aから第5サーバ群22eのピークアクセス数が全て2000であるとする。また、第1モード切替値Mo1は7700、第2モード切替値Mo2は8300に設定されている。
図9では全アクセス数が7500から8200に変わった際の各サーバ群の稼働率が示される。この場合、変わった後の全アクセス数は第2モード切替値Mo2に届かないので、負荷管理装置10は依然として省電力モードに設定されたままであり、例えば第4サーバ群22dにピークアクセス数を越える数のアクセスが割り当てられることとなる。したがって第4サーバ群22dにおける処理速度は低下し、情報処理装置20全体の処理速度が低下する。対して実施の形態のようにヒステリシスを設けない場合は第5サーバ群22eが稼動状態に設定され、そこで第1サーバ群22a〜第4サーバ群22dでは処理しきれない新規のアクセスが処理される。しかしながら、第5サーバ群22eを省電力状態から稼動状態とする際にはオーバヘッドが存在するので、新規のアクセスを第5サーバ群22eに割り当てる前にそのオーバヘッドだけ待たなければならない。これはやはり情報処理装置20全体の処理速度の低下と見ることができる。したがって、サーバ群にピークアクセス数以上のアクセスを課すことによる処理速度の低下と、サーバ群の状態切替に伴うオーバヘッドが引き起こす処理速度の低下と、のかねあいでヒステリシスが決定されてもよい。
実施の形態では、サーバ群をどの状態に置くかについて、状態設定部150において表1に示されるストラテジが使用される場合について説明したが、これに限られない。例えば、省電力状態としてOS休眠状態を使用し、電源オフ状態を使用しなくてもよい。この場合、電源オンオフにかかる比較的長いオーバヘッドがなくなるので、より早いレスポンスが期待できる。また、処理が簡素化される。別の例としては、省電力状態として電源オフ状態を使用し、OS休眠状態を使用しなくてもよい。この場合、消費電力をより低減できる。
実施の形態では、状態設定部150は負荷管理装置10を省電力モードに設定する場合について説明したが、これに限られない。例えば、状態設定部150が少なくとも1つのサーバ群を省電力状態とすることをもって、負荷管理装置10は省電力モードであると認識してもよい。つまり、負荷管理装置10は省電力モードであるとの別個のインジケータがなくとも、サーバ群状態テーブル114のサーバ群の状態を見ることでどのモード(通常モードか、省電力モードか)であるかを判別してもよい。
実施の形態では、第1サーバ群22a〜第5サーバ群22eの要求の処理能力はほぼ等しく設定される場合について説明したが、これに限られない。情報処理装置20に含まれる複数のサーバ群のうちの少なくとも2つについて、それらの要求の処理能力が異なる場合でも、本実施の形態と同等の作用効果を有することは本明細書に触れた当業者には理解される。
実施の形態では、稼動サーバ群決定部154がアクセスの同一性を保証する場合について説明したが、これに限られず、アクセスの同一性が要求される場合は負荷管理装置10がアクセスの同一性を保証すればよい。
実施の形態では、サーバ群選択部134は省電力モードでは、稼動状態にあるサーバ群の稼働率が100%となるように、稼動状態にあるサーバ群から新規のアクセスを処理させるサーバ群を選択する場合について説明したが、これに限られない。例えば、サーバ群選択部134は、稼動状態にあるサーバ群のなかから、ラウンドロビン方式や最速方式などの公知の負荷分散アルゴリズムを使用して新規のアクセスを処理させるサーバ群を選択してもよい。これらの場合でも、依然として省電力モードでは省電力状態(OS休眠状態もしくは電源オフ状態)のサーバ群を設けているので、全体としての電力消費量を低減できる。
実施の形態では、第1フロントエンドサーバ24aと第1アプリケーションサーバ26aと第1データベースサーバ28aとは別個のサーバであり、この順に直列に接続されている場合について説明したが、これに限られない。個々のサーバ群は少なくともひとつのサーバを含めばよく、例えば、サーバ群はフロントエンドサーバとアプリケーションサーバとデータベースサーバの機能を全て併せ持つ1台のサーバを含んでもよい。また、サーバ群は、それら3つのサーバの機能のうちの任意の2つの機能を併せ持つサーバと、残りの機能を持つサーバと、を含んでもよい。
実施の形態では、負荷管理装置10は、負荷がモード切替値Moより少ない場合は省電力モード、以上の場合は通常モードに設定される場合について説明したが、これに限られない。例えば、多くのサーバ群を有する情報処理システムでは、負荷の許容量が大きく、通常モードを設定する必要がない場合もある。このような場合では負荷管理装置は常に省電力モードに設定され、通常モードは設定されないか実装されていなくてもよい。この場合でも本実施の形態で説明した効果と同様の効果を得ることができる。
実施の形態では、負荷予測部160は予測アクセス数を負荷比較部152に渡す場合について説明したが、これに限られない。例えば、負荷予測部160は一年以上前の同月同日の同じ時間帯の稼動サーバ群の数222を取得し、その稼動サーバ群の数222を稼動サーバ群決定部154に渡してもよい。この場合、稼動サーバ群決定部154はこの稼動サーバ群の数222を基に稼動状態にするサーバ群を決定する。
実施の形態では、要求処理ユニットがサーバ群である場合について説明したが、これに限られない。本実施の形態に係る技術思想は例えばGSLB(Global Server Load Balance)にも応用されうる。そこでは、要求処理ユニットはそれ自体が複数の並列に配されたサーバ群を有するシステムであってもよい。また、実施の形態では要求はユーザからのアクセスである場合について説明したが、これに限られず、本実施の形態に係る技術思想が適用されるシステムによって異なってもよい。要求とは処理主体への処理の指示であるとも言える。
実施の形態では、負荷管理装置10と情報処理装置20とが異なる装置である場合について説明したが、これに限られず、負荷管理装置10と情報処理装置20とが一体となっていてもよい。
以上、実施の形態にもとづき本発明を説明したが、実施の形態は、本発明の原理、応用を示しているにすぎないことはいうまでもなく、実施の形態には、請求の範囲に規定された本発明の思想を逸脱しない範囲において、多くの変形例や配置の変更が可能であることはいうまでもない。
2 情報処理システム、 4 ネットワーク、 6 ユーザ端末、 10 負荷管理装置、 20 情報処理装置、 110 記憶装置、 112 稼動履歴テーブル、 114 サーバ群状態テーブル、 116 接続テーブル、 120 要求取得部、 130 要求割当部、 140 負荷検出部、 150 状態設定部、 160 負荷予測部、 180 稼動履歴記録部。

Claims (7)

  1. ネットワークからの情報処理装置に対する要求を取得する要求取得部と、
    前記要求取得部によって取得された要求の負荷を検出する負荷検出部と、
    前記負荷検出部によって検出された負荷が所定の値より少ない場合、前記情報処理装置に含まれる少なくともひとつの要求処理ユニットを、要求を受付可能な第1状態よりも省電力の第2状態に設定する状態設定部と、
    前記要求取得部によって取得された要求を前記情報処理装置に含まれる他の要求処理ユニットに割り当てる要求割当部と、を備えることを特徴とする負荷管理装置。
  2. 前記状態設定部は、要求処理ユニットの最大性能を発揮せしめる前提で、前記要求取得部によって取得された要求を処理させる要求処理ユニットを決定し、残りの要求処理ユニットを前記第2状態に設定することを特徴とする請求項1に記載の負荷管理装置。
  3. 前記状態設定部は、前記負荷検出部によって検出された負荷の変動により前記情報処理装置の性能が落ちると予測される場合には、前記第2状態に設定されている少なくともひとつの要求処理ユニットを前記第1状態に設定し、
    前記要求割当部は、前記要求取得部によって取得された要求を、前記状態設定部によって前記第2状態から前記第1状態に設定された要求処理ユニットに割り当てることを特徴とする請求項1または2に記載の負荷管理装置。
  4. 過去の稼動履歴を基に負荷を予測する負荷予測部をさらに備え、
    前記状態設定部は、前記負荷予測部によって予測された負荷が前記所定の値より少ない場合、少なくともひとつの要求処理ユニットを、前記第2状態に設定することを特徴とする請求項1から3のいずれかに記載の負荷管理装置。
  5. ネットワークからの要求を処理する情報処理装置と、
    前記ネットワークと接続され、前記ネットワークからの前記情報処理装置に対する要求を前記情報処理装置に送る負荷管理装置と、を備え、
    前記情報処理装置は、それぞれが要求の処理単位である複数の要求処理ユニットを含み、
    前記負荷管理装置は、
    前記ネットワークからの前記情報処理装置に対する要求を取得する要求取得部と、
    前記要求取得部によって取得された要求の負荷を検出する負荷検出部と、
    前記負荷検出部によって検出された負荷が所定の値より少ない場合、前記情報処理装置に含まれる少なくともひとつの要求処理ユニットを、要求を受付可能な第1状態よりも省電力の第2状態に設定する状態設定部と、
    前記要求取得部によって取得された要求を前記情報処理装置に含まれる他の要求処理ユニットに割り当てる要求割当部と、を含むことを特徴とする情報処理システム。
  6. ネットワークからの情報処理装置に対する要求を取得するステップと、
    取得された要求の負荷を検出するステップと、
    検出された負荷が所定の値より少ない場合、前記情報処理装置に含まれる少なくともひとつの要求処理ユニットを、要求を受付可能な第1状態よりも省電力の第2状態に設定するステップと、
    取得された要求を前記情報処理装置に含まれる他の要求処理ユニットに割り当てるステップと、を含むことを特徴とする負荷管理方法。
  7. ネットワークからの情報処理装置に対する要求を取得する機能と、
    取得された要求の負荷を検出する機能と、
    検出された負荷が所定の値より少ない場合、前記情報処理装置に含まれる少なくともひとつの要求処理ユニットを、要求を受付可能な第1状態よりも省電力の第2状態に設定する機能と、
    取得された要求を前記情報処理装置に含まれる他の要求処理ユニットに割り当てる機能と、をコンピュータに実現させることを特徴とするコンピュータプログラム。
JP2009228702A 2009-09-30 2009-09-30 負荷管理装置、情報処理システムおよび負荷管理方法 Pending JP2011076468A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009228702A JP2011076468A (ja) 2009-09-30 2009-09-30 負荷管理装置、情報処理システムおよび負荷管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009228702A JP2011076468A (ja) 2009-09-30 2009-09-30 負荷管理装置、情報処理システムおよび負荷管理方法

Publications (1)

Publication Number Publication Date
JP2011076468A true JP2011076468A (ja) 2011-04-14

Family

ID=44020365

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009228702A Pending JP2011076468A (ja) 2009-09-30 2009-09-30 負荷管理装置、情報処理システムおよび負荷管理方法

Country Status (1)

Country Link
JP (1) JP2011076468A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016006638A (ja) * 2014-05-28 2016-01-14 セイコーソリューションズ株式会社 負荷分散装置、負荷分散方法及びプログラム
JP2016177376A (ja) * 2015-03-18 2016-10-06 富士ゼロックス株式会社 プログラム、情報処理装置及び情報処理方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016006638A (ja) * 2014-05-28 2016-01-14 セイコーソリューションズ株式会社 負荷分散装置、負荷分散方法及びプログラム
JP2016177376A (ja) * 2015-03-18 2016-10-06 富士ゼロックス株式会社 プログラム、情報処理装置及び情報処理方法

Similar Documents

Publication Publication Date Title
JP4824806B2 (ja) 負荷管理装置、情報処理システムおよび負荷管理方法
Hameed et al. A survey and taxonomy on energy efficient resource allocation techniques for cloud computing systems
JP6568931B2 (ja) 行動型需要反応ランキング
Choudhary et al. A critical analysis of energy efficient virtual machine placement techniques and its optimization in a cloud computing environment
EP2721461B1 (en) Power and load management based on contextual information
Maheshwari et al. Dynamic energy efficient data placement and cluster reconfiguration algorithm for MapReduce framework
US9003211B2 (en) Method and apparatus for holistic power management to dynamically and automatically turn servers, network equipment and facility components on and off inside and across multiple data centers based on a variety of parameters without violating existing service levels
JP4681676B1 (ja) 情報処理システムおよび情報処理方法
US9870269B1 (en) Job allocation in a clustered environment
Liu et al. An economical and SLO-guaranteed cloud storage service across multiple cloud service providers
TW200404199A (en) Method for managing power consumption in computer servers
JP2005531047A (ja) 複数コンピュータ・サーバの電力消費を管理する方法
CN102917077A (zh) 云计算系统中的资源分配方法
JP4824807B2 (ja) 負荷管理装置、情報処理システムおよび負荷管理方法
Dargie et al. Analysis of the power and hardware resource consumption of servers under different load balancing policies
Chandra et al. Resource management for scalable disconnected access to web services
Rahmani et al. Burst‐aware virtual machine migration for improving performance in the cloud
Orgerie et al. ERIDIS: energy-efficient reservation infrastructure for large-scale distributed systems
JP2011076468A (ja) 負荷管理装置、情報処理システムおよび負荷管理方法
JP4878394B2 (ja) 運用管理装置および運用管理方法
Imada et al. Power management of distributed web savers by controlling server power state and traffic prediction for QoS
JP4878397B2 (ja) 情報処理システムおよび情報処理方法
Paya et al. Energy-aware application scaling on a cloud
JP5309200B2 (ja) 運用管理装置および情報処理システム
Tian et al. Energy Management