WO2004084085A1

WO2004084085A1 - サイト間連携による負荷分散システム

Info

Publication number: WO2004084085A1
Application number: PCT/JP2003/003273
Authority: WO
Inventors: Tsutomu Kawai; Satoshi Tutiya; Yasuhiro Kokusho
Original assignee: Fujitsu Limited
Priority date: 2003-03-18
Filing date: 2003-03-18
Publication date: 2004-09-30
Also published as: JPWO2004084085A1

Abstract

ネットワーク１１を介してクライアント１０から直接リクエストを受信する前段センタ１２−１と、前段センタ１２−１を介してクライアント１０からのリクエストを受信する後段センタ１２−２からなるシステムにおいて、各センタが予備サーバ１７−１、１７−２を有する。まず、前段センタ１２−１が通常のサーバを使ってサービスを提供する。サーバの負荷が大きくなったことを検出したシステム制御装置１６−１は、サービス１とサービス２に共通に設けられた予備サーバ１７−１から負荷が大きくなったサービスの提供用にサーバを提供する。それでも負荷が支えきれないときは、システム制御装置１６−１が後段センタ１２−２のシステム制御装置１６−２にサービスの提供をになうよう指示を出す。後段センタ１２−２も、負荷が通常サーバで支えきれなくなったら、予備サーバ１７−２を使って、負荷を支える。

Description

明細書サイト間連携による負荷分散システム技術分野

本発明は、サイト間連携による負荷分散システムに関する。背景技術

インターネットの爆発的な普及によつてサービス提供側で必要となるサーバ、ネットワーク等のリソースは膨大なものとなってきている。しかし、ユーザからの要求の量は時間や条件によって大きく変動することが分かっており、集中時にあわせてリソースを確保しておけば通常時には無駄なリソースの維持が必要となり、かといつて集中時には対応できないリソースでは、サービス品質の低下を招きユーザに不快感を与えることとなる。更にユーザ数の増加に伴い必要なリソースの上限を見積もることは困難になっており、リソースを必要に応じて割り当てるシステムが必要となってくる。同時に過剰なリソースは管理コストの増大を招くため、必要でないリソースを有効に利用するための仕みも必要とされている。

図 1は、従来の負荷分散システムの一例である。

図 1の構成では、クライアント 1 0がネットワーク 1 1を介してデータセンタ 1 2にアクセスし、サービスを受ける。負荷分散装置 1 3には、複数のサーバ 1 4が接続されている。

1台のサーバでは処理しきれない場合、図 1のようにサーバを複数台設置し、その前段に負荷分散装置 1 3を配置することで負荷を複数のサーバに分散し、サービス品質を向上させるが、サーバ 1 4の追加判定やサーバ 1 4 .負荷分散装置 13の追加、設定変更の作業は人手で行われることが多く、また最大負荷に合わせたサーバを常時確保する必要があるため大きなコストがかかる。

特許文献 1では、サーバの追加及びユーザからのリクエストの振り分け方法を定義しているが、ユーザ側にサーバ選択のための機構を組み込む必要があり、不特定多数向けのサービスへの適用には適していない。また、リクエスト以外の管理情報のやりとりが必要になるという問題がある。

また、特許文献 2の方式は、静的な情報を配信する場合にしか適用できず、サービス提供等ユーザからの要求によつて毎回異なる情報を返す場合には適用できない。

更に、特許文献 3についても静的情報の場合を想定しており、ファイルサーバ等への負荷が過剰になつた場合については考慮されていない。

特許文献 1

特開平 9一 106381号公報

特許文献 2

特開平 9一 1 79820号公報

特許文献 3

特開 2002— 259354号公報発明の開示

本発明の目的は、サービス提供のための負荷を分散し、ユーザからの要求の変化に柔軟に対応できる負荷分散システムを提供することである。

本発明の方法は、クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置の負荷分散の方法であって、通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサービスの設定もされていない複数の予備サーバを設けるステップと、通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアブリケーシヨンを設定して、該サービスの提供用サーバとし、通常サービスを提供するサーバと負荷を分担させる制御ステップとを備えることを特徴とする。本発明によれば、データセンタなどの装置内に、通常サービスを提供するサーパの他に、予備サーバを複数設け、通常サービスを提供するサーバの負荷が大きくなつた場合には、予備サーバに、そのサービスを提供可能なようにアブリケ——ンョンをインストールして、当該サーバの当該サービスを提供するための負荷を分担させる。

また、別の形態では、本発明に従って、予備サーバを備えた装置をネットヮークで接続し、互いに、予備サーバを提供し合うように制御することにより、 1つのデータセンタでは、一時的な負荷を支える程の処理能力を得られなくても、複数の装置がネットワークを介して協同して負荷に対処することにより、大きな負荷によってサービス提供の中断を避けることが出来る。また、これにより、 1つの装置に備える予備サーバの数を減らすことが出来、ハードウエアを冗長に、各装置に持たせる必要が無くなる。図面の簡単な説明

図 1は、従来の負荷分散システムの一例である。

図 2は、本発明の実施形態の基本構成を示す図である。

図 3は、図 2の基本構成におけるセンタ内のネットワーク配置構成を示す図である。

図 4は、本発明の第 1の実施形態を示す図である。

図 5は、本発明の第 1の実施形態の動作を示す図である。

