JPWO2013111317A1

JPWO2013111317A1 - 情報処理方法、装置及びプログラム

Info

Publication number: JPWO2013111317A1
Application number: JP2013555076A
Authority: JP
Inventors: 雅崇園田; 松本　安英; 安英松本
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2012-01-27
Filing date: 2012-01-27
Publication date: 2015-05-11
Anticipated expiration: 2032-01-27
Also published as: WO2013111317A1; US20140325277A1; JP5949785B2

Abstract

本情報処理方法は、システム内の構成要素と当該構成要素間の関係とを表すデータを格納する第１のデータ格納部に格納されているデータから、システム内において影響を及ぼす範囲に関する指標値に関する所定の条件を満たす構成要素を特定する第１の特定処理と、第１のデータ格納部に格納されているデータに基づき、特定された構成要素から所定の範囲内の構成要素を抽出する抽出処理と、構成要素の種別毎に１又は複数の故障タイプが登録された第２のデータ格納部に格納されているデータから、抽出された構成要素の１つと当該構成要素に対応する故障タイプとのセットを１又は複数含む故障パターンを生成し、第３のデータ格納部に格納する生成処理とを含む。

Description

本技術は、コンピュータシステムの管理技術に関する。

クラウドコンピューティングなどの進展により、コンピュータシステムが大規模化しており、システム内の一部装置の故障や、設定ミスなどの操作ミスが、広範囲に影響を及ぼすようになってきている。

従来、障害への対策としては、シナリオベースのテストを行っておくというものがある。具体的には、過去の経験や使われ方、そして障害発生などを想定してシナリオを作成し、そのシナリオに沿ってテストを行うものである。しかしながら、最初に想定に基づきシナリオを作成するので、リスクが大きい想定外のケースをカバーできないという問題がある。特に、障害の原因は多種多様であり、想定外の状況が避けられない。特に、大規模障害の多くは、システムが想定外の状況になることが多い。すなわち、設計時には気付いていなかった潜在的なリスクが、他の障害によって条件を満たすことになって具現化し、障害が連鎖的に発生して大規模化する。一方で、想定内の状況ならば対策も用意でき、影響が広がらないうちに解決できる。

このように大規模障害を回避するために、想定外の状況を無くすことが好ましいが、人手による想定は難しいので、シミュレーションによって影響範囲を予測するという手法が用いられることが多い。具体的には、故障パターンを変えて、システムの状況をステップバイステップでシミュレーションすることで、故障パターン毎に障害の影響範囲を予測する。しかしながら、シミュレーションすべき故障パターンの数は、大規模なシステムでは非常に膨大な数となる。

故障パターンが、システム内のどの構成要素でどのような壊れ方をするかを表すものであり、構成要素数をｉ、各構成要素での故障の種類を平均ｊ種類とする。そうすると、故障パターン数Ｐは、以下のように表される。
Ｐ＝ｉ＊ｊ＋_iＣ₂＊ｊ＊ｊ

例えば、クラウドセンターが８つのゾーンを含み、１つのゾーンに数百台の物理マシン、数千台レベルの仮想マシンが含まれているとする。この場合、ｊ＝５と仮定すると、１箇所だけが壊れるケースだけでも２０万近いケースであり、２箇所壊れるケースは１００億以上のケースとなる。このように、全てのケースをシミュレーションすることは現実的ではない。

特開２００４−３１２２２４号公報特開２０１１−１８０８０５号公報特開平４−３１０１６０号公報特開平１１−２５９３３１号公報特開２０１１−１５５５０８号公報

従って、本技術の目的は、一側面において、影響が大きい故障パターンを効率的に特定するための技術を提供することである。

本技術に係る情報処理方法は、（Ａ）システム内の構成要素と当該構成要素間の関係とを表すデータを格納する第１のデータ格納部に格納されているデータから、システム内において影響を及ぼす範囲に関する指標値に関する所定の条件を満たす構成要素を特定する第１の特定処理と、（Ｂ）第１のデータ格納部に格納されているデータに基づき、特定された構成要素から所定の範囲内の構成要素を抽出する抽出処理と、（Ｃ）構成要素の種別毎に１又は複数の故障タイプが登録された第２のデータ格納部に格納されているデータから、抽出された構成要素の１つと対応する故障タイプとのセットを１又は複数含む故障パターンを生成し、第３のデータ格納部に格納する生成処理とを含む。

図１は、システムの構成例を示す図である。図２は、構成要素間の接続関係の一例を示す図である。図３は、システム構成データ格納部に格納されるデータの一例を示す図である。図４は、システム構成データ格納部に格納されるデータの一例を示す図である。図５は、システム構成データ格納部に格納されるデータの一例を示す図である。図６は、構成要素間の呼出関係の一例を示す図である。図７は、システム構成データ格納部に格納されるデータの一例を示す図である。図８は、システム構成データ格納部に格納されるデータの一例を示す図である。図９は、第１の実施の形態に係る処理フローを示す図である。図１０は、障害発生が想定されるシステムの一例を示す図である。図１１は、集約ポイント特定処理の処理フローを示す図である。図１２は、システムの物理構成例を示す図である。図１３は、配下の要素数を説明するための図である。図１４は、配下の要素数及び被呼出数の計算結果の一例を示す図である。図１５は、被呼出数を説明するための図である。図１６は、集約ポイント格納部に格納されるデータの一例を示す図である。図１７は、故障箇所候補抽出処理の処理フローを示す図である。図１８は、故障箇所候補抽出処理を説明するための図である。図１９は、故障箇所候補抽出処理を説明するための図である。図２０は、故障箇所候補リスト格納部に格納されるデータの一例を示す図である。図２１は、故障パターン生成処理の処理フローを示す図である。図２２は、故障タイプリスト格納部に格納されるデータの一例を示す図である。図２３は、故障パターン生成処理を説明するための図である。図２４は、故障パターンリスト格納部に格納されるデータの一例を示す図である。図２５は、状態遷移モデルの一例を示す図である。図２６は、スイッチの状態遷移モデルの一例を示す図である。図２７は、物理マシンの状態遷移モデルの一例を示す図である。図２８は、メインの仮想マシンの状態遷移モデルの一例を示す図である。図２９は、コピーの仮想マシンの状態遷移モデルの一例を示す図である。図３０は、マネージャの状態遷移モデルの一例を示す図である。図３１は、シミュレーション例における初期状態を示す図である。図３２は、シミュレーション例における第１ステップ目を示す図である。図３３は、シミュレーション例における第２ステップ目を示す図である。図３４は、シミュレーション例における第３ステップ目を示す図である。図３５は、シミュレーション例における第４ステップ目を示す図である。図３６は、シミュレーション例における第５ステップ目を示す図である。図３７は、シミュレーション結果格納部に格納されるデータの一例を示す図である。図３８は、処理結果の一例を示す図である。図３９は、第２の実施の形態に係る処理フローを示す図である。図４０Ａは、ｎ＝１の場合の範囲を示す図である。図４０Ｂは、ｎ＝１の場合のシミュレーション結果を表す図である。図４１Ａは、ｎ＝２の場合の範囲を示す図である。図４１Ｂは、ｎ＝２の場合のシミュレーション結果を表す図である。図４２は、最大被害要素数の変化を表す図である。図４３は、コンピュータの機能ブロック図である。

［実施の形態１］
本技術の実施の形態に係るシステムの構成を図１に示す。本システムには、情報処理装置１００と、運用管理システム２００と、１又は複数のユーザ端末３００とを含む。これらの装置は、ネットワークにて接続されている。

運用管理システム２００は、障害発生が想定されているシステムの運用管理のために既に構築されているシステムであり、障害発生が想定されているシステムについての構成要素のデータを格納するシステム構成データ格納部２１０を含む。

