情報処理システム運用管理装置、運用管理方法及び運用管理プログラム
【課題】
並列分散処理システム、例えばＭａｐＲｅｄｕｃｅ方式のように、複数の情報処理装置から取得した監視データを基に障害検知を行おうとしても、どの装置の間に相関関係が生じるかが事前に決定できない。また、稼働中に相関関係が生じる組み合わせが変化するようなシステムにおいて、障害の検知を行う。
【解決手段】
複数の情報処理装置が協調して動作する情報処理システムを運用管理する情報処理システム運用管理装置であって、前記情報処理装置を、その特性によって分類し、２つの前記情報処理装置の間の典型的な関係を各々の前記特性の組をキーとして記憶し、記憶された前記典型的な関係を用いて前記情報処理装置の状態を判定する。
並列分散処理システム、例えばＭａｐＲｅｄｕｃｅ方式のように、複数の情報処理装置から取得した監視データを基に障害検知を行おうとしても、どの装置の間に相関関係が生じるかが事前に決定できない。また、稼働中に相関関係が生じる組み合わせが変化するようなシステムにおいて、障害の検知を行う。
【解決手段】
複数の情報処理装置が協調して動作する情報処理システムを運用管理する情報処理システム運用管理装置であって、前記情報処理装置を、その特性によって分類し、２つの前記情報処理装置の間の典型的な関係を各々の前記特性の組をキーとして記憶し、記憶された前記典型的な関係を用いて前記情報処理装置の状態を判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
情報処理システムの運用管理装置、運用管理方法及び運用管理プログラムに関し、特にシステムの稼働状況を監視し、システムの障害の発生を検知する情報処理システムの運用管理装置、運用管理方法及び運用管理プログラムに関する。
【背景技術】
【０００２】
近年、情報処理システムが企業活動や社会インフラの基盤としてますます重要な位置を占めるようになるにつれ、高い処理能力と高い信頼性を兼備した情報処理システムへの要請はかつてないほど高くなっている。
【０００３】
そうした高度な情報処理システムの実現様態として、多数の情報処理装置をデータセンタ等に設置し、それらを協調動作させることによってシステムとしての目的を達成せしめる並列分散処理システムが普及しつつある。
【０００４】
こうした並列分散処理システムを運用管理するにあたって課題となるのは、システムで発生する障害の検知と対応である。多数の情報処理装置の協調により動作するという特性上、装置の障害の発生はシステム全体の動作に影響を及ぼす。多くのシステムは、このような障害の発生に対する耐性を具備しており、システム全体の停止は回避されるが、それでも性能の劣化や資源の利用効率の低下は避けられない。また、システムが大規模になり、使用する装置の数が増加するに従い、装置の障害発生の頻度は看過できないほどに大きくなる。
【０００５】
こうした障害発生の検知に関わる背景技術として、例えば特許文献１では、「複数の情報処理装置が協調して動作する情報処理システムの性能を監視する性能運用管理装置であって、前記複数の情報処理装置の稼働状況、及び、前記複数の情報処理装置間を接続する各通信回線のデータ通信状況を監視する監視手段と、前記監視手段による監視データに基づいて、前記情報処理システムに現在発生している障害を検知」する装置が開示されている。
【０００６】
また非特許文献１では、仮想化されたシステムにおいて、あるアプリケーションが動作する複数のインスタンスの間で計測データの相関関係を抽出し、その相関の低下によって障害の発生を検知する方法が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００５−３２７２６１号公報
【非特許文献】
【０００８】
【非特許文献１】Hui Kang, Haifeng Chen, and Guofei Jiang. 2010、 PeerWatch: a fault detection and diagnosis tool for virtualized consolidation systems、 In Proceeding of the 7th international conference on Autonomic computing (ICAC '10). ACM, New York, NY, USA, 119-128.
【発明の概要】
【発明が解決しようとする課題】
【０００９】
さて、前述のような並列分散処理システムが普及した理由として、情報処理装置の低廉化により大量に設置、運用が可能になったこと、それら装置の単体性能が著しく向上したことが挙げられる。加えて、そうした情報処理装置の群をひとまとまりとして協調動作させ（こうした群をクラスタと呼称する）、任意の目的のシステムとして活用せしめるにあたり必要となるソフトウェアを、容易に記述できるプログラミング技法が開発されたことが挙げられる。
【００１０】
そうした技法のひとつがＭａｐＲｅｄｕｃｅ方式である。ＭａｐＲｅｄｕｃｅ方式においては、ジョブを多数のタスクに分割し、それぞれのタスクを、クラスタを構成する多数の情報処理装置に分散させて実行するため、並列効果により大幅な実行時間の短縮を期待できる。また、タスクを大きくＭａｐタスクとＲｅｄｕｃｅタスクの２種類に分割し、複数のＭａｐタスク、あるいは複数のＲｅｄｕｃｅタスクそれぞれの間に、処理対象とするデータの相互依存をなくすようになっているため、タスク間の処理の同期を明示してプログラミングする必要がなくなり、タスクスケジューリングを簡素化したのも特徴である。 このＭａｐＲｅｄｕｃｅ方式を活用することで、並列分散処理を活用した多種多様な応用システムが実現可能となり、例えば公共交通機関における電子乗車券の使用履歴から得られるデータを活用した人流分析や、送配電網上に設置されたセンサから得られる電力消費量データを活用した電力需要分析等の応用が考えられる。
【００１１】
並列分散処理システムにおいては、情報処理装置の障害の発生が、システム全体の動作に影響を及ぼすことは前に述べた。ＭａｐＲｅｄｕｃｅ方式は、こうした状況への対策としても有効である。クラスタを構成する情報処理装置のうちひとつに障害が発生し、当該装置で実行中であったタスクが正常に終了しなかったとしよう。その場合でも、別の装置で同じタスクを再実行することで、ジョブ全体の実行は停止させずに完遂することができる。これは、ＭａｐＲｅｄｕｃｅ方式においてはタスク間の相互依存が最小限にとどめられているため、一つのタスクを再実行しても、他のタスクへの影響が極めて少ないためである。
【００１２】
しかしながら、かかる特性を備えたＭａｐＲｅｄｕｃｅ方式のクラスタにおいても、障害の発生を完全に無視できるわけではない。タスク間の相互依存が極小化されているとは言え、タスクの再実行はジョブ全体の実行を遅延せしめる。
【００１３】
また、ある種の障害によっては、タスクが異常終了しないまでも、その実行が本来期待されるものより遅延するという事態が発生しうる。これは例えば、情報処理装置でのスラッシングといった現象の発生によるものがある。このような場合、ＭａｐＲｅｄｕｃｅ方式では、こうしたタスクの実行遅延が発生していることを認識し、同じタスクを別の装置でも実行を開始する。こうした処理を投機的実行と呼称し、開始されるタスクをバックアップタスクと呼ぶ。そして、より先に正常に実行が終了したタスクの出力を処理結果として採用し、そのタスクより遅延しているタスクは強制終了させる。
【００１４】
こうしたバックアップタスク方式は一定の有効性を持つが、それでもなおジョブ全体の実行が遅延することには変わりはない。
【００１５】
また、タスクの異常終了であれ実行遅延であれ、こうした障害が頻発する情報処理装置は、計算資源の浪費を引き起こすものであり、早急に修理・交換を行うことが求められる。
【００１６】
よって、ＭａｐＲｅｄｕｃｅ方式を採用した並列分散処理システムを対象とした障害検知の方法が必要となるが、公知の方法では必ずしも十全とは言えない。
【００１７】
例えば前記特許文献1にて開示される発明においては、複数の情報処理装置から、それぞれ複数種類の監視データを取得し、そこから相関関係を算出することで障害の発生を検知する技術が開示されている。しかし、そうした相関関係を抽出すべき監視データをいかに選択するか、その指針は示していない。該文献に例示されている監視データは、ＤＢサーバにおけるトランザクションのスループットとディスクＩ／Ｏ量といったように、監視対象であるシステムの構成やダイナミクスについて一定の知識を有する者であれば、そこに相関が存在することを見出せるものであるが、つまり障害監視を実行するにあたって、当該システムについてのアプリオリな知識を必要とするものである。
【００１８】
しかるに前述のようなＭａｐＲｅｄｕｃｅ方式の並列分散処理システムにてこの発明を適用しようとすると困難に直面するであろう。なぜならば、ＭａｐＲｅｄｕｃｅ方式においては、ジョブをタスクに分割した後、どのタスクをどの情報処理装置で実行するかは実行時にならないと決定しないからである。この性質ゆえに、ＭａｐＲｅｄｕｃｅ方式はタスクスケジューリングの柔軟さと計算資源の利用効率の向上という利点を得ることができたのであるが、上記のような監視データを基にした障害検知技術の適用を図ろうとすると、どの装置間で相関関係を算出すればよいのか判然としないという問題がある。
【００１９】
また、プログラミング技法としてのＭａｐＲｅｄｕｃｅ方式の利点が、容易に多種多様な並列分散ソフトウェアを構築しうるという点にあるのであれば、ＭａｐＲｅｄｕｃｅ方式の並列分散処理システムは特定少数の応用システムのためのみならず、多様な応用システムのアプリケーションに供用されることも考えられる。その場合、当該クラスタが実行するジョブは、プロセッサ資源を多用するもの、ディスクＩ／Ｏを多用するもの等の特質の差異が生じ、装置にもたらす負荷も多様になるであろう。この結果、上記のようなアプローチによる障害検知技術の適用を図ろうとすると、装置から取得しうる多数の監視データの中から、相関関係算出の対象とすべきものを抽出することが困難となるという問題がある。
【００２０】
さらに、並列分散処理システムが有効に活用されればされるほどに、その規模を拡大するために、新たな情報処理装置が追加導入されることであろう。その結果、近年のように装置の性能面での進歩が急速な時代においては、クラスタを構成する情報処理装置のそれぞれについて、その具備する計算資源が不均一なものとなると考えられる。この点もまた、上記のようなアプローチによる障害検知技術の適用を困難とする。
【００２１】
すなわち、監視データの相関関係を分析することによって障害検知を行うというアプローチでは、どの情報処理装置の、どの監視データを選択しペアとして分析すべきかという問題に対して回答する必要がある。
【００２２】
例えば、前記非特許文献１にて開示される技術においては、正準相関分析（Ｃａｎｏｎｉｃａｌ Ｃｏｒｒｅｌａｔｉｏｎ Ａｎａｌｙｓｉｓ）という統計手法を活用することで、多様な監視データをひとまとまりとして分析の対象としている。この方法は、装置の監視データからどれを選択するかという課題を解決する一例である。しかしながら、前記のような、どの装置の間で相関があるとみなすべきかを判断する問題に対する解とはなっていない。
【００２３】
このように、公知の技術は、並列分散処理システムにおいて障害検知が重要であるにもかかわらず対応できていない。例えば、ＭａｐＲｅｄｕｃｅ方式のクラスタのように、複数の情報処理装置でそれぞれ取得した監視データを基に障害検知を行おうとしても、どの装置の間に相関関係が生じるかが事前に決定せず、またシステムの稼働中に相関関係が生じる組み合わせが変化するようなシステムに対応できていない。
【００２４】
そこで、並列分散処理システムにおいて、障害検知を行う方法、プログラム、装置、システムを提供する。これは例えば、ジョブの多様性や、ジョブの実行スケジューリングの非決定性や、稼働中のシステム構成の変更にも関わらず、障害検知を行うものである。
【課題を解決するための手段】
【００２５】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
【００２６】
本願は上記課題を解決する手段を複数含んでいるが、その一例は以下のような構成を有する。
ジョブを複数の情報処理装置で協調して実行する情報処理システムの運用管理装置であって、運用管理装置は、複数の情報処理装置各々から情報を取得するデータ収集部と、複数の情報処理装置に関するデータを記憶する記憶部と、記憶部に記憶されたデータを用いて複数の情報処理装置の状態を評価する評価部を有する。複数の情報処理装置は各々、所定の複数の特性の内のいずれか一の特性を有しており、
データ収集部は、複数の情報処理装置各々から性能情報を取得して前記記憶部に格納する。記憶部は更に、二の情報処理装置がとり得る特性の組み合わせ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶している。評価部は、複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、当該評価対象の情報処理装置以外の複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出すると共に当該評価対象の情報処理装置との特性の組み合わせを特定し、特定された特性の組み合わせについて記憶部に格納されている閾値と算出された相関値とを比較し、比較の結果に基づいて評価対象の情報処理装置の状態を評価する。
【発明の効果】
【００２７】
並列分散処理システムにおいて障害検知が可能となる。例えば、多様なジョブが実行される並列分散処理システムにおいても、障害検知が可能となる。
【００２８】
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００２９】
【図１】情報処理装置の構成の一例を示す図である。
【図２】並列分散処理システムの全体構成の一例を示す図である。
【図３】ＭａｐＲｅｄｕｃｅクラスタの構成の一例を示す図である。
【図４】ＭａｐＲｅｄｕｃｅ方式の処理の実行フローの一例を示す図である。
【図５】タスクトラッカのスロット数の概念の一例を示す図である。
【図６Ａ】監視エージェントの構成の一例を示す図である。
【図６Ｂ】監視エージェントの処理手順の一例を示す図である。
【図７Ａ】監視マネージャの構成の一例を示す図である。
【図７Ｂ】監視エージェントの処理手順の一例を示す図である。
【図８】監視マネージャのデータベースが格納しているテーブル群の一例を示す図である。
【図９】管理対象ホスト一覧テーブルの一例を示す図である。
【図１０Ａ】ＯＳ性能情報を格納するテーブルの一例であるプロセッサ性能情報テーブルの例を示す図である。
【図１０Ｂ】ＯＳ性能情報を格納するテーブルの一例であるメモリ性能情報テーブルの例を示す図である。
【図１０Ｃ】ＯＳ性能情報を格納するテーブルの一例であるディスク性能情報テーブルの例を示す図である。
【図１１Ａ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるジョブリストの一例を示す図である。
【図１１Ｂ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるタスクリストの一例を示す図である。
【図１１Ｃ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるアテンプトリストの一例を示す図である。
【図１１Ｄ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるデータ転送トレースの一例を示す図である。
【図１２】稼働状況評価処理手順の一例を示す図である。
【図１３】仮想グループ生成の処理手順の一例を示す図である。
【図１４Ａ】仮想グループテーブルの一例を示す図である。
【図１４Ｂ】仮想グループノード一覧テーブルの例を示す図である。
【図１５】仮想グループの概念の一例を示す図である。
【図１６】ノード特性判定の処理手順の一例を示す図である。
【図１７Ａ】ノード特性判定に用いるテーブルの例を示す図である。
【図１７Ｂ】ノード特性判定に用いるテーブルの他の例を示す図である。
【図１７Ｃ】ノード特性判定に用いるテーブルの設定に用いる画面表示の一例を示す図である。
【図１８】クラスタマップ生成の処理手順の一例を示す図である。
【図１９】クラスタマップテーブルの一例を示す図である。
【図２０】クラスタマップの概念の一例を示す図である。
【図２１】ノード性能行列生成の処理手順の一例を示す図である。
【図２２】ノード性能行列テーブルの一例を示す図である。
【図２３】相関算出の処理手順の一例を示す図である。
【図２４】ジョブプロファイルテーブルの一例を示す図である。
【図２５】イベント通知の処理手順の一例を示す図である。
【図２６】イベント通知の画面表示の一例を示す図である。
【図２７】管理対象ホスト稼働状況表示の処理手順の一例を示す図である。
【図２８Ａ】監視コンソールの画面表示の一例を示す図である。
【図２８Ｂ】監視コンソールの画面表示の他の一例を示す図である。
【図２９Ａ】監視コンソールの画面表示の一例を示す図である。
【図２９Ｂ】監視コンソールの画面表示の他の一例を示す図である。
【図３０】第２の実施形態による並列分散処理システムの全体構成の一例を示す図である。
【図３１】第２の実施形態による監視マネージャとリモートモニタの構成の一例を示す図である。
【図３２】第３の実施形態によるノード性能行列生成の処理手順の一例を示す図である。
【図３３】第３の実施形態による管理対象ホスト一覧テーブルの一例を示す図である。
【図３４Ａ】第４の実施形態によるジョブプロファイルテーブルの一例を示す図である。
【図３４Ｂ】第４の実施形態による分析アルゴリズムテーブルの一例を示す図である。
【図３５】第４の実施形態による相関算出の処理手順の一例を示す図である。
【図３６】第４の実施形態による分析アルゴリズム設定に用いる画面表示の一例を示す図である。
【図３７Ａ】第４の実施形態による分析アルゴリズム自動判定方法の概念の一例を示す図である。
【図３７Ｂ】第４の実施形態による分析アルゴリズム自動判定方法の概念の他の一例を示す図である。
【図３８】第４の実施形態による分析アルゴリズム自動判定の処理手順の一例を示す図である。
【図３９】第４の実施形態による障害検知方法の概念の一例を示す図である。
【発明を実施するための形態】
【００３０】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、以後説明される図面においては、同一部には同一符号を付し、その繰り返しの説明は省略または簡略化される。
【実施例１】
【００３１】
まず、第一の実施例として、障害検知の機能を備えるシステム運用管理装置の例を説明する。
【００３２】
図１は、情報処理装置の構成の一例を示す図である。
【００３３】
情報処理装置１００はプロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５から構成されている。プロセッサ１０１はメモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５と接続されている。ネットワークＩ／Ｆ１０４は、ネットワーク１０６と接続されている。
【００３４】
情報処理装置１００は、例えばラックマウントサーバ、ブレードサーバ、パーソナルコンピュータ等である。また情報処理装置１００は、プロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５を、いずれも複数を備えることがある。また、ストレージ１０３は、例えばハードディスクドライブ（ＨＤＤ）や、ソリッドステートドライブ（ＳＳＤ）等であり、またはこれらを複数台組み合わせたものである。また、ネットワーク１０６は、例えばイーサネット（登録商標）や、ＩＥＥＥ８０２．１１規格に基づく無線ネットワーク等である。
【００３５】
ストレージ１０３は、データを不揮発的に記録し、また読み出すことができる。ネットワークＩ／Ｆ１０４は、それが接続するネットワーク１０６を経由して、他の情報処理装置１００が有するネットワークＩ／Ｆ１０４と通信することができる。コンソール１０５は、ディスプレイ装置を用いてテキスト情報、グラフィカル情報等を表示し、また接続されたヒューマンインタフェースデバイスから情報を受信することができる。
【００３６】
情報処理装置１００は、メモリ１０２にユーザプロセス２００、オペレーティングシステム（ＯＳ）２１０を実装している。ユーザプロセス２００、オペレーティングシステム２１０は、いずれもプログラムであって、情報処理装置１００の有するプロセッサ１０１で実行され、これによって情報処理装置１００はメモリ１０２やストレージ１０３へデータを読み書きし、ネットワークＩ／Ｆ１０４とネットワーク１０６を経由して、他の情報処理装置１００のメモリ２００に実装されているユーザプロセス２００やオペレーティングシステム２１０と通信を行い、コンソール１０５に情報を表示し受信することができる。
【００３７】
本実施例で示すシステム運用管理装置、あるいは並列分散処理システムは図１に示す情報処理装置１００と同様の構成を有する。
【００３８】
図２は、並列分散処理システムの全体構成の一例を示す図である。
【００３９】
監視サーバ１１０、クライアント１２０、マスタノード１３０、ワーカノード１４０は、いずれも情報処理装置１００にそれぞれ特徴のあるユーザプロセス２００を実装したものである。例えば、監視サーバ１１０はユーザプロセスとして監視マネージャ２０１を実装する。クライアント１２０はユーザプロセスとして監視コンソール２０２を実装する。マスタノード１３０はユーザプロセスとしてジョブトラッカ２０３、ネームノード２０４、監視エージェント２０５を実装する。ワーカノード１４０はユーザプロセスとしてタスクトラッカ２０６、データノード２０７、監視エージェント２０５を実装する。また、これら情報処理装置は、ネットワーク１０６を経由して相互に通信が可能である。
【００４０】
ＭａｐＲｅｄｕｃｅクラスタ３００は、マスタノード１３０の１台と、ワーカノード１４０の１台以上を含む。
【００４１】
並列分散処理システムは、監視サーバ１１０、クライアント１２０を複数含むことがある。並列分散処理システムは、ＭａｐＲｅｄｕｃｅクラスタ３００を複数含むことがある。
【００４２】
本実施例におけるシステム運用管理装置とは、監視サーバ１１０と監視マネージャ２０１に加えて、クライアント１２０と監視コンソール２０２、または監視エージェント２０５のいずれかまたは両方から構成される。監視サーバ１１０がクライアント１２０を兼ねることもありうる。情報処理装置とそこに実装されるユーザプロセスの対応関係には自由度があり、本実施例はその多数の組み合わせの中の一例であることは留意されたい。
【００４３】
並列分散処理システムの運用管理担当者は、クライアント１２０が実装する監視コンソール２０２が、コンソール１０５を経由して表示する情報を基にして並列分散処理システムの監視を行う。また監視コンソール２０２は、運用管理担当者がコンソール１０５を経由して入力する情報を受信して監視マネージャに送信し、監視マネージャはその情報を基に動作を変更する。こうした、監視コンソールを介した運用管理担当者とシステム運用管理装置との相互作用の例は後述される。
【００４４】
図３は、ＭａｐＲｅｄｕｃｅクラスタ３００を構成するマスタノード１３０とワーカノード１４０の関係の一例を示す図である。
【００４５】
マスタノード１３０のジョブトラッカ２０３は、ジョブ３０１を実行する。ジョブ３０１は、１つ以上のタスク３０２の集合である。タスク３０２はユーザプロセス２００の一様態であり、ワーカノード１４０では1つ以上のタスク３０２が実行可能である。ジョブトラッカ２０３は、ワーカノード１４０のタスクトラッカ２０６と通信を行う。すなわち、ジョブトラッカ２０３はタスクトラッカ２０６に、タスク３０２の実行を指示する。１つのジョブ３０１を構成するタスク３０２の群を、複数のワーカノード１４０に分散させて並列に実行することによって、処理効率の向上を図るのがＭａｐＲｅｄｕｃｅ方式の主眼である。
【００４６】
ＭａｐＲｅｄｕｃｅクラスタの利用者は、実行すべきジョブ３０１をジョブトラッカ２０３に指示する。指示はマスタノード１３０のコンソール１０５を使用して行ってもよいし、他の情報処理装置１００からネットワーク１０６を経由した通信を行うことで行ってもよい。ジョブトラッカ２０３は、そのジョブ３０１を構成するタスク３０２の群を、その管理下にあるタスクトラッカ２０６に分配し、タスクトラッカ２０６は、分配されたタスク３０２を実行する。
【００４７】
またＭａｐＲｅｄｕｃｅクラスタ３００は、ワーカノード１４０のストレージ１０３にデータを格納する分散ファイルシステムの機能を備える。これはタスク３０２がその処理に必要とするデータを格納するものである。マスタノード１３０のネームノード２０４は、あるデータがどのワーカノード１４０に格納されているかという情報（メタデータ）を持っている。あるデータを必要とするタスク３０２は、ネームノード２０４と通信を行う。すなわち、タスク３０２はネームノード２０４からその必要とするデータに対応するメタデータを取得し、しかる後にそのデータが格納されているワーカノード１４０で動作するデータノード２０７と通信を行い、目的のデータを要求する。データノード２０７は、データをデータブロック３０３の群に分割してストレージ１０３に格納しており、要求されたデータをタスク３０２に転送する。
【００４８】
図４は、ＭａｐＲｅｄｕｃｅ方式のジョブ３０１の実行フローを示す図である。
【００４９】
ジョブ３０１が、１つ以上のタスク３０２の集合であることは先に述べた。タスク３０２は、Ｍａｐタスク３０５とＲｅｄｕｃｅタスク３０７の２つの種別からなる。Ｍａｐタスク３０５は、分散ファイルシステムに置かれた入力ファイルであるスプリット３０４を読み、何らかの処理を行った上で中間ファイル３０６を生成し、これをワーカノード１４０のストレージ１０３に書き込む。この中間ファイル３０６は、キー・バリュー形式のファイルであり、このキーによって、そのデータがどのＲｅｄｕｃｅタスク３０７の入力となるかが決まる。すなわちファイル３０６のバリューにはマップタスク３０５による処理の結果が書き込まれ、キーにはバリューとして書き込まれた値を入力すべきReduceタスク３０７を指定する値が書き込まれる。タスクトラッカ２０６は、Ｒｅｄｕｃｅタスク３０７を実行するワーカノード１４０に、中間ファイル３０６の群から特定のキーを持つデータを転送する。タスクトラッカ２０６は、転送されたデータをソートしたうえでＲｅｄｕｃｅタスク３０７に入力する。Ｒｅｄｕｃｅタスク３０７はそのデータに何らかの処理を行い、その結果を分散ファイルシステム上の出力ファイル３０８として生成する。
【００５０】
図５は、タスクトラッカ２０６のスロット数の概念を示す図である。
【００５１】
タスクトラッカ２０６には「スロット数」の設定がある。これは、ワーカノード１４０において１つのタスクトラッカ２０６が同時に実行するタスク数の上限値であり、Ｍａｐタスク３０５とＲｅｄｕｃｅタスク３０７毎に設定できる。図ではスロット数として各４が設定された状態を示す。これらの値は上限値であり、常にこの値と同数のタスクを実行しているわけではない。タスクトラッカ２０６は、スロット数の設定情報をジョブトラッカ２０３に送り、ジョブトラッカ２０３は、その情報を基に各タスクトラッカ２０６で実行すべきタスクを指定する。
【００５２】
図６は、監視エージェント２０５の構成の一例と、その処理手順の一例を示す図である。
【００５３】
図６Ａは監視エージェント２０５の構成の一例を示す。監視エージェント２０５は、監視データ取得部２０５１、監視データ送信部２０５４から構成される。監視データ取得部２０５１は、ＯＳ性能情報取得部２０５２、ＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０５３を有する。監視エージェント２０５は、多様な監視対象から監視データを取得できるよう、監視データ取得部２０５１は、監視対象に応じた監視データ取得のための機能をプラグインとして使用するように構成されている。本実施例では、監視データ取得部２０５１は、オペレーティングシステム（ＯＳ）２１０からＯＳ性能情報を取得するためのＯＳ性能情報取得部２０５２、ジョブトラッカ２０３とデータノード２０７からＭａｐＲｅｄｕｃｅスケジューリング情報を取得するためのＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０５３を、それぞれプラグインとして使用する。
【００５４】
監視データ送信部２０５４は、監視データ取得部２０５１とそのプラグインが取得した監視データを、監視マネージャ２０１に送信する。送信する手段は、ユニキャストでもマルチキャストでもよい。
【００５５】
図６Ｂは監視エージェント２０５の処理手順の一例を示す。監視エージェント２０５は、ＯＳ性能情報を取得し（Ｓ６０１）、ＭａｐＲｅｄｕｃｅスケジューリング情報を取得し（Ｓ６０２）、取得した監視データを監視マネージャ２０１に送信し（Ｓ６０３）、しかる後に一定の時間ウェイトし（Ｓ６０４）、再びステップＳ６０１を開始する。このように、監視エージェント２０５の処理手順は１つのループ処理であり、稼働している間は一定間隔で監視データを監視マネージャ２０１に送信し続けることになる。
【００５６】
図７は、監視マネージャ２０１の構成の一例と、その処理手順の一例を示す図である。 図７Ａは監視マネージャ２０１の構成の一例を示す。監視マネージャ２０１は、監視データ収集部２０１１、監視データ格納部２０１２、データベース２０１３、稼働状況評価部２０１４、イベント通知部２０１５から構成される。監視データ収集部２０１１は、監視エージェント２０５が送信する監視データを収集する。監視データ格納部２０１２は、収集された監視データをデータベース２０１３に格納する。本実施例では、前述の監視エージェント２０５が送信するＭａｐＲｅｄｕｃｅスケジューリング情報とＯＳ性能情報を格納する。稼働状況評価部２０１４は、データベース２０１３に格納された監視データの情報を基に、並列分散処理システムの稼働状況評価を行い、障害の発生を検知した場合は、イベント通知部２０１５が監視コンソール２０２に対してイベント通知を行う。
【００５７】
図７Ｂは監視マネージャ２０１の処理手順の一例を示す。監視マネージャ２０１の処理は、２つのループ処理からなる。第１のループは、監視エージェント２０５が送信した監視データを受信し（Ｓ７０１）、ＭａｐＲｅｄｕｃｅスケジューリング情報をデータベースに格納し（Ｓ７０２）、ＯＳ性能情報を同じくデータベースに格納する（Ｓ７０３）。第２のループは、データベース２０１３から得られる情報を基に稼働状況評価を行い（Ｓ７０４）、もし障害の発生を検知したならば（Ｓ７０５）、監視コンソール２０２に対してイベント通知を行い（Ｓ７０６）、しかる後に一定時間ウェイトする（Ｓ７０７）。このうちステップＳ７０４、Ｓ７０６については、より詳細な手順を後述する。
【００５８】
上記のように、監視エージェント２０５と監視マネージャ２０１は、定期的に監視データのやりとりのために通信を行う。本実施例では、監視エージェント２０５が監視データを送信するステップＳ６０３の実行をもって、その通信の開始の契機を制御している様態となっているが、該通信の様態はこれに限定されるものではなく、例えば監視マネージャ２０１が定期的に監視エージェント２０５に対して監視データの送信を要求する等もありうる。
【００５９】
図８は、監視マネージャ２０１のデータベース２０１３がその内部に格納しているテーブル群の一例を示す図である。データベース２０１３は、管理対象ホスト一覧のテーブル４０１を格納する。また、ＯＳ性能情報のテーブル群４０２をホスト毎に格納する。また、ＭａｐＲｅｄｕｃｅスケジューリング情報のテーブル群４０３をクラスタ毎に格納する。
【００６０】
図９は、管理対象ホスト一覧のテーブル４０１の一例を示す図である。管理対象ホストとは、監視マネージャ２０１が稼働状況判定の対象とする情報処理装置１０１である。本実施例においては、典型的にはワーカノード１４０の一群であるが、他の情報処理装置１０１もまた管理対象ホストになりうる。
【００６１】
該テーブルの１レコードは１つの管理対象ホストに対応する。該テーブルに管理対象ホストが追加される契機としては、運用管理担当者の操作によるもの、監視エージェント２０５からの通知処理によるもの、監視マネージャ２０１のディスカバリ処理によるもの等が考えられる。
【００６２】
図９では、該テーブルのフィールドのうち、説明に必要なもののみを挙げている。ホスト名フィールド４０１１は、管理対象ホストのホスト名を記録する。代表ＩＰアドレスフィールド４０１２は、管理対象ホストのネットワークＩ／Ｆ１０４のうち１つに付与されたＩＰアドレスを記録する。クラスタ名フィールド４０１３は、管理対象ホストが属するＭａｐＲｅｄｕｃｅクラスタ３００を記録する。障害検知フラグフィールド４０１４は、管理対象ホストで障害の発生が検知されているかを示すフラグを格納する。該テーブルには、監視マネージャの処理にとって必要な情報を記録するための他のフィールドも存在しうることは留意されたい。
【００６３】
図１０は、ＯＳ性能情報のテーブル群４０２の一例を示す図である。ＯＳ性能情報は、監視エージェント２０５がオペレーティングシステム２１０から取得し、監視マネージャ２０１に送信する監視データである。監視マネージャ２０１は、受信したＯＳ性能情報を、データベース２０１３内のテーブル群４０２に格納する。
【００６４】
本実施例では、ＯＳ性能情報のテーブルの個別の例として、プロセッサ性能情報テーブル４０２１、メモリ性能情報テーブル４０２２、ディスク性能情報テーブル４０２３を示す。各テーブルに共通するのは、レコードそれぞれに当該情報を取得した時刻と、情報を取得するインターバルを含むことである。プロセッサやディスクの場合、インターバルは、何秒間の値を累積し算出したものかを示す。
【００６５】
プロセッサ性能情報の場合は、累積値からさらに使用率を算出し記録する。ディスク性能情報の場合は、累積値から単位時間当たりのＩ／Ｏ量を算出し記録する。一方メモリ性能情報の場合は、取得した値はその取得した時点でのスナップショットであり、インターバルは文字通り、情報の取得間隔の意味である。そして、各レコードはさらに詳細な性能情報の項目を複数含む。この項目それぞれをメトリックと呼ぶ。
【００６６】
情報処理装置１０１は、プロセッサ１０１や、ストレージ１０３を構成するディスクを複数搭載することがある。監視エージェント２０５は、オペレーティングシステム２１０からそれらを別個の監視データとして取得し、監視マネージャ２０１がＯＳ性能情報のテーブル群４０２に記録する際には別個のレコードとして記録し、それぞれがプロセッサＩＤやデバイス名で区別特定される。
【００６７】
本実施例では、ＯＳ性能情報の代表的なものとして上記の３つを取り上げたが、これに限定されるものではなく、他にもオペレーティングシステム２１０から取得できる統計情報は、同様にＯＳ性能情報のテーブル群４０２の１つとなりうる。
【００６８】
図１１は、ＭａｐＲｅｄｕｃｅスケジューリング情報のテーブル群４０３の一例を示す図である。ＭａｐＲｅｄｕｃｅスケジューリング情報は、監視エージェント２０５がジョブトラッカ２０３とデータノード２０７から取得し、監視マネージャ２０１に送信する監視データである。監視マネージャ２０１は、受信したＭａｐＲｅｄｕｃｅスケジューリング情報を、データベース２０１３内のテーブル群４０３に格納する。
【００６９】
本実施例では、ＭａｐＲｅｄｕｃｅスケジューリング情報のテーブルとして、ジョブリスト４０４、タスクリスト４０５、アテンプトリスト４０６、データ転送トレース４０７がある。
【００７０】
ＭａｐＲｅｄｕｃｅ方式におけるジョブ３０１とタスク３０２の関係については図３で説明したとおりである。ジョブリスト４０４は、ジョブ１つにつき１レコードを記録する。ジョブはジョブＩＤフィールドに記録されるジョブＩＤにより一意に特定される。タスクリスト４０５は、タスク１つにつき１レコードを記録する。タスクはタスクＩＤフィールドに記録されるタスクＩＤにより一意に特定され、ジョブＩＤフィールドに記録されるジョブＩＤにより、該タスクが属するジョブが特定される。
【００７１】
ＭａｐＲｅｄｕｃｅ方式におけるタスク３０２の実行をアテンプトと呼ぶ。アテンプトリスト４０６は１アテンプトにつき１レコードを記録する。アテンプトはアテンプトＩＤフィールドに記録されるアテンプトＩＤにより一意に特定され、タスクＩＤフィールドに記録されるタスクＩＤにより、該アテンプトの元となるタスクが特定される。通常は1タスクにつき1アテンプトのみが記録されるが、タスクの実行が失敗した場合等にタスクの再実行が行われ、同一のタスクが複数回実行されることがある。この場合は、アテンプトリスト４０６に、同一のタスクＩＤに対して複数回のアテンプトが記録されることになる。アテンプトリスト４０６の実行ノードフィールドには、当該アテンプトを実行したワーカノード１４０のホスト名が記録される。
【００７２】
ＭａｐＲｅｄｕｃｅクラスタ３００が分散ファイルシステムを備えることは前述した。データ転送トレース４０７は、データノード２０７が転送したデータについて記録する。データ転送１回につき１レコードを記録する。
【００７３】
図１２は、監視マネージャの処理手順のうち、稼働状況評価の処理手順（ステップＳ７０４）の一例を示す図である。この図を基に、まず稼働状況評価の処理手順を概説し、それに続いてより詳細な手順を説明する。
【００７４】
稼働状況評価部２０１４は、まずデータベース２０１３から、ＭａｐＲｅｄｕｃｅスケジューリング情報４０３のうち、ジョブリスト４０４、タスクリスト４０５、アテンプトリスト４０６を取得する。この３テーブルのうち、ジョブリスト４０４とタスクリスト４０５はいずれもジョブＩＤのフィールドを含み、タスクリスト４０５とアテンプトリスト４０６はいずれもタスクＩＤのフィールドを含むことが分かる。また、アテンプトリスト４０６は実行ノードのフィールドを含む。よって、これらのフィールドをもって３つのテーブルを結合することで、あるジョブの実行に使用されたワーカノード１４０の群が判別できる。このワーカノード群を抽出する処理が仮想グループの生成（Ｓ１２０１）である。
【００７５】
次に稼働状況評価部２０１４は、データベース２０１３から管理対象ホスト一覧テーブル４０１を取得する。そして管理対象ホスト毎に、先のタスクリスト４０５とアテンプトリスト４０６を使い、該管理対象ホストで実行されていたタスクのタスク種別を求める。次に、データ転送トレース４０７を取得し、そこから得られる該管理対象ホストから転送したデータの情報を加えて、各管理対象ホストのノード特性を判定する（Ｓ１２０２）。 次に稼働状況評価部２０１４は、先に生成した仮想グループと、各管理対象ホストのノード特性を併合しクラスタマップを生成する（Ｓ１２０３）。
【００７６】
そしてクラスタマップを生成すると、次に各管理対象ホストについて、そのＯＳ性能情報４０２からノード性能行列を生成し（Ｓ１２０４）、そのノード性能行列を用いて正準相関係数の算出による相関分析を行う（Ｓ１２０５）。稼働状況評価部２０１４は、その相関分析の結果によって、障害の発生を検知する。もし障害の発生を検知した場合には、処理はイベント通知部２０１５によるイベント通知の処理手順（ステップＳ７０６）に移行する。
【００７７】
以下、上記の各ステップについて詳細な手順を説明する。
【００７８】
図１３は、稼働状況評価の処理手順のうち、仮想グループ生成の処理手順（ステップＳ１２０１）の一例を示す図である。まず稼働状況評価部は、ジョブリスト４０４を取得し（Ｓ１３０１）、そこからステータスがＲＵＮＮＩＮＧであるジョブ、または終了時刻が記録されていないジョブを抽出する（Ｓ１３０２）。これで現在実行中のジョブが抽出される。これらのジョブ群をカレントジョブと呼ぶ。
【００７９】
次にタスクリスト４０５を取得し（Ｓ１３０３）、そこからカレントジョブのジョブＩＤを含むレコードを抽出する（Ｓ１３０４）。さらにステータスがＲＵＮＮＩＮＧ、または終了時刻が記録されていないタスクを抽出する（Ｓ１３０５）。これにより、現在実行中のタスクが抽出される。
【００８０】
次にアテンプトリスト４０６を取得し（Ｓ１３０６）、そこから実行中のタスクのタスクＩＤを含むレコードを抽出し（Ｓ１３０７）、さらにステータスがＲＵＮＮＩＮＧ、または終了時刻が記録されていないアテンプトを抽出する（Ｓ１３０８）。
【００８１】
ここまでで抽出されたレコードのうち、タスクリストから抽出されたレコードにはスプリットのフィールドが、アテンプトリストから抽出されたレコードには実行ノードのフィールドがある。そこで、カレントジョブの各々について、これらの対応関係をそれぞれ仮想グループテーブルに記載する（Ｓ１３１０、Ｓ１３１１）。
【００８２】
図１４Ａは、この仮想グループテーブル５０１の一例を示す図である。
【００８３】
スプリットを含む、または、実行ノードである全ノードを、あるジョブの仮想グループとする（Ｓ１３１２）。すなわち、カレントジョブ1つにつき仮想グループ1つができる。 図１４Ｂは、仮想グループノード一覧テーブル５０２の一例を示す図である。これは仮想グループテーブル５０１から、ジョブＩＤ、ジョブ名、ノード名を取り出したテーブルである。このテーブルにより、ある仮想グループに属するノードを一覧することができる。
【００８４】
稼働状況評価部２０１４は、これら仮想グループテーブル５０１および仮想グループノード一覧テーブル５０２を、後々の処理に供するため監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【００８５】
図１５は、上記の仮想グループの概念を示す図の一例である。仮想グループ５０３には、あるジョブについて、タスク３０２の実行ノードおよびスプリット（Ｍａｐタスクの入力ファイル）３０４を含むノードが所属することになる。
【００８６】
図１６は、ノード特性判定の処理手順（ステップＳ１２０２）の一例を示す図である。 ノード特性の判定とは、ノードが仮想グループにおいてどのような役割を果たしているかを判定するものである。この役割をノード特性と呼称する。判定の材料となるのは、仮想グループ生成のときに作成した、対応関係を記したテーブルと、データ転送トレースである。データ転送トレースの転送先フィールドを参照することで、そのノードが含むスプリットがどこに転送されるものなのかを判定することができる。
【００８７】
ノード特性の判定は、管理対象ホスト毎に行う。まず管理対象ホストが仮想グループに属するかを、仮想グループノード一覧テーブル５０２に基づき判定する（Ｓ１６０１）。仮想グループに属する場合は処理を継続するが、属しない場合は稼働状況評価対象外として処理を終了する（Ｓ１６０７）仮想グループに属する場合、仮想グループテーブル５０１の情報を用いて実行ノードであるかを判定する（Ｓ１６０２）。実行ノードである場合は、そのタスク種別を判定する（Ｓ１６０３）。次に仮想グループテーブル５０１の情報を用いてスプリットを含むかを判定する（Ｓ１６０４）。スプリットを含む場合は、データ転送トレースの情報を用い、そのスプリットの転送先を判定する（Ｓ１６０５）。これらの処理、特にタスク種別の判定Ｓ１６０３と転送先の判定Ｓ１６０５によって得られる情報と、次に示すテーブルを用いてノード特性の判定を行う（Ｓ１６０６）。
【００８８】
図１７は、ノード特性の判定に使用するテーブルの例と、それらの設定に用いる画面表示の例を示す図である。
【００８９】
まず図１７Ａは、もっとも単純なノード特性の分類の例である。この例では、1ノードが1スロット（同時に1タスクしか実行できない）という設定であり、タスク種別はＭａｐ、Ｒｅｄｕｃｅ、Ｎｏｎｅ（実行ノードでない）のいずれか、スプリットの転送先はローカル、リモート、転送なしのいずれかである。
【００９０】
先のステップＳ１６０３、Ｓ１６０５によって得られる情報から、該管理対象ホストがこのテーブル５０４のどの欄に該当するかを判定できる。その欄に記された記号（ＭＬ、ＭＲ等）が、すなわちその管理対象ホストのノード特性である。このテーブル５０４に記されたこれらの記号は、複数のノード特性を区別するために便宜的に定められた記号であり、その用をなすものであればどのような記号の体系を用いても構わない。
【００９１】
図１７Ｂは、いくぶん複雑なノード特性の分類の例である。管理対象ホストは、スプリットを複数含み、それらを様々な転送先に転送することもあるであろう。データ転送トレースの情報から、管理対象ホストがスプリットを転送した転送先とバイト数を得ることができる。これをローカル転送（Ｌ）とリモート転送（Ｒ）に分け、さらにその転送量の比率で６段階に分類する。また、1ノードに複数スロットが設定されている場合、実行されているタスクのタスク種別がＭａｐタスク（Ｍ）であるかＲｅｄｕｃｅタスク（Ｒ）であるか、その数の比率に応じて５段階で、あるいは実行しているタスクがない状態（Ｎｏｎｅ）を加えて６段階で分類する。
【００９２】
こうしたノード特性の判定に使用するテーブルは様々なものが考えうるが、どういったテーブルが適切であるかは、並列分散処理システムによって異なるであろう。そこで、並列分散処理システムの運用管理担当者が、どのようなテーブルを使用するかを監視マネージャに指示できるようにする。
【００９３】
図１７Ｃは、これらノード特性の判定に使用するテーブルを設定するプリファレンス画面の例を示す図である。プリファレンス画面６０１は、監視コンソール２０２が監視コンソールスクリーン６００に表示する画面であり、ノード特性使用チェックボックス６０１１、ノード特性自動判定チェックボックス６０１２、プリセットメソッド使用チェックボックス６０１３、メソッド選択ドロップダウンボックス６０１４、カスタムメソッド作成チェックボックス６０１５、カスタムメソッドテーブル６０１６を備える。カスタムメソッドテーブル６０１６は、複数のエントリにより構成され、エントリそれぞれはメトリクス使用チェックボックス６０１７、メトリクス名６０１８を備える。また、プリファレンス画面６０１は、ＯＫ／Ｃａｎｃｅｌボタン６０１９を備える。
【００９４】
運用管理担当者は、監視コンソール２０２が実装されているクライアント１２０のコンソール１０５に表示される監視コンソールスクリーン６００と、同じくコンソール１０５のヒューマンインタフェースデバイスを用いて、ノード特性の判定に使用するテーブルを指定する。ノード特性使用チェックボックス６０１１をチェックすることで、稼働状況評価にノード特性を適用するよう指示することができる。ノード特性自動判定チェックボックス６０１２をチェックすることで、監視マネージャがノード特性を自動的に判定するよう指示することができる。このノード特性自動判定チェックボックス６０１２をチェックすることで、以下のノード特性判定方法に関わる操作が可能になる。
【００９５】
プリセットメソッド使用チェックボックス６０１３をチェックすることで、あらかじめ監視マネージャに登録されているノード特性判定方法を使用するよう指示することができる。プリセットメソッド使用チェックボックス６０１３をチェックすると、メソッド選択ドロップダウンボックス６０１４が使用できるようになる。このメソッド選択ドロップダウンボックス６０１４を操作することで、あらかじめ登録されているノード特性判定方法のうちどれを使用するかを選択し指示することができる。例えば、管理対象ホストがＭａｐＲｅｄｕｃｅクラスタを構成するノードである場合に適切なノード特性判定方法として「ＭａｐＲｅｄｕｃｅ」という名称の判定方法が登録されていれば、これを選択する。
【００９６】
監視マネージャにあらかじめ登録されているノード特性判定方法では適切ではないと運用管理担当者が判断した場合は、カスタムメソッド作成チェックボックス６０１５をチェックし、カスタム化されたノード特性判定方法を使用するよう指示することができる。カスタムメソッド作成チェックボックス６０１５をチェックすると、カスタムメソッドテーブル６０１６の操作が可能になる。
【００９７】
カスタムメソッドテーブル６０１６は、監視マネージャが監視エージェントから収集する様々な監視データを列挙し、それらのうちどれを用いてノード特性の判定を行うかを指示するものである。監視データはカスタムメソッドテーブル６０１６のエントリとして一覧表示され、多数に及ぶ場合にはスクロールバーによりその一部のみを表示する。各エントリに対応する監視データの名称をメトリクス名６０１８に表示する。各エントリが備えるメトリクス使用チェックボックス６０１７をチェックすると、該エントリに対応する監視データをノード特性判定に使用するよう指示することができる。
【００９８】
運用管理担当者が、カスタムメソッドテーブル６０１６のメトリクス使用チェックボックスのうち適切と判断するものをいくつか選択のうえチェックし、ＯＫ／Ｃａｎｃｅｌボタン６０１９のうちＯＫボタンを押下すると、監視コンソールはそれら選択されたメトリクスの情報を監視マネージャに送信する。監視マネージャはその情報に基づき、ノード特性判定に使用するテーブルを構築し、監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【００９９】
図１８は、クラスタマップ生成の処理手順（ステップＳ１２０３）の一例を示す図である。
【０１００】
クラスタマップは、仮想グループに属するノードをノード特性で分類したものである。まずノード特性判定結果を取得する（Ｓ１８０１）。次に、仮想グループはカレントジョブ1つにつき1つであるので、まずジョブＩＤにてソートする（Ｓ１８０２）。次にノード特性でソートする（Ｓ１８０３）ことで、ノード特性ごとにノードを分類することができる。
【０１０１】
図１９は、クラスタマップテーブルの一例を示す図である。
【０１０２】
クラスタマップテーブル５０６は、図１４Ｂで示した仮想グループノード一覧テーブル５０２にノード特性判定結果を追記し、ノード特性でソートしたものであると言える。
【０１０３】
図２０は、クラスタマップの概念を示す図の一例である。
【０１０４】
クラスタマップ５０３は、ジョブＩＤとジョブ名で識別されるジョブを単位として、そのジョブの実行に関わるノードをノード種別により分類したものである。あるノード特性を備えるノード１４０は、同じノード特性を備えるノードと共にノード特性グループ５０７に属する。
【０１０５】
図２１は、ノード性能行列生成の処理手順（ステップＳ１２０４）の一例を示す図である。
【０１０６】
管理対象ホスト毎に、まずデータベースに該ホストのＯＳ性能情報があるかを判定する（Ｓ２１０１）。もしなければ、稼働状況評価の対象外とする（Ｓ２１０５）。もしあれば、そのＯＳ性能情報から一定のタイムフレームのデータを取得し（Ｓ２１０２）、全てのメトリックを連結し（Ｓ２１０３）、ノード性能行列を生成する（Ｓ２１０４）。
【０１０７】
この手順で示されるように、ノード性能行列とは、そのノードから取得したＯＳ性能情報を連結したものであり、ＯＳ性能情報がデータベースに記録されているホストについて、そのホストの特性をあるタイムフレーム内の資源の使用状況から特徴づけるものである。ここではメトリックを単純に連結したものをノード性能行列として使用しているが、他の例も考えられる。例えば、過去のＯＳ性能情報もデータベースに記録されていることを利用し、指数加重移動平均を算出した上で連結するといった方法も可能である。
【０１０８】
また、このホストの特性を特徴づけるという目的から、タイムフレームを決定する。ＯＳ性能情報には情報取得のインターバルが記録されている。稼働状況評価の処理一回につき各ホストで共通のタイムフレームであれば、どのようなものを使うにせよ、メトリック毎にデータを複数含むようなタイムフレームを選択することが必要である。
【０１０９】
図２２は、ノード性能行列テーブルの一例を示す図である。ノード性能行列テーブルは、ノード性能行列を格納するテーブルであり、稼働状況評価の対象となるノード毎に生成される。上記ステップＳ２１０３で連結したとおり、テーブルの列方向にはＯＳ性能情報の各メトリックが列挙され、テーブルの縦方向には各メトリックのタイムフレーム内のデータが取得時刻順に配置される。この例ではテーブルの最初の行に各メトリックの名称、左端の列にデータの取得時刻を含むが、これはテーブルの内容をわかりやすく示すために記載したものであり、実際のテーブルには必ずしも含む必要はない。
【０１１０】
図２３は、相関分析の処理手順（ステップＳ１２０５）の一例を示す図である。
【０１１１】
相関分析は、管理対象ホスト毎に行う。まず管理対象ホストが仮想グループに属するかを判定する（Ｓ２３０１）。もし仮想グループに属していないとすれば、該管理対象ホストはどのカレントジョブの実行にも関与していないということであり、稼働状況評価の対象外とする（Ｓ２３１４）。次に管理対象ホストのノード性能行列が存在するかを判定する（Ｓ２３０２）。もしＯＳ性能情報が取得されていない等の理由でノード性能行列が生成されず、該管理対象ホストのノード性能行列テーブルが存在しない場合は、稼働状況評価の対象外とする（Ｓ２３１４）。
【０１１２】
次からの処理は、管理対象ホストが属する仮想グループに注目して行う。まず該仮想グループに存在するノード特性を抽出し（Ｓ２３０３）、それらノード特性毎に、該ノード特性を備えるノードを抽出し（Ｓ２３０４）、そしてそれらノード毎に相関係数の算出の処理を行う（Ｓ２３０５）。これらの処理に必要な、ノードとノード特性の情報はクラスタマップテーブル５０６から抽出することができる。
【０１１３】
このように、ある管理対象ホストから見て、ノード特性が自身のそれと同一であるか異なるかに関わらず、自身の属する仮想グループに存在する全てのノード属性との間で相関係数算出の処理を行うことにより、該仮想グループに属するノード特性の構成がいかようであっても対応することができる。
【０１１４】
さて、ステップＳ２３０５にてあるノード特性を備えるノード群から１ノードを選択した後、次に該ノードのノード性能行列Ｖnを取得する（Ｓ２３０６）。そして、管理対象ホストのノード性能行列Vpと、該ノードのノード性能行列Vnとの間の正準相関係数を算出する（Ｓ２３０７）。正準相関係数は、１つ以上の相関係数ρ１〜ρｎとして表わされる。
【０１１５】
この正準相関係数のうち、ある閾値より高いものの数が、カレントジョブのその２つのノード間の関係を示す情報である。この数が、該ジョブの正常時における同一組のノード特性間のそれより小さい場合、当該ノード間の相関が低くなったことを意味する。そして、他の全ノードに対してその現象が観測された場合、管理対象ホストについての障害の検知とみなす。この処理を実行するためには、あるジョブの正常時におけるノード特性間の正準相関係数についての情報が必要であり、そうした情報を既定正準相関データと呼称する。この情報を格納するテーブルをジョブプロファイルテーブルと呼称し、後述される。 相関分析の処理手順の説明に戻る。正準相関係数ρ１〜ρｎを算出したのち、管理対象ホストと選択したノードのノード特性の組をキーとして、ジョブプロファイルテーブルから該ノード特性間の既定正準相関データを取得する（Ｓ２３０８）。次に、ρ１〜ρｎのうち、ある閾値より高いものを選出し（Ｓ２３０９）、そしてその数が既定正準相関データの数より小さいと判定した場合は（Ｓ２３１０）、カウンタをインクリメントする（Ｓ２３１１）。こうして、正準相関係数の算出と既定正準相関データとの比較を、仮想グループ内の全ノード特性とそれに属するノード群、すなわち仮想グループ内の全ノードに対して行い、結果カウンタの値が仮想グループの(現在注目している管理対象ホストを除いた)ノード数に等しくなった場合（Ｓ２３１２）、当該管理対象ホストでは障害が発生していると判定し、管理対象ホスト一覧のテーブルの該レコードについて障害検知フラグを１に設定する（Ｓ２３１３）。
【０１１６】
この処理において必要となる閾値は、１つのクラスタ、あるいは１つのシステム運用管理装置において一貫したものであれば、任意のものを設定できる。また、障害発生の判定に使用するカウンタについて、仮想グループのノード数と等しくなったときに限らず、例えば仮想グループのノード数の半数を超えた場合に障害発生とみなす等、その判定の基準は任意のものを設定できる。こうした自由度は、並列分散処理システムの複雑さ、あるいは情報処理装置で発生する障害の多様さに適応するために必要なものである。
【０１１７】
図２４は、ジョブプロファイルテーブルの一例を示す図である。
【０１１８】
ジョブプロファイルテーブル５０９は、ジョブ名で特定されるジョブについて、そのジョブの実行に関わるノードをノード特性で分類した上で、正常時のそれらのノード同士でノード性能行列の正準相関係数を算出した結果から、既定の閾値より大きい値を記録したもの、すなわち既定正準相関データを、ジョブ名およびノード特性の組をキーとして検索できるよう記録したものである。稼働状況評価部２０１４は、ジョブプロファイルテーブルに既定正準相関データを記録する。この際、前述したようにある閾値より大きい値のみを記録してもよいし、あるいは算出した正準相関係数を全て記録しておき、相関算出の処理を実行するに際して閾値より大きい値のみを取得するようにしてもよい。また、同一のノード特性を持つノードの組は複数の組み合わせがありうるが、それぞれから算出される正準相関係数のうち最も小さい値のものを既定正準相関データとして採用してもよいし、平均値や中央値を算出して採用してもよい。稼働状況評価部２０１４は、ジョブプロファイルテーブル５０９を、後々の相関分析の処理に供するため監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【０１１９】
図２５は、監視マネージャの処理手順のうち、イベント通知の処理手順（Ｓ７０６）の一例を示す図である。
【０１２０】
イベント通知は、管理対象ホストのうち、相関算出の結果障害検知フラグフィールド４０１４が1に設定されたものを抽出し、監視コンソールに当該ホストの情報を通知する処理である。イベント通知部は、まず管理対象ホスト一覧のテーブル４０１を取得し（Ｓ２５０１）、該テーブルの各レコードにつき障害検知フラグフィールド４０１４を調べる（Ｓ２５０２）。そして、該フィールドが１である場合は、そのレコードからホスト名フィールド４０１１を抽出し、監視コンソールに通知する（Ｓ２５０３）。また他のフィールド、例えばクラスタ名フィールド４０１３を、ホスト名フィールドと併せて通知することもできる。
【０１２１】
図２６は、監視コンソールにおけるイベント通知の画面表示の一例を示す図である。
【０１２２】
監視マネージャ２０１のイベント通知部２０１５からの通知を受信した監視コンソール２０２は、クライアント１２０のコンソール１０５に監視コンソールスクリーン６００およびイベント通知画面６０２を表示することで、運用管理担当者に障害の発生を通知する。
【０１２３】
イベント通知画面６０２は、クラスタ名表示６０２１と、該クラスタに属するノードのノード名表示６０２２とノードステータス表示６０２３の組により構成される。監視マネージャが送信したイベント通知がクラスタ名フィールドを含む場合には、監視コンソールスクリーンにノードをクラスタ別に分類して表示することで、運用管理担当者は障害が影響する範囲を容易に把握することができる。このために、クラスタ名表示６０２１が用意される。イベント通知が含むホスト名は、ノード名表示６０２２に表示する。ノードステータス表示６０２３には、監視マネージャが該ノードにおける障害の発生を検知したことを運用管理担当者が認識できるような方法で、それを表示する。例えば文字による表示、色調の変化による表示、あるいはこれらの組み合わせによる表示等の方法がある。また、運用管理担当者が障害への対応を実施するにあたって有用な情報を、併せて表示することができる。
【０１２４】
このイベント通知画面に示されるように、本実施例のシステム運用管理装置は、その管理対象ホストにおける障害の発生を、コンソール１０５を経由した情報表示にて運用管理担当者に通知するが、他にも電子メールの送信による通知や、ブザーの鳴動や回転警告灯の点灯による通知等、様々な方法がありうる。
【０１２５】
図２７は、監視コンソールが管理対象ホストの稼働状況を画面表示する処理手順の一例を示す図である。監視コンソール２０２は、監視マネージャ２０１からのイベント通知処理に依らずとも、管理対象ホストの稼働状況をクライアント１２０のコンソール１０５に表示させることができる。これにより、管理対象ホストにおける障害の発生の有無に関わらず、運用管理担当者は管理対象ホストの稼働状況を監視することができる。
【０１２６】
まず監視コンソール２０２は、管理対象ホスト一覧のテーブル４０１を取得する（Ｓ２７０１）。管理対象ホスト一覧のテーブルは、監視マネージャ２０１のデータベース２０１３に格納されているものを、監視マネージャとの通信によって取得する。次いで、取得した管理対象ホスト一覧から表示対象ホストを抽出する（Ｓ２７０２）。表示対象ホストは、管理対象ホスト一覧のサブセットであり、その抽出には様々な基準を適用しうるが、例えば監視マネージャが監視サーバのメモリにテーブルとして保存している情報を使用することが考えられる。その例は後述される。しかる後に、表示対象ホストの一覧を画面表示に適した表形式に整形し（Ｓ２７０３）、クライアント１２０のコンソール１０５を経由して画面表示を行う（Ｓ２７０４）。
【０１２７】
監視コンソール２０２は、上記のように管理対象ホスト一覧のテーブルや、監視マネージャがメモリに保存しているテーブルを監視マネージャとの通信によって取得するが、これらの処理を管理対象ホストの稼働状況を画面表示する都度実行する必要があるわけでは必ずしもない。監視コンソールは、取得したテーブルをクライアント１２０のメモリ１０２に保存しておき、複数回の画面表示の処理でこれらメモリに保存されたテーブルを再使用することで監視マネージャとのデータ転送量を削減することができる。この場合、クライアントのメモリに保存されたテーブルと、監視サーバのメモリに保存ないしはデータベースに格納されたテーブルとの間で、その内容に齟齬が生じないよう配慮する必要があるが、そのために必要な処理は一般にキャッシュ制御と呼ばれ、当業者には周知のものであろう。
【０１２８】
図２８は、監視コンソールが管理対象ホストの稼働状況を画面表示する一例として、仮想グループノード一覧テーブルの情報を基に表示対象ホストを抽出する画面表示の例を示す図である。
【０１２９】
監視コンソールが仮想グループを画面表示するにあたって、例えば図１５に示すような図を模して表示することも可能であるが、より一覧性の高い例も考えられる。
【０１３０】
図２８Ａは監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、仮想グループノード一覧テーブル５０２の情報を基にして表示する例である。仮想グループノード一覧テーブルは、監視マネージャ２０１の稼働状況評価部２０１４が生成するものであり、監視マネージャは図１４Ｂに示すテーブルとして監視サーバ１１０のメモリに保存している。管理対象ホスト一覧のテーブルとこのテーブルの情報を基に、監視コンソールが仮想グループを単位とした管理対象ホストの稼働状況を監視コンソールスクリーンに画面表示するとすれば、クラスタ名表示６０３１、仮想グループ６０３２、ノード６０３３、を表示する。
【０１３１】
図２８Ｂは、監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、仮想グループノード一覧テーブル５０２の情報を基にして表示する別の例である。この例では、クラスタ名表示６０３１、ノード６０３３、該ノードが実行に関わるジョブ名６０３４、を表示する。監視コンソールが、こうした監視コンソールスクリーン６００をクライアント１２０のコンソール１０５に表示することで、運用管理担当者は管理対象ホストの稼働状況を知ることができる。
【０１３２】
図２９は、監視コンソールが管理対象ホストの稼働状況を画面表示する別の例として、クラスタマップテーブルの情報を基に表示対象ホストを抽出する画面表示の例を示す図である。
【０１３３】
監視コンソールがクラスタマップを画面表示するにあたって、例えば図２０に示すような図を模して表示することも可能であるが、より一覧性の高い例も考えられる。
【０１３４】
図２９Ａは監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、クラスタマップテーブル５０６の情報を基にして表示する例である。クラスタマップテーブルは、監視マネージャ２０１の稼働状況評価部２０１４が生成するものであり、監視マネージャは図１９に示すテーブルとして監視サーバ１１０のメモリに保存している。管理対象ホスト一覧のテーブルとこのテーブルの情報を基に、監視コンソールが仮想グループを単位とした管理対象ホストの稼働状況を監視コンソールスクリーンに画面表示するとすれば、クラスタ名表示６０３１、仮想グループ６０３２、ノード６０３３、ノード属性６０３５、を表示する。
【０１３５】
図２９Ｂは、監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、クラスタマップテーブル５０６の情報を基にして表示する別の例である。この例では、クラスタ名表示６０３１、ノード６０３３、該ノードが実行に関わるジョブ名６０３４、該ノードのノード属性ラベル６０３６を表示する。
【０１３６】
以上の説明においては、ジョブ３０１が、Ｍａｐタスク３０５とＲｅｄｕｃｅタスク３０７の２つの種別のタスクを有する場合を例示した。しかしジョブが複数のMapタスクを有し、Reduceタスクを含まない場合にも本発明は上記説明に従って実施可能である。この場合、ノード特性はスプリットの転送先（すなわちデータファイルの特性）によって判定される（図１６）。
【実施例２】
【０１３７】
次に、本発明を適用した第二の実施例を説明する。第一の実施例で示した障害検知の機能を備えるシステム運用管理装置は、管理対象ホストからＯＳ性能情報やＭａｐＲｅｄｕｃｅスケジューリング情報を収集するために、各管理対象ホストに監視エージェントを実装していた。このような監視エージェントは、多くの場合、運用管理担当者が該ホストにインストールするものである。つまり管理対象ホスト数が増加するほど、作業が煩雑になるであろう。また、監視エージェントが該ホストのメモリをいくばくか消費することについて、懸念する向きもあるであろう。
【０１３８】
そこで本実施例では、監視エージェントを使用せずに障害検知を行う例を説明する。基本的な構成は第一の実施例と同一であるため、差異となる部分のみを説明する。
【０１３９】
図３０は、第二の実施例による並列分散処理システムの一例を示す図である。図２に示す、第一の実施例による並列分散処理システムとの差異は、マスタノード１３０やワーカノード１４０が監視エージェントを実装せず、代わりに監視サーバ１１０がリモートモニタ２０８を実装する点である。
【０１４０】
図３１は、第二の実施例における監視マネージャとリモートモニタのブロック構成を示す図の一例である。
【０１４１】
リモートモニタ２０８は、リモート監視データ取得部２０８１、監視データ送信部２０８４から構成される。
【０１４２】
リモート監視データ取得部２０８１は、ＯＳ性能情報取得部２０８２、ＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０８３を有する。リモートモニタ２０８は、多様な監視対象から監視データを取得できるよう、リモート監視データ取得部２０８１が、監視対象に応じた監視データ取得のための機能をプラグインとして使用するように構成されている。本実施例では、リモート監視データ取得部２０８１は、オペレーティングシステム（ＯＳ）２１０からＯＳ性能情報を取得するためのＯＳ性能情報取得部２０８２、ジョブトラッカ２０３とデータノード２０７からＭａｐＲｅｄｕｃｅスケジューリング情報を取得するためのＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０８３を、それぞれプラグインとして使用する。
【０１４３】
監視データ送信部２０８４は、リモート監視データ取得部２０８１とそのプラグインが取得した監視データを、監視マネージャ２０１に送信する。監視マネージャ２０１の監視データ収集部２０１１は、リモートモニタ２０８が送信する監視データを収集する。
【０１４４】
プラグインは、それぞれの方法で情報を取得する。その例として、ＯＳ性能情報の場合は、ＳＳＨ（登録商標）とＯＳコマンド、あるいはＳＮＭＰを使うといった方法がある。ＭａｐＲｅｄｕｃｅスケジューリング情報の場合は、ＳＳＨでジョブトラッカやデータノードのログファイルを収集するといった方法がある。いずれにしても、取得する情報については第一の実施例における監視エージェントの実装するプラグインと変わりはない。
【０１４５】
監視データ送信部２０８４が、監視マネージャ２０１に監視データを送信する方法としては、例えばソケット、ＲＰＣ、ＨＴＴＰといったプロセス間通信の方法によるものがある。
【０１４６】
以上説明したような方法で、第二の実施例は監視エージェントを実装せずに、本発明を並列分散処理システムに適用する。
【実施例３】
【０１４７】
次に、本発明を適用した第三の実施例を説明する。第一の実施例では、ノード性能行列生成において管理対象ホストから収集されるＯＳ性能情報の監視データを使用した。第三の実施例では、これに加えて、管理対象ホストのノード性能指標を使用する。ノード性能指標とは、情報処理装置の備えるプロセッサ、メモリといった計算資源の個別の性能を数値によって表現したものである。例えばプロセッサについては、ある管理対象ホストが備えるプロセッサの個数、動作周波数といったものがノード性能指標である。本実施例は、この情報を使用することで、その具備する計算資源において多様性のある情報処理装置により構成される並列分散処理システムを対象にした障害検知をより効果的に行うことを狙いとするものである。以下、基本的な構成は第一の実施例と同一であるため、差異となる部分のみを説明する。
【０１４８】
図３２は、第三の実施例におけるノード性能行列生成の処理手順の一例を示す図である。図２１に示す処理手順に加えて、ステップＳ３２０３が追加される。監視マネージャ２０１の稼働状況評価部２０１４は、ステップＳ３２０３において、管理対象ホストのノード性能指標を取得する。典型的には、ノード性能指標は管理対象ホスト一覧テーブル４０１に記録されており、これを取得する。そしてステップＳ３２０４において、ＯＳ性能情報から取得した一定のタイムフレームのデータに含まれるメトリックに加えて、ノード性能指標の数値を列挙したものを連結し、ノード性能行列を生成する（Ｓ３２０５）。
【０１４９】
図３３は、第三の実施例における管理対象ホスト一覧のテーブル４０１の一例を示す図である。図９に示す管理対象ホスト一覧テーブル４０１の内容に加えて、プロセッサ数を記録するフィールド４０１５、プロセッサの動作周波数を記録するフィールド４０１６が追加される。これらのフィールドは、ノード性能指標として典型的なものとして例示されているのであって、他にも搭載するメモリの量といった計算資源に関わる情報も同様にノード性能指標として活用しうることは留意されたい。
【実施例４】
【０１５０】
次に、本発明を適用した第四の実施例を説明する。第一の実施例では、正準相関分析、すなわち二つのノード性能行列からその正準相関係数を算出することにより、障害を検知した。第四の実施例では、正準相関分析に限定せず、様々な統計手法を用いて障害検知を行う。
【０１５１】
そもそも本発明の要諦は、情報処理装置より取得した監視データからノード性能行列を生成し、統計手法を用いてそれらの相関を分析するところにある。そして、このような目的に供することのできる統計手法は正準相関分析に限定されるものではない。一般に統計手法の中でも多変量解析として知られる分野では、複数の変数からなるデータ群を対象として、データの分類、次元圧縮、特徴抽出を行う統計手法が研究されてきた。例えば、主成分分析、ユークリッド距離を距離関数とするクラスタ分析、といった手法が知られており、正準相関分析もまたその一例である。
【０１５２】
こうした様々な手法を、監視データを基にした障害検知に適用するにあたっては、ある種の適性が存在する。例えばあるジョブの実行において同一のノード特性を持つノード群について、それらの監視データを時系列データとして捉えてみると、大局的には変動が少ない一方で、局所的にはノード間で互いに同期しない微細な変動を呈する場合がある。このような場合には、例えばノード性能行列についてペアワイズでユークリッド距離を求め、群平均法によってノード間の距離を判定することで、様々に変動する監視データ群から異常なものを検知することができる。
【０１５３】
こうした統計手法は、情報処理装置のメモリ上ではアルゴリズムを実装するプログラムとして実現される。そして、それら様々なアルゴリズム群からジョブの性質に応じて適切なものを選択する方法として、例えば監視データを時系列データのグラフとして監視コンソールスクリーンに図示し、運用管理担当者がその振る舞いを観察し、適切なアルゴリズムを判断、設定するといった方法が考えられる。また、こうしたプロセスをプログラムで自動化することも考えられる。
【０１５４】
他にも、ジョブの性質に応じてアルゴリズムの適性を判定する方法は様々なものが考えられるが、本発明で注目するのは、監視データの分析に基づく障害検知に適用するアルゴリズムについて、様々なものを適宜使い分けることで、より効果的な障害検知を実現し得るという点である。そこで本実施例では、ジョブ、あるいはジョブの中でのノード特性の組によって、それぞれ適用する分析アルゴリズムを選択することで、より効果的に障害検知を行う構成と処理手順を示す。以下、基本的な構成、処理手順は第一の実施例と同一であるため、差異となる部分のみを説明する。
【０１５５】
図３４は、第四の実施例において稼働状況評価部２０１４が使用するテーブルの一例を示す図である。
【０１５６】
図３４Ａは、第四の実施例における分析アルゴリズム付きジョブプロファイルテーブルの一例を示す図である。図２４に示すジョブプロファイルテーブル５０９では、あるノード特性とその比較対象に適用する分析アルゴリズムは暗黙のうちに仮定されていた。一方、図３４Ａに示すジョブプロファイルテーブル５１０は、分析アルゴリズムフィールド５１０１と、閾値データフィールド５１０２を含む。すなわちジョブプロファイルテーブル５１０は、分析アルゴリズムと閾値データを、ジョブ名およびノード特性の組をキーとして検索できるよう記録したものである。
【０１５７】
分析アルゴリズムを記録する分析アルゴリズムフィールド５１０１は、特定のアルゴリズムと一意に対応するＩＤを含む。このアルゴリズムＩＤを記録するテーブルは後述される。
【０１５８】
閾値データを含む閾値データフィールド５１０２は、分析アルゴリズムが障害の発生を判定するために使用するデータを含む。第一の実施例におけるジョブプロファイルテーブル５０９は既定正準相関データを記録していたが、これはその名前が示す通り、正準相関分析に基づく障害検知の処理において必要なデータであった。一方、本実施例にて閾値データを記録する閾値データフィールド５１０２は、分析アルゴリズムフィールド５１０１が含みうる様々な分析アルゴリズムに対応する閾値データを含む。なお、該閾値データは、第一の実施例で相関分析の処理（図２３のステップＳ２３０９）に用いた閾値とは異なる構成要素であることには留意されたい。
【０１５９】
図３４Ｂは、分析アルゴリズムテーブルの一例を示す図である。分析アルゴリズムテーブル５１１は、アルゴリズムＩＤフィールド５１１１、アルゴリズムＩＤに対応する分析アルゴリズムの名称を記録するアルゴリズム名フィールド５１１２、該分析アルゴリズムを実装する関数へのポインタを記録する分析関数ポインタフィールド５１１３、該分析関数の出力である相関値と閾値データを比較する関数へのポインタを記録する閾値判定関数ポインタフィールド５１１４を含む。関数へのポインタとは、監視マネージャ２０１と同様に監視サーバ１１０のメモリ１０２に実装されるプログラムを指示するアドレスであり、例えば分析関数プログラム５１２のメモリ空間上のアドレスである。すなわち分析アルゴリズムテーブル５１１は、アルゴリズムＩＤをキーとして、該アルゴリズムＩＤと一意に対応するある分析アルゴリズムを実装するプログラム、および該分析アルゴリズムが算出する相関値と閾値データを比較するプログラムを検索できるよう記録したものである。アルゴリズム名フィールド５１１２に記録された分析アルゴリズムの名称は、監視コンソール２０２を介した運用管理担当者への情報の提示において使用する。
【０１６０】
前記の関数ポインタは必ずしもメモリ空間上のアドレスである必要はなく、例えば分析関数プログラム５１２は、監視マネージャとはまた異なるユーザプロセス２００として実装され、該プログラムと監視マネージャがプロセス間通信を行うためのエンドポイントをもって関数ポインタと見做してもよい。こうしたプログラムの相互呼び出しに関する多様な技術の中から当業者にとって好適なものを選択してよい。
【０１６１】
ジョブプロファイルテーブル５１０の分析アルゴリズムフィールド５１０１は、システム運用管理装置の動作中に任意のタイミングで書き換えることができる。また、分析アルゴリズムテーブル５１１の関数ポインタを記録するフィールド５１１３および５１１４と、該ポインタが指示するメモリ空間内のアドレスに格納されるプログラムは、同じく任意のタイミングで書き換えることができる。もちろん、監視サーバ１１０のメモリに複数のプログラムを実装しておき、分析アルゴリズムテーブル５１１のフィールドに記録された関数ポインタを、あるプログラムのアドレスから別のプログラムのアドレスへと切り替えることもできる。つまり、並列分散処理システムの稼働中に、適用する分析アルゴリズムを様々に変更することができる。こうした自由度は、並列分散処理システムの複雑さ、あるいは情報処理装置で発生する障害の多様さに適応するために必要なものである。こうしたフィールドの書き換えを行うタイミングの例は後述される。
【０１６２】
稼働状況評価部２０１４は、ジョブプロファイルテーブル５１０および分析アルゴリズムテーブル５１１を、相関分析の処理に供するため監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【０１６３】
図３５は、相関分析の処理手順（ステップＳ１２０５）の別の一例を示す図である。図２３で示した相関分析の処理手順では、分析アルゴリズムとして正準相関分析を用いることを前提とした処理であったが、ここでは、複数の分析アルゴリズムを使い分ける処理を示す。なお、便宜上「相関」という呼称を用いて説明するが、統計学におけるその語義は本実施例で適用する統計手法を限定するものではなく、「相関係数」の上位概念としての「類似度」、あるいは任意の距離空間における「距離」といった概念を含む、より広義のものとして捉えられるべきものである。
【０１６４】
相関分析の処理手順において、仮想グループへの所属の判定から、ノード性能行列の取得まで（ステップＳ３５０１〜ステップＳ３５０６）は、第一の実施例と共通である。すなわち相関分析は管理対象ホスト毎に行い、まず管理対象ホストが仮想グループに属するかを判定し（Ｓ３５０１）、もし仮想グループに属していないとすれば、該管理対象ホストはどのカレントジョブの実行にも関与していないということであり、稼働状況評価の対象外とする（Ｓ３５１３）。次に管理対象ホストのノード性能行列が存在するかを判定し（Ｓ３５０２）、もしＯＳ性能情報が取得されていない等の理由でノード性能行列が生成されず、該管理対象ホストのノード性能行列テーブルが存在しない場合は、稼働状況評価の対象外とする（Ｓ３５１３）。
【０１６５】
次からの処理は、管理対象ホストが属する仮想グループに注目して行う。まず該仮想グループに存在するノード特性を抽出し（Ｓ３５０３）、それらノード特性毎に、該ノード特性を備えるノード群を抽出し（Ｓ３５０４）、そしてそれらノード群から順に１ノードを選択して相関の算出の処理を行う（Ｓ３５０５）。これらの処理に必要な、ノードとノード特性の情報はクラスタマップテーブル５０６から抽出することができる。次いで、ステップＳ３５０５のループにて選択した１ノードについて、該ノードのノード性能行列Ｖnを取得する（Ｓ３５０６）。これ以降の処理が、第一の実施例の差異となる。
【０１６６】
まず、管理対象ホストのノード性能行列Ｖｐと、ステップＳ３５０６にて取得したノード性能行列Ｖｎとを引数として関数ｆ１を実行し、その解ｒを得る（Ｓ３５０７）。関数ｆ１は、ジョブプロファイルテーブル５１０を管理対象ホストと選択したノードのノード特性の組をキーとして検索してアルゴリズムＩＤを取得し、さらに該アルゴリズムＩＤをキーとして分析アルゴリズムテーブル５１１を検索することで取得できる、分析関数ポインタの指示する分析関数プログラムである。典型的には、該分析関数ｆ１はＶｎおよびＶｐを引数に取り、その戻り値をｒとする。このｒは、先に説明した「相関」の値であり、二つのノード性能行列間の類似度あるいは距離を意味する。
【０１６７】
次にジョブプロファイルテーブル５１０を、管理対象ホストと選択したノードのノード特性の組をキーとして検索することで閾値データｔを取得する（Ｓ３５０８）。この閾値ｔは、相関値ｒと比較することを目的としたデータである。
【０１６８】
次にｒおよびｔを引数として関数ｆ２を実行し、その解として真偽値を得（Ｓ３５０９）、もし真であれば閾値を超過していると見做し、カウンタをインクリメントする（Ｓ３５１０）。もし偽であれば閾値を超過していないと見做す。関数ｆ２は、関数ｆ１と同様、ジョブプロファイルテーブル５１０を管理対象ホストと選択したノードのノード特性の組をキーとして検索してアルゴリズムＩＤを取得し、さらに該アルゴリズムＩＤをキーとして分析アルゴリズムテーブル５１１を検索することで取得できる、閾値判定関数ポインタの指示する閾値判定関数プログラムである。典型的には、該閾値判定関数ｆ２はｒおよびｔを引数に取り、真偽値を戻り値とする。
【０１６９】
こうして、相関値の算出と閾値データとの比較を、仮想グループ内の全ノード特性とそれに属するノード群、すなわち仮想グループ内の全ノードに対して行い、結果カウンタの値が仮想グループの(現在注目している管理対象ホストを除いた)ノード数に等しくなった場合（Ｓ３５１１）、当該管理対象ホストでは障害が発生していると判定し、管理対象ホスト一覧のテーブルの該レコードについて障害検知フラグを１に設定する（Ｓ３５１２）。このカウンタの値について、仮想グループのノード数と等しくなったときに限らず、例えば仮想グループのノード数の半数を超えた場合に障害発生とみなす等、その判定の基準として任意のものを設定できるのは第一の実施例と同様である。
【０１７０】
閾値判定関数ｆ２は、ｒおよびｔについて、そのスカラ値としての大小を比較するものとは限らない。例えば、関数ｆ１として正準相関分析を採用する場合であれば、rは正準相関係数ρ１〜ρｎの配列であり、ｔは並列分散処理システムの正常時において一定以上の値である正準相関係数の配列であり、関数ｆ２は配列ｒの要素のうち一定以上の値であるものの要素数ｎ１と配列ｔの要素数ｎ２を比較し、ｎ１＜ｎ２である場合に真を、それ以外の場合に偽を返却するものとなろう。また同様に、ｔをシステム正常時の正準相関係数の配列と、前記の「一定以上の値」を判定する閾値とを格納する構造体としてもよい。これらの例は第一の実施例における正準相関分析に基づいた処理と実質的に同一のものであるが、このように二つの関数ｆ１、ｆ２、そして閾値データｔによって抽象化することで、様々な分析アルゴリズムを適用することができる。
【０１７１】
もしジョブプロファイルテーブル５１０の分析アルゴリズムフィールド５１０１にアルゴリズムＩＤが記録されていない場合は、デフォルトの分析アルゴリズムを使用するように構成してもよい。このようなデフォルトの分析アルゴリズムは、固定されていてもよいし、運用管理担当者が指定してもよい。
【０１７２】
さて、並列分散処理システムの動作中に、任意のタイミングで適用する分析アルゴリズムを変更できることは前述した。どの分析アルゴリズムを適用するかの判断について、これを運用管理担当者の裁量によって行ってもよいし、システム運用管理装置がプログラムによって行ってもよい。本実施例では、まず運用管理担当者が、監視コンソールを介して障害検知に使用する分析アルゴリズムをシステム運用管理装置に指示できるようにする方法の一例を示す。続いて、システム運用管理装置がプログラムによって、障害検知に使用する分析アルゴリズムを判定する方法の一例を示す。
【０１７３】
図３６は、障害検知に使用する分析アルゴリズムを設定する画面の例を示す図である。分析アルゴリズム設定画面６０４は、監視コンソール２０２が監視コンソールスクリーン６００に表示する画面であり、デフォルト分析アルゴリズム選択ドロップダウンボックス６０４１、マルチ分析アルゴリズム使用チェックボックス６０４２、分析アルゴリズム自動判定ラジオボタン６０４３、分析アルゴリズム手動設定ラジオボタン６０４４、カスタム分析アルゴリズム設定テーブル６０４５、カスタム分析アルゴリズム設定ボタン６０４８を備える。カスタム分析アルゴリズム設定テーブル６０４５は、複数のエントリにより構成され、エントリそれぞれは関連付け使用チェックボックス６０４５１、ジョブ名６０４５２、ノード特性の組名６０４５３、分析アルゴリズム名６０４５４の各フィールドを備える。また、分析アルゴリズム設定画面６０４は、分析アルゴリズムリスト表示リンク６０４６、ＯＫ／Ｃａｎｃｅｌボタン６０４７を備える。
【０１７４】
運用管理担当者は、監視コンソール２０２が実装されているクライアント１２０のコンソール１０５に表示される監視コンソールスクリーン６００と、同じくコンソール１０５のヒューマンインタフェースデバイスを用いて、障害検知に使用する分析アルゴリズムを監視マネージャ２０１に対して指定することができる。
【０１７５】
デフォルト分析アルゴリズム選択ドロップダウンボックス６０４１は、システム運用管理装置にプログラムとしてインストールされ、相関分析の処理に適用可能となっている分析アルゴリズムの名称を選択肢として表示し、これを操作することでデフォルトの分析アルゴリズムを選択し監視マネージャに対して指示することができる。デフォルトの分析アルゴリズムは、他に分析アルゴリズムを選択する契機が存在しない場合に適用する。これは例えば、複数種類の分析アルゴリズムを使用するよう指示されていない場合や、初めて実行するジョブであったり、分析アルゴリズムの自動判定を実行する前提となる情報が未だ十分に蓄積されていなかったりといった理由により適用する分析アルゴリズムの自動判定が行われなかった場合や、使用する分析アルゴリズムが手動で設定されていない場合等に、デフォルトの分析アルゴリズムを適用する。また、システム運用管理装置にプログラムとしてインストールされた分析アルゴリズムが１つのみ存在する場合には、デフォルト分析アルゴリズム選択ドロップダウンボックス６０４１は選択肢としてその分析アルゴリズムの名称のみを表示し、デフォルトの分析アルゴリズムとして適用する。
【０１７６】
マルチ分析アルゴリズム使用チェックボックス６０４２をチェックすることで、複数種類の分析アルゴリズムを障害検知に適用するよう指示することができる。マルチ分析アルゴリズム使用チェックボックス６０４２をチェックすることで、以下の分析アルゴリズム設定に関する操作が可能になる。
【０１７７】
分析アルゴリズム自動判定ラジオボタン６０４３を選択すると、監視マネージャに対して、適用する分析アルゴリズムを運用管理担当者による指定に依らずとも判定するよう指示することができる。一方、分析アルゴリズム手動設定ラジオボタン６０４４を選択すると、監視マネージャに対して、運用管理担当者による設定に基づき適用する分析アルゴリズムを変更するよう指示することができる。この二つのラジオボタンは排他関係にあり、同時には選択できないよう構成してある。以降、監視マネージャが前者の指定に従った処理を行うモードを自動判定モード、後者の指定に従った処理を行うモードを手動設定モードと呼称する。
【０１７８】
監視マネージャは自動判定モードに設定されると、収集した監視データとクラスタマップテーブルの情報に基づいて、適用する分析アルゴリズムを判定する。この処理の例は後述される。
【０１７９】
一方、監視マネージャが手動設定モードに設定されると、運用管理担当者の指示に基づいて分析アルゴリズムを適用する。すなわち、分析アルゴリズム手動設定ラジオボタン６０４４を選択すると、カスタム分析アルゴリズム設定テーブル６０４５の操作が可能になる。カスタム分析アルゴリズム設定テーブル６０４５は、ジョブプロファイルテーブル５１０に記録されているジョブ名およびノード特性の組を列挙し、それらに対してどの分析アルゴリズムを適用するかの関連付けを指示するものである。これら関連付けの情報は、カスタム分析アルゴリズム設定テーブルのエントリとして一覧表示され、多数に及ぶ場合はスクロールバーによりその一部のみを表示する。
【０１８０】
エントリの先頭にある関連付け使用チェックボックス６０４５１をチェックすると、該エントリに属する各フィールドの内容に基づく関連付けを有効にする。このチェックボックスを操作することにより、関連付けの適用を一時的に抑止したり、また有効化したり、といった操作が可能になる。
【０１８１】
ジョブ名フィールド６０４５２とノード特性の組名フィールド６０４５３に対して、適用したい分析アルゴリズムを分析アルゴリズム名フィールド６０４５４で選択する。１つのジョブ名に対して、ノード特性の組は１つ以上が存在し得るが、設定がない場合はデフォルトの分析アルゴリズムが適用される。この関連付けは運用管理担当者の明示的な指示がなくとも設定および表示されており、例えば、ノード特性の組名として「Ｄｅｆａｕｌｔ」を、分析アルゴリズム名として、前述のデフォルトの分析アルゴリズムの名称を、いずれも斜体で表示する。
【０１８２】
分析アルゴリズム名フィールドはドロップダウンボックスを兼用しており、関連付けを設定したい分析アルゴリズムを選択できる。表示されている分析アルゴリズムの名称が、デフォルトの分析アルゴリズムである場合にはそれと判別できるよう表示する。例えば、分析アルゴリズム名を斜体で表示する。
【０１８３】
アルゴリズムリスト表示リンク６０４６を選択すると、システム運用管理装置にプログラムとしてインストールされ相関分析の処理に適用可能となっている分析アルゴリズムの名称の一覧を監視コンソールスクリーン６００に表示する。典型的には、このリストは分析アルゴリズム設定画面６０４とは別の画面として表示し、運用管理担当者がカスタム分析アルゴリズム設定テーブルの操作を行うに当たって参考となるよう、分析アルゴリズムの名称、特徴、過去の使用実績等の情報を表示する。また同様の情報は、ヘルプウィンドウ、ツールチップ等、監視コンソール２０２の操作性の観点から見てより好適な手段を選択して表示してもよい。
【０１８４】
カスタム分析アルゴリズム設定ボタン６０４８を押下すると、ジョブ名、ノード特性の組名について分析アルゴリズムとの関連付けを追加する画面を表示する。この画面は、カスタム分析アルゴリズム設定テーブルと同様に、ジョブ名、ノード特性の組を表示するが、クラスタマップテーブル５０６に記録されている監視マネージャにとって既知のジョブとそのノード特性の組を全てエントリとして表示する。そのエントリ群の中から、分析アルゴリズムとの関連付けを設定したいエントリを選択すると、カスタム分析アルゴリズム設定テーブルに該エントリが追加され、分析アルゴリズムとの関連付けの設定が可能となる。この操作で追加したエントリは、ノード特性の組名フィールドに「Ｄｅｆａｕｌｔ」ではなく選択したノード特性の組が表示され、分析アルゴリズム名フィールドは関連付けを設定したい分析アルゴリズムを選択できるようドロップダウンボックスを兼用する。
【０１８５】
監視マネージャは、運用管理担当者が関連付けを設定するにあたって参考になる情報を表示してもよい。これは例えば、後述される分析アルゴリズムの自動判定に用いる方法から得られた自動判定結果を表示したり、ノード特性毎にその代表的な監視データの情報を時系列データのグラフとして表示したり、といった様々な方法を含む。
【０１８６】
運用管理担当者が、ＯＫ／Ｃａｎｃｅｌボタン６０４７のうちＯＫボタンを押下すると、監視コンソールは分析アルゴリズムの関連付けに関する情報を監視マネージャに送信する。これは典型的には、デフォルトの分析アルゴリズムの名称、複数種類の分析アルゴリズム使用の可否、自動判定モードと手動設定モードの別、ジョブ名およびそのノード特性の組名とそれに関連付けられた分析アルゴリズムの名称、といった情報であるが、分析アルゴリズム設定画面の操作の前後で変更された情報の差分のみを送信する等、処理効率を鑑みつつ好適な方法を選択してよい。
【０１８７】
監視マネージャは監視コンソールより受信した情報に基づき、ジョブプロファイルテーブル５１０の分析アルゴリズムフィールド５１０１に分析アルゴリズムＩＤを記録する。併せて閾値データフィールド５１０２に、該分析アルゴリズムに対応する閾値データを記録する。適用する分析アルゴリズムによって、それぞれ対応する閾値データが必要となるが、過去に使用した閾値データを再利用することもあるであろう。そこで、閾値データをメモリに保存、あるいはデータベースに格納しておき、適宜ジョブプロファイルテーブルの閾値データフィールドに複製したり、あるいは該閾値データのメモリ空間上のアドレスやデータベース上の検索キーをもって閾値データフィールドの記録内容としたりしてもよい。
【０１８８】
さて、監視マネージャが自動判定モードに設定されると、収集した監視データとクラスタマップテーブルの情報に基づいて、適用する分析アルゴリズムを判定すると先に述べた。この自動判定の処理の一例について、まずその概念を示し、続いて処理手順を示す。
【０１８９】
図３７は、ある管理対象ホストから収集したＯＳ性能情報を、時系列データとしてグラフに描画した例を示す。横軸は時間の推移であり、縦軸は当該ＯＳ性能情報が含むメトリックの１つ、例えばプロセッサの使用率の変化である。
【０１９０】
図３７Ａは、あるノード特性Ａを備えるノードのメトリックの変動を示すグラフの例である。当該メトリックの変動を、例えば区間７０１で観察すると、その区間での最大値は７０２、最小値は７０３である。一方、図３７Ｂは、また別のノード特性Ｂを備えるノードのメトリックの変動を示す別の例である。同じく区間７０１で観察すると、その区間での最大値は７０４、最小値は７０５である。ここで７０２と７０３の差α、７０４と７０５の差βに注目すると、α》βである。いずれのグラフにおいても、メトリックは微細なレベルで変動しているが、大局的な変動には顕著な違いがある。
【０１９１】
これが意味するところは、図３７Ａに示すようなメトリックの変動を特徴とするノード特性Ａと、図３７Ｂに示すようなメトリックの変動を特徴とするノード特性Ｂにおいては、適用すべき分析アルゴリズムが異なるということである。なぜならば、ノード特性Ａのようなメトリック変動の特徴を備えるノード同士では、その大局的な変動を相関として適切に検出することができるが、一方ノード特性Ｂのようなメトリック変動の特徴を備えるノード同士の場合、典型的な相関分析のアルゴリズムでは相関が検出されないか、よしんば相関を検出したとしても、障害発生時にその相関の変化、典型的には相関の低下によって、それを検出できない可能性が無視できなくなるためである。
【０１９２】
このような理由により、ＯＳ性能情報の変動の特徴を用いた分析アルゴリズムの自動判定が必要となる。前者のようなノード特性に対しては、正準相関分析を一例とする分析アルゴリズム、後者のようなノード特性に対しては、ノード間でのメトリックの相対的な比較に基づく分析アルゴリズムが有効である。
【０１９３】
このような、メトリック変動の特徴に注目した分析アルゴリズム自動判定の方法として、例えば自己相関分析による方法が考えられるが、ここではより簡易な例として、最大値と最小値を用いる方法を示す。
【０１９４】
図３８は、分析アルゴリズム自動判定の処理手順の一例を示す図である。この処理は、監視マネージャが自動判定モードに設定された状態である場合に、任意のタイミングで実行する。
【０１９５】
分析アルゴリズムの自動判定は、典型的には仮想グループ毎に行う。自動判定モードにある監視マネージャは、まずクラスタマップテーブル５０６に記録されているある仮想グループを選択し、さらにその仮想グループからあるノード特性Ｃを備えるノード群を抽出する（Ｓ３８０１）。次に、該ノード群の中からランダムに１つを抽出する（Ｓ３８０２）。この抽出されたノードのＯＳ性能情報を取得し（Ｓ３８０３）、ＯＳ性能情報が含む複数のメトリックの各々について（Ｓ３８０４）、一定のタイムフレームのデータを取得し、その区間内での最大値と最小値を求める（Ｓ３８０５）。次いで最大値と最小値の差、すなわち変動の幅をある一定の閾値と比較し（Ｓ３８０６）、もし変動の幅が閾値を超える場合は、カウンタＡをインクリメントし（Ｓ３８０７）、一方、変動の幅が閾値内に収まる場合は、カウンタＢをインクリメントする（Ｓ３８０８）。
【０１９６】
この変動幅と閾値との比較を全メトリックについて行った後、カウンタＡの値とカウンタＢの値を比較する（Ｓ３８０９）。比較の結果、カウンタＡの方が大きい場合は分析アルゴリズムＡの適用を判定し（Ｓ３８１０）、カウンタＢの方が大きい場合には分析アルゴリズムＢの適用を判定する（Ｓ３８１１）。典型的には、分析アルゴリズムＡは正準相関分析を一例とし、分析アルゴリズムＢは後述されるようなメトリックの平均値に注目するアルゴリズムを一例とする。
【０１９７】
分析アルゴリズムが判定されると、監視マネージャは、ジョブプロファイルテーブル５１０から該仮想グループが実行に関与するジョブ名とノード特性Ｃ同士の組のレコードを検索し、判定した分析アルゴリズムを該レコードの分析アルゴリズムフィールド５１０１に記録し、以降の相関分析の処理に適用する。
【０１９８】
また、あるジョブのあるノード特性について適用する分析アルゴリズムを判定した後、まだ他のノード特性について自動判定の処理が行われていなかった場合、当該分析アルゴリズムを他のノード特性の組に適用する分析アルゴリズムとして併せて記録してもよい。これにより、あるノード特性１つについて適用する分析アルゴリズムを判定すれば、それをデフォルトの分析アルゴリズムに代えて当該ジョブの分析アルゴリズムとして適用することができる。
【０１９９】
さて、前記の自動判定方法は、あるメトリックについて、その最大値と最小値に注目する方法であった。この２つの値は、障害検知のための分析にも活用できる。すなわち変動の少ないメトリックしか得られない場合に適用する分析アルゴリズムの一例を示す。
【０２００】
図３９は、あるノード特性を備える３つの管理対象ホストから収集したＯＳ性能情報を、時系列データとしてグラフに描画した例を示す。横軸は時間の推移であり、縦軸は当該ＯＳ性能情報が含むメトリックの１つ、例えばプロセッサの使用率の変化である。
【０２０１】
図３９において、前記の分析アルゴリズム自動判定の処理を実行することで得られた、あるノード特性Ｃの管理対象ホストにおけるプロセッサ使用率の最大値を７０６、最小値を７０７で示す。また、ノード特性Ｃを備えるある２つの管理対象ホストのプロセッサ使用率を、それぞれ平均値を７０８、７０９で示す。平均値７０８、７０９は、前記７０６と７０７で夾叉される範囲内に収まっていることがわかる。
【０２０２】
一方で、同じくノード特性Ｃを備える、別の管理対象ホストのプロセッサ使用率の平均値を算出してみたところ、７１０であったとしよう。この平均値７１０は、前記７０６と７０７の範囲を逸脱している。これを持って、平均値７１０を呈する当該管理対象ホストでは障害が発生していると判定する。
【０２０３】
この分析アルゴリズムは、ノード毎に平均値の算出とその閾値判定を行うだけであり、前述した相関分析の処理手順より単純であるが、ジョブによっては実用的なレベルで障害検知が可能である。
【０２０４】
以上のようにして、並列分散処理システムの稼働中に、監視マネージャの稼働状況評価部２０１が障害検知に適用する分析アルゴリズムを、運用管理担当者の手動設定によっても、監視マネージャの自動判定によっても、様々に変更することができる。
【０２０５】
また、監視マネージャはその稼働中に、自動判定モードと手動設定モードを相互に遷移することもできる。この場合、モード遷移前にジョブプロファイルテーブル５１０に記録した分析アルゴリズムや閾値データを維持することが望ましいが、モード遷移後に、各々決められた処理に基づいてこれらのデータに変更を加えることは妨げられない。
【０２０６】
以上説明した方法により、第四の実施例は、様々な契機に複数の分析アルゴリズムから１つを選択して適用することで、より効果的な障害検知を実現する。
【０２０７】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０２０８】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ＨＤＤ、ＳＳＤ等の記憶装置、またはＳＤカード、ＤＶＤ−ＲＯＭ等の記憶媒体に置くことができる。
【０２０９】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０２１０】
１００ 情報処理装置
１１０ 監視サーバ
１２０ クライアント
１３０ マスタノード
１４０ ワーカノード
２００ ユーザプロセス
２０１ 監視マネージャ
２０２ 監視コンソール
２０３ ジョブトラッカ
２０４ ネームノード
２０５ 監視エージェント
２０６ タスクトラッカ
２０７ データノード
２０８ リモートモニタ
３００ ＭａｐＲｅｄｕｃｅクラスタ
３０１ ジョブ
３０２ タスク
３０３ データブロック
３０４ スプリット
３０５ Ｍａｐタスク
３０６ 中間ファイル
３０７ Ｒｅｄｕｃｅタスク
３０８ 出力ファイル
３０９ Ｍａｐスロット
３１０ Ｒｅｄｕｃｅスロット
４０１ 管理対象ホスト一覧テーブル
４０２ ＯＳ性能情報
４０３ ＭａｐＲｅｄｕｃｅスケジューリング情報
４０４ ジョブリスト
４０５ タスクリスト
４０６ アテンプトリスト
４０７ データ転送トレース
５０１ 仮想グループテーブル
５０２ 仮想グループノード一覧テーブル
５０３ 仮想グループ
５０４ ノード特性テーブル
５０５ 多相ノード特性テーブル
５０６ クラスタマップテーブル
５０７ ノード特性グループ
５０８ ノード性能行列テーブル
５０９ ジョブプロファイルテーブル
５１０ 分析アルゴリズム付きジョブプロファイルテーブル
５１１ 分析アルゴリズムテーブル
６００ 監視コンソールスクリーン
６０１ プリファレンス設定画面
６０２ イベント通知画面
６０３ クラスタ表示画面
６０４ 分析アルゴリズム設定画面
【技術分野】
【０００１】
情報処理システムの運用管理装置、運用管理方法及び運用管理プログラムに関し、特にシステムの稼働状況を監視し、システムの障害の発生を検知する情報処理システムの運用管理装置、運用管理方法及び運用管理プログラムに関する。
【背景技術】
【０００２】
近年、情報処理システムが企業活動や社会インフラの基盤としてますます重要な位置を占めるようになるにつれ、高い処理能力と高い信頼性を兼備した情報処理システムへの要請はかつてないほど高くなっている。
【０００３】
そうした高度な情報処理システムの実現様態として、多数の情報処理装置をデータセンタ等に設置し、それらを協調動作させることによってシステムとしての目的を達成せしめる並列分散処理システムが普及しつつある。
【０００４】
こうした並列分散処理システムを運用管理するにあたって課題となるのは、システムで発生する障害の検知と対応である。多数の情報処理装置の協調により動作するという特性上、装置の障害の発生はシステム全体の動作に影響を及ぼす。多くのシステムは、このような障害の発生に対する耐性を具備しており、システム全体の停止は回避されるが、それでも性能の劣化や資源の利用効率の低下は避けられない。また、システムが大規模になり、使用する装置の数が増加するに従い、装置の障害発生の頻度は看過できないほどに大きくなる。
【０００５】
こうした障害発生の検知に関わる背景技術として、例えば特許文献１では、「複数の情報処理装置が協調して動作する情報処理システムの性能を監視する性能運用管理装置であって、前記複数の情報処理装置の稼働状況、及び、前記複数の情報処理装置間を接続する各通信回線のデータ通信状況を監視する監視手段と、前記監視手段による監視データに基づいて、前記情報処理システムに現在発生している障害を検知」する装置が開示されている。
【０００６】
また非特許文献１では、仮想化されたシステムにおいて、あるアプリケーションが動作する複数のインスタンスの間で計測データの相関関係を抽出し、その相関の低下によって障害の発生を検知する方法が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００５−３２７２６１号公報
【非特許文献】
【０００８】
【非特許文献１】Hui Kang, Haifeng Chen, and Guofei Jiang. 2010、 PeerWatch: a fault detection and diagnosis tool for virtualized consolidation systems、 In Proceeding of the 7th international conference on Autonomic computing (ICAC '10). ACM, New York, NY, USA, 119-128.
【発明の概要】
【発明が解決しようとする課題】
【０００９】
さて、前述のような並列分散処理システムが普及した理由として、情報処理装置の低廉化により大量に設置、運用が可能になったこと、それら装置の単体性能が著しく向上したことが挙げられる。加えて、そうした情報処理装置の群をひとまとまりとして協調動作させ（こうした群をクラスタと呼称する）、任意の目的のシステムとして活用せしめるにあたり必要となるソフトウェアを、容易に記述できるプログラミング技法が開発されたことが挙げられる。
【００１０】
そうした技法のひとつがＭａｐＲｅｄｕｃｅ方式である。ＭａｐＲｅｄｕｃｅ方式においては、ジョブを多数のタスクに分割し、それぞれのタスクを、クラスタを構成する多数の情報処理装置に分散させて実行するため、並列効果により大幅な実行時間の短縮を期待できる。また、タスクを大きくＭａｐタスクとＲｅｄｕｃｅタスクの２種類に分割し、複数のＭａｐタスク、あるいは複数のＲｅｄｕｃｅタスクそれぞれの間に、処理対象とするデータの相互依存をなくすようになっているため、タスク間の処理の同期を明示してプログラミングする必要がなくなり、タスクスケジューリングを簡素化したのも特徴である。 このＭａｐＲｅｄｕｃｅ方式を活用することで、並列分散処理を活用した多種多様な応用システムが実現可能となり、例えば公共交通機関における電子乗車券の使用履歴から得られるデータを活用した人流分析や、送配電網上に設置されたセンサから得られる電力消費量データを活用した電力需要分析等の応用が考えられる。
【００１１】
並列分散処理システムにおいては、情報処理装置の障害の発生が、システム全体の動作に影響を及ぼすことは前に述べた。ＭａｐＲｅｄｕｃｅ方式は、こうした状況への対策としても有効である。クラスタを構成する情報処理装置のうちひとつに障害が発生し、当該装置で実行中であったタスクが正常に終了しなかったとしよう。その場合でも、別の装置で同じタスクを再実行することで、ジョブ全体の実行は停止させずに完遂することができる。これは、ＭａｐＲｅｄｕｃｅ方式においてはタスク間の相互依存が最小限にとどめられているため、一つのタスクを再実行しても、他のタスクへの影響が極めて少ないためである。
【００１２】
しかしながら、かかる特性を備えたＭａｐＲｅｄｕｃｅ方式のクラスタにおいても、障害の発生を完全に無視できるわけではない。タスク間の相互依存が極小化されているとは言え、タスクの再実行はジョブ全体の実行を遅延せしめる。
【００１３】
また、ある種の障害によっては、タスクが異常終了しないまでも、その実行が本来期待されるものより遅延するという事態が発生しうる。これは例えば、情報処理装置でのスラッシングといった現象の発生によるものがある。このような場合、ＭａｐＲｅｄｕｃｅ方式では、こうしたタスクの実行遅延が発生していることを認識し、同じタスクを別の装置でも実行を開始する。こうした処理を投機的実行と呼称し、開始されるタスクをバックアップタスクと呼ぶ。そして、より先に正常に実行が終了したタスクの出力を処理結果として採用し、そのタスクより遅延しているタスクは強制終了させる。
【００１４】
こうしたバックアップタスク方式は一定の有効性を持つが、それでもなおジョブ全体の実行が遅延することには変わりはない。
【００１５】
また、タスクの異常終了であれ実行遅延であれ、こうした障害が頻発する情報処理装置は、計算資源の浪費を引き起こすものであり、早急に修理・交換を行うことが求められる。
【００１６】
よって、ＭａｐＲｅｄｕｃｅ方式を採用した並列分散処理システムを対象とした障害検知の方法が必要となるが、公知の方法では必ずしも十全とは言えない。
【００１７】
例えば前記特許文献1にて開示される発明においては、複数の情報処理装置から、それぞれ複数種類の監視データを取得し、そこから相関関係を算出することで障害の発生を検知する技術が開示されている。しかし、そうした相関関係を抽出すべき監視データをいかに選択するか、その指針は示していない。該文献に例示されている監視データは、ＤＢサーバにおけるトランザクションのスループットとディスクＩ／Ｏ量といったように、監視対象であるシステムの構成やダイナミクスについて一定の知識を有する者であれば、そこに相関が存在することを見出せるものであるが、つまり障害監視を実行するにあたって、当該システムについてのアプリオリな知識を必要とするものである。
【００１８】
しかるに前述のようなＭａｐＲｅｄｕｃｅ方式の並列分散処理システムにてこの発明を適用しようとすると困難に直面するであろう。なぜならば、ＭａｐＲｅｄｕｃｅ方式においては、ジョブをタスクに分割した後、どのタスクをどの情報処理装置で実行するかは実行時にならないと決定しないからである。この性質ゆえに、ＭａｐＲｅｄｕｃｅ方式はタスクスケジューリングの柔軟さと計算資源の利用効率の向上という利点を得ることができたのであるが、上記のような監視データを基にした障害検知技術の適用を図ろうとすると、どの装置間で相関関係を算出すればよいのか判然としないという問題がある。
【００１９】
また、プログラミング技法としてのＭａｐＲｅｄｕｃｅ方式の利点が、容易に多種多様な並列分散ソフトウェアを構築しうるという点にあるのであれば、ＭａｐＲｅｄｕｃｅ方式の並列分散処理システムは特定少数の応用システムのためのみならず、多様な応用システムのアプリケーションに供用されることも考えられる。その場合、当該クラスタが実行するジョブは、プロセッサ資源を多用するもの、ディスクＩ／Ｏを多用するもの等の特質の差異が生じ、装置にもたらす負荷も多様になるであろう。この結果、上記のようなアプローチによる障害検知技術の適用を図ろうとすると、装置から取得しうる多数の監視データの中から、相関関係算出の対象とすべきものを抽出することが困難となるという問題がある。
【００２０】
さらに、並列分散処理システムが有効に活用されればされるほどに、その規模を拡大するために、新たな情報処理装置が追加導入されることであろう。その結果、近年のように装置の性能面での進歩が急速な時代においては、クラスタを構成する情報処理装置のそれぞれについて、その具備する計算資源が不均一なものとなると考えられる。この点もまた、上記のようなアプローチによる障害検知技術の適用を困難とする。
【００２１】
すなわち、監視データの相関関係を分析することによって障害検知を行うというアプローチでは、どの情報処理装置の、どの監視データを選択しペアとして分析すべきかという問題に対して回答する必要がある。
【００２２】
例えば、前記非特許文献１にて開示される技術においては、正準相関分析（Ｃａｎｏｎｉｃａｌ Ｃｏｒｒｅｌａｔｉｏｎ Ａｎａｌｙｓｉｓ）という統計手法を活用することで、多様な監視データをひとまとまりとして分析の対象としている。この方法は、装置の監視データからどれを選択するかという課題を解決する一例である。しかしながら、前記のような、どの装置の間で相関があるとみなすべきかを判断する問題に対する解とはなっていない。
【００２３】
このように、公知の技術は、並列分散処理システムにおいて障害検知が重要であるにもかかわらず対応できていない。例えば、ＭａｐＲｅｄｕｃｅ方式のクラスタのように、複数の情報処理装置でそれぞれ取得した監視データを基に障害検知を行おうとしても、どの装置の間に相関関係が生じるかが事前に決定せず、またシステムの稼働中に相関関係が生じる組み合わせが変化するようなシステムに対応できていない。
【００２４】
そこで、並列分散処理システムにおいて、障害検知を行う方法、プログラム、装置、システムを提供する。これは例えば、ジョブの多様性や、ジョブの実行スケジューリングの非決定性や、稼働中のシステム構成の変更にも関わらず、障害検知を行うものである。
【課題を解決するための手段】
【００２５】
上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
【００２６】
本願は上記課題を解決する手段を複数含んでいるが、その一例は以下のような構成を有する。
ジョブを複数の情報処理装置で協調して実行する情報処理システムの運用管理装置であって、運用管理装置は、複数の情報処理装置各々から情報を取得するデータ収集部と、複数の情報処理装置に関するデータを記憶する記憶部と、記憶部に記憶されたデータを用いて複数の情報処理装置の状態を評価する評価部を有する。複数の情報処理装置は各々、所定の複数の特性の内のいずれか一の特性を有しており、
データ収集部は、複数の情報処理装置各々から性能情報を取得して前記記憶部に格納する。記憶部は更に、二の情報処理装置がとり得る特性の組み合わせ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶している。評価部は、複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、当該評価対象の情報処理装置以外の複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出すると共に当該評価対象の情報処理装置との特性の組み合わせを特定し、特定された特性の組み合わせについて記憶部に格納されている閾値と算出された相関値とを比較し、比較の結果に基づいて評価対象の情報処理装置の状態を評価する。
【発明の効果】
【００２７】
並列分散処理システムにおいて障害検知が可能となる。例えば、多様なジョブが実行される並列分散処理システムにおいても、障害検知が可能となる。
【００２８】
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００２９】
【図１】情報処理装置の構成の一例を示す図である。
【図２】並列分散処理システムの全体構成の一例を示す図である。
【図３】ＭａｐＲｅｄｕｃｅクラスタの構成の一例を示す図である。
【図４】ＭａｐＲｅｄｕｃｅ方式の処理の実行フローの一例を示す図である。
【図５】タスクトラッカのスロット数の概念の一例を示す図である。
【図６Ａ】監視エージェントの構成の一例を示す図である。
【図６Ｂ】監視エージェントの処理手順の一例を示す図である。
【図７Ａ】監視マネージャの構成の一例を示す図である。
【図７Ｂ】監視エージェントの処理手順の一例を示す図である。
【図８】監視マネージャのデータベースが格納しているテーブル群の一例を示す図である。
【図９】管理対象ホスト一覧テーブルの一例を示す図である。
【図１０Ａ】ＯＳ性能情報を格納するテーブルの一例であるプロセッサ性能情報テーブルの例を示す図である。
【図１０Ｂ】ＯＳ性能情報を格納するテーブルの一例であるメモリ性能情報テーブルの例を示す図である。
【図１０Ｃ】ＯＳ性能情報を格納するテーブルの一例であるディスク性能情報テーブルの例を示す図である。
【図１１Ａ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるジョブリストの一例を示す図である。
【図１１Ｂ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるタスクリストの一例を示す図である。
【図１１Ｃ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるアテンプトリストの一例を示す図である。
【図１１Ｄ】ＭａｐＲｅｄｕｃｅスケジューリング情報の例であるデータ転送トレースの一例を示す図である。
【図１２】稼働状況評価処理手順の一例を示す図である。
【図１３】仮想グループ生成の処理手順の一例を示す図である。
【図１４Ａ】仮想グループテーブルの一例を示す図である。
【図１４Ｂ】仮想グループノード一覧テーブルの例を示す図である。
【図１５】仮想グループの概念の一例を示す図である。
【図１６】ノード特性判定の処理手順の一例を示す図である。
【図１７Ａ】ノード特性判定に用いるテーブルの例を示す図である。
【図１７Ｂ】ノード特性判定に用いるテーブルの他の例を示す図である。
【図１７Ｃ】ノード特性判定に用いるテーブルの設定に用いる画面表示の一例を示す図である。
【図１８】クラスタマップ生成の処理手順の一例を示す図である。
【図１９】クラスタマップテーブルの一例を示す図である。
【図２０】クラスタマップの概念の一例を示す図である。
【図２１】ノード性能行列生成の処理手順の一例を示す図である。
【図２２】ノード性能行列テーブルの一例を示す図である。
【図２３】相関算出の処理手順の一例を示す図である。
【図２４】ジョブプロファイルテーブルの一例を示す図である。
【図２５】イベント通知の処理手順の一例を示す図である。
【図２６】イベント通知の画面表示の一例を示す図である。
【図２７】管理対象ホスト稼働状況表示の処理手順の一例を示す図である。
【図２８Ａ】監視コンソールの画面表示の一例を示す図である。
【図２８Ｂ】監視コンソールの画面表示の他の一例を示す図である。
【図２９Ａ】監視コンソールの画面表示の一例を示す図である。
【図２９Ｂ】監視コンソールの画面表示の他の一例を示す図である。
【図３０】第２の実施形態による並列分散処理システムの全体構成の一例を示す図である。
【図３１】第２の実施形態による監視マネージャとリモートモニタの構成の一例を示す図である。
【図３２】第３の実施形態によるノード性能行列生成の処理手順の一例を示す図である。
【図３３】第３の実施形態による管理対象ホスト一覧テーブルの一例を示す図である。
【図３４Ａ】第４の実施形態によるジョブプロファイルテーブルの一例を示す図である。
【図３４Ｂ】第４の実施形態による分析アルゴリズムテーブルの一例を示す図である。
【図３５】第４の実施形態による相関算出の処理手順の一例を示す図である。
【図３６】第４の実施形態による分析アルゴリズム設定に用いる画面表示の一例を示す図である。
【図３７Ａ】第４の実施形態による分析アルゴリズム自動判定方法の概念の一例を示す図である。
【図３７Ｂ】第４の実施形態による分析アルゴリズム自動判定方法の概念の他の一例を示す図である。
【図３８】第４の実施形態による分析アルゴリズム自動判定の処理手順の一例を示す図である。
【図３９】第４の実施形態による障害検知方法の概念の一例を示す図である。
【発明を実施するための形態】
【００３０】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、以後説明される図面においては、同一部には同一符号を付し、その繰り返しの説明は省略または簡略化される。
【実施例１】
【００３１】
まず、第一の実施例として、障害検知の機能を備えるシステム運用管理装置の例を説明する。
【００３２】
図１は、情報処理装置の構成の一例を示す図である。
【００３３】
情報処理装置１００はプロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５から構成されている。プロセッサ１０１はメモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５と接続されている。ネットワークＩ／Ｆ１０４は、ネットワーク１０６と接続されている。
【００３４】
情報処理装置１００は、例えばラックマウントサーバ、ブレードサーバ、パーソナルコンピュータ等である。また情報処理装置１００は、プロセッサ１０１、メモリ１０２、ストレージ１０３、ネットワークＩ／Ｆ１０４、コンソール１０５を、いずれも複数を備えることがある。また、ストレージ１０３は、例えばハードディスクドライブ（ＨＤＤ）や、ソリッドステートドライブ（ＳＳＤ）等であり、またはこれらを複数台組み合わせたものである。また、ネットワーク１０６は、例えばイーサネット（登録商標）や、ＩＥＥＥ８０２．１１規格に基づく無線ネットワーク等である。
【００３５】
ストレージ１０３は、データを不揮発的に記録し、また読み出すことができる。ネットワークＩ／Ｆ１０４は、それが接続するネットワーク１０６を経由して、他の情報処理装置１００が有するネットワークＩ／Ｆ１０４と通信することができる。コンソール１０５は、ディスプレイ装置を用いてテキスト情報、グラフィカル情報等を表示し、また接続されたヒューマンインタフェースデバイスから情報を受信することができる。
【００３６】
情報処理装置１００は、メモリ１０２にユーザプロセス２００、オペレーティングシステム（ＯＳ）２１０を実装している。ユーザプロセス２００、オペレーティングシステム２１０は、いずれもプログラムであって、情報処理装置１００の有するプロセッサ１０１で実行され、これによって情報処理装置１００はメモリ１０２やストレージ１０３へデータを読み書きし、ネットワークＩ／Ｆ１０４とネットワーク１０６を経由して、他の情報処理装置１００のメモリ２００に実装されているユーザプロセス２００やオペレーティングシステム２１０と通信を行い、コンソール１０５に情報を表示し受信することができる。
【００３７】
本実施例で示すシステム運用管理装置、あるいは並列分散処理システムは図１に示す情報処理装置１００と同様の構成を有する。
【００３８】
図２は、並列分散処理システムの全体構成の一例を示す図である。
【００３９】
監視サーバ１１０、クライアント１２０、マスタノード１３０、ワーカノード１４０は、いずれも情報処理装置１００にそれぞれ特徴のあるユーザプロセス２００を実装したものである。例えば、監視サーバ１１０はユーザプロセスとして監視マネージャ２０１を実装する。クライアント１２０はユーザプロセスとして監視コンソール２０２を実装する。マスタノード１３０はユーザプロセスとしてジョブトラッカ２０３、ネームノード２０４、監視エージェント２０５を実装する。ワーカノード１４０はユーザプロセスとしてタスクトラッカ２０６、データノード２０７、監視エージェント２０５を実装する。また、これら情報処理装置は、ネットワーク１０６を経由して相互に通信が可能である。
【００４０】
ＭａｐＲｅｄｕｃｅクラスタ３００は、マスタノード１３０の１台と、ワーカノード１４０の１台以上を含む。
【００４１】
並列分散処理システムは、監視サーバ１１０、クライアント１２０を複数含むことがある。並列分散処理システムは、ＭａｐＲｅｄｕｃｅクラスタ３００を複数含むことがある。
【００４２】
本実施例におけるシステム運用管理装置とは、監視サーバ１１０と監視マネージャ２０１に加えて、クライアント１２０と監視コンソール２０２、または監視エージェント２０５のいずれかまたは両方から構成される。監視サーバ１１０がクライアント１２０を兼ねることもありうる。情報処理装置とそこに実装されるユーザプロセスの対応関係には自由度があり、本実施例はその多数の組み合わせの中の一例であることは留意されたい。
【００４３】
並列分散処理システムの運用管理担当者は、クライアント１２０が実装する監視コンソール２０２が、コンソール１０５を経由して表示する情報を基にして並列分散処理システムの監視を行う。また監視コンソール２０２は、運用管理担当者がコンソール１０５を経由して入力する情報を受信して監視マネージャに送信し、監視マネージャはその情報を基に動作を変更する。こうした、監視コンソールを介した運用管理担当者とシステム運用管理装置との相互作用の例は後述される。
【００４４】
図３は、ＭａｐＲｅｄｕｃｅクラスタ３００を構成するマスタノード１３０とワーカノード１４０の関係の一例を示す図である。
【００４５】
マスタノード１３０のジョブトラッカ２０３は、ジョブ３０１を実行する。ジョブ３０１は、１つ以上のタスク３０２の集合である。タスク３０２はユーザプロセス２００の一様態であり、ワーカノード１４０では1つ以上のタスク３０２が実行可能である。ジョブトラッカ２０３は、ワーカノード１４０のタスクトラッカ２０６と通信を行う。すなわち、ジョブトラッカ２０３はタスクトラッカ２０６に、タスク３０２の実行を指示する。１つのジョブ３０１を構成するタスク３０２の群を、複数のワーカノード１４０に分散させて並列に実行することによって、処理効率の向上を図るのがＭａｐＲｅｄｕｃｅ方式の主眼である。
【００４６】
ＭａｐＲｅｄｕｃｅクラスタの利用者は、実行すべきジョブ３０１をジョブトラッカ２０３に指示する。指示はマスタノード１３０のコンソール１０５を使用して行ってもよいし、他の情報処理装置１００からネットワーク１０６を経由した通信を行うことで行ってもよい。ジョブトラッカ２０３は、そのジョブ３０１を構成するタスク３０２の群を、その管理下にあるタスクトラッカ２０６に分配し、タスクトラッカ２０６は、分配されたタスク３０２を実行する。
【００４７】
またＭａｐＲｅｄｕｃｅクラスタ３００は、ワーカノード１４０のストレージ１０３にデータを格納する分散ファイルシステムの機能を備える。これはタスク３０２がその処理に必要とするデータを格納するものである。マスタノード１３０のネームノード２０４は、あるデータがどのワーカノード１４０に格納されているかという情報（メタデータ）を持っている。あるデータを必要とするタスク３０２は、ネームノード２０４と通信を行う。すなわち、タスク３０２はネームノード２０４からその必要とするデータに対応するメタデータを取得し、しかる後にそのデータが格納されているワーカノード１４０で動作するデータノード２０７と通信を行い、目的のデータを要求する。データノード２０７は、データをデータブロック３０３の群に分割してストレージ１０３に格納しており、要求されたデータをタスク３０２に転送する。
【００４８】
図４は、ＭａｐＲｅｄｕｃｅ方式のジョブ３０１の実行フローを示す図である。
【００４９】
ジョブ３０１が、１つ以上のタスク３０２の集合であることは先に述べた。タスク３０２は、Ｍａｐタスク３０５とＲｅｄｕｃｅタスク３０７の２つの種別からなる。Ｍａｐタスク３０５は、分散ファイルシステムに置かれた入力ファイルであるスプリット３０４を読み、何らかの処理を行った上で中間ファイル３０６を生成し、これをワーカノード１４０のストレージ１０３に書き込む。この中間ファイル３０６は、キー・バリュー形式のファイルであり、このキーによって、そのデータがどのＲｅｄｕｃｅタスク３０７の入力となるかが決まる。すなわちファイル３０６のバリューにはマップタスク３０５による処理の結果が書き込まれ、キーにはバリューとして書き込まれた値を入力すべきReduceタスク３０７を指定する値が書き込まれる。タスクトラッカ２０６は、Ｒｅｄｕｃｅタスク３０７を実行するワーカノード１４０に、中間ファイル３０６の群から特定のキーを持つデータを転送する。タスクトラッカ２０６は、転送されたデータをソートしたうえでＲｅｄｕｃｅタスク３０７に入力する。Ｒｅｄｕｃｅタスク３０７はそのデータに何らかの処理を行い、その結果を分散ファイルシステム上の出力ファイル３０８として生成する。
【００５０】
図５は、タスクトラッカ２０６のスロット数の概念を示す図である。
【００５１】
タスクトラッカ２０６には「スロット数」の設定がある。これは、ワーカノード１４０において１つのタスクトラッカ２０６が同時に実行するタスク数の上限値であり、Ｍａｐタスク３０５とＲｅｄｕｃｅタスク３０７毎に設定できる。図ではスロット数として各４が設定された状態を示す。これらの値は上限値であり、常にこの値と同数のタスクを実行しているわけではない。タスクトラッカ２０６は、スロット数の設定情報をジョブトラッカ２０３に送り、ジョブトラッカ２０３は、その情報を基に各タスクトラッカ２０６で実行すべきタスクを指定する。
【００５２】
図６は、監視エージェント２０５の構成の一例と、その処理手順の一例を示す図である。
【００５３】
図６Ａは監視エージェント２０５の構成の一例を示す。監視エージェント２０５は、監視データ取得部２０５１、監視データ送信部２０５４から構成される。監視データ取得部２０５１は、ＯＳ性能情報取得部２０５２、ＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０５３を有する。監視エージェント２０５は、多様な監視対象から監視データを取得できるよう、監視データ取得部２０５１は、監視対象に応じた監視データ取得のための機能をプラグインとして使用するように構成されている。本実施例では、監視データ取得部２０５１は、オペレーティングシステム（ＯＳ）２１０からＯＳ性能情報を取得するためのＯＳ性能情報取得部２０５２、ジョブトラッカ２０３とデータノード２０７からＭａｐＲｅｄｕｃｅスケジューリング情報を取得するためのＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０５３を、それぞれプラグインとして使用する。
【００５４】
監視データ送信部２０５４は、監視データ取得部２０５１とそのプラグインが取得した監視データを、監視マネージャ２０１に送信する。送信する手段は、ユニキャストでもマルチキャストでもよい。
【００５５】
図６Ｂは監視エージェント２０５の処理手順の一例を示す。監視エージェント２０５は、ＯＳ性能情報を取得し（Ｓ６０１）、ＭａｐＲｅｄｕｃｅスケジューリング情報を取得し（Ｓ６０２）、取得した監視データを監視マネージャ２０１に送信し（Ｓ６０３）、しかる後に一定の時間ウェイトし（Ｓ６０４）、再びステップＳ６０１を開始する。このように、監視エージェント２０５の処理手順は１つのループ処理であり、稼働している間は一定間隔で監視データを監視マネージャ２０１に送信し続けることになる。
【００５６】
図７は、監視マネージャ２０１の構成の一例と、その処理手順の一例を示す図である。 図７Ａは監視マネージャ２０１の構成の一例を示す。監視マネージャ２０１は、監視データ収集部２０１１、監視データ格納部２０１２、データベース２０１３、稼働状況評価部２０１４、イベント通知部２０１５から構成される。監視データ収集部２０１１は、監視エージェント２０５が送信する監視データを収集する。監視データ格納部２０１２は、収集された監視データをデータベース２０１３に格納する。本実施例では、前述の監視エージェント２０５が送信するＭａｐＲｅｄｕｃｅスケジューリング情報とＯＳ性能情報を格納する。稼働状況評価部２０１４は、データベース２０１３に格納された監視データの情報を基に、並列分散処理システムの稼働状況評価を行い、障害の発生を検知した場合は、イベント通知部２０１５が監視コンソール２０２に対してイベント通知を行う。
【００５７】
図７Ｂは監視マネージャ２０１の処理手順の一例を示す。監視マネージャ２０１の処理は、２つのループ処理からなる。第１のループは、監視エージェント２０５が送信した監視データを受信し（Ｓ７０１）、ＭａｐＲｅｄｕｃｅスケジューリング情報をデータベースに格納し（Ｓ７０２）、ＯＳ性能情報を同じくデータベースに格納する（Ｓ７０３）。第２のループは、データベース２０１３から得られる情報を基に稼働状況評価を行い（Ｓ７０４）、もし障害の発生を検知したならば（Ｓ７０５）、監視コンソール２０２に対してイベント通知を行い（Ｓ７０６）、しかる後に一定時間ウェイトする（Ｓ７０７）。このうちステップＳ７０４、Ｓ７０６については、より詳細な手順を後述する。
【００５８】
上記のように、監視エージェント２０５と監視マネージャ２０１は、定期的に監視データのやりとりのために通信を行う。本実施例では、監視エージェント２０５が監視データを送信するステップＳ６０３の実行をもって、その通信の開始の契機を制御している様態となっているが、該通信の様態はこれに限定されるものではなく、例えば監視マネージャ２０１が定期的に監視エージェント２０５に対して監視データの送信を要求する等もありうる。
【００５９】
図８は、監視マネージャ２０１のデータベース２０１３がその内部に格納しているテーブル群の一例を示す図である。データベース２０１３は、管理対象ホスト一覧のテーブル４０１を格納する。また、ＯＳ性能情報のテーブル群４０２をホスト毎に格納する。また、ＭａｐＲｅｄｕｃｅスケジューリング情報のテーブル群４０３をクラスタ毎に格納する。
【００６０】
図９は、管理対象ホスト一覧のテーブル４０１の一例を示す図である。管理対象ホストとは、監視マネージャ２０１が稼働状況判定の対象とする情報処理装置１０１である。本実施例においては、典型的にはワーカノード１４０の一群であるが、他の情報処理装置１０１もまた管理対象ホストになりうる。
【００６１】
該テーブルの１レコードは１つの管理対象ホストに対応する。該テーブルに管理対象ホストが追加される契機としては、運用管理担当者の操作によるもの、監視エージェント２０５からの通知処理によるもの、監視マネージャ２０１のディスカバリ処理によるもの等が考えられる。
【００６２】
図９では、該テーブルのフィールドのうち、説明に必要なもののみを挙げている。ホスト名フィールド４０１１は、管理対象ホストのホスト名を記録する。代表ＩＰアドレスフィールド４０１２は、管理対象ホストのネットワークＩ／Ｆ１０４のうち１つに付与されたＩＰアドレスを記録する。クラスタ名フィールド４０１３は、管理対象ホストが属するＭａｐＲｅｄｕｃｅクラスタ３００を記録する。障害検知フラグフィールド４０１４は、管理対象ホストで障害の発生が検知されているかを示すフラグを格納する。該テーブルには、監視マネージャの処理にとって必要な情報を記録するための他のフィールドも存在しうることは留意されたい。
【００６３】
図１０は、ＯＳ性能情報のテーブル群４０２の一例を示す図である。ＯＳ性能情報は、監視エージェント２０５がオペレーティングシステム２１０から取得し、監視マネージャ２０１に送信する監視データである。監視マネージャ２０１は、受信したＯＳ性能情報を、データベース２０１３内のテーブル群４０２に格納する。
【００６４】
本実施例では、ＯＳ性能情報のテーブルの個別の例として、プロセッサ性能情報テーブル４０２１、メモリ性能情報テーブル４０２２、ディスク性能情報テーブル４０２３を示す。各テーブルに共通するのは、レコードそれぞれに当該情報を取得した時刻と、情報を取得するインターバルを含むことである。プロセッサやディスクの場合、インターバルは、何秒間の値を累積し算出したものかを示す。
【００６５】
プロセッサ性能情報の場合は、累積値からさらに使用率を算出し記録する。ディスク性能情報の場合は、累積値から単位時間当たりのＩ／Ｏ量を算出し記録する。一方メモリ性能情報の場合は、取得した値はその取得した時点でのスナップショットであり、インターバルは文字通り、情報の取得間隔の意味である。そして、各レコードはさらに詳細な性能情報の項目を複数含む。この項目それぞれをメトリックと呼ぶ。
【００６６】
情報処理装置１０１は、プロセッサ１０１や、ストレージ１０３を構成するディスクを複数搭載することがある。監視エージェント２０５は、オペレーティングシステム２１０からそれらを別個の監視データとして取得し、監視マネージャ２０１がＯＳ性能情報のテーブル群４０２に記録する際には別個のレコードとして記録し、それぞれがプロセッサＩＤやデバイス名で区別特定される。
【００６７】
本実施例では、ＯＳ性能情報の代表的なものとして上記の３つを取り上げたが、これに限定されるものではなく、他にもオペレーティングシステム２１０から取得できる統計情報は、同様にＯＳ性能情報のテーブル群４０２の１つとなりうる。
【００６８】
図１１は、ＭａｐＲｅｄｕｃｅスケジューリング情報のテーブル群４０３の一例を示す図である。ＭａｐＲｅｄｕｃｅスケジューリング情報は、監視エージェント２０５がジョブトラッカ２０３とデータノード２０７から取得し、監視マネージャ２０１に送信する監視データである。監視マネージャ２０１は、受信したＭａｐＲｅｄｕｃｅスケジューリング情報を、データベース２０１３内のテーブル群４０３に格納する。
【００６９】
本実施例では、ＭａｐＲｅｄｕｃｅスケジューリング情報のテーブルとして、ジョブリスト４０４、タスクリスト４０５、アテンプトリスト４０６、データ転送トレース４０７がある。
【００７０】
ＭａｐＲｅｄｕｃｅ方式におけるジョブ３０１とタスク３０２の関係については図３で説明したとおりである。ジョブリスト４０４は、ジョブ１つにつき１レコードを記録する。ジョブはジョブＩＤフィールドに記録されるジョブＩＤにより一意に特定される。タスクリスト４０５は、タスク１つにつき１レコードを記録する。タスクはタスクＩＤフィールドに記録されるタスクＩＤにより一意に特定され、ジョブＩＤフィールドに記録されるジョブＩＤにより、該タスクが属するジョブが特定される。
【００７１】
ＭａｐＲｅｄｕｃｅ方式におけるタスク３０２の実行をアテンプトと呼ぶ。アテンプトリスト４０６は１アテンプトにつき１レコードを記録する。アテンプトはアテンプトＩＤフィールドに記録されるアテンプトＩＤにより一意に特定され、タスクＩＤフィールドに記録されるタスクＩＤにより、該アテンプトの元となるタスクが特定される。通常は1タスクにつき1アテンプトのみが記録されるが、タスクの実行が失敗した場合等にタスクの再実行が行われ、同一のタスクが複数回実行されることがある。この場合は、アテンプトリスト４０６に、同一のタスクＩＤに対して複数回のアテンプトが記録されることになる。アテンプトリスト４０６の実行ノードフィールドには、当該アテンプトを実行したワーカノード１４０のホスト名が記録される。
【００７２】
ＭａｐＲｅｄｕｃｅクラスタ３００が分散ファイルシステムを備えることは前述した。データ転送トレース４０７は、データノード２０７が転送したデータについて記録する。データ転送１回につき１レコードを記録する。
【００７３】
図１２は、監視マネージャの処理手順のうち、稼働状況評価の処理手順（ステップＳ７０４）の一例を示す図である。この図を基に、まず稼働状況評価の処理手順を概説し、それに続いてより詳細な手順を説明する。
【００７４】
稼働状況評価部２０１４は、まずデータベース２０１３から、ＭａｐＲｅｄｕｃｅスケジューリング情報４０３のうち、ジョブリスト４０４、タスクリスト４０５、アテンプトリスト４０６を取得する。この３テーブルのうち、ジョブリスト４０４とタスクリスト４０５はいずれもジョブＩＤのフィールドを含み、タスクリスト４０５とアテンプトリスト４０６はいずれもタスクＩＤのフィールドを含むことが分かる。また、アテンプトリスト４０６は実行ノードのフィールドを含む。よって、これらのフィールドをもって３つのテーブルを結合することで、あるジョブの実行に使用されたワーカノード１４０の群が判別できる。このワーカノード群を抽出する処理が仮想グループの生成（Ｓ１２０１）である。
【００７５】
次に稼働状況評価部２０１４は、データベース２０１３から管理対象ホスト一覧テーブル４０１を取得する。そして管理対象ホスト毎に、先のタスクリスト４０５とアテンプトリスト４０６を使い、該管理対象ホストで実行されていたタスクのタスク種別を求める。次に、データ転送トレース４０７を取得し、そこから得られる該管理対象ホストから転送したデータの情報を加えて、各管理対象ホストのノード特性を判定する（Ｓ１２０２）。 次に稼働状況評価部２０１４は、先に生成した仮想グループと、各管理対象ホストのノード特性を併合しクラスタマップを生成する（Ｓ１２０３）。
【００７６】
そしてクラスタマップを生成すると、次に各管理対象ホストについて、そのＯＳ性能情報４０２からノード性能行列を生成し（Ｓ１２０４）、そのノード性能行列を用いて正準相関係数の算出による相関分析を行う（Ｓ１２０５）。稼働状況評価部２０１４は、その相関分析の結果によって、障害の発生を検知する。もし障害の発生を検知した場合には、処理はイベント通知部２０１５によるイベント通知の処理手順（ステップＳ７０６）に移行する。
【００７７】
以下、上記の各ステップについて詳細な手順を説明する。
【００７８】
図１３は、稼働状況評価の処理手順のうち、仮想グループ生成の処理手順（ステップＳ１２０１）の一例を示す図である。まず稼働状況評価部は、ジョブリスト４０４を取得し（Ｓ１３０１）、そこからステータスがＲＵＮＮＩＮＧであるジョブ、または終了時刻が記録されていないジョブを抽出する（Ｓ１３０２）。これで現在実行中のジョブが抽出される。これらのジョブ群をカレントジョブと呼ぶ。
【００７９】
次にタスクリスト４０５を取得し（Ｓ１３０３）、そこからカレントジョブのジョブＩＤを含むレコードを抽出する（Ｓ１３０４）。さらにステータスがＲＵＮＮＩＮＧ、または終了時刻が記録されていないタスクを抽出する（Ｓ１３０５）。これにより、現在実行中のタスクが抽出される。
【００８０】
次にアテンプトリスト４０６を取得し（Ｓ１３０６）、そこから実行中のタスクのタスクＩＤを含むレコードを抽出し（Ｓ１３０７）、さらにステータスがＲＵＮＮＩＮＧ、または終了時刻が記録されていないアテンプトを抽出する（Ｓ１３０８）。
【００８１】
ここまでで抽出されたレコードのうち、タスクリストから抽出されたレコードにはスプリットのフィールドが、アテンプトリストから抽出されたレコードには実行ノードのフィールドがある。そこで、カレントジョブの各々について、これらの対応関係をそれぞれ仮想グループテーブルに記載する（Ｓ１３１０、Ｓ１３１１）。
【００８２】
図１４Ａは、この仮想グループテーブル５０１の一例を示す図である。
【００８３】
スプリットを含む、または、実行ノードである全ノードを、あるジョブの仮想グループとする（Ｓ１３１２）。すなわち、カレントジョブ1つにつき仮想グループ1つができる。 図１４Ｂは、仮想グループノード一覧テーブル５０２の一例を示す図である。これは仮想グループテーブル５０１から、ジョブＩＤ、ジョブ名、ノード名を取り出したテーブルである。このテーブルにより、ある仮想グループに属するノードを一覧することができる。
【００８４】
稼働状況評価部２０１４は、これら仮想グループテーブル５０１および仮想グループノード一覧テーブル５０２を、後々の処理に供するため監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【００８５】
図１５は、上記の仮想グループの概念を示す図の一例である。仮想グループ５０３には、あるジョブについて、タスク３０２の実行ノードおよびスプリット（Ｍａｐタスクの入力ファイル）３０４を含むノードが所属することになる。
【００８６】
図１６は、ノード特性判定の処理手順（ステップＳ１２０２）の一例を示す図である。 ノード特性の判定とは、ノードが仮想グループにおいてどのような役割を果たしているかを判定するものである。この役割をノード特性と呼称する。判定の材料となるのは、仮想グループ生成のときに作成した、対応関係を記したテーブルと、データ転送トレースである。データ転送トレースの転送先フィールドを参照することで、そのノードが含むスプリットがどこに転送されるものなのかを判定することができる。
【００８７】
ノード特性の判定は、管理対象ホスト毎に行う。まず管理対象ホストが仮想グループに属するかを、仮想グループノード一覧テーブル５０２に基づき判定する（Ｓ１６０１）。仮想グループに属する場合は処理を継続するが、属しない場合は稼働状況評価対象外として処理を終了する（Ｓ１６０７）仮想グループに属する場合、仮想グループテーブル５０１の情報を用いて実行ノードであるかを判定する（Ｓ１６０２）。実行ノードである場合は、そのタスク種別を判定する（Ｓ１６０３）。次に仮想グループテーブル５０１の情報を用いてスプリットを含むかを判定する（Ｓ１６０４）。スプリットを含む場合は、データ転送トレースの情報を用い、そのスプリットの転送先を判定する（Ｓ１６０５）。これらの処理、特にタスク種別の判定Ｓ１６０３と転送先の判定Ｓ１６０５によって得られる情報と、次に示すテーブルを用いてノード特性の判定を行う（Ｓ１６０６）。
【００８８】
図１７は、ノード特性の判定に使用するテーブルの例と、それらの設定に用いる画面表示の例を示す図である。
【００８９】
まず図１７Ａは、もっとも単純なノード特性の分類の例である。この例では、1ノードが1スロット（同時に1タスクしか実行できない）という設定であり、タスク種別はＭａｐ、Ｒｅｄｕｃｅ、Ｎｏｎｅ（実行ノードでない）のいずれか、スプリットの転送先はローカル、リモート、転送なしのいずれかである。
【００９０】
先のステップＳ１６０３、Ｓ１６０５によって得られる情報から、該管理対象ホストがこのテーブル５０４のどの欄に該当するかを判定できる。その欄に記された記号（ＭＬ、ＭＲ等）が、すなわちその管理対象ホストのノード特性である。このテーブル５０４に記されたこれらの記号は、複数のノード特性を区別するために便宜的に定められた記号であり、その用をなすものであればどのような記号の体系を用いても構わない。
【００９１】
図１７Ｂは、いくぶん複雑なノード特性の分類の例である。管理対象ホストは、スプリットを複数含み、それらを様々な転送先に転送することもあるであろう。データ転送トレースの情報から、管理対象ホストがスプリットを転送した転送先とバイト数を得ることができる。これをローカル転送（Ｌ）とリモート転送（Ｒ）に分け、さらにその転送量の比率で６段階に分類する。また、1ノードに複数スロットが設定されている場合、実行されているタスクのタスク種別がＭａｐタスク（Ｍ）であるかＲｅｄｕｃｅタスク（Ｒ）であるか、その数の比率に応じて５段階で、あるいは実行しているタスクがない状態（Ｎｏｎｅ）を加えて６段階で分類する。
【００９２】
こうしたノード特性の判定に使用するテーブルは様々なものが考えうるが、どういったテーブルが適切であるかは、並列分散処理システムによって異なるであろう。そこで、並列分散処理システムの運用管理担当者が、どのようなテーブルを使用するかを監視マネージャに指示できるようにする。
【００９３】
図１７Ｃは、これらノード特性の判定に使用するテーブルを設定するプリファレンス画面の例を示す図である。プリファレンス画面６０１は、監視コンソール２０２が監視コンソールスクリーン６００に表示する画面であり、ノード特性使用チェックボックス６０１１、ノード特性自動判定チェックボックス６０１２、プリセットメソッド使用チェックボックス６０１３、メソッド選択ドロップダウンボックス６０１４、カスタムメソッド作成チェックボックス６０１５、カスタムメソッドテーブル６０１６を備える。カスタムメソッドテーブル６０１６は、複数のエントリにより構成され、エントリそれぞれはメトリクス使用チェックボックス６０１７、メトリクス名６０１８を備える。また、プリファレンス画面６０１は、ＯＫ／Ｃａｎｃｅｌボタン６０１９を備える。
【００９４】
運用管理担当者は、監視コンソール２０２が実装されているクライアント１２０のコンソール１０５に表示される監視コンソールスクリーン６００と、同じくコンソール１０５のヒューマンインタフェースデバイスを用いて、ノード特性の判定に使用するテーブルを指定する。ノード特性使用チェックボックス６０１１をチェックすることで、稼働状況評価にノード特性を適用するよう指示することができる。ノード特性自動判定チェックボックス６０１２をチェックすることで、監視マネージャがノード特性を自動的に判定するよう指示することができる。このノード特性自動判定チェックボックス６０１２をチェックすることで、以下のノード特性判定方法に関わる操作が可能になる。
【００９５】
プリセットメソッド使用チェックボックス６０１３をチェックすることで、あらかじめ監視マネージャに登録されているノード特性判定方法を使用するよう指示することができる。プリセットメソッド使用チェックボックス６０１３をチェックすると、メソッド選択ドロップダウンボックス６０１４が使用できるようになる。このメソッド選択ドロップダウンボックス６０１４を操作することで、あらかじめ登録されているノード特性判定方法のうちどれを使用するかを選択し指示することができる。例えば、管理対象ホストがＭａｐＲｅｄｕｃｅクラスタを構成するノードである場合に適切なノード特性判定方法として「ＭａｐＲｅｄｕｃｅ」という名称の判定方法が登録されていれば、これを選択する。
【００９６】
監視マネージャにあらかじめ登録されているノード特性判定方法では適切ではないと運用管理担当者が判断した場合は、カスタムメソッド作成チェックボックス６０１５をチェックし、カスタム化されたノード特性判定方法を使用するよう指示することができる。カスタムメソッド作成チェックボックス６０１５をチェックすると、カスタムメソッドテーブル６０１６の操作が可能になる。
【００９７】
カスタムメソッドテーブル６０１６は、監視マネージャが監視エージェントから収集する様々な監視データを列挙し、それらのうちどれを用いてノード特性の判定を行うかを指示するものである。監視データはカスタムメソッドテーブル６０１６のエントリとして一覧表示され、多数に及ぶ場合にはスクロールバーによりその一部のみを表示する。各エントリに対応する監視データの名称をメトリクス名６０１８に表示する。各エントリが備えるメトリクス使用チェックボックス６０１７をチェックすると、該エントリに対応する監視データをノード特性判定に使用するよう指示することができる。
【００９８】
運用管理担当者が、カスタムメソッドテーブル６０１６のメトリクス使用チェックボックスのうち適切と判断するものをいくつか選択のうえチェックし、ＯＫ／Ｃａｎｃｅｌボタン６０１９のうちＯＫボタンを押下すると、監視コンソールはそれら選択されたメトリクスの情報を監視マネージャに送信する。監視マネージャはその情報に基づき、ノード特性判定に使用するテーブルを構築し、監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【００９９】
図１８は、クラスタマップ生成の処理手順（ステップＳ１２０３）の一例を示す図である。
【０１００】
クラスタマップは、仮想グループに属するノードをノード特性で分類したものである。まずノード特性判定結果を取得する（Ｓ１８０１）。次に、仮想グループはカレントジョブ1つにつき1つであるので、まずジョブＩＤにてソートする（Ｓ１８０２）。次にノード特性でソートする（Ｓ１８０３）ことで、ノード特性ごとにノードを分類することができる。
【０１０１】
図１９は、クラスタマップテーブルの一例を示す図である。
【０１０２】
クラスタマップテーブル５０６は、図１４Ｂで示した仮想グループノード一覧テーブル５０２にノード特性判定結果を追記し、ノード特性でソートしたものであると言える。
【０１０３】
図２０は、クラスタマップの概念を示す図の一例である。
【０１０４】
クラスタマップ５０３は、ジョブＩＤとジョブ名で識別されるジョブを単位として、そのジョブの実行に関わるノードをノード種別により分類したものである。あるノード特性を備えるノード１４０は、同じノード特性を備えるノードと共にノード特性グループ５０７に属する。
【０１０５】
図２１は、ノード性能行列生成の処理手順（ステップＳ１２０４）の一例を示す図である。
【０１０６】
管理対象ホスト毎に、まずデータベースに該ホストのＯＳ性能情報があるかを判定する（Ｓ２１０１）。もしなければ、稼働状況評価の対象外とする（Ｓ２１０５）。もしあれば、そのＯＳ性能情報から一定のタイムフレームのデータを取得し（Ｓ２１０２）、全てのメトリックを連結し（Ｓ２１０３）、ノード性能行列を生成する（Ｓ２１０４）。
【０１０７】
この手順で示されるように、ノード性能行列とは、そのノードから取得したＯＳ性能情報を連結したものであり、ＯＳ性能情報がデータベースに記録されているホストについて、そのホストの特性をあるタイムフレーム内の資源の使用状況から特徴づけるものである。ここではメトリックを単純に連結したものをノード性能行列として使用しているが、他の例も考えられる。例えば、過去のＯＳ性能情報もデータベースに記録されていることを利用し、指数加重移動平均を算出した上で連結するといった方法も可能である。
【０１０８】
また、このホストの特性を特徴づけるという目的から、タイムフレームを決定する。ＯＳ性能情報には情報取得のインターバルが記録されている。稼働状況評価の処理一回につき各ホストで共通のタイムフレームであれば、どのようなものを使うにせよ、メトリック毎にデータを複数含むようなタイムフレームを選択することが必要である。
【０１０９】
図２２は、ノード性能行列テーブルの一例を示す図である。ノード性能行列テーブルは、ノード性能行列を格納するテーブルであり、稼働状況評価の対象となるノード毎に生成される。上記ステップＳ２１０３で連結したとおり、テーブルの列方向にはＯＳ性能情報の各メトリックが列挙され、テーブルの縦方向には各メトリックのタイムフレーム内のデータが取得時刻順に配置される。この例ではテーブルの最初の行に各メトリックの名称、左端の列にデータの取得時刻を含むが、これはテーブルの内容をわかりやすく示すために記載したものであり、実際のテーブルには必ずしも含む必要はない。
【０１１０】
図２３は、相関分析の処理手順（ステップＳ１２０５）の一例を示す図である。
【０１１１】
相関分析は、管理対象ホスト毎に行う。まず管理対象ホストが仮想グループに属するかを判定する（Ｓ２３０１）。もし仮想グループに属していないとすれば、該管理対象ホストはどのカレントジョブの実行にも関与していないということであり、稼働状況評価の対象外とする（Ｓ２３１４）。次に管理対象ホストのノード性能行列が存在するかを判定する（Ｓ２３０２）。もしＯＳ性能情報が取得されていない等の理由でノード性能行列が生成されず、該管理対象ホストのノード性能行列テーブルが存在しない場合は、稼働状況評価の対象外とする（Ｓ２３１４）。
【０１１２】
次からの処理は、管理対象ホストが属する仮想グループに注目して行う。まず該仮想グループに存在するノード特性を抽出し（Ｓ２３０３）、それらノード特性毎に、該ノード特性を備えるノードを抽出し（Ｓ２３０４）、そしてそれらノード毎に相関係数の算出の処理を行う（Ｓ２３０５）。これらの処理に必要な、ノードとノード特性の情報はクラスタマップテーブル５０６から抽出することができる。
【０１１３】
このように、ある管理対象ホストから見て、ノード特性が自身のそれと同一であるか異なるかに関わらず、自身の属する仮想グループに存在する全てのノード属性との間で相関係数算出の処理を行うことにより、該仮想グループに属するノード特性の構成がいかようであっても対応することができる。
【０１１４】
さて、ステップＳ２３０５にてあるノード特性を備えるノード群から１ノードを選択した後、次に該ノードのノード性能行列Ｖnを取得する（Ｓ２３０６）。そして、管理対象ホストのノード性能行列Vpと、該ノードのノード性能行列Vnとの間の正準相関係数を算出する（Ｓ２３０７）。正準相関係数は、１つ以上の相関係数ρ１〜ρｎとして表わされる。
【０１１５】
この正準相関係数のうち、ある閾値より高いものの数が、カレントジョブのその２つのノード間の関係を示す情報である。この数が、該ジョブの正常時における同一組のノード特性間のそれより小さい場合、当該ノード間の相関が低くなったことを意味する。そして、他の全ノードに対してその現象が観測された場合、管理対象ホストについての障害の検知とみなす。この処理を実行するためには、あるジョブの正常時におけるノード特性間の正準相関係数についての情報が必要であり、そうした情報を既定正準相関データと呼称する。この情報を格納するテーブルをジョブプロファイルテーブルと呼称し、後述される。 相関分析の処理手順の説明に戻る。正準相関係数ρ１〜ρｎを算出したのち、管理対象ホストと選択したノードのノード特性の組をキーとして、ジョブプロファイルテーブルから該ノード特性間の既定正準相関データを取得する（Ｓ２３０８）。次に、ρ１〜ρｎのうち、ある閾値より高いものを選出し（Ｓ２３０９）、そしてその数が既定正準相関データの数より小さいと判定した場合は（Ｓ２３１０）、カウンタをインクリメントする（Ｓ２３１１）。こうして、正準相関係数の算出と既定正準相関データとの比較を、仮想グループ内の全ノード特性とそれに属するノード群、すなわち仮想グループ内の全ノードに対して行い、結果カウンタの値が仮想グループの(現在注目している管理対象ホストを除いた)ノード数に等しくなった場合（Ｓ２３１２）、当該管理対象ホストでは障害が発生していると判定し、管理対象ホスト一覧のテーブルの該レコードについて障害検知フラグを１に設定する（Ｓ２３１３）。
【０１１６】
この処理において必要となる閾値は、１つのクラスタ、あるいは１つのシステム運用管理装置において一貫したものであれば、任意のものを設定できる。また、障害発生の判定に使用するカウンタについて、仮想グループのノード数と等しくなったときに限らず、例えば仮想グループのノード数の半数を超えた場合に障害発生とみなす等、その判定の基準は任意のものを設定できる。こうした自由度は、並列分散処理システムの複雑さ、あるいは情報処理装置で発生する障害の多様さに適応するために必要なものである。
【０１１７】
図２４は、ジョブプロファイルテーブルの一例を示す図である。
【０１１８】
ジョブプロファイルテーブル５０９は、ジョブ名で特定されるジョブについて、そのジョブの実行に関わるノードをノード特性で分類した上で、正常時のそれらのノード同士でノード性能行列の正準相関係数を算出した結果から、既定の閾値より大きい値を記録したもの、すなわち既定正準相関データを、ジョブ名およびノード特性の組をキーとして検索できるよう記録したものである。稼働状況評価部２０１４は、ジョブプロファイルテーブルに既定正準相関データを記録する。この際、前述したようにある閾値より大きい値のみを記録してもよいし、あるいは算出した正準相関係数を全て記録しておき、相関算出の処理を実行するに際して閾値より大きい値のみを取得するようにしてもよい。また、同一のノード特性を持つノードの組は複数の組み合わせがありうるが、それぞれから算出される正準相関係数のうち最も小さい値のものを既定正準相関データとして採用してもよいし、平均値や中央値を算出して採用してもよい。稼働状況評価部２０１４は、ジョブプロファイルテーブル５０９を、後々の相関分析の処理に供するため監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【０１１９】
図２５は、監視マネージャの処理手順のうち、イベント通知の処理手順（Ｓ７０６）の一例を示す図である。
【０１２０】
イベント通知は、管理対象ホストのうち、相関算出の結果障害検知フラグフィールド４０１４が1に設定されたものを抽出し、監視コンソールに当該ホストの情報を通知する処理である。イベント通知部は、まず管理対象ホスト一覧のテーブル４０１を取得し（Ｓ２５０１）、該テーブルの各レコードにつき障害検知フラグフィールド４０１４を調べる（Ｓ２５０２）。そして、該フィールドが１である場合は、そのレコードからホスト名フィールド４０１１を抽出し、監視コンソールに通知する（Ｓ２５０３）。また他のフィールド、例えばクラスタ名フィールド４０１３を、ホスト名フィールドと併せて通知することもできる。
【０１２１】
図２６は、監視コンソールにおけるイベント通知の画面表示の一例を示す図である。
【０１２２】
監視マネージャ２０１のイベント通知部２０１５からの通知を受信した監視コンソール２０２は、クライアント１２０のコンソール１０５に監視コンソールスクリーン６００およびイベント通知画面６０２を表示することで、運用管理担当者に障害の発生を通知する。
【０１２３】
イベント通知画面６０２は、クラスタ名表示６０２１と、該クラスタに属するノードのノード名表示６０２２とノードステータス表示６０２３の組により構成される。監視マネージャが送信したイベント通知がクラスタ名フィールドを含む場合には、監視コンソールスクリーンにノードをクラスタ別に分類して表示することで、運用管理担当者は障害が影響する範囲を容易に把握することができる。このために、クラスタ名表示６０２１が用意される。イベント通知が含むホスト名は、ノード名表示６０２２に表示する。ノードステータス表示６０２３には、監視マネージャが該ノードにおける障害の発生を検知したことを運用管理担当者が認識できるような方法で、それを表示する。例えば文字による表示、色調の変化による表示、あるいはこれらの組み合わせによる表示等の方法がある。また、運用管理担当者が障害への対応を実施するにあたって有用な情報を、併せて表示することができる。
【０１２４】
このイベント通知画面に示されるように、本実施例のシステム運用管理装置は、その管理対象ホストにおける障害の発生を、コンソール１０５を経由した情報表示にて運用管理担当者に通知するが、他にも電子メールの送信による通知や、ブザーの鳴動や回転警告灯の点灯による通知等、様々な方法がありうる。
【０１２５】
図２７は、監視コンソールが管理対象ホストの稼働状況を画面表示する処理手順の一例を示す図である。監視コンソール２０２は、監視マネージャ２０１からのイベント通知処理に依らずとも、管理対象ホストの稼働状況をクライアント１２０のコンソール１０５に表示させることができる。これにより、管理対象ホストにおける障害の発生の有無に関わらず、運用管理担当者は管理対象ホストの稼働状況を監視することができる。
【０１２６】
まず監視コンソール２０２は、管理対象ホスト一覧のテーブル４０１を取得する（Ｓ２７０１）。管理対象ホスト一覧のテーブルは、監視マネージャ２０１のデータベース２０１３に格納されているものを、監視マネージャとの通信によって取得する。次いで、取得した管理対象ホスト一覧から表示対象ホストを抽出する（Ｓ２７０２）。表示対象ホストは、管理対象ホスト一覧のサブセットであり、その抽出には様々な基準を適用しうるが、例えば監視マネージャが監視サーバのメモリにテーブルとして保存している情報を使用することが考えられる。その例は後述される。しかる後に、表示対象ホストの一覧を画面表示に適した表形式に整形し（Ｓ２７０３）、クライアント１２０のコンソール１０５を経由して画面表示を行う（Ｓ２７０４）。
【０１２７】
監視コンソール２０２は、上記のように管理対象ホスト一覧のテーブルや、監視マネージャがメモリに保存しているテーブルを監視マネージャとの通信によって取得するが、これらの処理を管理対象ホストの稼働状況を画面表示する都度実行する必要があるわけでは必ずしもない。監視コンソールは、取得したテーブルをクライアント１２０のメモリ１０２に保存しておき、複数回の画面表示の処理でこれらメモリに保存されたテーブルを再使用することで監視マネージャとのデータ転送量を削減することができる。この場合、クライアントのメモリに保存されたテーブルと、監視サーバのメモリに保存ないしはデータベースに格納されたテーブルとの間で、その内容に齟齬が生じないよう配慮する必要があるが、そのために必要な処理は一般にキャッシュ制御と呼ばれ、当業者には周知のものであろう。
【０１２８】
図２８は、監視コンソールが管理対象ホストの稼働状況を画面表示する一例として、仮想グループノード一覧テーブルの情報を基に表示対象ホストを抽出する画面表示の例を示す図である。
【０１２９】
監視コンソールが仮想グループを画面表示するにあたって、例えば図１５に示すような図を模して表示することも可能であるが、より一覧性の高い例も考えられる。
【０１３０】
図２８Ａは監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、仮想グループノード一覧テーブル５０２の情報を基にして表示する例である。仮想グループノード一覧テーブルは、監視マネージャ２０１の稼働状況評価部２０１４が生成するものであり、監視マネージャは図１４Ｂに示すテーブルとして監視サーバ１１０のメモリに保存している。管理対象ホスト一覧のテーブルとこのテーブルの情報を基に、監視コンソールが仮想グループを単位とした管理対象ホストの稼働状況を監視コンソールスクリーンに画面表示するとすれば、クラスタ名表示６０３１、仮想グループ６０３２、ノード６０３３、を表示する。
【０１３１】
図２８Ｂは、監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、仮想グループノード一覧テーブル５０２の情報を基にして表示する別の例である。この例では、クラスタ名表示６０３１、ノード６０３３、該ノードが実行に関わるジョブ名６０３４、を表示する。監視コンソールが、こうした監視コンソールスクリーン６００をクライアント１２０のコンソール１０５に表示することで、運用管理担当者は管理対象ホストの稼働状況を知ることができる。
【０１３２】
図２９は、監視コンソールが管理対象ホストの稼働状況を画面表示する別の例として、クラスタマップテーブルの情報を基に表示対象ホストを抽出する画面表示の例を示す図である。
【０１３３】
監視コンソールがクラスタマップを画面表示するにあたって、例えば図２０に示すような図を模して表示することも可能であるが、より一覧性の高い例も考えられる。
【０１３４】
図２９Ａは監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、クラスタマップテーブル５０６の情報を基にして表示する例である。クラスタマップテーブルは、監視マネージャ２０１の稼働状況評価部２０１４が生成するものであり、監視マネージャは図１９に示すテーブルとして監視サーバ１１０のメモリに保存している。管理対象ホスト一覧のテーブルとこのテーブルの情報を基に、監視コンソールが仮想グループを単位とした管理対象ホストの稼働状況を監視コンソールスクリーンに画面表示するとすれば、クラスタ名表示６０３１、仮想グループ６０３２、ノード６０３３、ノード属性６０３５、を表示する。
【０１３５】
図２９Ｂは、監視コンソールスクリーン６００に、あるＭａｐＲｅｄｕｃｅクラスタのクラスタ表示画面６０３を、クラスタマップテーブル５０６の情報を基にして表示する別の例である。この例では、クラスタ名表示６０３１、ノード６０３３、該ノードが実行に関わるジョブ名６０３４、該ノードのノード属性ラベル６０３６を表示する。
【０１３６】
以上の説明においては、ジョブ３０１が、Ｍａｐタスク３０５とＲｅｄｕｃｅタスク３０７の２つの種別のタスクを有する場合を例示した。しかしジョブが複数のMapタスクを有し、Reduceタスクを含まない場合にも本発明は上記説明に従って実施可能である。この場合、ノード特性はスプリットの転送先（すなわちデータファイルの特性）によって判定される（図１６）。
【実施例２】
【０１３７】
次に、本発明を適用した第二の実施例を説明する。第一の実施例で示した障害検知の機能を備えるシステム運用管理装置は、管理対象ホストからＯＳ性能情報やＭａｐＲｅｄｕｃｅスケジューリング情報を収集するために、各管理対象ホストに監視エージェントを実装していた。このような監視エージェントは、多くの場合、運用管理担当者が該ホストにインストールするものである。つまり管理対象ホスト数が増加するほど、作業が煩雑になるであろう。また、監視エージェントが該ホストのメモリをいくばくか消費することについて、懸念する向きもあるであろう。
【０１３８】
そこで本実施例では、監視エージェントを使用せずに障害検知を行う例を説明する。基本的な構成は第一の実施例と同一であるため、差異となる部分のみを説明する。
【０１３９】
図３０は、第二の実施例による並列分散処理システムの一例を示す図である。図２に示す、第一の実施例による並列分散処理システムとの差異は、マスタノード１３０やワーカノード１４０が監視エージェントを実装せず、代わりに監視サーバ１１０がリモートモニタ２０８を実装する点である。
【０１４０】
図３１は、第二の実施例における監視マネージャとリモートモニタのブロック構成を示す図の一例である。
【０１４１】
リモートモニタ２０８は、リモート監視データ取得部２０８１、監視データ送信部２０８４から構成される。
【０１４２】
リモート監視データ取得部２０８１は、ＯＳ性能情報取得部２０８２、ＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０８３を有する。リモートモニタ２０８は、多様な監視対象から監視データを取得できるよう、リモート監視データ取得部２０８１が、監視対象に応じた監視データ取得のための機能をプラグインとして使用するように構成されている。本実施例では、リモート監視データ取得部２０８１は、オペレーティングシステム（ＯＳ）２１０からＯＳ性能情報を取得するためのＯＳ性能情報取得部２０８２、ジョブトラッカ２０３とデータノード２０７からＭａｐＲｅｄｕｃｅスケジューリング情報を取得するためのＭａｐＲｅｄｕｃｅスケジューリング情報取得部２０８３を、それぞれプラグインとして使用する。
【０１４３】
監視データ送信部２０８４は、リモート監視データ取得部２０８１とそのプラグインが取得した監視データを、監視マネージャ２０１に送信する。監視マネージャ２０１の監視データ収集部２０１１は、リモートモニタ２０８が送信する監視データを収集する。
【０１４４】
プラグインは、それぞれの方法で情報を取得する。その例として、ＯＳ性能情報の場合は、ＳＳＨ（登録商標）とＯＳコマンド、あるいはＳＮＭＰを使うといった方法がある。ＭａｐＲｅｄｕｃｅスケジューリング情報の場合は、ＳＳＨでジョブトラッカやデータノードのログファイルを収集するといった方法がある。いずれにしても、取得する情報については第一の実施例における監視エージェントの実装するプラグインと変わりはない。
【０１４５】
監視データ送信部２０８４が、監視マネージャ２０１に監視データを送信する方法としては、例えばソケット、ＲＰＣ、ＨＴＴＰといったプロセス間通信の方法によるものがある。
【０１４６】
以上説明したような方法で、第二の実施例は監視エージェントを実装せずに、本発明を並列分散処理システムに適用する。
【実施例３】
【０１４７】
次に、本発明を適用した第三の実施例を説明する。第一の実施例では、ノード性能行列生成において管理対象ホストから収集されるＯＳ性能情報の監視データを使用した。第三の実施例では、これに加えて、管理対象ホストのノード性能指標を使用する。ノード性能指標とは、情報処理装置の備えるプロセッサ、メモリといった計算資源の個別の性能を数値によって表現したものである。例えばプロセッサについては、ある管理対象ホストが備えるプロセッサの個数、動作周波数といったものがノード性能指標である。本実施例は、この情報を使用することで、その具備する計算資源において多様性のある情報処理装置により構成される並列分散処理システムを対象にした障害検知をより効果的に行うことを狙いとするものである。以下、基本的な構成は第一の実施例と同一であるため、差異となる部分のみを説明する。
【０１４８】
図３２は、第三の実施例におけるノード性能行列生成の処理手順の一例を示す図である。図２１に示す処理手順に加えて、ステップＳ３２０３が追加される。監視マネージャ２０１の稼働状況評価部２０１４は、ステップＳ３２０３において、管理対象ホストのノード性能指標を取得する。典型的には、ノード性能指標は管理対象ホスト一覧テーブル４０１に記録されており、これを取得する。そしてステップＳ３２０４において、ＯＳ性能情報から取得した一定のタイムフレームのデータに含まれるメトリックに加えて、ノード性能指標の数値を列挙したものを連結し、ノード性能行列を生成する（Ｓ３２０５）。
【０１４９】
図３３は、第三の実施例における管理対象ホスト一覧のテーブル４０１の一例を示す図である。図９に示す管理対象ホスト一覧テーブル４０１の内容に加えて、プロセッサ数を記録するフィールド４０１５、プロセッサの動作周波数を記録するフィールド４０１６が追加される。これらのフィールドは、ノード性能指標として典型的なものとして例示されているのであって、他にも搭載するメモリの量といった計算資源に関わる情報も同様にノード性能指標として活用しうることは留意されたい。
【実施例４】
【０１５０】
次に、本発明を適用した第四の実施例を説明する。第一の実施例では、正準相関分析、すなわち二つのノード性能行列からその正準相関係数を算出することにより、障害を検知した。第四の実施例では、正準相関分析に限定せず、様々な統計手法を用いて障害検知を行う。
【０１５１】
そもそも本発明の要諦は、情報処理装置より取得した監視データからノード性能行列を生成し、統計手法を用いてそれらの相関を分析するところにある。そして、このような目的に供することのできる統計手法は正準相関分析に限定されるものではない。一般に統計手法の中でも多変量解析として知られる分野では、複数の変数からなるデータ群を対象として、データの分類、次元圧縮、特徴抽出を行う統計手法が研究されてきた。例えば、主成分分析、ユークリッド距離を距離関数とするクラスタ分析、といった手法が知られており、正準相関分析もまたその一例である。
【０１５２】
こうした様々な手法を、監視データを基にした障害検知に適用するにあたっては、ある種の適性が存在する。例えばあるジョブの実行において同一のノード特性を持つノード群について、それらの監視データを時系列データとして捉えてみると、大局的には変動が少ない一方で、局所的にはノード間で互いに同期しない微細な変動を呈する場合がある。このような場合には、例えばノード性能行列についてペアワイズでユークリッド距離を求め、群平均法によってノード間の距離を判定することで、様々に変動する監視データ群から異常なものを検知することができる。
【０１５３】
こうした統計手法は、情報処理装置のメモリ上ではアルゴリズムを実装するプログラムとして実現される。そして、それら様々なアルゴリズム群からジョブの性質に応じて適切なものを選択する方法として、例えば監視データを時系列データのグラフとして監視コンソールスクリーンに図示し、運用管理担当者がその振る舞いを観察し、適切なアルゴリズムを判断、設定するといった方法が考えられる。また、こうしたプロセスをプログラムで自動化することも考えられる。
【０１５４】
他にも、ジョブの性質に応じてアルゴリズムの適性を判定する方法は様々なものが考えられるが、本発明で注目するのは、監視データの分析に基づく障害検知に適用するアルゴリズムについて、様々なものを適宜使い分けることで、より効果的な障害検知を実現し得るという点である。そこで本実施例では、ジョブ、あるいはジョブの中でのノード特性の組によって、それぞれ適用する分析アルゴリズムを選択することで、より効果的に障害検知を行う構成と処理手順を示す。以下、基本的な構成、処理手順は第一の実施例と同一であるため、差異となる部分のみを説明する。
【０１５５】
図３４は、第四の実施例において稼働状況評価部２０１４が使用するテーブルの一例を示す図である。
【０１５６】
図３４Ａは、第四の実施例における分析アルゴリズム付きジョブプロファイルテーブルの一例を示す図である。図２４に示すジョブプロファイルテーブル５０９では、あるノード特性とその比較対象に適用する分析アルゴリズムは暗黙のうちに仮定されていた。一方、図３４Ａに示すジョブプロファイルテーブル５１０は、分析アルゴリズムフィールド５１０１と、閾値データフィールド５１０２を含む。すなわちジョブプロファイルテーブル５１０は、分析アルゴリズムと閾値データを、ジョブ名およびノード特性の組をキーとして検索できるよう記録したものである。
【０１５７】
分析アルゴリズムを記録する分析アルゴリズムフィールド５１０１は、特定のアルゴリズムと一意に対応するＩＤを含む。このアルゴリズムＩＤを記録するテーブルは後述される。
【０１５８】
閾値データを含む閾値データフィールド５１０２は、分析アルゴリズムが障害の発生を判定するために使用するデータを含む。第一の実施例におけるジョブプロファイルテーブル５０９は既定正準相関データを記録していたが、これはその名前が示す通り、正準相関分析に基づく障害検知の処理において必要なデータであった。一方、本実施例にて閾値データを記録する閾値データフィールド５１０２は、分析アルゴリズムフィールド５１０１が含みうる様々な分析アルゴリズムに対応する閾値データを含む。なお、該閾値データは、第一の実施例で相関分析の処理（図２３のステップＳ２３０９）に用いた閾値とは異なる構成要素であることには留意されたい。
【０１５９】
図３４Ｂは、分析アルゴリズムテーブルの一例を示す図である。分析アルゴリズムテーブル５１１は、アルゴリズムＩＤフィールド５１１１、アルゴリズムＩＤに対応する分析アルゴリズムの名称を記録するアルゴリズム名フィールド５１１２、該分析アルゴリズムを実装する関数へのポインタを記録する分析関数ポインタフィールド５１１３、該分析関数の出力である相関値と閾値データを比較する関数へのポインタを記録する閾値判定関数ポインタフィールド５１１４を含む。関数へのポインタとは、監視マネージャ２０１と同様に監視サーバ１１０のメモリ１０２に実装されるプログラムを指示するアドレスであり、例えば分析関数プログラム５１２のメモリ空間上のアドレスである。すなわち分析アルゴリズムテーブル５１１は、アルゴリズムＩＤをキーとして、該アルゴリズムＩＤと一意に対応するある分析アルゴリズムを実装するプログラム、および該分析アルゴリズムが算出する相関値と閾値データを比較するプログラムを検索できるよう記録したものである。アルゴリズム名フィールド５１１２に記録された分析アルゴリズムの名称は、監視コンソール２０２を介した運用管理担当者への情報の提示において使用する。
【０１６０】
前記の関数ポインタは必ずしもメモリ空間上のアドレスである必要はなく、例えば分析関数プログラム５１２は、監視マネージャとはまた異なるユーザプロセス２００として実装され、該プログラムと監視マネージャがプロセス間通信を行うためのエンドポイントをもって関数ポインタと見做してもよい。こうしたプログラムの相互呼び出しに関する多様な技術の中から当業者にとって好適なものを選択してよい。
【０１６１】
ジョブプロファイルテーブル５１０の分析アルゴリズムフィールド５１０１は、システム運用管理装置の動作中に任意のタイミングで書き換えることができる。また、分析アルゴリズムテーブル５１１の関数ポインタを記録するフィールド５１１３および５１１４と、該ポインタが指示するメモリ空間内のアドレスに格納されるプログラムは、同じく任意のタイミングで書き換えることができる。もちろん、監視サーバ１１０のメモリに複数のプログラムを実装しておき、分析アルゴリズムテーブル５１１のフィールドに記録された関数ポインタを、あるプログラムのアドレスから別のプログラムのアドレスへと切り替えることもできる。つまり、並列分散処理システムの稼働中に、適用する分析アルゴリズムを様々に変更することができる。こうした自由度は、並列分散処理システムの複雑さ、あるいは情報処理装置で発生する障害の多様さに適応するために必要なものである。こうしたフィールドの書き換えを行うタイミングの例は後述される。
【０１６２】
稼働状況評価部２０１４は、ジョブプロファイルテーブル５１０および分析アルゴリズムテーブル５１１を、相関分析の処理に供するため監視サーバ１１０のメモリ１０２に保存する。または、データベース２０１３に格納してもよい。
【０１６３】
図３５は、相関分析の処理手順（ステップＳ１２０５）の別の一例を示す図である。図２３で示した相関分析の処理手順では、分析アルゴリズムとして正準相関分析を用いることを前提とした処理であったが、ここでは、複数の分析アルゴリズムを使い分ける処理を示す。なお、便宜上「相関」という呼称を用いて説明するが、統計学におけるその語義は本実施例で適用する統計手法を限定するものではなく、「相関係数」の上位概念としての「類似度」、あるいは任意の距離空間における「距離」といった概念を含む、より広義のものとして捉えられるべきものである。
【０１６４】
相関分析の処理手順において、仮想グループへの所属の判定から、ノード性能行列の取得まで（ステップＳ３５０１〜ステップＳ３５０６）は、第一の実施例と共通である。すなわち相関分析は管理対象ホスト毎に行い、まず管理対象ホストが仮想グループに属するかを判定し（Ｓ３５０１）、もし仮想グループに属していないとすれば、該管理対象ホストはどのカレントジョブの実行にも関与していないということであり、稼働状況評価の対象外とする（Ｓ３５１３）。次に管理対象ホストのノード性能行列が存在するかを判定し（Ｓ３５０２）、もしＯＳ性能情報が取得されていない等の理由でノード性能行列が生成されず、該管理対象ホストのノード性能行列テーブルが存在しない場合は、稼働状況評価の対象外とする（Ｓ３５１３）。
【０１６５】
次からの処理は、管理対象ホストが属する仮想グループに注目して行う。まず該仮想グループに存在するノード特性を抽出し（Ｓ３５０３）、それらノード特性毎に、該ノード特性を備えるノード群を抽出し（Ｓ３５０４）、そしてそれらノード群から順に１ノードを選択して相関の算出の処理を行う（Ｓ３５０５）。これらの処理に必要な、ノードとノード特性の情報はクラスタマップテーブル５０６から抽出することができる。次いで、ステップＳ３５０５のループにて選択した１ノードについて、該ノードのノード性能行列Ｖnを取得する（Ｓ３５０６）。これ以降の処理が、第一の実施例の差異となる。
【０１６６】
まず、管理対象ホストのノード性能行列Ｖｐと、ステップＳ３５０６にて取得したノード性能行列Ｖｎとを引数として関数ｆ１を実行し、その解ｒを得る（Ｓ３５０７）。関数ｆ１は、ジョブプロファイルテーブル５１０を管理対象ホストと選択したノードのノード特性の組をキーとして検索してアルゴリズムＩＤを取得し、さらに該アルゴリズムＩＤをキーとして分析アルゴリズムテーブル５１１を検索することで取得できる、分析関数ポインタの指示する分析関数プログラムである。典型的には、該分析関数ｆ１はＶｎおよびＶｐを引数に取り、その戻り値をｒとする。このｒは、先に説明した「相関」の値であり、二つのノード性能行列間の類似度あるいは距離を意味する。
【０１６７】
次にジョブプロファイルテーブル５１０を、管理対象ホストと選択したノードのノード特性の組をキーとして検索することで閾値データｔを取得する（Ｓ３５０８）。この閾値ｔは、相関値ｒと比較することを目的としたデータである。
【０１６８】
次にｒおよびｔを引数として関数ｆ２を実行し、その解として真偽値を得（Ｓ３５０９）、もし真であれば閾値を超過していると見做し、カウンタをインクリメントする（Ｓ３５１０）。もし偽であれば閾値を超過していないと見做す。関数ｆ２は、関数ｆ１と同様、ジョブプロファイルテーブル５１０を管理対象ホストと選択したノードのノード特性の組をキーとして検索してアルゴリズムＩＤを取得し、さらに該アルゴリズムＩＤをキーとして分析アルゴリズムテーブル５１１を検索することで取得できる、閾値判定関数ポインタの指示する閾値判定関数プログラムである。典型的には、該閾値判定関数ｆ２はｒおよびｔを引数に取り、真偽値を戻り値とする。
【０１６９】
こうして、相関値の算出と閾値データとの比較を、仮想グループ内の全ノード特性とそれに属するノード群、すなわち仮想グループ内の全ノードに対して行い、結果カウンタの値が仮想グループの(現在注目している管理対象ホストを除いた)ノード数に等しくなった場合（Ｓ３５１１）、当該管理対象ホストでは障害が発生していると判定し、管理対象ホスト一覧のテーブルの該レコードについて障害検知フラグを１に設定する（Ｓ３５１２）。このカウンタの値について、仮想グループのノード数と等しくなったときに限らず、例えば仮想グループのノード数の半数を超えた場合に障害発生とみなす等、その判定の基準として任意のものを設定できるのは第一の実施例と同様である。
【０１７０】
閾値判定関数ｆ２は、ｒおよびｔについて、そのスカラ値としての大小を比較するものとは限らない。例えば、関数ｆ１として正準相関分析を採用する場合であれば、rは正準相関係数ρ１〜ρｎの配列であり、ｔは並列分散処理システムの正常時において一定以上の値である正準相関係数の配列であり、関数ｆ２は配列ｒの要素のうち一定以上の値であるものの要素数ｎ１と配列ｔの要素数ｎ２を比較し、ｎ１＜ｎ２である場合に真を、それ以外の場合に偽を返却するものとなろう。また同様に、ｔをシステム正常時の正準相関係数の配列と、前記の「一定以上の値」を判定する閾値とを格納する構造体としてもよい。これらの例は第一の実施例における正準相関分析に基づいた処理と実質的に同一のものであるが、このように二つの関数ｆ１、ｆ２、そして閾値データｔによって抽象化することで、様々な分析アルゴリズムを適用することができる。
【０１７１】
もしジョブプロファイルテーブル５１０の分析アルゴリズムフィールド５１０１にアルゴリズムＩＤが記録されていない場合は、デフォルトの分析アルゴリズムを使用するように構成してもよい。このようなデフォルトの分析アルゴリズムは、固定されていてもよいし、運用管理担当者が指定してもよい。
【０１７２】
さて、並列分散処理システムの動作中に、任意のタイミングで適用する分析アルゴリズムを変更できることは前述した。どの分析アルゴリズムを適用するかの判断について、これを運用管理担当者の裁量によって行ってもよいし、システム運用管理装置がプログラムによって行ってもよい。本実施例では、まず運用管理担当者が、監視コンソールを介して障害検知に使用する分析アルゴリズムをシステム運用管理装置に指示できるようにする方法の一例を示す。続いて、システム運用管理装置がプログラムによって、障害検知に使用する分析アルゴリズムを判定する方法の一例を示す。
【０１７３】
図３６は、障害検知に使用する分析アルゴリズムを設定する画面の例を示す図である。分析アルゴリズム設定画面６０４は、監視コンソール２０２が監視コンソールスクリーン６００に表示する画面であり、デフォルト分析アルゴリズム選択ドロップダウンボックス６０４１、マルチ分析アルゴリズム使用チェックボックス６０４２、分析アルゴリズム自動判定ラジオボタン６０４３、分析アルゴリズム手動設定ラジオボタン６０４４、カスタム分析アルゴリズム設定テーブル６０４５、カスタム分析アルゴリズム設定ボタン６０４８を備える。カスタム分析アルゴリズム設定テーブル６０４５は、複数のエントリにより構成され、エントリそれぞれは関連付け使用チェックボックス６０４５１、ジョブ名６０４５２、ノード特性の組名６０４５３、分析アルゴリズム名６０４５４の各フィールドを備える。また、分析アルゴリズム設定画面６０４は、分析アルゴリズムリスト表示リンク６０４６、ＯＫ／Ｃａｎｃｅｌボタン６０４７を備える。
【０１７４】
運用管理担当者は、監視コンソール２０２が実装されているクライアント１２０のコンソール１０５に表示される監視コンソールスクリーン６００と、同じくコンソール１０５のヒューマンインタフェースデバイスを用いて、障害検知に使用する分析アルゴリズムを監視マネージャ２０１に対して指定することができる。
【０１７５】
デフォルト分析アルゴリズム選択ドロップダウンボックス６０４１は、システム運用管理装置にプログラムとしてインストールされ、相関分析の処理に適用可能となっている分析アルゴリズムの名称を選択肢として表示し、これを操作することでデフォルトの分析アルゴリズムを選択し監視マネージャに対して指示することができる。デフォルトの分析アルゴリズムは、他に分析アルゴリズムを選択する契機が存在しない場合に適用する。これは例えば、複数種類の分析アルゴリズムを使用するよう指示されていない場合や、初めて実行するジョブであったり、分析アルゴリズムの自動判定を実行する前提となる情報が未だ十分に蓄積されていなかったりといった理由により適用する分析アルゴリズムの自動判定が行われなかった場合や、使用する分析アルゴリズムが手動で設定されていない場合等に、デフォルトの分析アルゴリズムを適用する。また、システム運用管理装置にプログラムとしてインストールされた分析アルゴリズムが１つのみ存在する場合には、デフォルト分析アルゴリズム選択ドロップダウンボックス６０４１は選択肢としてその分析アルゴリズムの名称のみを表示し、デフォルトの分析アルゴリズムとして適用する。
【０１７６】
マルチ分析アルゴリズム使用チェックボックス６０４２をチェックすることで、複数種類の分析アルゴリズムを障害検知に適用するよう指示することができる。マルチ分析アルゴリズム使用チェックボックス６０４２をチェックすることで、以下の分析アルゴリズム設定に関する操作が可能になる。
【０１７７】
分析アルゴリズム自動判定ラジオボタン６０４３を選択すると、監視マネージャに対して、適用する分析アルゴリズムを運用管理担当者による指定に依らずとも判定するよう指示することができる。一方、分析アルゴリズム手動設定ラジオボタン６０４４を選択すると、監視マネージャに対して、運用管理担当者による設定に基づき適用する分析アルゴリズムを変更するよう指示することができる。この二つのラジオボタンは排他関係にあり、同時には選択できないよう構成してある。以降、監視マネージャが前者の指定に従った処理を行うモードを自動判定モード、後者の指定に従った処理を行うモードを手動設定モードと呼称する。
【０１７８】
監視マネージャは自動判定モードに設定されると、収集した監視データとクラスタマップテーブルの情報に基づいて、適用する分析アルゴリズムを判定する。この処理の例は後述される。
【０１７９】
一方、監視マネージャが手動設定モードに設定されると、運用管理担当者の指示に基づいて分析アルゴリズムを適用する。すなわち、分析アルゴリズム手動設定ラジオボタン６０４４を選択すると、カスタム分析アルゴリズム設定テーブル６０４５の操作が可能になる。カスタム分析アルゴリズム設定テーブル６０４５は、ジョブプロファイルテーブル５１０に記録されているジョブ名およびノード特性の組を列挙し、それらに対してどの分析アルゴリズムを適用するかの関連付けを指示するものである。これら関連付けの情報は、カスタム分析アルゴリズム設定テーブルのエントリとして一覧表示され、多数に及ぶ場合はスクロールバーによりその一部のみを表示する。
【０１８０】
エントリの先頭にある関連付け使用チェックボックス６０４５１をチェックすると、該エントリに属する各フィールドの内容に基づく関連付けを有効にする。このチェックボックスを操作することにより、関連付けの適用を一時的に抑止したり、また有効化したり、といった操作が可能になる。
【０１８１】
ジョブ名フィールド６０４５２とノード特性の組名フィールド６０４５３に対して、適用したい分析アルゴリズムを分析アルゴリズム名フィールド６０４５４で選択する。１つのジョブ名に対して、ノード特性の組は１つ以上が存在し得るが、設定がない場合はデフォルトの分析アルゴリズムが適用される。この関連付けは運用管理担当者の明示的な指示がなくとも設定および表示されており、例えば、ノード特性の組名として「Ｄｅｆａｕｌｔ」を、分析アルゴリズム名として、前述のデフォルトの分析アルゴリズムの名称を、いずれも斜体で表示する。
【０１８２】
分析アルゴリズム名フィールドはドロップダウンボックスを兼用しており、関連付けを設定したい分析アルゴリズムを選択できる。表示されている分析アルゴリズムの名称が、デフォルトの分析アルゴリズムである場合にはそれと判別できるよう表示する。例えば、分析アルゴリズム名を斜体で表示する。
【０１８３】
アルゴリズムリスト表示リンク６０４６を選択すると、システム運用管理装置にプログラムとしてインストールされ相関分析の処理に適用可能となっている分析アルゴリズムの名称の一覧を監視コンソールスクリーン６００に表示する。典型的には、このリストは分析アルゴリズム設定画面６０４とは別の画面として表示し、運用管理担当者がカスタム分析アルゴリズム設定テーブルの操作を行うに当たって参考となるよう、分析アルゴリズムの名称、特徴、過去の使用実績等の情報を表示する。また同様の情報は、ヘルプウィンドウ、ツールチップ等、監視コンソール２０２の操作性の観点から見てより好適な手段を選択して表示してもよい。
【０１８４】
カスタム分析アルゴリズム設定ボタン６０４８を押下すると、ジョブ名、ノード特性の組名について分析アルゴリズムとの関連付けを追加する画面を表示する。この画面は、カスタム分析アルゴリズム設定テーブルと同様に、ジョブ名、ノード特性の組を表示するが、クラスタマップテーブル５０６に記録されている監視マネージャにとって既知のジョブとそのノード特性の組を全てエントリとして表示する。そのエントリ群の中から、分析アルゴリズムとの関連付けを設定したいエントリを選択すると、カスタム分析アルゴリズム設定テーブルに該エントリが追加され、分析アルゴリズムとの関連付けの設定が可能となる。この操作で追加したエントリは、ノード特性の組名フィールドに「Ｄｅｆａｕｌｔ」ではなく選択したノード特性の組が表示され、分析アルゴリズム名フィールドは関連付けを設定したい分析アルゴリズムを選択できるようドロップダウンボックスを兼用する。
【０１８５】
監視マネージャは、運用管理担当者が関連付けを設定するにあたって参考になる情報を表示してもよい。これは例えば、後述される分析アルゴリズムの自動判定に用いる方法から得られた自動判定結果を表示したり、ノード特性毎にその代表的な監視データの情報を時系列データのグラフとして表示したり、といった様々な方法を含む。
【０１８６】
運用管理担当者が、ＯＫ／Ｃａｎｃｅｌボタン６０４７のうちＯＫボタンを押下すると、監視コンソールは分析アルゴリズムの関連付けに関する情報を監視マネージャに送信する。これは典型的には、デフォルトの分析アルゴリズムの名称、複数種類の分析アルゴリズム使用の可否、自動判定モードと手動設定モードの別、ジョブ名およびそのノード特性の組名とそれに関連付けられた分析アルゴリズムの名称、といった情報であるが、分析アルゴリズム設定画面の操作の前後で変更された情報の差分のみを送信する等、処理効率を鑑みつつ好適な方法を選択してよい。
【０１８７】
監視マネージャは監視コンソールより受信した情報に基づき、ジョブプロファイルテーブル５１０の分析アルゴリズムフィールド５１０１に分析アルゴリズムＩＤを記録する。併せて閾値データフィールド５１０２に、該分析アルゴリズムに対応する閾値データを記録する。適用する分析アルゴリズムによって、それぞれ対応する閾値データが必要となるが、過去に使用した閾値データを再利用することもあるであろう。そこで、閾値データをメモリに保存、あるいはデータベースに格納しておき、適宜ジョブプロファイルテーブルの閾値データフィールドに複製したり、あるいは該閾値データのメモリ空間上のアドレスやデータベース上の検索キーをもって閾値データフィールドの記録内容としたりしてもよい。
【０１８８】
さて、監視マネージャが自動判定モードに設定されると、収集した監視データとクラスタマップテーブルの情報に基づいて、適用する分析アルゴリズムを判定すると先に述べた。この自動判定の処理の一例について、まずその概念を示し、続いて処理手順を示す。
【０１８９】
図３７は、ある管理対象ホストから収集したＯＳ性能情報を、時系列データとしてグラフに描画した例を示す。横軸は時間の推移であり、縦軸は当該ＯＳ性能情報が含むメトリックの１つ、例えばプロセッサの使用率の変化である。
【０１９０】
図３７Ａは、あるノード特性Ａを備えるノードのメトリックの変動を示すグラフの例である。当該メトリックの変動を、例えば区間７０１で観察すると、その区間での最大値は７０２、最小値は７０３である。一方、図３７Ｂは、また別のノード特性Ｂを備えるノードのメトリックの変動を示す別の例である。同じく区間７０１で観察すると、その区間での最大値は７０４、最小値は７０５である。ここで７０２と７０３の差α、７０４と７０５の差βに注目すると、α》βである。いずれのグラフにおいても、メトリックは微細なレベルで変動しているが、大局的な変動には顕著な違いがある。
【０１９１】
これが意味するところは、図３７Ａに示すようなメトリックの変動を特徴とするノード特性Ａと、図３７Ｂに示すようなメトリックの変動を特徴とするノード特性Ｂにおいては、適用すべき分析アルゴリズムが異なるということである。なぜならば、ノード特性Ａのようなメトリック変動の特徴を備えるノード同士では、その大局的な変動を相関として適切に検出することができるが、一方ノード特性Ｂのようなメトリック変動の特徴を備えるノード同士の場合、典型的な相関分析のアルゴリズムでは相関が検出されないか、よしんば相関を検出したとしても、障害発生時にその相関の変化、典型的には相関の低下によって、それを検出できない可能性が無視できなくなるためである。
【０１９２】
このような理由により、ＯＳ性能情報の変動の特徴を用いた分析アルゴリズムの自動判定が必要となる。前者のようなノード特性に対しては、正準相関分析を一例とする分析アルゴリズム、後者のようなノード特性に対しては、ノード間でのメトリックの相対的な比較に基づく分析アルゴリズムが有効である。
【０１９３】
このような、メトリック変動の特徴に注目した分析アルゴリズム自動判定の方法として、例えば自己相関分析による方法が考えられるが、ここではより簡易な例として、最大値と最小値を用いる方法を示す。
【０１９４】
図３８は、分析アルゴリズム自動判定の処理手順の一例を示す図である。この処理は、監視マネージャが自動判定モードに設定された状態である場合に、任意のタイミングで実行する。
【０１９５】
分析アルゴリズムの自動判定は、典型的には仮想グループ毎に行う。自動判定モードにある監視マネージャは、まずクラスタマップテーブル５０６に記録されているある仮想グループを選択し、さらにその仮想グループからあるノード特性Ｃを備えるノード群を抽出する（Ｓ３８０１）。次に、該ノード群の中からランダムに１つを抽出する（Ｓ３８０２）。この抽出されたノードのＯＳ性能情報を取得し（Ｓ３８０３）、ＯＳ性能情報が含む複数のメトリックの各々について（Ｓ３８０４）、一定のタイムフレームのデータを取得し、その区間内での最大値と最小値を求める（Ｓ３８０５）。次いで最大値と最小値の差、すなわち変動の幅をある一定の閾値と比較し（Ｓ３８０６）、もし変動の幅が閾値を超える場合は、カウンタＡをインクリメントし（Ｓ３８０７）、一方、変動の幅が閾値内に収まる場合は、カウンタＢをインクリメントする（Ｓ３８０８）。
【０１９６】
この変動幅と閾値との比較を全メトリックについて行った後、カウンタＡの値とカウンタＢの値を比較する（Ｓ３８０９）。比較の結果、カウンタＡの方が大きい場合は分析アルゴリズムＡの適用を判定し（Ｓ３８１０）、カウンタＢの方が大きい場合には分析アルゴリズムＢの適用を判定する（Ｓ３８１１）。典型的には、分析アルゴリズムＡは正準相関分析を一例とし、分析アルゴリズムＢは後述されるようなメトリックの平均値に注目するアルゴリズムを一例とする。
【０１９７】
分析アルゴリズムが判定されると、監視マネージャは、ジョブプロファイルテーブル５１０から該仮想グループが実行に関与するジョブ名とノード特性Ｃ同士の組のレコードを検索し、判定した分析アルゴリズムを該レコードの分析アルゴリズムフィールド５１０１に記録し、以降の相関分析の処理に適用する。
【０１９８】
また、あるジョブのあるノード特性について適用する分析アルゴリズムを判定した後、まだ他のノード特性について自動判定の処理が行われていなかった場合、当該分析アルゴリズムを他のノード特性の組に適用する分析アルゴリズムとして併せて記録してもよい。これにより、あるノード特性１つについて適用する分析アルゴリズムを判定すれば、それをデフォルトの分析アルゴリズムに代えて当該ジョブの分析アルゴリズムとして適用することができる。
【０１９９】
さて、前記の自動判定方法は、あるメトリックについて、その最大値と最小値に注目する方法であった。この２つの値は、障害検知のための分析にも活用できる。すなわち変動の少ないメトリックしか得られない場合に適用する分析アルゴリズムの一例を示す。
【０２００】
図３９は、あるノード特性を備える３つの管理対象ホストから収集したＯＳ性能情報を、時系列データとしてグラフに描画した例を示す。横軸は時間の推移であり、縦軸は当該ＯＳ性能情報が含むメトリックの１つ、例えばプロセッサの使用率の変化である。
【０２０１】
図３９において、前記の分析アルゴリズム自動判定の処理を実行することで得られた、あるノード特性Ｃの管理対象ホストにおけるプロセッサ使用率の最大値を７０６、最小値を７０７で示す。また、ノード特性Ｃを備えるある２つの管理対象ホストのプロセッサ使用率を、それぞれ平均値を７０８、７０９で示す。平均値７０８、７０９は、前記７０６と７０７で夾叉される範囲内に収まっていることがわかる。
【０２０２】
一方で、同じくノード特性Ｃを備える、別の管理対象ホストのプロセッサ使用率の平均値を算出してみたところ、７１０であったとしよう。この平均値７１０は、前記７０６と７０７の範囲を逸脱している。これを持って、平均値７１０を呈する当該管理対象ホストでは障害が発生していると判定する。
【０２０３】
この分析アルゴリズムは、ノード毎に平均値の算出とその閾値判定を行うだけであり、前述した相関分析の処理手順より単純であるが、ジョブによっては実用的なレベルで障害検知が可能である。
【０２０４】
以上のようにして、並列分散処理システムの稼働中に、監視マネージャの稼働状況評価部２０１が障害検知に適用する分析アルゴリズムを、運用管理担当者の手動設定によっても、監視マネージャの自動判定によっても、様々に変更することができる。
【０２０５】
また、監視マネージャはその稼働中に、自動判定モードと手動設定モードを相互に遷移することもできる。この場合、モード遷移前にジョブプロファイルテーブル５１０に記録した分析アルゴリズムや閾値データを維持することが望ましいが、モード遷移後に、各々決められた処理に基づいてこれらのデータに変更を加えることは妨げられない。
【０２０６】
以上説明した方法により、第四の実施例は、様々な契機に複数の分析アルゴリズムから１つを選択して適用することで、より効果的な障害検知を実現する。
【０２０７】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０２０８】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ＨＤＤ、ＳＳＤ等の記憶装置、またはＳＤカード、ＤＶＤ−ＲＯＭ等の記憶媒体に置くことができる。
【０２０９】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【０２１０】
１００ 情報処理装置
１１０ 監視サーバ
１２０ クライアント
１３０ マスタノード
１４０ ワーカノード
２００ ユーザプロセス
２０１ 監視マネージャ
２０２ 監視コンソール
２０３ ジョブトラッカ
２０４ ネームノード
２０５ 監視エージェント
２０６ タスクトラッカ
２０７ データノード
２０８ リモートモニタ
３００ ＭａｐＲｅｄｕｃｅクラスタ
３０１ ジョブ
３０２ タスク
３０３ データブロック
３０４ スプリット
３０５ Ｍａｐタスク
３０６ 中間ファイル
３０７ Ｒｅｄｕｃｅタスク
３０８ 出力ファイル
３０９ Ｍａｐスロット
３１０ Ｒｅｄｕｃｅスロット
４０１ 管理対象ホスト一覧テーブル
４０２ ＯＳ性能情報
４０３ ＭａｐＲｅｄｕｃｅスケジューリング情報
４０４ ジョブリスト
４０５ タスクリスト
４０６ アテンプトリスト
４０７ データ転送トレース
５０１ 仮想グループテーブル
５０２ 仮想グループノード一覧テーブル
５０３ 仮想グループ
５０４ ノード特性テーブル
５０５ 多相ノード特性テーブル
５０６ クラスタマップテーブル
５０７ ノード特性グループ
５０８ ノード性能行列テーブル
５０９ ジョブプロファイルテーブル
５１０ 分析アルゴリズム付きジョブプロファイルテーブル
５１１ 分析アルゴリズムテーブル
６００ 監視コンソールスクリーン
６０１ プリファレンス設定画面
６０２ イベント通知画面
６０３ クラスタ表示画面
６０４ 分析アルゴリズム設定画面
【特許請求の範囲】
【請求項１】
ジョブを複数の情報処理装置で協調して実行する情報処理システムの運用管理装置であって、
前記複数の情報処理装置各々から情報を取得するデータ収集部と、
前記複数の情報処理装置に関するデータを記憶する記憶部と、
前記記憶部に記憶されたデータを用いて前記複数の情報処理装置の状態を評価する評価部を有しており、
前記複数の情報処理装置は各々、所定の複数の特性の内のいずれか一の特性を有しており、
前記データ収集部は、前記複数の情報処理装置各々から性能情報を取得して前記記憶部に格納し、
前記記憶部は更に、二の情報処理装置がとり得る特性の組み合わせ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶しており、
前記評価部は、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、
当該評価対象の情報処理装置以外の前記複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出すると共に当該評価対象の情報処理装置との特性の組み合わせを特定し、特定された特性の組み合わせについて前記記憶部に格納されている閾値と算出された前記相関値とを比較し、
前記比較の結果に基づいて前記評価対象の情報処理装置の状態を評価することを特徴とする運用管理装置。
【請求項２】
請求項１記載の運用管理装置であって、前記ジョブは複数のタスクおよび複数のデータファイルから構成されており、
前記所定の複数の特性は、情報処理装置が実行するタスクの種別および前記情報処理装置が入出力するデータファイルの特性に基づいて定まる特性であることを特徴とする運用管理装置。
【請求項３】
請求項２記載の運用管理装置であって、前記ジョブはMapReduce方式のジョブであって、当該ジョブはMapタスクとReduceタスクとを有しており、
前記所定の複数の特性は、情報処理装置が実行するタスクがMapタスクとReduceタスクのいずれであるか、および当該タスクの実行に伴うデータファイルの転送の種別に基づいて定まる特性であることを特徴とする運用管理装置。
【請求項４】
請求項２記載の運用管理装置であって、
前記データ収集部は、前記情報処理システムで実行されるジョブ毎に、当該ジョブを実行する複数の情報処理装置各々について、当該情報処理装置が実行するタスクの種別および当該情報処理装置が入出力するデータファイルの特性を取得し、
前記評価部は、前記データ収集部が収集したタスクの種別およびデータファイルの特性に基づいて、前記複数の情報処理装置各々の特性を特定することを特徴とする運用管理装置。
【請求項５】
請求項１記載の運用管理装置であって、
前記記憶部に格納される閾値は、前記データ収集部が前記複数の情報処理装置から収集した性能情報を用いて前記評価部が算出した値であることを特徴とする運用管理装置。
【請求項６】
請求項５記載の運用管理装置であって、
前記性能情報には、前記情報処理装置を構成する計算資源の性能指標が含まれることを特徴とする運用管理装置。
【請求項７】
請求項１記載の運用管理装置であって、
前記評価部は、前記記憶部に格納されている閾値と算出された前記相関値との比較に基づいて、前記情報処理装置における異常の発生を判定することを特徴とする運用管理装置。
【請求項８】
請求項１記載の運用管理装置であって、前記ジョブは複数のタスクおよび複数のデータファイルから構成されており、
前記所定の複数の特性は、前記情報処理装置が入出力するデータファイルの特性に基づいて定まる特性であることを特徴とする運用管理装置。
【請求項９】
請求項1記載の運用管理装置であって、
前記記憶部は前記二の情報処理装置がとり得る特性の組み合わせ各々について、当該二の情報処理装置の性能情報の相関値を算出する相関値算出手段と、前記相関値算出手段を用いて算出される相関値と前記閾値を比較する閾値判定手段とを記憶しており、
前記評価部は、前記相関値算出手段を用いて前記性能情報の相関値を算出し、前記閾値判定手段を用いて前記相関値と前記閾値を比較することを特徴とする運用管理装置。
【請求項１０】
請求項９記載の運用管理装置であって、
前記記憶部は、複数の前記相関値算出手段と、複数の前記閾値判定手段とを記憶しており、
前記評価部は、前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、
当該評価対象の情報処理装置から収集した性能情報の最大値と最小値を算出し、
前記最大値と前記最小値の差に基づいて、前記相関値算出手段と、前記閾値判定手段とをそれぞれ切り替えることを特徴とする運用管理装置。
【請求項１１】
請求項１０記載の運用管理装置であって、
前記記憶部は、前記性能情報の最大値と最小値を記憶しており、
前記評価部は、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、当該評価対象の情報処理装置から収集した性能情報の平均値を算出し、
前記平均値と、前記最大値と前記最小値それぞれとの比較に基づいて異常の発生を判定することを特徴とする運用管理装置。
【請求項１２】
所定の複数の特性の内のいずれか一つの特性を有する複数の情報処理装置でジョブを協調して実行する情報処理システムの運用管理方法であって、
前記複数の情報処理装置と通信可能に接続された運用管理装置が、
前記複数の情報処理装置のうち二の情報処理装置がとり得る特性の組合せ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶し、
前記複数の情報処理装置各々から性能情報を取得し、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、
当該評価対象の情報処理装置以外の前記複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出し、
当該評価対象の情報処理装置との特性の組み合わせを特定して、特定された特性の組み合わせについて前記閾値と算出された前記相関値とを比較し、
前記比較の結果に基づいて前記評価対象の情報処理装置の状態を評価する
ことを含むことを特徴とする運用管理方法。
【請求項１３】
所定の複数の特性の内のいずれか一つの特性を有する複数の情報処理装置でジョブを協調して実行する情報処理システムの前記情報処理装置と通信可能に接続された運用管理装置に、
前記複数の情報処理装置のうち二の情報処理装置がとり得る特性の組合せ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶させる手順と、
前記複数の情報処理装置各々から性能情報を取得させる手順と、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価させる場合に、
当該評価対象の情報処理装置以外の前記複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出させる手順と、
当該評価対象の情報処理装置との特性の組み合わせを特定させ、特定させた特性の組み合わせについて前記閾値と算出させた前記相関値とを比較させる手順と、
前記比較の結果に基づいて前記評価対象の情報処理装置の状態を評価させる手順と
を実行させることを特徴とする運用管理プログラム。
【請求項１】
ジョブを複数の情報処理装置で協調して実行する情報処理システムの運用管理装置であって、
前記複数の情報処理装置各々から情報を取得するデータ収集部と、
前記複数の情報処理装置に関するデータを記憶する記憶部と、
前記記憶部に記憶されたデータを用いて前記複数の情報処理装置の状態を評価する評価部を有しており、
前記複数の情報処理装置は各々、所定の複数の特性の内のいずれか一の特性を有しており、
前記データ収集部は、前記複数の情報処理装置各々から性能情報を取得して前記記憶部に格納し、
前記記憶部は更に、二の情報処理装置がとり得る特性の組み合わせ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶しており、
前記評価部は、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、
当該評価対象の情報処理装置以外の前記複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出すると共に当該評価対象の情報処理装置との特性の組み合わせを特定し、特定された特性の組み合わせについて前記記憶部に格納されている閾値と算出された前記相関値とを比較し、
前記比較の結果に基づいて前記評価対象の情報処理装置の状態を評価することを特徴とする運用管理装置。
【請求項２】
請求項１記載の運用管理装置であって、前記ジョブは複数のタスクおよび複数のデータファイルから構成されており、
前記所定の複数の特性は、情報処理装置が実行するタスクの種別および前記情報処理装置が入出力するデータファイルの特性に基づいて定まる特性であることを特徴とする運用管理装置。
【請求項３】
請求項２記載の運用管理装置であって、前記ジョブはMapReduce方式のジョブであって、当該ジョブはMapタスクとReduceタスクとを有しており、
前記所定の複数の特性は、情報処理装置が実行するタスクがMapタスクとReduceタスクのいずれであるか、および当該タスクの実行に伴うデータファイルの転送の種別に基づいて定まる特性であることを特徴とする運用管理装置。
【請求項４】
請求項２記載の運用管理装置であって、
前記データ収集部は、前記情報処理システムで実行されるジョブ毎に、当該ジョブを実行する複数の情報処理装置各々について、当該情報処理装置が実行するタスクの種別および当該情報処理装置が入出力するデータファイルの特性を取得し、
前記評価部は、前記データ収集部が収集したタスクの種別およびデータファイルの特性に基づいて、前記複数の情報処理装置各々の特性を特定することを特徴とする運用管理装置。
【請求項５】
請求項１記載の運用管理装置であって、
前記記憶部に格納される閾値は、前記データ収集部が前記複数の情報処理装置から収集した性能情報を用いて前記評価部が算出した値であることを特徴とする運用管理装置。
【請求項６】
請求項５記載の運用管理装置であって、
前記性能情報には、前記情報処理装置を構成する計算資源の性能指標が含まれることを特徴とする運用管理装置。
【請求項７】
請求項１記載の運用管理装置であって、
前記評価部は、前記記憶部に格納されている閾値と算出された前記相関値との比較に基づいて、前記情報処理装置における異常の発生を判定することを特徴とする運用管理装置。
【請求項８】
請求項１記載の運用管理装置であって、前記ジョブは複数のタスクおよび複数のデータファイルから構成されており、
前記所定の複数の特性は、前記情報処理装置が入出力するデータファイルの特性に基づいて定まる特性であることを特徴とする運用管理装置。
【請求項９】
請求項1記載の運用管理装置であって、
前記記憶部は前記二の情報処理装置がとり得る特性の組み合わせ各々について、当該二の情報処理装置の性能情報の相関値を算出する相関値算出手段と、前記相関値算出手段を用いて算出される相関値と前記閾値を比較する閾値判定手段とを記憶しており、
前記評価部は、前記相関値算出手段を用いて前記性能情報の相関値を算出し、前記閾値判定手段を用いて前記相関値と前記閾値を比較することを特徴とする運用管理装置。
【請求項１０】
請求項９記載の運用管理装置であって、
前記記憶部は、複数の前記相関値算出手段と、複数の前記閾値判定手段とを記憶しており、
前記評価部は、前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、
当該評価対象の情報処理装置から収集した性能情報の最大値と最小値を算出し、
前記最大値と前記最小値の差に基づいて、前記相関値算出手段と、前記閾値判定手段とをそれぞれ切り替えることを特徴とする運用管理装置。
【請求項１１】
請求項１０記載の運用管理装置であって、
前記記憶部は、前記性能情報の最大値と最小値を記憶しており、
前記評価部は、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、当該評価対象の情報処理装置から収集した性能情報の平均値を算出し、
前記平均値と、前記最大値と前記最小値それぞれとの比較に基づいて異常の発生を判定することを特徴とする運用管理装置。
【請求項１２】
所定の複数の特性の内のいずれか一つの特性を有する複数の情報処理装置でジョブを協調して実行する情報処理システムの運用管理方法であって、
前記複数の情報処理装置と通信可能に接続された運用管理装置が、
前記複数の情報処理装置のうち二の情報処理装置がとり得る特性の組合せ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶し、
前記複数の情報処理装置各々から性能情報を取得し、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価する場合に、
当該評価対象の情報処理装置以外の前記複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出し、
当該評価対象の情報処理装置との特性の組み合わせを特定して、特定された特性の組み合わせについて前記閾値と算出された前記相関値とを比較し、
前記比較の結果に基づいて前記評価対象の情報処理装置の状態を評価する
ことを含むことを特徴とする運用管理方法。
【請求項１３】
所定の複数の特性の内のいずれか一つの特性を有する複数の情報処理装置でジョブを協調して実行する情報処理システムの前記情報処理装置と通信可能に接続された運用管理装置に、
前記複数の情報処理装置のうち二の情報処理装置がとり得る特性の組合せ各々について、当該二の情報処理装置の性能情報の相関関係についての閾値を記憶させる手順と、
前記複数の情報処理装置各々から性能情報を取得させる手順と、
前記複数の情報処理装置のうち一の評価対象の情報処理装置について当該評価対象の情報処理装置の状態を評価させる場合に、
当該評価対象の情報処理装置以外の前記複数の情報処理装置各々について、当該評価対象の情報処理装置との性能情報の相関値を算出させる手順と、
当該評価対象の情報処理装置との特性の組み合わせを特定させ、特定させた特性の組み合わせについて前記閾値と算出させた前記相関値とを比較させる手順と、
前記比較の結果に基づいて前記評価対象の情報処理装置の状態を評価させる手順と
を実行させることを特徴とする運用管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１０Ｃ】
【図１１Ａ】
【図１１Ｂ】
【図１１Ｃ】
【図１１Ｄ】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１７Ｃ】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８Ａ】
【図２８Ｂ】
【図２９Ａ】
【図２９Ｂ】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４Ａ】
【図３４Ｂ】
【図３５】
【図３６】
【図３７Ａ】
【図３７Ｂ】
【図３８】
【図３９】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図１０Ｃ】
【図１１Ａ】
【図１１Ｂ】
【図１１Ｃ】
【図１１Ｄ】
【図１２】
【図１３】
【図１４Ａ】
【図１４Ｂ】
【図１５】
【図１６】
【図１７Ａ】
【図１７Ｂ】
【図１７Ｃ】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８Ａ】
【図２８Ｂ】
【図２９Ａ】
【図２９Ｂ】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４Ａ】
【図３４Ｂ】
【図３５】
【図３６】
【図３７Ａ】
【図３７Ｂ】
【図３８】
【図３９】
【公開番号】特開２０１３−４１５７４（Ｐ２０１３−４１５７４Ａ）
【公開日】平成２５年２月２８日（２０１３．２．２８）
【国際特許分類】
【出願番号】特願２０１２−１３０３７５（Ｐ２０１２−１３０３７５）
【出願日】平成２４年６月８日（２０１２．６．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２５年２月２８日（２０１３．２．２８）
【国際特許分類】
【出願日】平成２４年６月８日（２０１２．６．８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]