図 6は、サーバの負荷と容量を算出するためのデータを示す図である。図 7は、負荷の大きさに応じてサーバの選択をするためのデータを示す図である。

図 8は、追加するサーバの能力と負荷の予測値との関係を示した図である。図 9は、複数のサービスで予備サーバを共用する構成を示した図である。図 1 0は、異なるセンタ間で予備サーバの提供を行う場合の構成を示す図でめる。

図 1 1は、本発明の実施形態の動作を説明する図である。

図 1 2は、他センタとの連携を図る場合におけるネットワーク帯域の確保に関する説明をする図である。

図 1 3は、ウェブサーバにおける本発明の実施形態の適用例を示す図である。図 1 4は、ウェブサービスにおける本発明の実施形態の適用例を示す図であ図 1 5は、対等なセンタ間が相互にリソースを融通し合う場合の本発明の実施形態の適用例である。

図 1 6は、予備サーバを持たない前段センタの場合に本発明の実施形態を適用した例を示す図である。

図 1 7〜図 2 4は、センタに設けられるデータベース間の連携のない場合の本発明の実施形態の動作を説明するフローチャートである。

図 2 5〜図 3 0は、データベースの連携がある場合の本発明の実施形態の処理の流れを示すフローチャートである。発明を実施するための最良の形態

本発明では、ユーザからの要求量の変化を予測し、それに合わせてデータセンタ内、もしくは、連携する別データセンタ内のサーバを動的に追加、削除することでサービス品質を保証し、同時に余剰サーバを複数のサービスで共用することでコスト削減を目指すものである。図 2は、本発明の実施形態の基本構成を示す図である。

クライアント 10は、ネットワーク 1 1を介して、前段センタ 1 2—1の負荷分散装置 1 3_ 1経由で、 We bサーバ 1 5— 1にアクセスする。 We bサーバ 1 5— 1でのデータ処理の結果、クライアント 10は、データベースサーパ 14— 1あるいは、ファイルサーバ 14一 2にアクセスして、サービスを受ける。後段サーバ 1 2— 2は、前段センタ 1 2— 1とほぼ同様の構成をしており、負荷分散装置 1 3— 1経由でクライアント 10からの要求を受け付け、負荷分散装置 1 3-2で負荷分散を行いながら、 We bサーバ 15— 2にクライアント 10を導く。そして、クライアント 1 0は、 We bサーバ 1 5— 2を介して、データベースサーバ 14— 3あるいは 14 _ 4にアクセスし、サービスを受ける。

ここで前段センタ 1 2-1とは、ユーザの要求を直接受け取るセンタを指し、後段センタ 12— 2とは前段センタ 12— 1を通してユーザ要求を処理するセンタを示している。データセンタ間でのサーバの割当ては多対多の関係であり、あるデータセンタが複数のデータセンタのサーバを利用する場合や複数のデータセンタからのサーバ要求に同時に、あるデータセンタが応じる場合もある。サーバの負荷状態ゃクライアントからの負荷状態はシステム制御装置 1 6- 1,

16— 2が集計 ·判定 '適用を行い、結果をサーバ 14一 1〜14一 4や負荷分散装置 1 3— 1、 1 3— 2に設定する。サーバリソースが不足した場合には予備サーバ内のサーバ 1 7_ 1、 1 7— 2を必要な機能のサーバとして設定した上で、サービスに追加し、能力を向上させる。

物理的なネットワーク構成は単一のスィッチ群 20の直下に全てのサーバを接続し、その上に論理的に独立したネットワーク（VLAN0、 VLAN 1 1、 V L AN 1 2、 V L AN 2 1 ) を複数構成する。このような配置にすることで必要な位置へのサーバ追加処理を自動化することが可能となる。

サーバの追加、削除を行う場合には、 C P U性能ゃネットワーク構成等のサーバ仕様からサーバ能力を導きだし、様々な種類のハードが混在する環境であつても必要なサーバの算出を行い、適切にサーバの割当てを行う。同時にそのサーバに対してかかるトラフィックを計算し、ネットワーク帯域の確保もしくは調停を行う。

また、負荷計測及び負荷変動予測から将来の負荷を予想することで過剰負荷となる前にサーバの追加を行い、サービス品質の保証を実現する。

図 4は、本発明の第 1の実施形態を示す図である。

同図において、図 2と同様な構成要素には同様の参照符号を付して詳細な説明を省略する。

ユーザからのリクエストが割当てたサーバの能力を超えた場合、応答時間の増大や無応答が発生し、ユーザに対し不快感を与えることになる。その状態で更に負荷が増大した場合には、サーバ障害が引き起こされる場合もある。これを防ぐために、サーバの負荷状態の計測をシステム制御装置 1 6が行い、現在のサーバ数では問題を起こすと判断した場合には、予備サーバ 1 7からサーバの追加を行い、アプリケーションやサービス、利用するデータ等の設定及び導入を行う。そして、依存関係にある機器及びサーバ等の設定を更新することでサービスに組み込む。

図 5は、本発明の第 1の実施形態の動作を示す図である。

同図において、図 4と同じ構成要素には同じ参照符号を付して説明を省略する。

ユーザからのリクエスト量が減少した場合には、余剰サーバが発生する。この余剰サーバ分については削除したとしてもサービス品質は低下せず、むしろ運用コストゃ利用率の向上という面からは予備サーバとして開放し、他のサービスで利用することが望ましい。このため依存関係にある機器から関係する設定を削除することでサービスとの連携を解消し、その後設定の解除等の処理を行い、予備サーバ 1 7に戻す。