システム構成データ格納部２１０は、システム内の構成要素のデータと、構成要素間の接続関係のデータと、構成要素間の呼出関係のデータとを格納している。例えば、図２に示すように、スイッチＳｗｉｔｃｈ００１と、サーバＳｅｒｖｅｒ００１とが接続されている場合には、図３乃至図５のようなデータが、システム構成データ格納部２１０に格納される。図３は、接続のソース（Ｓｏｕｒｃｅ）となるスイッチＳｗｉｔｃｈ００１のデータを表しており、当該スイッチＳｗｉｔｃｈ００１のタイプと、各種属性及び状態などが登録されるようになっている。また、図４は、接続のターゲット（Ｔａｒｇｅｔ）となるサーバＳｅｒｖｅｒ００１のデータを表しており、サーバＳｅｒｖｅｒ００１のタイプと、各種属性及び状態などが登録されるようになっている。そして、図５は、スイッチＳｗｉｔｃｈ００１とサーバＳｅｒｖｅｒ００１との間の接続関係を表しており、関係のタイプ（Ｃｏｎｎｅｃｔｉｏｎ）と、ソースとなる構成要素と、ターゲットとなる構成要素と、接続状態などが登録されるようになっている。また、図６に示すように、サーバＳｅｒｖｅｒ００１からサーバＳｅｒｖｅｒ００２を呼び出す場合には、図４と図７及び図８に示すようなデータが、システム構成データ格納部２１０に格納される。図７は、呼出先のサーバＳｅｒｖｅｒ００２のデータを表しており、図４と同様に、サーバＳｅｒｖｅｒ００２のタイプ、各種属性及び状態などが登録されるようになっている。図８は、サーバＳｅｒｖｅｒ００１からサーバＳｅｒｖｅｒ００２への呼出関係を表しており、関係のタイプと（Ｃａｌｌ）、ソースとなる構成要素、ターゲットとなる構成要素などが登録されるようになっている。

なお、図３乃至図８の例はＸＭＬ（eXtensible Markup Language）で記述する例を示したが、他の方法で構成要素及びその関係を記述するようにしても良い。

情報処理装置１００は、集約ポイント特定部１０１と、集約ポイント格納部１０２と、故障箇所候補抽出部１０３と、故障箇所候補リスト格納部１０４と、故障パターン生成部１０５と、故障タイプリスト格納部１０６と、除外リスト格納部１０７と、故障パターンリスト格納部１０８と、シミュレーション実行部１０９と、状態遷移モデル格納部１１０と、シミュレーション結果格納部１１１と、出力処理部１１２とを有する。

集約ポイント特定部１０１は、システム構成データ格納部２１０に格納されているデータを用いて、障害発生が想定されているシステムにおける集約ポイントを特定し、集約ポイント格納部１０２に格納する。故障箇所候補抽出部１０３は、集約ポイント格納部１０２に格納されているデータに基づき、システム構成データ格納部２１０から故障箇所候補を抽出し、抽出結果を故障箇所候補リスト格納部１０４に格納する。故障パターン生成部１０５は、故障箇所候補リスト格納部１０４及び故障タイプリスト格納部１０６に格納されているデータを用いて故障パターンを生成して、故障パターンリスト格納部１０８に格納する。なお、この際、故障パターン生成部１０５は、除外リスト格納部１０７に格納されているデータに基づき、除外すべき故障パターンを、故障パターンリスト格納部１０８から削除する。

シミュレーション実行部１０９は、故障パターンリスト格納部１０８に格納されている故障パターン毎に、状態遷移モデル格納部１１０に格納されている状態遷移モデルに従って、当該故障パターンの故障が発生したとして、システム構成データ格納部２１０に格納されている構成要素の状態遷移についてのシミュレーションを実施し、シミュレーション結果をシミュレーション結果格納部１１１に格納する。出力処理部１１２は、例えばユーザ端末３００からの要求に応じて、シミュレーション結果格納部１１１に格納されているデータから出力データを生成してユーザ端末３００に対して出力する。

ユーザ端末３００は、運用管理者が操作する例えばパーソナルコンピュータであり、情報処理装置１００の集約ポイント特定部１０１などに処理開始を指示したり、出力処理部１１２に対して処理結果の出力を要求して、出力処理部１１２から処理結果を受信して、表示装置に表示する。

次に、図９乃至図３８を用いて情報処理装置１００の処理内容について説明する。

まず、集約ポイント特定部１０１は、集約ポイント特定処理を実施する（図９：ステップＳ１）。この集約ポイント特定処理については、図１０乃至図１６を用いて説明する。

本実施の形態では、例えば図１０に示すようなシステムを故障発生が想定されるシステムの一例として説明する。このシステムは、サービス用の２つのラック（ラック１及び２）と、管理用の１つのラックとを含む。これらのラックは、スイッチｃｉ０２で接続されている。ラック１では、スイッチｃｉ０２に接続されているスイッチｃｉ０１に、物理マシン（ｐｍ）ｃｉ０５及びｃｉ０６が接続されており、物理マシンｃｉ０５には、配下に仮想マシン（ｖｍ）ｃｉ１１乃至ｃｉ１５が設けられ、物理マシンｃｉ０６には、配下に仮想マシンｃｉ１６乃至ｃｉ２０が設けられる。ラック２では、スイッチｃｉ０２に接続されているスイッチｃｉ０３に、物理マシンｃｉ０７及びｃｉ０８が接続されている。物理マシンｃｉ０７及びｃｉ０８の配下には仮想マシンは存在していない。管理用のラックでは、スイッチｃｉ０２に接続されているスイッチｃｉ０４に、物理マシンｃｉ０９が接続されており、この物理マシンｃｉ０９には、マネージャ（Ｍｇｒ）である構成要素ｃｉ１０が設けられている。このような各構成要素及びそれらの構成要素間の接続関係が、システム構成データ格納部２１０に規定されている。

このシステムにおいては、仮想マシンｃｉ１１乃至ｃｉ１５がマスタで、仮想マシンｃｉ１６乃至ｃｉ２０はそれらのコピーである。マスタである仮想マシンｃｉ１１乃至ｃｉ１５は、それぞれ自身のコピーの生存を例えば定期的に確認する。これは、仮想マシンｃｉ１１から仮想マシンｃｉ１６への呼出関係（Ｃａｌｌ）としてシステム構成データ格納部２１０に規定されている。仮想マシンｃｉ１２乃至ｃｉ１５についても同様である。また、コピーの生存が不明になると、マスタの仮想マシンｃｉ１１乃至ｃｉ１５は、新たなコピーを生成するため、複製生成要求を、マネージャＭｇｒに要求（Ｃａｌｌ）する。これが、マスタの仮想マシンｃｉ１１乃至ｃｉ１５から、マネージャＭｇｒへの呼出関係として規定されている。

まず、集約ポイント特定部１０１は、システム構成データ格納部２１０において未処理の構成要素（ＣＩ：Component Item）を１つ特定する（図１１：ステップＳ２１）。以下で説明するように、仮想マシンに対応する構成要素から選択すると効率がよい。集約ポイント特定部１０１は、特定された構成要素の配下の要素数を算出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ２３）。

本実施の形態では、特定された構成要素の要素タイプを特定し、当該要素タイプに合わせて配下の要素数を算出する。構成要素の要素タイプは、ルータ、スイッチ（コア）、スイッチ（エッジ）、物理マシン、仮想マシンなどがある。一般的には、システムの物理構成は図１２のようになっており、最上位のルータ、ルータの配下に配置され且つ大部分が配下のスイッチに接続されているスイッチ（コア）、コアスイッチ以外のスイッチ（エッジ）、スイッチに接続される物理マシン（ＰＭ）、物理マシン上に起動される仮想マシン（ＶＭ）が含まれる。ルータ、スイッチ、物理マシン及び仮想マシンについては、要素タイプが明に規定されているのでそれにより特定され、エッジスイッチとコアスイッチは、上で述べたように接続先の構成要素の要素タイプによって区別する。

