JP2013242899A - 監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム - Google Patents
監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム Download PDFInfo
- Publication number
- JP2013242899A JP2013242899A JP2013149251A JP2013149251A JP2013242899A JP 2013242899 A JP2013242899 A JP 2013242899A JP 2013149251 A JP2013149251 A JP 2013149251A JP 2013149251 A JP2013149251 A JP 2013149251A JP 2013242899 A JP2013242899 A JP 2013242899A
- Authority
- JP
- Japan
- Prior art keywords
- server
- performance
- configuration change
- monitoring control
- servers
- 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.)
- Granted
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
Abstract
【課題】スケールアウト型サーバシステムにおいて、2次的なボトルネックの発生を回避しつつ、適切な構成変更を実施できるようにする。
【解決手段】スケールアウト型サーバシステムを構成する複数の被監視制御サーバ3に接続され、複数の被監視制御サーバ3を監視制御する監視制御サーバ2を備え、監視制御サーバ2が、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を予測する。
【選択図】図2
【解決手段】スケールアウト型サーバシステムを構成する複数の被監視制御サーバ3に接続され、複数の被監視制御サーバ3を監視制御する監視制御サーバ2を備え、監視制御サーバ2が、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を予測する。
【選択図】図2
Description
本発明は、スケールアウト型サーバシステムを監視制御する監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムに関する。
企業情報システム、データセンタ、プロバイダなどの比較的大規模なシステムにおいて、スケールアウト型サーバシステムが普及している。
スケールアウト型のサーバシステムとは、サーバの数を増やす(スケールアウト)ことで、サーバ群全体のパフォーマンスを向上させるというものである。
例えば、一台のサーバが10人のユーザしか処理できない場合に、サーバを二台に増やすことで負荷を分散し、20人のユーザへの対応が可能となるというものである。
スケールアウト型のサーバシステムとは、サーバの数を増やす(スケールアウト)ことで、サーバ群全体のパフォーマンスを向上させるというものである。
例えば、一台のサーバが10人のユーザしか処理できない場合に、サーバを二台に増やすことで負荷を分散し、20人のユーザへの対応が可能となるというものである。
このようなスケールアウト型サーバシステムは、複数のサーバ(物理サーバ及び仮想サーバを含む。)を役割毎にグループ化し、グループ内のサーバに処理要求を均等に割り当てるので、各グループの処理量をサーバの台数で管理できるという利点がある。
そして、サーバをスケールアウトした場合にも、複数のサーバを連携して動作させることになるため、メンテナンスや障害発生時にもサービスを完全に停止させる必要がないというメリットがある。
そして、サーバをスケールアウトした場合にも、複数のサーバを連携して動作させることになるため、メンテナンスや障害発生時にもサービスを完全に停止させる必要がないというメリットがある。
このようなスケールアウト型サーバシステムの普及は、システムの構成変更(スケールアウト)を容易化するサーバプロビジョニングツールの登場も影響しており、システム管理者は、このツールを用いることにより、負荷(ワークロード)に応じたシステムの柔軟な構成変更が可能となった。
また、システムが処理できる毎秒のトランザクション件数に対して、ボトルネック箇所を検出するキャパシティプランニング技術も提供されている。このキャパシティプランニング技術によれば、システム管理者は、システムのボトルネック箇所を特定し、所望の性能に対して必要となるサーバ台数を見積もり、システムの構成変更を行うことが可能となった。
また、システムが処理できる毎秒のトランザクション件数に対して、ボトルネック箇所を検出するキャパシティプランニング技術も提供されている。このキャパシティプランニング技術によれば、システム管理者は、システムのボトルネック箇所を特定し、所望の性能に対して必要となるサーバ台数を見積もり、システムの構成変更を行うことが可能となった。
しかしながら、スケールアウト型サーバシステムでは、現行システムのボトルネックを特定し、そのボトルネックを解消すべく構成変更を行っても、性能が向上しない場合があった。
その理由は、構成変更に伴って許容負荷が増加すると、その影響で別の箇所に2次的にボトルネックが発生する可能性があるからである。
そして、このような2次的なボトルネックの発生は、予測が不可能であるため、実際に構成変更を行った後に、再度ボトルネックの有無を検出し、構成変更を検討する必要があった。
その理由は、構成変更に伴って許容負荷が増加すると、その影響で別の箇所に2次的にボトルネックが発生する可能性があるからである。
そして、このような2次的なボトルネックの発生は、予測が不可能であるため、実際に構成変更を行った後に、再度ボトルネックの有無を検出し、構成変更を検討する必要があった。
ここで、特許文献1には、ストレージシステムの構成を実際に変更する前に、ストレージシステムの各要素の状態に基づいてボトルネックの発生を検出し、このボトルネックを解消するための対策を提示するストレージシステム及びその障害解消方法が示されている。
しかしながら、この特許文献1記載のボトルネックの解消方法は、ホストコンピュータからストレージ装置までの通信経路上に存在する各要素を対象としてボトルネックの検出を行うことに特化されており、スケールアウト型サーバシステムにおいて2次的なボトルネックとなるサーバを予測することはできなかった。
しかしながら、この特許文献1記載のボトルネックの解消方法は、ホストコンピュータからストレージ装置までの通信経路上に存在する各要素を対象としてボトルネックの検出を行うことに特化されており、スケールアウト型サーバシステムにおいて2次的なボトルネックとなるサーバを予測することはできなかった。
本発明の目的は、上述した課題である2次的なボトルネックの発生を回避しつつ適切な構成変更を可能とするという課題を解決する監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムを提供することにある。
上記目的を達成するため本発明の監視制御システムは、システムを構成する複数のサーバに接続され、複数のサーバを監視する監視サーバを備え、監視サーバが、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段とを備える構成としてある。
また、本発明の監視制御方法は、システムを構成する複数のサーバに、複数のサーバを監視する監視サーバを接続し、監視サーバが、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化し、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する方法としてある。
また、本発明の監視制御サーバは、システムを構成する複数のサーバに接続され、複数のサーバを監視制御するにあたり、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段とを備える構成としてある。
また、本発明の監視制御プログラムは、システムを構成する複数のサーバに接続され、複数のサーバを監視制御するコンピュータに、複数のサーバから収集した性能情報に基づいて、各サーバの性能をモデル化させ、システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成させる構成としてある。
本発明によれば、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を事前に予測して、2次的なボトルネックの発生を回避しつつ、適切な構成変更を実施することができる。
以下、本発明に係る監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムの実施形態について、図面を参照して説明する。
なお、以下に示す本発明の監視制御システム及び監視制御サーバで実行される処理動作は、プログラム(ソフトウェア)の命令によりコンピュータで実行される処理,手段,機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示すような本発明の所定の処理、例えば、複数の被監視制御サーバから収集した性能情報に基づくサーバシステムの性能のモデル化、構成変更前の性能モデルから構成変更後の性能モデルの生成、構成変更後の性能モデルに基づくサーバの構成変更に伴う2次的なボトルネック発生の予測、複数の被監視制御サーバから収集した性能情報とサーバシステムの負荷情報に基づく各被監視制御サーバの性能の相関関数のモデル化等の処理・手順を行わせる。
なお、以下に示す本発明の監視制御システム及び監視制御サーバで実行される処理動作は、プログラム(ソフトウェア)の命令によりコンピュータで実行される処理,手段,機能によって実現される。プログラムは、コンピュータの各構成要素に指令を送り、以下に示すような本発明の所定の処理、例えば、複数の被監視制御サーバから収集した性能情報に基づくサーバシステムの性能のモデル化、構成変更前の性能モデルから構成変更後の性能モデルの生成、構成変更後の性能モデルに基づくサーバの構成変更に伴う2次的なボトルネック発生の予測、複数の被監視制御サーバから収集した性能情報とサーバシステムの負荷情報に基づく各被監視制御サーバの性能の相関関数のモデル化等の処理・手順を行わせる。
このように、本発明における各処理や手段は、プログラムとコンピュータとが協働した具体的手段によって実現される。
なお、プログラムの全部又は一部は、例えば、磁気ディスク,光ディスク,半導体メモリ,その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。
なお、プログラムの全部又は一部は、例えば、磁気ディスク,光ディスク,半導体メモリ,その他任意のコンピュータで読取り可能な記録媒体により提供され、記録媒体から読み出されたプログラムがコンピュータにインストールされて実行される。また、プログラムは、記録媒体を介さず、通信回線を通じて直接にコンピュータにロードし実行することもできる。
[監視制御システムの概略]
まず、図1を参照して、本発明の一実施形態に係る監視制御サーバの概略構成について説明する。
図1は、本発明の一実施形態に係る監視制御サーバの概略構成を示す機能ブロック図である。
同図に示すように、本実施形態の監視制御サーバ2は、スケールアウト型サーバシステムを構成する複数の被監視制御サーバ3と通信可能に接続されて、複数の被監視制御サーバ3を監視制御するための監視制御サーバである。
まず、図1を参照して、本発明の一実施形態に係る監視制御サーバの概略構成について説明する。
図1は、本発明の一実施形態に係る監視制御サーバの概略構成を示す機能ブロック図である。
同図に示すように、本実施形態の監視制御サーバ2は、スケールアウト型サーバシステムを構成する複数の被監視制御サーバ3と通信可能に接続されて、複数の被監視制御サーバ3を監視制御するための監視制御サーバである。
監視制御サーバ2は、例えば、サーバを構成するワークステーションやパーソナルコンピュータ等のコンピュータ(情報処理装置)からなり、コンピュータにインストールされたプログラムが実行されることにより、以下のような各手段を構成するようになっている。
まず、図1(a)に示すように、監視制御サーバ2は、ボトルネック予測手段2aを備える。
また、図1(b)に示すように、監視制御サーバ2は、ボトルネック予測手段2aに加えて、性能モデル化手段2b及び構成変更後性能モデル生成手段2cを備えることができる。
まず、図1(a)に示すように、監視制御サーバ2は、ボトルネック予測手段2aを備える。
また、図1(b)に示すように、監視制御サーバ2は、ボトルネック予測手段2aに加えて、性能モデル化手段2b及び構成変更後性能モデル生成手段2cを備えることができる。
ボトルネック予測手段2aは、複数の被監視制御サーバ3で構成されるスケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を予測する手段である。
性能モデル化手段2bは、複数の被監視制御サーバ3から収集した性能情報に基づいて、被監視制御サーバ3で構成されるスケールアウト型サーバシステムの性能をモデル化する手段である。
構成変更後性能モデル生成手段2cは、被監視制御サーバ3で構成されるスケールアウト型サーバシステムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する手段である。
そして、ボトルネック予測手段2aは、構成変更後性能モデル生成手段2cで生成される構成変更後の性能モデルに基づいて、被監視制御サーバ3で構成されるスケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を予測するようになっている。
性能モデル化手段2bは、複数の被監視制御サーバ3から収集した性能情報に基づいて、被監視制御サーバ3で構成されるスケールアウト型サーバシステムの性能をモデル化する手段である。
構成変更後性能モデル生成手段2cは、被監視制御サーバ3で構成されるスケールアウト型サーバシステムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する手段である。
そして、ボトルネック予測手段2aは、構成変更後性能モデル生成手段2cで生成される構成変更後の性能モデルに基づいて、被監視制御サーバ3で構成されるスケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を予測するようになっている。
性能モデル化手段2bは、複数の被監視制御サーバ3から収集した性能情報と、被監視制御サーバ3で構成されるスケールアウト型サーバシステムの負荷情報に基づいて、各被監視制御サーバ3の性能を、負荷を変数とする相関関数にモデル化する処理を行う。
構成変更後性能モデル生成手段2cは、スケールアウト型サーバシステムの構成変更指示に応じて、追加される被監視制御サーバ3と同種の被監視制御サーバを既存の被監視制御サーバ3から選択し、当該既存の被監視制御サーバ3の相関関数を、追加される被監視制御サーバの相関関数として複製する処理を行う。
構成変更後性能モデル生成手段2cは、スケールアウト型サーバシステムの構成変更指示に応じて、追加される被監視制御サーバ3と同種の被監視制御サーバを既存の被監視制御サーバ3から選択し、当該既存の被監視制御サーバ3の相関関数を、追加される被監視制御サーバの相関関数として複製する処理を行う。
さらに、ボトルネック予測手段2aは、構成変更後の性能モデルである各被監視制御サーバ3の相関関数に所定の負荷を代入し、その出力が所定の閾値を超えている被監視制御サーバ3を、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックであるとして抽出・予測する。
ここで、相関関数に代入される負荷データは、任意に指定・入力することができる。
以上のような各手段を備える本実施形態の監視制御サーバ2とこれを備える監視制御システムのより具体的な構成及び動作について、図2〜図14を参照して以下に詳述する。
ここで、相関関数に代入される負荷データは、任意に指定・入力することができる。
以上のような各手段を備える本実施形態の監視制御サーバ2とこれを備える監視制御システムのより具体的な構成及び動作について、図2〜図14を参照して以下に詳述する。
[監視制御システムの詳細]
図2は、本発明の実施形態に係る監視制御システムの構成を示すブロック図である。
同図に示すシステムは、スケールアウト型サーバシステムの監視制御を行う監視制御システムであって、監視端末1と、監視制御サーバ2と、複数の被監視制御サーバ3とから構成されている。
監視端末1は、監視制御サーバ2と通信可能に接続された情報処理装置からなり、図2に示すように、性能情報表示部11と、論理構成エディタ12とを備える。
図2は、本発明の実施形態に係る監視制御システムの構成を示すブロック図である。
同図に示すシステムは、スケールアウト型サーバシステムの監視制御を行う監視制御システムであって、監視端末1と、監視制御サーバ2と、複数の被監視制御サーバ3とから構成されている。
監視端末1は、監視制御サーバ2と通信可能に接続された情報処理装置からなり、図2に示すように、性能情報表示部11と、論理構成エディタ12とを備える。
監視制御サーバ2は、図1に示した監視制御サーバ2と同様の情報処理装置からなり、図2に示すように、構成変更後性能予測手段21と、相関モデル蓄積手段23と、相関検出部24と、論理構成データ25と、論理構成管理部26と、監視装置27と、性能情報蓄積手段28と、制御装置29とを備える。
被監視制御サーバ3は、監視制御サーバ2と通信可能に接続された複数のサーバ装置を構成する情報処理装置からなり、図2に示すように、各被監視制御サーバ3が監視制御エージェント31を備えている。
被監視制御サーバ3は、監視制御サーバ2と通信可能に接続された複数のサーバ装置を構成する情報処理装置からなり、図2に示すように、各被監視制御サーバ3が監視制御エージェント31を備えている。
被監視制御サーバ3の監視制御エージェント31は、監視制御サーバ2の監視装置27及び制御装置29と通信して、被監視制御サーバ3の性能情報の通知及び制御を行うことができる。
ここで、被監視制御サーバ3の性能情報は、サーバの利用状況によって左右されるが、本実施形態ではスケールアウト型のサーバシステムであるので、同一種類のサーバ間でトランザクションがほぼ均一に振り分けられるようになっている。
ここで、被監視制御サーバ3の性能情報は、サーバの利用状況によって左右されるが、本実施形態ではスケールアウト型のサーバシステムであるので、同一種類のサーバ間でトランザクションがほぼ均一に振り分けられるようになっている。
被監視制御サーバ3を構成するサーバは、例えば、WEBサーバ、AP(アプリケーション)サーバ、DB(データベース)サーバ等があり、これらサーバのうち、同一種類(WEB層、AP層、DB層)のサーバ間ではトランザクションがほぼ均一に振り分けられることになる。
なお、サーバの性能情報とは、被監視制御サーバ3が持つCPU、メモリ、ネットワークなどの利用状況を示す数値データである。これらの数値データは、性能項目ごとに、所定のタイミング(例えば1分おき)の時系列データとなって収集され、監視装置27に定期的に送信される。
なお、サーバの性能情報とは、被監視制御サーバ3が持つCPU、メモリ、ネットワークなどの利用状況を示す数値データである。これらの数値データは、性能項目ごとに、所定のタイミング(例えば1分おき)の時系列データとなって収集され、監視装置27に定期的に送信される。
被監視制御サーバ3から収集した時系列の性能情報は、監視制御サーバ2の性能情報蓄積手段28に蓄積される。
監視制御サーバ2の相関検出部24は、収集した性能情報から、後述する相関関数導出方法を用いて相関関係を抽出し、相関モデルとして相関モデル蓄積手段23に蓄積する。
監視制御サーバ2の相関検出部24は、収集した性能情報から、後述する相関関数導出方法を用いて相関関係を抽出し、相関モデルとして相関モデル蓄積手段23に蓄積する。
監視端末1の論理構成エディタ12は、ユーザからの論理構成変更要求を受け付け、監視制御サーバ2の論理構成管理部26へ構成変更を指示する。
例えば、物理サーバを任意のサーバグループに追加し、稼動サーバの台数を増加させてシステム全体の処理性能を向上させる。
例えば、物理サーバを任意のサーバグループに追加し、稼動サーバの台数を増加させてシステム全体の処理性能を向上させる。
監視制御サーバ2の論理構成管理部26は、制御装置29へ構成変更指示を行うとともに、論理構成データ25を更新する。
被監視制御サーバ3には、OSやアプリケーションが導入され、業務に合わせた設定がされているが、それらは、制御装置29を介して伝達される論理構成変更指示にしたがって変更される。
例えば、サーバを異なる用途に転用する場合には、新しいアプリケーションの導入指示や、アプリケーションの設定変更指示が、アプリケーションのインストールファイルとともに監視制御サーバ2の制御装置29から被監視制御サーバ3の監視制御エージェント31に伝達され、監視制御エージェント31が受信して処理することで、被監視制御サーバ3の構成が変更される。
これにより、既存の稼動しているシステムに対して、新規サーバの追加を行うことができる。
被監視制御サーバ3には、OSやアプリケーションが導入され、業務に合わせた設定がされているが、それらは、制御装置29を介して伝達される論理構成変更指示にしたがって変更される。
例えば、サーバを異なる用途に転用する場合には、新しいアプリケーションの導入指示や、アプリケーションの設定変更指示が、アプリケーションのインストールファイルとともに監視制御サーバ2の制御装置29から被監視制御サーバ3の監視制御エージェント31に伝達され、監視制御エージェント31が受信して処理することで、被監視制御サーバ3の構成が変更される。
これにより、既存の稼動しているシステムに対して、新規サーバの追加を行うことができる。
監視端末1においてユーザが論理構成の変更を入力・指示することにより、監視制御サーバ2は、論理構成データ25を介して、構成変更後性能予測手段21が構成変更の開始を認識する。
構成変更後性能予測手段21は、相関モデル蓄積手段23より得られる相関モデルから、構成変更後の相関モデルを計算し、構成変更後の性能予測を行う。
構成変更後性能予測手段21は、相関モデル蓄積手段23より得られる相関モデルから、構成変更後の相関モデルを計算し、構成変更後の性能予測を行う。
監視端末1では、ユーザの入力操作等に応じて、さらに性能情報表示部11に表示されるダイアログに、構成変更後に期待するスループットの値が入力される。
性能情報表示部11には、構成変更後の各サーバの必要となるリソース消費見込みが表示される。
この情報から、もし新たなボトルネックが検出されれば、所定の警告が出力・表示される。これにより、監視端末1を操作するユーザは、構成変更前にボトルネックの発生を認識することができ、最終的に適切な構成変更が可能になる。
性能情報表示部11には、構成変更後の各サーバの必要となるリソース消費見込みが表示される。
この情報から、もし新たなボトルネックが検出されれば、所定の警告が出力・表示される。これにより、監視端末1を操作するユーザは、構成変更前にボトルネックの発生を認識することができ、最終的に適切な構成変更が可能になる。
[監視制御サーバの処理内容]
次に、監視制御サーバの具体的な処理内容について、図2〜図14を参照して説明する。
図3は、監視制御サーバの処理手順を示すフローチャート、図4は、監視制御サーバが収集する性能項目を示す説明図、図5は、サーバ追加前の性能項目間に成り立つ相関関係を示すネットワーク図、図6は、サーバ追加前の性能項目間に成り立つ相関関係を示す表図、図7は、論理構成の変更指示を行う画面の説明図、図8は、サーバ追加後の性能項目間に成り立つ相関関係を示すネットワーク図、図9は、サーバ追加後の性能項目間に成り立つ相関関係を示す表図、図10は、サーバ追加後のサーバ毎のワークロードの割り当てを示す説明図、図11は、所望のワークロードをインプットする画面の説明図、図12は、サーバ追加後の性能値の計算例を示す表図、図13は、サーバ追加後のボトルネック検出例を示す表図、図14は、ボトルネック検出結果を示す画面の説明図である。
次に、監視制御サーバの具体的な処理内容について、図2〜図14を参照して説明する。
図3は、監視制御サーバの処理手順を示すフローチャート、図4は、監視制御サーバが収集する性能項目を示す説明図、図5は、サーバ追加前の性能項目間に成り立つ相関関係を示すネットワーク図、図6は、サーバ追加前の性能項目間に成り立つ相関関係を示す表図、図7は、論理構成の変更指示を行う画面の説明図、図8は、サーバ追加後の性能項目間に成り立つ相関関係を示すネットワーク図、図9は、サーバ追加後の性能項目間に成り立つ相関関係を示す表図、図10は、サーバ追加後のサーバ毎のワークロードの割り当てを示す説明図、図11は、所望のワークロードをインプットする画面の説明図、図12は、サーバ追加後の性能値の計算例を示す表図、図13は、サーバ追加後のボトルネック検出例を示す表図、図14は、ボトルネック検出結果を示す画面の説明図である。
「ステップS1:性能モデル化(性能モデル化手段)」
まず、図3のステップS1で示す「性能モデル化」の処理が行われる。この性能モデル化処理が、上述した性能モデル化手段2bに相当する(図1参照)。
具体的には、監視制御サーバ2は、被監視制御サーバ3から収集した時系列の性能情報を性能情報蓄積手段28に蓄積する。例えば、図4に示すように、1列目に時刻、2列目以降に性能情報が格納される。
また、監視制御サーバ2は、システムに対する負荷(ワークロード)も定期的に取得し、性能情報蓄積手段28に蓄積する。図4に示す例では、最終列に負荷が格納されている。負荷の取得方法は、任意であるが、例えば、Webサーバである場合、毎秒のリクエスト数をカウントすることで取得できる。
まず、図3のステップS1で示す「性能モデル化」の処理が行われる。この性能モデル化処理が、上述した性能モデル化手段2bに相当する(図1参照)。
具体的には、監視制御サーバ2は、被監視制御サーバ3から収集した時系列の性能情報を性能情報蓄積手段28に蓄積する。例えば、図4に示すように、1列目に時刻、2列目以降に性能情報が格納される。
また、監視制御サーバ2は、システムに対する負荷(ワークロード)も定期的に取得し、性能情報蓄積手段28に蓄積する。図4に示す例では、最終列に負荷が格納されている。負荷の取得方法は、任意であるが、例えば、Webサーバである場合、毎秒のリクエスト数をカウントすることで取得できる。
次に、相関検出部24は、これら性能情報を分析し、性能モデルとして性能情報間の相関関数(変換関数)を算出する。
ここで、相関検出部24は、図5に示すように、性能情報に含まれる任意の二つの項目を、全ての組み合わせで選択し、それぞれの組み合わせについて相関関数を導出することができる。本実施形態では、各被監視制御サーバ2の性能を、負荷を変数とする相関関数にモデル化する。
相関関数の導出方法としては、様々な方法が知られているが、説明を簡略化するために、近似する一次関数「y=Ax+C」を求める方法を用いて説明する。
ここで、相関検出部24は、図5に示すように、性能情報に含まれる任意の二つの項目を、全ての組み合わせで選択し、それぞれの組み合わせについて相関関数を導出することができる。本実施形態では、各被監視制御サーバ2の性能を、負荷を変数とする相関関数にモデル化する。
相関関数の導出方法としては、様々な方法が知られているが、説明を簡略化するために、近似する一次関数「y=Ax+C」を求める方法を用いて説明する。
上記の方法では、負荷をx、性能をyとし、近似する一次関数「y=Ax+C」の係数を求める。
例えば、要素「AP1.CPU」の相関関数は、「y=0.5x+8」として導出することができ、その係数A、Cの値が図6に示すように相関モデル蓄積手段23に蓄積される。
また、相関関数の導出に際しては、重みWも算出され、相関モデル蓄積手段23に蓄積される。この重みWは、相関関数の誤差補正係数であり、導出した相関関数に負荷を代入して得られる性能パターンと、実際に収集した性能パターンとの差分から算出することができる。
例えば、要素「AP1.CPU」の相関関数は、「y=0.5x+8」として導出することができ、その係数A、Cの値が図6に示すように相関モデル蓄積手段23に蓄積される。
また、相関関数の導出に際しては、重みWも算出され、相関モデル蓄積手段23に蓄積される。この重みWは、相関関数の誤差補正係数であり、導出した相関関数に負荷を代入して得られる性能パターンと、実際に収集した性能パターンとの差分から算出することができる。
「ステップS2:構成変更の指示」
次に、図3のステップS2で示す「構成変更の指示」の処理が行われる。
具体的には、ユーザ等による監視端末1の入力操作により、監視端末1の論理構成エディタ12の画面(図7参照)で、構成変更の指示が入力・指定される。
例えば、APサーバ群に、AP2と言う名前の新規のAPサーバが追加されて、APサーバ層の構成変更(サーバ追加)が指示・入力される。
この指示は、監視制御サーバ2の論理構成管理部26に受け渡され、論理構成データ25に格納される。
構成変更後性能予測手段21には、論理構成データ25を介して、構成変更(サーバ追加)が行われることが通知される。
次に、図3のステップS2で示す「構成変更の指示」の処理が行われる。
具体的には、ユーザ等による監視端末1の入力操作により、監視端末1の論理構成エディタ12の画面(図7参照)で、構成変更の指示が入力・指定される。
例えば、APサーバ群に、AP2と言う名前の新規のAPサーバが追加されて、APサーバ層の構成変更(サーバ追加)が指示・入力される。
この指示は、監視制御サーバ2の論理構成管理部26に受け渡され、論理構成データ25に格納される。
構成変更後性能予測手段21には、論理構成データ25を介して、構成変更(サーバ追加)が行われることが通知される。
「ステップS3:相関の再計算(構成変更後性能モデル生成手段)」
次いで、図3のステップS3で示す「相関の再計算」の処理が行われる。この相関の再計算処理が、上述した構成変更後性能モデル生成手段2cに相当する(図1参照)。
具体的には、構成変更後性能予測手段21は、ステップS2の構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデル(図8参照)を生成する。
例えば、図5及び図6に示すように、構成変更前の性能モデルにおいては、相関関数「y=Ax+C」が成立しており、APサーバを追加したい場合、構成変更後性能予測手段21は、サーバが追加されようとしている層から、既存のサーバを選択し、既存のサーバに成り立っている相関関数「y=Ax+C」を、新規サーバにおいても成り立つとして複製し、サーバ追加後の性能モデルを生成する。
例えば、図9に示すように、APサーバ層の既存サーバである「AP1.CPU」のデータ領域からの相関関数の値、A、C、Wが抽出され、「AP2.CPU」のデータ領域に複製される。
図8に、構成変更(サーバ追加)後の性能項目間に成り立つ相関関係を示す。
次いで、図3のステップS3で示す「相関の再計算」の処理が行われる。この相関の再計算処理が、上述した構成変更後性能モデル生成手段2cに相当する(図1参照)。
具体的には、構成変更後性能予測手段21は、ステップS2の構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデル(図8参照)を生成する。
例えば、図5及び図6に示すように、構成変更前の性能モデルにおいては、相関関数「y=Ax+C」が成立しており、APサーバを追加したい場合、構成変更後性能予測手段21は、サーバが追加されようとしている層から、既存のサーバを選択し、既存のサーバに成り立っている相関関数「y=Ax+C」を、新規サーバにおいても成り立つとして複製し、サーバ追加後の性能モデルを生成する。
例えば、図9に示すように、APサーバ層の既存サーバである「AP1.CPU」のデータ領域からの相関関数の値、A、C、Wが抽出され、「AP2.CPU」のデータ領域に複製される。
図8に、構成変更(サーバ追加)後の性能項目間に成り立つ相関関係を示す。
「ステップS4:新たなボトルネックの探索(ボトルネック予測手段)」
さらに、図3のステップS4で示す「新たなボトルネックの探索」の処理が行われる。この新たなボトルネックの探索処理が、上述したボトルネック予測手段2aに相当する(図1参照)。
具体的には、構成変更後性能予測手段21は、構成変更後の性能モデルに基づいて、構成変更に伴う2次的なボトルネックの発生を検出・予測する。
性能モデルを用いたボトルネックの検出は、例えば、性能モデルである相関関数の変数に要求値(例えば、本実施形態では要求負荷)を代入し、得られた性能値が所定の閾値を超えているか否かに基づいて検出することができる。
以下、具体的なボトルネックの検出方法について説明する。
さらに、図3のステップS4で示す「新たなボトルネックの探索」の処理が行われる。この新たなボトルネックの探索処理が、上述したボトルネック予測手段2aに相当する(図1参照)。
具体的には、構成変更後性能予測手段21は、構成変更後の性能モデルに基づいて、構成変更に伴う2次的なボトルネックの発生を検出・予測する。
性能モデルを用いたボトルネックの検出は、例えば、性能モデルである相関関数の変数に要求値(例えば、本実施形態では要求負荷)を代入し、得られた性能値が所定の閾値を超えているか否かに基づいて検出することができる。
以下、具体的なボトルネックの検出方法について説明する。
図10に示すように、スケールアウト型サーバシステムにおける同種類のサーバの負荷は均一に分散する。従って、例えばAPサーバが1台から2台に増えると、各APサーバにかかる負荷は半分に減少する。
ユーザは、監視端末1を介して、図11に示すような画面において、所望の負荷(ワークロード)として、例えば「300/sec」と所望の要求データを入力することができる。
構成変更後性能予測手段21は、入力された所望の負荷を上限とし、段階的に負荷を増加しながらボトルネックの検出を行う。
例えば、図12及び図13に示すように、「100/sec」から開始し、段階的に「10/sec」ずつ増やしながらボトルネックの検出を行う。
ユーザは、監視端末1を介して、図11に示すような画面において、所望の負荷(ワークロード)として、例えば「300/sec」と所望の要求データを入力することができる。
構成変更後性能予測手段21は、入力された所望の負荷を上限とし、段階的に負荷を増加しながらボトルネックの検出を行う。
例えば、図12及び図13に示すように、「100/sec」から開始し、段階的に「10/sec」ずつ増やしながらボトルネックの検出を行う。
ここで、所望の負荷W’に対して各サーバの性能値を計算する場合には、
y=A・W’・サーバ追加係数+C
とすればよい。(ただし、重みWによる補正は省略)
サーバ追加係数とは、サーバのグループ毎に、
サーバ追加前の台数/サーバ追加後の台数
を計算することで得られる。
この方法にしたがい、全ての性能項目に関して計算を行う。
例えば、APサーバの性能値を計算する場合には、
y=A・W’/2+C
とすればよい。
同様にWEBサーバ及びDBサーバの性能値を計算する場合には、
y=A・W’+C
とすればよい。
y=A・W’・サーバ追加係数+C
とすればよい。(ただし、重みWによる補正は省略)
サーバ追加係数とは、サーバのグループ毎に、
サーバ追加前の台数/サーバ追加後の台数
を計算することで得られる。
この方法にしたがい、全ての性能項目に関して計算を行う。
例えば、APサーバの性能値を計算する場合には、
y=A・W’/2+C
とすればよい。
同様にWEBサーバ及びDBサーバの性能値を計算する場合には、
y=A・W’+C
とすればよい。
「ステップS5:判断」
図3のステップS5で示す判断処理が行われる。
この処理ステップでは、ボトルネックが検出されたか否かが判断される。
例えば、図13に示すように、ユーザが負荷=300を設定したところ、負荷が220で、DBサーバに性能の飽和が発生している。
この場合、図14に示すように、結果表示画面において、サーバ追加後のシステムにおいて最初にボトルネックとなるサーバを表示する。
このようにして、APサーバ以外に発生する2次的なボトルネックの発生を、APサーバを追加する前に確認することが可能となる。
図3のステップS5で示す判断処理が行われる。
この処理ステップでは、ボトルネックが検出されたか否かが判断される。
例えば、図13に示すように、ユーザが負荷=300を設定したところ、負荷が220で、DBサーバに性能の飽和が発生している。
この場合、図14に示すように、結果表示画面において、サーバ追加後のシステムにおいて最初にボトルネックとなるサーバを表示する。
このようにして、APサーバ以外に発生する2次的なボトルネックの発生を、APサーバを追加する前に確認することが可能となる。
「ステップS6:警告」
次に、図3のステップS6で示す「警告」の処理が行われる。
上述したステップS5の処理によりボトルネックの発生が予測された場合は、ユーザに警告を促すことができる。
これは、例えば一種類のサーバの追加だけでは所望のスループットは補えず、他種のサーバの追加も同時に考慮すべきであるからである。
具体的には、上述した例によれば、APサーバの負荷がサーバ追加により軽減されたことにより、APサーバのグループでは所望の負荷を処理することが可能と判断できる一方で、DBサーバについては要求される負荷を満たせないことが理解できる。
従って、このような場合には、所定の警告処理が実行され、監視端末1を操作するユーザに対して警告が促されることになる。
次に、図3のステップS6で示す「警告」の処理が行われる。
上述したステップS5の処理によりボトルネックの発生が予測された場合は、ユーザに警告を促すことができる。
これは、例えば一種類のサーバの追加だけでは所望のスループットは補えず、他種のサーバの追加も同時に考慮すべきであるからである。
具体的には、上述した例によれば、APサーバの負荷がサーバ追加により軽減されたことにより、APサーバのグループでは所望の負荷を処理することが可能と判断できる一方で、DBサーバについては要求される負荷を満たせないことが理解できる。
従って、このような場合には、所定の警告処理が実行され、監視端末1を操作するユーザに対して警告が促されることになる。
「ステップS7:構成変更の実施」
さらに、図3のSステップS7で示す「構成変更の実施」の処理が行われる。
上述したステップS5の処理によりボトルネックが無いことが確認できた場合には、実際に構成の変更が実施される。
以上のステップを経ることにより、構成変更に伴う2次的なボトルネックを発生させることなく、適切な構成変更を実施することが可能となる。
さらに、図3のSステップS7で示す「構成変更の実施」の処理が行われる。
上述したステップS5の処理によりボトルネックが無いことが確認できた場合には、実際に構成の変更が実施される。
以上のステップを経ることにより、構成変更に伴う2次的なボトルネックを発生させることなく、適切な構成変更を実施することが可能となる。
以上説明したように、本実施形態の監視制御システム及び監視制御サーバによれば、スケールアウト型サーバシステムを構成する複数の被監視制御サーバ3に接続され、複数の被監視制御サーバ3を監視制御する監視制御サーバ2を備え、監視制御サーバ2が、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を予測するので、2次的なボトルネックの発生を回避しつつ、適切な構成変更を実施することができる。
監視制御サーバ2は、複数の被監視制御サーバ3から収集した性能情報に基づいて、スケールアウト型サーバシステムの性能をモデル化し、スケールアウト型サーバシステムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成し、構成変更後の性能モデルに基づいて、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックの発生を予測するので、構成変更に伴う2次的なボトルネックの発生を、構成変更前の性能モデルを踏まえて正確に予測することができる。
また、監視制御サーバ2は、複数の被監視制御サーバ3から収集した性能情報と、スケールアウト型サーバシステムの負荷情報に基づいて、各被監視制御サーバ2の性能を、負荷を変数とする相関関数にモデル化するので、要求負荷に対する各被監視制御サーバ2の性能を容易に算出し、ボトルネックを検出することができる。
また、監視制御サーバ2は、スケールアウト型サーバシステムの構成変更指示に応じて、追加される被監視制御サーバ3と同種の被監視制御サーバ3を既存の被監視制御サーバ3から選択し、当該既存の被監視制御サーバ3の相関関数を、追加される被監視制御サーバ3の相関関数として複製するので、構成変更後の性能モデルを容易に生成することができる。
また、監視制御サーバ2は、スケールアウト型サーバシステムの構成変更指示に応じて、追加される被監視制御サーバ3と同種の被監視制御サーバ3を既存の被監視制御サーバ3から選択し、当該既存の被監視制御サーバ3の相関関数を、追加される被監視制御サーバ3の相関関数として複製するので、構成変更後の性能モデルを容易に生成することができる。
また、監視制御サーバ2は、構成変更後の性能モデルである各被監視制御サーバ3の相関関数に所定の負荷を代入し、その出力が所定の閾値を超えている被監視制御サーバ3が、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックであると予測するので、簡単な計算処理でボトルネックの検出を行うことができる。
さらに、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックを予測する際、相関関数に代入する負荷が任意に指定されるので、ユーザは、様々な負荷を入力して構成変更に伴う2次的なボトルネックを予測し、適切な構成変更を行うことができる。
さらに、スケールアウト型サーバシステムの構成変更に伴う2次的なボトルネックを予測する際、相関関数に代入する負荷が任意に指定されるので、ユーザは、様々な負荷を入力して構成変更に伴う2次的なボトルネックを予測し、適切な構成変更を行うことができる。
以上、本発明について、一実施形態を示して説明したが、本発明は、上述した実施形態にのみ限定されるものではなく、特許請求の範囲内で種々の変更が可能であることは言うまでもない。
例えば、上述した実施形態では、被監視制御サーバに設けられるサーバとして、WEBサーバ、AP(アプリケーション)サーバ、DB(データベース)サーバの3種類のサーバを例にとって説明したが、本発明により監視制御の対象となるサーバの種類や数等は特に上述した実施形態の場合に限定されるものではない。
例えば、上述した実施形態では、被監視制御サーバに設けられるサーバとして、WEBサーバ、AP(アプリケーション)サーバ、DB(データベース)サーバの3種類のサーバを例にとって説明したが、本発明により監視制御の対象となるサーバの種類や数等は特に上述した実施形態の場合に限定されるものではない。
本発明は、スケールアウト型サーバシステムを監視制御する監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラムとして利用することができる。
1 監視端末
11 性能情報表示部
12 論理構成エディタ
2 監視制御サーバ
21 構成変更後性能予測手段
23 相関モデル蓄積手段
24 相関検出部
25 論理構成データ
26 論理構成管理部
27 監視装置
28 性能情報蓄積手段
29 制御装置
3 被監視制御サーバ
31 監視制御エージェント
11 性能情報表示部
12 論理構成エディタ
2 監視制御サーバ
21 構成変更後性能予測手段
23 相関モデル蓄積手段
24 相関検出部
25 論理構成データ
26 論理構成管理部
27 監視装置
28 性能情報蓄積手段
29 制御装置
3 被監視制御サーバ
31 監視制御エージェント
Claims (9)
- システムを構成する複数のサーバに接続され、複数の前記サーバを監視する監視サーバを備え、
前記監視サーバが、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段と、を備える
ことを特徴とする監視制御システム。 - 前記監視サーバが、
構成変更後の性能モデルに基づいて、前記システムの構成変更に伴う2次的なボトルネックの発生を予測するボトルネック予測手段を備える
ことを特徴とする請求項1記載の監視制御システム。 - 前記性能モデル化手段が、
複数の前記サーバから収集した性能情報と、前記システムの負荷情報に基づいて、各サーバの性能を、負荷を変数とする相関関数にモデル化する
ことを特徴とする請求項2記載の監視制御システム。 - 前記構成変更後性能モデル生成手段が、
前記システムの構成変更指示に応じて、追加されるサーバと同種のサーバを既存のサーバから選択し、当該既存のサーバの相関関数を、追加されるサーバの相関関数として複製する
ことを特徴とする請求項3記載の監視制御システム。 - 前記ボトルネック予測手段が、
構成変更後の性能モデルである各サーバの相関関数に所定の負荷を代入し、その出力が所定の閾値を超えているサーバが、前記システムの構成変更に伴う2次的なボトルネックであると予測する
ことを特徴とする請求項4記載の監視制御システム。 - 前記システムの構成変更に伴う2次的なボトルネックを予測する際、相関関数に代入する負荷が任意に指定される
ことを特徴とする請求項5記載の監視制御システム。 - システムを構成する複数のサーバに、複数の前記サーバを監視する監視サーバを接続し、
前記監視サーバが、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化し、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する
ことを特徴とする監視制御方法。 - システムを構成する複数のサーバに接続され、複数の前記サーバを監視制御するにあたり、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化する性能モデル化手段と、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成する構成変更後性能モデル生成手段と、を備える
ことを特徴とする監視制御サーバ。 - システムを構成する複数のサーバに接続され、複数の前記サーバを監視制御するコンピュータに、
複数の前記サーバから収集した性能情報に基づいて、各サーバの性能をモデル化させ、
前記システムの構成変更指示に応じて、構成変更前の性能モデルから構成変更後の性能モデルを生成させる
ことを特徴とする監視制御プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013149251A JP5500301B2 (ja) | 2013-07-18 | 2013-07-18 | 監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013149251A JP5500301B2 (ja) | 2013-07-18 | 2013-07-18 | 監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009084102A Division JP5321195B2 (ja) | 2009-03-31 | 2009-03-31 | 監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2013242899A true JP2013242899A (ja) | 2013-12-05 |
JP5500301B2 JP5500301B2 (ja) | 2014-05-21 |
Family
ID=49843647
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013149251A Active JP5500301B2 (ja) | 2013-07-18 | 2013-07-18 | 監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5500301B2 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017064779A1 (ja) * | 2015-10-14 | 2017-04-20 | 株式会社日立製作所 | 計算機システム、管理計算機、及び、クラスタ制御方法 |
JP2020177581A (ja) * | 2019-04-22 | 2020-10-29 | 株式会社日立製作所 | トポロジマップ提示システム、トポロジマップ提示方法及びコンピュータプログラム |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09311782A (ja) * | 1996-03-14 | 1997-12-02 | Internatl Business Mach Corp <Ibm> | パフォーマンスの予測を行うための機構および方法 |
JP2002342182A (ja) * | 2001-05-21 | 2002-11-29 | Hitachi Ltd | ネットワークシステムにおける運用管理の支援システム |
JP2005327261A (ja) * | 2004-04-16 | 2005-11-24 | Ns Solutions Corp | 性能監視装置、性能監視方法及びプログラム |
JP2008171235A (ja) * | 2007-01-12 | 2008-07-24 | Nec Corp | システム構成変更ルール生成システム、方法およびプログラム |
-
2013
- 2013-07-18 JP JP2013149251A patent/JP5500301B2/ja active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09311782A (ja) * | 1996-03-14 | 1997-12-02 | Internatl Business Mach Corp <Ibm> | パフォーマンスの予測を行うための機構および方法 |
JP2002342182A (ja) * | 2001-05-21 | 2002-11-29 | Hitachi Ltd | ネットワークシステムにおける運用管理の支援システム |
JP2005327261A (ja) * | 2004-04-16 | 2005-11-24 | Ns Solutions Corp | 性能監視装置、性能監視方法及びプログラム |
JP2008171235A (ja) * | 2007-01-12 | 2008-07-24 | Nec Corp | システム構成変更ルール生成システム、方法およびプログラム |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017064779A1 (ja) * | 2015-10-14 | 2017-04-20 | 株式会社日立製作所 | 計算機システム、管理計算機、及び、クラスタ制御方法 |
JP2020177581A (ja) * | 2019-04-22 | 2020-10-29 | 株式会社日立製作所 | トポロジマップ提示システム、トポロジマップ提示方法及びコンピュータプログラム |
JP7166982B2 (ja) | 2019-04-22 | 2022-11-08 | 株式会社日立製作所 | トポロジマップ提示システム、トポロジマップ提示方法及びコンピュータプログラム |
Also Published As
Publication number | Publication date |
---|---|
JP5500301B2 (ja) | 2014-05-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10652119B2 (en) | Automatic recovery engine with continuous recovery state machine and remote workflows | |
KR20190070659A (ko) | 컨테이너 기반의 자원 할당을 지원하는 클라우드 컴퓨팅 장치 및 방법 | |
JP5729466B2 (ja) | 仮想マシン管理装置、仮想マシン管理方法、及び、プログラム | |
US20120084788A1 (en) | Complex event distributing apparatus, complex event distributing method, and complex event distributing program | |
JP5321195B2 (ja) | 監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム | |
CN111443870B (zh) | 一种数据处理的方法、设备及存储介质 | |
EP2645635B1 (en) | Cluster monitor, method for monitoring a cluster, and computer-readable recording medium | |
TW201347459A (zh) | 管理方法及其系統 | |
CN112948063A (zh) | 云平台的创建方法、装置、云平台以及云平台实现系统 | |
JP2017138895A (ja) | 仮想化環境管理システムおよび仮想化環境管理方法 | |
CN110998535A (zh) | 经由对应用操作请求的分析来恢复应用功能 | |
WO2015141218A1 (ja) | 情報処理装置、解析方法、及び、プログラム記録媒体 | |
CN115167992A (zh) | 任务处理方法、系统、装置、服务器、介质及程序产品 | |
JP5500301B2 (ja) | 監視制御システム、監視制御方法、監視制御サーバ及び監視制御プログラム | |
Mohammed et al. | An integrated virtualized strategy for fault tolerance in cloud computing environment | |
US20220229689A1 (en) | Virtualization platform control device, virtualization platform control method, and virtualization platform control program | |
CN105511952A (zh) | 基于云计算平台的资源自迁移方法及系统 | |
JP6059259B2 (ja) | 計算機システム及び計算機リソースの割当方法 | |
JP5443686B2 (ja) | 情報処理装置、情報処理方法及びプログラム | |
Wang et al. | An adaptive elasticity policy for staging based in-situ processing | |
Mondal et al. | Energy modeling of virtual machine replication schemes with checkpointing in data centers | |
JP6555131B2 (ja) | 並列処理装置、ジョブ監視方法及びジョブ監視プログラム | |
KR102672580B1 (ko) | 비정상 이벤트에 대한 가상 머신의 처리 용량 증가 | |
CN108984271A (zh) | 一种均衡负载的方法以及相关设备 | |
Salapura et al. | Virtual Machine Resiliency Management System for the Cloud |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140212 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140225 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5500301 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |