(57)【特許請求の範囲】
【請求項１】
システムを構成する複数のサーバに接続され、複数の前記サーバを監視する監視サーバを備え、
前記監視サーバが、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段と、を備える
ことを特徴とする監視制御システム。
【請求項２】
前記監視サーバが、
構成変更後の性能モデルに基づいて、前記システムの構成変更に伴う２次的なボトルネックの発生を予測するボトルネック予測手段を備える
ことを特徴とする請求項１記載の監視制御システム。
【請求項３】
前記性能モデル化手段が、
複数の前記サーバから収集した性能情報と、前記システムの負荷情報に基づいて、各サーバの性能を、負荷を変数とする相関関数にモデル化する
ことを特徴とする請求項２記載の監視制御システム。
【請求項４】
前記構成変更後性能モデル生成手段が、
前記システムの構成変更指示に応じて、追加されるサーバと同種のサーバを既存のサーバから選択し、当該既存のサーバの相関関数を、追加されるサーバの相関関数として複製する
ことを特徴とする請求項３記載の監視制御システム。
【請求項５】
前記ボトルネック予測手段が、
構成変更後の性能モデルである各サーバの相関関数に所定の負荷を代入し、その出力が所定の閾値を超えているサーバが、前記システムの構成変更に伴う２次的なボトルネックであると予測する
ことを特徴とする請求項４記載の監視制御システム。
【請求項６】
前記システムの構成変更に伴う２次的なボトルネックを予測する際、相関関数に代入する負荷が任意に指定される
ことを特徴とする請求項５記載の監視制御システム。
【請求項７】
システムを構成する複数のサーバに、複数の前記サーバを監視する監視サーバを接続し、
前記監視サーバが、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化し、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する
ことを特徴とする監視制御方法。
【請求項８】
システムを構成する複数のサーバに接続され、複数の前記サーバを監視制御するにあたり、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段と、を備える
ことを特徴とする監視制御サーバ。
【請求項９】
システムを構成する複数のサーバに接続され、複数の前記サーバを監視制御するコンピュータに、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化させ、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成させる
ことを特徴とする監視制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、スケールアウト型サーバシステムを監視制御する監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムに関する。
【背景技術】
【０００２】
企業情報システム、データセンタ、プロバイダなどの比較的大規模なシステムにおいて、スケールアウト型サーバシステムが普及している。
スケールアウト型のサーバシステムとは、サーバの数を増やす（スケールアウト）ことで、サーバ群全体のパフォーマンスを向上させるというものである。
例えば、一台のサーバが１０人のユーザしか処理できない場合に、サーバを二台に増やすことで負荷を分散し、２０人のユーザへの対応が可能となるというものである。
【０００３】
このようなスケールアウト型サーバシステムは、複数のサーバ（物理サーバ及び仮想サーバを含む。）を役割毎にグループ化し、グループ内のサーバに処理要求を均等に割り当てるので、各グループの処理量をサーバの台数で管理できるという利点がある。
そして、サーバをスケールアウトした場合にも、複数のサーバを連携して動作させることになるため、メンテナンスや障害発生時にもサービスを完全に停止させる必要がないというメリットがある。
【０００４】
このようなスケールアウト型サーバシステムの普及は、システムの構成変更（スケールアウト）を容易化するサーバプロビジョニングツールの登場も影響しており、システム管理者は、このツールを用いることにより、負荷（ワークロード）に応じたシステムの柔軟な構成変更が可能となった。
また、システムが処理できる毎秒のトランザクション件数に対して、ボトルネック箇所を検出するキャパシティプランニング技術も提供されている。このキャパシティプランニング技術によれば、システム管理者は、システムのボトルネック箇所を特定し、所望の性能に対して必要となるサーバ台数を見積もり、システムの構成変更を行うことが可能となった。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−３０９７４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、スケールアウト型サーバシステムでは、現行システムのボトルネックを特定し、そのボトルネックを解消すべく構成変更を行っても、性能が向上しない場合があった。
その理由は、構成変更に伴って許容負荷が増加すると、その影響で別の箇所に２次的にボトルネックが発生する可能性があるからである。
そして、このような２次的なボトルネックの発生は、予測が不可能であるため、実際に構成変更を行った後に、再度ボトルネックの有無を検出し、構成変更を検討する必要があった。
【０００７】
ここで、特許文献１には、ストレージシステムの構成を実際に変更する前に、ストレージシステムの各要素の状態に基づいてボトルネックの発生を検出し、このボトルネックを解消するための対策を提示するストレージシステム及びその障害解消方法が示されている。
しかしながら、この特許文献１記載のボトルネックの解消方法は、ホストコンピュータからストレージ装置までの通信経路上に存在する各要素を対象としてボトルネックの検出を行うことに特化されており、スケールアウト型サーバシステムにおいて２次的なボトルネックとなるサーバを予測することはできなかった。
【０００８】
本発明の目的は、上述した課題である２次的なボトルネックの発生を回避しつつ適切な構成変更を可能とするという課題を解決する監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するため本発明の監視制御システムは、システムを構成する複数のサーバに接続され、複数のサーバを監視する監視サーバを備え、監視サーバが、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段とを備える構成としてある。
【００１０】
また、本発明の監視制御方法は、システムを構成する複数のサーバに、複数のサーバを監視する監視サーバを接続し、監視サーバが、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化し、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する方法としてある。
【００１１】
また、本発明の監視制御サーバは、システムを構成する複数のサーバに接続され、複数のサーバを監視制御するにあたり、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段とを備える構成としてある。
【００１２】
また、本発明の監視制御プログラムは、システムを構成する複数のサーバに接続され、複数のサーバを監視制御するコンピュータに、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化させ、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成させる構成としてある。
【発明の効果】
【００１３】
本発明によれば、スケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックの発生を事前に予測して、２次的なボトルネックの発生を回避しつつ、適切な構成変更を実施することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態に係る監視制御サーバの概略構成を示す機能ブロック図である。
【図２】本発明の一実施形態に係る監視制御システムの構成を示す機能ブロック図である。
【図３】本発明の一実施形態に係る監視制御サーバの処理手順を示すフローチャートである。
【図４】本発明の一実施形態に係る監視制御サーバが収集する性能項目を示す説明図である。
【図５】本発明の一実施形態に係る監視制御システムにおいて、サーバ追加前の性能項目間に成り立つ相関関係を示すネットワーク図である。
【図６】本発明の一実施形態に係る監視制御システムにおいて、サーバ追加前の性能項目間に成り立つ相関関係を示す表図である。
【図７】本発明の一実施形態に係る監視制御システムにおいて、論理構成の変更指示を行う画面の説明図である。
【図８】本発明の一実施形態に係る監視制御システムにおいて、サーバ追加後の性能項目間に成り立つ相関関係を示すネットワーク図である。
【図９】本発明の一実施形態に係る監視制御システムにおいて、サーバ追加後の性能項目間に成り立つ相関関係を示す表図である。
【図１０】本発明の一実施形態に係る監視制御システムにおいて、サーバ追加後のサーバ毎のワークロードの割り当てを示す説明図である。
【図１１】本発明の一実施形態に係る監視制御システムにおいて、所望のワークロードをインプットする画面の説明図である。
【図１２】本発明の一実施形態に係る監視制御システムにおいて、サーバ追加後の性能値の計算例を示す表図である。
【図１３】本発明の一実施形態に係る監視制御システムにおいて、サーバ追加後のボトルネック検出例を示す表図である。
【図１４】本発明の一実施形態に係る監視制御システムにおいて、ボトルネック検出結果を示す画面の説明図である。
【発明を実施するための形態】
【００１５】
以下、本発明に係る監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムの実施形態について、図面を参照して説明する。
なお、以下に示す本発明の監視制御システム及び監視制御サーバで実行される処理動作は、プログラム（ソフトウェア）の命令によりコンピュータで実行される処理，手段，機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示すような本発明の所定の処理、例えば、複数の被監視制御サーバから収集した性能情報に基づくサーバシステムの性能のモデル化、構成変更前の性能モデルから構成変更後の性能モデルの生成、構成変更後の性能モデルに基づくサーバの構成変更に伴う２次的なボトルネック発生の予測、複数の被監視制御サーバから収集した性能情報とサーバシステムの負荷情報に基づく各被監視制御サーバの性能の相関関数のモデル化等の処理・手順を行わせる。
【００１６】
このように、本発明における各処理や手段は、プログラムとコンピュータとが協働した具体的手段によって実現される。
なお、プログラムの全部又は一部は、例えば、磁気ディスク，光ディスク，半導体メモリ，その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。
【００１７】
［監視制御システムの概略］
まず、図１を参照して、本発明の一実施形態に係る監視制御サーバの概略構成について説明する。
図１は、本発明の一実施形態に係る監視制御サーバの概略構成を示す機能ブロック図である。
同図に示すように、本実施形態の監視制御サーバ２は、スケールアウト型サーバシステムを構成する複数の被監視制御サーバ３と通信可能に接続されて、複数の被監視制御サーバ３を監視制御するための監視制御サーバである。
【００１８】
監視制御サーバ２は、例えば、サーバを構成するワークステーションやパーソナルコンピュータ等のコンピュータ（情報処理装置）からなり、コンピュータにインストールされたプログラムが実行されることにより、以下のような各手段を構成するようになっている。
まず、図１（ａ）に示すように、監視制御サーバ２は、ボトルネック予測手段２ａを備える。
また、図１（ｂ）に示すように、監視制御サーバ２は、ボトルネック予測手段２ａに加えて、性能モデル化手段２ｂ及び構成変更後性能モデル生成手段２ｃを備えることができる。
【００１９】
ボトルネック予測手段２ａは、複数の被監視制御サーバ３で構成されるスケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックの発生を予測する手段である。
性能モデル化手段２ｂは、複数の被監視制御サーバ３から収集した性能情報に基づいて、被監視制御サーバ３で構成されるスケールアウト型サーバシステムの性能をモデル化する手段である。
構成変更後性能モデル生成手段２ｃは、被監視制御サーバ３で構成されるスケールアウト型サーバシステムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する手段である。
そして、ボトルネック予測手段２ａは、構成変更後性能モデル生成手段２ｃで生成される構成変更後の性能モデルに基づいて、被監視制御サーバ３で構成されるスケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックの発生を予測するようになっている。
【００２０】
性能モデル化手段２ｂは、複数の被監視制御サーバ３から収集した性能情報と、被監視制御サーバ３で構成されるスケールアウト型サーバシステムの負荷情報に基づいて、各被監視制御サーバ３の性能を、負荷を変数とする相関関数にモデル化する処理を行う。
構成変更後性能モデル生成手段２ｃは、スケールアウト型サーバシステムの構成変更指示に応じて、追加される被監視制御サーバ３と同種の被監視制御サーバを既存の被監視制御サーバ３から選択し、当該既存の被監視制御サーバ３の相関関数を、追加される被監視制御サーバの相関関数として複製する処理を行う。
【００２１】
さらに、ボトルネック予測手段２ａは、構成変更後の性能モデルである各被監視制御サーバ３の相関関数に所定の負荷を代入し、その出力が所定の閾値を超えている被監視制御サーバ３を、スケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックであるとして抽出・予測する。
ここで、相関関数に代入される負荷データは、任意に指定・入力することができる。
以上のような各手段を備える本実施形態の監視制御サーバ２とこれを備える監視制御システムのより具体的な構成及び動作について、図２〜図１４を参照して以下に詳述する。
【００２２】
［監視制御システムの詳細］
図２は、本発明の実施形態に係る監視制御システムの構成を示すブロック図である。
同図に示すシステムは、スケールアウト型サーバシステムの監視制御を行う監視制御システムであって、監視端末１と、監視制御サーバ２と、複数の被監視制御サーバ３とから構成されている。
監視端末１は、監視制御サーバ２と通信可能に接続された情報処理装置からなり、図２に示すように、性能情報表示部１１と、論理構成エディタ１２とを備える。
【００２３】
監視制御サーバ２は、図１に示した監視制御サーバ２と同様の情報処理装置からなり、図２に示すように、構成変更後性能予測手段２１と、相関モデル蓄積手段２３と、相関検出部２４と、論理構成データ２５と、論理構成管理部２６と、監視装置２７と、性能情報蓄積手段２８と、制御装置２９とを備える。
被監視制御サーバ３は、監視制御サーバ２と通信可能に接続された複数のサーバ装置を構成する情報処理装置からなり、図２に示すように、各被監視制御サーバ３が監視制御エージェント３１を備えている。
【００２４】
被監視制御サーバ３の監視制御エージェント３１は、監視制御サーバ２の監視装置２７及び制御装置２９と通信して、被監視制御サーバ３の性能情報の通知及び制御を行うことができる。
ここで、被監視制御サーバ３の性能情報は、サーバの利用状況によって左右されるが、本実施形態ではスケールアウト型のサーバシステムであるので、同一種類のサーバ間でトランザクションがほぼ均一に振り分けられるようになっている。
【００２５】
被監視制御サーバ３を構成するサーバは、例えば、ＷＥＢサーバ、ＡＰ（アプリケーション）サーバ、ＤＢ（データベース）サーバ等があり、これらサーバのうち、同一種類（ＷＥＢ層、ＡＰ層、ＤＢ層）のサーバ間ではトランザクションがほぼ均一に振り分けられることになる。
なお、サーバの性能情報とは、被監視制御サーバ３が持つＣＰＵ、メモリ、ネットワークなどの利用状況を示す数値データである。これらの数値データは、性能項目ごとに、所定のタイミング（例えば１分おき）の時系列データとなって収集され、監視装置２７に定期的に送信される。
【００２６】
被監視制御サーバ３から収集した時系列の性能情報は、監視制御サーバ２の性能情報蓄積手段２８に蓄積される。
監視制御サーバ２の相関検出部２４は、収集した性能情報から、後述する相関関数導出方法を用いて相関関係を抽出し、相関モデルとして相関モデル蓄積手段２３に蓄積する。
【００２７】
監視端末１の論理構成エディタ１２は、ユーザからの論理構成変更要求を受け付け、監視制御サーバ２の論理構成管理部２６へ構成変更を指示する。
例えば、物理サーバを任意のサーバグループに追加し、稼動サーバの台数を増加させてシステム全体の処理性能を向上させる。
【００２８】
監視制御サーバ２の論理構成管理部２６は、制御装置２９へ構成変更指示を行うとともに、論理構成データ２５を更新する。
被監視制御サーバ３には、ＯＳやアプリケーションが導入され、業務に合わせた設定がされているが、それらは、制御装置２９を介して伝達される論理構成変更指示にしたがって変更される。
例えば、サーバを異なる用途に転用する場合には、新しいアプリケーションの導入指示や、アプリケーションの設定変更指示が、アプリケーションのインストールファイルとともに監視制御サーバ２の制御装置２９から被監視制御サーバ３の監視制御エージェント３１に伝達され、監視制御エージェント３１が受信して処理することで、被監視制御サーバ３の構成が変更される。
これにより、既存の稼動しているシステムに対して、新規サーバの追加を行うことができる。
【００２９】
監視端末１においてユーザが論理構成の変更を入力・指示することにより、監視制御サーバ２は、論理構成データ２５を介して、構成変更後性能予測手段２１が構成変更の開始を認識する。
構成変更後性能予測手段２１は、相関モデル蓄積手段２３より得られる相関モデルから、構成変更後の相関モデルを計算し、構成変更後の性能予測を行う。
【００３０】
監視端末１では、ユーザの入力操作等に応じて、さらに性能情報表示部１１に表示されるダイアログに、構成変更後に期待するスループットの値が入力される。
性能情報表示部１１には、構成変更後の各サーバの必要となるリソース消費見込みが表示される。
この情報から、もし新たなボトルネックが検出されれば、所定の警告が出力・表示される。これにより、監視端末１を操作するユーザは、構成変更前にボトルネックの発生を認識することができ、最終的に適切な構成変更が可能になる。
【００３１】
［監視制御サーバの処理内容］ 
次に、監視制御サーバの具体的な処理内容について、図２〜図１４を参照して説明する。
図３は、監視制御サーバの処理手順を示すフローチャート、図４は、監視制御サーバが収集する性能項目を示す説明図、図５は、サーバ追加前の性能項目間に成り立つ相関関係を示すネットワーク図、図６は、サーバ追加前の性能項目間に成り立つ相関関係を示す表図、図７は、論理構成の変更指示を行う画面の説明図、図８は、サーバ追加後の性能項目間に成り立つ相関関係を示すネットワーク図、図９は、サーバ追加後の性能項目間に成り立つ相関関係を示す表図、図１０は、サーバ追加後のサーバ毎のワークロードの割り当てを示す説明図、図１１は、所望のワークロードをインプットする画面の説明図、図１２は、サーバ追加後の性能値の計算例を示す表図、図１３は、サーバ追加後のボトルネック検出例を示す表図、図１４は、ボトルネック検出結果を示す画面の説明図である。
【００３２】
「ステップＳ１：性能モデル化（性能モデル化手段）」
まず、図３のステップＳ１で示す「性能モデル化」の処理が行われる。この性能モデル化処理が、上述した性能モデル化手段２ｂに相当する（図１参照）。
具体的には、監視制御サーバ２は、被監視制御サーバ３から収集した時系列の性能情報を性能情報蓄積手段２８に蓄積する。例えば、図４に示すように、１列目に時刻、２列目以降に性能情報が格納される。
また、監視制御サーバ２は、システムに対する負荷（ワークロード）も定期的に取得し、性能情報蓄積手段２８に蓄積する。図４に示す例では、最終列に負荷が格納されている。負荷の取得方法は、任意であるが、例えば、Ｗｅｂサーバである場合、毎秒のリクエスト数をカウントすることで取得できる。
【００３３】
次に、相関検出部２４は、これら性能情報を分析し、性能モデルとして性能情報間の相関関数（変換関数）を算出する。
ここで、相関検出部２４は、図５に示すように、性能情報に含まれる任意の二つの項目を、全ての組み合わせで選択し、それぞれの組み合わせについて相関関数を導出することができる。本実施形態では、各被監視制御サーバ２の性能を、負荷を変数とする相関関数にモデル化する。
相関関数の導出方法としては、様々な方法が知られているが、説明を簡略化するために、近似する一次関数「ｙ＝Ａｘ＋Ｃ」を求める方法を用いて説明する。
【００３４】
上記の方法では、負荷をｘ、性能をｙとし、近似する一次関数「ｙ＝Ａｘ＋Ｃ」の係数を求める。
例えば、要素「ＡＰ１．ＣＰＵ」の相関関数は、「ｙ＝０．５ｘ＋８」として導出することができ、その係数Ａ、Ｃの値が図６に示すように相関モデル蓄積手段２３に蓄積される。
また、相関関数の導出に際しては、重みＷも算出され、相関モデル蓄積手段２３に蓄積される。この重みＷは、相関関数の誤差補正係数であり、導出した相関関数に負荷を代入して得られる性能パターンと、実際に収集した性能パターンとの差分から算出することができる。
【００３５】
「ステップＳ２：構成変更の指示」
次に、図３のステップＳ２で示す「構成変更の指示」の処理が行われる。
具体的には、ユーザ等による監視端末１の入力操作により、監視端末１の論理構成エディタ１２の画面（図７参照）で、構成変更の指示が入力・指定される。
例えば、ＡＰサーバ群に、ＡＰ２と言う名前の新規のＡＰサーバが追加されて、ＡＰサーバ層の構成変更（サーバ追加）が指示・入力される。
この指示は、監視制御サーバ２の論理構成管理部２６に受け渡され、論理構成データ２５に格納される。
構成変更後性能予測手段２１には、論理構成データ２５を介して、構成変更（サーバ追加）が行われることが通知される。
【００３６】
「ステップＳ３：相関の再計算（構成変更後性能モデル生成手段）」
次いで、図３のステップＳ３で示す「相関の再計算」の処理が行われる。この相関の再計算処理が、上述した構成変更後性能モデル生成手段２ｃに相当する（図１参照）。
具体的には、構成変更後性能予測手段２１は、ステップＳ２の構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデル（図８参照）を生成する。
例えば、図５及び図６に示すように、構成変更前の性能モデルにおいては、相関関数「ｙ＝Ａｘ＋Ｃ」が成立しており、ＡＰサーバを追加したい場合、構成変更後性能予測手段２１は、サーバが追加されようとしている層から、既存のサーバを選択し、既存のサーバに成り立っている相関関数「ｙ＝Ａｘ＋Ｃ」を、新規サーバにおいても成り立つとして複製し、サーバ追加後の性能モデルを生成する。
例えば、図９に示すように、ＡＰサーバ層の既存サーバである「ＡＰ１．ＣＰＵ」のデータ領域からの相関関数の値、Ａ、Ｃ、Ｗが抽出され、「ＡＰ２．ＣＰＵ」のデータ領域に複製される。
図８に、構成変更（サーバ追加）後の性能項目間に成り立つ相関関係を示す。
【００３７】
「ステップＳ４：新たなボトルネックの探索（ボトルネック予測手段）」
さらに、図３のステップＳ４で示す「新たなボトルネックの探索」の処理が行われる。この新たなボトルネックの探索処理が、上述したボトルネック予測手段２ａに相当する（図１参照）。
具体的には、構成変更後性能予測手段２１は、構成変更後の性能モデルに基づいて、構成変更に伴う２次的なボトルネックの発生を検出・予測する。
性能モデルを用いたボトルネックの検出は、例えば、性能モデルである相関関数の変数に要求値（例えば、本実施形態では要求負荷）を代入し、得られた性能値が所定の閾値を超えているか否かに基づいて検出することができる。
以下、具体的なボトルネックの検出方法について説明する。
【００３８】
図１０に示すように、スケールアウト型サーバシステムにおける同種類のサーバの負荷は均一に分散する。従って、例えばＡＰサーバが１台から２台に増えると、各ＡＰサーバにかかる負荷は半分に減少する。
ユーザは、監視端末１を介して、図１１に示すような画面において、所望の負荷（ワークロード）として、例えば「３００／ｓｅｃ」と所望の要求データを入力することができる。
構成変更後性能予測手段２１は、入力された所望の負荷を上限とし、段階的に負荷を増加しながらボトルネックの検出を行う。
例えば、図１２及び図１３に示すように、「１００／ｓｅｃ」から開始し、段階的に「１０／ｓｅｃ」ずつ増やしながらボトルネックの検出を行う。
【００３９】
ここで、所望の負荷W’に対して各サーバの性能値を計算する場合には、
ｙ＝Ａ・W’・サーバ追加係数＋Ｃ
とすればよい。（ただし、重みＷによる補正は省略）
サーバ追加係数とは、サーバのグループ毎に、
サーバ追加前の台数／サーバ追加後の台数
を計算することで得られる。
この方法にしたがい、全ての性能項目に関して計算を行う。
例えば、ＡＰサーバの性能値を計算する場合には、
ｙ＝Ａ・Ｗ’／２＋Ｃ
とすればよい。
同様にＷＥＢサーバ及びＤＢサーバの性能値を計算する場合には、
ｙ＝Ａ・Ｗ’＋Ｃ
とすればよい。
【００４０】
「ステップＳ５：判断」
図３のステップＳ５で示す判断処理が行われる。
この処理ステップでは、ボトルネックが検出されたか否かが判断される。
例えば、図１３に示すように、ユーザが負荷＝３００を設定したところ、負荷が２２０で、ＤＢサーバに性能の飽和が発生している。
この場合、図１４に示すように、結果表示画面において、サーバ追加後のシステムにおいて最初にボトルネックとなるサーバを表示する。
このようにして、ＡＰサーバ以外に発生する２次的なボトルネックの発生を、ＡＰサーバを追加する前に確認することが可能となる。
【００４１】
「ステップＳ６：警告」
次に、図３のステップＳ６で示す「警告」の処理が行われる。
上述したステップＳ５の処理によりボトルネックの発生が予測された場合は、ユーザに警告を促すことができる。
これは、例えば一種類のサーバの追加だけでは所望のスループットは補えず、他種のサーバの追加も同時に考慮すべきであるからである。
具体的には、上述した例によれば、ＡＰサーバの負荷がサーバ追加により軽減されたことにより、ＡＰサーバのグループでは所望の負荷を処理することが可能と判断できる一方で、ＤＢサーバについては要求される負荷を満たせないことが理解できる。
従って、このような場合には、所定の警告処理が実行され、監視端末１を操作するユーザに対して警告が促されることになる。
【００４２】
「ステップＳ７：構成変更の実施」
さらに、図３のＳステップＳ７で示す「構成変更の実施」の処理が行われる。
上述したステップＳ５の処理によりボトルネックが無いことが確認できた場合には、実際に構成の変更が実施される。
以上のステップを経ることにより、構成変更に伴う２次的なボトルネックを発生させることなく、適切な構成変更を実施することが可能となる。
【００４３】
以上説明したように、本実施形態の監視制御システム及び監視制御サーバによれば、スケールアウト型サーバシステムを構成する複数の被監視制御サーバ３に接続され、複数の被監視制御サーバ３を監視制御する監視制御サーバ２を備え、監視制御サーバ２が、スケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックの発生を予測するので、２次的なボトルネックの発生を回避しつつ、適切な構成変更を実施することができる。
【００４４】
監視制御サーバ２は、複数の被監視制御サーバ３から収集した性能情報に基づいて、スケールアウト型サーバシステムの性能をモデル化し、スケールアウト型サーバシステムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成し、構成変更後の性能モデルに基づいて、スケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックの発生を予測するので、構成変更に伴う２次的なボトルネックの発生を、構成変更前の性能モデルを踏まえて正確に予測することができる。
【００４５】
また、監視制御サーバ２は、複数の被監視制御サーバ３から収集した性能情報と、スケールアウト型サーバシステムの負荷情報に基づいて、各被監視制御サーバ２の性能を、負荷を変数とする相関関数にモデル化するので、要求負荷に対する各被監視制御サーバ２の性能を容易に算出し、ボトルネックを検出することができる。
また、監視制御サーバ２は、スケールアウト型サーバシステムの構成変更指示に応じて、追加される被監視制御サーバ３と同種の被監視制御サーバ３を既存の被監視制御サーバ３から選択し、当該既存の被監視制御サーバ３の相関関数を、追加される被監視制御サーバ３の相関関数として複製するので、構成変更後の性能モデルを容易に生成することができる。
【００４６】
また、監視制御サーバ２は、構成変更後の性能モデルである各被監視制御サーバ３の相関関数に所定の負荷を代入し、その出力が所定の閾値を超えている被監視制御サーバ３が、スケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックであると予測するので、簡単な計算処理でボトルネックの検出を行うことができる。
さらに、スケールアウト型サーバシステムの構成変更に伴う２次的なボトルネックを予測する際、相関関数に代入する負荷が任意に指定されるので、ユーザは、様々な負荷を入力して構成変更に伴う２次的なボトルネックを予測し、適切な構成変更を行うことができる。
【００４７】
以上、本発明について、一実施形態を示して説明したが、本発明は、上述した実施形態にのみ限定されるものではなく、特許請求の範囲内で種々の変更が可能であることは言うまでもない。
例えば、上述した実施形態では、被監視制御サーバに設けられるサーバとして、ＷＥＢサーバ、ＡＰ（アプリケーション）サーバ、ＤＢ（データベース）サーバの３種類のサーバを例にとって説明したが、本発明により監視制御の対象となるサーバの種類や数等は特に上述した実施形態の場合に限定されるものではない。
【産業上の利用可能性】
【００４８】
本発明は、スケールアウト型サーバシステムを監視制御する監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムとして利用することができる。
【符号の説明】
【００４９】
１  監視端末
１１  性能情報表示部
１２  論理構成エディタ
２  監視制御サーバ
２１  構成変更後性能予測手段
２３  相関モデル蓄積手段
２４  相関検出部
２５  論理構成データ
２６  論理構成管理部
２７  監視装置
２８  性能情報蓄積手段
２９  制御装置
３  被監視制御サーバ
３１  監視制御エージェント
【図１】
0005500301.tif 000002
【図２】
0005500301.tif 000003
【図３】
0005500301.tif 000004
【図４】
0005500301.tif 000005
【図５】
0005500301.tif 000006
【図６】
0005500301.tif 000007
【図７】
0005500301.tif 000008
【図８】
0005500301.tif 000009
【図９】
0005500301.tif 000010
【図１０】
0005500301.tif 000011
【図１１】
0005500301.tif 000012
【図１２】
0005500301.tif 000013
【図１３】
0005500301.tif 000014
【図１４】
0005500301.tif 000015