そして、コアスイッチの場合には、直下のエッジスイッチの数と直下のエッジスイッチの配下の要素数との総和により、コアスイッチの配下の要素数を算出する。図１３に示すように、図１０で示したシステムの中で、スイッチｃｉ０２は、接続先がスイッチのみであるからコアスイッチとなる。このようなスイッチｃｉ０２の場合には、配下の要素数は、直下のスイッチｃｉ０１、ｃｉ０３及びｃｉ０４の数「３」と、それらの配下の要素数の和「１６」（＝１２＋２＋２）との総和である「１９」と算出される。

また、エッジスイッチの場合には、直下の物理マシンの数とそれらの配下の要素数との総和により、エッジスイッチの配下の要素数を算出する。スイッチｃｉ０１は、２つの物理マシンｃｉ０５及びｃｉ０６に接続されており、エッジスイッチと判断される。そして、配下の要素数は、物理マシンｃｉ０５及びｃｉ０６の数「２」と、これらの物理マシンｃｉ０５及びｃｉ０６の配下の要素数の和「１０」（＝５＋５）との総和である「１２」と算出される。スイッチｃｉ０３は、２つの物理マシンｃｉ０７及びｃｉ０８に接続されており、エッジスイッチと判断される。そして、配下の要素数は、物理マシンｃｉ０７及びｃｉ０８の数「２」と、これらの物理マシンｃｉ０７及びｃｉ０８の配下の要素数の和「０」との総和である「２」と算出される。スイッチｃｉ０４は、物理マシンｃｉ０９に接続されており、エッジスイッチと判断される。そして、配下の要素数は、物理マシンｃｉ０９の数「１」と、この物理マシンｃｉ０９の配下の要素数の和「１」との総和である「２」と算出される。

さらに、物理マシンの場合には、直下の仮想マシンの数が、物理マシンの配下の要素数となる。物理マシンｃｉ０５及びｃｉ０６の場合には、直下の仮想マシンの数は５であるから、配下の要素数は「５」となる。物理マシンｃｉ０８及びｃｉ０９の場合、直下の仮想マシンの数は０であるから、配下の要素数は「０」となる。物理マシンｃｉ０９の場合、直下の仮想マシンの数は１であるから、配下の要素数は「１」となる。仮想マシンの場合には、配下の要素数は０と特定される。

また、集約ポイント特定部１０１は、特定された構成要素の被呼出数を算出し、例えばメインメモリなどの記憶装置に格納する（ステップＳ２５）。被呼出数については、自身がターゲットとなっている呼出関係の数と、当該呼出関係のソースについての被呼出数との総和として算出される。すなわち、呼出関係のソースを遡って行き、辿ることができなくなるまでの呼出関係の総和が、被呼出数である。図１０の例では、マネージャＭｇｒの場合、仮想マシンｃｉ１１乃至ｃｉ１５をソースとする呼出関係が５つ登録されているので、被呼出数は５となる。一方、コピーの仮想マシンｃｉ１６乃至ｃｉ２０の場合には、それぞれ自身のマスタから呼び出されるので、マスタの仮想マシンをソースとする呼出関係がそれぞれ１つ登録されている。従って、これらの仮想マシンｃｉ１６乃至ｃｉ２０については、被呼出数は１となる。

一方、別の例として、図１５に示すようなシステムにおいて、ロードバランサ（ＬＢ）ｃｉ１７と、ウェブサーバ（Ｗｅｂ）ｃｉ１８乃至ｃｉ２０と、アプリケーションサーバについてのロードバランサ（ＡｐｐＬＢ）ｃｉ２１と、アプリケーションサーバ（Ａｐｐ）ｃｉ２２及びｃｉ２３と、ゲートウェイ（ＧＷ）ｃｉ２４と、ＤＢサーバ（ＤＢ）ｃｉ２５とが設けられているものとする。この場合には、図１５に示すように、ロードバランサｃｉ１７から呼出関係が、ウェブサーバ、アプリケーションサーバについてのロードバランサ、アプリケーションサーバ、ゲートウェイ、そしてＤＢサーバへと連鎖的に繋がれている。このような場合には、各ウェブサーバの被呼出数は「１」であり、アプリケーションサーバについてのロードバランサの被呼出数は「６」である。また、各アプリケーションサーバの被呼出数は「７」であり、ゲートウェイの被呼出数は「１６」となる。結果として、ＤＢサーバの被呼出数は「１７」となる。

そうすると、例えば図１４に示すような算出結果が得られる。図１４の例では、各構成要素（ＣＩ）について、配下の要素数と、被呼出数とが登録されるようになっている。このように、システム内においてこの構成要素が動作不能となった場合において影響を受ける範囲に関する指標値が登録される。

そして、集約ポイント特定部１０１は、特定された構成要素が、集約ポイント（集約Ｐとも記す）の条件を満たしているか判断する（ステップＳ２７）。例えば、配下の要素数であれば「１６」以上となっており、被呼出数であれば「６」以上であるという条件を満たしているか判断する。なお、配下の要素数と被呼出数とを重み付け加算した結果を評価値として算出し、当該評価値が閾値以上であるか否かで、集約ポイントであるか否かを判断するようにしても良い。図１４の例では、太枠で示した構成要素ｃｉ０２が集約ポイントの条件を満たしていると判断される。

集約ポイントの条件を満たしていない場合には処理はステップＳ３１に移行する。一方、集約ポイントの条件を満たしている場合には、集約ポイント特定部１０１は、特定された構成要素を集約ポイントリストに追加し、集約ポイント格納部１０２に格納する（ステップＳ２９）。集約ポイント格納部１０２には、例えば図１６に示すようなデータが格納される。図１６のように、集約ポイントとして特定された構成要素の識別子が登録されるリストが格納されるようになっている。なお、構造的な集約ポイントと挙動の集約ポイントとで異なる基準を用いる場合には、以下で述べる故障箇所候補を抽出する際にも異なる基準で故障箇所候補を抽出する場合もある。このため、集約ポイント格納部１０２に、構成要素の識別子に加えて構造又は挙動の別を設定しておく場合もある。

集約ポイントは、上で述べたように、システムにおいて多数の他の構成要素が関連している構成要素である。そして、上で述べたように配下の要素数が多いことで特定される構造的な集約ポイントと、多くの構成要素により直接及び間接的に呼び出されることを表す被呼出数にて特定される挙動の集約ポイントとが存在する。このような集約ポイントに着目するのは、集約ポイントが故障の影響を受けると、短時間で影響範囲が拡大する可能性が大きいことが知られており、集約ポイントに影響を与える故障を見つけることが対策を行う上で重要である。特に、集約ポイントに早期に影響を与える故障ほど緊急性の高い故障であり、このような緊急性の高い故障に対処できれば十分に効果的である。従って、本実施の形態では、集約ポイントに早期に影響を与えるような故障を特定するものとする。

処理はステップＳ３１に移行して、集約ポイント特定部１０１は、システム構成データ格納部２１０において、未処理の構成要素が存在しているか判断する（ステップＳ３１）。未処理の構成要素が存在している場合にはステップＳ２１に戻る。一方、未処理の構成要素が存在していない場合には、呼出元の処理に戻る。

このような処理を実施すれば、集約ポイント格納部１０２に、集約ポイントのリストが格納されるようになる。

