JPWO2014162595A1 - 管理システム及び管理プログラム - Google Patents

管理システム及び管理プログラム Download PDF

Info

Publication number
JPWO2014162595A1
JPWO2014162595A1 JP2015509840A JP2015509840A JPWO2014162595A1 JP WO2014162595 A1 JPWO2014162595 A1 JP WO2014162595A1 JP 2015509840 A JP2015509840 A JP 2015509840A JP 2015509840 A JP2015509840 A JP 2015509840A JP WO2014162595 A1 JPWO2014162595 A1 JP WO2014162595A1
Authority
JP
Japan
Prior art keywords
plan
cause
event
rule
expansion
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2015509840A
Other languages
English (en)
Other versions
JP6114818B2 (ja
Inventor
名倉　正剛
正剛 名倉
中島　淳
淳 中島
崇之 永井
崇之 永井
裕 工藤
裕 工藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of JPWO2014162595A1 publication Critical patent/JPWO2014162595A1/ja
Application granted granted Critical
Publication of JP6114818B2 publication Critical patent/JP6114818B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0769—Readable error formats, e.g. cross-platform generic formats, human understandable formats
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
    • G06F11/2094—Redundant storage or storage space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3031—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a motherboard or an expansion card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

管理システムは、複数の管理対象デバイスを有する計算機システムの管理を行う。管理システムの記憶デバイスは、１以上のルールと、プラン情報と、プラン履歴情報とを記憶する。管理システムの制御デバイスは、１以上のルールに基づいて、複数の管理対象デバイスのいずれかで発生したイベントの原因の候補となる第１の原因イベントを特定し、プラン情報に基づいて、第１の原因イベントが原因である場合に実施し得る複数の第１のプランを特定し、プラン履歴情報に基づいて、複数の第１のプランのそれぞれについて、当該プランを実施した場合の障害回復に成功する可能性を示す指標値を計算し、指標値に基づいて決定した表示形態に従って、複数の第１のプランのうちのいずれか１以上のプランを示すデータを表示する。

Description

本発明は、例えば、ホストコンピュータ、ネットワーク装置、及びストレージ装置等の管理対象装置を含む計算機システムを管理する技術に関する。
計算機システムの管理において、イベントコリレーション（Event Correlation）技術等のイベントベースでの障害原因を特定する技術を用いることで、計算機システムの管理者は、計算機システムにおいて発生した障害の原因を検出することが可能となっている（特許文献1参照）。
例えば、特許文献２は、管理対象装置において発生した複数の障害等のイベントの因果関係を解析するための解析エンジンが、事前に定められた条件文と結論文とからなる汎用ルールを、管理対象装置に関するイベント、例えば性能値が所定の閾値を超過することのイベントに適用することで、性能低下の原因となる原因イベントと、それによって引き起こされている条件イベント群を含む展開ルールを生成し、生成した展開ルールに基づいて障害の原因の特定を行う技術を開示している。
近年の計算機システムには、障害に対する回復策（障害からの復旧、すなわち障害回復を行うための方策）として実施可能な有用な方策が数多く存在しており、例えば、システムリソース(仮想マシン、データ)の配置にあたり、適切なデータ移動を行うことによって障害からの復旧を行うという方策等が存在する。データ移動を行う技術として、例えば、物理的なホストコンピュータの上で複数の仮想的なホストコンピュータ（仮想マシンのことであり、以下「ＶＭ」という）を動作させている環境において、ＶＭの性能を示す情報やリソースの利用情報に従って、ＶＭの動作を或る物理的なホストコンピュータから別の物理的なホストコンピュータに引き継がせる技術（第１のＶＭ移動）や、或る記憶領域に格納されているＶＭを別の記憶領域へ移動させる技術（第２のＶＭ移動）が知られている。ここで、ＶＭは記憶領域に格納されるデータの一種であり、ＶＭ移動（第１のＶＭ移動及び第２のＶＭ移動）は記憶領域間のデータ移動の一種である。また、ストレージ装置のデータ記憶領域（ボリューム）間でデータ移動を行う技術として、ボリュームマイグレーションが知られている（特許文献３参照）。
非特許文献１は、障害に対する回復策を実施した後に、その回復策により障害が改善されたかどうかを検査し、改善されていない場合は事前に定義された別の回復策を自動的に実施する技術を開示している。
また、特許文献４は、障害に対して過去にどのような回復策が実施されたかを記録しておき、回復策を選択する際にその記録した情報を利用する技術を開示している。
米国特許第７１０７１８５号明細書 特開２０１０−８６１１５号公報 米国特許第６１０８７４８号明細書 国際公開第２０１１／００７３９４号パンフレット
工藤裕、森村知弘、増岡義政、薦田憲久:"情報システムの運用自動化に向けたポリシー記述形式とポリシー実行スケジューリング方式"、電気学会Ｃ部門論文誌、Ｖｏｌ．１３１、Ｎｏ．１０、２０１１．
特許文献１や特許文献２のようなイベントコリレーション技術により特定された障害に対応する場合、管理者が具体的にどのような回復策を実施して障害回復を行えばよいかがわからず、障害から復旧するまでにコストがかかるという課題がある。障害原因と障害原因に対する回復策とのマッピングを取った上で、そのマッピングに基づいて障害原因に対する回復策を生成することができたとしても、実際の運用管理現場で、障害からの復旧作業を行う管理者の意図に沿って作業を実施するためにどの回復策を優先的に選択すればよいのかは、管理者にとって不明である。言い換えれば、障害原因及びその障害原因に対する回復策を管理者に提示する際、管理者の意図（障害回復に要する人的或いは経済的コストや、復旧作業の対象となる装置の重要性に基づく優先度判断等）によって、或る程度限定された回復策しか選択しないことがあるとしても、推論できるいくつもの回復策が管理者に提示されるため、どの回復策を選択すればよいのか、管理者には選択が困難になる。
非特許文献１に開示された技術を利用すると、選択された回復策が実施されることにより障害が改善されたかどうかを検査し、改善されていない場合は事前に定義された別の回復策を自動的に実施できる。これにより、回復策の実施後に問題個所が残った場合は、さらに別の回復策を実施できる。しかし、過去に同じような障害が発生している場合において、管理者によって過去にどのような回復策が実施されたかを考慮していないため、管理者の意図しない回復策を優先的に提示又は実施してしまう場合があり、管理者が回復策を選択する際のコストの増加を招くことがあり得る。
第１の観点に係る管理システムは、複数の管理対象デバイスを有する計算機システムの管理を行う。管理システムの記憶デバイスは、複数の管理対象デバイスのいずれかに関する原因イベントと、原因イベントが原因となることの条件となる、複数の管理対象デバイスのいずれかに関する１以上の条件イベントとの対応関係を示す１以上のルールと、ルールと当該ルールの原因イベントが原因である場合に実施し得る回復策であるプランとの対応関係を示すプラン情報と、プランが実施されるごとに、当該プランの実施による障害回復の成否を示すプラン履歴情報とを記憶する。管理システムの制御デバイスは、１以上のルールに基づいて、複数の管理対象デバイスのいずれかで発生したイベントの原因解析を行い、発生したイベントの原因の候補となる第１の原因イベントを特定し、プラン情報に基づいて、第１の原因イベントが原因である場合に実施し得る複数の第１のプランを特定し、プラン履歴情報に基づいて、複数の第１のプランのそれぞれについて、当該プランを実施した場合の障害回復に成功する可能性を示す指標値を計算し、指標値に基づいて決定した表示形態に従って、複数の第１のプランのうちのいずれか１以上のプランを示すデータを表示する。なお、「データを表示する」とは、管理システムが有する表示デバイスにデータを表示することであっても良いし、管理システムに接続され表示デバイスを有する遠隔のコンピュータに表示のためにデータを送信することであっても良い。
本発明によると、障害に対処する管理者を支援するための技術を提供できる。
図１は、第１の実施形態に係る計算機システムの一例の構成図である。 図２は、第１の実施形態に係るホストコンピュータの一例の構成図である。 図３は、第１の実施形態に係るストレージ装置の一例の構成図である。 図４は、第１の実施形態に係る管理サーバの一例の構成図である。 図５は、第１の実施形態に係る装置性能管理表の一例の構成図である。 図６は、第１の実施形態に係るボリュームトポロジ管理表の一例の構成図である。 図７は、第１の実施形態に係るイベント管理表の一例の構成図である。 図８は、第１の実施形態に係る汎用ルールの一例の構成図である。 図９Ａは、第１の実施形態に係る展開ルールの第１の例を示す図である。 図９Ｂは、第１の実施形態に係る展開ルールの第２の例を示す図である。 図９Ｃは、第１の実施形態に係る展開ルールの第３の例を示す図である。 図９Ｄは、第１の実施形態に係る展開ルールの第４の例を示す図である。 図１０は、第１の実施形態に係る解析結果管理表の一例の構成図である。 図１１は、第１の実施形態に係る汎用プラン表の一例の構成図である。 図１２は、第１の実施形態に係る展開プラン表の一例の構成図である。 図１３は、第１の実施形態に係るルール・プラン対応管理表の一例の構成図である。 図１４は、第１の実施形態に係るプラン実行履歴管理表の一例の構成図である。 図１５は、第１の実施形態に係る性能情報取得処理のフローチャートである。 図１６は、第１の実施形態に係る障害原因解析処理のフローチャートである。 図１７は、第１の実施形態に係るプラン展開処理のフローチャートである。 図１８は、第１の実施形態に係るプラン実行後リスク抽出処理のフローチャートである。 図１９は、第１の実施形態に係るプラン提示処理のフローチャートである。 図２０は、第１の実施形態に係るプラン提示画面の一例の構成図である。 図２１は、第１の実施形態に係るプラン実行処理のフローチャートである。 図２２は、第２の実施形態に係る管理サーバの一例の構成図である。 図２３は、第２の実施形態に係るテストケースリポジトリの一例の構成図である。 図２４は、第２の実施形態に係るテストケース抽出処理のフローチャートである。 図２５は、第３の実施形態に係る計算機システムの一例の構成図である。 図２６は、第３の実施形態に係る管理サーバの一例の構成図である。 図２７は、第３の実施形態に係るプラン実行履歴管理表の一例の構成図である。 図２８は、第３の実施形態に係る管理サーバ一覧表の一例の構成図である。 図２９は、第３の実施形態に係るプラン実行履歴交換処理のフローチャートである。 図３０は、第３の実施形態に係るプラン提示画面の一例の構成図である。
以下、本発明の実施形態を図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。なお、以後の説明では「ａａａ表」等の表現にて本発明の情報を説明するが、これら情報は表等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａ表」等について「ａａａ情報」、「ａａａデータ」と呼ぶことがある。さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名前」、「ＩＤ」という表現を用いるが、これらについては互いに置換が可能である。
以後の説明では「プログラム」又は「モジュール」を主語として説明を行う場合があるが、プログラム（モジュール）はプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（管理ポート、Ｉ／Ｏポート）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は、管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては、専用ハードウェアによって実現されてもよい。プロセッサ又はプロセッサとそのような専用ハードウェアとを含んだデバイスが「制御デバイス」と呼ばれてよい。また、各種プログラムは、プログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。
以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバが表示用情報を表示する場合は管理サーバが管理システムである、また、管理サーバと表示用計算機（例えば、ＷＥＢブラウザ起動サーバ）との組み合わせも管理システムである。また、管理処理の高速化や高信頼化のために複数の計算機で管理サーバと同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システムである。
（１）第１の実施形態
第１の実施形態は、管理ソフトウェア（例えば、管理サーバ内のプログラム）による障害原因の候補の表示処理に関する。
＜システム構成＞
図１は、第１の実施形態に係る計算機システムの一例の構成図である。
計算機システムは、１以上のストレージ装置２００００と、１以上のホストコンピュータ１００００と、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００とを有し、それらが、１以上のネットワーク装置、例えばＩＰスイッチ４００００、図示しないルータ等によって構成される通信ネットワーク４５０００によって接続される構成となっている。
ホストコンピュータ１００００は、例えば、図示しないクライアントコンピュータからファイルのＩ／Ｏ（入出力）要求を受信し、受信したＩ／Ｏ要求に基づいてストレージ装置２００００へのアクセスを行う。また、管理サーバ３００００は、計算機システム全体の運用を管理する。
ＷＥＢブラウザ起動サーバ３５０００は、通信ネットワーク４５０００を介して、管理サーバ３００００のＧＵＩ表示処理モジュールと通信し、ＷＥＢブラウザによって表示されるブラウザ画面上に各種情報を表示する。管理者は、ＷＥＢブラウザ起動サーバ３５０００上のブラウザ画面に表示された情報を参照することで、計算機システム内の各装置を管理する。ただし、管理サーバ３００００と、ＷＥＢブラウザ起動サーバ３５０００は１台のサーバから構成されていてもよい。
以下、計算機システムに含まれる装置のうち、管理サーバ３００００が管理の対象とする装置を「管理対象装置」と呼ぶ。本実施形態において、管理対象装置は、ホストコンピュータ１００００、ストレージ装置２００００、及びＩＰスイッチ４００００等のネットワーク装置であるが、その他の装置、例えば、ＮＡＳ（Network Attached Storage）、プリンタ等が管理対象装置として含まれてもよい。また、管理対象装置が有するデバイスのうち、管理サーバ３００００が管理の対象とするデバイスを「管理対象デバイス」と呼ぶ。
＜ホストコンピュータの内部構成＞
図２は、第１の実施形態に係るホストコンピュータの一例の構成図である。
ホストコンピュータ１００００は、通信ネットワーク４５０００に接続するためのポート１１０００と、プロセッサ１２０００と、メモリ１３０００とを有し、これらは内部バス等の回路を介して相互に接続される構成となっている。なお、ホストコンピュータ１００００は、例えばディスク（磁気ディスク）等の二次記憶デバイスを含んでいてもよい。
メモリ１３０００は、業務アプリケーション１３１００と、オペレーティングシステム（ＯＳ）１３２００とを記憶する。業務アプリケーション１３１００は、オペレーティングシステム１３２００から提供された記憶領域を使用し、当該記憶領域に対しデータの入出力（Ｉ／Ｏ）を行う。オペレーティングシステム１３２００は、通信ネットワーク４５０００を介してホストコンピュータ１００００に接続されたストレージ装置２００００上の論理ボリュームを、記憶領域として業務アプリケーション１３１００に認識させるための処理を実行する。
図２の例において、ポート１１０００は、ストレージ装置２００００とｉＳＣＳＩ（Internet Small Computer System Interface）により通信を行うためのＩ／Ｏポートと、管理サーバ３００００がホストコンピュータ１００００内の管理情報を取得するための管理ポートとを含む単一のポートとして表記されているが、それらが別々のポートとして分かれていてもよい。
＜ストレージ装置の内部構成＞
図３は、第１の実施形態に係るストレージ装置の一例の構成図である。
ストレージ装置２００００は、通信ネットワーク４５０００を介してホストコンピュータ１００００に接続するためのＩ／Ｏポート２１０００と、通信ネットワーク４５０００を介して管理サーバ３００００に接続するための管理ポート２１１００と、各種管理情報を格納するための管理メモリ２３０００と、ユーザデータを格納するためのＲＡＩＤ（Redundant Arrays of Inexpensive Disks）グループ２４０００と、ユーザデータや管理メモリ内の管理情報を制御するためのコントローラ２５０００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。なお、本実施形態において、ＲＡＩＤグループ２４０００が他のデバイスと接続されているとは、ＲＡＩＤグループ２４０００を構成するディスク２４２００が他のデバイスと接続されていることを意味する。
管理メモリ２３０００は、ストレージ装置２００００を管理するための管理プログラム２３１００を記憶する。管理プログラム２３１００は、管理ポート２１１００を経由して管理サーバ３００００と通信し、管理サーバ３００００に対してストレージ装置２００００の構成情報を提供する。
ＲＡＩＤグループ２４０００は、１以上のディスク２４２００によって構成される。ＲＡＩＤグループ２４０００が複数のディスク２４２００によって構成されている場合、それら複数のディスク２４０００は、ＲＡＩＤ構成を組んでいてもよい。また、ストレージ装置２００００には、ＲＡＩＤグループ２４０００内の記憶領域に基づいて、１以上の論理ボリューム２４１００が形成される。
なお、論理ボリューム２４１００は、１以上のディスク２４２００の記憶領域を用いて構成されるのであれば、ＲＡＩＤ構成を組まなくてもよい。また、論理ボリューム２４１００に対応する記憶領域を提供するデバイスとして、ディスク２４２００に代えて又は加えて、フラッシュメモリ等他の種類の記憶媒体が採用されてもよい。
コントローラ２５０００は、その内部に、ストレージ装置２００００の制御を行うプロセッサと、ホストコンピュータ１００００との間でやりとりするデータを一時的に格納するキャッシュメモリとを有する。コントローラ２５０００は、Ｉ／Ｏポート２１０００とＲＡＩＤグループ２４０００との間に介在し、両者の間でデータの受け渡しを行う。
なお、ストレージ装置２００００は、何れかのホストコンピュータ１００００に対して論理ボリューム２４１００を提供し、Ｉ／Ｏ要求を受信し、受信したＩ／Ｏ要求に応じて記憶デバイス（本実施形態では、ディスク２４２００）への読み書きを行うストレージコントローラ（本実施形態では、コントローラ２５０００）と、記憶領域を提供する記憶デバイスとを含めば、図３以外の構成でもよく、例えば、ストレージコントローラと記憶領域を提供する記憶デバイスとがそれぞれ別の筐体に存在していてもよい。また、図３の例では、管理メモリ２３０００とコントローラ２５０００とが別個のデバイスとして設けられているが、コントローラ２５０００が管理メモリ２３０００を含む構成としてもよい。また、ストレージコントローラと記憶デバイスとが同じ筐体に存在する場合と別の筐体に存在する場合との両者を含む表現として、「ストレージ装置」を例えば「ストレージシステム」と呼び変えてもよい。
＜管理サーバの内部構成＞
図４は、第１の実施形態に係る管理サーバの一例の構成図である。
管理サーバ３００００は、通信ネットワーク４５０００に接続するための管理ポート３１０００と、プロセッサ３１１００と、記憶デバイスの一種であるキャッシュメモリ等のメモリ３２０００と、記憶デバイスの一種であるＨＤＤ（ハードディスクドライブ）等の二次記憶デバイス３３０００と、処理結果を出力するためのディスプレイ等の出力デバイス３１２００と、管理者が指示を入力するためのキーボード等の入力デバイス３１３００とを有し、これらが内部バス等の回路を介して相互に接続される構成となっている。
メモリ３２０００は、プログラム制御モジュール３２１００、構成管理情報取得モジュール３２２００、装置性能取得モジュール３２３００、ＧＵＩ表示処理モジュール３２４００、イベント解析処理モジュール３２５００、ルール展開モジュール３２６００、プラン展開モジュール３２７００、プラン実行後リスク抽出モジュール３２８００、プラン提示モジュール３２９００、プラン実行モジュール３２９１０、プラン実行結果確認モジュール３２９２０、プラン実行履歴抽出モジュール３２９３０、及びプラン評価モジュール３２９４０のコンピュータプログラムを記憶する。なお、本実施形態において、各モジュールは、メモリ３２０００のソフトウェアモジュールとして提供されるが、ハードウェアモジュールとして提供されてもよい。また、各モジュールが行う処理が、１以上のプログラムコードとして提供されてもよく、モジュール間の明確な境界が存在しなくてもよい。モジュールは、プログラムと読み替えてもよい。
二次記憶デバイス３３０００は、装置性能管理表３３１００、ボリュームトポロジ管理表３３２００、イベント管理表３３３００、汎用ルールリポジトリ３３４００、展開ルールリポジトリ３３５００、解析結果管理表３３６００、汎用プラン表３３７００、１以上の展開プラン表３３８００、ルール・プラン対応管理表３３９００、及びプラン実行履歴管理表３３９５０を記憶する。汎用ルールリポジトリ３３４００には、１以上の汎用ルールが格納される。展開ルールリポジトリ３３５００には、１以上の展開ルールが格納される。汎用ルール及び展開ルールは、計算機システムを構成する管理対象デバイスで発生し得る１以上の条件イベントの組み合わせと、その１以上の条件イベントの組み合わせに対して障害の原因とされる原因イベントとの対応関係を示す情報である。なお、二次記憶デバイス３３０００は、例えば、半導体メモリ及びディスク、又は半導体メモリ及びディスクのいずれか一方から構成される。
ＧＵＩ表示処理モジュール３２４００は、入力デバイス３１３００を介した管理者からの要求に応じ、取得した構成管理情報を出力デバイス３１２００を介して表示する。なお、入力デバイス３１３００及び出力デバイス３１２００は、それぞれが別々のデバイスでもよく、１つのまとまったデバイスでもよい。
なお、管理サーバ３００００は、例えば、入力デバイス３１３００としてキーボード、ポインタデバイス等を有し、出力デバイス３１２００としてディスプレイ、プリンタ等を有しているが、これ以外の装置であってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを用い、当該インタフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。
＜装置性能管理表の構成＞
図５は、第１の実施形態に係る装置性能管理表の一例の構成図である。
装置性能管理表３３１００は、管理対象装置の識別子（以下「装置ＩＤ」という）を格納するためのフィールドである装置ＩＤ３３１１０と、管理対象デバイスの識別子（以下「デバイスＩＤ」という）を格納するためのフィールドであるデバイスＩＤ３３１２０と、管理対象デバイスに関する性能値の種類を示すメトリック名称を格納するためのフィールドであるメトリック３３１３０と、性能値の閾値異常が検知された管理対象装置のＯＳの種別を示すデータを格納するためのフィールドである機器ＯＳ３３１４０と、管理対象デバイスの性能値を当該デバイスを含む管理対象装置から取得して格納するためのフィールドである性能値３３１５０と、管理対象デバイスの性能値の正常範囲の上限又は下限の閾値（以下「アラート実行閾値」という）を、ユーザからの入力を受けて格納するためのフィールドであるアラート実行閾値３３１６０と、アラート実行閾値が正常範囲の上限であるのか下限であるのかを示すデータを格納するためのフィールドである閾値種別３３１７０と、性能値が正常値であるか異常値であるかを示すデータを格納するためのフィールドであるステータス３３１８０とを含む。
例えば、図５の上から１つ目のエントリは、ストレージ装置「ＳＹＳ１」（装置ＩＤが「ＳＹＳ１」であるストレージ装置２００００のことであり、以下、装置ＩＤを用いて管理対象装置を特定する場合に同様の表記をする）内のコントローラ「ＣＴＬ１」（デバイスＩＤが「ＣＴＬ１」であるコントローラ２５０００のことであり、以下、デバイスＩＤを用いて管理対象デバイスを特定する場合に同様の表記をする）に関するエントリである。このエントリから、コントローラ「ＣＴＬ１」について、プロセッサの稼働率が２０％を超えた場合に管理サーバ３００００によって過負荷であると判断されること、すなわちコントローラ「ＣＴＬ１」についてのアラート実行閾値が２０％であることが分かる。また、このエントリから、コントローラ「ＣＴＬ１」についての現時点のプロセッサの稼働率が４０％であり、本性能値が異常値であると判断されていることが分かる。
なお、図５では、管理対象デバイスの性能値として、プロセッサの稼働率（図面では単に「稼働率」と表記）、単位時間当たりのＩ／Ｏ量、及びレスポンスタイムを例として挙げているが、これら以外の性能値の種類が採用されてもよい。
＜ボリュームトポロジ管理表の構成＞
図６は、第１の実施形態に係るボリュームトポロジ管理表の一例の構成図である。
ボリュームトポロジ管理表３３２００は、計算機システム内の複数の管理対象デバイス間の接続関係を管理するための情報（接続情報）である。ボリュームトポロジ管理表３３２００は、ストレージ装置２００００の装置ＩＤを格納するためのフィールドである装置ＩＤ３３２１０と、ストレージ装置２００００が有する論理ボリューム２４１００についてのストレージ装置２００００内で利用される識別子（以下「ボリュームＩＤ」という）を格納するためのフィールドであるボリュームＩＤ３３２２０と、ホストコンピュータ１００００が論理ボリューム２４１００を認識するための論理ボリューム２４１００の識別子（以下「ＬＵ番号」という）を格納するためのフィールドであるＬＵ番号３３２３０と、ホストコンピュータ１００００が論理ボリューム２４１００にアクセスする際に使用されるコントローラ２５０００のデバイスＩＤを格納するためのフィールドであるコントローラ名３２３４０と、論理ボリューム２４１００にアクセスするホストコンピュータ１００００の装置ＩＤを格納するためのフィールドである接続先ホストＩＤ３３２５０と、論理ボリューム２４１００が実体となるホストコンピュータ１００００内のボリューム（ドライブ）のデバイスＩＤを格納するためのフィールドである接続先ドライブ名３３２６０とを含む。
例えば、図６の上から１つ目のエントリから、ストレージ装置「ＳＹＳ１」の論理ボリューム「ＶＯＬ１」が、「ＬＵ１」というＬＵ番号で示される論理ユニット（ＬＵ）としてホストコンピュータ「ＨＯＳＴ１」に提供されており、ホストコンピュータ「ＨＯＳＴ１」は、コントローラ「ＣＴＬ１」を介して論理ボリューム「ＶＯＬ１」にアクセスし、ホストコンピュータ「ＨＯＳＴ１」上で論理ボリューム「ＶＯＬ１」がドライブ「／ｖａｒ」として認識されていることが分かる。なお、本実施形態において、論理ボリューム２４１００のデバイスＩＤとして、ボリュームＩＤを用いる場合と、ＬＵ番号を用いる場合とがある。例えば、論理ボリューム「ＶＯＬ１」を論理ボリューム「ＬＵ１」と表記する場合もあるが、いずれも同じ論理ボリューム２４１００を指している。
＜イベント管理表の構成＞
図７は、第１の実施形態に係るイベント管理表の一例の構成図である。イベント管理表３３３００は、後述する障害原因解析処理（図１６）において適宜参照される。
イベント管理表３３３００は、障害等のイベントに付された識別子（以下「イベントＩＤ」という）を格納するためのフィールドであるイベントＩＤ３３３１０と、イベントの発生した管理対象装置の装置ＩＤを格納するためのフィールドである装置ＩＤ３３３２０と、イベントの発生した管理対象デバイスのデバイスＩＤを格納するためのフィールドである装置部位ＩＤ３３３３０と、閾値異常が検知された性能値に関するメトリック名称を格納するためのフィールドであるメトリック３３３４０と、閾値異常が検知された管理対象装置のＯＳの種別を示すデータを格納するためのフィールドである機器ＯＳ３３３５０と、イベントの発生した管理対象デバイスのイベント発生時の状態を示すデータを格納するためのフィールドであるステータス３３３６０と、イベントがイベント解析処理モジュール３２５００によって解析済みかどうかを示すデータを格納するためのフィールドである解析済フラグ３３３７０と、イベントが発生した日時を示すデータを格納するためのフィールドである発生日時３３３８０とを含む。
例えば、図７の上から１つ目のエントリから、管理サーバ３００００が、ストレージ装置「ＳＹＳ１」のコントローラ「ＣＴＬ１」におけるプロセッサの稼働率の閾値異常を検知し、その閾値異常に対応するイベントのイベントＩＤが「ＥＶ１」であることが分かる。
＜汎用ルールの構成＞
図８は、第１の実施形態に係る汎用ルールの一例の構成図である。
汎用ルールは、複数の管理対象デバイスのいずれかに関する原因イベントと、原因イベントが障害の原因となることの条件となる、複数の管理対象デバイスのいずれかに関する１以上の条件イベントとの対応関係を示すルールであって、原因イベント及び条件イベントに関係する管理対象デバイスを当該管理対象デバイスの種別で表したルールである。一般的に、障害解析において原因を特定するためのイベント伝播モデルは、或る障害（原因）によって発生することが予想されるイベントの組み合わせと、その原因とが“ＩＦ−ＴＨＥＮ”形式で記載される。なお、汎用ルールは、図８に挙げられたものに限られず、さらに多くのルールがあっても構わない。
汎用ルールは、汎用ルールの識別子（以下「汎用ルールＩＤ」という）を格納するためのフィールドである汎用ルールＩＤ３３４３０と、“ＩＦ−ＴＨＥＮ”形式で記載した汎用ルールのＩＦ部に相当する観測事象、すなわち、１以上の条件イベントのそれぞれを示すデータを格納するためのフィールドである条件部３３４１０と、“ＩＦ−ＴＨＥＮ”形式で記載した汎用ルールのＴＨＥＮ部に相当する原因事象、すなわち、原因イベントを示すデータを格納するためのフィールドである結論部３３４２０と、汎用ルールを実システムに展開し、展開ルールを生成する際に参照されるトポロジ情報（接続情報）を示すデータを格納するためのフィールドである適用トポロジ３３４４０とを含む。また、条件部３３４１０は、条件イベントごとに、条件イベントに付された番号（以下「条件イベント番号」という）を格納するためのフィールド３３４５０を含む。条件部３３４１０が示す１以上の条件イベントが検知された場合、結論部３３４２０が示す原因イベントが障害の原因と判定される。結論部３３４２０のステータスが正常になれば、条件部３３４１０の問題も解決されることが期待される。図８の例では、条件部３３４１０には２つの条件イベントが記述されているが、条件イベントの数に制限はない。
例えば、図８に例示した汎用ルール、すなわち、汎用ルール「Ｒｕｌｅ１」（汎用ルールＩＤが「Ｒｕｌｅ１」である汎用ルールのことであり、以下、識別子を用いてルールを特定する場合に同様の表記をする）は、観測事象として、ホストコンピュータ１００００のドライブにおけるレスポンスタイムの閾値異常と、ストレージ装置２００００の論理ボリューム２４１００（ＬＵ）における単位時間のＩ／Ｏ量の閾値異常とが検知されたときに、ストレージ装置２００００の論理ボリューム２４１００における単位時間のＩ／Ｏ量の閾値異常が原因であると結論付けられることを示している。また、この汎用ルールに基づいて展開ルールを生成する際には、ボリュームトポロジ管理表３３２００がトポロジ情報として参照される。なお、観測事象に含まれる条件イベントとして、或る条件が正常であることを定義してもよい。
＜展開ルールの構成＞
図９Ａは、第１の実施形態に係る展開ルールの第１の例を示す図である。図９Ｂは、第１の実施形態に係る展開ルールの第２の例を示す図である。図９Ｃは、第１の実施形態に係る展開ルールの第３の例を示す図である。図９Ｄは、第１の実施形態に係る展開ルールの第４の例を示す図である。
展開ルールは、汎用ルールを計算機システムの実構成に依存する形式に展開したルールである。すなわち、展開ルールは、複数の管理対象デバイスのいずれかに関する原因イベントと、原因イベントが障害の原因となることの条件となる、複数の管理対象デバイスのいずれかに関する１以上の条件イベントとの対応関係を示すルールであって、原因イベント及び条件イベントに関係する管理対象デバイスを特定の管理対象デバイスを示すデータで表したルールである。展開ルールは、汎用ルールにおける条件イベント及び原因イベントのそれぞれに関係する管理対象装置の種別及び管理対象デバイスの種別を、ボリュームトポロジ管理表３３２００で定義されている特定の管理対象装置の装置ＩＤ及び特定の管理対象デバイスのデバイスＩＤに置き換えることによって生成される。
以下、図９Ａを参照して展開ルールの構成を説明する。展開ルールは、展開ルールの識別子（以下「展開ルールＩＤ」という）を格納するためのフィールドである展開ルールＩＤ３３５３０と、展開ルールの基となった汎用ルールの汎用ルールＩＤを格納するためのフィールドである展開前汎用ルールＩＤ３３５４０と、“ＩＦ−ＴＨＥＮ”形式で記載した展開ルールのＩＦ部に相当する観測事象、すなわち、１以上の条件イベントのそれぞれを示すデータを格納するためのフィールドである条件部３３５１０と、“ＩＦ−ＴＨＥＮ”形式で記載した展開ルールのＴＨＥＮ部に相当する原因事象、すなわち、原因イベントを示すデータを格納するためのフィールドである結論部３３５２０とを含む。また、条件部３３５１０は、条件イベントごとに、条件イベントに付された条件イベント番号を格納するためのフィールド３３５５０を含む。
例えば、図９Ａに例示した展開ルールは、図８に示す汎用ルール「Ｒｕｌｅ１」における条件イベント及び原因イベントのそれぞれに関係する管理対象装置の種別及び管理対象デバイスの種別を、ボリュームトポロジ管理表３３２００で定義されている特定の管理対象装置（ホストコンピュータ「ＨＯＳＴ１」、ストレージ装置「ＳＹＳ１」）の装置ＩＤ及び特定の管理対象デバイス（ドライブ「／ｖａｒ」、論理ボリューム「ＬＵ１」）のデバイスＩＤに置き換えることによって生成される。そして、図９Ａから、展開ルール「ＥｘＲｕｌｅ１−１」が、汎用ルール「Ｒｕｌｅ１」を基に展開され、観測事象として、ホストコンピュータ「ＨＯＳＴ１」のドライブ「／ｖａｒ」におけるレスポンスタイムの閾値異常と、ストレージ装置「ＳＹＳ１」の論理ボリューム「ＬＵ１」における単位時間のＩ／Ｏ量の閾値異常とが検知されたときに、ストレージ装置「ＳＹＳ１」の論理ボリューム「ＬＵ１」における単位時間のＩ／Ｏ量の閾値異常が原因であると結論付けられることが分かる。
＜解析結果管理表の構成＞
図１０は、第１の実施形態に係る解析結果管理表の一例の構成図である。
解析結果管理表３３６００は、障害原因解析処理において障害原因の候補と判断されたイベント（以下「原因候補イベント」という）（第１の原因イベント）に関係する管理対象装置の装置ＩＤを格納するためのフィールドである原因装置ＩＤ３３６１０と、原因候補イベントに関係する管理対象デバイスのデバイスＩＤを格納するためのフィールドである原因部位ＩＤ３３６２０と、原因候補イベントの種別を示すデータ、すなわち、原因候補イベントに関係する性能値に関するメトリック名称を格納するためのフィールドであるメトリック３３６３０と、原因候補イベントが根本原因であることの確からしさを示す値（確信度）を格納するためのフィールドである確信度３３６４０と、原因候補イベントを原因イベントとして含む展開ルール、すなわち、原因候補イベントを障害原因の候補と判断した根拠となる展開ルールの展開ルールＩＤを格納するためのフィールドである展開ルールＩＤ３３６５０と、原因候補イベントを原因イベントとして含む展開ルールの１以上の条件イベントのうちの実際に発生したイベントのイベントＩＤを格納するためのフィールドである受信イベントＩＤ３３６６０と、解析結果を元に管理者が実際に障害対応を行ったかどうかを示すデータを格納するためのフィールドである対応済フラグ３３６７０と、イベントの発生に伴う障害解析処理を開始した日時を示すデータを格納するためのフィールドである解析実行日時３３６８０とを含む。なお、本実施形態において、確信度は、過去一定期間内における条件イベントの発生割合である。
例えば、図１０の上から１つ目のエントリから、展開ルール「ＥｘＲｕｌｅ１−１」に基づき、管理サーバ３００００が、ストレージ装置「ＳＹＳ１」の論理ボリューム「ＬＵ１」における単位時間のＩ／Ｏ量の閾値異常を障害原因の候補として判断したこと、イベントＩＤが「ＥＶ３」、「ＥＶ６」で示されるイベントが発生したことが当該判断の根拠とされたこと、及び、確信度、すなわち条件イベントの発生割合が１００％（２／２×１００）であることが分かる。
＜汎用プランの構成＞
図１１は、第１の実施形態に係る汎用プラン表の一例の構成図である。
汎用プラン表３３７００は、汎用プランの一覧を示す情報である。ここで、汎用プランとは、計算機システムにおいて実施可能な障害に対する回復策（以下「プラン」という）であって計算機システムの実構成に依存しない形式で示したプランのことをいう。汎用プラン表３３７００は、汎用プランＩＤ３３７１０、及びプラン３３７２０のフィールドを含む。汎用プランＩＤ３３７１０には、汎用プランの識別子（以下「汎用プランＩＤ」という）が格納される。プラン３３７２０には、計算機システムにおいて実行可能な汎用プランを示すデータ、例えば、汎用プランの名称が格納される。汎用プランとしては、例えば、ホストコンピュータ１００００のリブート、ＩＰスイッチ４００００の設定変更、ストレージ装置２００００におけるボリュームマイグレーション、ＶＭ移動等がある。なお、汎用プランは、図１１に挙げられたものに限られない。
＜展開プランの構成＞
図１２は、第１の実施形態に係る展開プラン表の一例の構成図である。
展開プラン表３３８００は、１以上の展開プランを管理するための情報である。展開プランは、汎用プランを計算機システムの実構成に依存する形式に展開したプランである。展開プラン表３３８００は、プラン展開モジュール３２７００によって、展開ルール、汎用プラン表３３７００、ボリュームトポロジ管理表３３２００、及び装置性能管理表３３１００に基づいて生成される。
展開プラン表３３８００は、プラン詳細３３８１０、汎用プランＩＤ３３８２０、展開ルールＩＤ３３８２３、及び汎用ルールＩＤ３３８２５のフィールドを含む。汎用プランＩＤ３３８２０には、展開プランの基となった汎用プランの汎用プランＩＤが格納される。展開ルールＩＤ３３８２３には、展開されたプランが、どの障害原因に対するプランなのかを識別するための情報として、展開プランに対応する展開ルールの展開ルールＩＤが格納される。すなわち、展開プラン表３３８００内の各展開プランは、展開ルールＩＤ３３８２３の展開ルールＩＤによって示される展開ルールの原因イベントが障害原因である場合に実施し得るプラン（当該障害原因に対するプラン）である。つまり、展開プラン表３３８００は、展開ルールと、当該展開ルールに対応する１以上の展開プランとの対応関係を管理するための情報であるとも言える。本実施形態では、展開プラン表３３８００は、展開ルールと汎用プランとの組み合わせごとに作成されるが、例えば展開ルールごとに作成される等、別の形態が採用されてもよい。展開プラン表３３８００は、ルールと、当該ルールの原因イベントが原因である場合に実施し得るプランとの対応関係を示す情報（プラン情報）に対応する。汎用ルールＩＤ３３８２５には、展開プランに対応する展開ルールの基となった汎用ルールの汎用ルールＩＤが格納される。
プラン詳細３３８１０には、展開された１以上の展開プランのそれぞれについての具体的な処理内容及び展開プラン実行後の状態情報が格納される。プラン詳細３３８１０は、展開プランＩＤ３３８３０、プラン対象３３８４０、及びリスク箇所３３８９０のフィールドを含む。展開プランＩＤ３３８３０には、展開プランの識別子（以下「展開プランＩＤ」という）が格納される。プラン対象３３８４０には、展開プランに関係する構成要素（デバイス）を示す情報、プラン実行後の情報等が格納される。リスク箇所３３８９０には、プラン実行後にも潜在的に残されたままになる問題個所（以下「リスク箇所」という）を示すデータが格納される。
図１２に例示した展開プラン表３３８００は、汎用プランＩＤが「Ｐｌａｎ１」である汎用プランに基づく展開プラン、すなわちボリュームマイグレーションに関する展開プランを管理する。ボリュームマイグレーションに関する展開プランの場合、プラン対象３３８４０は、例えば、移動対象ボリューム３３８５０、移動元装置３３８６０、及び移動先装置３３８７０のフィールドを含む。移動対象ボリューム３３８５０は、ボリュームマイグレーションの対象となる論理ボリューム２４１００（以下「移動対象ボリューム」という）のデバイスＩＤを格納するためのフィールドであるボリュームＩＤ３３８５０Ａと、ボリュームマイグレーション実行後の、移動対象ボリュームに対するＩ／Ｏのレスポンスタイムの予測値を格納するためのフィールドであるＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測３３８５０Ｂとを含む。移動元装置３３８６０は、移動対象ボリュームを有しているストレージ装置２００００（以下「移動元装置」という）の装置ＩＤを格納するためのフィールドである装置ＩＤ３３８６０Ａと、ボリュームマイグレーション実行後の、移動元装置に対するＩ／Ｏのレスポンスタイムの予測値を格納するためのフィールドであるＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測３３８６０Ｂとを含む。移動先装置３３８７０は、移動対象ボリュームのデータの移動先となるストレージ装置２００００（以下「移動先装置」という）の装置ＩＤを格納するためのフィールドである装置ＩＤ３３８７０Ａと、ボリュームマイグレーション実行後の、移動先装置に対するＩ／Ｏのレスポンスタイムの予測値を格納するためのフィールドであるＩ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測３３８７０Ｂとを含む。
ボリュームＩＤ３３８５０Ａ、装置ＩＤ３３８６０Ａ、及び装置ＩＤ３３８７０Ａの各情報は、プラン展開モジュール３２７００が、ボリュームトポロジ管理表３３２００から情報を取得し、格納する。また、各Ｉ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測３３８５０Ｂ、３３８６０Ｂ、及び３３８７０Ｂに格納される値の算出方法としては、任意の方法を採用してもよい。例えば、各Ｉ／Ｏ ＲｅｓｐｏｎｓｅＴｉｍｅ予測３３８５０Ｂ、３３８６０Ｂ、及び３３８７０Ｂの値を、例えば、プラン展開モジュール３２７００が、装置性能管理表３３１００から、移動対象ボリューム、移動元装置、及び移動先装置の単位時間当たりのＩ／Ｏ量を取得し、移動対象ボリュームの単位時間当たりのＩ／Ｏ量の値を、移動元装置の単位時間当たりのＩ／Ｏ量から減算し、移動先装置の単位時間当たりのＩ／Ｏ量に加算して、ボリュームマイグレーション実行後の移動元装置及び移動先装置のＩ／Ｏ量を予測し、その逆数を取ることで得られる値（Ｉ／Ｏのレスポンスタイム）としてもよい。なお、図１２の例では、プラン詳細３３８１０の内容として、性能情報が格納される例を記載したが、プランに関するコスト情報やプランを実行した際における障害によるシステムのダウンタイム時間情報等が格納されてもよい。
また、図１２は、ボリュームマイグレーションに関する展開プランの例を示しているが、汎用プラン表３３７００に含まれるその他の汎用プランに対応する展開プランも同様に生成される。その他の汎用プランを展開プランに展開する場合においても、プラン展開モジュール３２７００が、例えば、ボリュームトポロジ管理表３３２００を参照して、プランに関係するデバイスを列挙し、装置性能管理表３３１００を参照して、性能情報、容量情報、コスト情報、ダウンタイム情報等の、プラン実行後の状態情報をシミュレートすることによって、プランに関係するデバイスに関する、プラン実行後の性能値の予測値を計算する。
＜ルール・プラン対応管理表の構成＞
図１３は、第１の実施形態に係るルール・プラン対応管理表の一例の構成図である。
ルール・プラン対応管理表３３９００は、汎用ルールと、当該汎用ルールに対応する１以上の汎用プラン、すなわち、当該汎用ルールの原因イベントが原因である場合に実施し得る１以上の汎用プランとの対応関係を管理するための情報である。ルール・プラン対応管理表３３９００は、ルールと、当該ルールの原因イベントが原因である場合に実施し得るプランとの対応関係を示す情報（プラン情報）に対応する。ルール・プラン対応管理表３３９００は、汎用ルールと、その汎用ルールを適用して障害の原因を特定した場合に実施可能な汎用プランのリストと、各汎用プランを実行した場合に未解決状態のまま残るイベント（以下「未解決イベント」という）との対応関係を示す。
ルール・プラン対応管理表３３９００は、汎用ルールＩＤ３３９１０、汎用プランＩＤ３３９２０、及び未解決イベントＩＤ３３９３０のフィールドを含む。汎用ルールＩＤ３３９１０には、汎用ルールの汎用ルールＩＤが格納される。汎用プランＩＤ３３９２０には、汎用プランの汎用プランＩＤが格納される。未解決イベントＩＤ３３９３０には、各汎用プランを実行した場合に未解決状態のまま残るイベント（未解決イベント）の識別子（以下「未解決イベントＩＤ」という）が格納される。未解決イベントＩＤは、汎用ルールの条件部３３４１０のフィールド３３４５０に格納される条件イベント番号に対応している。未解決イベントＩＤ３３９３０には、例えば、未解決イベントが存在しない場合に「ＮＯＮＥ」が格納され、条件イベント及び原因イベントの全てが未解決イベントとして残る場合に「ＡＬＬ」が格納される。
＜プラン実行履歴管理表の構成＞
図１４は、第１の実施形態に係るプラン実行履歴管理表の一例の構成図である。
プラン実行履歴管理表３３９５０は、計算機システムにおいて実行された展開プラン、例えばプラン実行モジュール３２９１０が実行した展開プランについての実行結果（障害回復の成否）を管理するための情報（プラン履歴情報）である。プラン実行履歴管理表３３９５０は、展開ルールＩＤ３３９６０、展開プランＩＤ３３９７０、実行成否３３９８０、及び実施日時３３９９０のフィールドを含む。展開ルールＩＤ３３９６０には、展開ルールの展開ルールＩＤが格納される。展開プランＩＤ３３９７０には、展開プランの展開プランＩＤが格納される。実行成否３３９８０には、展開プランの実行による障害回復の成否を示すデータ、すなわち、展開プランＩＤ３３９７０の展開プランＩＤが示す展開プランの実行によって、展開ルールＩＤ３３９６０の展開ルールＩＤが示す展開ルールの原因イベントを障害原因とする障害の回復に成功したか否かを示すデータが格納される。例えば、実行成否３３９８０には、障害回復に成功した場合に「ＯＫ」が格納され、障害回復に失敗した場合に「ＮＧ」が格納される。実施日時３３９９０には、展開プランが実行された日時を示すデータが格納される。
なお、図１４の例では、プラン実行履歴管理表３３９５０の各エントリ（履歴要素）は、障害原因（正確には、障害原因の候補）と特定された原因イベントを含む展開ルールと、当該障害原因に対して実行された展開プランと、当該展開プランの実行による障害回復の成否とを対応付けて示しているが、プラン実行履歴管理表３３９５０の構成は、これに限られない。各エントリが、障害原因と、当該障害原因に対して実行された展開プランと、当該展開プランの実行による障害回復の成否とを対応付けて示し得る構成であればよい。例えば、各エントリが、障害原因と特定された原因イベントと、当該障害原因に対して実行された展開プランと、当該展開プランの実行による障害回復の成否とを対応付けて示すように構成されてもよい。
次に、管理サーバ３００００が実行する各処理について説明する。
＜構成管理情報の取得処理、及びボリュームトポロジ管理表の更新処理＞
プログラム制御モジュール３２１００は、例えばポーリング処理によって、構成管理情報取得モジュール３２２００に対し、計算機システム内の管理対象装置、本実施形態ではストレージ装置２００００、ホストコンピュータ１００００、及びＩＰスイッチ４００００から、構成管理情報を定期的に取得するよう指示する。
構成管理情報取得モジュール３２２００は、ストレージ装置２００００、ホストコンピュータ１００００、及びＩＰスイッチ４００００から構成管理情報を取得するとともに、取得した構成管理情報に基づいてボリュームトポロジ管理表３３２００内のデータを更新する。
＜装置性能情報取得処理及びイベント解析処理＞
図１５は、第１の実施形態に係る性能情報取得処理のフローチャートである。
プログラム制御モジュール３２１００は、例えば、プログラムの起動時或いは前回の性能情報取得処理から一定時間経過するたびに、装置性能取得モジュール３２３００に対して、性能情報取得処理の実行を指示する。なお、当該実行指示を繰り返し出す場合は、厳密に一定期間ごとである必要は無く、繰り返しさえしていればよい。
装置性能取得モジュール３２３００は、各管理対象装置に対し、以下の一連の処理を繰り返す。
装置性能取得モジュール３２３００は、まず、各管理対象装置に対して、性能情報の送信を指示する（ステップ６１０１０）。
装置性能取得モジュール３２３００は、管理対象装置から応答があったか否かを判定する（ステップ６１０２０）。管理対象装置から応答があった場合、すなわち管理対象装置から性能情報を受信した場合（ステップ６１０２０：Ｙｅｓ）、装置性能取得モジュール３２３００は、受信した性能情報に基づいて装置性能管理表３３１００の性能値３３１５０の値を更新する（ステップ６１０３０）。一方、管理対象装置から応答がなかった場合（ステップ６１０２０：Ｎｏ）、装置性能取得モジュール３２３００は、性能情報取得処理を終了する。
次に、装置性能取得モジュール３２３００は、装置性能管理表３３１００に格納された各管理対象デバイスの性能値を参照し、各性能値に対してステップ６１０５０からステップ６１０７０までの処理を繰り返す（ステップ６１０４０）。
装置性能取得モジュール３２３００は、性能値がアラート実行閾値を超過しているか否かを確認し、その確認結果に基づいて装置性能管理表３３１００のステータス３３１８０の値を更新する（ステップ６１０５０）。そして、装置性能取得モジュール３２３００は、性能値の状態が変化したか否か、すなわち性能値が正常値から異常値に或いは異常値から正常値に変化したか否かを判定する（ステップ６１０６０）。状態が変化している場合（ステップ６１０６０：Ｙｅｓ）、装置性能取得モジュール３２３００は、イベント管理表３３７００に、その性能値の状態の変化に対応するイベントに関するエントリを登録する（ステップ６１０７０）。一方、状態が変化していない場合（ステップ６１０６０：Ｎｏ）、装置性能取得モジュール３２３００は、全ての性能値に対する状態確認処理（ステップ６１０５０からステップ６１０７０までの処理）が終わっていなければ、処理をステップ６１０４０へ進める。
全ての性能値に対する状態確認処理が終了した後、装置性能取得モジュール３２３００は、イベント管理表３３７００に新規に登録されたイベント（イベントに関するエントリ）があるか否かを判定する（ステップ６１０８０）。新規に登録されたイベントがある場合（ステップ６１０８０：Ｙｅｓ）、装置性能取得モジュール３２３００は、イベント解析処理モジュール３２５００に対して、障害原因解析処理（図１６参照）の実行を指示する（ステップ６１０９０）。一方、新規に登録されたイベントがない場合（ステップ６１０８０：Ｎｏ）、装置性能取得モジュール３２３００は、性能情報取得処理を終了する。
＜障害原因解析処理の詳細＞
図１６は、第１の実施形態に係る障害原因解析処理のフローチャートである。障害原因解析処理は、図１５のステップ６１０９０の処理に対応する。
イベント解析処理モジュール３２５００は、イベント管理表３３３００から、解析済フラグ３３３７０の値が「Ｙｅｓ」になっていないイベントに関するエントリを取得する（ステップ６２０１０）。
次に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００内の各展開ルールに対して、ステップ６２０３０の処理を繰り返す（ステップ６２０２０）。イベント解析処理モジュール３２５００は、処理対象の展開ルールについての確信度（処理対象の展開ルールの原因イベントについての確信度）、すなわち、処理対象の展開ルールに含まれる１以上の条件イベントの過去一定期間内の発生割合を算出する（ステップ６２０３０）。
続いて、イベント解析処理モジュール３２５００は、イベント管理表３３３００におけるステップ６２０１０で取得したエントリの解析済フラグ３３３７０を「Ｙｅｓ」に設定する（ステップ６２０５０）。そして、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００内の展開ルールのうちの、ステップ６２０３０で計算した確信度が０でない展開ルールのそれぞれについて、当該展開ルールの原因イベントを障害原因の候補（第１の原因イベント）とする解析結果管理表３３６００のエントリを生成し、生成したエントリを解析結果管理表３３６００に登録する（ステップ６２０６０）。
次に、イベント解析処理モジュール３２５００は、展開ルールリポジトリ３３５００内の各展開ルールに対して、ステップ６２０７０からステップ６２１００までの処理を繰り返す（ステップ６２０７０）。イベント解析処理モジュール３２５００は、処理対象の展開ルールについてのステップ６２０３０で計算した確信度が一定値を超えているか否かを判定する（ステップ６２０８０）。
確信度が一定値を超えている場合（ステップ６２０８０：Ｙｅｓ）、イベント解析処理モジュール３２５００は、プラン展開モジュール３２７００に対して、処理対象の展開ルールについてのプラン展開処理の実行を指示する（ステップ６２０９０）。このプラン展開処理により、処理対象の展開ルールに対応する展開プラン、すなわち、処理対象の展開ルールの原因イベントが障害原因である場合のその障害原因に対する展開プランが生成される。
一方、確信度が一定値を超えていない場合（ステップ６２０８０：Ｎｏ）、イベント解析処理モジュール３２５００は、処理対象の展開ルールについてのステップ６２０９０の処理は行わない。
展開ルールリポジトリ３３５００内の各展開ルールに対してステップ６２０７０からステップ６２１００までの処理を終えた後、イベント解析処理モジュール３２５００は、障害原因解析処理を終了する。
例えば、図９Ａに示す展開ルール「ＥｘＲｕｌｅ１−１」の条件イベントは、ホストコンピュータ「ＨＯＳＴ１」のドライブ「／ｖａｒ」におけるレスポンスタイムの閾値異常に対応するイベント（以下「イベントＡ」という）と、ストレージ装置「ＳＹＳ１」の論理ボリューム「ＬＵ１」における単位時間のＩ／Ｏ量の閾値異常に対応するイベント（以下「イベントＢ」という）との２つである。
そして、イベント管理表３３３００にイベントＢ（図７の例では「ＥＶ３」のイベントＩＤを持つイベント）に関するエントリが登録されると、イベント解析処理モジュール３２５００は、一定時間待機した後にイベント管理表３３３００を参照し、過去一定期間に発生したイベントを特定する。
次に、イベント解析処理モジュール３２５００は、展開ルール「ＥｘＲｕｌｅ１−１」についての確信度（過去一定期間内における条件イベントの発生割合）を算出する。その結果、イベントＡ（図７の例では「ＥＶ６」のイベントＩＤを持つイベント）も過去一定期間に発生していることから、展開ルール「ＥｘＲｕｌｅ１−１」についての確信度は、１００％（２／２×１００）となる。
以上のようにして算出された確信度が一定値を超過している場合、イベント解析処理モジュール３２５００は、プラン展開モジュール３２７００に対して、プラン展開処理の実行を指示し、障害回復のための展開プランの生成を行わせる。例えば、上記一定値を３０％とした場合、展開ルール「ＥｘＲｕｌｅ１−１」についての確信度は１００％であり３０％を超えているので、展開ルール「ＥｘＲｕｌｅ１−１」に対応する展開プランが生成されることになる。
＜プラン展開処理の詳細＞
図１７は、第１の実施形態に係るプラン展開処理のフローチャートである。プラン展開処理は、図１６のステップ６２０９０の処理に対応する。
まず、プラン展開モジュール３２７００は、解析結果管理表３３６００から、新規に登録された解析結果管理表３３６００のエントリ（以下「新規登録エントリ」という）を取得する（ステップ６３０１０）。プラン展開モジュール３２７００は、取得した新規登録エントリのそれぞれに対して、以下のステップ６３０３０からステップ６３０９０までの処理を実施する（ステップ６３０２０）。
プラン展開モジュール３２７００は、解析結果管理表３３６００の処理対象の新規登録エントリから、展開ルールＩＤ３３６５０に格納されている展開ルールＩＤを取得する。以下、ここで取得した展開ルールＩＤが示す展開ルールを「処理対象の展開ルール」と呼ぶ。そして、プラン展開モジュール３２７００は、処理対象の展開ルールの展開前汎用ルールＩＤ３３５４０に格納されている汎用ルールＩＤを取得する（ステップ６３０３０）。ここで取得した汎用ルールＩＤが示す汎用ルールは、処理対象の展開ルールの基となった汎用ルールである。
次に、プラン展開モジュール３２７００は、ルール・プラン対応管理表３３９００を参照し、処理対象の展開ルールの基となった汎用ルールに対応する１以上の汎用プランを特定する。また、プラン展開モジュール３２７００は、ルール・プラン対応管理表３３９００を参照し、処理対象の展開ルールの基となった汎用ルールと、特定した汎用プランとの組み合わせに対応する未解決イベントを特定する（ステップ６３０４０）。
次に、プラン展開モジュール３２７００は、ボリュームトポロジ管理表３３２００を参照し、ステップ６３０４０で特定した汎用プランに基づく、処理対象の展開ルールに対応する１以上の展開プランを生成し、生成した展開プランに関する情報を展開プラン表３３８００に追加する（ステップ６３０５０）。例えば、ボリュームマイグレーションの汎用プランを展開する場合、プラン展開モジュール３２７００は、移動先装置となり得るストレージ装置２００００の全てを、ボリュームトポロジ管理表３３２００を参照して特定する。
続いて、プラン展開モジュール３２７００は、ステップ６３０５０で生成した各展開プランに対して、ステップ６３０７０及びステップ６３０８０の処理を繰り返し実行する（ステップ６３０６０）。プラン展開モジュール３２７００は、装置性能管理表３３１００を参照し、プラン実行後の状況をシミュレートすることによってプラン実行後の性能値の予測値を算出し、シミュレートの結果情報に基づいて、処理対象の展開プランのプラン対象３３８４０の値を更新する（ステップ６３０７０）。次に、プラン展開モジュール３２７００は、プラン実行後リスク抽出モジュール３２８００に対して、プラン実行後リスク抽出処理（図１８参照）の実行を指示する（ステップ６３０８０）。この際、プラン展開モジュール３２７００は、処理対象の展開プランに関する未解決イベント、すなわち、処理対象の展開ルールの基となった汎用ルールと、処理対象の展開プランの基となった汎用プランとの組み合わせに対応する未解決イベント、の未解決イベントＩＤをプラン実行後リスク抽出モジュール３２８００に入力する。
プラン展開モジュール３２７００は、取得した新規登録エントリの全てに対してステップ６３０３０からステップ６３０９０までの処理を終えた後、プラン提示モジュール３２９００に対して、プラン提示処理（図１９参照）の実行を指示する（ステップ６３１１０）。その後、プラン展開モジュール３２７００は、プラン展開処理を終了する。
本実施形態では、性能情報、特にＩ／Ｏのレスポンスタイムの予測値を取り上げ、シミュレートを実施してＩ／Ｏのレスポンスタイムの予測値を算出し、シミュレートによって得られた予測値を展開プラン表３３８００のプラン対象３３８４０に格納している。この予測値は、例えば、展開プラン「ＥｘＰｌａｎ１−１」が実行された場合、論理ボリューム「ＬＵ２」のデータがストレージ装置「ＳＹＳ１」からストレージ装置「ＳＹＳ２」へ移動されるが、装置性能管理表３３１００から得られる現在の移動対象ボリューム（論理ボリューム「ＬＵ２」）、移動元装置（ストレージ装置「ＳＹＳ１」）、及び移動先装置（ストレージ装置「ＳＹＳ２」）のそれぞれのＩ／Ｏのレスポンスタイムに基づいて算出される。ここでは、シミュレート方法の一例を示したが、展開プラン表３３８００に格納する値としては、プランの特徴を表す指標となり得る値であれば、性能値以外でもよい。管理サーバ３００００は、例えば、プラン実行にかかるコストの情報やプラン実行に要する時間等の情報をボリュームトポロジ管理表３３２００又は装置性能管理表３３１００に格納しておく等して、性能値と同様にシミュレートを行ってもよい。
＜プラン実行後リスク抽出処理の詳細＞
図１８は、第１の実施形態に係るプラン実行後リスク抽出処理のフローチャートである。プラン実行後リスク抽出処理は、図１７のステップ６３０８０の処理に対応する。
まず、プラン実行後リスク抽出モジュール３２８００は、プラン展開モジュール３２７００から受信した未解決イベントＩＤを利用して、解析結果管理表３３６００における新規登録エントリの受信イベントＩＤ３３６６０に登録されている実際に発生した条件イベントの中から、解消できないイベントを抽出する（ステップ６４０１０）。ここで、解消できないイベントとは、実際に発生した条件イベントのうちの、未解決イベントＩＤが示す条件イベントに対応するイベントのことをいう。
次に、プラン実行後リスク抽出モジュール３２８００は、イベント管理表３３３００、及び処理対象の展開ルールを参照し、ステップ６４０１０で抽出した解消できないイベントの発生個所（発生元の装置及びデバイス）を特定する（ステップ６４０２０）。次に、プラン実行後リスク抽出モジュール３２８００は、ボリュームトポロジ管理表３３２００を参照し、解消できないイベントの発生個所、及び解消できないイベントの発生個所とＩ／Ｏパス上の関連を持つ箇所（装置及びデバイス）のうちのいずれか１以上をリスク箇所として抽出する（ステップ６４０３０）。
ステップ６４０３０においてリスク箇所が抽出された場合（ステップ６４０４０：Ｙｅｓ）、プラン実行後リスク抽出モジュール３２８００は、展開プラン表３３８００における処理対象の展開プランのリスク箇所３３８９０に、抽出したリスク箇所を示すデータを格納し（ステップ６４０４０）、プラン実行後リスク抽出処理を終了する。一方、ステップ６４０３０においてリスク箇所が抽出されなかった場合（ステップ６４０４０：Ｎｏ）、プラン実行後リスク抽出モジュール３２８００は、プラン実行後リスク抽出処理を終了する。
図１２の展開プラン表３３８００のリスク箇所３３８９０には、リスク箇所が抽出されなかったためにリスク箇所を示すデータが格納されていないが、リスク箇所としては、例えば、ボリュームトポロジ管理表３３２００のエントリが示すＩ／Ｏパス上の箇所、例えば、ホストコンピュータ１００００のドライブ、ストレージ装置２００００のコントローラ２５０００、ストレージ装置２００００の論理ボリューム２４１００等が抽出され得る。
＜プラン提示処理の詳細＞
図１９は、第１の実施形態に係るプラン提示処理のフローチャートである。プラン提示処理は、図１７のステップ６３１１０の処理に対応する。
まず、プラン提示モジュール３２９００は、解析結果管理表３３６００から、障害原因の候補を示す情報及び障害原因の候補についての確信度、すなわち、原因装置ＩＤ３３６１０、原因部位ＩＤ３３６２０、メトリック３３６３０、及び確信度３３６４０の値を取得する（ステップ６５０１０）。
次に、プラン提示モジュール３２９００は、解析結果管理表３３６００の各新規登録エントリに対して、ステップ６５０３０の処理を実施する。プラン提示モジュール３２９００は、展開プラン表３３８００から、処理対象の新規登録エントリが示す障害原因（正確には、障害原因の候補）に対する１以上の展開プラン、すなわち、処理対象の新規登録エントリが示す展開ルールに対応する１以上の展開プラン（障害回復における候補となる展開プラン）（第１のプラン）に関する情報を取得する（ステップ６５０３０）。なお、新規登録エントリが示す展開ルールとは、当該新規登録エントリの展開ルールＩＤ３３６５０に格納されている展開ルールＩＤが示す展開ルールのことである。
全ての新規登録エントリに対してステップ６５０３０の処理を終えた後、プラン提示モジュール３２９００は、解析結果管理表３３６００の各新規登録エントリに対して、ステップ６５０６０からステップ６５０８０までの処理を実施する。プラン提示モジュール３２９００は、処理対象の新規登録エントリが示す障害原因（処理対象の障害原因）に対する１以上の展開プランのそれぞれについて、ステップ６５０７０の処理を実施する。
ステップ６５０７０において、プラン提示モジュール３２９００は、プラン実行履歴管理表３３９５０が示す過去に実行された展開プランの実行結果に基づいて、処理対象の障害原因に対する処理対象の展開プランについてのスコア値を算出する。ここで、スコア値とは、展開プランを実行した場合の障害回復に成功する可能性を示す指標値、すなわち、障害が改善される見込み値のことをいう。例えば、プラン提示モジュール３２９００は、プラン実行履歴管理表３３９５０から、処理対象の新規登録エントリが示す展開ルールと処理対象の展開プランとの組み合わせに対応するエントリを全て取得する。そして、プラン提示モジュール３２９００は、取得した１以上のエントリのそれぞれの障害回復の成否を示すデータに基づいて、処理対象の障害原因に対して処理対象の展開プランを実行した場合の成功率、具体的には、取得したエントリの総数に対する、取得したエントリのうちの実行成否３３９８０に「ＯＫ」が格納されているエントリの数の割合を、スコア値として算出する。
なお、本実施形態では、成功率をそのままスコア値としているが、例えば、式１によって得られる値（ｓ）をスコア値としてもよい。式１は、プラン実行履歴管理表３３９５０内の実行結果を所定の期間ごとに分け、期間ごとに算出した成功率（Ｒｉ）をその期間に基づく重み値（１／２ｉ）で重み付けし、重み付け後の成功率（Ｒｉ／２ｉ）の総和をスコア値とする式である。式１では、より現在に近い期間の成功率により大きな重み値が付され、より直近に成功しているほど値が高くなるようにスコア値が算出される。式１において、Ｒｉは、ｉ時間前から（ｉ＋ｎ）時間前（ｎは所定値、例えば１）までの期間の成功率を示している。
ｓ=Σ（Ｒｉ／２ｉ）・・・（式１）
なお、スコア値は、成功率及び重み付け後の成功率に限られず、これら以外の値がスコア値とされてもよい。例えば、成功率に加えて展開プランの実行回数、すなわちプラン実行履歴管理表３３９５０内の実行結果の数が考慮された値がスコア値とされてもよいし、展開プランの実行回数がそのままスコア値とされてもよい。成功率に加えて展開プランの実行回数を考慮する場合の例として、例えば、成功率が同等である場合に実行回数が多いほど値が高くなるようにスコア値が決定されてもよい。また、例えば、展開プランが実行されて障害が改善されてから現在までの期間がより長く、且つその期間内に障害が再発していない場合ほど、値が高くなるようにスコア値が決定されてもよい。また、管理サーバ３００００は、複数種類のスコア値の算出方法をあらかじめ用意しておき、所定のポリシーに基づいて、実行時の状態に応じてスコア値の算出方法を切り替えるようにしてもよい。
全ての新規登録エントリに対してステップ６５０６０からステップ６５０８０までの処理を終えた後、プラン提示モジュール３２９００は、ステップ６５０７０の処理（スコア値の算出処理）の対象とされた障害原因と展開プランとの組み合わせの中から、過去に所定回数以上実行され、且つスコア値が所定値以上である障害原因と展開プランとの組み合わせを抽出する（ステップ６５１００）。この際、プラン提示モジュール３２９００は、例えば、プラン実行履歴管理表３３９５０内の実行結果の数が明らかに有意に多い障害原因と展開プランとの組み合わせを抽出してもよく、管理者の展開プランの特徴を表せる方法であれば、抽出方法は限定しない。
次に、プラン提示モジュール３２９００は、抽出した障害原因と展開プランとの組み合わせの中に、その障害原因についての確信度が１００％である組み合わせが存在するかを判定する（ステップ６５１１０）。
確信度が１００％である組み合わせが存在しない場合（ステップ６５１１０：Ｎｏ）、プラン提示モジュール３２９００は、ステップ６５０１０で取得した障害原因の候補を示す情報及び障害原因の候補についての確信度、ステップ６５０３０で取得した候補となる展開プランに関する情報、並びに、ステップ６５０７０で算出した各展開プランについてのスコア値に基づいて、プラン提示画面（図２０参照）を生成し、生成したプラン提示画面を出力デバイス３１２００に表示する（ステップ６５１２０）。例えば、プラン提示画面において、候補となる展開プランのうちの１以上の展開プラン（以下「提示プラン」という）が、スコア値が高いプランから順に並べて表示される。提示プランは、例えば、候補となる展開プランのうちのスコア値が所定値以上の展開プランである。その後、プラン提示モジュール３２９００は、プラン提示処理を終了する。
一方、確信度が１００％である組み合わせが存在する場合（ステップ６５１１０：Ｙｅｓ）、プラン提示モジュール３２９００は、確信度が１００％である組み合わせのうちのスコア値が最も高い組み合わせに含まれる展開プラン、すなわち、確信度が１００％である障害原因に対する展開プランのうちのスコア値が最も高い展開プランを特定する。そして、プラン提示モジュール３２９００は、特定した展開プランについてのプラン実行処理（図２１参照）の実行を、プラン実行モジュール３２９１０に指示する（ステップ６５１３０）。このプラン実行処理により、確信度が１００％である障害原因に対する展開プランのうちのスコア値が最も高い展開プランが自動的に実行される。その後、プラン提示モジュール３２９００は、プラン提示処理を終了する。
なお、本実施形態では、管理サーバ３００００が、確信度が１００％である障害原因が存在する場合に、その確信度が１００％である障害原因に対する、スコア値が最も高い展開プランを自動的に実行するが、この自動実行を行うか否かの判定基準は、確信度が１００％であることに限られない。例えば、管理サーバ３００００は、確信度が所定値（例えば、１００％に近い値）以上である場合に、その確信度が所定値以上である障害原因に対する、スコア値が最も高い展開プラン（第２のプラン）を自動的に実行してもよい。また、例えば、管理サーバ３００００は、確信度が所定値以上であり、且つ、その確信度が所定値以上である障害原因に対する複数の展開プランのそれぞれについてのスコア値の最大値（第２のプランについてのスコア値）が所定値以上である場合に、その最大のスコア値を持つ展開プラン（第２のプラン）を自動的に実行してもよい。また、管理サーバ３００００は、自動実行を行う前に、自動実行を行ってもよいか否かについて管理者に承認を求めてもよい。管理サーバ３００００は、自動実行を行う前又は行った後に、ステップ６５１２０の処理を行ってプラン提示画面を表示してもよい。
図２０は、第１の実施形態に係るプラン提示画面の一例の構成図である。
プラン提示画面は、計算機システムにおいて障害が発生した場合に、管理者がその原因を追究して対策を実施する際に参照する情報、具体的には、障害原因の候補と、その障害原因の候補に対して実行し得る展開プラン（候補となる展開プランのうちの１以上の展開プラン、すなわち提示プラン）のリストとの対応関係を表示するための表示領域７１０１０と、展開プランの実行を指示するためのプラン実行ボタン７１０２０とを有する。
障害原因の候補と展開プランとの対応関係を表示する表示領域７１０１０には、障害原因の候補を示す情報として、例えば、障害原因の候補に対応するイベントに関係する管理対象装置の装置ＩＤ、障害原因の候補に対応するイベントに関係する管理対象デバイスのデバイスＩＤ、障害原因の候補に対応するイベントの種別、及び、障害原因の候補についての確信度、すなわち条件イベントの総数に対する実際に発生した条件イベントの数の割合が表示される。これらの値は、例えば、プラン提示モジュール３２９００が、図１９のステップ６５０１０において、解析結果管理表３３６００から取得する。
また、表示領域７１０１０には、障害原因の候補に対する展開プラン（提示プラン）に関する情報として、展開プランの内容を示す情報、展開プランの実行にかかるコスト、展開プランの実行に要する時間、すなわち障害が残り続ける時間（ダウンタイム）、及び、リスク箇所を示す情報が表示される。これらの値は、例えば、プラン提示モジュール３２９００が、図１９のステップ６５０３０において、展開プラン表３３８００から取得する。
ここで、障害原因の候補に対する複数の展開プランは、ステップ６５０７０で算出されたスコア値が高い展開プランから順番に並べて表示される。なお、複数の展開プランを、展開プランの実行にかかるコストが少ないものから順番に並べたり、展開プランの実行に要する時間の短いものから順番に並べたり、リスク箇所が存在しないものから順番に並べたりする等、展開プランの特徴に基づいて並べ替えを行えるようにしてもよい。並べ替えの方法としては、例えば、表示領域７１０１０における「Ｃｏｓｔ（$）」をクリックすることで、コストが少ないものから順番に並べるようにする等、どのような方法が採用されてもよい。
プラン実行ボタン７１０２０は、選択された展開プランの実行を指示するためのボタンであり、当該ボタンが押下されると、管理サーバ３００００は、選択された展開プランに相当する機能を提供するプログラムに対して、展開プランの実行指示を出す。展開プランの実行指示を受けたプログラムは、選択された展開プランを実行することとなる。ここで、展開プランを実行するプログラムは、例えば、管理サーバ３００００のメモリ３２０００内のプログラムであり、例えば、ボリュームマイグレーションプログラム（図示しない）や、ＶＭ移動プログラム（図示しない）等である。
なお、表示領域７１０１０において、展開プラン表３３８００のプラン対象３３８４０に格納されている、展開プラン実行前の性能値及び展開プラン実行後の性能値の予測値をあわせて表示してもよく、性能値及び性能値の予測値がトレンド情報としてグラフ形式で表示されてもよい。
図２０は、プラン提示画面の一例であり、展開プランの実行にかかるコスト、展開プランの実行に要する時間以外の展開プランの特徴を表す情報、例えば、ステップ６５０７０で算出されたスコア値等が表示領域７１０１０にあわせて表示されてもよく、他の表示態様が採用されてもよい。
＜プラン実行処理の詳細＞
図２１は、第１の実施形態に係るプラン実行処理のフローチャートである。
プラン提示画面において、表示領域７１０１０から一つの展開プランが選択され、プラン実行ボタン７１０２０が押下されると、プラン実行モジュール３２９１０は、プラン実行処理の実行を開始する。
まず、プラン実行モジュール３２９１０は、選択された展開プランに相当する機能を提供するプログラムに対して、選択された展開プランの実行を指示する（ステップ６７０１０）。ここで、展開プランを実行するプログラムは、例えば、ボリュームマイグレーションプログラム、ＶＭ移動プログラム等であり、これらが行う処理は、引用文献等に開示されている従来技術の処理と同様である。また、プラン実行モジュール３２９１０は、これらの処理を実施する際に、実行順序制御や競合回避を行うための一般的な機構を利用して競合状態を回避してもよい。
次に、プラン実行モジュール３２９１０は、展開プラン表３３８００の展開ルールＩＤ３３８２３を参照して、選択された展開プランに対応する展開ルールを特定する（ステップ６７０２０）。そして、プラン実行モジュール３２９１０は、特定した展開ルールの条件イベントの中から、選択された展開プランに関する未解決イベントに対応しない条件イベントを抽出する（ステップ６７０３０）。ここで、プラン実行モジュール３２９１０は、ルール・プラン対応管理表３３９００を参照して、特定した展開ルールの基となった汎用ルールと、選択された展開プランの基となった汎用プランとの組み合わせに対応する未解決イベントを、選択された展開プランに関する未解決イベントとして特定する。
プラン実行モジュール３２９１０は、抽出した各条件イベントに対して、ステップ６７０５０及び６７０６０の処理を実施する。まず、プラン実行モジュール３２９１０は、プラン実行結果確認モジュール３２９２０に対して、障害が改善されたか否かの確認処理の実施を指示する。確認処理の実施の指示を受けたプラン実行結果確認モジュール３２９２０は、処理対象の条件イベントの発生元の管理対象装置に対して、処理対象の条件イベントに対応する障害が改善されたか否か、すなわち処理対象の条件イベントが発生していない状態となったか否かを問い合わせる（ステップ６７０５０）。
処理対象の条件イベントが発生していない状態となっている場合（ステップ６７０６０：Ｙｅｓ）、プラン実行結果確認モジュール３２９２０は、未だ確認処理の対象とされていない条件イベントについて確認処理を実施する。ステップ６７０３０で抽出された条件イベントの全てが発生していない状態となっている場合、プラン実行モジュール３２９１０は、選択された展開プランが実行されたこと及び実行結果が成功であることを示すエントリをプラン実行履歴管理表３３９５０に登録する（ステップ６７０８０）。ここで登録されるエントリの展開ルールＩＤ３３９６０には、ステップ６７０２０で特定された展開ルールの展開ルールＩＤが格納され、展開プランＩＤ３３９７０には、選択された展開プランの展開プランＩＤが格納され、実行成否３３９８０には、「ＯＫ」が格納され、実施日時３３９９０には、例えば現在の日時を示すデータが格納される。その後、プラン実行モジュール３２９１０は、プラン実行処理を終了する。
少なくとも１つの条件イベントが発生したままの状態となっている場合（ステップ６７０６０：Ｎｏ）、プラン実行モジュール３２９１０は、選択された展開プランが実行されたこと及び実行結果が失敗であることを示すエントリをプラン実行履歴管理表３３９５０に登録する（ステップ６７０９０）。ここで登録されるエントリの展開ルールＩＤ３３９６０には、ステップ６７０２０で特定された展開ルールの展開ルールＩＤが格納され、展開プランＩＤ３３９７０には、選択された展開プランの展開プランＩＤが格納され、実行成否３３９８０には、「ＮＧ」が格納され、実施日時３３９９０には、例えば現在の日時を示すデータが格納される。その後、プラン実行モジュール３２９１０は、プラン実行処理を終了する。
なお、本実施形態では、管理サーバ３００００は、展開プランに対応する展開ルールに含まれる条件イベントのうちの、展開プランの実行によって解決すると見込まれたイベント（未解決イベントに対応しないイベント）の全てが解決された場合に成功と判定しているが、展開プランの実行結果の判定方法はこの限りではなく、管理サーバ３００００は、例えば、展開プランの実行によりサービスレベルがどの程度改善したか（所定のサービスレベルが満たされたかどうか）や、解決すると見込まれたイベントの総数に対する実際に解決したイベントの数の割合が一定値以上に達したかどうかによって成功か失敗かを判定してもよい。また、障害が改善されたか否かの確認処理において、非特許文献１において述べられている障害が回復しているかどうかを検査する手段が利用されてもよい。
第１の実施形態によれば、管理サーバ３００００は、展開プランの実行後にその実行による障害回復の成否を示すデータを履歴として蓄積しておく。そして、管理サーバ３００００は、障害発生時に障害原因とその障害原因に対する展開プランとを導出し、導出した展開プランの過去の実行成否状況に応じて展開プランをスコア付けする。管理サーバ３００００は、障害原因についての確信度とスコア値とに応じて、自動的な対処が可能かどうかを判断し、可能な場合はスコア値の最も高い展開プランを自動的に実行することで障害回復を行うことができる。なお、管理サーバ３００００は、展開プランを自動的に実行する前に管理者からの承認を得てもよい。また、自動的な対処が不可能な場合は、管理サーバ３００００は、障害原因に対する複数の展開プランを示すデータを、スコア値が高い展開プランから順に並べて表示して管理者に提示する。これにより、管理者は、障害回復に成功する可能性の高い展開プランを容易に知ることができ、障害回復に成功する可能性の高い展開プランを、実行する展開ルールとして迅速に選択できるようになり、障害回復のための運用管理コストを削減できる。
例えば、或るホストコンピュータ１００００上で動作しているアプリケーションサーバの実行パフォーマンスが低下している場合において、管理者が、そのアプリケーションサーバの実行パフォーマンスの低下という障害に対して実施する展開プランを選択する場合を想定する。例えば、障害に対して過去にどのような展開プランが実施されたかを記録しておき、展開プランを選択する際にその記録した情報を利用するという技術（特許文献４に開示された技術）を採用した場合において、過去に（１）アプリケーションサーバのプロセスの再起動と（２）ホストコンピュータ１００００の再起動とが展開プランとして実施されている場合、管理サーバ３００００は、過去に実施された展開プラン、すなわち（１）の展開プランと（２）の展開プランとを同等に管理者に推薦する。例えば、ホストコンピュータ１００００上で多くの他のプロセスが起動されていることが障害原因であった場合は（１）の展開プランが実施されても障害を解決できない可能性があるが、この場合でも、管理サーバ３００００は、（１）の展開プランと（２）の展開プランとを同等に管理者に推薦する。これに対し、本実施形態では、管理サーバ３００００は、過去に実施された展開プランのその実施による障害回復の成否に基づいてスコア値を算出し、候補となる複数の展開プランを示すデータを、スコア値が高い展開プランから順に並べて表示して管理者に提示する。従って、例えば、（１）の展開プランの過去の実施において障害回復に失敗しており、（２）の展開プランの過去の実施において障害回復に成功している場合は、（２）の展開プランについてのスコア値は（１）の展開プランについてのスコア値よりも高くなるため、管理サーバ３００００は、（２）の展開プランを（１）の展開プランよりも上位に表示して（２）の展開プランを（１）の展開プランよりも優先的に管理者に提示する。従って、管理者は、過去に障害回復に成功しており、障害回復に成功する可能性が高いと考えられる展開プランである（２）の展開プランを容易に知ることができ、実行する展開ルールとして（２）の展開プランを迅速に選択できる。
（２）第２の実施形態
次に、第２の実施形態について説明する。以下の説明では、第１の実施形態との差異を中心に説明し、同等の構成要素や、同等の機能を持つプログラム、同等の項目を持つ表については、記載を省略する。
第１の実施形態では、管理サーバ３００００は、障害原因に対する展開プランとして複数の展開プランが存在する際に、過去の実行履歴を参照して算出したスコア値に基づいて、管理サーバ３００００又は管理者が適切な展開プランを迅速に選択できるように支援している。しかしながら、展開プランの過去の実行回数が少なくプラン実行履歴管理表３３９５０内に蓄えられている過去の実行結果の数が少ない場合、スコア値の妥当性を担保するための履歴データが十分であるとはいえず、このような場合にスコア値に基づいて展開プランが選択されたとしても選択された展開プランが最適かどうかは不明である。また、スコア値が低い展開プランについては、選択される可能性が低いため、スコア値が低い展開プランについて履歴データが増える可能性は低い。例えば、候補となる展開プランとして２つの展開プラン（展開プランＡ及び展開プランＢ）があり、いずれも過去に１回だけ実行されている場合において、展開プランＡが障害回復に成功し展開プランＢが障害回復に失敗している場合、展開プランＡについてのスコア値は、展開プランＢについてのスコア値よりも高くなるため、展開プランＡが選択される可能性が高い。しかし、展開プランＡ及び展開プランＢの過去の実行回数は１回にすぎず、展開プランＡがたまたま障害回復に成功し展開プランＢがたまたま障害回復に失敗していた可能性も考えられるため、必ずしも展開プランＡが最適であるとは言えない。そして、選択される可能性の低い展開プランＢについては、履歴データが増える可能性が低くその後にスコア値が高くなる可能性は低いため、結果として、それ以降は常に展開プランＡが優先的に選択されることとなってしまう。
第２の実施形態では、管理サーバ３００００が、実行回数の少ない展開プランに関するテストケースを抽出し、管理サーバ３００００又は管理者が、抽出したテストケースに基づいて、実行回数の少ない展開プランについてテスト環境で例えば運用開始前にテストを実行し、その展開プランについての履歴データを生成する。
図２２は、第２の実施形態に係る管理サーバの一例の構成図である。
管理サーバ３００００のメモリ３２０００は、さらにテストケース抽出モジュール３２９５０のコンピュータプログラムを記憶する。また、管理サーバ３００００の二次記憶デバイス３３０００は、さらにテストケースリポジトリ３４１００を記憶する。
図２３は、第２の実施形態に係るテストケースリポジトリの一例の構図である。
テストケースリポジトリ３４１００は、障害イベント情報３４１１０、展開ルールＩＤ３４１２０、及び展開プランＩＤ３４１３０のフィールドを含む。障害イベント情報３４１１０には、展開ルールＩＤ３４１２０の展開ルールＩＤが示す展開ルールに含まれるイベント（条件イベント及び原因イベント）に関する情報が格納される。展開ルールＩＤ３４１２０には、テスト対象の障害原因に対応するイベントを原因イベントとする展開ルールの展開ルールＩＤが格納される。展開プランＩＤ３４１３０には、テスト対象の展開プランの展開プランＩＤが格納される。
図２４は、第２の実施形態に係るテストケース抽出処理のフローチャートである。
まず、テストケース抽出モジュール３２９５０は、展開ルールリポジトリ３３５００に含まれる全ての展開ルールについて、ステップ６８０２０の処理を実施する。ステップ６８０２０において、テストケース抽出モジュール３２９５０は、処理対象の展開ルールに含まれるイベント（条件イベント及び原因イベント）を抽出する。
テストケース抽出モジュール３２９５０は、ステップ６８０２０で抽出した各イベントに対して、ステップ６８０４０からステップ６８０９０までの処理を実施する。
まず、テストケース抽出モジュール３２９５０は、展開ルールリポジトリ３３５００から処理対象のイベントを含む展開ルールを抽出する（ステップ６８０５０）。そして、テストケース抽出モジュール３２９５０は、図１７のステップ６３０３０から６３０９０までの処理を実施することによって、抽出した展開ルールに対応する展開プラン、すなわち、抽出した展開ルールの原因イベントが障害原因である場合のその障害原因に対する展開プランを生成する（ステップ６８０６０）。
その後、テストケース抽出モジュール３２９５０は、プラン実行履歴管理表３３９５０から、ステップ６８０５０で抽出した展開ルールと、ステップ６８０６０で生成した展開プランとの組み合わせに対応するエントリを全て取得する。そして、テストケース抽出モジュール３２９５０は、取得したエントリの数が一定数以上であるか否かを判定する（ステップ６８０７０）。
取得したエントリの数が一定数以上でない場合（ステップ６８０７０：Ｎｏ）、テストケース抽出モジュール３２９５０は、ステップ６８０５０で抽出した展開ルールと、ステップ６８０６０で生成した展開プランとの組み合わせによって示されるテストケースに関する、テストケースリポジトリ３４１００のエントリを生成し、生成したエントリをテストケースリポジトリ３４１００に追加する。このエントリの障害イベント情報３４１１０には、ステップ６８０５０で抽出された展開ルールの１以上の条件イベント及び原因イベントのそれぞれに関する情報が格納される。このエントリの展開ルールＩＤ３４１２０には、ステップ６８０５０で抽出された展開ルールの展開ルールＩＤが格納される。このエントリの展開プランＩＤ３４１３０には、ステップ６８０６０で生成された展開プランの展開プランＩＤが格納される。
ステップ６８０２０で抽出した各イベントに対して、ステップ６８０４０からステップ６８０９０までの処理を終えた後、テストケース抽出モジュール３２９５０は、テストケース抽出処理を終了する。
本実施形態に係る管理サーバ３００００又は管理者は、例えば運用開始前に、テストケースリポジトリ３４１００に登録されているテストケースのそれぞれについて、当該テストケースに対応するテストを実施する。そして、管理サーバ３００００又は管理者は、テスト結果、すなわち展開プランの実行結果をプラン実行履歴管理表３３９５０に登録する。例えば、展開ルール「ＥｘＲｕｌｅ１−１」と展開プラン「ＥｘＰｌａｎ１−１」との組み合わせによって示されるテストケースがテストケースリポジトリ３４１００に登録されている場合、管理サーバ３００００又は管理者は、例えば、展開ルール「ＥｘＲｕｌｅ１−１」の条件イベント又は原因イベントを擬似的に発生させる等して疑似的に障害状況（展開ルール「ＥｘＲｕｌｅ１−１」の原因イベントを障害原因とする障害状況）を作り、その状況下で展開プラン「ＥｘＰｌａｎ１−１」を実行する。そして、管理サーバ３００００又は管理者は、その実行結果、すなわち、展開プラン「ＥｘＰｌａｎ１−１」の実行によって、展開ルール「ＥｘＲｕｌｅ１−１」の原因イベントを障害原因とする障害の回復に成功したか否かを示すデータをプラン実行履歴管理表３３９５０に登録する。本実施形態では、テストによって得られた展開プランの実行結果も、スコア値の算出の際に利用される。
第２の実施形態によれば、管理サーバ３００００は、履歴データが十分でない展開ルールと展開プランとの組み合わせをテストケースとして、テストケースリポジトリ３４１００に追加する。そして、管理サーバ３００００又は管理者は、例えば管理サーバ３００００の導入時に、テストケースリポジトリ３４１００に登録されているテストケースに対応するテストを実施し、テスト結果をプラン実行履歴管理表３３９５０に登録する。これにより、全ての展開プランについて十分な履歴データが確保され、展開プラン間の実施履歴の偏りを防止することができる。また、スコア値が、十分な履歴データに基づいて算出され、その妥当性が担保されるので、管理サーバ３００００又は管理者は、スコア値に基づいてより適切な展開プランを選択できるようになる。
（３）第３の実施形態
次に、第３の実施形態について説明する。以下の説明では、第１の実施形態との差異を中心に説明し、同等の構成要素や、同等の機能を持つプログラム、同等の項目を持つ表については、記載を省略する。
第２の実施形態で述べたように、履歴データが不足している場合、スコア値に基づいて最適な展開プランが選択されるかどうかは不明であり、また、スコア値が低い展開プランについては、履歴データが増える可能性が低いため、最初にスコア値が高く算出された展開プランがそれ以降常に選択されてしまう可能性がある。第３の実施形態では、計算機システムが複数のサブシステム（管理サーバ３００００の管理単位であり、以下「ドメイン」という）から構成されており、ドメインごとに管理サーバ３００００が設けられている場合を想定する。他のドメインに存在する他の管理対象装置群において発生した同様の障害に対して、他のドメインの管理者が別の展開プランを実施することが多いのであれば、その展開プランがより適切であるということも考えられる。そこで、本実施形態では、複数のドメインのそれぞれの管理サーバ３００００間で通信を行い、同様の障害に対する展開プランの履歴が一定数以上存在する場合に、そのことをも加味してスコア値が算出される。
図２５は、第３の実施形態に係る計算機システムの一例の構成図である。
第３の実施形態に係る計算機システムは、複数のドメインのそれぞれを管理する複数の管理サーバ３００００と、複数の管理サーバ３００００のそれぞれの表示用計算機である複数のＷＥＢブラウザ起動サーバ３５０００とを有する。複数の管理サーバ３００００は、それぞれ異なる管理者によって利用されている。
図２６は、第３の実施形態に係る管理サーバの一例の構成図である。
管理サーバ３００００のメモリ３２０００は、さらに履歴送受信モジュール３２９５０のコンピュータプログラムを記憶する。また、管理サーバ３００００の二次記憶デバイス３３０００は、さらに管理サーバ一覧表３４２００を記憶する。
図２７は、第３の実施形態に係るプラン実行履歴管理表３３９５０の一例の構成図である。
第３の実施形態に係るプラン実行履歴管理表３３９５０は、第１の実施形態に係るプラン実行履歴管理表３３９５０の各フィールドに加えて、さらに、他のドメインの管理サーバ３００００から受信した履歴データであるか否かを示すデータを格納するためのフィールドである外部受信３３９９５と、他のドメインの管理サーバ３００００から受信した履歴データについてその履歴データの送信元の管理サーバ３００００を示すデータを格納するためのフィールドである送信元サーバ３３９９７とを含む。例えば、エントリが示す履歴データが他のドメインの管理サーバ３００００から受信した履歴データ、すなわち、他のドメインにおいて展開プランが実行されて得られた履歴データである場合、外部受信３３９９５には「Ｙｅｓ」が格納される。また、エントリが示す履歴データが他のドメインの管理サーバ３００００から受信した履歴データでない場合、すなわち、当該プラン実行履歴管理表３３９５０を有する管理サーバ３０００が管理するドメイン（自ドメイン）において展開プランが実行されて得られた履歴データである場合、外部受信３３９９５にはＮＵＬＬが格納される。
図２８は、第３の実施形態に係る管理サーバ一覧表の一例の構成図である。
管理サーバ一覧表３４２００は、計算機システム内の複数の管理サーバ３００００のそれぞれを示すデータ（以下「サーバＩＤ」という）を格納するためのフィールドであるサーバＩＤ３４２１０と、計算機システム内の複数の管理サーバ３００００のそれぞれに割り当てられているＩＰアドレスを格納するためのフィールドであるＩＰアドレス３４２００とを含む。
図２９は、第３の実施形態に係るプラン実行履歴交換処理のフローチャートである。
図２９において、ステップ６９０１０から６９０６０までの処理が、送信側の管理サーバ３００００の履歴送受信モジュール３２９５０（以下「送信側モジュール」という）の処理に対応し、ステップ６９０７０から６９０７５までの処理が、受信側の管理サーバ３００００の履歴送受信モジュール３２９５０（以下「受信側モジュール」という）の処理に対応している。
送信側モジュールは、定期的又は不定期的に、送信側の管理サーバ３００００のプラン実行履歴管理表３３９５０から外部受信フィールド３３９９５が「Ｙｅｓ」ではない１以上のエントリを抽出する（ステップ６９０１０）。そして、送信側モジュールは、抽出した１以上のエントリを１以上のエントリ群に分類する（ステップ６９０２０）。ここで、エントリ群とは、展開ルールＩＤ３３９６０と展開プランＩＤ３３９７０との値の組み合わせが一致する１以上のエントリのことをいう。
送信側モジュールは、１以上のエントリ群のそれぞれに対して、ステップ６９０３０から６９０６０までの処理を実施する。
ステップ６９０４０において、送信側モジュールは、処理対象のエントリ群に含まれるエントリの数が一定数以上であるか否かを判定する。処理対象のエントリ群に含まれるエントリの数が一定数以上である場合（ステップ６９０４０：Ｙｅｓ）、送信側モジュールは、処理対象のエントリ群の各エントリが示すデータ（履歴データ）を全て含むデータ（以下「外部履歴データ」という）を、管理サーバ一覧表３４２１０に登録されている他の全ての管理サーバ３００００に対して送信する（ステップ６９０５０）。
１以上のエントリ群のそれぞれに対して、ステップ６９０３０から６９０６０までの処理を終えた後、送信側モジュールは、プラン実行履歴交換処理を終了する。
外部履歴データを受信した各管理サーバ３００００の受信側モジュールは、外部履歴データに含まれる履歴データを示す各エントリに対して、ステップ６９０７１からステップ６９０７５までの処理を実施する。
まず、受信側モジュールは、処理対象のエントリと、展開ルールＩＤ３３９６０と展開プランＩＤ３３９７０との値の組み合わせが一致する１以上のエントリを、受信側の管理サーバ３００００のプラン実行履歴管理表３３９５０（以下「受信側履歴管理表」という）から抽出する（ステップ６９０７２）。
次に、受信側モジュールは、抽出した１以上のエントリの中に、送信元サーバＩＤ３３９９７と実施日時３３９９０との値の組み合わせが処理対象のエントリと一致するエントリが含まれるか否かを判定する（ステップ６９０７３）。一致するエントリが含まれなかった場合（ステップ６９０７３：Ｎｏ）、受信側モジュールは、処理対象のエントリを受信側履歴管理表に登録する（ステップ６９０７４）。この際、登録されるエントリの外部受信３３９９５には、「Ｙｅｓ」が格納され、登録されるエントリの送信元サーバ３３９９７には、管理サーバ一覧表３４２００で管理されている送信側の管理サーバ３００００のサーバＩＤが格納される。一方、一致するエントリが含まれる場合（ステップ６９０７３：Ｙｅｓ）、受信側モジュールは、処理対象のエントリの受信側履歴管理表への登録は行わない。
外部履歴データに含まれる履歴データを示す各エントリに対してステップ６９０７１からステップ６９０７５までの処理を終えた後、受信側モジュールは、プラン実行履歴交換処理を終了する。
本実施形態に係る管理サーバ３００００は、図１９のステップ６５０７０においてスコア値を算出する際、自ドメインにおいて得られた履歴データに加えて、プラン実行履歴交換処理によってプラン実行履歴管理表３３９５０に登録された履歴データ、すなわち他のドメインの管理サーバ３００００から受信した履歴データをも利用してスコア値を算出する。なお、管理サーバ３００００は、他のドメインの管理サーバ３００００から受信した履歴データを、自ドメインにおいて得られた履歴データと同様に扱ってスコア値を算出してもよいし、他のドメインの管理サーバ３００００から受信した履歴データと自ドメインにおいて得られた履歴データとを区別してスコア値を算出してもよい。また、管理サーバ３００００は、複数の他のドメインの管理サーバ３００００のうちの特定の管理サーバ３００００、例えば、運用形態が異なるドメインの管理サーバ３００００から受信した履歴データについては、スコア値の算出に利用しないようにしてもよい。
図３０は、第３の実施形態に係るプラン提示画面の一例の構成図である。
第３の実施形態に係るプラン提示画面は、第１の実施形態に係るプラン提示画面（図２０）の表示領域７１０１０に、さらに、展開プランごとにその展開プランについての実行履歴に関するデータが表示される。実行履歴に関するデータには、例えば、自ドメインにおいて得られた実行履歴と他のドメインの管理サーバ３００００から受信した実行履歴とを含めた実行履歴の総数、実行履歴の総数のうちの他のドメインの管理サーバ３００００から受信した実行履歴の数、及び、実行履歴を送信した他のドメインの管理サーバ３００００の数が含まれる。例えば、１番目の展開プラン（「＃」が「１」の展開プラン）についての実行履歴に関するデータから、この展開プランが全部で１００回実行されており、そのうちの２０回が他の３つのドメインにおいて実行されていることが分かる。なお、実行履歴に関するデータには、例えば、提示されている展開プランが具体的にどのドメインの管理サーバ３００００で実行されたかを示す情報が含まれてもよい。図３０は、プラン提示画面の一例であり、実行履歴の内訳がどの程度であるかを管理者が理解できる画面であれば、表示形態は図３０が示す形態に限られない。
第３の実施形態によれば、管理サーバ３００００は、自ドメインにおいて得られた履歴データに加えて、他のドメインの管理サーバ３００００から受信した履歴データをも利用して展開プランをスコア付けする。管理サーバ３００００は、障害原因についての確信度とスコア値とに応じて、自動的な対処が可能かどうかを判断し、可能な場合はスコア値の最も高い展開プランを自動的に実行することで障害回復を行うことができる。なお、管理サーバ３００００は、展開プランを自動的に実行する前に管理者からの承認を得てもよい。また、自動的な対処が不可能な場合は、管理サーバ３００００は、障害原因に対する複数の展開プランを示すデータを、スコア値が高い展開プランから順に並べて表示して管理者に提示する。これにより、管理サーバ３００００又は管理者は、自ドメインにおいて得られた履歴データだけではなく他のドメインで得られた履歴データをも利用して算出されたスコア値に基づき、過去の実績に応じて適切な展開プランを迅速に選択できるようになり、障害回復のための運用管理コストを削減できる。
なお、本発明は、以上説明した実施形態に限定されるものでなく、その趣旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
１００００：ホストコンピュータ
２００００：ストレージ装置
３００００：管理サーバ
３５０００：ＷＥＢブラウザ起動サーバ
４００００：ＩＰスイッチ
４５０００：通信ネットワーク

Claims (15)

  1. 複数の管理対象デバイスを有する計算機システムの管理を行う管理システムを構成するコンピュータに、
    前記複数の管理対象デバイスのいずれかに関する原因イベントと、前記原因イベントが原因となることの条件となる、前記複数の管理対象デバイスのいずれかに関する１以上の条件イベントとの対応関係を示す１以上のルールに基づいて、前記複数の管理対象デバイスのいずれかで発生したイベントの原因解析を行わせ、前記発生したイベントの原因の候補となる第１の原因イベントを特定し、
    前記ルールと、前記ルールの原因イベントが原因である場合に実施し得る回復策であるプランとの対応関係を示すプラン情報に基づいて、前記第１の原因イベントが原因である場合に実施し得る複数の第１のプランを特定し、
    前記プランが実施されるごとに、当該プランの実施による障害回復の成否を示すプラン履歴情報に基づいて、前記複数の第１のプランのそれぞれについて、当該プランを実施した場合の障害回復に成功する可能性を示す指標値を計算し、
    前記指標値に基づいて決定した表示形態に従って、前記複数の第１のプランのうちのいずれか１以上のプランを示すデータを表示する
    ことを実行させる管理プログラム。
  2. 前記複数の第１のプランの中から、前記指標値が所定値以上の１以上のプランを抽出させ、当該抽出した１以上のプランを示すデータを表示する
    ことを前記コンピュータに実行させる請求項１に記載の管理プログラム。
  3. 前記抽出した１以上のプランを前記指標値が高いプランから順に並べて表示する
    ことを前記コンピュータに実行させる請求項２に記載の管理プログラム。
  4. 前記発生したイベントの原因解析において、１以上のルールのそれぞれの原因イベントについて、当該原因イベントが原因であることの確からしさを示す確信度を計算し、前記確信度に基づいて前記第１の原因イベントを特定し、
    前記第１の原因イベントについての前記確信度が所定値以上である場合に、前記複数の第１のプランのうちの前記指標値が最も高い第２のプランを実施する
    ことを前記コンピュータに実行させる請求項３に記載の管理プログラム。
  5. 前記第１の原因イベントについての前記確信度が所定値以上であり、且つ、前記第２のプランについての前記指標値が所定値以上である場合に、前記第２のプランを実施する
    ことを前記コンピュータに実行させる請求項４に記載の管理プログラム。
  6. 前記複数の第１のプランのうちの一のプランが実施された後、前記一のプランの実施による障害回復の成否を示すデータを前記プラン履歴情報に追加する
    ことを前記コンピュータに実行させる請求項５に記載の管理プログラム。
  7. 前記プラン履歴情報は、過去に原因の候補と特定された原因イベントを含むルールと、当該ルールの原因イベントが原因の候補と特定された際に実施されたプランと、当該プランの実施による障害回復の成否とを対応付けて示す履歴要素を複数含み、
    前記コンピュータに、
    前記プラン情報、及び前記プラン履歴情報に基づいて、１以上のルールのうちの一のルールと当該ルールに対応する一のプランとの組み合わせごとに、当該組み合わせに関する履歴要素が、前記プラン履歴情報に所定数以上含まれているか否かを判定し、
    履歴要素が所定数以上含まれていない組み合わせについて、当該組み合わせを構成するルールの原因イベントを原因とする障害状況下において、当該組み合わせを構成するプランを実施するテストを行ない、当該テストの結果に基づく当該組み合わせに関する履歴要素を生成し、生成した履歴要素を前記プラン履歴情報に追加する
    ことを実行させる請求項６に記載の管理プログラム。
  8. 前記プラン履歴情報は、過去に原因の候補と特定された原因イベントを含むルールと、当該ルールの原因イベントが原因の候補と特定された際に実施されたプランと、当該プランの実施による障害回復の成否とを対応付けて示す履歴要素を複数含み、
    前記コンピュータに、
    前記プラン履歴情報に含まれる第１の履歴要素が示すルールと前記第１の履歴要素が示すプランとの組み合わせに関する履歴要素が、前記プラン履歴情報に所定数以上含まれている場合、当該組み合わせに関する履歴要素を含むデータを、前記計算機システムとは異なる計算機システムを管理する管理システムへ送信し、
    前記計算機システムとは異なる計算機システムを管理する管理システムから履歴要素を含むデータを受信した場合、前記受信したデータに含まれる履歴要素を前記プラン履歴情報に追加する、
    ことを実行させる請求項７に記載の管理プログラム。
  9. 前記ルールには、前記原因イベント及び前記条件イベントに関係する管理対象デバイスを当該管理対象デバイスの種別で表した汎用ルールと、前記原因イベント及び前記条件イベントに関係する管理対象デバイスの種別を特定の管理対象デバイスを示すデータで表した展開ルールとがあり、
    前記プランには、前記計算機システムの実構成に依存しない形式の回復策である汎用プランと、前記汎用プランを前記計算機システムの実構成を考慮して展開した回復策である展開プランとがあり、
    前記プラン情報は、前記汎用ルールと、前記汎用ルールの原因イベントが原因である場合に実施し得る汎用プランとの対応関係を示し、
    前記プラン履歴情報は、前記展開プランが実施されるごとに、当該展開プランの実施による障害回復の成否を示し、過去に原因の候補と特定された原因イベントを含む展開ルールと、当該展開ルールの原因イベントが原因の候補と特定された際に実施された展開プランと、当該展開プランの実施による障害回復の成否とを対応付けて示す履歴要素を複数含み、
    前記コンピュータに、
    前記複数の管理対象デバイス間の接続関係を示す接続情報、及び前記汎用ルールに基づいて、前記展開ルールを複数生成し、
    前記発生したイベントの原因解析において、前記生成した複数の展開ルールのそれぞれの原因イベントについて計算した前記確信度に基づいて、前記第１の原因イベントを特定し、
    前記プラン情報に基づいて、前記第１の原因イベントを含む展開ルールの基となる汎用ルールに対応する汎用プランを特定し、当該特定した汎用プランを展開することにより生成した複数の展開プランのそれぞれを前記第１のプランとして特定する
    ことを実行させる請求項８に記載の管理プログラム。
  10. 複数の管理対象デバイスを有する計算機システムの管理を行う管理システムであって、
    記憶デバイスと、
    前記記憶デバイスに接続された制御デバイスと
    を有し、
    前記記憶デバイスは、
    前記複数の管理対象デバイスのいずれかに関する原因イベントと、前記原因イベントが原因となることの条件となる、前記複数の管理対象デバイスのいずれかに関する１以上の条件イベントとの対応関係を示す１以上のルールと、
    前記ルールと、前記ルールの原因イベントが原因である場合に実施し得る回復策であるプランとの対応関係を示すプラン情報と、
    前記プランが実施されるごとに、当該プランの実施による障害回復の成否を示すプラン履歴情報と
    を記憶し、
    前記制御デバイスは、
    前記１以上のルールに基づいて、前記複数の管理対象デバイスのいずれかで発生したイベントの原因解析を行い、前記発生したイベントの原因の候補となる第１の原因イベントを特定し、
    前記プラン情報に基づいて、前記第１の原因イベントが原因である場合に実施し得る複数の第１のプランを特定し、
    前記プラン履歴情報に基づいて、前記複数の第１のプランのそれぞれについて、当該プランを実施した場合の障害回復に成功する可能性を示す指標値を計算し、
    前記指標値に基づいて決定した表示形態に従って、前記複数の第１のプランのうちのいずれか１以上のプランを示すデータを表示する
    管理システム。
  11. 前記制御デバイスは、前記複数の第１のプランのうちのいずれか１以上のプランを前記指標値が高いプランから順に並べて表示する
    請求項１０に記載の管理システム。
  12. 前記制御デバイスは、
    前記発生したイベントの原因解析において、１以上のルールのそれぞれの原因イベントについて、当該原因イベントが原因であることの確からしさを示す確信度を計算し、前記確信度に基づいて前記第１の原因イベントを特定し、
    前記第１の原因イベントについての前記確信度が所定値以上である場合に、前記複数の第１のプランのうちの前記指標値が最も高いプランを実施する
    請求項１０に記載の管理システム。
  13. 前記プラン履歴情報は、過去に原因の候補と特定された原因イベントを含むルールと、当該ルールの原因イベントが原因の候補と特定された際に実施されたプランと、当該プランの実施による障害回復の成否とを対応付けて示す履歴要素を複数含み、
    前記制御デバイスは、
    前記プラン情報、及び前記プラン履歴情報に基づいて、１以上のルールのうちの一のルールと当該ルールに対応する一のプランとの組み合わせごとに、当該組み合わせに関する履歴要素が、前記プラン履歴情報に所定数以上含まれているか否かを判定し、
    履歴要素が所定数以上含まれていない組み合わせについて、当該組み合わせを構成するルールの原因イベントを原因とする障害状況下において、当該組み合わせを構成するプランを実施するテストを行い、当該テストの結果に基づく当該組み合わせに関する履歴要素を生成し、生成した履歴要素を前記プラン履歴情報に追加する
    請求項１０に記載の管理システム。
  14. 前記プラン履歴情報は、過去に原因の候補と特定された原因イベントを含むルールと、当該ルールの原因イベントが原因の候補と特定された際に実施されたプランと、当該プランの実施による障害回復の成否とを対応付けて示す履歴要素を複数含み、
    前記制御デバイスは、
    前記プラン履歴情報に含まれる第１の履歴要素が示すルールと前記第１の履歴要素が示すプランとの組み合わせに関する履歴要素が、前記プラン履歴情報に所定数以上含まれている場合、当該組み合わせに関する履歴要素を含むデータを、前記計算機システムとは異なる計算機システムを管理する管理システムへ送信し、
    前記計算機システムとは異なる計算機システムを管理する管理システムから履歴要素を含むデータを受信した場合、当該受信したデータに含まれる履歴要素を前記プラン履歴情報に追加する
    請求項１０に記載の管理システム。
  15. 前記ルールは、前記原因イベント及び前記条件イベントに関係する管理対象デバイスを当該管理対象デバイスの種別で表した汎用ルールであり、
    前記プラン情報は、前記汎用ルールと、前記汎用ルールの原因イベントが原因である場合に実施し得る回復策であって前記計算機システムの実構成に依存しない形式の回復策である汎用プランとの対応関係を示し、
    前記プラン履歴情報は、前記汎用プランを前記計算機システムの実構成を考慮して展開した回復策である展開プランが実施されるごとに、当該展開プランの実施による障害回復の成否を示し、
    前記記憶デバイスは、前記複数の管理対象デバイス間の接続関係を示す接続情報をさらに記憶し、
    前記制御デバイスは、
    前記接続情報及び前記汎用ルールに基づいて、前記原因イベント及び前記条件イベントに関係する管理対象デバイスの種別を特定の管理対象デバイスを示すデータで表した複数の展開ルールを生成し、
    前記発生したイベントの原因解析において、１以上の汎用ルールに基づいて生成した複数の展開ルールに基づいて、前記第１の原因イベントを特定し、
    前記プラン情報に基づいて、前記第１の原因イベントを含む展開ルールの基となる汎用ルールに対応する汎用プランを特定し、当該特定した汎用プランを展開することにより生成した複数の展開プランのそれぞれを前記第１のプランとして特定する
    請求項１０に記載の管理システム。
JP2015509840A 2013-04-05 2013-04-05 管理システム及び管理プログラム Active JP6114818B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/060506 WO2014162595A1 (ja) 2013-04-05 2013-04-05 管理システム及び管理プログラム

Publications (2)

Publication Number Publication Date
JPWO2014162595A1 true JPWO2014162595A1 (ja) 2017-02-16
JP6114818B2 JP6114818B2 (ja) 2017-04-12

Family

ID=51657921

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015509840A Active JP6114818B2 (ja) 2013-04-05 2013-04-05 管理システム及び管理プログラム

Country Status (6)

Country Link
US (1) US9619314B2 (ja)
EP (1) EP2887222B1 (ja)
JP (1) JP6114818B2 (ja)
CN (1) CN104583968B (ja)
IN (1) IN2015DN01974A (ja)
WO (1) WO2014162595A1 (ja)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10346862B2 (en) 2013-10-08 2019-07-09 Accenture Global Solutions Limited Migration system to migrate users to target services
US9516119B2 (en) * 2013-10-08 2016-12-06 Accenture Global Services Limited Service provider network migration
US9703624B2 (en) * 2015-10-12 2017-07-11 Bank Of America Corporation Event correlation and calculation engine
US10235227B2 (en) 2015-10-12 2019-03-19 Bank Of America Corporation Detection, remediation and inference rule development for multi-layer information technology (“IT”) structures
US9578063B1 (en) * 2015-11-20 2017-02-21 International Business Machines Corporation Application self-service for assured log management in cloud environments
CN105867289A (zh) * 2016-04-07 2016-08-17 高必红 一种堆料机抱闸故障的分析处理方法
US10346201B2 (en) * 2016-06-15 2019-07-09 International Business Machines Corporation Guided virtual machine migration
US10289854B1 (en) * 2016-09-23 2019-05-14 Amdocs Development Limited Apparatus, computer program, and method for generating an intermediate entitlement specification for controlling access to service or content
US10355913B2 (en) * 2017-05-04 2019-07-16 Servicenow, Inc. Operational analytics in managed networks
US11210158B2 (en) * 2017-11-29 2021-12-28 Riverbed Technology, Inc. Automated problem diagnosis on logs using anomalous telemetry analysis
JP6684850B2 (ja) * 2018-05-16 2020-04-22 株式会社日立製作所 分散台帳システム、分散台帳サブシステム、および、分散台帳ノード
JP2020071570A (ja) * 2018-10-30 2020-05-07 ファナック株式会社 データ作成装置、デバッグ装置、データ作成方法及びデータ作成プログラム
US11194591B2 (en) 2019-01-23 2021-12-07 Salesforce.Com, Inc. Scalable software resource loader
US10802944B2 (en) * 2019-01-23 2020-10-13 Salesforce.Com, Inc. Dynamically maintaining alarm thresholds for software application performance management
US10922095B2 (en) 2019-04-15 2021-02-16 Salesforce.Com, Inc. Software application performance regression analysis
US10922062B2 (en) 2019-04-15 2021-02-16 Salesforce.Com, Inc. Software application optimization
CN110516931A (zh) * 2019-08-12 2019-11-29 国家电网公司华东分部 多维度调控交互模式与全事件优化聚合的方法和存储介质
JP7077285B2 (ja) * 2019-09-19 2022-05-30 ヤフー株式会社 表示制御装置、表示制御方法および表示制御プログラム
JP6882802B1 (ja) * 2020-01-21 2021-06-02 株式会社Ｅｃｏ‐Ｐｏｒｋ 畜産情報管理システム、畜産情報管理サーバ、畜産情報管理方法、及び畜産情報管理プログラム
US20210294713A1 (en) * 2020-03-20 2021-09-23 5thColumn LLC Generation of an identification evaluation regarding a system aspect of a system
US11403165B2 (en) * 2020-04-29 2022-08-02 Kyndryl, Inc. Cognitive disaster recovery workflow management

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0296201A (ja) * 1988-09-30 1990-04-09 Mazda Motor Corp シーケンス制御方式機械装置の異常復旧装置

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5528516A (en) * 1994-05-25 1996-06-18 System Management Arts, Inc. Apparatus and method for event correlation and problem reporting
US7107185B1 (en) 1994-05-25 2006-09-12 Emc Corporation Apparatus and method for event correlation and problem reporting
US5680640A (en) 1995-09-01 1997-10-21 Emc Corporation System for migrating data by selecting a first or second transfer means based on the status of a data element map initialized to a predetermined state
US6487677B1 (en) * 1999-09-30 2002-11-26 Lsi Logic Corporation Methods and systems for dynamic selection of error recovery procedures in a managed device
JP2003108377A (ja) * 2001-10-01 2003-04-11 Seiko Epson Corp 知識ルール変換装置、エキスパートシステム、知識ルール変換プログラムおよびエキスパートシステムの構築方法
US7536370B2 (en) * 2004-06-24 2009-05-19 Sun Microsystems, Inc. Inferential diagnosing engines for grid-based computing systems
US7734945B1 (en) 2005-04-29 2010-06-08 Microsoft Corporation Automated recovery of unbootable systems
EP2998894B1 (en) * 2005-07-11 2021-09-08 Brooks Automation, Inc. Intelligent condition monitoring and fault diagnostic system
JP4896573B2 (ja) * 2006-04-20 2012-03-14 株式会社東芝 障害監視システムと方法、およびプログラム
CN101369241A (zh) * 2007-09-21 2009-02-18 中国科学院计算技术研究所 一种机群容错系统、装置及方法
US8112378B2 (en) * 2008-06-17 2012-02-07 Hitachi, Ltd. Methods and systems for performing root cause analysis
JP5237034B2 (ja) 2008-09-30 2013-07-17 株式会社日立製作所 イベント情報取得外のｉｔ装置を対象とする根本原因解析方法、装置、プログラム。
US8069374B2 (en) * 2009-02-27 2011-11-29 Microsoft Corporation Fingerprinting event logs for system management troubleshooting
EP2455863A4 (en) * 2009-07-16 2013-03-27 Hitachi Ltd MANAGEMENT SYSTEM FOR PROVIDING INFORMATION DESCRIBING A RECOVERY METHOD CORRESPONDING TO A FUNDAMENTAL CAUSE OF FAILURE
CN101833497B (zh) * 2010-03-30 2015-01-21 浪潮电子信息产业股份有限公司 一种基于专家系统方法的计算机故障管理系统
JP5419819B2 (ja) * 2010-07-16 2014-02-19 株式会社日立製作所 計算機システムの管理方法、及び管理システム
US20120030346A1 (en) * 2010-07-29 2012-02-02 Hitachi, Ltd. Method for inferring extent of impact of configuration change event on system failure
JP5432867B2 (ja) * 2010-09-09 2014-03-05 株式会社日立製作所 計算機システムの管理方法、及び管理システム
JP5658417B2 (ja) * 2012-02-27 2015-01-28 株式会社日立製作所 監視システム及び監視プログラム
WO2014033945A1 (ja) * 2012-09-03 2014-03-06 株式会社日立製作所 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム
GB2524434A (en) * 2013-09-18 2015-09-23 Hitachi Ltd Management system for managing computer system and management method thereof

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0296201A (ja) * 1988-09-30 1990-04-09 Mazda Motor Corp シーケンス制御方式機械装置の異常復旧装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
永井崇之ほか: "ＩＴシステム向け障害対処プラン自動生成システムの検討", 電子情報通信学会技術研究報告, vol. 112, no. 492, JPN6016036344, 7 March 2013 (2013-03-07), JP, pages 125 - 130, ISSN: 0003402666 *

Also Published As

Publication number Publication date
IN2015DN01974A (ja) 2015-08-14
WO2014162595A1 (ja) 2014-10-09
EP2887222A1 (en) 2015-06-24
US20160004582A1 (en) 2016-01-07
JP6114818B2 (ja) 2017-04-12
US9619314B2 (en) 2017-04-11
CN104583968A (zh) 2015-04-29
CN104583968B (zh) 2017-08-04
EP2887222B1 (en) 2020-07-15
EP2887222A4 (en) 2016-05-25

Similar Documents

Publication Publication Date Title
JP6114818B2 (ja) 管理システム及び管理プログラム
JP5719974B2 (ja) 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム
JP5684946B2 (ja) イベントの根本原因の解析を支援する方法及びシステム
US10599506B2 (en) Methods and systems for identifying action for responding to anomaly in cloud computing system
US9130850B2 (en) Monitoring system and monitoring program with detection probability judgment for condition event
US10489232B1 (en) Data center diagnostic information
JP5432867B2 (ja) 計算機システムの管理方法、及び管理システム
JP6009089B2 (ja) 計算機システムを管理する管理システム及びその管理方法
JP6190468B2 (ja) 管理システム、プラン生成方法、およびプラン生成プログラム
US20160188373A1 (en) System management method, management computer, and non-transitory computer-readable storage medium
US10360614B1 (en) Assessing and rating deployments of resources
US9021078B2 (en) Management method and management system
JP5419819B2 (ja) 計算機システムの管理方法、及び管理システム
JP6722345B2 (ja) 予兆検知装置及び予兆検知方法
US20160004584A1 (en) Method and computer system to allocate actual memory area from storage pool to virtual volume
JP5993052B2 (ja) 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム
Shahab et al. Fault Tolerance in Service Function Chains: A Taxonomy, Survey and Future Directions
Luo Cost-Based Automatic Recovery Policy in Data Centers
Wang Reliability Assessment for Cloud Applications
US20170124470A1 (en) Sequence of causes estimation device, sequence of causes estimation method, and recording medium in which sequence of causes estimation program is stored

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161114

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170314

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170317

R150 Certificate of patent or registration of utility model

Ref document number: 6114818

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150