図 6は、サーバの負荷と容量を算出するためのデータを示す図である。サービス能力を必要に応じて追加 ·削除するためには、あるサーバがどれだけのサービス能力を提供するかといつた情報が必要となる。データセンタ等においては、利用するサーバや機器、そしてアプリケーションやサービスの組み合わせによって 1ュニットあたりのサービス能力は変化する。利用するサーバを均一なものでそろえることは、複数のデータセンタが連携する場合などにおいては現実的に不可能であり、そのため C P Uゃメモリ等の機器仕様からサービス能力を算出する必要がある。このため、典型的な構成における性能値から

C P U能力等の違いを考慮して性能値を推定する方法を利用する。

図 7は、負荷の大きさに応じてサーバの選択をするためのデータを示す図であ o。

ここでは、サービス能力だけでなく、サーバュニットの特性としてどのような用途に利用するかが好ましいかという情報を保持する。上記のように利用できるサーバごとの性能値は均一でないため、これらを組み合わせて必要な能力を提供できる構成を作成する必要がある。このため図 6で求めた性能値と特性及び要求される性能値から、推奨度の高いサーバを優先して要求量を満たすまでサーバを選択し、利用する。

図 8は、追加するサーバの能力と負荷の予測値との関係を示した図である。計測されたリクエスト量がサービス能力を超える場合にリソースを追加するだけでは、急激に負荷が上昇しつつある場合等にサービス品質が保証出来なくなる。そのため負荷の傾向を把握し、リクエスト量の増加が見込まれる場合には予測されるリクエスト量に見合ったサービス能力を予め追加しておくことでサービス品質の低下を防ぐ。予測の仕方としては、線形外挿などを行うなどが考えられる。

図 9は、複数のサービスで予備サーバを共用する構成を示した図である。あるデータセンタ内の複数のサービスの負荷状態を見た場合、全てのサービスが同時に高負荷となることは極めて希であり、サービス毎に予備リソースを確保したのでは利用されないリソースが常時存在すると考えられる。予備リソースを複数のサービスで共用することで、全体としてより少ない予備リソースで必要なサービス能力の追加が可能となる。また、共用することで維持コストを分散させることが出来る。センタ 1 2には、サービス 1とサービス 2が搭載されており、それぞれに負荷分散装置 1 3 - 1 , 1 3 - 2が設けられる。サービス 1には、 W e bサーバ 1 5— 1、データベースサーバ 1 4— 1、フアイルサーバ 1 4— 2が設けられる。サービス 2には、サーバ 2 5が設けられる。予備サーバ 1 7は、サービス 1とサービス 2に共通に設けられており、システム制御装置 1 6が負荷の状況を見て、予備サーバ 1 7から、サービス 1あるいはサービス 2に、追加サーバを導入する。

図 1 0は、異なるセンタ間で予備サーバの提供を行う場合の構成を示す図である。

同図において、図 2と同様な構成要素には同じ参照符号を付し、説明を省略する。

データセンタ 1 2— 1の規模によっては、たとえ予備サーバを異なるサービス間で共用したとしても物理的もしくはコスト的に充分な予備サーバ 1 7— 1 を確保できないケースがある。また十分に確保しておいたつもりであっても突発的な負荷によってデータセンタ内の予備サーバではまかないきれない場合が起こり得る。このような場合に、ネットワークで接続されている別のデータセンタ 1 2— 2を後段センタとし、その予備サーバ 1 7— 2をネットワーク経由で利用する。

図 1 1は、本発明の実施形態の動作を説明する図である。

同図においては、図 9と同じ構成要素には同じ参照符号を付して、説明を省略する。

サービスによつては直接ユーザと情報を交換するサーバ以外にもデータべ一ス等連携して動作するサーバが必要なものがある。このようなサービスの場合、それぞれの機能毎に処理能力や負荷状態の確認を行い適切な機能にサーバを追加しなければ性能の向上が望めない。そのためシステム制御装置 1 6は、各階層毎に負荷の確認を行い、追加 ·削除時には連携しているサーバの設定を変更することで能力の増減を図る。

なお、同図において、図 1 0と同じ構成要素には同じ参照符号を付している。複数のサービスが同時に動作する場合や連携処理が必要な場合には、サーバを追加するだけでなく各サービスや機能間のトラフィックを調停しなければ充分な処理能力が得られない。それぞれの部分で必要となる帯域を計算し、それらの割合を考慮した上でネットワークに対して各帯域の確保を行うことで全体として充分な性能を出せる様にする。

上記の構成により、ユーザからの負荷とサーバ能力の状態を監視し、負荷がサーバ能力を超える前に必要充分なリソースを、データセンタ内、もしくは連携するデータセンタから割り当てることが出来るようになり、ユーザからのリクエストに対するサービス品質の保証が可能となる。同時に必要となる予備サーバを広範囲で共用することが可能になるため、全体として必要なサーバの総量を減らすことができる。また、複数の機能を持つサーバが連携し合うサービスであっても、ボトルネックとなっている機能に対してサーバの追加を行うことができるため、充分な大規模化が可能になる。更に全体の処理を自動化可能なため、ユーザからの要求量の変化に素早く追従可能である。

図 1 3は、ウェブサーバにおける本発明の実施形態の適用例を示す図である。同図において、図 1 2と同じ構成要素には同じ参照符号を付して説明を省略する。

負荷が軽い状態では、前段センタ 1 2— 1のみで運用される。負荷が増加した場合は、前段センタ 1 2 - 1内の予備サーバ 1 7— 1をウェブサーバ 1 5— 1として追加する。更に負荷が増大してくると後段センタ 1 2— 2にウェブサーバ群 1 5— 2を作成し、後段センタ 1 2 - 2でも負荷を受け持つようにする。図 1 4は、ウェブサービスにおける本発明の実施形態の適用例を示す図である。

同図において、図 1 2と同じ構成要素には、同じ参照符号を付して説明を省略する。

この例では、ウェブサービスがゥヱブサーバ 1 5— 1とデータベースサーバ 1 4 - 1 , フアイルサーバ 1 4 _ 2の組み合わせで構成されている。負荷が軽い状態では、前段センタ 1 2— 1のみで運用される。負荷の増大に伴い、ボトルネックとなつた部分に順次予備サーバ 1 7 - 1の追加を行っていき、前段センタ 1 2— 1でまかない切れなくなった場合には後段センタ 1 2— 2との連携を行う。この例のデータベースサーバ 1 4— 1は、前段センタ 1 2 _ 1と後段センタ 1 2— 2の間で連携中もデータの同期を行う。これはセンタ間をまたぐ V L ANの作成及び帯域確保を行うことで実現する。

図 1 5は、対等なセンタ間が相互にリソースを融通し合う場合の本発明の実施形態の適用例である。

センタ 1内のサービス 1の処理能力がセンタ 1内の予備サーバ 3 0— 1でまかなえなくなった場合、センタ 2に対して連携を依頼しセンタ 2内のサーバ（網掛け部分及ぴ予備サーバ 3 0— 3 ) を利用する。更にセンタ 2内のサーバ容量も枯渴した場合（予備サーバ 3 0— 2を含めた容量が枯渴した場合）は別のセンタ 3に対して連携を依頼しセンタ 3内のサーバ（網掛け部分及び予備サーバ 3 0 - 3 ) を利用する。

前段センタ 1 2—1において、サービス提供に対してサーバが不足したとシステム制御部 1 6 - 1が判断した場合には、後段センタ 1 2 - 2に連携を依頼し、後段センタ 1 2— 2内のサーバを利用する。ここでは、負荷分散装置、及び W e bサーバをサービス 1とサービス 2に対して提供する。サービス 1，とサービス 2，のサーバは、それぞれサービス 1及ぴサービス 2のサービスを行う。更に、後段センタ 1 2— 2では、サーバの容量が足りなくなった場合には、予備サーバ 1 7をそれぞれのサービスに必要なだけ追加する。追加の判断や、前段センタ 1 2— 1 との連携は、システム制御部 1 6 _ 2が行う。

図 1 7〜図 2 4は、センタに設けられるデータベース間の連携のなレ、場合の本発明の実施形態の動作を説明するフローチヤ一トである。

図 1 7は、システム制御装置の全体の流れを示すフローチャートである。まず、ステップ S 1 0において、負荷計測を行う。ステップ S 1 1において、予測処理能力が割当て済み処理能力を超えているか否かを判断する。ステップ S 1 1の判断が Y E Sの場合には、ステップ S 1 2において、処理能力の追加を行いステップ S 1 5に進む。ステップ S 1 5では、 1 0秒待つとなっている力この数値は設計者が適宜設定すべきものである。

ステップ S 1 1における判断が N Oの場合には、ステップ S 1 3において、現在処理能力が割当て済み処理能力の 2分の 1以下であるか否かを判断する。ステップ S 1 3の判断が Y E Sの場合には、ステップ S 1 4において、処理能力の削減を行い、ステップ S 1 5に進む。ステップ S 1 3の判断が N Oの場合には、ステップ S 1 5に進む。

ステップ S 1 5の後は、再びステップ S 1 0に戻る。

図 1 8は、図 1 7のステップ S 1 0の負荷計測の詳細を示す図である。ステップ S 2 0において、使用サーバから 1 0秒間の平均の処理数を収集する。この 1 0秒というのは、図 1 7のステップ S 1 5の値と一致するべきものである。ステップ S 2 1において、総平均処理数を計算し、計測履歴に追加する。ステップ S 2 2において、計測履歴が 4項以上あるか否かを判断する。ステツプ S 2 2の判断が N Oの場合には、ステップ S 2 3において、最新履歴を 3 0秒後の予測値として、ステップ S 2 5に進む。ステップ S 2 2における判断が Y E Sの場合には、ステップ S 2 4において、最新 4履歴から最小 2乗近似で 3 0秒後の予測値を算出し、ステップ S 2 5に進む。これは、最新の 4履歴から、回帰曲線を求め、回帰曲線を使って、 3 0秒後の予測値を得ることである。ステップ S 2 5においては、 3 0秒後の予測値を設定し、ステップ S 2 6において、最新履歴を現在値に設定して図 1 7のフローに戻る。

図 1 9は、図 1 7のステップ S 1 2の処理能力追加処理の詳細を示す図である。