図９の処理の説明に戻って、次に、故障箇所候補抽出部１０３は、故障箇所候補抽出処理を実施する（ステップＳ３）。この故障箇所候補抽出処理については、図１７乃至図２０を用いて説明する。故障箇所候補抽出部１０３は、集約ポイント格納部１０２において、未処理の集約ポイントを１つ特定する（図１７：ステップＳ４１）。そして、故障箇所候補抽出部１０３は、システム構成データ格納部２１０において、特定された集約ポイントからｎホップ以内にある構成要素を検索する（ステップＳ４３）。例えば構造的な集約ポイントの場合には、接続関係で繋がれるｎホップ以内（例えば２ホップ以内）の構成要素を、故障箇所候補として抽出する。図１０の例では、スイッチｃｉ０２が集約ポイントとして特定されているので、図１８に示すように、集約ポイントであるスイッチｃｉ０２から接続関係において２ホップ内とすると、点線で囲まれたスイッチｃｉ０１、ｃｉ０３及びｃｉ０４と、物理マシンｃｉ０５乃至ｃｉ０９とが抽出される。

一方、図１５に示すようなシステムにおいて被呼出数に基づき挙動の集約ポイントが特定されると、図１９に示すように、集約ポイントであるＤＢサーバｃｉ２５から、呼出関係を辿ってｎホップ以内（例えば２ホップ以内）の構成要素を抽出する。具体的には、図１９において点線で囲まれたアプリケーションサーバｃｉ２２及びｃｉ２３と、ゲートウェイｃｉ２４とが抽出される。

なお、配下の要素数及び被呼出数を総合的に評価した上で集約ポイントを抽出した場合、又は配下の要素数の基準と被呼出数の基準との両方の基準を満たすような集約ポイントが存在する場合には、接続関係について所定ホップ以内の構成要素と、呼出関係について所定ホップ数以内の構成要素とを両方とも抽出する。

その後、故障箇所候補抽出部１０３は、ステップＳ４３の検索で検出された構成要素を、故障箇所候補として、故障箇所候補リスト格納部１０４に格納する（ステップＳ４５）。図１８の例では、例えば図２０に示すようなデータが、故障箇所候補リスト格納部１０４に格納される。図２０の例では、構成要素の識別子と、当該構成要素の要素タイプとが対応付けて格納される。

そして、故障箇所候補抽出部１０３は、集約ポイント格納部１０２において未処理の集約ポイントが存在しているか判断する（ステップＳ４７）。未処理の集約ポイントが存在している場合には処理はステップＳ４１に戻る。一方、未処理の集約ポイントが存在していない場合には、呼出元の処理に戻る。

このような処理を実施すれば、故障した際に集約ポイントに影響を及ぼす可能性の高い構成要素が、故障箇所候補として抽出されたことになる。

図９の処理の説明に戻って、故障パターン生成部１０５は、故障パターン生成処理を実施する（ステップＳ５）。この故障パターン生成処理については、図２１乃至図２４を用いて説明する。まず、故障パターン生成部１０５は、故障箇所候補リスト格納部１０４において、故障タイプリスト格納部１０６から、各故障箇所候補の要素タイプに対応する故障タイプを特定する（図２１：ステップＳ５１）。故障タイプリスト格納部１０６には、例えば図２２に示すようなデータが格納されている。図２２の例では、要素タイプ毎に、１又は複数の故障タイプが対応付けられている。例えば物理マシンｐｍという要素タイプに対しては、ディスク（Ｄｉｓｋ）故障及びＮＩＣ（Network Interface Card）故障という２つの故障タイプが対応付けられている。同じ構成要素でも、故障タイプが異なればその影響の波及状況も異なるので、区別して取り扱うためである。

そして、故障パターン生成部１０５は、カウンタｉを１に初期化する（ステップＳ５３）。その後、故障パターン生成部１０５は、故障箇所候補と故障タイプのセットをｉ個含むパターンを全て生成し、故障パターンリスト格納部１０８に格納する（ステップＳ５５）。

図２０のような故障箇所候補が抽出された場合、図２２に示すような故障タイプリストのデータから、要素タイプｓｗであれば１つの故障タイプ「故障」が得られ、要素タイプｐｍであれば２つの故障タイプ「Ｄｉｓｋ故障」及び「ＮＩＣ故障」が得られる。従って、図２３に示すように、スイッチであればそれぞれ構成要素の識別子と故障タイプ「故障」のセットが１つずつ生成され、物理マシンであれば構成要素の識別子と故障タイプ「Ｄｉｓｋ故障」のセットと構成要素の識別子と故障タイプ「ＮＩＣ故障」のセットとが２つずつ生成される。これらのセットを１つ含むような故障パターンについては、故障が一箇所で発生するものと仮定したもので、故障パターンリスト格納部１０８に格納する。

また、一度に複数の故障箇所候補で故障が発生することを想定しても良い。例えばｉ＝２の場合には、上で述べたようなセットを２つ含むような故障パターンをセットの全ての組み合わせについて生成する。例えば、セット（ｃｉ０１，故障）とセット（ｃｉ０３，故障）の組み合わせ、セット（ｃｉ０１，故障）とセット（ｃｉ０６，Ｄｉｓｋ故障）の組み合わせ、．．．などが生成される。

そしてステップＳ５５で生成した故障パターンについては、故障パターンリスト格納部１０８に格納される。故障パターンリスト格納部１０８には、例えば図２４のようなデータが格納される。図２４の例では、故障パターンが列挙されるリストが格納されるようになっている。

その後、故障パターン生成部１０５は、除外リスト格納部１０７に格納されている故障パターンを、故障パターンリスト格納部１０８から削除する（ステップＳ５７）。予め除外リストに、１つのみ故障する場合に検討不要な故障パターンや、複数箇所故障する場合の組み合わせについてあり得ない組み合わせや検討不要な組み合わせを登録しておく。このような登録については運用管理者がその知見を予め登録するようにしても良い。また、物理マシンが故障すれば配下の仮想マシンも故障となるので、（ｐｍ１，故障）のセットが登録されていれば、（ｐｍ１，故障）及び（ｖｍ１１，故障）の組み合わせは削除するというルールを登録しておき、適用しても良い。

また、例えば特開２０１１−１４５７７３号公報記載の技術を用いて、除外リストに登録すべき故障パターン（又はルール）をシステム構成データ格納部２１０から自動的に生成して、除外リスト格納部１０７に格納するようにしても良い。

その後、故障パターン生成部１０５は、ｉが上限値を超えたか判断する（ステップＳ５９）。上限値は、一度に発生する故障の上限数であり、予め設定しておく。そして、ｉが上限値を超えていない場合には、故障パターン生成部１０５は、ｉを１インクリメントして（ステップＳ６１）、処理はステップＳ５５に戻る。一方、ｉが上限値を超えた場合には、処理は呼出元の処理に戻る。

このような処理を実施することで、集約ポイントに影響を及ぼし且つ想定すべき故障パターンが生成されたことになる。

図９の処理の説明に戻って、シミュレーション実行部１０９は、故障パターンリスト格納部１０８に格納されている各故障パターンについて、状態遷移モデル格納部１１０に格納されている状態遷移モデルに従って、当該故障パターンの故障が発生したと想定して、システム構成データ格納部２１０に格納されている各構成要素の状態遷移のシミュレーションを実施する（ステップＳ７）。

