JP2012008935A - 分散サーバシステムの状態推定装置 - Google Patents
分散サーバシステムの状態推定装置 Download PDFInfo
- Publication number
- JP2012008935A JP2012008935A JP2010146384A JP2010146384A JP2012008935A JP 2012008935 A JP2012008935 A JP 2012008935A JP 2010146384 A JP2010146384 A JP 2010146384A JP 2010146384 A JP2010146384 A JP 2010146384A JP 2012008935 A JP2012008935 A JP 2012008935A
- Authority
- JP
- Japan
- Prior art keywords
- node
- state
- soundness
- network
- health
- 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
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
【課題】複数のノードをネットワーク上に配置して処理を行う分散サーバシステムにおいて、各ノードの利用状態の推定を行う装置を得る。
【解決手段】複数のノード30を有する分散サーバシステムにおいて、前記各ノード30の駆動状態を管理する管理ノード10を備え、前記管理ノード10は、前記各ノードの駆動状態を複数のパラメータとして定期的に受信するノードパラメータ受信部11と、前記各ノードパラメータから所定式に基づいて健全度を算出するノード健全度判定部12と、算出した健全度を履歴情報として記録する健全度履歴管理部14と、算出した現在の健全度と健全度履歴によりノード状態を判定するノード状態判定部13を備えることで状態推定装置を構成する。
【選択図】図2
【解決手段】複数のノード30を有する分散サーバシステムにおいて、前記各ノード30の駆動状態を管理する管理ノード10を備え、前記管理ノード10は、前記各ノードの駆動状態を複数のパラメータとして定期的に受信するノードパラメータ受信部11と、前記各ノードパラメータから所定式に基づいて健全度を算出するノード健全度判定部12と、算出した健全度を履歴情報として記録する健全度履歴管理部14と、算出した現在の健全度と健全度履歴によりノード状態を判定するノード状態判定部13を備えることで状態推定装置を構成する。
【選択図】図2
Description
本発明は、複数のノードをネットワーク上に配置してディスクを共有する分散サーバシステムに関し、特に、障害の発生等を未然に防止するために、システムにおけるノード等の利用状態を把握するための状態推定装置に関する。
分散サーバシステムは、ネットワークを介して散在する複数のコンピュータのディレクトリ、もしくはファイルを仮想的に統合して利用するための技術である。この種の技術としては、非特許文献1や非特許文献2で示されるように、複数のマシンのディスクを組み合わせて1つのファイルシステムとして機能する分散プラットフォームが提案されている。
非特許文献1に示されたGfarmは、広域ネットワーク上で、大容量、大規模データ処理の要求に応えるスケーラブルな分散ファイルシステムプラットフォームであり、広域なネットワーク上での効率的なファイル共有に適した分散プラットフォームである。
一方、非特許文献2に示されたHadoopは、1つのディスクで保存できない大量のデータを並列化することで高速かつ効率良く処理できるものであり、比較的大きなサイズかつ基本的に更新されることのないファイルのI/Oに適した分散プラットフォームである。
一方、非特許文献2に示されたHadoopは、1つのディスクで保存できない大量のデータを並列化することで高速かつ効率良く処理できるものであり、比較的大きなサイズかつ基本的に更新されることのないファイルのI/Oに適した分散プラットフォームである。
また、特許文献1には、コンピュータシステムにおける障害発生イベントの検出を支援する方法が提案されている。
URL:http://datafarm.apgrid.org/index.ja.html
URL:http://hadoop.apache.org/
従来、分散ファイルシステムにおいて、サーバやシステムがどのような状態かを判断するには、複数の監視項目と分散サーバシステムの仕組みや構成について知識がないと難しいため、運用者が簡単に判断できないという問題があった。
分散サーバシステムは故障を許容するシステムであり、利用状況を監視することで故障の有無の判断は可能であるがどのような対処が必要かの判断が難しい。
また、特許文献1には、障害の発生を検出することはできるが、障害発生に至る前段階における状態を検知することができない。
分散サーバシステムは故障を許容するシステムであり、利用状況を監視することで故障の有無の判断は可能であるがどのような対処が必要かの判断が難しい。
また、特許文献1には、障害の発生を検出することはできるが、障害発生に至る前段階における状態を検知することができない。
本発明は上記事情に鑑みて提案されたもので、複数のノードをネットワーク上に配置して処理を行う分散サーバシステムにおいて、ノードやシステムの利用状態の推定を行う分散サーバシステムにおける状態推定装置を提供することを目的とする。
上記目的を達成するため本発明の分散サーバシステムにおける状態推定装置は、複数のノードをネットワーク上に配置し処理を行うシステムにおいて、各ノードから複数のパラメータを取得し、ノードやシステムの状態の推定を行うものである。
すなわち、請求項1は、複数のノードを有する分散サーバシステムにおいて、前記各ノードの駆動状態を管理する管理ノードを備え、前記管理ノードが次の構成を含むことを特徴としている。
ノードパラメータ受信部。このノードパラメータ受信部は、前記各ノードの駆動状態を複数のパラメータとして定期的に受信するものである。
ノード健全度判定部。このノード健全度判定部は、前記各ノードパラメータから所定式に基づいて健全度を算出するものである。
健全度履歴管理部。この健全度履歴管理部は、算出した健全度を履歴情報として記録するものである。
ノード状態判定部。このノード状態判定部は、算出した現在の健全度と健全度履歴によりノード状態を判定するものである。
ノードパラメータ受信部。このノードパラメータ受信部は、前記各ノードの駆動状態を複数のパラメータとして定期的に受信するものである。
ノード健全度判定部。このノード健全度判定部は、前記各ノードパラメータから所定式に基づいて健全度を算出するものである。
健全度履歴管理部。この健全度履歴管理部は、算出した健全度を履歴情報として記録するものである。
ノード状態判定部。このノード状態判定部は、算出した現在の健全度と健全度履歴によりノード状態を判定するものである。
請求項2は、請求項1の分散サーバシステムの状態推定装置において、複数のノード毎にネットワークを設定して管理するネットワーク設定部と、前記ノード健全度判定部で算出した健全度を受信するノード健全度受信部と、前記ネットワーク設定部で設定されたネットワーク毎に健全度を算出するネットワーク健全度判定部と、算出した現在の健全度と健全度履歴によりネットワーク状態を判定するネットワーク状態判定部とを更に備えたことを特徴としている。
請求項3は、請求項2の分散サーバシステムの状態推定装置において、前記ネットワーク健全度判定部で算出した健全度を受信するネットワーク健全度受信部と、システム全体の健全度を算出するシステム健全度判定部と、算出した現在の健全度と健全度履歴によりシステム状態を判定するシステム状態判定部とを更に備えたことを特徴としている。
本発明によれば、各パラメータから健全度を算出し、健全度の履歴及び現在の健全度からノードの状態を判断するので、障害が発生する前の状態を把握して、ノードやシステムに対する対処の必要性や緊急度を判断でき、簡易な判断で適切な運用を行うことが可能になる。
本発明の分散サーバシステムの状態推定装置の実施形態の一例について、図面を参照しながら説明する。
分散サーバシステムは、図1に示すように、複数のファイルサーバ1から構成されるネットワークA〜Fと、各ネットワークA〜Fを管理する管理サーバ2と、クライアントサーバ3から構成されている。分散サーバシステムは、n個(数量に規定はない)のノード(N1〜Nn)を、管理サーバ2を介してアクセスさせることで、各ノードを意識せず単一のサーバとしてユーザに提供するシステムである。すなわち、分散サーバシステムのファイルサーバ1へは、複数のクライアントサーバ3が管理サーバ2を介してアクセスすることで、データの書込みや読み出し処理が行われる。
分散サーバシステムは、図1に示すように、複数のファイルサーバ1から構成されるネットワークA〜Fと、各ネットワークA〜Fを管理する管理サーバ2と、クライアントサーバ3から構成されている。分散サーバシステムは、n個(数量に規定はない)のノード(N1〜Nn)を、管理サーバ2を介してアクセスさせることで、各ノードを意識せず単一のサーバとしてユーザに提供するシステムである。すなわち、分散サーバシステムのファイルサーバ1へは、複数のクライアントサーバ3が管理サーバ2を介してアクセスすることで、データの書込みや読み出し処理が行われる。
本発明の分散サーバシステムの状態推定装置の詳細構成について、図2を参照して説明する。
分散サーバシステムの状態推定装置は、分散サーバシステムに対して、ノード単体やネットワーク、システムの健全度を判定する管理ノード10を設けることで、ノード、ネットワーク、システムの状態を推定する。管理ノード10において、ノード単体やネットワーク、システムの健全度や状態を判断する際の構成では、ファイルサーバ1、管理サーバ2、クライアントサーバ3は、全てノード30として同等に扱われる。また、ネットワークやシステムの健全度を算出する際には、各ノードの役割に応じた重みづけを行った各健全度から算出するようにしてもよい。
分散サーバシステムの状態推定装置は、分散サーバシステムに対して、ノード単体やネットワーク、システムの健全度を判定する管理ノード10を設けることで、ノード、ネットワーク、システムの状態を推定する。管理ノード10において、ノード単体やネットワーク、システムの健全度や状態を判断する際の構成では、ファイルサーバ1、管理サーバ2、クライアントサーバ3は、全てノード30として同等に扱われる。また、ネットワークやシステムの健全度を算出する際には、各ノードの役割に応じた重みづけを行った各健全度から算出するようにしてもよい。
ノード30は、パラメータ収集部31とパラメータ送信部32を備えている。パラメータ収集部31では、ノード内部の駆動状態に関係する複数の情報源となるパラメータを定期的に収集する。パラメータ送信部32では、収集した複数のパラメータを管理ノード10へ送信する。
管理ノード10は、ノードパラメータ受信部11、ノード健全度判定部12、ノード状態判定部13、ネットワーク設定部14、ノード健全度受信部16、ネットワーク健全度判定部17、ネットワーク状態判定部18、ネットワーク健全度受信部19、システム健全度判定部20、システム状態判定部21、健全度履歴管理部14を備えている。健全度履歴管理部14は、ノード、ネットワーク、システムの健全度を算出する毎に順次格納し履歴を保存する。
ノードパラメータ受信部11では、複数のノード30のパラメータ送信部32から送信されたパラメータを定期的に受信する。ノード健全度判定部12では、受信した各ノードのパラメータから各ノードの健全度を定期的に算出する。健全度の算出は、予め設定された所定式によって求められる。算出の具体例については後述する。また、算出された各ノードの健全度は、健全度履歴管理部14に記憶されて管理される。
ノード状態判定部13では、算出したノードの健全度(暫定状態)と、履歴から取得した直近N個(数量に規定はない)の健全度の平均値(履歴状態)からノードの状態を判定する。Nは、「1」より大きい数とし、予め設定されている。ノード状態の判定は、「正常」「異常」「危険」の3つの状態で行う。具体的な判定方法については後述する。
ノード状態判定部13では、算出したノードの健全度(暫定状態)と、履歴から取得した直近N個(数量に規定はない)の健全度の平均値(履歴状態)からノードの状態を判定する。Nは、「1」より大きい数とし、予め設定されている。ノード状態の判定は、「正常」「異常」「危険」の3つの状態で行う。具体的な判定方法については後述する。
ノード健全度受信部16では、ノード健全度判定部12で算出された各ノードの健全度を受信する。ネットワーク設定部15では、各ネットワークを構成するノードの情報を保持している。ネットワーク健全度判定部17では、ノード健全度受信部16で受信したノードの健全度とネットワーク設定部15から受信したネットワークを構成するノードの情報から、ネットワークの健全度を算出する。ネットワークの健全度は、例えば、ネットワークを構成する各ノードの健全度の平均値に類する値で算出される。具体的な算出の計算式は後述する。算出された各ネットワークの健全度は、健全度履歴管理部14に記憶されて管理される。
ネットワーク状態判定部18では、算出したネットワーク健全度(暫定状態)と履歴のネットワーク健全度(履歴状態)を用いて、現在のネットワークの状態を判定する。
ネットワーク状態判定部18では、算出したネットワーク健全度(暫定状態)と履歴のネットワーク健全度(履歴状態)を用いて、現在のネットワークの状態を判定する。
ネットワーク健全度受信部19では、ネットワークの健全度を受信する。システム健全度判定部20では、全てのネットワーク健全度からシステムの健全度を算出する。システムの健全度は、例えば、システム全体を構成する各ネットワークの健全度の平均値に類する値で算出される。具体的な算出の計算式は後述する。算出されたシステムの健全度は、健全度履歴管理部14に記憶されて管理される。
システム状態判定部21では、算出したシステムの健全度(暫定状態)と、履歴から取得したシステムの健全度(履歴状態)から、現在のシステムの状態を判定する。
システム状態判定部21では、算出したシステムの健全度(暫定状態)と、履歴から取得したシステムの健全度(履歴状態)から、現在のシステムの状態を判定する。
次に、各ノードに対して算出される健全度からノードの状態の推定を行う場合の手順について、図3を参照しながら説明する。
先ず、ノードからのパラメータを収集し(ステップ41)、履歴から今までの状態(直近N個の履歴状態)を取得する(ステップ42)。
次に、ノードから収集したパラメータから健全度を算出し暫定的に現在の状態を決定し(ステップ43)、暫定状態と履歴状態から現在の状態を判断する(ステップ44)。その後、履歴に現在の状態を追加し終了する(ステップ45)。
この処理手順は、サーバ単体のノードにおける状態推定だけでなく、ネットワークやシステムの状態推定にも用いられる。ただし、健全度の判定方法は、サーバ単体、ネットワーク、システムによって算出方法が異なる。具体的な判定方法については後述する。また、健全度とは「0〜1.0」までの範囲をとり、「1」に近いほど健全度が高く0に近いほど健全度が低いとする。
先ず、ノードからのパラメータを収集し(ステップ41)、履歴から今までの状態(直近N個の履歴状態)を取得する(ステップ42)。
次に、ノードから収集したパラメータから健全度を算出し暫定的に現在の状態を決定し(ステップ43)、暫定状態と履歴状態から現在の状態を判断する(ステップ44)。その後、履歴に現在の状態を追加し終了する(ステップ45)。
この処理手順は、サーバ単体のノードにおける状態推定だけでなく、ネットワークやシステムの状態推定にも用いられる。ただし、健全度の判定方法は、サーバ単体、ネットワーク、システムによって算出方法が異なる。具体的な判定方法については後述する。また、健全度とは「0〜1.0」までの範囲をとり、「1」に近いほど健全度が高く0に近いほど健全度が低いとする。
サーバ単体での健全度算出に際して、パラメータとして使用する項目例を表1に示す。
項目としては、ロードアベレージ、ファン回転数、電源、プロセス、HDD容量を設定している。各項目に、異常値と危険値の閾値と、重みを設ける。電源及びプロセスについては、駆動と停止の2通りで閾値は設定されない。状態の係数として、異常値を0.5、危険値を1.0に設定する。重みは、故障頻度が高い項目は小さな値とし、故障頻度が低い項目は大きな値とする。例として、一時的に異常値や危険値を超える可能性が高い項目は重みを低くする。
項目としては、ロードアベレージ、ファン回転数、電源、プロセス、HDD容量を設定している。各項目に、異常値と危険値の閾値と、重みを設ける。電源及びプロセスについては、駆動と停止の2通りで閾値は設定されない。状態の係数として、異常値を0.5、危険値を1.0に設定する。重みは、故障頻度が高い項目は小さな値とし、故障頻度が低い項目は大きな値とする。例として、一時的に異常値や危険値を超える可能性が高い項目は重みを低くする。
ロードアベレージとは、実行プロセス数の平均である。ファン回転数とは、CPUのファン回転数を指す。プロセスとは、対象とするノードが分散サーバシステムの一部として使用可能なように動作しているプログラムを指す。例えば、Gfarmだとgfmdやgfsd、HadoopだとNameNodeやDataNodeなどである。
ノードの健全度の算出例として、次の計算式を用いる。
1−(Σ(項目1の重み×状態の係数)/全項目の重みの合計)
ロードアベレージが4でかつHDD容量が80%であった場合のサーバの健全度を算出すると、
1−((3*0.5 + 2*0+ 5*0+ 4*0 + 1*0.5 ) / 3+2+5+4+1) ≒ 0.83
となる。
また、項目例としては、表1で例示したものの他に、CPU温度等も考えられる。
1−(Σ(項目1の重み×状態の係数)/全項目の重みの合計)
ロードアベレージが4でかつHDD容量が80%であった場合のサーバの健全度を算出すると、
1−((3*0.5 + 2*0+ 5*0+ 4*0 + 1*0.5 ) / 3+2+5+4+1) ≒ 0.83
となる。
また、項目例としては、表1で例示したものの他に、CPU温度等も考えられる。
ネットワークとシステムの健全度算出例について、表2のようなシステム構成である場合を例に説明する。
表2では、ノード単体の健全度、ノードが所属するネットワークを示している。
表2では、ノード単体の健全度、ノードが所属するネットワークを示している。
ネットワークを構成するノード数がnである場合のネットワークの健全度の算出例として、次の計算式を用いる。
1−(Σ((1−健全度n)*(健全度nのサーバ数/ネットワークの全サーバ数)))
これを基に表2におけるネットワーク1(NW1)の健全度を計算すると、
1-((1-0.9)*(2/6)+(1-0.8)*(1/6)+(1-0.4)*(1/6))≒0.83
となる。
1−(Σ((1−健全度n)*(健全度nのサーバ数/ネットワークの全サーバ数)))
これを基に表2におけるネットワーク1(NW1)の健全度を計算すると、
1-((1-0.9)*(2/6)+(1-0.8)*(1/6)+(1-0.4)*(1/6))≒0.83
となる。
また、システムを構成するネットワーク数がNである場合のシステムの健全度の算出例として、次の計算式を用いる。
1−(Σ((1-ネットワークNの健全度)*(ネットワークNに存在するサーバ数/システムに存在するサーバ数)))
これを基に表2のシステムの健全度を算出すると、
1-((1-0.83)*6/9+(1-0.97)*3/9)=0.88
となる。
1−(Σ((1-ネットワークNの健全度)*(ネットワークNに存在するサーバ数/システムに存在するサーバ数)))
これを基に表2のシステムの健全度を算出すると、
1-((1-0.83)*6/9+(1-0.97)*3/9)=0.88
となる。
次に、算出した健全度からノードやネットワーク、システムの状態判定を行う場合の手順について、図4を参照して説明する。
状態判定については、「正常」「異常」「危険」の3つの分類で状態の判定を行う。
先ず、ノード、ネットワーク、システムのいずれかを対象とし健全度を算出し、暫定の状態を決定する(ステップ51)。
次に、履歴から直近N個の健全度の平均値を取得し履歴の状態を決定する(ステップ52)。
状態判定については、「正常」「異常」「危険」の3つの分類で状態の判定を行う。
先ず、ノード、ネットワーク、システムのいずれかを対象とし健全度を算出し、暫定の状態を決定する(ステップ51)。
次に、履歴から直近N個の健全度の平均値を取得し履歴の状態を決定する(ステップ52)。
その後、暫定の状態と履歴の状態から現在の状態を決定する。状態の決定方法は次のようにして行う。
暫定状態が危険かどうか(ステップ53)、履歴状態が危険かどうか(ステップ54)をそれぞれ判断する。危険かどうかの判断は、健全度が危険閾値より小さいかどうかで判断する。
暫定状態が危険でかつ履歴状態も危険な場合、現在の状態を危険とし(ステップ55)、現在の状態を履歴に追加する(ステップ56)。
暫定状態が危険かどうか(ステップ53)、履歴状態が危険かどうか(ステップ54)をそれぞれ判断する。危険かどうかの判断は、健全度が危険閾値より小さいかどうかで判断する。
暫定状態が危険でかつ履歴状態も危険な場合、現在の状態を危険とし(ステップ55)、現在の状態を履歴に追加する(ステップ56)。
暫定状態が危険で履歴状態が危険でない場合、履歴状態が異常かどうか(ステップ57)を判断し、履歴状態が異常である場合、現在の状態を危険とし(ステップ58)、現在の状態を履歴に追加する(ステップ56)。履歴状態が異常でない場合は、現在の状態を異常とし(ステップ59)、現在の状態を履歴に追加する(ステップ56)。異常かどうかの判断は、健全度が異常閾値より小さい(危険閾値より大きい値)かどうかで判断する。
暫定状態が危険でない場合(ステップ53)、暫定状態が異常か(ステップ60)、履歴状態が危険かをそれぞれ判断し(ステップ61)、暫定状態が異常で履歴状態が危険な場合は、現在の状態を危険とし(ステップ62)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が危険でない場合は(ステップ61)、履歴状態が異常かを判断し(ステップ63)、履歴状態が異常な場合は、現在の状態を異常とし(ステップ64)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が異常でない場合(ステップ63)、現在の状態を正常とし(ステップ65)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が危険でない場合は(ステップ61)、履歴状態が異常かを判断し(ステップ63)、履歴状態が異常な場合は、現在の状態を異常とし(ステップ64)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が異常でない場合(ステップ63)、現在の状態を正常とし(ステップ65)、現在の状態を履歴に追加する(ステップ56)。
暫定状態が異常でない場合は(ステップ60)、履歴状態が危険かを判断し(ステップ66)、履歴状態が危険な場合は、現在の状態を異常とし(ステップ67)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が危険でない場合(ステップ66)、履歴状態が異常かを判断し(ステップ68)、履歴状態が異常な場合は、現在の状態を異常とし(ステップ69)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が異常でない場合(ステップ68)、現在の状態を正常とし(ステップ70)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が危険でない場合(ステップ66)、履歴状態が異常かを判断し(ステップ68)、履歴状態が異常な場合は、現在の状態を異常とし(ステップ69)、現在の状態を履歴に追加する(ステップ56)。
履歴状態が異常でない場合(ステップ68)、現在の状態を正常とし(ステップ70)、現在の状態を履歴に追加する(ステップ56)。
上述した分散サーバシステムの状態推定装置によれば、現在(暫定状態)及び過去(履歴状態)の健全度からサーバ単体、ネットワーク、システムの状態を把握することができる。
危険な状態であると判断された場合には、ノード等の停止を行うことで障害の発生を未然に防止することができる。
また、危険な状態ではないが異常な状態(例えば、高負荷な状態が続いている、又は、ネットワーク遅延が増大している)を検知することが可能になるため、それに応じた対策を講じることでシステムのパフォーマンス低下を防ぐことができる。
また、ノード、ネットワーク、システムの状態を常に監視するため、故障発生時の原因特定をより短時間で行うことができる。
危険な状態であると判断された場合には、ノード等の停止を行うことで障害の発生を未然に防止することができる。
また、危険な状態ではないが異常な状態(例えば、高負荷な状態が続いている、又は、ネットワーク遅延が増大している)を検知することが可能になるため、それに応じた対策を講じることでシステムのパフォーマンス低下を防ぐことができる。
また、ノード、ネットワーク、システムの状態を常に監視するため、故障発生時の原因特定をより短時間で行うことができる。
1…ファイルサーバ(ノード)、 2…管理サーバ(ノード)、 3…クライアントサーバ(ノード)、 10…管理ノード、 11…ノードパラメータ受信部、 12…ノード健全度判定部、 13…ノード状態判定部、 14…健全度履歴管理部、 15…ネットワーク設定部、 16…ノード健全度受信部、 17…ネットワーク健全度判定部、 18…ネットワーク状態判定部、 19…ネットワーク健全度受信部、 20…システム健全度判定部、 21…システム状態判定部。 30…ノード、 31…パラメータ収集部、 32…パラメータ送信部。
Claims (3)
- 複数のノードを有する分散サーバシステムにおいて、
前記各ノードの駆動状態を管理する管理ノードを備え、
前記管理ノードは、
前記各ノードの駆動状態を複数のパラメータとして定期的に受信するノードパラメータ受信部と、
前記各ノードパラメータから所定式に基づいて健全度を算出するノード健全度判定部と、
算出した健全度を履歴情報として記録する健全度履歴管理部と、
算出した現在の健全度と健全度履歴によりノード状態を判定するノード状態判定部と、
を具備する分散サーバシステムの状態推定装置。 - 複数のノード毎にネットワークを設定して管理するネットワーク設定部と、
前記ノード健全度判定部で算出した健全度を受信するノード健全度受信部と、
前記ネットワーク設定部で設定されたネットワーク毎に健全度を算出するネットワーク健全度判定部と、
算出した現在の健全度と健全度履歴によりネットワーク状態を判定するネットワーク状態判定部と
を更に備えた請求項1に記載の分散サーバシステムの状態推定装置。 - 前記ネットワーク健全度判定部で算出した健全度を受信するネットワーク健全度受信部と、
システム全体の健全度を算出するシステム健全度判定部と、
算出した現在の健全度と健全度履歴によりシステム状態を判定するシステム状態判定部と
を更に備えた請求項2に記載の分散サーバシステムの状態推定装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010146384A JP2012008935A (ja) | 2010-06-28 | 2010-06-28 | 分散サーバシステムの状態推定装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010146384A JP2012008935A (ja) | 2010-06-28 | 2010-06-28 | 分散サーバシステムの状態推定装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2012008935A true JP2012008935A (ja) | 2012-01-12 |
Family
ID=45539368
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010146384A Pending JP2012008935A (ja) | 2010-06-28 | 2010-06-28 | 分散サーバシステムの状態推定装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2012008935A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013108584A1 (en) | 2012-01-19 | 2013-07-25 | Canon Kabushiki Kaisha | Actuator and movable mirror |
JP2020178338A (ja) * | 2019-04-15 | 2020-10-29 | 富士通株式会社 | ブロックチェーンネットワークをチェックする装置 |
-
2010
- 2010-06-28 JP JP2010146384A patent/JP2012008935A/ja active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013108584A1 (en) | 2012-01-19 | 2013-07-25 | Canon Kabushiki Kaisha | Actuator and movable mirror |
JP2020178338A (ja) * | 2019-04-15 | 2020-10-29 | 富士通株式会社 | ブロックチェーンネットワークをチェックする装置 |
JP7322723B2 (ja) | 2019-04-15 | 2023-08-08 | 富士通株式会社 | ブロックチェーンネットワークをチェックする装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5267684B2 (ja) | 運用管理装置、運用管理方法、及びプログラム記憶媒体 | |
US11212208B2 (en) | Adaptive metric collection, storage, and alert thresholds | |
CN108874640B (zh) | 一种集群性能的评估方法和装置 | |
EP3346650B1 (en) | Network monitoring system, network monitoring method, and program | |
EP2685380B1 (en) | Operations management unit, operations management method, and program | |
JP6438035B2 (ja) | ラックスケールアーキテクチャコンピューティングシステムのためのワークロード最適化、スケジューリング及び配置 | |
US8056082B2 (en) | Capacity management and predictive planning systems based on trended rate change of monitored factors and methods thereof | |
US20120030346A1 (en) | Method for inferring extent of impact of configuration change event on system failure | |
US20150280969A1 (en) | Multi-hop root cause analysis | |
US20110320228A1 (en) | Automated Generation of Markov Chains for Use in Information Technology | |
JP6246357B2 (ja) | 建物管理装置、広域管理システム、データ取得方法、及びプログラム | |
Jassas et al. | Failure analysis and characterization of scheduling jobs in google cluster trace | |
JP2011175357A5 (ja) | 管理装置及び管理プログラム | |
WO2015009405A1 (en) | Systems and methods for filtering low utility value messages from system logs | |
WO2014101093A1 (en) | Power optimization for distributed computing system | |
EP3338191A1 (en) | Diagnostic framework in computing systems | |
US10176033B1 (en) | Large-scale event detector | |
US10599204B1 (en) | Performance efficiency monitoring system | |
JP2012008935A (ja) | 分散サーバシステムの状態推定装置 | |
US20210140664A1 (en) | Continuous Monitoring for Early Failure Detection in Climate Control Systems | |
JP2012181744A (ja) | 分散ファイルシステムにおける運用監視システム及び運用監視方法 | |
JP2010198579A (ja) | 異常検出システム、異常検出方法および異常検出用プログラム | |
US8769088B2 (en) | Managing stability of a link coupling an adapter of a computing system to a port of a networking device for in-band data communications | |
Sloss et al. | Metrics that matter | |
JP2019079120A (ja) | 情報処理装置、情報処理方法、及びプログラム |