ステップ S 3 0において、予測値から現在割当て値を引いて追加処理能力量を決定する。ステップ S 3 1において、センタ内に予備サーバがあるか否かを判断する。ステップ S 3 1の判断が Y E Sの場合には、ステップ S 3 2において、センタ内の追加サーバを選択する。ステップ S 3 3では、追加処理能力量が充足されたか否かを判断する。ステップ S 3 3の判断が N〇の場合には、ステツプ S 3 4へ、判断が Y E Sの場合には、ステップ S 3 8に進む。ステップ S 3 1の判断が N Oの場合には、ステップ S 3 4に進む。 3 4においては、予備処理能力を持つ連携先センタがあるか否かを判断する。ステップ S 3 4の判断が Y E Sの場合には、ステップ S 3 6において、連携センタで処理能力を割当てる。ステップ S 3 7においては、追加処理能力量が充足されたか否かを判断する。ステップ S 3 7の判断が N Oの場合には、ステップ S 3 4に進む。ステップ S 3 7の判断が Y E Sの場合には、ステツプ S 3 8に進む。ステップ S 3 4の判断が N Oの場合には、ステップ S 3 5において、追加処理能力量の充足不能を管理者に警告して、ステップ S 3 8 に進む。ステップ S 3 8では、選択されたサーバを含むよう V L A Nを設定し、ステップ S 3 9において、選択されたサーバにアプリケーションを設定し、ステツプ S 4 0に進む。

ステップ S 4 0においては、センタ間の連携があるか否かを判断し、判断が N Oの場合には、ステップ S 4 3に進む。ステップ S 4 0の判断が Y E Sの場合には、ステップ S 4 1において、連携センタ負荷分散比率の決定、及び割当て装置の設定を行い、ステップ S 4 2において、自センタと連携センタとの間の通信帯域を設定し、ステップ S 4 3に進む。ステップ S 4 3においては、自センタの負荷分散比率を決定し、割当て装置を決定して、図 1 7のフローに戻る。

図 2 0は、図 1 9のステップ S 3 2の追加サーバの選択処理を詳細に示すフローである。

ステップ S 5 0において、必要な用途向けのサーバがあるか否かが判断される。ステップ S 5 0の判断が N Oの場合には、ステップ S 5 4に進む。ステツプ S 5 0の判断が Y E Sの場合には、ステップ S 5 1において、必要な用途向けサーバ内で、 1台で追加処理能力量を充足可能なサーバがあるか否かを判断する。ステップ S 5 1の判断が N Oの場合には、ステップ S 5 2において、必要な用途向けで最大性能のサーバを選択し、ステップ S 5 0に戻る。ステップ S 5 1の判断が Y E Sの場合には、必要な用途向けサーバの内、 1台で追加処理能力量をまかなえるサーバの内、最低性能のサーバを選択し、ステップ S 5 8に進む。 .

ステップ S 5 4においては、利用可能なサーバがあるか否かを判断する。ステツプ S 5 4の判断が N Oの場合には、ステップ S 5 8に進む。ステップ S 5 4の判断が Y E Sの場合には、ステップ S 5 5において、 1台で追加処理能力量を充足可能なサーバあるか否かを判断する。ステップ S 5 5の判断が N〇の場合には、ステップ S 5 6において、最大性能のサーバを選択し、ステップ S 5 4に戻る。ステップ S 5 5の判断が Y E Sの場合には、ステップ S 5 7において、 1台で追加処理能力量を充足可能なサーバの内、最低の性能のサーバを選択し、ステップ S 5 8に進む。ステップ S 5 8においては、割り当てられたサーバ一覧を構成して、図 1 9の処理に戻る。

図 2 1は、図 1 9のステップ S 3 6の連携センタ処理能力割当て処理の流れを示すフローである。

ステップ S 6 0において、帯域による処理能力上限が割当て希望値より小さいか否かを判断する。ステップ S 6 0の判断が N Oの場合には、ステップ S 6 2に進む。ステップ S 6 0の判断が Y E Sの場合には、ステップ S 6 1において、割当量上限を帯域上限とし、ステップ S 6 2に進む。

ステップ S 6 2においては、連携先センタにサーバ選択を依頼し、ステップ S 6 3において、連携先センタ内で追加サーバを選択し、ステップ S 6 4において、割り当てられたサーバ一覧を構成して、図 1 9の処理に戻る。

図 2 2は、図 1 9のステップ S 3 9のアプリケーション設定の詳細フローである。

ステップ S 7 0において、センタ間の連携があるか否かを判断する。ステツプ S 7 0の判断が N Oの場合には、ステップ S 7 4に進む。ステップ S 7 0の判断が Y E Sの場合には、ステップ S 7 1において、アプリケーションのァー力イブを転送済みか否かを判断する。ステップ S 7 1の判断が Y E Sの場合には、ステップ S 7 3に進む。ステップ S 7 1の判断が N Oの場合には、ステツプ S 7 2において、連携先センタにアプリケーションのアーカイブを転送し、ステップ S 7 3に進む。ステップ S 7 3においては、追加サーバにアプリケーシヨンをインストールし、ステップ S 7 4に進む。ステップ S 7 4では、自センタ内追加サーバにアプリケーションをィンストールし、図 1 9の処理に戻る。図 2 3は、図 1 7のステップ S 1 4の処理能力の削減処理を示すフローである。