状態遷移モデルを、要素タイプ毎に状態遷移モデル格納部１１０に格納しておく。典型的には、図２５に示すような形式で状態遷移モデルを記述する。状態は、構成要素の状態を表し、丸や四角で囲まれて表されている。その状態間の遷移は、ある状態から別の状態への変化を表し、矢印で表される。なお、遷移には、トリガー、ガード条件及び作用が規定される。トリガーとは、遷移のきっかけとなるイベントであり、ガード条件とは、遷移するための条件であり、作用とは、遷移に伴う振る舞いを表す。ガード条件及び作用については規定されない場合もある。本実施の形態では「遷移：トリガー［ガード条件］／作用」といった形で表す。図２５において、状態「停止」から状態「起動中」へトリガー「起動」により遷移が生じ、状態「起動中」から状態「停止」へトリガー「停止」により遷移が生ずる。また、状態「起動中」から状態「過負荷」へ、トリガー「処理要求受信」でガード条件［処理量＞許容処理量］を満たせば遷移が発生する。その作用として「要求受け付け停止」が行われる。一方、状態「過負荷」から状態「起動中」へ、トリガー「要求受信」でガード条件［処理量≦許容処理量］を満たせば遷移が発生する。その作用として「要求受け付け再開」が行われる。本実施の形態では、トリガーとして別の構成要素の状態や作用をも表現可能とする。例えば、状態「起動中」から状態「停止」への遷移についてのトリガーに、「停止＠ｐｍ」といった表記を使用できるようにする。例えば、仮想マシンｖｍ状態遷移モデルにおいて「ｐｍが停止している場合、ｖｍが状態「起動中」から状態「停止」に遷移」することを表現する。

より具体的に図１０に示したシステムにおいて用いられている要素タイプ「ｓｗ」の構成要素についての状態遷移モデルの一例を図２６に示す。図２６に示すように、状態「停止中」、状態「起動中」及び状態「ダウン」が含まれる。そして、状態「停止中」から状態「起動中」への遷移は、トリガー「起動処理」に応じて行われる。また、状態「起動中」から状態「ダウン」への遷移は、トリガー「故障」に応じて行われる。状態「起動中」から状態「停止中」への遷移は、トリガー「シャットダウン処理」に応じて行われる。さらに、状態「ダウン」から状態「停止中」への遷移は、トリガー「停止処理」に応じて行われる。このようにスイッチは故障が発生するとダウンする。

また、図１０に示したシステムにおいて用いられている要素タイプ「ｐｍ」の構成要素についての状態遷移モデルの一例を図２７に示す。図２７に示すように、状態「停止中」、状態「起動中」、状態「通信不能」及び状態「ダウン」が含まれている。状態「停止中」から状態「起動中」への遷移は、トリガー「起動処理」でガード条件［ｓｗが起動中］であれば行われる。状態「起動中」から状態「ダウン」への遷移は、トリガー「ｄｉｓｋ故障」に応じて行われる。また、状態「起動中」から状態「通信不能」への遷移は、トリガー「ＮＩＣ故障」又は「ｓｗの停止」又は「ｓｗの過負荷」に応じて行われる。一方、状態「通信不能」から状態「起動中」への遷移は、トリガー「ｓｗの起動中」に応じて行われる。状態「起動中」から状態「停止中」への遷移は、トリガー「シャットダウン処理」に応じて行われる。さらに、状態「停止中」から状態「通信不能」への遷移は、トリガー「起動処理」でガード条件［ｓｗが停止中］又は［ｓｗが過負荷］を満たせば行われる。逆に、状態「通信不能」から状態「停止中」への遷移は、トリガー「シャットダウン処理」に応じて行われる。また、状態「ダウン」から状態「停止中」への遷移は、トリガー「停止処理」に応じて行われる。このように、ｓｗの状態やＮＩＣ故障に応じて起動中から通信不能になったり、ｓｗの状態が回復すれば通信不能から起動中に遷移する。また、ｄｉｓｋ故障が発生すると、起動中からダウン状態になる。

また、図１０に示したシステムにおいて用いられている要素タイプ「ｖｍ」でメインの仮想マシンの場合の状態遷移モデルの一例を図２８に示す。図２８に示すように、状態「停止中」、状態「起動中」、状態「通信不能」、状態「ダウン」及び状態「複製不明」が含まれる。状態「停止中」から状態「起動中」への遷移は、トリガー「起動処理」でガード条件［ｓｗが起動中且つｐｍが起動中］が満たされれば行われる。また、状態「起動中」から状態「ダウン」への遷移は、トリガー「ｐｍが停止」又は「ｐｍがダウン」に応じて行われる。状態「ダウン」から状態「起動中」への遷移は、トリガー「起動処理」でガード条件［ｓｗが起動中且つｐｍが起動中］を満たせば行われる。状態「起動中」から状態「通信不能」への遷移は、トリガー「ｓｗが停止」又は「ｓｗが過負荷」又は「ｐｍが通信不能」に応じて行われる。状態「通信不能」から状態「起動中」への遷移は、トリガー「ｓｗが起動中且つｐｍが起動中」に応じて行われる。さらに、状態「起動中」から状態「複製不明」への遷移は、トリガー「ｖｍ（コピー）がダウン」又は「ｖｍ（コピー）が通信不能」に応じて行われる。状態「複製不明」への自己遷移は、トリガー「複製生成要求」に応じて行われる。状態「通信不能」から状態「複製不明」への遷移は、自動的に行われる。状態「起動中」から状態「停止中」への遷移、及び状態「通信不能」から状態「停止中」への遷移は、トリガー「シャットダウン処理」に応じて行われる。また、状態「停止中」から状態「通信不能」への遷移は、トリガー「起動処理」でガード条件［ｓｗが停止又はｓｗが過負荷］を満たせば行われる。状態「ダウン」から状態「停止中」への遷移は、トリガー「停止処理」に応じて行われる。このように遷移のトリガー又はガード条件の一部に物理マシンｐｍの状態が含まれている。また、自身のコピー（ｖｍ（コピー））の生存を常に確認しており、生存が不明になるとマネージャＭｇｒに複製生成要求を送信する。なお、自身が通信不能状態であれば、自動的に複製不明状態になる。

さらに、図１０に示したシステムにおいて用いられる要素タイプ「ｖｍ」でコピーの仮想マシンの場合の状態遷移モデルの一例を図２９に示す。メインの仮想マシンとの差は、状態「複製不明」が存在せず、それに関連する遷移も同様に存在しない部分であり、それ以外は同じである。

また、図１０に示したシステムにおいて用いられる要素タイプ「Ｍｇｒ」の構成要素についての状態遷移モデルの一例を図３０に示す。図３０に示すように、状態「停止中」、状態「起動中」及び状態「過負荷」が含まれている。そして、状態「停止中」から状態「起動中」への遷移は、トリガー「起動処理」に応じて行われる。状態「起動中」の第１の自己遷移は、トリガー「複製要求」でガード条件［要求量ｒがｒ_max以下］を満たせば行われる。この遷移が行われると要求量ｒが１インクリメントされる。また、状態「起動中」の第２の自己遷移は、トリガー「複製処理」でガード条件［ｒがｒ_max以下］を満たせば行われる。この遷移が行われると要求量ｒが１デクリメントされる。また、状態「起動中」から状態「過負荷」への遷移は、トリガー「複製生成要求」でガード条件［ｒ＞ｒ_max］で行われる。状態「過負荷」の第１の自己遷移は、トリガー「複製生成要求」でガード条件［ｒ＞ｒ_max］を満たせば行われる。この遷移が行われると要求量ｒが１インクリメントされる。また、状態「過負荷」の第２の自己遷移は、トリガー「複製処理」でガード条件［ｒ＞ｒ_max］を満たせば行われる。この遷移が行われると要求量ｒが１デクリメントされる。状態「過負荷」から状態「起動中」への遷移は、トリガー「複製処理」でガード条件［ｒ≦ｒ_max］を満たせば行われる。この遷移が行われると要求量ｒが１デクリメントされる。状態「起動中」から状態「停止中」への遷移、及び状態「過負荷」から状態「停止中」への遷移は、トリガー「シャットダウン処理」に応じて行われる。この遷移により要求量ｒは０になる。

