(57)【要約】ネットワーク１１を介してクライアント１０から直接リクエストを受信する前段センタ１２−１と、前段センタ１２−１を介してクライアント１０からのリクエストを受信する後段センタ１２−２からなるシステムにおいて、各センタが予備サーバ１７−１、１７−２を有する。まず、前段センタ１２−１が通常のサーバを使ってサービスを提供する。サーバの負荷が大きくなったことを検出したシステム制御装置１６−１は、サービス１とサービス２に共通に設けられた予備サーバ１７−１から負荷が大きくなったサービスの提供用にサーバを提供する。それでも負荷が支えきれないときは、システム制御装置１６−１が後段センタ１２−２のシステム制御装置１６−２にサービスの提供をになうよう指示を出す。後段センタ１２−２も、負荷が通常サーバで支えきれなくなったら、予備サーバ１７−２を使って、負荷を支える。
2004084085.tif 000002
【特許請求の範囲】
【請求項１】
クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置の負荷分散の方法であって、
通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサービスの設定もされていない複数の予備サーバを設けるステップと、
通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアプリケーションを設定して、該サービスの提供用サーバとし、通常サービスを提供するサーバと負荷を分担させる制御ステップと、
を備えることを特徴とする方法。
【請求項２】
複数の前記装置がネットワークを介して接続され、１つの装置が負荷を支えきれなくなった場合に、他の装置の有する、必要とされるサービスを通常提供するのに使用されるサーバを、該１つの装置のために提供することを特徴とする請求項１に記載の方法。
【請求項３】
前記他の装置は、予備サーバを有し、前記１つの装置のために提供したサーバが負荷を支えきれなくなった場合に、該予備サーバを提供することを特徴とする請求項２に記載の方法。
【請求項４】
前記複数の装置間で負荷を分担する場合には、該複数の装置間の通信帯域の確保を行うことを特徴とする請求項２に記載の方法。
【請求項５】
前記制御ステップでは、過去のサーバのリクエストの処理数から所定時間後の負荷の大きさを予測することによって、予備サーバをサービスの提供に使用するか否かを決定することを特徴とする請求項１に記載の方法。
【請求項６】
特定のサービスに予備サーバを使用する場合、予備サーバのハードウェアの特性に基づいて、該特定のサービスの提供に適した予備サーバから使用することを特徴とする請求項１に記載の方法。
【請求項７】
特定のサービスに予備サーバを使用する場合、補充すべき処理能力を１台で補充することの出来る予備サーバから優先して使用することを特徴とする請求項１に記載の方法。
【請求項８】
１台で補充すべき処理能力を補充可能な予備サーバの内、最低性能の予備サーバから優先して使用することを特徴とする請求項７に記載の方法。
【請求項９】
特定のサービスに呼びサーバを使用する場合、補充すべき処理能力を１台で補充することの出来る予備サーバがない場合には、最大性能の予備サーバを使用することを特徴とする請求項１に記載の方法。
【請求項１０】
前記制御ステップは、負荷が予備サーバなしでも支えることが出来るほど少なくなった場合には、負荷の減ったサービスの提供に使用していた予備サーバから、該サービスの提供のためのアプリケーションを削除し、予備サーバの使用を停止することを特徴とする請求項１に記載の方法。
【請求項１１】
予備サーバの使用を中止する場合には、予備サーバのハードウェアの特性を考慮して、使用を中止することを特徴とする請求項１０に記載の方法。
【請求項１２】
予備サーバの使用を中止する場合には、残りのサーバ及び予備サーバで特定サービスの負荷を支え続けられる範囲内で、最大性能の予備サーバの使用を中止することを特徴とする請求項１０に記載の方法。
【請求項１３】
クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置であって、
通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサービスの設定もされていない複数の予備サーバと、
通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアプリケーションを設定して、該サービスの提供用サーバとし、通常サービスを提供するサーバと負荷を分担させる制御手段と、を備えることを特徴とする装置。
【請求項１４】
クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置の負荷分散の方法であって、
通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサービスの設定もされていない複数の予備サーバを設けるステップと、
通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアプリケーションを設定して、該サービスの提供用サーバとし、通常サービスを提供するサーバと負荷を分担させる制御ステップと、
を備えることを特徴とする方法をコンピュータに実現させるプログラム。
【発明の詳細な説明】
【技術分野】  本発明は、サイト間連携による負荷分散システムに関する。
【背景技術】  インターネットの爆発的な普及によってサービス提供側で必要となるサーバ、ネットワーク等のリソースは膨大なものとなってきている。しかし、ユーザからの要求の量は時間や条件によって大きく変動することが分かっており、集中時にあわせてリソースを確保しておけば通常時には無駄なリソースの維持が必要となり、かといって集中時には対応できないリソースでは、サービス品質の低下を招きユーザに不快感を与えることとなる。更にユーザ数の増加に伴い必要なリソースの上限を見積もることは困難になっており、リソースを必要に応じて割り当てるシステムが必要となってくる。同時に過剰なリソースは管理コストの増大を招くため、必要でないリソースを有効に利用するための仕組みも必要とされている。
図１は、従来の負荷分散システムの一例である。
図１の構成では、クライアント１０がネットワーク１１を介してデータセンタ１２にアクセスし、サービスを受ける。負荷分散装置１３には、複数のサーバ１４が接続されている。
１台のサーバでは処理しきれない場合、図１のようにサーバを複数台設置し、その前段に負荷分散装置１３を配置することで負荷を複数のサーバに分散し、サービス品質を向上させるが、サーバ１４の追加判定やサーバ１４・負荷分散装置１３の追加、設定変更の作業は人手で行われることが多く、また最大負荷に合わせたサーバを常時確保する必要があるため大きなコストがかかる。
特許文献１では、サーバの追加及びユーザからのリクエストの振り分け方法を定義しているが、ユーザ側にサーバ選択のための機構を組み込む必要があり、不特定多数向けのサービスへの適用には適していない。また、リクエスト以外の管理情報のやりとりが必要になるという問題がある。
また、特許文献２の方式は、静的な情報を配信する場合にしか適用できず、サービス提供等ユーザからの要求によって毎回異なる情報を返す場合には適用できない。
更に、特許文献３についても静的情報の場合を想定しており、ファイルサーバ等への負荷が過剰になった場合については考慮されていない。
【特許文献１】特開平９−１０６３８１号公報
【特許文献２】特開平９−１７９８２０号公報
【特許文献３】特開２００２−２５９３５４号公報
【発明の開示】
本発明の目的は、サービス提供のための負荷を分散し、ユーザからの要求の変化に柔軟に対応できる負荷分散システムを提供することである。
本発明の方法は、クライアントにネットワーク経由でサービスを提供する複数のサーバを備えた装置の負荷分散の方法であって、通常サービスを提供するサーバの負荷を分担するための、初期状態ではいずれのサービスの設定もされていない複数の予備サーバを設けるステップと、通常サービスを提供するサーバの負荷の増大を見込んで、該予備サーバに提供すべきサービスのためのアプリケーションを設定して、該サービスの提供用サーバとし、通常サービスを提供するサーバと負荷を分担させる制御ステップとを備えることを特徴とする。
本発明によれば、データセンタなどの装置内に、通常サービスを提供するサーバの他に、予備サーバを複数設け、通常サービスを提供するサーバの負荷が大きくなった場合には、予備サーバに、そのサービスを提供可能なようにアプリケーションをインストールして、当該サーバの当該サービスを提供するための負荷を分担させる。
また、別の形態では、本発明に従って、予備サーバを備えた装置をネットワークで接続し、互いに、予備サーバを提供し合うように制御することにより、１つのデータセンタでは、一時的な負荷を支える程の処理能力を得られなくても、複数の装置がネットワークを介して協同して負荷に対処することにより、大きな負荷によってサービス提供の中断を避けることが出来る。また、これにより、１つの装置に備える予備サーバの数を減らすことが出来、ハードウェアを冗長に、各装置に持たせる必要が無くなる。
【図面の簡単な説明】  図１は、従来の負荷分散システムの一例である。
図２は、本発明の実施形態の基本構成を示す図である。
図３は、図２の基本構成におけるセンタ内のネットワーク配置構成を示す図である。
図４は、本発明の第１の実施形態を示す図である。
図５は、本発明の第１の実施形態の動作を示す図である。
図６は、サーバの負荷と容量を算出するためのデータを示す図である。
図７は、負荷の大きさに応じてサーバの選択をするためのデータを示す図である。
図８は、追加するサーバの能力と負荷の予測値との関係を示した図である。
図９は、複数のサービスで予備サーバを共用する構成を示した図である。
図１０は、異なるセンタ間で予備サーバの提供を行う場合の構成を示す図である。
図１１は、本発明の実施形態の動作を説明する図である。
図１２は、他センタとの連携を図る場合におけるネットワーク帯域の確保に関する説明をする図である。
図１３は、ウェブサーバにおける本発明の実施形態の適用例を示す図である。
図１４は、ウェブサービスにおける本発明の実施形態の適用例を示す図である。
図１５は、対等なセンタ間が相互にリソースを融通し合う場合の本発明の実施形態の適用例である。
図１６は、予備サーバを持たない前段センタの場合に本発明の実施形態を適用した例を示す図である。
図１７〜図２４は、センタに設けられるデータベース間の連携のない場合の本発明の実施形態の動作を説明するフローチャートである。
図２５〜図３０は、データベースの連携がある場合の本発明の実施形態の処理の流れを示すフローチャートである。
【発明を実施するための最良の形態】  本発明では、ユーザからの要求量の変化を予測し、それに合わせてデータセンタ内、もしくは、連携する別データセンタ内のサーバを動的に追加、削除することでサービス品質を保証し、同時に余剰サーバを複数のサービスで共用することでコスト削減を目指すものである。
図２は、本発明の実施形態の基本構成を示す図である。
クライアント１０は、ネットワーク１１を介して、前段センタ１２−１の負荷分散装置１３−１経由で、Ｗｅｂサーバ１５−１にアクセスする。Ｗｅｂサーバ１５−１でのデータ処理の結果、クライアント１０は、データベースサーバ１４−１あるいは、ファイルサーバ１４−２にアクセスして、サービスを受ける。後段サーバ１２−２は、前段センタ１２−１とほぼ同様の構成をしており、負荷分散装置１３−１経由でクライアント１０からの要求を受け付け、負荷分散装置１３−２で負荷分散を行いながら、Ｗｅｂサーバ１５−２にクライアント１０を導く。そして、クライアント１０は、Ｗｅｂサーバ１５−２を介して、データベースサーバ１４−３あるいは１４−４にアクセスし、サービスを受ける。
ここで前段センタ１２−１とは、ユーザの要求を直接受け取るセンタを指し、後段センタ１２−２とは前段センタ１２−１を通してユーザ要求を処理するセンタを示している。データセンタ間でのサーバの割当ては多対多の関係であり、あるデータセンタが複数のデータセンタのサーバを利用する場合や複数のデータセンタからのサーバ要求に同時に、あるデータセンタが応じる場合もある。サーバの負荷状態やクライアントからの負荷状態はシステム制御装置１６−１、１６−２が集計・判定・適用を行い、結果をサーバ１４−１〜１４−４や負荷分散装置１３−１、１３−２に設定する。サーバリソースが不足した場合には予備サーバ内のサーバ１７−１、１７−２を必要な機能のサーバとして設定した上で、サービスに追加し、能力を向上させる。
図３は、図２の基本構成におけるセンタ内のネットワーク配置構成を示す図である。
物理的なネットワーク構成は単一のスイッチ群２０の直下に全てのサーバを接続し、その上に論理的に独立したネットワーク（ＶＬＡＮ０、ＶＬＡＮ１１、ＶＬＡＮ１２、ＶＬＡＮ２１）を複数構成する。このような配置にすることで必要な位置へのサーバ追加処理を自動化することが可能となる。
サーバの追加、削除を行う場合には、ＣＰＵ性能やネットワーク構成等のサーバ仕様からサーバ能力を導きだし、様々な種類のハードが混在する環境であっても必要なサーバの算出を行い、適切にサーバの割当てを行う。同時にそのサーバに対してかかるトラフィックを計算し、ネットワーク帯域の確保もしくは調停を行う。
また、負荷計測及び負荷変動予測から将来の負荷を予想することで過剰負荷となる前にサーバの追加を行い、サービス品質の保証を実現する。
図４は、本発明の第１の実施形態を示す図である。
同図において、図２と同様な構成要素には同様の参照符号を付して詳細な説明を省略する。
ユーザからのリクエストが割当てたサーバの能力を超えた場合、応答時間の増大や無応答が発生し、ユーザに対し不快感を与えることになる。その状態で更に負荷が増大した場合には、サーバ障害が引き起こされる場合もある。これを防ぐために、サーバの負荷状態の計測をシステム制御装置１６が行い、現在のサーバ数では問題を起こすと判断した場合には、予備サーバ１７からサーバの追加を行い、アプリケーションやサービス、利用するデータ等の設定及び導入を行う。そして、依存関係にある機器及びサーバ等の設定を更新することでサービスに組み込む。
図５は、本発明の第１の実施形態の動作を示す図である。
同図において、図４と同じ構成要素には同じ参照符号を付して説明を省略する。
ユーザからのリクエスト量が減少した場合には、余剰サーバが発生する。この余剰サーバ分については削除したとしてもサービス品質は低下せず、むしろ運用コストや利用率の向上という面からは予備サーバとして開放し、他のサービスで利用することが望ましい。このため依存関係にある機器から関係する設定を削除することでサービスとの連携を解消し、その後設定の解除等の処理を行い、予備サーバ１７に戻す。
図６は、サーバの負荷と容量を算出するためのデータを示す図である。
サービス能力を必要に応じて追加・削除するためには、あるサーバがどれだけのサービス能力を提供するかといった情報が必要となる。データセンタ等においては、利用するサーバや機器、そしてアプリケーションやサービスの組み合わせによって１ユニットあたりのサービス能力は変化する。利用するサーバを均一なものでそろえることは、複数のデータセンタが連携する場合などにおいては現実的に不可能であり、そのためＣＰＵやメモリ等の機器仕様からサービス能力を算出する必要がある。このため、典型的な構成における性能値からＣＰＵ能力等の違いを考慮して性能値を推定する方法を利用する。
図７は、負荷の大きさに応じてサーバの選択をするためのデータを示す図である。
ここでは、サービス能力だけでなく、サーバユニットの特性としてどのような用途に利用するかが好ましいかという情報を保持する。上記のように利用できるサーバごとの性能値は均一でないため、これらを組み合わせて必要な能力を提供できる構成を作成する必要がある。このため図６で求めた性能値と特性及び要求される性能値から、推奨度の高いサーバを優先して要求量を満たすまでサーバを選択し、利用する。
図８は、追加するサーバの能力と負荷の予測値との関係を示した図である。
計測されたリクエスト量がサービス能力を超える場合にリソースを追加するだけでは、急激に負荷が上昇しつつある場合等にサービス品質が保証出来なくなる。そのため負荷の傾向を把握し、リクエスト量の増加が見込まれる場合には予測されるリクエスト量に見合ったサービス能力を予め追加しておくことでサービス品質の低下を防ぐ。予測の仕方としては、線形外挿などを行うなどが考えられる。
図９は、複数のサービスで予備サーバを共用する構成を示した図である。
あるデータセンタ内の複数のサービスの負荷状態を見た場合、全てのサービスが同時に高負荷となることは極めて希であり、サービス毎に予備リソースを確保したのでは利用されないリソースが常時存在すると考えられる。予備リソースを複数のサービスで共用することで、全体としてより少ない予備リソースで必要なサービス能力の追加が可能となる。また、共用することで維持コストを分散させることが出来る。センタ１２には、サービス１とサービス２が搭載されており、それぞれに負荷分散装置１３−１、１３−２が設けられる。サービス１には、Ｗｅｂサーバ１５−１、データベースサーバ１４−１、ファイルサーバ１４−２が設けられる。サービス２には、サーバ２５が設けられる。予備サーバ１７は、サービス１とサービス２に共通に設けられており、システム制御装置１６が負荷の状況を見て、予備サーバ１７から、サービス１あるいはサービス２に、追加サーバを導入する。
図１０は、異なるセンタ間で予備サーバの提供を行う場合の構成を示す図である。
同図において、図２と同様な構成要素には同じ参照符号を付し、説明を省略する。
データセンタ１２−１の規模によっては、たとえ予備サーバを異なるサービス間で共用したとしても物理的もしくはコスト的に充分な予備サーバ１７−１を確保できないケースがある。また十分に確保しておいたつもりであっても突発的な負荷によってデータセンタ内の予備サーバではまかないきれない場合が起こり得る。このような場合に、ネットワークで接続されている別のデータセンタ１２−２を後段センタとし、その予備サーバ１７−２をネットワーク経由で利用する。
図１１は、本発明の実施形態の動作を説明する図である。
同図においては、図９と同じ構成要素には同じ参照符号を付して、説明を省略する。
サービスによっては直接ユーザと情報を交換するサーバ以外にもデータベース等連携して動作するサーバが必要なものがある。このようなサービスの場合、それぞれの機能毎に処理能力や負荷状態の確認を行い適切な機能にサーバを追加しなければ性能の向上が望めない。そのためシステム制御装置１６は、各階層毎に負荷の確認を行い、追加・削除時には連携しているサーバの設定を変更することで能力の増減を図る。
図１２は、他センタとの連携を図る場合におけるネットワーク帯域の確保に関する説明をする図である。
なお、同図において、図１０と同じ構成要素には同じ参照符号を付している。
複数のサービスが同時に動作する場合や連携処理が必要な場合には、サーバを追加するだけでなく各サービスや機能間のトラフィックを調停しなければ充分な処理能力が得られない。それぞれの部分で必要となる帯域を計算し、それらの割合を考慮した上でネットワークに対して各帯域の確保を行うことで全体として充分な性能を出せる様にする。
上記の構成により、ユーザからの負荷とサーバ能力の状態を監視し、負荷がサーバ能力を超える前に必要充分なリソースを、データセンタ内、もしくは連携するデータセンタから割り当てることが出来るようになり、ユーザからのリクエストに対するサービス品質の保証が可能となる。同時に必要となる予備サーバを広範囲で共用することが可能になるため、全体として必要なサーバの総量を減らすことができる。また、複数の機能を持つサーバが連携し合うサービスであっても、ボトルネックとなっている機能に対してサーバの追加を行うことができるため、充分な大規模化が可能になる。更に全体の処理を自動化可能なため、ユーザからの要求量の変化に素早く追従可能である。
図１３は、ウェブサーバにおける本発明の実施形態の適用例を示す図である。
同図において、図１２と同じ構成要素には同じ参照符号を付して説明を省略する。
負荷が軽い状態では、前段センタ１２−１のみで運用される。負荷が増加した場合は、前段センタ１２−１内の予備サーバ１７−１をウェブサーバ１５−１として追加する。更に負荷が増大してくると後段センタ１２−２にウェブサーバ群１５−２を作成し、後段センタ１２−２でも負荷を受け持つようにする。
図１４は、ウェブサービスにおける本発明の実施形態の適用例を示す図である。
同図において、図１２と同じ構成要素には、同じ参照符号を付して説明を省略する。
この例では、ウェブサービスがウェブサーバ１５−１とデータベースサーバ１４−１、ファイルサーバ１４−２の組み合わせで構成されている。負荷が軽い状態では、前段センタ１２−１のみで運用される。負荷の増大に伴い、ボトルネックとなった部分に順次予備サーバ１７−１の追加を行っていき、前段センタ１２−１でまかない切れなくなった場合には後段センタ１２−２との連携を行う。この例のデータベースサーバ１４−１は、前段センタ１２−１と後段センタ１２−２の間で連携中もデータの同期を行う。これはセンタ間をまたぐＶＬＡＮの作成及び帯域確保を行うことで実現する。
図１５は、対等なセンタ間が相互にリソースを融通し合う場合の本発明の実施形態の適用例である。
センタ１内のサービス１の処理能力がセンタ１内の予備サーバ３０−１でまかなえなくなった場合、センタ２に対して連携を依頼しセンタ２内のサーバ（網掛け部分及び予備サーバ３０−３）を利用する。更にセンタ２内のサーバ容量も枯渇した場合（予備サーバ３０−２を含めた容量が枯渇した場合）は別のセンタ３に対して連携を依頼しセンタ３内のサーバ（網掛け部分及び予備サーバ３０−３）を利用する。
図１６は、予備サーバを持たない前段センタの場合に本発明の実施形態を適用した例を示す図である。
前段センタ１２−１において、サービス提供に対してサーバが不足したとシステム制御部１６−１が判断した場合には、後段センタ１２−２に連携を依頼し、後段センタ１２−２内のサーバを利用する。ここでは、負荷分散装置、及びＷｅｂサーバをサービス１とサービス２に対して提供する。サービス１’とサービス２’のサーバは、それぞれサービス１及びサービス２のサービスを行う。更に、後段センタ１２−２では、サーバの容量が足りなくなった場合には、予備サーバ１７をそれぞれのサービスに必要なだけ追加する。追加の判断や、前段センタ１２−１との連携は、システム制御部１６−２が行う。
図１７〜図２４は、センタに設けられるデータベース間の連携のない場合の本発明の実施形態の動作を説明するフローチャートである。
図１７は、システム制御装置の全体の流れを示すフローチャートである。
まず、ステップＳ１０において、負荷計測を行う。ステップＳ１１において、予測処理能力が割当て済み処理能力を超えているか否かを判断する。ステップＳ１１の判断がＹＥＳの場合には、ステップＳ１２において、処理能力の追加を行いステップＳ１５に進む。ステップＳ１５では、１０秒待つとなっているが、この数値は設計者が適宜設定すべきものである。
ステップＳ１１における判断がＮＯの場合には、ステップＳ１３において、現在処理能力が割当て済み処理能力の２分の１以下であるか否かを判断する。ステップＳ１３の判断がＹＥＳの場合には、ステップＳ１４において、処理能力の削減を行い、ステップＳ１５に進む。ステップＳ１３の判断がＮＯの場合には、ステップＳ１５に進む。
ステップＳ１５の後は、再びステップＳ１０に戻る。
図１８は、図１７のステップＳ１０の負荷計測の詳細を示す図である。
ステップＳ２０において、使用サーバから１０秒間の平均の処理数を収集する。この１０秒というのは、図１７のステップＳ１５の値と一致するべきものである。ステップＳ２１において、総平均処理数を計算し、計測履歴に追加する。ステップＳ２２において、計測履歴が４項以上あるか否かを判断する。ステップＳ２２の判断がＮＯの場合には、ステップＳ２３において、最新履歴を３０秒後の予測値として、ステップＳ２５に進む。ステップＳ２２における判断がＹＥＳの場合には、ステップＳ２４において、最新４履歴から最小２乗近似で３０秒後の予測値を算出し、ステップＳ２５に進む。これは、最新の４履歴から、回帰曲線を求め、回帰曲線を使って、３０秒後の予測値を得ることである。ステップＳ２５においては、３０秒後の予測値を設定し、ステップＳ２６において、最新履歴を現在値に設定して図１７のフローに戻る。
図１９は、図１７のステップＳ１２の処理能力追加処理の詳細を示す図である。
ステップＳ３０において、予測値から現在割当て値を引いて追加処理能力量を決定する。ステップＳ３１において、センタ内に予備サーバがあるか否かを判断する。ステップＳ３１の判断がＹＥＳの場合には、ステップＳ３２において、センタ内の追加サーバを選択する。ステップＳ３３では、追加処理能力量が充足されたか否かを判断する。ステップＳ３３の判断がＮＯの場合には、ステップＳ３４へ、判断がＹＥＳの場合には、ステップＳ３８に進む。ステップＳ３１の判断がＮＯの場合には、ステップＳ３４に進む。
ステップＳ３４においては、予備処理能力を持つ連携先センタがあるか否かを判断する。ステップＳ３４の判断がＹＥＳの場合には、ステップＳ３６において、連携センタで処理能力を割当てる。ステップＳ３７においては、追加処理能力量が充足されたか否かを判断する。ステップＳ３７の判断がＮＯの場合には、ステップＳ３４に進む。ステップＳ３７の判断がＹＥＳの場合には、ステップＳ３８に進む。ステップＳ３４の判断がＮＯの場合には、ステップＳ３５において、追加処理能力量の充足不能を管理者に警告して、ステップＳ３８に進む。ステップＳ３８では、選択されたサーバを含むようＶＬＡＮを設定し、ステップＳ３９において、選択されたサーバにアプリケーションを設定し、ステップＳ４０に進む。
ステップＳ４０においては、センタ間の連携があるか否かを判断し、判断がＮＯの場合には、ステップＳ４３に進む。ステップＳ４０の判断がＹＥＳの場合には、ステップＳ４１において、連携センタ負荷分散比率の決定、及び割当て装置の設定を行い、ステップＳ４２において、自センタと連携センタとの間の通信帯域を設定し、ステップＳ４３に進む。ステップＳ４３においては、自センタの負荷分散比率を決定し、割当て装置を決定して、図１７のフローに戻る。
図２０は、図１９のステップＳ３２の追加サーバの選択処理を詳細に示すフローである。
ステップＳ５０において、必要な用途向けのサーバがあるか否かが判断される。ステップＳ５０の判断がＮＯの場合には、ステップＳ５４に進む。ステップＳ５０の判断がＹＥＳの場合には、ステップＳ５１において、必要な用途向けサーバ内で、１台で追加処理能力量を充足可能なサーバがあるか否かを判断する。ステップＳ５１の判断がＮＯの場合には、ステップＳ５２において、必要な用途向けで最大性能のサーバを選択し、ステップＳ５０に戻る。ステップＳ５１の判断がＹＥＳの場合には、必要な用途向けサーバの内、１台で追加処理能力量をまかなえるサーバの内、最低性能のサーバを選択し、ステップＳ５８に進む。
ステップＳ５４においては、利用可能なサーバがあるか否かを判断する。ステップＳ５４の判断がＮＯの場合には、ステップＳ５８に進む。ステップＳ５４の判断がＹＥＳの場合には、ステップＳ５５において、１台で追加処理能力量を充足可能なサーバあるか否かを判断する。ステップＳ５５の判断がＮＯの場合には、ステップＳ５６において、最大性能のサーバを選択し、ステップＳ５４に戻る。ステップＳ５５の判断がＹＥＳの場合には、ステップＳ５７において、１台で追加処理能力量を充足可能なサーバの内、最低の性能のサーバを選択し、ステップＳ５８に進む。ステップＳ５８においては、割り当てられたサーバ一覧を構成して、図１９の処理に戻る。
図２１は、図１９のステップＳ３６の連携センタ処理能力割当て処理の流れを示すフローである。
ステップＳ６０において、帯域による処理能力上限が割当て希望値より小さいか否かを判断する。ステップＳ６０の判断がＮＯの場合には、ステップＳ６２に進む。ステップＳ６０の判断がＹＥＳの場合には、ステップＳ６１において、割当量上限を帯域上限とし、ステップＳ６２に進む。
ステップＳ６２においては、連携先センタにサーバ選択を依頼し、ステップＳ６３において、連携先センタ内で追加サーバを選択し、ステップＳ６４において、割り当てられたサーバ一覧を構成して、図１９の処理に戻る。
図２２は、図１９のステップＳ３９のアプリケーション設定の詳細フローである。
ステップＳ７０において、センタ間の連携があるか否かを判断する。ステップＳ７０の判断がＮＯの場合には、ステップＳ７４に進む。ステップＳ７０の判断がＹＥＳの場合には、ステップＳ７１において、アプリケーションのアーカイブを転送済みか否かを判断する。ステップＳ７１の判断がＹＥＳの場合には、ステップＳ７３に進む。ステップＳ７１の判断がＮＯの場合には、ステップＳ７２において、連携先センタにアプリケーションのアーカイブを転送し、ステップＳ７３に進む。ステップＳ７３においては、追加サーバにアプリケーションをインストールし、ステップＳ７４に進む。ステップＳ７４では、自センタ内追加サーバにアプリケーションをインストールし、図１９の処理に戻る。
図２３は、図１７のステップＳ１４の処理能力の削減処理を示すフローである。
ステップＳ８０において、割当て値から現在の計測値を引き算し、削減処理能力量を決定する。ステップＳ８１において、連携センタがあるか否かを判断する。ステップＳ８１の判断がＹＥＳの場合には、ステップＳ８２において、連携センタで削減サーバを決定し、ステップＳ８３において、連携センタの全サーバが削減されたか否かを判断する。ステップＳ８３の判断がＹＥＳの場合には、ステップＳ８１に戻る。ステップＳ８３の判断がＮＯの場合には、ステップＳ８５に進む。ステップＳ８１の判断がＮＯの場合には、ステップＳ８４において、自センタで削減サーバを決定し、ステップＳ８５に進む。
ステップＳ８５においては、自センタの負荷分散比率の決定、および割当て装置を設定する。ステップＳ８６においては、連携センタの負荷分散比率を決定し、割当て装置を設定する。そして、ステップＳ８７において、ユーザリクエスト処理の完了を待つ。ステップＳ８８において、削減サーバからアプリケーションを削除し、ステップＳ８９において、残ったサーバのみを含むようＶＬＡＮを設定し（連携用ネットワーク通信路を設定し）、ステップＳ９０において、連携の解除があるか否かを判断する。ステップＳ９０の判断がＹＥＳの場合には、ステップＳ９１において、自センタと連携センタの帯域を解除して図１７の処理に戻る。ステップＳ９０の判断がＮＯの時も、図１７の処理に戻る。
図２４は、図２３のステップＳ８２あるいは、ステップＳ８４の削減サーバの選択処理を示すフローである。
ステップＳ１００において、他用途に利用可能なサーバがあるか否かを判断する。ステップＳ１００の判断がＮＯの場合、ステップＳ１０３に進む。ステップＳ１００の判断がＹＥＳの場合、ステップＳ１０１において、残り削減性能よりも性能が低いサーバがあるか否かを判断する。ステップＳ１０１の判断がＮＯの場合には、ステップＳ１０３に進む。ステップＳ１０１の判断がＹＥＳの場合には、ステップＳ１０２において、残り削減性能よりも性能が低いサーバの内、最大性能のサーバを削減してステップＳ１００に進む。
ステップＳ１０３では、現在利用中のサーバがあるか否かを判断する。ステップＳ１０３の判断がＮＯの場合には、ステップＳ１０６に進む。ステップＳ１０３の判断がＹＥＳの場合には、ステップＳ１０４において、残り削減性能よりも性能が低いサーバがあるか否かを判断する。ステップＳ１０４の判断がＮＯの場合には、ステップＳ１０６に進む。ステップＳ１０４の判断がＹＥＳの場合には、ステップＳ１０５において、残り削減性能よりも性能が低いサーバの内、最大性能のサーバを削減して、ステップＳ１０３に戻る。
ステップＳ１０６では、削除されたサーバ一覧を生成し、図２３の処理に戻る。
図２５〜図３０は、データベースの連携がある場合の本発明の実施形態の処理の流れを示すフローチャートである。
図２５は、連携依頼を行う自センタの全体の処理の流れを示すフローである。
ステップＳ１１０において、Ｗｅｂサーバの負荷計測を行う。ステップＳ１１１において、予測処理能力が割当て済み処理能力より大きいか否かを判断する。ステップＳ１１１の判断がＹＥＳの場合には、ステップＳ１１２において、Ｗｅｂ処理能力の追加を行い、ステップＳ１１５に進む。ステップＳ１１１の判断がＮＯの場合には、ステップＳ１１３において、現在処理能力が割当て済み処理能力の２分の１より小さいか否かを判断する。ステップＳ１１３の判断がＮＯの場合には、ステップＳ１１５に進む。ステップＳ１１３の判断がＹＥＳの場合には、ステップＳ１１４において、Ｗｅｂ処理の能力を削減して、ステップＳ１１５に進む。ステップＳ１１５においては、センタ内データベースの負荷を計測する。ステップＳ１１６においては、予測処理能力が割当て済み処理能力より大きいか否かを判断する。ステップＳ１１６の判断がＹＥＳの場合には、ステップＳ１１７において、データベース処理能力の追加を行い、ステップＳ１２０に進む。ステップＳ１１６の判断がＮＯの場合には、ステップＳ１１８において、現在処理能力が割当て済み処理能力の２分の１より小さいか否かを判断する。ステップＳ１１８の判断がＮＯの場合には、ステップＳ１２０に進む。ステップＳ１１８の判断がＹＥＳの場合には、ステップＳ１１９において、データベースの処理能力の削減を行い、ステップＳ１２０に進む。ステップＳ１２０では、１０秒待つ。この待ち時間は、設計者により適宜設定されるべきものである。ステップＳ１２０の後は、再び、ステップＳ１１０に戻る。
図２６は、連携先センタの全体処理の流れを示すフローである。
ステップＳ１３０において、センタ内のデータベース負荷を計測する。ステップＳ１３１において、予測処理能力が割当て済み処理能力より大きいか否かを判断する。ステップＳ１３１の判断がＹＥＳの場合には、ステップＳ１３２において、データベース処理能力を追加し、ステップＳ１３５に進む。ステップＳ１３１の判断がＮＯの場合には、ステップＳ１３３において、現在処理能力が割当て済み処理能力の２分の１より小さいか否かを判断する。ステップＳ１３３の判断がＮＯの場合には、ステップＳ１３５に進む。ステップＳ１３３の判断がＹＥＳの場合には、ステップＳ１３４において、データベース処理能力削減を行い、ステップＳ１３５に進む。ステップＳ１３５においては、１０秒待ち、ステップＳ１３０に戻る。この１０秒間はこれに限定されるべきものではなく、設計者によって適宜設定されるべきものである。
図２７は、各センタで行われるウェブ負荷計測あるいはデータベース負荷計測の詳細処理を示すフローである。
ステップＳ１４０においては、使用サーバから１０秒間の平均の処理数を収集する。この１０秒は、図２５のステップＳ１２０、図２６のステップＳ１３５の待ち時間と同じ値であるべきである。ステップＳ１４１において、総平均処理数を計算し、計測履歴に追加する。ステップＳ１４２において、計測履歴が４項以上あるか否かを判断する。ステップＳ１４２の判断がＮＯの時には、ステップＳ１４３において、最新履歴を３０秒後の予測値として、ステップＳ１４５に進む。ステップＳ１４２の判断がＹＥＳの場合には、ステップＳ１４４において、最新４履歴から最小２乗近似で３０秒後の予測値を導出し、ステップＳ１４５に進む。この導出の仕方は、図１８で述べたとおりである。
ステップＳ１４５においては、３０秒後の予測値を設定する。ステップＳ１４６においては、最新履歴を現在値に設定して図２５、２６の処理に戻る。
図２８は、図２５のステップＳ１１２のＷｅｂ処理能力追加処理の詳細フローである。
図２８のフローは、連携センタを追加したときは、ステップＳ１５４からの処理を行う。
まず、ステップＳ１５０において、予測値から現在割り当て値を引き算し、追加処理能力量を決定する。ステップＳ１５１においては、センタ内に予備サーバがあるか否かを判断する。ステップＳ１５１の判断がＮＯの時は、ステップＳ１５４に進む。ステップＳ１５１の判断がＹＥＳの時は、ステップＳ１５２において、センタ内の追加サーバの選択を行う。この処理の詳細は、図２０に示すとおりである。そして、ステップＳ１５３において、追加処理能力量が充足されたか否かを判断する。ステップＳ１５３の判断がＮＯの時は、ステップＳ１５４に進む。ステップＳ１５３の判断がＹＥＳの時は、ステップＳ１５８に進む。
ステップＳ１５４においては、予備処理能力を持つ連携先センタがあるか否かを判断する。ステップＳ１５４の判断がＹＥＳの場合には、ステップＳ１５６において、連携センタで処理能力を割り当てを行う。この処理の詳細は、図２１に示すとおりである。ステップＳ１５７では、追加処理能力量が充足されたか否かを判断する。ステップＳ１５７の判断がＮＯの場合には、ステップＳ１５４に戻る。ステップＳ１５７の判断がＹＥＳの場合には、ステップＳ１５８に進む。ステップＳ１５４の判断がＮＯの場合には、ステップＳ１５５において、追加処理能力量の充足が不能であることを管理者に警告して、ステップＳ１５８に進む。
ステップＳ１５８においては、選択されたサーバを含むようＶＬＡＮを設定し、ステップＳ１５９において、選択されたサーバにアプリケーションを設定する。アプリケーションの設定は、図２２に示したとおりである。ステップＳ１６０では、センタ間の連携があるか否かを判断する。ステップＳ１６０の判断の結果、ＹＥＳであれば、ステップＳ１６１において、連携センタ負荷分散比率の決定及び装置設定を行い、ステップＳ１６２において、自センタと連携センタ間の通信帯域を設定し、ステップＳ１６３に進む。
ステップＳ１６０の判断がＮＯの場合には、ステップＳ１６３にそのまま進む。ステップＳ１６３では、自センタの負荷分散比率を決定し、装置設定して、図２５の処理に戻る。
図２９は、図２５のステップＳ１１７及び図２６のステップＳ１３２のデータベース処理能力追加処理の詳細なフローである。
ステップＳ１７０において、予測値から現在の割り当て値を引き算し、追加処理能力量を決定する。ステップＳ１７１において、センタ内に予備サーバがあるか否かを判断する。ステップＳ１７１の判断がＮＯの場合には、ステップＳ１７７において、現在のデータベースから可能なＷｅｂ能力を計算し、ステップＳ１７８において、連携センタで不足分のＷｅｂ能力を追加する。ステップＳ１７８の処理は、図２８の通りである。そして、図２５あるいは図２６の処理に戻る。
ステップＳ１７１の判断がＹＥＳの場合には、ステップＳ１７２において、センタ内の追加サーバを選択する。そして、ステップＳ１７３において、追加処理能力量が充足されたか否かを判断する。ステップＳ１７３の判断がＮＯの場合には、ステップＳ１７７に進む。ステップＳ１７３の判断がＹＥＳの場合には、ステップＳ１７４において、選択されたサーバを含むようＶＬＡＮを設定し、ステップＳ１７５において、選択されたサーバにデータベースを設定し、ステップＳ１７６において、センタ内のＷｅｂサーバのデータベースリストを更新し、図２５あるいは図２６の処理に戻る。
図３０は、Ｗｅｂサーバ及びデータベースに共通の追加サーバの選択処理の詳細を示すフローである。
ステップＳ１８０において、必要な用途向けサーバがあるか否かを判断する。ステップＳ１８０の判断がＹＥＳの場合、ステップＳ１８１において、必要な用途向けサーバ内に１台で追加処理能力量を充足可能なサーバがあるか否かを判断する。ステップＳ１８１の判断がＮＯの場合には、ステップＳ１８２において、必要な用途向けであって、最大性能のサーバを選択し、ステップＳ１８０に戻る。ステップＳ１８１の判断がＹＥＳの場合には、ステップＳ１８３において、１台で追加処理能力量を充足可能なサーバの中で最低性能のサーバを選択し、ステップＳ１８８に進む。
ステップＳ１８０の判断がＮＯの場合には、ステップＳ１８４において、利用可能なサーバがあるか否かを判断する。ステップＳ１８４の判断がＹＥＳの場合には、ステップＳ１８５において、１台で追加処理能力量を充足可能なサーバがあるか否かを判断する。ステップＳ１８５の判断がＮＯの場合には、ステップＳ１８６において、使用できる最大性能のサーバを選択してステップＳ１８４に進む。ステップＳ１８５の判断がＹＥＳの場合には、ステップＳ１８７において、１台で追加処理能力量を充足可能なサーバの内、最低性能のサーバを選択してステップＳ１８８に進む。ステップＳ１８４の判断がＮＯの場合には、そのままステップＳ１８８に進む。
ステップＳ１８８では、割り当てられたサーバ一覧を構成し、図２８あるいは図２９の処理に戻る。
【産業上の利用可能性】  本発明により、サービス毎、データセンタ毎に充分な予備サーバを確保して置かなくても必要となった時に動的に割り当てることでサービス品質が達成できるようになる。また、小規模なデータセンタであっても、他のデータセンタと連携することで急激な負荷集中時にもサービス品質を保証することが可能になる。更に予備サーバの共用により設備投資を軽減でき、同時に設備の有効利用が可能となる。
【図１】
2004084085.tif 000003
【図２】
2004084085.tif 000004
【図３】
2004084085.tif 000005
【図４】
2004084085.tif 000006
【図５】
2004084085.tif 000007
【図６】
2004084085.tif 000008
【図７】
2004084085.tif 000009
【図８】
2004084085.tif 000010
【図９】
2004084085.tif 000011
【図１０】
2004084085.tif 000012
【図１１】
2004084085.tif 000013
【図１２】
2004084085.tif 000014
【図１３】
2004084085.tif 000015
【図１４】
2004084085.tif 000016
【図１５】
2004084085.tif 000017
【図１６】
2004084085.tif 000018
【図１７】
2004084085.tif 000019
【図１８】
2004084085.tif 000020
【図１９】
2004084085.tif 000021
【図２０】
2004084085.tif 000022
【図２１】
2004084085.tif 000023
【図２２】
2004084085.tif 000024
【図２３】
2004084085.tif 000025
【図２４】
2004084085.tif 000026
【図２５】
2004084085.tif 000027
【図２６】
2004084085.tif 000028
【図２７】
2004084085.tif 000029
【図２８】
2004084085.tif 000030
【図２９】
2004084085.tif 000031
【図３０】
2004084085.tif 000032
【国際調査報告】
2004084085.tif 000033
2004084085.tif 000034
2004084085.tif 000035
2004084085.tif 000036