ステップ S 8 0において、割当て値から現在の計測値を引き算し、削減処理能力量を決定する。ステップ S 8 1において、連携センタがあるか否かを判断する。ステップ S 8 1の判断が Y E Sの場合には、ステップ S 8 2において、連携センタで削減サーバを決定し、ステップ S 8 3において、連携センタの全サーバが削減されたか否かを判断する。ステップ S 8 3の判断が Y E Sの場合には、ステップ S 8 1に戻る。ステップ S 8 3の判断が N Oの場合には、ステップ S 8 5に進む。ステップ S 8 1の判断が N Oの場合には、ステップ S 8 4 において、自センタで削減サーバを決定し、ステップ S 8 5に進む。

ステップ S 8 5においては、自センタの負荷分散比率の決定、および割当て装置を設定する。ステップ S 8 6においては、連携センタの負荷分散比率を決定し、割当て装置を設定する。そして、ステップ S 8 7において、ユーザリクエスト処理の完了を待つ。ステップ S 8 8において、削減サーバからアプリケーシヨンを削除し、ステップ S 8 9において、残ったサーバのみを含むよう V L A Nを設定し（連携用ネットワーク通信路を設定し）、ステップ S 9 0において、連携の解除があるか否かを判断する。ステップ S 9 0の判断が Y E Sの場合には、ステップ S 9 1において、自センタと連携センタの帯域を解除して図 1 7の処理に戻る。ステップ S 90の判断が NOの時も、図 17の処理に戻る。図 24は、図 23のステップ S 82あるいは、ステップ S 84の削減サーバの選択処理を示すフローである。

ステップ S 100において、他用途に利用可能なサーバがあるか否かを判断する。ステップ S 100の判断が NOの場合、ステップ S 103に進む。ステップ S 100の判断が YESの場合、ステップ S 101において、残り削減十生能よりも性能が低いサーバがあるか否かを判断する。ステップ S 101の判断が NOの場合には、ステップ S 103に進む。ステップ S 101の判断が YE Sの場合には、ステップ S 102において、残り削減性能よりも性能が低いサーバの内、最大性能のサーバを削減してステップ S 100に進む。

ステップ S 103では、現在利用中のサーバがあるか否かを判断する。ステップ S 103の判断が NOの場合には、ステップ S 106に進む。ステップ S 103の判断が YE Sの場合には、ステップ S 104において、残り削減性能よりも性能が低いサーバがあるか否かを判断する。ステップ S 104の判断が NOの場合には、ステップ S 106に進む。ステップ S 104の判断が Y E S の場合には、ステップ S 105において、残り削減性能よりも性能が低いサーバの内、最大性能のサーバを削減して、ステップ S 103に戻る。

ステップ S 106では、削除されたサーバ一覧を生成し、図 23の処理に戻る。

図 25〜図 30は、データベースの連携がある場合の本発明の実施形態の処理の流れを示すフローチャートである。

図 25は、連携依頼を行う自センタの全体の処理の流れを示すフローである。ステップ S 1 10において、 We bサーバの負荷計測を行う。ステップ S 1 1 1において、予測処理能力が割当て済み処理能力より大きいか否かを判断する。ステップ S 1 1 1の判断が YE Sの場合には、ステップ S 1 1 2において、 W e b処理能力の追加を行い、ステップ S 1 1 5に進む。ステップ S 1 1 1の判断が N Oの場合には、ステップ S 1 1 3において、現在処理能力が割当て済み処理能力の 2分の 1より小さいか否かを判断する。ステップ S 1 1 3の判断が N〇の場合には、ステップ S 1 1 5に進む。ステップ S 1 1 3の判断が Y E Sの場合には、ステップ S 1 1 4において、 W e b処理の能力を削減して、ステツプ S 1 1 5に進む。ステップ S 1 1 5においては、センタ内データベースの負荷を計測する。ステップ S 1 1 6においては、予測処理能力が割当て済み処理能力より大きいか否かを判断する。ステップ S 1 1 6の判断が Y E Sの-場合には、ステップ S 1 1 7において、データベース処理能力の追加を行い、ステツプ S 1 2 0に進む。ステップ S 1 1 6の判断が N Oの場合には、ステップ S 1 1 8において、現在処理能力が割当て済み処理能力の 2分の 1より小さいか否かを判断する。ステップ S 1 1 8の判断が N Oの場合には、ステップ S 1 2 0に進む。ステップ S 1 1 8の判断が Y E Sの場合には、ステップ S 1 1 9 において、デ一タベースの処理能力の削減を行い、ステップ S 1 2 0に進む。ステップ S 1 2 0では、 1 0秒待つ。この待ち時間は、設計者により適宜設定されるべきものである。ステップ S 1 2 0の後は、再び、ステップ S 1 1 0に民

図 2 6は、連携先センタの全体処理の流れを示すフローである。

ステップ S 1 3 0において、センタ内のデータベース負荷を計測する。ステップ S 1 3 1において、予測処理能力が割当て済み処理能力より大きいか否かを判断する。ステップ S 1 3 1の判断が Y E Sの場合には、ステップ S 1 3 2 において、データベース処理能力を追加し、ステップ S 1 3 5に進む。ステツプ S 1 3 1の判断が N Oの場合には、ステップ S 1 3 3において、現在処理能力が割当て済み処理能力の 2分の 1より小さいか否かを判断する。ステップ S 1 3 3の判断が N Oの場合には、ステップ S 1 3 5に進む。ステップ S 1 3 3 の判断が Y E Sの場合には、ステップ S 1 3 4において、データベース処理能力削減を行い、ステップ S 1 3 5に進む。ステップ S 1 3 5においては、 1 0 秒待ち、ステップ S 1 3 0に戻る。この 1 0秒間はこれに限定されるべきものではなく、設計者によって適宜設定されるべきものである。