シミュレーション実行部１０９は、このような状態遷移モデルを用いてシミュレーションを実施する。なお、この際故障パターンで規定されている特定の構成要素に特定の故障が発生したものとしてシミュレーションを行うことになる。

例えば図１０のシステムにおいて、故障パターンとして（ｃｉ０６，ＮＩＣ故障）についてシミュレーションを行う場合について、具体的な状態遷移を図３１乃至図３６を用いて説明する。なお、ここでは、メインの仮想マシンｖｍは、状態「複製不明」での複製生成要求は１ステップに１回のペースで繰り返されるものとする。また、マネージャＭｇｒにおける最大要求量ｒ_max＝１０であるものとする。また、マネージャＭｇｒも、１ステップに１要求を処理できるものとする。さらに、早期に影響を与えるような故障を特定するために、例えば５ステップ後まででシミュレーションを終了するものとする。

初期状態では、図３１に示すように、全ての構成要素が「起動中」であり、マネージャＭｇｒにおける要求量ｒは０となっている。そして、第１ステップ目で、図３２に示すように、物理マシンｐｍである構成要素ｃｉ０６がＮＩＣ故障に応じて「通信不能」状態になったものとする。そうすると、第２ステップ目では、図３３に示すように、コピーの仮想マシンｖｍである構成要素ｃｉ１６乃至ｃｉ２０は「通信不能」状態に遷移する。

その後、第３ステップ目では、図３４に示すように、メインの仮想マシンである構成要素ｃｉ１１乃至ｃｉ１５は、コピーの仮想マシンの生存確認ができなくなるので、「複製不明」状態に遷移する。そうすると、複製生成要求が、メインの仮想マシンである構成要素ｃｉ１１乃至ｃｉ１５から、マネージャＭｇｒに送信される。従って、合計で５つの複製生成要求がマネージャＭｇｒに到達するので、要求量ｒが５に増加する。

そして、第４ステップ目では、図３５に示すように、マネージャＭｇｒは、複製生成要求を１つ処理するが、メインの仮想マシンである構成要素ｃｉ１１乃至ｃｉ１５は、生存確認ができないので再度複製生成要求をマネージャＭｇｒに送信するので、ｒ＝５−１＋５＝９となる。

その後、第５ステップ目では、図３６に示すように、マネージャＭｇｒは、複製生成要求を１つ処理するが、メインの仮想マシンである構成要素ｃｉ１１乃至ｃｉ１５は、まだ生存確認ができないので再度複製生成要求をマネージャＭｇｒに送信するので、ｒ＝９−１＋５＝１３となる。これによって、マネージャＭｇｒの最大処理量ｒ_max＝１０を超えるので、マネージャＭｇｒの構成要素ｃｉ１０は過負荷状態となる。

以上のように、故障パターンに含まれる構成要素ｃｉ０６に加えて、構成要素ｃｉ１０乃至ｃｉ２０に不具合が発生しているということが分かる。ここでは、故障パターンに含まれる構成要素を含めて、被害要素数として計数するものとする。本例では、被害要素数「１２」が得られる。

このような処理を、各故障パターンについて実施すると、シミュレーション実行部１０９は、シミュレーション結果格納部１１１に、図３７に示すようなデータを格納する。図３７の例では、各故障パターンについて、影響を受けた構成要素の数である被害要素数と、影響を受けた構成要素である被害要素の識別子とが含まれる。

なお、このようなシミュレーションの具体的処理方法については、従来から存在するものを利用でき、且つシミュレーションの仕方自体は本実施の形態の主旨ではないので、これ以上述べない。

図９の処理の説明に戻って、出力処理部１１２は、シミュレーション結果格納部１１１に格納されているシミュレーション結果に含まれる被害要素数で、故障パターンを降順にソートする（ステップＳ９）。そして、出力処理部１１２は、ソート結果から上位所定数の故障パターンを抽出して、当該抽出した上位所定数の故障パターンのデータを、例えばユーザ端末３００に出力する（ステップＳ１１）。

例えば、図３８に示すようなデータを生成して、ユーザ端末３００の表示装置などに表示する。図３８の例では、上位所定数が「３」であり、故障パターン毎に、被害要素数と被害要素とが示されるようになっている。

このように被害要素数が多い、すなわち影響が及ぶ範囲が広い故障パターンを特定できるため、これに対する対策を行うことができるようになる。

［実施の形態２］
第１の実施の形態では集約ポイントから固定のホップ数ｎの範囲に含まれる構成要素を故障箇所候補として抽出する例を示した。しかしながら、必ずしも最初からｎを適切に設定できるわけではない。また、集約ポイントからやや離れた構成要素の方が影響範囲が広い場合もある。従って、以下で述べるような処理を実施することで、故障箇所候補を抽出する範囲を動的に変更して、適切な故障箇所候補を抽出することで、対処すべき故障パターンを適切に抽出する。

例えば、図３９に示すような処理を実施する。まず、集約ポイント特定部１０１は、集約ポイント特定処理を実施する（図３９：ステップＳ２０１）。この集約ポイント特定処理については、図１０乃至図１６を用いて説明した処理と同じである。従って、詳細な説明は省略する。次に。故障箇所候補抽出部１０３は、カウンタｎを１に初期化する（ステップＳ２０３）。そして、故障箇所候補抽出部１０３は、故障箇所候補抽出処理を実施する（ステップＳ２０５）。この故障箇所候補抽出処理については、図１７乃至図２０を用いて説明した処理と同じである。従って、詳細な説明は省略する。その後、故障パターン生成部１０５は、故障パターン生成処理を実施する（ステップＳ２０７）。故障パターン生成処理については、図２１乃至図２４を用いて説明した処理と同じである。従って、詳細な説明については省略する。

そして、シミュレーション実行部１０９は、故障パターンリスト格納部１０８に格納されている各故障パターンについて、状態遷移モデル格納部１１０に格納されている状態遷移モデルに従って、当該故障パターンの故障が発生したと想定して、システム構成データ格納部２１０に格納されている各構成要素の状態遷移のシミュレーションを実施する（ステップＳ２０９）。このステップの処理内容はステップＳ７と同様であるから、詳細な説明は省略する。

その後、出力処理部１１２は、シミュレーション結果に含まれる被害要素数で、故障パターンを降順にソートする（ステップＳ２１１）。この処理もステップＳ９と同様であるから、これ以上述べない。そして、出力処理部１１２は、最大被害要素数及びその時の故障パターンを特定し、例えばシミュレーション結果格納部１１１に格納する（ステップＳ２１３）。

さらに出力処理部１１２は、ｎが予め設定された最大値に達したか又はｎの変動が収束したか判断する（ステップＳ２１５）。変動が収束というのは、例えば被害要素数の最大値が２回続けて変動しない場合などの条件を満たしているか判断する。

ｎが最大値に達しておらず且つｎの変動が収束していない場合、出力処理部１１２は、ｎを１インクリメントする（ステップＳ２１７）。そして処理はステップＳ２０５に戻る。

図４０Ａに模式的に示すように、システム内の構成要素ｃｉ０２が集約ポイントであるとすると、ホップ数ｎ＝１について故障箇所候補を抽出すると、図４０Ｂに示すようなシミュレーション結果が得られる。この例では、ｎ＝１の場合、被害要素数の最大値は１０となっている。さらに、図４１Ａに模式的に示すように、ホップ数ｎ＝２について故障箇所候補を抽出すると、図４１Ｂに示すようなシミュレーション結果が得られる。この例では、ｎ＝２の場合、被害要素数の最大値は１３となっている。このような処理がステップＳ２１５の条件が満たされるまで繰り返されることになる。

一方、ｎが最大値に達しているか又は変動が収束した場合には、出力処理部１１２は、最大被害要素数の変化を表すデータを生成して、例えばユーザ端末３００に出力する（ステップＳ２１９）。ユーザ端末３００では、例えば図４２に示すようなデータが表示される。図４２では、横軸がホップ数ｎを表し、縦軸が被害要素数を表す。この例では、ホップ数ｎ＝３及びｎ＝４で、最大被害要素数が変化しないので、ｎ＝５以降の処理は省略される。なお、図４０Ｂや図４１Ｂのようなデータをも提示するようにしても良い。

このような処理を実施することで、集約ポイントからどの程度の範囲を検討すればよいのかについての目安を得ることができる。さらに、第１の実施の形態と同様に、注意すべき故障パターンについても特定できるため、そのための対応策を用意することもできるようになる。

以上述べたように、故障パターンを影響範囲が大きくなる可能性が高いものに限定することで、効率的にリスクの高い故障パターンを把握できるようになる。特に、構成要素の数が多くなっても、本実施の形態の方法を採用すれば、構成要素の数に依存せず、集約ポイントの所定範囲内に含まれる要素数で故障パターンの数は決まるので、より効果的である。

さらに、上では運用管理者が用いる例を示したが、例えばシステム設計時に、上で述べた処理を行っておけば、大規模障害が発生しないようなシステムを設計することが可能となる。さらに、上でも述べたように、運用管理者が用いることによって、事前に大規模障害の発生を想定することができるようになり、対策を用意したり、未然防止のための処置を講ずることができるようになる。さらに、システム変更時にも、上で述べたような処理を事前に行えば、大規模障害が発生しうる変更を回避するなどの処置が可能となる。

以上本技術の実施の形態を説明したが、本実施の形態はこれらに限定されるものではない。例えば、上で述べた機能ブロック図は一例であって、実際のプログラムモジュール構成とは一致しない場合もある。データ保持態様についても一例であって、必ずしも実際のファイル構成などと一致しない場合もある。

さらに、処理フローについても、処理結果が変わることがなければ、処理順番を入れ替えたり、並列実行するようにしても良い。

さらに、運用管理システム２００と情報処理装置１００が別の装置である例を示したが、一体となっている場合もある。また、情報処理装置１００が複数台のコンピュータで実現される場合もある。例えば、シミュレーション実行部１０９を別のコンピュータで実現するようにしても良い。

さらに、一度に発生する故障数についても変動させるようにしても良い。

なお、上で述べた情報処理装置１００及び運用管理システム２００は、コンピュータ装置であって、図４３に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本実施の形態をまとめると、以下のようになる。

本実施の形態に係る情報処理方法は、（Ａ）システム内の構成要素と当該構成要素間の関係とを表すデータを格納する第１のデータ格納部に格納されているデータから、システム内において影響を及ぼす範囲に関する指標値に関する所定の条件を満たす構成要素を特定する第１の特定処理と、（Ｂ）第１のデータ格納部に格納されているデータに基づき、特定された構成要素から所定の範囲内の構成要素を抽出する抽出処理と、（Ｃ）構成要素の種別毎に１又は複数の故障タイプが登録された第２のデータ格納部に格納されているデータから、抽出された構成要素の１つと当該構成要素に対応する故障タイプとのセットを１又は複数含む故障パターンを生成し、第３のデータ格納部に格納する生成処理とを含む。

システム内の全ての構成要素について故障パターンを生成するのではなく、故障パターンを生成すべき構成要素を上で述べたように絞り込むことで、効率的に影響の大きい故障パターンを特定できるようになる。なお、システム内において通信が集中しうる構成要素やメッセージが集中しうる構成要素は、その構成要素に障害が発生すると、システム全体に大規模な影響を与えることになる。従って、影響を及ぼす範囲が広い構成要素に着目するが、それだけではなく、この構成要素に故障及び障害で影響を及ぼす構成要素にも注目するものである。これによって自身の影響範囲は狭くても上で述べたような影響を及ぼす範囲が広い構成要素に影響を及ぼすことで、システム全体にインパクトを与えるような故障パターンの候補を生成できるようになる。

上で述べた情報処理方法は、（Ｄ）第３のデータ格納部に格納されている各故障パターンについてシステムの状態に関するシミュレーションを実施して当該故障パターンにおける故障から影響を受ける構成要素の数を特定する第２の特定処理をさらに含むようにしても良い。このようにシミュレーションを実施することによってさらに故障パターンを絞り込むことができるようになる。

また、上で述べた情報処理方法は、（Ｅ）特定された上記構成要素の数で降順に故障パターンをソートして、上位所定数の故障パターンを出力する処理をさらに含むようにしても良い。このようにすれば、ユーザは対処すべき故障パターンを容易に特定できるようになる。

さらに、上記情報処理方法において、上で述べた所定の範囲を変動させて、抽出処理と生成処理と第２の特定処理とを繰り返し実施させ、上記所定の範囲と、当該所定の範囲に対する第２の特定処理において特定される構成要素の数のうち最大値との関係を表すデータを生成するようにしても良い。このようにすれば、所定の範囲をどのように設定すべきかを判断できるようになる。すなわち、影響を及ぼす範囲が広い構成要素に影響を及ぼす構成要素をどの程度まで検討すべきかを把握できるようになる。

さらに、上で述べた構成要素間の関係が、構成要素間の接続関係と構成要素間の呼出関係とを含む場合がある。この場合、上で述べた第１の特定処理が、構成要素間の接続関係から各構成要素について配下の要素数を算出し、構成要素間の呼出関係から各構成要素について直接及び間接的な被呼出数を算出する処理と、配下の要素数と直接及び間接的な被呼出数とに基づき、所定の条件を満たす構成要素を特定する処理とを含むようにしても良い。配下の要素数と直接及び間接的な被呼出数とに別々に閾値を設定しても良いし、評価関数を用意して総合的に判断するようにしても良い。

なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ（Random Access Memory）等の記憶装置に一時保管される。

システム構成データ格納部２１０は、システム内の構成要素のデータと、構成要素間の接続関係のデータと、構成要素間の呼出関係のデータとを格納している。例えば、図２に示すように、スイッチＳｗｉｔｃｈ００１と、サーバＳｅｒｖｅｒ００１とが接続されている場合には、図３乃至図５のようなデータが、システム構成データ格納部２１０に格納される。図３は、接続のソース（Ｓｏｕｒｃｅ）となるスイッチＳｗｉｔｃｈ００１のデータを表しており、当該スイッチＳｗｉｔｃｈ００１のタイプと、各種属性及び状態などが登録されるようになっている。また、図４は、接続のターゲット（Ｔａｒｇｅｔ）となるサーバＳｅｒｖｅｒ００１のデータを表しており、サーバＳｅｒｖｅｒ００１のタイプと、各種属性及び状態などが登録されるようになっている。そして、図５は、スイッチＳｗｉｔｃｈ００１とサーバＳｅｒｖｅｒ００１との間の接続関係を表しており、関係のタイプ（Ｃｏｎｎｅｃｔｉｏｎ）と、ソースとなる構成要素と、ターゲットとなる構成要素と、接続状態などが登録されるようになっている。また、図６に示すように、サーバＳｅｒｖｅｒ００１からサーバＳｅｒｖｅｒ００２を呼び出す場合には、図４と図７及び図８に示すようなデータが、システム構成データ格納部２１０に格納される。図７は、呼出先のサーバＳｅｒｖｅｒ００２のデータを表しており、図４と同様に、サーバＳｅｒｖｅｒ００２のタイプ、各種属性及び状態などが登録されるようになっている。図８は、サーバＳｅｒｖｅｒ００１からサーバＳｅｒｖｅｒ００２への呼出関係を表しており、関係のタイプ（Ｃａｌｌ）と、ソースとなる構成要素、ターゲットとなる構成要素などが登録されるようになっている。