図 2 7は、各センタで行われるウェブ負荷計測あるいはデータベース負荷計測の詳細処理を示すフローである。

ステップ S 1 4 0においては、使用サーバから 1 0秒間の平均の処理数を収集する。この 1 0秒は、図 2 5のステップ S 1 2 0、図 2 6のステップ S 1 3 5の待ち時間と同じ値であるべきである。ステップ S 1 4 1において、総平均処理数を計算し、計測履歴に追加する。ステップ S 1 4 2において、計測履歴が 4項以上あるか否かを判断する。ステップ S 1 4 2の判断が N Oの時には、ステップ S 1 4 3において、最新履歴を 3 0秒後の予測値として、ステップ S 1 4 5に進む。ステップ S 1 4 2の判断が Y E Sの場合には、ステップ S 1 4 4において、最新 4履歴から最小 2乗近似で 3 0秒後の予測値を導出し、ステップ S 1 4 5に進む。この導出の仕方は、図 1 8で述べたとおりである。ステップ S 1 4 5においては、 3 0秒後の予測値を設定する。ステップ S 1 4 6においては、最新履歴を現在値に設定して図 2 5、 2 6の処理に戻る。図 2 8は、図 2 5のステップ S 1 1 2の W e b処理能力追加処理の詳細フロ一である。

図 2 8のフローは、連携センタを追加したときは、ステップ S 1 5 4からの処理を行う。

まず、ステップ S 1 5 0において、予測値から現在割り当て値を引き算し、追加処理能力量を決定する。ステップ S 1 5 1においては、センタ内に予備サーバがあるか否かを判断する。ステップ S 1 5 1の判断が N Oの時は、ステツプ S 1 5 4に進む。ステップ S 1 5 1の判断が Y E Sの時は、ステップ S 1 5 2において、センタ内の追加サーバの選択を行う。この処理の詳細は、図 2 0 に示すとおりである。そして、ステップ S 1 5 3において、追加処理能力量が充足されたか否かを判断する。ステップ S 1 5 3の判断が N Oの時は、ステツプ S 1 5 4に進む。ステップ S 1 5 3の判断が Y E Sの時は、ステップ S 1 5 8に進む。

ステップ S 1 5 4においては、予備処理能力を持つ連携先センタがあるか否かを判断する。ステップ S 1 5 4の判断が Y E Sの場合には、ステップ S 1 5 6において、連携センタで処理能力を割り当てを行う。この処理の詳細は、図 2 1に示すとおりである。ステップ S 1 5 7では、追加処理能力量が充足されたか否かを判断する。ステップ S 1 5 7の判断が N Oの場合には、ステップ S

1 5 4に戻る。ステップ S 1 5 7の判断が Y E Sの場合には、ステップ S 1 5 8に進む。ステップ S 1 5 4の判断が N Oの場合には、ステップ S 1 5 5において、追加処理能力量の充足が不能であることを管理者に警告して、ステップ S 1 5 8に進む。

ステップ S 1 5 8においては、選択されたサーバを含むよう V L A Nを設定し、ステップ S 1 5 9において、選択されたサーバにアプリケーションを設定する。アプリケーションの設定は、図 2 2に示したとおりである。ステップ S

1 6 0では、センタ間の連携があるか否かを判断する。ステップ S 1 6 0の判断の結果、 Y E Sであれば、ステップ S 1 6 1において、連携センタ負荷分散比率の決定及び装置設定を行い、ステップ S 1 6 2において、自センタと連携センタ間の通信帯域を設定し、ステップ S 1 6 3に進む。

ステップ S 1 6 0の判断が N Oの場合には、ステップ S 1 6 3にそのまま進む。ステップ S 1 6 3では、自センタの負荷分散比率を決定し、装置設定して、図 2 5の処理に戻る。

図 2 9は、図 2 5のステップ S 1 1 7及び図 2 6のステップ S 1 3 2のデータベース処理能力追加処理の詳細なフローである。

ステップ S 170において、予測値から現在の割り当て値を引き算し、追加処理能力量を決定する。ステップ S 171において、センタ内に予備サーバがあるか否かを判断する。ステップ S 1 71の判断が N〇の場合には、ステップ S 177において、現在のデータベースから可能な We b能力を計算し、ステップ S 178において、連携センタで不足分の We b能力を追加する。ステツプ S 178の処理は、図 28の通りである。そして、図 25あるいは図 26の処理に戻る。

ステップ S 1 71の判断が YE Sの場合には、ステップ S 1 72において、センタ内の追加サーバを選択する。そして、ステップ S 1 73において、追加処理能力量が充足されたか否かを判断する。ステップ S 1 73の判断が NOの場合には、ステップ S 1 77に進む。ステップ S 1 73の判断が YESの場合には、ステップ S 1 74において、選択されたサーバを含むよう VLANを設定し、ステップ S 1 75において、選択されたサーバにデータベースを設定し、ステップ S 1 76において、センタ内の We bサーバのデータベースリストを更新し、図 25あるいは図 26の処理に戻る。

図 30は、 We bサーバ及びデータベースに共通の追加サーバの選択処理の詳細を示すフローである。