さらに、物理マシンの場合には、直下の仮想マシンの数が、物理マシンの配下の要素数となる。物理マシンｃｉ０５及びｃｉ０６の場合には、直下の仮想マシンの数は５であるから、配下の要素数は「５」となる。物理マシンｃｉ０７及びｃｉ０８の場合、直下の仮想マシンの数は０であるから、配下の要素数は「０」となる。物理マシンｃｉ０９の場合、直下の仮想マシンの数は１であるから、配下の要素数は「１」となる。仮想マシンの場合には、配下の要素数は０と特定される。

なお、配下の要素数及び被呼出数を総合的に評価した上で集約ポイントを抽出した場合、又は配下の要素数の基準と被呼出数の基準との両方の基準を満たすような集約ポイントが存在する場合には、接続関係について所定ホップ数以内の構成要素と、呼出関係について所定ホップ数以内の構成要素とを両方とも抽出する。

また、図１０に示したシステムにおいて用いられる要素タイプ「Ｍｇｒ」の構成要素についての状態遷移モデルの一例を図３０に示す。図３０に示すように、状態「停止中」、状態「起動中」及び状態「過負荷」が含まれている。そして、状態「停止中」から状態「起動中」への遷移は、トリガー「起動処理」に応じて行われる。状態「起動中」の第１の自己遷移は、トリガー「複製生成要求」でガード条件［要求量ｒがｒ_max以下］を満たせば行われる。この遷移が行われると要求量ｒが１インクリメントされる。また、状態「起動中」の第２の自己遷移は、トリガー「複製処理」でガード条件［ｒがｒ_max以下］を満たせば行われる。この遷移が行われると要求量ｒが１デクリメントされる。また、状態「起動中」から状態「過負荷」への遷移は、トリガー「複製生成要求」でガード条件［ｒ＞ｒ_max］で行われる。状態「過負荷」の第１の自己遷移は、トリガー「複製生成要求」でガード条件［ｒ＞ｒ_max］を満たせば行われる。この遷移が行われると要求量ｒが１インクリメントされる。また、状態「過負荷」の第２の自己遷移は、トリガー「複製処理」でガード条件［ｒ＞ｒ_max］を満たせば行われる。この遷移が行われると要求量ｒが１デクリメントされる。状態「過負荷」から状態「起動中」への遷移は、トリガー「複製処理」でガード条件［ｒ≦ｒ_max］を満たせば行われる。この遷移が行われると要求量ｒが１デクリメントされる。状態「起動中」から状態「停止中」への遷移、及び状態「過負荷」から状態「停止中」への遷移は、トリガー「シャットダウン処理」に応じて行われる。この遷移により要求量ｒは０になる。

例えば、図３９に示すような処理を実施する。まず、集約ポイント特定部１０１は、集約ポイント特定処理を実施する（図３９：ステップＳ２０１）。この集約ポイント特定処理については、図１０乃至図１６を用いて説明した処理と同じである。従って、詳細な説明は省略する。次に、故障箇所候補抽出部１０３は、カウンタｎを１に初期化する（ステップＳ２０３）。そして、故障箇所候補抽出部１０３は、故障箇所候補抽出処理を実施する（ステップＳ２０５）。この故障箇所候補抽出処理については、図１７乃至図２０を用いて説明した処理と同じである。従って、詳細な説明は省略する。その後、故障パターン生成部１０５は、故障パターン生成処理を実施する（ステップＳ２０７）。故障パターン生成処理については、図２１乃至図２４を用いて説明した処理と同じである。従って、詳細な説明については省略する。

さらに出力処理部１１２は、ｎが予め設定された最大値に達したか又は変動が収束したか判断する（ステップＳ２１５）。変動が収束というのは、例えば被害要素数の最大値が２回続けて変動しない場合などの条件を満たしているか判断する。

ｎが最大値に達しておらず且つ変動が収束していない場合、出力処理部１１２は、ｎを１インクリメントする（ステップＳ２１７）。そして処理はステップＳ２０５に戻る。

以上本技術の実施の形態を説明したが、本技術はこれらに限定されるものではない。例えば、上で述べた機能ブロック図は一例であって、実際のプログラムモジュール構成とは一致しない場合もある。データ保持態様についても一例であって、必ずしも実際のファイル構成などと一致しない場合もある。

Claims

システム内の構成要素と当該構成要素間の関係とを表すデータを格納する第１のデータ格納部に格納されているデータから、前記システム内において影響を及ぼす範囲に関する指標値に関する所定の条件を満たす構成要素を特定する第１の特定処理と、
前記第１のデータ格納部に格納されているデータに基づき、特定された前記構成要素から所定の範囲内の構成要素を抽出する抽出処理と、
構成要素の種別毎に１又は複数の故障タイプが登録された第２のデータ格納部に格納されているデータから、抽出された前記構成要素の１つと当該構成要素に対応する故障タイプとのセットを１又は複数含む故障パターンを生成し、第３のデータ格納部に格納する生成処理と、
を、コンピュータに実行させるためのプログラム。
前記第３のデータ格納部に格納されている各前記故障パターンについて前記システムの状態に関するシミュレーションを実施して当該故障パターンにおける故障から影響を受ける構成要素の数を特定する第２の特定処理、
をさらに前記コンピュータに実行させるための請求項１記載のプログラム。
特定された前記構成要素の数で降順に前記故障パターンをソートして、上位所定数の故障パターンを出力する処理
をさらに前記コンピュータに実行させるための請求項２記載のプログラム。
前記所定の範囲を変動させて、前記抽出処理と前記生成処理と前記第２の特定処理とを繰り返し実施させ、
前記所定の範囲と、当該所定の範囲に対する前記第２の特定処理において特定される構成要素の数のうち最大値との関係を表すデータを生成する
処理をさらに前記コンピュータに実行させるための請求項２又は３記載のプログラム。
前記構成要素間の関係が、前記構成要素間の接続関係と前記構成要素間の呼出関係とを含み、
前記第１の特定処理が、
前記構成要素間の接続関係から各前記構成要素について配下の要素数を算出し、前記構成要素間の呼出関係から各前記構成要素について直接及び間接的な被呼出数を算出する処理と、
前記配下の要素数と前記直接及び間接的な被呼出数とに基づき、前記所定の条件を満たす構成要素を特定する処理と、
を含む請求項１乃至４のいずれか１つ記載のプログラム。
システム内の構成要素と当該構成要素間の関係とを表すデータを格納する第１のデータ格納部に格納されているデータから、前記システム内において影響を及ぼす範囲に関する指標値に関する所定の条件を満たす構成要素を特定する第１の特定処理と、
前記第１のデータ格納部に格納されているデータに基づき、特定された前記構成要素から所定の範囲内の構成要素を抽出する抽出処理と、
構成要素の種別毎に１又は複数の故障タイプが登録された第２のデータ格納部に格納されているデータから、抽出された前記構成要素の１つと当該構成要素に対応する故障タイプとのセットを１又は複数含む故障パターンを生成し、第３のデータ格納部に格納する生成処理と、
を含み、コンピュータにより実行される情報処理方法。
システム内の構成要素と当該構成要素間の関係とを表すデータを格納する第１のデータ格納部に格納されているデータから、前記システム内において影響を及ぼす範囲に関する指標値に関する所定の条件を満たす構成要素を特定する特定部と、
前記第１のデータ格納部に格納されているデータに基づき、特定された前記構成要素から所定の範囲内の構成要素を抽出する抽出部と、
構成要素の種別毎に１又は複数の故障タイプが登録された第２のデータ格納部に格納されているデータから、抽出された前記構成要素の１つと当該構成要素に対応する故障タイプとのセットを１又は複数含む故障パターンを生成し、第３のデータ格納部に格納する生成部と、
を有する情報処理装置。