ステップ S 180において、必要な用途向けサーバがあるか否かを判断する。ステップ S 1 80の判断が YE Sの場合、ステップ S 1 81において、必要な用途向けサーバ内に 1台で追加処理能力量を充足可能なサーバがあるか否かを判断する。ステップ S 1 8 1の判断が NOの場合には、ステップ S 182において、必要な用途向けであって、最大性能のサーバを選択し、ステップ S 1 8 0に戻る。ステップ S 1 81の判断が YE Sの場合には、ステップ S 1 83において、 1台で追加処理能力量を充足可能なサーバの中で最低性能のサーバを選択し、ステップ S 1 8 8に進む。

ステップ S 1 8 0の判断が N〇の場合には、ステップ S 1 8 4において、利用可能なサーバがあるか否かを判断する。ステップ S 1 8 4の判断が Y E Sの場合には、ステップ S 1 8 5において、 1台で追加処理能力量を充足可能なサーバがあるか否かを判断する。ステップ S 1 8 5の判断が N Oの場合には、ステツプ S 1 8 6において、使用できる最大性能のサーバを選択してステップ S 1 8 4に進む。ステップ S 1 8 5の判断が Y E Sの場合には、ステップ S 1 8 7において、 1台で追加処理能力量を充足可能なサーバの内、最低性能のサーバを選択してステップ S 1 8 8に進む。ステップ S 1 8 4の判断が N〇の場合には、そのままステップ S 1 8 8に進む。

ステップ S 1 8 8では、割り当てられたサーバ一覧を構成し、図 2 8あるいは図 2 9の処理に戻る。産業上の利用可能性

本発明により、サービス毎、データセンタ毎に充分な予備サーバを確保して置かなくても必要となった時に動的に割り当てることでサービス品質が達成できるようになる。また、小規模なデータセンタであっても、他のデータセンタと連携することで急激な負荷集中時にもサービス品質を保証することが可能になる。更に予備サーバの共用により設備投資を軽減でき、同時に設備の有効利用が可能となる。

Claims

請求の範囲

1 . クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置の負荷分散の方法であって、

通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサ一ビスの設定もされていない複数の予備サーバを設けるステップと、通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアプリケーションを設定して、該サービスの提供用サーバとし、通常サービスを提供するサーバと負荷を分担させる制御ステップと、

を備えることを特徴とする方法。

2 . 複数の前記装置がネットワークを介して接続され、 1つの装置が負荷を支えきれなくなった場合に、他の装置の有する、必要とされるサービスを通常提供するのに使用されるサーバを、該 1つの装置のために提供することを特徴とする請求項 1に記載の方法。

3 . 前記他の装置は、予備サーバを有し、前記 1つの装置のために提供したサーバが負荷を支えきれなくなった場合に、該予備サーバを提供することを特徴とする請求項 2に記載の方法。

4 . 前記複数の装置間で負荷を分担する場合には、該複数の装置間の通信帯域の確保を行うことを特徴とする請求項 2に記載の方法。

5 . 前記制御ステップでは、過去のサーバのリクエストの処理数から所定時間後の負荷の大きさを予測することによって、予備サーバをサービスの提供に使用するか否かを決定することを特徴とする請求項 1に記載の方法。

6 . 特定のサービスに予備サーバを使用する場合、予備サーバのハードウェアの特性に基づいて、該特定のサービスの提供に適した予備サーバから使用することを特徴とする請求項 1に記載の方法。

7 . 特定のサービスに予備サーバを使用する場合、補充すべき処理能力を 1台で補充することの出来る予備サーバから優先して使用することを特徴とする請求項 1に記載の方法。

8 . 1台で補充すべき処理能力を補充可能な予備サーバの内、最低性能の予備サーバから優先して使用することを特徴とする請求項 7に記載の方法。

9 . 特定のサービスに呼ぴサーバを使用する場合、補充すべき処理能力を 1台で補充することの出来る予備サーバがない場合には、最大性能の予備サーバを使用することを特徴とする請求項 1に記載の方法。

1 0 . 前記制御ステップは、負荷が予備サーバなしでも支えることが出来るほど少なくなった場合には、負荷の減ったサービスの提供に使用していた予備サーバから、該サービスの提供のためのアプリケーションを削除し、予備サーバの使用を停止することを特徴とする請求項 1に記載の方法。

1 1 . 予備サーバの使用を中止する場合には、予備サーバのハードウェアの特性を考慮して、使用を中止することを特徴とする請求項 1 0に記載の方法。

1 2 . 予備サーバの使用を中止する場合には、残りのサーバ及び予備サーバで特定サービスの負荷を支え続けられる範囲内で、最大性能の予備サーバの使用を中止することを特徴とする請求項 1 0に記載の方法。

1 3 . クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置であって、

通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサービスの設定もされていない複数の予備サーバと、

通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアプリケーションを設定して、該サービスの提供用サーバとし、通常サ一ビスを提供するサーバと負荷を分担させる制御手段と、を備えることを特徴とする装置。

1 4 . クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置の負荷分散の方法であって、

通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサービスの設定もされていなレ、複数の予備サーバを設けるステップと、通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアプリケーションを設定して、該サービスの提供用サーバとし、通常サービスを提供するサーバと負荷を分担させる制御ステップと、

を備えることを特徴とする方法をコンピュータに実現させるプログラム。